👋 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

👻 Сегодня у нас на повестке дня интересный репорт с 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

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

🔓 Представьте, что любой владелец группы в 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-токенам и внутренним коммуникациям. Особенно опасно это было для стандартных аккаунтов вроде demo-triager@hackerone.com, которые открывали атакующему доступ сразу во множество песочниц и программ.

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

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