Привет, Хабр! На связи Николай Анисеня из отдела перспективных технологий Positive Technologies. Так вышло, что в компании я уже много лет занимаюсь безопасностью мобильных приложений, исследую тренды этого направления и, как и все, наверно, специалисты в этой области, ломаю голову: как сделать мобильное приложение более защищенным. Этой публикацией я открываю цикл статей на тему безопасности мобильных приложений и устройств, корень которой (начнем со спойлера!) — в анализе кода. В этой статье расскажу об угрозах мобильных приложений, сценариях атак на них и о главном парадоксе в их разработке. Интересно? Тогда погнали!

В теме безопасности мобильных приложений присутствуют разнонаправленные тренды. Что-то становится более защищенным благодаря улучшению фреймворков, операционных систем и практик безопасной разработки, а где-то, наоборот, появляются новые возможности для атак из-за новой функциональности мобильных приложений. Все как в том меме: «Исправлены баги, добавлены новые». Примером может служить уязвимость, приводящая к атаке типа Tapjacking, о которой впервые заговорили применительно к Android 2.3. На устройствах с Android 4 эта проблема была фактически решена, однако с выходом Android 6 вышел и «наследник» этой уязвимости, позволяющий произвести атаку Cloak and Dagger.

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

Этот факт также находит отражение в данных OWASP Mobile Top 10. Но в этом рейтинге можно заметить и весьма однозначные тренды, если анализировать долгосрочный период. Например, давайте рассмотрим ситуацию с защитой кода. За 10 лет существования OWASP Mobile Top 10 эта проблема не просто всегда отмечалась в рейтинге, но и стабильно поднималась вверх списка — с 10-го места в 2014-м на 7-е в 2024-м. Формулировали проблему каждый раз по-разному: возможность реверс-инжиниринга, тамперинга, недостаточная бинарная защита, защита кода.

Несмотря на растущую угрозу, защита кода все еще остается крайне непопулярной мерой защиты мобильных приложений, согласно исследованию, опубликованному на arXiv.org. За период с 2016 по 2023 год в среднем 56% приложений применяли техники обфускации, однако только 59% из них, или ⅓ от изначальной выборки, совмещали все три описанные в статье техники обфускации, при этом качество защиты не исследовалось. Не удалось найти похожих исследований для техник RASP — runtime application self-protection — самозащиты приложений во время запуска.

По нашей статистике, основанной на результатах анализа защищенности приложений за 2024 год, проводимых для наших клиентов, а также исходя из опыта личного участия наших экспертов в программах bug bounty, доля применения совокупности техник обфускации и RASP составляет только 8%.

🥁 Более чем за 10 лет анализа защищенности нам встретилось только одно приложение, защиту которого не удалось преодолеть за выделенное на проект время. Однако это не помешало нам обнаружить критическую уязвимость с помощью реверс-инжиниринга: в одном месте защита не применялась, и именно через него мы получили исполнение кода на сервере — уязвимость в10 баллов по шкале CVSS!

И вроде это неудивительно: реверс-инжиниринг нельзя сделать невозможным, а атакующий всегда может делать с клиентским приложением все, что ему вздумается: модифицировать, читать память, использовать фрагменты кода на свое усмотрение.

Почему так происходит?

Код клиентского приложения (бинарный, а иногда и исходный) всегда доступен атакующему, сколь сильно бы он ни был запутан и искажен. В случае, если код зашифрованный, он обязательно будет расшифрован для корректной работы приложения. Среда исполнения — смартфон — полностью контролируется злоумышленником. Можно собрать стенд, неотличимый для приложения от доверенного окружения, но дающий атакующему максимум привилегий: «экзотическое» железо, кастомные сборки ОС, аппаратные хаки и так далее — вопрос только в цене: денежной, временной и экспертной.

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

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

Сценарии атак на мобильные приложения

Для атакующего реверс-инжиниринг в широком смысле — это инструмент изучения внутреннего устройства приложения для достижения одной из целей:

🔻 поиск и эксплуатации уязвимостей,

🔻 создание клонов и модификаций,

🔻 изучение внутреннего устройства приложения в целях конкуренции,

🔻 использование части кода или компонентов приложения без согласия правообладателя,

🔻 кража контента,

🔻 автоматизация и разработка альтернативных клиентов.

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

Реверс-инжиниринг конкурентов

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

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

Кража ассетов

Также в геймдев распространено воровство ассетов. Неплохо защищаться в этом случае можно юридическими методами, так как доказать воровство большинства компонентов гораздо проще (по сравнению с формулами из предыдущего примера). Но не все ассеты могут быть защищены юридически. Примером таких уязвимых компонентов могут стать файлы локальных ML-моделей, хранимые в бандлах приложений. В исследовании на arXiv.org за 2021 год сказано, что 41% приложений никак не защищают свои модели, а ⅔ приложений допускают их тривиальное извлечение из бандла. Выгода атакующего здесь аналогичная: экономия ресурсов на обучение модели. Жертва в этом случае теряет конкурентное преимущество, на разработку которого уже потрачены ресурсы.

Воровство контента

Но воруют не только идеи и технологии. Злоумышленники также заинтересованы в пиратстве контента: фильмов, музыки, книг и др. Основным средством борьбы здесь является блокирование сайтов, распространяющих пиратский контент. Однако использование методов DRM (digital rights management, технологии для защиты копирайта) совместно с протекторами мобильных приложений может сильно увеличить стоимость извлечения контента.

Автоматизация и альтернативные клиенты

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

Автоматизация взаимодействия с API сервера мобильного приложения также может нести риски для бизнеса. Это разработка торговых или игровых ботов, сбор рыночных данных, данных о пользователях. Использование ботов — в торговле, играх, еще где-то — может привести к тому, что легитимные пользователи приложения будут в заведомо подвержены риску. В случае игр и трейдинга — это нечестная конкуренция, в мессенджерах и соцсетях — это спам-рассылки, мошенничество, накрутки. Другим ярким примером такого проигрыша могут служить боты для записи в визовые центры. Забронировать слот на сайте, как это предполагается системой, почти нереально, приходится выкупать забронированные ботами места.

Создание клонов и модификаций приложений

Мало кому хочется встречаться с сотрудником банка, чтобы установить мобильное приложение по «проводу», если оно было удалено из магазина приложений. Некоторых пользователей это толкает на самостоятельный поиск приложений в альтернативных источниках. Приложения, загруженные таким способом, не заслуживают доверия. Злоумышленники с радостью используют подобные поводы для распространения вредоносов среди доверчивых пользователей.

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

Обнаружен вредоносный клон, полученный с помощью перепаковки легитимного Android-приложения ChatGPT

EvilBamboo атакует мобильные устройства в ходе многолетней кампании

Семейство шпионских Android-приложений, переделанных из легитимных с помощью добавления бэкдора

Похожим образом дело обстоит с модификациями приложений без цели навредить пользователю. Удаление или перенаправление рекламы, разблокировка платных функций — все это легко дается злоумышленникам, если в приложении не применяются технологии защиты от модификации и перепаковки. Согласно этому исследованию, 21% модов (модифицированных приложений) перенаправляют рекламные доходы оригинального приложения.

Поиск и эксплуатация уязвимостей

Реверс-инжиниринг, перепаковка, статический и динамический анализ приложения, использование автоматических сканеров — все это этапы поиска уязвимостей в мобильном приложении, причем как в клиентской, так и в серверной части. По нашему опыту, в большинстве мобильных приложений дорога к уязвимостям — это прямая без препятствий. В редких случаях можно встретить незначительные «стены», преграждающие путь атакующему, но очень часто их можно обойти тривиальными способами. И хотя применение сложной комбинации продвинутых техник защиты может быть очень эффективным, встречается такая защита крайне редко.

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

Технологии RASP — дамп памяти, тамперинг и динамическая инструментация (Frida), применение динамических сканеров (DAST) — препятствуют динамическому анализу. В случае их использования злоумышленник вынужден потратить огромное количество ресурсов на создание кастомного тестового окружения, перепаковку приложения, чтобы просто подступиться к поиску уязвимостей.

Зона риска: какие приложения наиболее уязвимы?

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

Подавляющее большинство современных приложений — это сложные системы с большой поверхностью атаки. Даже простые заметки в телефоне уже хранят ваши секреты, а ведь большинство приложений намного сложнее. К примеру, банковские суперприложения: с их помощью уже давно можно делать не только переводы, но и покупать билеты на самолет и в театр, заправлять машину, заказывать продукты и многое-многое другое.

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

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

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