https://youtu.be/HdJVFXTmEC0 я пытался шутить в этом видео

👻 Сегодня у нас на повестке дня интересный репорт с HackerOne, который отлично показывает, как даже небольшая разница в ответах сервера может привести к утечке весьма чувствительной информации. Речь пойдет о том, как можно было проникнуть за завесу и узнать о приватных программах!

🔍 Наш герой, исследуя настройки своей sandbox-программы на H1, обратил внимание на ссылку "Download list of finders that have accepted terms (.CSV)". Ссылка оказалась предсказуемой: https://hackerone.com/<handle>/terms_acceptance_data.csv.

🕵️‍♂️ Тут начинается самое интересное! Исследователь решил подставить в URL другие handle'ы и обнаружил неожиданное поведение:

– Для sandbox-программ файл скачивался (пусть и пустой).
– Для private (invite-only) программ сервер отвечал обычным 404 "Page not found".
– А вот для несуществующих handle'ов выдавалась брендированная страница 404 от HackerOne.
Эта минимальная, но стабильная разница в ответах сервера стала ключом к багу!

💥 Суть баги: Это классический случай IDOR (Insecure Direct Object Reference) в связке с information disclosure. Эндпоинт terms_acceptance_data.csv для sandbox-программ не проверял разрешения download_terms_csv, тогда как для приватных программ он заворачивал запрос в стандартный контроллер, выдавая обычный 404. Отсутствие единообразной обработки ошибок (uniform error handling) позволило любому залогиненному пользователю (даже без инвайта в целевую программу!) по реакции сервера определить, является ли тестируемый handle приватной программой или нет.

😈 Влияние: Возможность собрать каталог приватных invite-only программ — это прямая потеря конфиденциальности самого факта их существования. Зная, что такая программа есть, злоумышленники могли бы проводить целевые фишинговые атаки или социальную инженерию на ее потенциальных участников.

💸 Что по фиксу и баунти? Команда H1 оперативно всё поправила: теперь все неавторизованные запросы к terms_acceptance_data.csv всегда возвращают единый 404, независимо от типа программы. Загружать CSV разрешено только членам соответствующей баг-баунти команды. Несмотря на CVSS 6.1 (Medium), H1 классифицировала баг как Low, основываясь на своей внутренней политике о раскрытии факта существования приватной программы. Баунти составило $500.

💡 Урок для нас: Всегда обращайте внимание на мельчайшие различия в ответах сервера — будь то код ответа, размер страницы, заголовки или даже текст ошибки. Именно в этих деталях часто кроется возможность для перечисления скрытых сущностей (enumeration) и утечки информации!

🔗 Хотите углубиться? Полный текст репорта с HackerOne доступен по ссылке:
eh.su/reports/92

📌 XSS через Mastodon embeds на IRCCloud

📝 Сервис IRCCloud умел автоматически встраивать превью для ссылок на посты в Mastodon. Для этого он запрашивал метаданные по API и, что самое важное, слепо доверял полю url из ответа, используя его для создания <iframe src="...">.

💥 Исследователь под ником lotsofloops поднял свой инстанс Mastodon (sm4.ca) и в JSON-ответе на запрос метаданных подставил пейлоад в поле url:

javascript:top.document.body.innerHTML = "hi your cookie is " + document.cookie;//

В результате, браузер жертвы создавал iframe с javascript:-схемой, и скрипт тут же выполнялся, получая полный доступ к объекту top родительского окна, включая куки сессии IRCCloud. И всё это без какого-либо взаимодействия со стороны жертвы – достаточно было просто отправить ссылку в чат!

🛠 Первый фикс от IRCCloud заключался в блокировке опасных URL-схем (javascript:, data:, vbscript: и т.д.). Однако, его удалось обойти, просто добавив пробел, таб или управляющий символ перед двоеточием (например, javascript :).
Финальное решение – валидация протокола через new URL(...).protocol, что оказалось куда надежнее ручных проверок startsWith().

💣 Импакт: Кража сессионных кук вела к полному захвату аккаунта IRCCloud. Уязвимость представляла собой DOM-based XSS, но вела себя как Stored XSS, так как вредоносная ссылка оставалась в истории чата. Классическая цепочка «пользовательский URL → iframe → javascript:» снова в деле! За этот репорт было выплачено $500.

🔗 Полный разбор и все детали вы найдете по ссылке:
eh.su/reports/94

🔥 Stored XSS в GitLab Wiki через Banzai pipeline!

Да-да, снова XSS, и на этот раз в Wiki GitLab. Уязвимость позволяла через специально подготовленную Markdown-разметку внедрить HTML, который после хитроумных преобразований в браузере превращался в полноценный Stored XSS с обходом CSP. А всё из-за особенностей работы Banzai pipeline!

🐛 В чём была соль?
Ресёрчер подметил, что фильтр AbstractReferenceFilter (часть Banzai) сверял ссылку лишь по её началу (link_pattern_start), а вот замену (gsub) производил по полному регулярному выражению. Это создавало забавное расхождение: второе совпадение ссылки внутри той же строки могло угодить прямиком в атрибут alt вложенного тега <a>. Оттуда оно уже не проходило должную санитизацию. Если такую конструкцию сохранить на Wiki-странице (например, в _sidebar.md), скрипт превращался в классический Stored XSS, срабатывающий у всех посетителей проекта.

🤯 Магия mXSS и обход CSP!
Для эксплуатации использовалась техника mXSS (mutation XSS). В href внедрялся примерно такой пейлоад:

*<svg><style><img/src="0"onerror="alert(0)"></style></svg>

На бэкенде Nokogiri (HTML4-парсер) видел лишь безобидный <img>. А вот браузер (с его HTML5-парсером) после DOM-мутаций "достраивал" эту конструкцию до рабочего <img src=... onerror=...>, который исполнялся вне <svg>, эффективно обходя даже строгую CSP на gitlab.com! Это происходило из-за того, что часть данных из оригинальной ссылки (после gsub) попадала в атрибут alt таким образом, что символ " позволял "вырваться" и добавить новые атрибуты или закрыть текущий.

💣 Какие были последствия?
Любой участник проекта с правами на редактирование Wiki мог выполнить произвольный JavaScript в браузере любого посетителя этой Wiki-страницы. С учетом обхода CSP, это открывало дорогу к прямому доступу к REST API от имени жертвы. Как бонус – утечка названий приватных issues/merge requests через "засветившиеся" alt атрибуты.

🛡 Фикс и что делать?
GitLab оперативно выпустил патч в релизе 16.10.1. Командам, использующим форки или self-hosted экземпляры, настоятельно рекомендуется обновиться! Основные уроки: сопоставлять регулярки полностью, а не только префиксы, и обязательно повторно санитайзить HTML после всех внутренних фильтров.

🔗 Полный разбор и технические детали доступны по ссылке:
eh.su/reports/93

🐛 Сегодня на повестке дня интересный DoS в Monero, который можно было вызвать через RPC-сервис, просто передав слишком большое число.

⚙️ Вся соль в RPC-методе get_fee_estimate. Он принимал параметр grace_blocks (беззнаковое 64-битное целое), который мог достигать астрономического значения 18446744073709551615 (это 2^64-1, если что)
Самое забавное, что проверка на адекватность этого параметра (grace_blocks <= 100) стояла ПОСЛЕ цикла for (size_t i = 0; i < grace_blocks; ++i). Представляете, сколько итераций могло быть? 😅

🔥 Исследователь просто засыпал локально поднятую ноду асинхронными POST-запросами с максимальным значением grace_blocks. Результат предсказуем: CPU на 100%, процесс зависал намертво, и нода переставала отвечать на новые подключения. Учитывая, что Censys находил сотни публичных RPC-нод Monero, масштаб атаки мог быть весьма ощутимым, затрагивая кошельки и сервисы, зависящие от RPC для расчета комиссий.

✅ Фикс оказался до банального прост: проверку grace_blocks перенесли ДО цикла, и ограничили его значением 99. Уязвимость устранена в версии Monero 0.18.3.2. За находку исследователь получил честно заработанные 5 XMR! 💰

📖 Это классический пример ошибки логики и отсутствия должной валидации входных данных. Никаких тебе переполнений буфера или RCE, просто "бесконечный" цикл, приводящий к CPU exhaustion. Мораль: всегда валидируйте входящие параметры, особенно числа, и не стесняйтесь смотреть на порядок выполнения проверок! 😉

Подробный разбор этого кейса можно почитать на нашем сайте:
eh.su/reports/115

☣️ Web Cache Poisoning DoS в Shopify: как один \ мог всё сломать

Сегодня разберем классический Web Cache Poisoning, который мог вызвать серьезные проблемы у Shopify. Суть бага была в разном поведении CDN и origin-сервера: CDN Shopify считал, что
https://cdn.shopify.com/asset.js
и
https://cdn.shopify.com\\asset.js
— это одно и то же для ключа кэша. А вот origin-сервер так не думал и на запрос с \ отвечал 404 Not Found.

🔎 В чем суть? Атакер мог отправить один единственный запрос с обратным слэшем (\). CDN-нода, получив 404, любезно кэшировала этот ошибочный ответ для правильного URL (с /)! После этого любой пользователь, запрашивающий легитимный файл, получал закешированный 404, пока кэш не истечет. Классика, подтвержденная заголовком CF-Cache-Status: HIT.

📉 Импакт? Огромный. Любой общий JS, CSS или файл с изображением на cdn.shopify.com можно было подменить на 404-страницу. Это привело бы к частичному DoS для тысяч магазинов на платформе Shopify и даже для их собственных сервисов, ведь все ассеты грузятся именно оттуда.

💰 За эту находку исследователь получил $3800. Команда Shopify оперативно пофиксила баг, внедрив правильную нормализацию URL на уровне CDN еще до запроса к origin-серверу. Быстро, четко и по делу!

📖 Хотите узнать больше деталей, увидеть PoC-запросы и почитать о процессе фикса? Полный разбор ждет вас по ссылке:
eh.su/reports/122

💥 Захват аккаунта Hostinger в один клик: разбор красивой цепочки уязвимостей

Сегодня разберем элегантный кейс от ресерчера aziz0x48, который привел к 1-Click Account Takeover. Идеальный пример того, как одна маленькая брешь в доверии рушит всю защиту.

⛓️ Все началось с классического Open Redirect на домене аутентификации auth.hostinger.com. Как мы знаем, сам по себе он часто имеет низкий импакт. Но здесь была одна важная деталь: в белом списке разрешенных доменов для редиректа находился поддомен marketing.hostinger.com. Именно он и стал слабым звеном.

⚙️ На поддомене marketing.hostinger.com обнаружилась Reflected XSS через параметр redirect_url. В итоге получилась убийственная цепочка:

– Жертва переходит по ссылке атакующего.
– auth.hostinger.com видит, что пользователь залогинен, добавляет в URL временный auth-token и редиректит его на "доверенный" marketing.hostinger.com.
– На уязвимой странице срабатывает XSS, который простым fetch отправляет весь window.location (вместе с токеном) на сервер злоумышленника.
– Профит! Токен в руках, его можно обменять на полноценный JWT и получить полный доступ к аккаунту.

🗣 Особенно интересна коммуникация с командой безопасности. Изначально они пытались понизить критичность, ссылаясь на то, что marketing.hostinger.com — стороннее приложение вне скоупа. Ресерчер грамотно парировал:

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

В итоге команда Hostinger согласилась и исправила уязвимость.

🎓 Главный вывод: Доверие должно быть подкреплено проверкой. Наличие поддомена в вайтлисте не делает его автоматически безопасным. Любая доверенная сущность — это часть вашей поверхности атаки.

🔗 Полный разбор кейса читайте на нашем сайте:
eh.su/reports/124

Приходите в 13:00 на моё выступление))
Подготовил для вас что-то интересное 😎

Как владелец группы мог захватить любой аккаунт

🔓 Представьте, что любой владелец группы в GitLab мог получить полный доступ к вашему аккаунту, просто заставив ваш браузер открыть скрытую картинку. Именно такая уязвимость была найдена и исправлена. Атакующий мог создать OAuth-приложение в своей группе, тайно пометить его как «trusted» (доверенное), и GitLab начинал выдавать access_token'ы для любого пользователя без экрана согласия.

💡 Вся магия крылась в незащищенном эндпоинте. В интерфейсе GitLab нельзя было сделать приложение «доверенным» на уровне группы, но исследователь предположил, что сам фреймворк Doorkeeper это умеет. Перехватив запрос в Burp, он просто добавил параметр doorkeeper_application[trusted]=1, и сервер принял его без дополнительной проверки прав! Классический пример того, почему нельзя доверять данным, приходящим с клиента.

🔗 Дальше — дело техники. Злоумышленник формировал ссылку для авторизации, где в redirect_uri был указан его собственный домен. Эту ссылку можно было вставить куда угодно, даже в тег <img>. Как только жертва, залогиненная в GitLab, открывала страницу с этой картинкой, её браузер автоматически отправлял запрос, GitLab мгновенно выдавал authorization_code и перенаправлял его на домен атакующего. Пользователь при этом ничего не замечал.

🚨 Итог — полный захват аккаунта с правами scope=api. Это давало возможность читать приватные репозитории, изменять код, красть CI/CD переменные и SSH-ключи. Уязвимость получила рейтинг Critical с оценкой CVSS 9.6.

🧠 Главный вывод для всех нас: всегда проверяйте критически важные флаги (trusted, admin и т.д.) на стороне сервера, а не просто скрывайте их в UI. Атакующий всегда найдет способ их подставить. И, конечно, валидация redirect_uri в OAuth-сценариях — это святое.

Полный разбор и детали от исследователя читайте в отчёте на нашем сайте:
eh.su/reports/125

🎧 Ваши крутые Sony WH-1000XM5 могут подружиться с кем угодно, даже без вашего ведома!

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

🥷 Атакующему достаточно подделать MAC-адрес и имя вашего ноутбука или смартфона (классический Bluetooth spoofing), и наушники сами к нему подключатся. Самое интересное: для этого не нужно переводить гарнитуру в режим сопряжения. Достаточно просто её включить, и она автоматически инициирует соединение с поддельным устройством.

💥 Последствия? От безобидного DoS, когда наушники «заняты» и не могут подключиться к вашему устройству, до полноценной MitM-атаки с перехватом аудиопотока и доступом к голосовому ассистенту. Уязвимость классифицирована как CWE-306 – Missing Authentication for Critical Function.

💰 А теперь самое интересное из-за кулис программы баг-баунти. Несмотря на высокий приоритет, Sony первоначально предложила... 0$ (но пообещала swag!). Ресёрчеру пришлось несколько месяцев вежливо, но настойчиво напоминать о себе, прежде чем компания подтвердила уязвимость и запланировала выпуск патча. Классика жанра для «железных» багов!

📖 Полный разбор с техническими деталями, pcap-файлами и рекомендациями для разработчиков уже ждет вас на сайте:
eh.su/reports/126

🐛 На повестке дня — классический, но от этого не менее интересный Subdomain Takeover на домене не кого-нибудь, а самого firefox.com. Исследователь обнаружил, что один из поддоменов остался без присмотра, что открыло дверь для целого ряда атак.

⛓️ Суть бага до смешного проста: поддомен ████.firefox.com через CNAME-запись указывал на ресурс www.mozilla.org, который когда-то хостился на популярной PaaS-платформе. Вот только сам хост на платформе уже удалили, а про DNS-запись попросту забыли. Классический dangling CNAME, который позволил исследователю зарегистрировать этот «бесхозный» хостнейм на себя и получить полный контроль над контентом.

💣 Помимо очевидных векторов вроде фишинга и распространения malware под видом официальных обновлений Firefox, репортёр продемонстрировал и более изящную атаку — Cookie Bombing. Загрузив на захваченный поддомен страницу, которая устанавливает куки огромного размера (~100 KB), он смог вызвать ошибку 413 Request Entity Too Large для всего домена firefox.com, эффективно блокируя доступ для пользователей.


✅ Автоматизация и гигиена DNS — наше всё. Неполный офф-бординг ресурсов — частая причина таких уязвимостей. Регулярные сканы на «висящие» записи (привет, subjack!) и четкие чек-листы в CI/CD при удалении сервисов помогают избежать подобных ситуаций.
Даже строгие CAA-записи, как в случае с Mozilla, не спасают на 100%, а лишь усложняют эксплуатацию для атакующего.

📖 Полный разбор с техническими деталями и скриншотами как всегда по ссылке:
eh.su/reports/127

🤯 HackerOne случайно слили приватные репорты через... публичные репозитории GitHub

Ресёрчер w2w наткнулся на несколько GitHub-профилей вида h1_analyst_*, которые принадлежали triage-командам HackerOne. В них нашлось более 40 публичных репозиториев с PoC-скриптами и workflow-файлами. Внутри — готовые эксплойты для IDOR, утечек access-token и даже RCE в продуктах, которые участвовали в закрытых программах. Фактически, это были полные тексты ещё нераскрытых отчётов.

🤦‍♂️ Как такое вообще могло произойти?
Всё дело в классической OPSEC-ошибке. Для проверки багов триажеры создавали публичные форки и репозитории, а после тестов просто забывали их удалять или переводить в private. Профили имели предсказуемые имена, а найти их можно было через обычную user-enumeration в интерфейсе GitHub, подставляя email-адреса на домене @wearehackerone.com.

💥 Импакт — настоящий подарок для злоумышленников.
Любой мог подписаться на изменения в этих репозиториях и в реальном времени получать свежие эксплойты, пока клиенты HackerOne ещё работали над патчами. Это открывало возможность для массового «zero-day farming» и перехвата CI/CD-секретов прямо из логов GitHub Actions. Атака была тривиальной, а ущерб для клиентов мог быть колоссальным.

💰 Что в итоге?
Сначала репорт пытались отклонить, назвав данные «тестовыми», но ресёрчер доказал обратное. После долгой переписки и чистки репозиториев HackerOne выплатила $2700 + бонус.

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

🔗 Полный разбор этой истории и все технические детали читайте на нашем сайте:
eh.su/reports/128

🔬 Ловите разбор крутейшего кейса: Stored Mutation XSS, который превращается в RCE в десктоп-клиенте Basecamp! Уязвимость нашли в популярном WYSIWYG-редакторе Trix Editor.

🤯 В чем магия? В двойном парсинге DOM.
Ребята обнаружили, что кастомный HTML-санитайзер редактора можно обмануть. Специально созданная конструкция с MathML и тегом <mglyph> кодируется в атрибут data-trix-attachment. После простого копирования и вставки в редактор, браузер «мутирует» безобидную на первый взгляд разметку, и наш <img src=x onerror=alert()> оживает.

🚀 Но самое интересное — эскалация!
XSS в приложении на старом Electron — это почти всегда прямой путь к RCE. Исследователи так и сделали: через XSS они подгрузили iframe с эксплойтом, пробили песочницу через две n-day уязвимости в V8 и получили заветный WinExec("calc.exe").

💪 Забавно, что с RCE пришлось повозиться. Эксплойт был настолько капризным к окружению, что для подтверждения уязвимости ребятам пришлось предоставить команде Basecamp полностью настроенный AWS-инстанс с удаленным доступом. Вот это я понимаю, сервис!

📚 Кейс наглядно демонстрирует, почему кастомные санитайзеры — зло, а обновлять Electron — жизненно необходимо. Рекомендованный фикс, конечно же, переход на DOMPurify.

🔗 Хотите погрузиться в технические детали, посмотреть на 600-строчный JS-эксплойт и ROP-цепочки? 👉 eh.su/reports/132

🤔 Представьте: полный захват аккаунта (Account Takeover) на самом hackerone.com! И всё из-за одной хитрой логической ошибки в SCIM-синхронизации. Недавно один из исследователей показал, как обычная функция для удобства бизнеса превратилась в вектор для атаки.

💥 Суть уязвимости, как часто бывает, невероятно проста.
При синхронизации пользователей через Identity Provider (например, Okta), HackerOne проверял доменную принадлежность только поля username. А вот поле email он слепо доверял и обновлял без какой-либо проверки. Атакующему было достаточно импортировать пользователя-жертву, оставить его username без изменений, но в поле email указать свой собственный адрес на предварительно верифицированном домене.

🔑 После автоматической синхронизации email жертвы тихо и незаметно менялся на email атакующего, без каких-либо уведомлений старому владельцу. Оставалось лишь нажать «сбросить пароль» — и вуаля, письмо для смены пароля прилетало прямиком к злоумышленнику. Game over: полный контроль над чужим аккаунтом.

💣 Импакт колоссальный: доступ к приватным отчётам, API-токенам и внутренним коммуникациям. Особенно опасно это было для стандартных аккаунтов вроде [email protected], которые открывали атакующему доступ сразу во множество песочниц и программ.

🛡 Команда HackerOne оперативно всё исправила. Теперь они валидируют домены и у username, и у email.
Мораль этой истории проста: всегда тщательно тестируйте логику работы с внешними системами идентификации. Даже маленькое допущение или упущение в валидации может привести к критической уязвимости.

📖 Детальный разбор со скриншотами и полной хронологией читайте в нашем подробном анализе:
eh.su/reports/133

🕵️‍♂️ Слив чужих эмейлов через приватный лидерборд WakaTime.
Как простая социальная фича превратилась в канал утечки данных?

Исследователь ctrl_cipher обнаружил, что в WakaTime можно было вытащить email пользователя, даже если он был скрыт в настройках приватности.

🐛 Вектор атаки был слишком прост: злоумышленник создает приватный лидерборд, приглашает туда жертву по её публичному @username, и как только та принимает инвайт — её скрытый email волшебным образом появляется в списке участников. Классический Information Disclosure, вызванный некорректным контролем доступа. Никаких внешних инструментов не требовалось.

⚙️ А почему так вышло?
Ошибка стара как мир: бэкенд отдавал в API полный объект пользователя, целиком и полностью доверяя фронтенду отфильтровать приватные данные. Разработчики, видимо, посчитали, что внутри «приватного» пространства можно не так сильно заморачиваться с проверками.

Никогда, слышите, НИКОГДА не доверяйте клиенту!

⚠️ Утечка PII — это прямой путь к целевому фишингу и нарушению регламентов вроде GDPR. К счастью, команда WakaTime отреагировала быстро и оперативно запатчила дыру. Репорт был принят, но баунти составило $0 (видимо, скрыто).

💡 Главный урок: всегда фильтруйте чувствительные данные на стороне сервера. Любая фича, работающая с данными нескольких пользователей, должна проходить строгий privacy-review. Даже такая безобидная, на первый взгляд, как таблица рекордов.

🔗 Полный разбор с техническими деталями и рекомендациями читайте по ссылке:
eh.su/reports/134

🏆 Накручиваем репутацию на HackerOne: разбор бага на $2,500

🎭 Представьте, что вы можете сами себе выписывать хвалебные отзывы на HackerOne, становясь «топовым» хакером за пару кликов. Именно такую возможность давала комбинация логической ошибки и IDOR в Sandbox-программах.
Система позволяла оставлять отзывы (Testimonials) после закрытия репорта, но проверка того, кто и кому оставляет отзыв, происходила только на клиенте. Сервер слепо доверял присланным данным.

⚙️ Вся магия заключалась в простом POST-запросе. Исследователь мог создать собственную Sandbox-программу, отправить туда фейковый репорт, закрыть его и в форме отзыва подставить любой hacker_username. Таким образом, можно было опубликовать отзыв от имени своей же тестовой программы на свой основной аккаунт. Или на аккаунт любого другого исследователя!

POST /hacker_reviews
{
  "hacker_username": "victim_user",
  "report_id": 1234567,
  "positive": true,
  "public_feedback": "+1 pentester, ship it!"
}

💥 Импакт очевиден: подрыв доверия ко всей репутационной системе платформы. Можно было за считанные минуты создать профиль «топового» исследователя с десятками положительных отзывов, обманывая заказчиков, работодателей и влияя на распределение приглашений в приватные программы. Чистый обман, основанный на уязвимости.

🧠 Главный урок: автоматические сканеры здесь бессильны. Уязвимости в бизнес-логике — золотая жила для багхантера. Любая функция, влияющая на репутацию, требует железобетонной серверной валидации прав.
Команда HackerOne в итоге исправила баг, удалила фейковые отзывы и выплатила $2,500 в качестве награды.

Полный и детальный разбор уязвимости, включая хронологию и рекомендации по фиксу, читайте по ссылке ниже 👇
eh.su/reports/135