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

В 2010 году, когда направление багбаунти еще не получило широкой известности, корпорация Google запустила свою программу вознаграждений за уязвимости. С тех пор в Google Vulnerability Reward Program поучаствовало более 3000 исследователей безопасности. Каждый год Google обновляет списки своих лучших багхантеров, которые нашли наибольшее количество уязвимостей в их продуктах. И нам удалось пообщаться с одной из них.

Алёна Склярова — исследователь безопасности, занимает 13-е место в топе багхантеров Google за последний год, а также 13-е место в рейтинге исследователей Android за все время. Алёна нашла несколько десятков уязвимостей в операционной системе Android, за что неоднократно получала благодарности от Google. Большинство найденных уязвимостей имеют высокий уровень опасности, все они отмечены в бюллетенях безопасности Android.

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

Как все началось?

Когда-то давно, на старте карьеры, мне посчастливилось попасть на работу в исследовательский центр одной известной российской IT-компании. Несмотря на рабочие проекты, у каждого сотрудника центра был свой ресерч, которым он занимался в свободное время. Многие коллеги работали в этой области достаточно долго и уже были признанными гуру реверса и бинарной эксплуатации. Они участвовали в багбаунти-программах Apple, Samsung, Mozilla, NVIDIA и активно делились своим опытом, рассказывали про свои исследования. Коллеги очень вдохновили меня, и я решила тоже попробовать сделать свой ресерч.

Нужно было определиться с областью исследования, где буду искать уязвимости. В итоге мой выбор пал на операционную систему Android, поскольку она доминирует на рынке мобильных ОС, и ее уязвимости могли бы подвергать опасности сотни миллионов пользователей по всему миру. Так я погрузилась в ресерч Android Open Source Project (AOSP) и узнала про существование Android Security Reward Program.

Пробовала искать баги в Android-приложениях? У Google же есть отдельная программа вознаграждений по ним.

Да, была такая программа — Google Play Security Reward Program, в рамках которой можно было получить вознаграждение за уязвимости в мобильных приложениях с более чем 100 миллионами установок в Google Play. Однако с 31 августа 2024 года программа была объявлена закрытой из-за уменьшения количества обнаруживаемых уязвимостей.

Забавно, но когда-то поиск и эксплуатация уязвимостей в мобильных приложениях были моей основной работой. Но стоило попробовать поковыряться в ОС — приложения отошли на второй план и уже не так увлекали.

Почему выбрала исследовать ОС?

Операционная система значительно более многогранна, чем даже самое функционально насыщенное приложение. Мне очень интересно изучать, как взаимодействуют между собой и функционируют различные компоненты ОС — от высокоуровневого Java-мира до нативных модулей системы и ядра.

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

Расскажи про свой первый баг.

Участвовать в Google Bug Bounty я начала летом 2022 года. Но с места в карьер не получилось.

Первые два месяца после регистрации на платформе все мои попытки сдать отчет об уязвимостях проваливались. То Google зачли отчет как дубликат какой-то проблемы, то инженерам не удалось воспроизвести баг, то посчитали, что все работает, как задумано, и это не баг, а фича. Сдаваться, конечно, не хотелось. Этот этап был достаточно изнуряющим, хоть и в какой-то степени самым важным. Я получила очень ценный опыт: изучила, как работают системные сервисы, как компоненты ОС «общаются» друг с другом. Код операционной системы мне многое подсказал и многому научил. Параллельно этому я узнала, как работает программа Google Bug Bounty, как сделать грамотный отчет, какие ошибки не стоит допускать, как подготовить PoC, как взаимодействовать с Android Security Team и так далее.

В конце концов в начале осени того же года я получила свой первый успешный зачет уязвимости. Она заключалась в обходе Android-разрешения QUERY_ALL_PACKAGES, которое приложения могут получить только после прохождения модерации Google, и утечке информации о пакетах, установленных на устройстве. Баг достаточно простенький, однако он прервал полосу неудач, и радости не было предела.

Если я нашел баг, как мне сообщить об этом?

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

Обязательно прочитайте правила программы на портале Google Bug Hunters. Здесь вы найдете ответы на самые популярные вопросы, лучшие практики, а также примерные суммы выплат за различные категории уязвимостей. Интересно, что, по статистике Google, более 90% присылаемых отчетов не содержат информации об уязвимостях.

Отчет нужно сформулировать грамотно и сделать его максимально полным. Помните, что ваш отчет также будет оцениваться по шкале качества. Чем ниже report quality, тем ниже будет выплата. Так Google мотивирует исследователей подготавливать качественные и подробные репорты. Составляйте отчет на английском языке. Придумайте заголовок, который бы отражал суть проблемы и ее импакт на безопасность, оставаясь при этом кратким и информативным, например: «Heap overflow in ClassName#MethodName allows return pointer overwriting that leads to remote code execution». Предоставьте технические детали уязвимости, описание модели злоумышленника, инструкцию по воспроизведению. Также нужно прикрепить PoC, стек-трейсы, фингерпринт устройства.

Что добавлять в технические детали?

Раздел технических деталей уязвимости — один из самых важных. Вот что стоит туда включить:

1. Краткое описание уязвимости и импакта на безопасность.

2. Опишите, как вы обнаружили уязвимость в коде, ход ваших мыслей очень важен. Смело цитируйте код AOSP, добавляйте скриншоты дизассемблера или дебагера, если реверсили и доступа к исходникам нет.

3. Прикладывайте стек-трейсы, краш-кейсы, если фаззили.

4. Обязательно проведите анализ вредоносного влияния. Продемонстрируйте, что может получить атакующий в результате эксплуатации уязвимости.

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

6. Опишите принцип работы PoC.

Как должен выглядеть PoC?

PoC всегда очень зависит от типа уязвимости и эксплуатации. PoC может быть чем угодно — мобильным приложением, исполняемым файлом, скриптом, набором байтов. В случае с удаленной эксплуатацией может понадобиться дополнительное устройство. Но есть единое правило — PoC должен воспроизводиться на последней сборке AOSP. Если прикладываете приложение Android в качестве PoC — помните, что заранее собранные APK-файлы в качестве доказательств не подойдут. Вместо этого предоставьте проект Android Studio, а инженеры сами все соберут.

Еще один важный момент. При создании PoC постарайтесь не использовать внешние зависимости. Например, крайне не рекомендуется подключать сторонние библиотеки в проект Android Studio. У меня были случаи, когда такие доказательства не принимались.

Кроме того, стоит приложить дополнительные материалы, которые способствуют быстрому и беспрепятственному воспроизведению уязвимости. Например, я очень часто прикладываю скриншоты и небольшие видеофайлы, где демонстрирую работу PoC. То есть, по сути, делаю визуализацию инструкции по воспроизведению.

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

Нужно ли предлагать исправления уязвимости?

Это не обязательно, но если можете — то да!

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

Ознакомиться с Patch Rewards Program Rules можно на сайте.

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

Могу ли я рассказать кому-нибудь о своей находке?

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

Сколько ждать финального решения?

В среднем уязвимость оценивают около двух недель. У меня есть рекорды в обе стороны, когда отчет рассмотрели супербыстро — за два дня, и когда изучали очень долго — почти шесть недель.

Уязвимости оцениваются инженерами Google в соответствии с Severity Assessment Matrix. Обратите внимание на таблицу с рейтингами, которые варьируются от низкого до критического, а также на модификаторы рейтинга. Это такие случаи, когда у вашей уязвимости может быть снижен уровень опасности. Это очень неприятный кейс, и мне даже удалось один раз с этим столкнуться: уязвимость, которая изначально была оценена как высокая, была понижена до средней.

Какой может поступить ответ?

Тут всего два варианта:

1. Уязвимость подтвердили, присвоили рейтинг от низкого до критического.

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

В конце — присвоение уязвимости CVE ID, публикация в бюллетене безопасности Android, и выражение благодарности (acknowledgements) от Android Security Team.

Обратите внимание, что в бюллетенях за последний год вы не встретите уязвимостей с рейтингом ниже высокого, то есть только критические и высокие. Суть в том, что в мае 2023 года были изменены правила Android VRP, согласно которым теперь за средние баги CVE присваиваться не будут. Плюс сама матрица иногда обновляется, и некоторые виды импакта могут подлежать переоценке.

2. Уязвимость не подтвердили.

Вердиктов тут несколько. Я сталкивалась со следующими: NSBC (Not Security Bulletin Class) и Duplicate (дубликат). С дубликатами все понятно — другой исследователь отправил отчет об этой уязвимости раньше, чем вы. NSBC же обозначает уязвимости, не подпадающие под критерии матрицы, и чаще всего соответствует незначительным проблемам безопасности. NSBC всегда дополняется статусом:

• Won’t fix (Not reproducible)

Инженеры не смогли воспроизвести баг. Это может быть по причине плохо составленной инструкции или некорректно работающего PoC, но чаще всего происходит из-за того, что баг уже исправлен. Например, во внутренней инженерной сборке Android.

• Won’t fix (Intended behavior)

Все работает как надо, никакого бага здесь нет.

• Won’t fix (Infeasible)

Чаще всего это уязвимости со слабым импактом на безопасность. Google считает этот риск допустимым и оставляет все как есть.

• Won’t fix (Obsolete)

Достаточно редкий тип, означает, что баг устарел. Встречала только в публичном трекере багов (Issue Tracker).

У тебя часто проваливались отчеты?

Достаточно часто, особенно на старте, когда только учишься и набиваешь шишки. Сейчас количество неудач у меня пока что преобладает над числом побед. Имею 55% провалов, то есть больше половины отправленных отчетов не были зачтены. Через край их нахваталась в самом начале пути. В основном из-за дубликатов и багов низкого влияния на безопасность.

Потом я поработала над ошибками. Если за первый год успешных отчетов — всего 13%, то за последний — 85%.

Сколько времени уходит на поиск одного бага?

Всегда по-разному. Бывает, везет что-то расковырять интересное за пару дней, а бывает, что несколько недель можно биться и ничего не найти. Если у вас есть основная работа, а багхантинг — хобби (как в моем случае), то временные ресурсы будут ограничены, и поиски могут затянуться.

Расскажи про свои баги.

Успешно засчитанных уязвимостей в Android у меня пока что 30 штук. Из них 10 уже имеют свои CVE ID, остальные ожидают присвоения.

На старте я больше концентрировалась на поиске утечек через обход запроса разрешений, о чем уже говорила. Раньше такие баги оценивались как средние, но были понижены до низкого рейтинга, и больше CVE за такую утечку не получить. Пример — CVE-2023-21348.

Сейчас в основном нахожу баги типа EoP и permanent DoS. Все они имеют высокий уровень опасности.

Например, найденная уязвимость CVE-2024-23713 позволяла вредоносному приложению получить право на прослушивание уведомлений, даже если пользователь не предоставил таких разрешений. А результатом эксплуатации уязвимости CVE-2023-21240 являлся перманентный отказ в обслуживании устройства, при котором смартфон входил в состояние бесконечного цикла загрузки и становился непригодным для использования. Это происходило из-за переполнения кучи и исчерпания ресурсов системы на этапе ее загрузки при обработке Wi-Fi конфигурации устройства.

Как попасть в топ рейтинга?

Достаточно сложно, но возможно. Нужно успешно сдать как можно больше классных баг, которые продвинут вас вперед. Помните — конкуренция высока! Очень много крутых ребят багхантят, многие — по несколько лет. А на старте всегда нелегко.

Рейтинг в целом очень динамичная штука — всегда меняется. Нашел новые уязвимости? Значит, продвинешься наверх. А если не искал, был занят чем-то другим, то начинаешь потихоньку скатываться, кто-то выходит вперед. Это нормально.

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

Что важно для успешного поиска уязвимостей?

Я думаю, ключевым моментом является умение быстро адаптироваться и не бояться открывать для себя новое. Вдохновляйтесь другими исследователями, анализируйте и читайте их работы, развивайте собственные идеи. Ведите заметки по ходу ваших поисков — к ним всегда можно будет вернуться и свежим взглядом увидеть то, что раньше оставалось незамеченным. Способность учиться новому, совершенствовать свои навыки и продолжать двигаться вперед, несмотря на неудачи, — залог успеха в багхантинге.