Вот теперь уже можно официально признать тот факт что DELL могли закрыть проблему год назад, но предпочли сэкономить 2500$ на critical репорте, засунули его в informative state и даже ничего не исправили!
Это реалии bug bounty management и policy. Когда важнее рисёрчера поставить на место, чем разбираться в проблеме, которая как будто не в твоей зоне отетственности. При этом как мне правильно подметили в комментах в твиттере - "Threat actors don't care about your bugbounty program's scope".

Теперь в новостях даже написано что "Hackers claim a second Dell data breach within a week, exposing sensitive internal files via compromised Atlassian tools. Allegedly, data from Jira, Jenkins, and Confluence was leaked.". Список затронутых систем в действительности более жирный - git, jira, confluence, jenkins, artifactory etc

Сейчас они героически порасследуют и скажут что ничего серьезного не украдено.
Однако сама проблема не в том что могло быть что-то украдено. А в том что обнаруженная нами ранее supply chain issue связанная с одним из подрядчиков, позволяла комитить в main, и ходить по репозиториям собирая hardcoded secrets от следующих сервисов. А вы что думали компания с офигенной капитализацией умеет в secret management? 😂

Когда мы это нашли, то ощущения были весьма стремные. Прикиньте такая большая контора, которая технику поставляет огромным корпорациям, а вы берете, заходите в их деплой системы и можете вредоноса оставить, и в системах закрепиться, и никто это даже исправлять не хочет 🫠

Думаю многие из вас слышали такую компаний как Detectify. И думаю многие из вас знают что одним из кофаундеров этого проекта, и основным "двигателем прогресса" был Frans Rosén. Он делал для компании маркетинг через секьюрити рисёрчи. Продвигал возможности исследователям монетизации уязвимостей через платформу. Вообще для меня Detectify был а ассоциации с Frans Rosén.
В начале сентября его доля в компании была передана в пользу текущего руководства. Подозреваю что он бы не оставил "своего ребенка" после стольких лет работы. Очень жаль что текущее руководство выбрало странный стиль управления и развития компании. Максимально спорное решение, которое в перспективе ни к чему хорошему не приведет.

Но Франс такой человек, который точно не нуждается в том, что его нужно жалеть. Пару дней назад он забрал уже четвертый MVH титул на Live Hacking Event, где основным кастомером был Amazon. С учетом что это достаточно сложный таргет, Франс в очередной раз доказал свое место в индустрии. Респект!

Синоптики обещают, что следующая неделя станет неделей переработок, бессонных ночей и попыток найти всё, о чём могли забыть или не знать.
Спасибо Linux CVSS 9.9 RCE и итальянскому исследователю Simone Margaritelli 😰
"The vulnerability, which allows for unauthenticated remote code execution (RCE), has been acknowledged by major industry players like Canonical and Red Hat, who have confirmed its severity with a CVSS score of 9.9 out of 10."

Update: Комментарии от самого исследователя - "it's bad but not shellshock bad ... tbh i think the initial 9.9 has been assigned because it's trivial to exploit and it's extremely widespread ... yet, it's not that bad, you'll see"

В bug bounty программе TikTok завелся старательный исследователь. Он не был приглашен на последний event от Hackerone (немного слов о справедливости распределения инвайтов). И даже после ивента где выгребли 1M$, он продолжает выгребать уязвимости.
Сейчас он опубликовал весьма стремную историю. И в целом из-за этой истории, американцы могут дальше продолжить топить приложение в легальном поле. Парниша конечно зря такое написал, и вероятно скоро даже удалит этот пост. Но интернет все помнит 😉
А TikTok ничего не удаляет 💁🏻‍♂️

В HackerOne Leaderboard с недавних пор появилось разделение по технологиям. Теперь можно посмотреть, кто лучший веб-хакер, кто лучший специалист по мобильным приложениям. Но что более интересно — можно увидеть, кто лучший AI-хакер.
Правда, после этого можно узнать, в каких программах участвуют эти исследователи, и сделать соответствующие выводы о надежности того или иного AI-решения 🙈.

Однако, пока за год статистика не слишком впечатляющая, и в общей массе уязвимостей за год сдано довольно мало.
PS: Нашел пару знакомых ребят в списке. Попробую узнать и рассказать что же там за AI баги такие находят 😉

Выглядело это всё дело как уверенный пятизнак🤑
Но посмотрим что будет в итоге. Ведь первое правило в bug bounty - ноль ожиданий!
Ребят из Amazon и так на днях потратили 2M$ на HackerOne Live Event. И думаю могли быть не готовы к таким интересным поворотам судьбы.

Полезный лайфхак. Сервис явно напрашивался на кавычку. Но вот беда - был нужен юзер, под которым можно кавычку вставить. Зарегать своего юзера не позволяло ограничение по домену. Однако регнуть krevetk0@amazon.com никто не запрещал. Да, конечно надо еще верифицировать аккаунт через почту...
Но кто сказал что это обязательная процедура?!😉

У индийцев произошел слив данных от крупной страховой компании Star Health. Но самое удивительное в этой ситуации — то, что главный специалист по информационной безопасности (CISO) этой компании решил заработать на стороне и продал доступы к данным хакерам. Т.е он буквально за деньги выдал хакерам доступы к API через proton mail.

Сначала CISO продал хакерам данные более 31 миллиона клиентов, включая информацию о зарплатах и налоговых номерах (PAN). Позже он предложил им доступ к данным страховых выплат за дополнительные деньги. Когда хакеры получили 5 ТБ данных, доступ был заблокирован, и CISO потребовал еще больше — заявив, что теперь нужно поделиться с руководством 😁

По итогу хакеркам не понравились такие расклады, и они потребовали возврат денег, которые уже оплатили индийцу. Индиец само собой ушел в несознанку. А хакеры из xenZen решили слить все пруфы этой истории. Читать эту историю просто потрясно. А смотреть qTox чат просто заглядение.

Исследователь нашёл весьма интересный баг в Zendesk. Сочетание TicketTrick с Email Spoofing позволяло добавлять себя в любые запросы от имени сотрудника компании, что открывало доступ ко всем деталям запросов в поддержку через Zendesk.

The bug itself was surprisingly simple. Zendesk had no effective protection against email spoofing, and this oversight made it possible to exploit their email collaboration feature to gain access to others’ tickets.

Однако упоминание о проблемах с DKIM и SPF сыграло с исследователем злую шутку. Контора решила что это и не баг вовсе. Хотя он весьма серьезный пример эскалации нарисовал. Ну и как я понял он еще у клиентов Zendesk немного денег собрал(там где есть bug bounty) благодаря такому багу by design. После чего zendesk был вынужден запатчить проблему на корню.

Вообще, все эти SaaS-решения и сторонние сервисы — это уникальное пространство, где можно найти одну уязвимость и затем эксплуатировать её у множества компаний. И главное, чтобы вендор придерживался позиции, что все его клиенты "должны быть в курсе" настроек безопасности и сами исправлять проблемы. Идеальо если это был письменный ответ. Это развязывает руки и позволяет “майнить” куда больше, чем этот исследователь.
Мне так удалось намайнить шестизнак... Но об этом как нибудь потом 😉

В последнее время попадаются ситуации когда есть XXE, но максимум что можно прочитать, это etc/hostname.
И вот в выходные предоставилась возможность потыкать очередную XXE. С первого взгляда работало только etc/hostname.
Но сервис был слишком интересный с точки зрения bug bounty. И я пошел собирать любые сведения о системе.
Почти всё из этого не работало, но, возможно, пригодится в будущем.

/proc/self/environ
/proc/X/environ (X от 1 до 10000)
/proc/self/cmdline
/etc/environment

Определяем тип системы

/sys/class/dmi/id/product_name
/sys/class/dmi/id/sys_vendor
/proc/net/arp
/etc/fstab
/etc/mtab
/etc/os-release
/etc/apt/sources.list.d
/etc/logrotate.conf
/etc/logrotate.d
/etc/php5/apache2/php.ini
/etc/group
/etc/hosts
/etc/issue
/etc/passwd
/etc/resolv.conf
/etc/shells
/proc/cmdline

Но дальше случилось удивительное.
Hostname вернул имя, и из-за него я решил что это какой-то микросервис на поде и попробовал выцепить следующее

/var/run/secrets/kubernetes.io/serviceaccount/token
/var/lib/docker/containers/
/etc/docker/
/etc/kubernetes/
/var/log/syslog
/etc/kubernetes/kubelet.conf
/var/lib/kubelet/config.yaml
/etc/kubernetes/admin.conf
/root/.kube/config
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
/var/run/secrets/kubernetes.io/serviceaccount/namespace
/root/.docker/config.json

Полученный случайно Kubernetes service account token, который мне вернулся по первой команде, позволял долбиться в Kubernetes API. По идее, для bug bounty это уже достаточно, чтоб отправить репорт. Но пока репорт рассматривается, попробую найти имя kubernetes api server, к которому, собственно полученный jwt токен и подойдет.

Jhaddix пошарил сокращенный формат своего AI тренинга на OWASP AppSec San Francisco. Дед продолжает поставлять годный контент, за что ему спасибо.
PS: Думаю теперь сходить на полноценный тренинг. Вот только дождусь когда за XXE заплатят 😁
https://youtu.be/XHeTn7uWVQM?si=98WOlJQN1qxv_lGI