Ни для кого не секрет, что багхантинг с каждым годом набирает популярность, привлекая внимание как компаний, стремящихся повысить безопасность своих продуктов, так и белых хакеров, желающих применить свои технические навыки и заработать на поиске уязвимостей. Все больше компаний создают собственные багбаунти-программы, некоторые интегрируются в уже существующие площадки.
В 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, стек-трейсы, фингерпринт устройства.
Что добавлять в технические детали?
Раздел технических деталей уязвимости — один из самых важных. Вот что стоит туда включить:
-
Краткое описание уязвимости и импакта на безопасность.
-
Опишите, как вы обнаружили уязвимость в коде, ход ваших мыслей очень важен. Смело цитируйте код AOSP, добавляйте скриншоты дизассемблера или дебагера, если реверсили и доступа к исходникам нет.
-
Прикладывайте стек-трейсы, краш-кейсы, если фаззили.
-
Обязательно проведите анализ вредоносного влияния. Продемонстрируйте, что может получить атакующий в результате эксплуатации уязвимости.
-
Отметьте вероятность успешной эксплуатации и необходимые для этого ресурсы. Обязательно опишите характеристики устройств или эмуляторов, на которых вы тестировали PoC. Приложите конфиги, опишите среду, которую нужно подготовить заранее, чтобы баг успешно показал себя.
-
Опишите принцип работы 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. Обратите внимание на таблицу с рейтингами, которые варьируются от низкого до критического, а также на модификаторы рейтинга. Это такие случаи, когда у вашей уязвимости может быть снижен уровень опасности. Это очень неприятный кейс, и мне даже удалось один раз с этим столкнуться: уязвимость, которая изначально была оценена как высокая, была понижена до средней.
Какой может поступить ответ?
Тут всего два варианта:
-
Уязвимость подтвердили, присвоили рейтинг от низкого до критического.
Спустя некоторое время баг исправят, о чем вас уведомят. Для багов с высоким рейтингом это время может занимать от месяца до трех, для средненьких можно ждать полгода, а то и больше. В течение 90 дней назначают вознаграждение. Иногда это случается до того, как уязвимость будет исправлена.
В конце — присвоение уязвимости CVE ID, публикация в бюллетене безопасности Android, и выражение благодарности (acknowledgements) от Android Security Team.
Обратите внимание, что в бюллетенях за последний год вы не встретите уязвимостей с рейтингом ниже высокого, то есть только критические и высокие. Суть в том, что в мае 2023 года были изменены правила Android VRP, согласно которым теперь за средние баги CVE присваиваться не будут. Плюс сама матрица иногда обновляется, и некоторые виды импакта могут подлежать переоценке.
-
Уязвимость не подтвердили.
Вердиктов тут несколько. Я сталкивалась со следующими: 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 конфигурации устройства.
Как попасть в топ рейтинга?
Достаточно сложно, но возможно. Нужно успешно сдать как можно больше классных баг, которые продвинут вас вперед. Помните — конкуренция высока! Очень много крутых ребят багхантят, многие — по несколько лет. А на старте всегда нелегко.
Рейтинг в целом очень динамичная штука — всегда меняется. Нашел новые уязвимости? Значит, продвинешься наверх. А если не искал, был занят чем-то другим, то начинаешь потихоньку скатываться, кто-то выходит вперед. Это нормально.
Мне кажется, что без выработанной стратегии постоянно в топе держаться невозможно. У вас должен быть собственный подход к поиску уязвимостей, и он должен работать как часы. Это уже такой уровень, когда багхантинг становится повседневной работой. В противном случае положение в рейтинге будет нестабильным.
Что важно для успешного поиска уязвимостей?
Я думаю, ключевым моментом является умение быстро адаптироваться и не бояться открывать для себя новое. Вдохновляйтесь другими исследователями, анализируйте и читайте их работы, развивайте собственные идеи. Ведите заметки по ходу ваших поисков — к ним всегда можно будет вернуться и свежим взглядом увидеть то, что раньше оставалось незамеченным. Способность учиться новому, совершенствовать свои навыки и продолжать двигаться вперед, несмотря на неудачи, — залог успеха в багхантинге.
ссылка на оригинал статьи https://habr.com/ru/articles/847740/
Добавить комментарий