В мире мобильной безопасности существует устойчивое заблуждение: если приложение при запуске проверило, есть ли на устройстве root или джейлбрейк, значит, можно выдохнуть. Но это только видимость безопасности — создается иллюзия защиты, но профессионалы знают, что хакеры обходят примитивные проверки за минуты, используя инструменты, которые сегодня доступны буквально каждому.
Кто в группе риска
Взгляд со стороны злоумышленника всегда помогает понять, почему одни приложения атакуют постоянно, а другие обходят стороной. Хакеры идут за деньгами и вниманием государства. Основная масса атак приходится на финансовый сектор — банковские приложения остаются наиболее привлекательной целью. Следом идут приложения госорганов и «Госуслуги»: здесь цель — шпионаж и персональные данные. Замыкают список маркетплейсы и ритейл. Это обусловлено не только «ликвидностью» целей, но и темпом разработки: чем чаще обновляется приложение и чем больше в нем функций, тем выше вероятность человеческой ошибки в коде, которую и эксплуатируют хакеры.
Однако было бы ошибкой считать, что приложения вне этих категорий никому неинтересны. Внутренние корпоративные приложения — обходчики, проводники, CRM-системы для сотрудников банков — сами по себе не слишком популярны, зато дают прямой доступ к критически важной части инфраструктуры. Такие цели для атакующих особенно интересны именно потому, что их защищают хуже.
Чтобы понять, как именно используется root-доступ, важно посмотреть на ситуацию глазами злоумышленника. Root — это важный инструмент: он позволяет свободно анализировать приложение, перехватывать его работу и вносить изменения в код и поведение. С его помощью хакер ищет уязвимости, изучает взаимодействие с API, создает модифицированные версии приложения или вредоносные клоны.
Почему через такие сценарии реализуются основные типы атак? Во-первых, финансовая выгода. Root-доступ позволяет модифицировать клиентское приложение (например, отключать проверки или менять параметры операций), проксировать трафик и работать с API от имени пользователя, а также создавать вредоносные клоны. Все это может приводить к хищению средств или злоупотреблению функциональностью сервиса. API часто защищают хуже, чем классические веб-приложения, и вероятность найти там серьезную уязвимость выше.
Во-вторых, доступ к конфиденциальной информации. Внутренние приложения сотрудников — это точка входа в инфраструктуру компании. Если злоумышленник действует осторожно и только читает хранимые данные, шансы заметить такую утечку стремятся к нулю.
В-третьих, манипуляция клиентской частью. В играх, ритейле и соцсетях злоумышленнику часто не нужен доступ к серверу, достаточно контролировать поведение приложения на устройстве. Это позволяет использовать ботов, накручивать показатели или обходить ограничения.
В таких сценариях root-детекция играет важную роль — но не как универсальный барьер от взлома, а как один из сигналов о небезопасной среде исполнения.
Как хакеры «снимают замок»: типовой сценарий атаки
Есть несколько способов взлома. Например, разведка — при ней хакер запускает приложение и смотрит логи, трафик, подключает отладчик (Frida/Xposed). Он ищет момент, когда приложение «падает» или выдает сообщение о несовместимости. На этом этапе собирается информация о том, какие проверки сработали.
Другой вариант — перехват управления. Самая популярная техника — хукинг (hooking). Хакер перехватывает вызов функции checkRoot(), заставляет ее всегда возвращать «все чисто» и идет дальше. Фреймворк Frida позволяет сделать это одной строкой JavaScript — без пересборки приложения.
Еще один способ — имитация. Вместо перехвата хакер может просто скопировать приложение в изолированную среду (VirtualApp, Island) и подменить системные вызовы. Это позволяет эмулировать «чистое» устройство, пока приложение работает в виртуальном контейнере.
Самый опасный сценарий — патч (изменение кода). Если скрыть файлы или перехватить функцию не получается, хакер вскрывает код приложения, вшивает заплатку и пересобирает его заново. Приложение запускается, выглядит так же, работает так же — но слепой зоны, куда смотрела защита, уже нет.
Заплатка при этом может быть крайне простой: например, подменять сервер, с которым должно взаимодействовать приложение, на прокси злоумышленника. Трафик перенаправляется через атакующего, который сохраняет логины и пароли, подменяет реквизиты и суммы в транзакциях. Заметить, что что-то идет не так, почти невозможно — в этом и состоит опасность качественных клонов: атакующему достаточно добавить минимальный вредоносный код, а не разрабатывать похожее приложение с нуля.
Самые популярные, но уже бесполезные методы защиты
Многие разработчики до сих пор используют подходы к root-детекции, которые кочуют из проекта в проект. Проблема в том, что они работали несколько лет назад, а сегодня хакеры обходят их автоматически.
Например, разработчики могут писать детекты самостоятельно без достаточной экспертизы. Важно постоянно находиться в инфополе и знать про современный инструментарий атакующих. Человек вне контекста сделает слабую проверку, которую сломают публично доступные автоматические инструменты — те, которыми пользуются даже школьники.
Использовать Open Source-решения сегодня — тоже не лучшая идея. Это может быть временной мерой для стартапа, но не путь серьезной организации с тысячами клиентов. В Open Source встречаются неплохие реализации, но все они на порядок проще обходятся, чем коммерческие решения.
Если вы думаете, что экспертизу способен заменить ИИ и можно «навайбкодить защиту» — это большое заблуждение. ИИ обучен на небезопасном большинстве, поэтому и выдаст дырявую реализацию защиты. Например, пришьет к приложению давно устаревшую библиотеку RootBeer — формально защита есть, но она давно не является препятствием даже для простых инструментов анализа. Вайбкодинг будет полезен только в руках эксперта.
Само понятие root-детекции при этом не устарело, но инструментарий хакеров настолько усовершенствовался, что полагаться только на один тип проверок бесполезно. В современных протекторах применяется совокупность десятков различных проверок, каждая из которых, например проверка root, реализована множеством способов.
Как построить лабиринт для хакера
Главный враг атакующего — время. Если код превращен в непроходимый лабиринт, злоумышленник, скорее всего, уйдет к более легкой цели. В действительности работают несколько направлений.
Применять одновременно защиту от статического и динамического анализа. Недостаточно просто накрыть код обфускатором или добавить всевозможные детекты во время запуска (RASP, runtime application self-protection). Хакер не будет выбирать только один путь атаки, поэтому и защищать нужно сразу с двух сторон.
Не делать ставку только на одну технику. Некоторые считают, что достаточно реализовать только хорошее шифрование кода или только детальный детект root-прав — и злоумышленник не преодолеет защиту. На практике атакующий будет пробовать множество обходных путей. Правильный подход — внедрять как можно больше различных техник, чтобы их совокупность давала синергетический эффект: разные техники не просто закрывают дыры, но и защищают друг друга по принципу 1+1>2.
Не экономить на старте. В безопасной разработке есть принцип shift left: чем раньше обнаружена уязвимость, тем дешевле ее исправление. Но на практике самые «ранние» практики — самые дорогие. Для начинающей команды разумнее двигаться «справа»: поставить WAF и протектор, а уже потом по мере зрелости идти влево, получая максимальный результат на всем пути.
Увеличивать стоимость ручного анализа. Самый дорогой и долгий этап для хакера — ручная работа: обход анти-реверса, изготовление клонов, поиск уязвимостей, разработка бота. Автоматизировать можно очень многое, особенно с помощью ИИ. Поэтому выгодно именно этот этап делать максимально дорогим: увеличивая стоимость реверс-инжиниринга, мы увеличиваем стоимость любой атаки — не только некоторых. Наличие даже базовой проверки увеличивает трудозатраты атакующего. Но коммерческий протектор может увеличить их буквально на порядки — в десятки и сотни раз — в то время как примитивная защита автоматически ломается инструментами, доступными каждому.
Внедрять защиту на стороне клиента. С точки зрения корпоративной инфраструктуры взлом через скомпрометированное приложение на устройстве сотрудника выглядит как обычное поведение — то же устройство, то же приложение, только аномальная активность может насторожить службу безопасности. Поэтому важно внедрять защиту непосредственно на устройство и в сами приложения.
Как понять, что ваше приложение атакуют
Рекомендация здесь стандартная: любые аномалии — повод что-то заподозрить. Приложение начало тормозить, открываться или закрываться самостоятельно, появились проблемы с соединением. Обнаружились подозрительные транзакции или новые сессии с незнакомых устройств — это можно проверить в настройках социальных сетей и мессенджеров. Также стоит обращать внимание на специальные ссылки в мессенджерах: приложения умеют их обрабатывать, и такая ссылка может быть способом атаковать приложение.
За более чем десять лет в анализе защищенности мобильных приложений наши эксперты проверили вручную более 2000 приложений. За все это время только один раз встретилось по-настоящему хорошо защищенное приложение. Хотя оно не помешало найти критическую уязвимость, в полной мере преодолеть его защиту за время, отведенное на проект, не удалось. Все остальные приложения всегда поддавались анализу. Подавляющее большинство либо никак не были защищены, либо обход защиты происходил с использованием публично доступных автоматических инструментов. Лишь изредка возникала необходимость прибегать к ручному анализу.
Вывод один — root-детекция работает только тогда, когда реализована правильно и в совокупности с другими техниками. Приложение, которое полагается на единственную проверку, только задержит хакера, но не сможет его остановить.
