GitHub рассказала о результатах применения искусственного интеллекта и больших языковых моделей (LLM) для автоматизации поиска уязвимостей в Android‑приложениях с помощью GitHub Security Lab Taskflow Agent. Этот фреймворк позволяет исследователям описывать цепочки задач (taskflows) для ИИ, автоматизировать аудит кода и делиться эффективными подсказками и сценариями.
В компании создали специальные сценарии аудита для мобильных приложений и с их помощью уже сообщили 24 уязвимости в Android‑приложениях, больше 20 из которых были найдены с применением этих taskflow. В качестве примеров GitHub разобрала критические баги в популярных приложениях OsmAnd и Wikipedia для Android.
Taskflow‑подход строится на том, что LLM пошагово выполняет заранее описанные действия, а не получает одну большую задачу. Это повышает шанс обнаружить сложные логические проблемы в коде, которые классические сканеры и единичные запросы к модели пропускают.
Как устроены мобильные taskflow GitHub Security Lab
Команда GitHub доработала существующие сценарии аудита, чтобы сфокусировать их на типичных проблемах мобильных приложений. Для этого были добавлены и изменены несколько ключевых taskflow:
- gather_mobile_entry_point_info.yaml — собирает точки входа, через которые в код может попасть данные, контролируемые атакующим, и делит их на мобильные и немобильные. Это позволяет анализировать репозитории со смешанными типами приложений и правильно оценивать атакующую поверхность.
- classify_application_local.yaml — содержит список популярных классов уязвимостей и просит LLM учитывать их для каждой точки входа и компонента. Для мобильных сценариев в список добавлены малоизвестные, но важные типы проблем, например, ошибки в обработке Android intents.
Если taskflow находит intent‑точку входа, сценарий подсказывает модели перечень частых багов для такой ситуации, например confused deputy или небезопасные широковещательные сообщения. Это помогает модели связать компоненты между собой и удерживать в поле зрения общую картину угроз.
GitHub отмечает, что наибольший эффект достигается при комбинировании строгих и более широких подсказок на нескольких прогонах. Строгие запросы снижают риск пропустить очевидные уязвимости, а широкие позволяют ИИ находить нетривиальные логические проблемы.
Примеры найденных уязвимостей в Android‑приложениях
OsmAnd: слежка за местоположением через изменённые настройки карт
OsmAnd — популярное навигационное приложение на базе OpenStreetMap с более чем 10 млн установок в Google Play. Taskflow обнаружил экспортируемую активность MapActivity, которая открывает файлы настроек и обрабатывает deeplink‑ссылки.
MapActivity принимает extras‑параметры intent (например, settings_version, silent_import, replace, export_type_list_key) и ожидает, что они придут из AIDL‑сервиса. Однако эти настройки передавались через intent extras, а не через внутренний канал, поэтому любое приложение могло отправить в экспортируемую активность произвольные extras.
Функция handleOsmAndSettingsImport позволяла импортировать настройки, включая параметры карт. Злоумышленник мог заменить URL шаблон для тайлов карты и подставить свой сервер. Тогда приложение запрашивало бы изображения тайлов по адресу вида:
https://attacker-server/tiles/{x}/{y}
В ответ на запросы сервер выдавал бы корректные тайлы OpenStreetMap, поэтому пользователь не замечал подмену. При этом атакующий получал список координат всех тайлов, которые загружались в приложении, то есть точные данные о перемещениях устройства. Аналогичным образом можно было перехватывать данные о начале и конце маршрутов, не имея никаких разрешений и не показывая пользователю изменений в интерфейсе.
Wikipedia для Android: подмена страниц и кража cookie
Официальное приложение Wikipedia для Android регистрирует deeplink‑схему wikipedia://, чтобы открывать статьи в приложении. Например, ссылка может выглядеть так: wikipedia://wikipedia.org/wiki/PoC. Taskflow обнаружил логическую ошибку в разборе имени хоста, из‑за чего приложение принимало и не‑Wikipedia URL‑адреса.
Это позволяло перенаправить пользователя на произвольный сайт через deeplink и создать иллюзию, что он находится на странице Wikipedia. Дополнительно атакующий получал возможность выполнять произвольный JavaScript в WebView приложения, что давало доступ к окружению, которое обычно считается защищённым.
Отдельный фрагмент кода отвечал за решение, какие страницы должны содержать cookie от домена wikipedia.org. Ошибка в этой логике в сочетании с подменой страниц позволяла утекать долгоживущие cookie. В результате комбинирования двух уязвимостей становилась возможной полная компрометация аккаунта пользователя.
Преимущества и ограничения использования LLM в безопасности
GitHub отмечает, что большие языковые модели хорошо подходят для поиска проблем в логике и работе с кодом, включая трудновоспроизводимые сценарии. Однако на практике выявились два ключевых недостатка:
- Избыточные и малозначимые находки. Модель часто возвращает уязвимости с низким влиянием или сценарии, которые почти невозможно воспроизвести в реальных условиях. Даже при явной просьбе игнорировать малозначимые баги LLM продолжает их находить, поэтому каждую находку всё равно должен просматривать специалист по безопасности.
- Ошибочная оценка критичности. Часто модели завышают или занижают серьёзность проблемы, не учитывая смягчающие факторы. Например, при обходе путей (path traversal), ограниченном внешним хранилищем, реальное влияние будет низким, но модель этого не видит без явного шага по созданию proof of concept.
Авторы описывают типичный сценарий: LLM предполагает, что данные из внешнего хранилища могут изменить состояние приложения, хотя в реальности данные из внутреннего хранилища имеют приоритет и полностью их перекрывают. В таких случаях уязвимости фактически нет, но модель отмечает её как критичную.
Часть проблем компенсируется ростом контекстного окна и улучшением рассуждений моделей, но в текущем виде GitHub считает, что проверка человеком или запуск PoC через отладчик остаются необходимыми шагами для снижения числа ложноположительных срабатываний.
Глубина понимания API и языков программирования
По наблюдениям GitHub, LLM уверенно работает с типовыми паттернами и API, важными для безопасности, даже без доступа к исходникам языков. Авторы приводят пример с Go: функция path.Clean заметно менее безопасна, чем filepath.Clean для Windows‑окружений и часто становится причиной уязвимостей. Модели в большинстве случаев корректно отражали специфические особенности подобных вызовов.
Большинство proof of concept‑примеров, которые LLM создавала на основе отчёта об уязвимости, требовали минимальных доработок со стороны исследователей. Это, по мнению GitHub, показывает, что модели уже накопили значительный опыт на базе прошлых эксплойтов и реализаций API.
Как запустить GitHub Security Lab Taskflow Agent
Taskflow‑агент распространяется как open source и его можно запустить локально для собственного проекта. Для использования подсказок требуется лицензия GitHub Copilot, так как сценарии выполняют запросы к премиальным моделям и могут генерировать множество инструментальных вызовов, расходуя значительное число токенов.
На репозитории среднего размера полный прогон может занять от одного до двух часов. По завершении открывается просмотрщик SQLite, в котором нужно открыть таблицу audit_results и искать строки с отметкой в столбце has_vulnerability, указывающей на потенциальную уязвимость.
GitHub подчёркивает, что производительность и цена запуска зависят от скорости и стоимости используемой модели. Чем больше запросов нужно для генерации PoC и перепроверки влияния, тем больше времени и ресурсов займёт аудит.
Новые сценарии: fuzzing и DevSecOps
В GitHub представили и новый fuzzing‑taskflow, построенный на том же AI‑фреймворке GitHub Security Lab Taskflow Agent. В отдельном материале компания объяснила, как с его помощью запускать автоматизированное тестирование, чтобы находить ошибки за пределами обычных сценариев использования.
Кроме того, GitHub делится рекомендациями по DevSecOps и использованию ИИ и автоматизации для решения ключевых проблем безопасности в цепочке разработки. Авторы подчёркивают, что внедрение нескольких бесплатных защитных настроек не сделает проект полностью защищённым, но «закроет лёгкие входы» и заметно усложнит атаку.
Роль ИИ в безопасности open source
GitHub считает ИИ одним из наиболее перспективных инструментов для повышения защиты open source‑проектов во всех типах приложений — веб, мобильных и настольных. По словам компании, безопасность должна быть приоритетом для всех мейнтейнеров, а ИИ станет ключевым помощником как в разработке, так и в защите кода.
Проект seclab-taskflow-agent открыт для вкладов. GitHub призывает исследователей и разработчиков добавлять новые подсказки, инструменты и механизмы поиска уязвимостей с использованием ИИ, а также запускать существующие taskflow на своих приложениях, чтобы сделать первый шаг к AI‑ассистированной безопасности.
Источник: блог GitHub.
