XSS-уязвимость в почте Yahoo позволяла читать чужие письма

XSS-уязвимость в почте Yahoo позволяла читать чужие письма

XSS-уязвимость в почте Yahoo позволяла читать чужие письма

Известный исследователь Йоуко Пюннёнен (Jouko Pynnönen) раскрыл в своем блоге детали опасной уязвимости, которую компания Yahoo исправила на прошлой неделе. Интересно, что почти год назад специалист уже находил практически аналогичный баг в веб-интерфейсе почтового сервиса Yahoo.

Тогда компания выплатила Пюннёнену вознаграждение в размере 10 000 долларов, и этот приз стал одним из самых крупных за всю историю существования bug bounty программы Yahoo. Теперь, спустя чуть меньше года, исследователь заработал на очень похожей уязвимости еще 10 000 долларов.

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

Равно как и год назад, проблема связана с некорректной работой фильтра Yahoo, который должен проверять корреспонденцию на наличие малвари и вредоносного кода. Более того, Пюннёнен искал второй такой же баг специально, хотя и понимал, что вероятность обнаружить еще одну XSS-уязвимость такого рода, крайне мала. Но исследователю улыбнулась удача, пишет xakep.ru.

Эксперт пишет, что на этот раз он изучал различные опции, которые обошел вниманием в прошлый раз, к примеру, функцию «Поделиться файлами с облачного хостинга». Пюннёнен заметил, что в данном случае к письму прикладывается не обычное вложение, но HTML-ссылка на Google Docs или Dropbox. Выглядит это так:

 

 

Специалист не мог не обратить внимания на атрибуты data-* HTML, и быстро понял, что в прошлом году ему удалось вычислить далеко не все атрибуты, которые можно протащить сквозь фильтр Yahoo. К тому же атрибуты data-* HTML используются для хранения специфических данных приложений и типичны для JavaScript. Так Пюннёнен обнаружил новый вектор атаки.

Вскоре исследователь разработал тестовый кейс следующего вида:

 

capture

 

При просмотре такого сообщения в Yahoo Mail, замаскированный JavaScript немедленно выполняется (см. верхнюю иллюстрацию). Пюннёнен отследил проблему до одной из функций почтового сервиса: t.shareMenu.generateButton(r.cardUrl,s), которую эксперт приводит в блоге в слегка обфусцированном виде:

 

capture2

 

В итоге Пюннёнен создал proof-of-concept, который отправил специалистам Yahoo, вместе с информацией о проблеме. PoC исследователя использует AJAX, и как только жертва открывает вредоносное письмо, эксплоит считывает все содержимое папки «Входящие» и отправляет его на сервер атакующего. Кроме того, новая брешь позволяет оснастить письмо саморазмножающимся червем, который будет внедряться в подпись каждого исходящего письма жертвы, заражая все новые и новые ящики.

12 ноября 2016 года Пюннёнен передал свои изыскания сотрудникам Yahoo через официальную программу bug bounty на HackerOne. Уязвимость была устранена 29 ноября 2016 года, а исследователю вновь заплатили 10 000 долларов. Пюннёнен пишет, что хотя уязвимость легко эксплуатировать, найти ее оказалось не так уж просто. «Не сказал бы, что это примитивный баг, подобное вряд ли можно обнаружить, используя автоматические инструменты и сканеры», — говорит эксперт.

AppSec.Track научился проверять код, написанный ИИ

AppSec.Track добавил поддержку работы с ИИ и стал первым российским SCA-анализатором, который умеет проверять код прямо в связке с ИИ-ассистентами. Обновление рассчитано в том числе на так называемых «вайб-кодеров» — разработчиков, которые активно используют LLM и ИИ-редакторы для генерации кода.

Новый функционал решает вполне практичную проблему: ИИ всё чаще пишет код сам, но далеко не всегда делает это безопасно.

Модель может «галлюцинировать», предлагать несуществующие пакеты, устаревшие версии библиотек или компоненты с известными уязвимостями. AppSec.Track теперь умеет отлавливать такие ситуации автоматически.

Разработчик может прямо в диалоге с ИИ-ассистентом запросить проверку сгенерированного кода через AppSec.Track. Система проанализирует используемые сторонние компоненты, подсветит потенциальные угрозы и предложит варианты исправления. В основе механизма — протокол MCP (Model Context Protocol), который позволяет безопасно подключать инструменты анализа к LLM.

Как поясняет директор по продукту AppSec.Track Константин Крючков, разработчики всё чаще пишут код «по-новому», а значит, и инструменты анализа должны меняться. Редакторы вроде Cursor или Windsurf уже умеют многое, но им всё равно нужна качественная и актуальная база уязвимостей. Именно её и даёт AppSec.Track, включая учёт внутренних требований безопасности конкретной компании. В итоге даже разработчик без глубокой экспертизы в ИБ может получить более надёжный результат.

Проблема особенно заметна на фоне роста low-coding и vibe-coding подходов. Код создаётся быстрее, а иногда — почти без участия человека, но с точки зрения безопасности в нём могут скрываться неприятные сюрпризы: SQL-инъекции, логические ошибки или небезопасные зависимости. Как отмечает старший управляющий директор AppSec Solutions Антон Башарин, ИИ-ассистенты не заменяют классические практики DevSecOps — особенно когда речь идёт об open source, где информация об угрозах обновляется быстрее, чем обучаются модели.

Новый функционал AppSec.Track ориентирован на профессиональные команды разработки, которые уже внедряют ИИ в свои процессы. Он позволяет сохранить требования Secure by Design и снизить риски даже в условиях активного использования генеративного кода.

RSS: Новости на портале Anti-Malware.ru