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

Исследователь Daniel Blaklis Le Gall собрал небольшой доклад для DefCon Bug Bounty Village, на котором показал различные интересные находки.

За долгие годы охоты, он насобирал 2М$ ревардов по всем платформам. И только лишь на HackerOne в прошлом месяце он пробил потолок общих выплат в 1М$. Деньги тут как показатель упорного труда. Парень знает где и что искать. Причем на h1 у него всего 176 репортов. Где можно увидеть выплаты и по 200$ и по 75k$🤑

Никакого сканинга, никакой автоматизации. Просто глубокое и уверенное изучение целей и приложений. Доклад полон интересных технических багов разной сложности. Eсть и тупые баги, где байпас авторизации был через кнопку отмены самой авторизации(что-то похожее недавно публиковал несколькими постами выше у amazon). Очень рекомендую выделить время и посмотреть доклад всем интересующимся😉

Justin Gardner так же выступил на DefCon32 с докладом-подборкой всяких классных и сложных багов, которые он находил за последнее время на различных LHE.

Что важно - он буквально серийный Live Hacking Event Hacker. И уже это вызывает уважение. Это правда не просто.
Мне после одного ивента хотелось полежать смотря в потолок недели две. Ну и performance после ивента у меня в бб буквально упал в ноль на какое-то время. А он умудряется не выгорать, не уставать, и продолжать херачить, и доствать интересные находки не только в web, network/router, hardware но и в IoT/SIP.

ROI с 11 раскрытых репортов получилось около 300к$. Но стоит помнить что в обычной жизни оно будет стоит дешевле. Просто на ивентах щедро насыпают бонусы.
Кстати если слушать внимательно, можно понять его подход к хакингу. Это тоже занимательно.

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

(продолжение в следующем посте)

Мне кажется, что риск взлома компаний через скомпрометированные учетные записи в последнее время достиг очень высокого уровня. До задержания особо активных хакеров практически каждую неделю можно было читать о взломах очередной компании, чьи данные оказывались на форумах.

Когда эта тенденция только начинала набирать обороты, я помогал множеству компаний успеть стабилизировать свое шаткое положение с доступами к административным панелям, базам данных, системам разработки и даже системам управления поставками. Многие компании “открывали глаза” на реальность. Их команды начинали лучше понимать, почему были взломаны Rockstar, Slack и другие известные фирмы.

Но были и такие компании, которые хотели воспользоваться моментом и наказать исследователя за якобы опасные и дерзкие действия по “компрометации” систем, к которым они вообще-то не были готовы и не просили что-либо искать.

Все подобные компании заканчивали одинаково. Через год какой-нибудь блэчер продавал их данные на форуме. А в сообществе исследователей разгорался спор о том, насколько этично искать утекшие доступы — ведь это не настоящий bug bounty подход и не поиск уязвимостей. С этим в целом не поспоришь, ведь это не OWASP Top 10. Однако не стоит забывать, что большинство компаний участвуют в bug bounty, чтобы минимизировать бизнес-риски. Бизнесу не важно, насколько сложную цепочку уязвимостей нашел исследователь; важно решить проблему, которая может представлять высокий риск эксплуатации злоумышленником.

Если злоумышленник может получить доступ к системе управления поставками, остановить поставки и создать проблемы для вашей розничной сети, это вполне серьезная проблема, от которой глупо защищаться только с помощью policy на платформе.

Теперь же некоторые компании запускают программы bug bounty именно для того, чтобы сократить такой простой, но хитрый риск компрометации бизнеса. Кажется, что индустрия начинает понимать: глупо игнорировать то, что в конечном итоге может стать самой большой проблемой, по сравнению с хитроумными цепочками уязвимостей от CRLF до RCE.

Я так понимаю шансов на повторное получение американской визы у меня стало значительно меньше 😂🙈
Ps: пинганите в личку, если оказались в Нюрнберге сегодня.

Как прошли ваши выходные?

Кстати, это достаточно популярная проблема для многих компаний, когда продовые данные распиханы по всем средам для удобства разработки и тестирования. А потом, когда начинают патчить в проде, забывают сделать то же самое для dev/stg. Иногда есть среды, о которых узнают только после следующего репорта 🙈.

В итоге багхантер может сделать х2 на одной уязвимости 💁‍♂️

Подобный случай — отличный повод для давления на разработчиков с целью анонимизации данных на тестовых средах. Ведь даже если вы не успели зафиксить проблему в test/stg, уязвимость для вас будет стоить дешевле.

Гугл запускает новую волну clickjacking хакеров.
Я то конечно понимаю, что рисёрчер вроде как не с нулевой репутацией, и действительно догадывался о каких-то цепочках. Но те кто прочитает его твит, пойдут с большим усилием запихивать кликджекинг алерты с бесплатных онлайн сервисов, тупо думая что нашли кнопку «бабло» 🤦🏻‍♂️

По следам последнего поста можно выйти на очень крутой доклад от Lyra Rebane.
Причем сама история публиковалась ранее тут. Но автор собрал очень круту презу для Bsides Tallinn, и я гарантирую что вы потратите 30 минут не зря послушав его повествование, и то как находил эти цепочки уязвимостей. Тот случай когда буквально можно понаблюдать за ходом мысли.

Вчера внезапно получаю такое письмо и моментально теряю навык сна. Всё потому, что я понятия не имею, о какой компании идет речь. Не знаю, какой именно у них случился инцидент, но точно понимаю, что это мой IP-адрес, который они нашли в логах аж с февраля! Я уже начал представлять, как буду составлять алиби и объяснять, что, вообще-то, ничего не делал и катался на сноуборде в это время 🤣

Но потом резко вспомнил, что занимался ресерчем в начале года. Много сканил. И, вероятнее всего, нашел их уязвимый сервис, но даже не знал, что у ребят есть bug bounty. Так баг и пролежал почти год, пока кто-то другой не зарепортил его. Но повезло, что это инцидент в формате bug bounty, а не в формате data breach 🙊

Человек может уехать из Ижевска, но Ижевск из человека — никогда.

Каждый раз, когда покупаю что-то “недоступное”, испытываю внутренний восторг. Новые кроссовки, на которые я мог копить три стипендии, — кайф. Билет на концерт группы, которую видел только по MTV или A-One, — да это вообще сравнимо с полётом в космос. Вознаграждение в XX.XXX$ от крупной компании — дяденьки, а вы точно нулями не ошиблись? 🙊
Интересно, это у меня одного такой imposter syndrome? 🤨

Наконец-то добрались руки чтоб записать этот выпуск. Осталось найти время, собрать и выложить .
Кто угадает гостя?
Есть небольшая подсказка - Сәләм или KONNICHIWA 😎

В годы моего детства был дефицит, и понимание материальных ценностей формировалось без усилий. Надо тебе в интернете зайти по Dial-Up на 30 минут — откладываешь неделю деньги с обедов.
Ценность многих вещей была очень понятной и очевидной.
И вот теперь новому поколению надо как-то эту ценность вложить. Решили начать с простого — с PS5 🙈. Старательно откладывая монетки и реварды за успешно сданные экзамены, удалось скопить на полноценную плойку. И это в 7 лет! Теперь надо какую-то следующую цель поставить. Есть идеи?

Ну и не будем забывать, ради чего все мы тут собрались. Полезный пост о том, как можно эксплуатировать SSRF. Целиком пост можно найти здесь. Причём автор регулярно раскрывает всякие приёмчики.

В этот раз ему удалось выцепить SSRF в URL — обычное дело. Но дальше он пнул AWS Lambda Function через:

http://localhost:9001/2018-06-01/runtime/invocation/next

И уже через неё, используя github.com/assetnote/surf, он выцепил какой-то очень внутренний Swagger с возможностью выполнять неавторизованные запросы. В итоге из URL SSRF привёл к неавторизованному чтению PII из внутреннего сервиса.

Лично я не считаю подобное постэксплуатацией, так как команда компании подобный риск вряд ли найдёт (или просто не захочет признать это).

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