Мобильные устройства — часть повседневной жизни миллиардов людей. Смартфоны не только вытеснили компьютеры в сегменте общения и онлайн‑ритейла, но и стали главными устройствами для доступа к госуслугам и банковским счетам. Согласно результатам исследований российской компании «НАФИ», 74% россиян предпочитают проводить финансовые операции через мобильные приложения.

Из‑за экономических санкций и удаления приложений из App Store и Google Play российские организации были вынуждены отойти от привычных всем репозиториев, предоставив злоумышленникам больше возможностей для обмана пользователей: загрузка и обновление приложений по внешним ссылкам даже для банковских клиентов стали привычными. Популярен также сценарий, когда пользователи ищут более удобную альтернативу известным приложениям — например, с возможностью наслаждаться видеоконтентом без рекламы или бесплатно слушать музыку на стриминговых площадках, что также вызывает необходимость качать приложения из сторонних источников.

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

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

Трендовые уязвимости

Мы разберем несколько трендовых уязвимостей. Они многим знакомы, для их исправления не всегда требуются большие финансовые и трудовые затраты. Однако количество этих недостатков составило почти половину от всех уязвимостей, найденных экспертами Positive Technologies в мобильных приложениях за два года. При этом эксплуатация представленных проблем может иметь серьезные последствия для компаний — разработчиков ПО, особенно с ростом штрафов за утечку персональных данных (для ИП и организаций — до 15 млн руб.).

Разбор уязвимостей для нас неразрывно связан с тремя вещами: международным стандартом OWASP Mobile Top 10, классификацией MASWE и сборником атак на мобильные приложения, сформированным нашими специалистами.

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

Небезопасная отправка неявных межпроцессных сообщений

• M8: некорректная конфигурация безопасности

• PT‑MOB-028: небезопасная отправка неявных межпроцессных сообщений

• Операционная система: Android

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

Межпроцессное взаимодействие в Android осуществляется при помощи специальных объектов — намерений (intent). Намерение связывает разные компоненты (ImageView, Button, Activity, WebView) и позволяет им общаться. Параметры обработчиков намерений задаются либо в основном файле манифеста (AndroidManifest.xml), либо в коде приложения. Намерения делятся на явные (explicit intent, один компонент напрямую связывается с другим) и неявные (implicit intent, для компонента А не задан компонент Б, а только описано действие). Использование неявных намерений создает для злоумышленника возможность скомпрометировать данные, содержащиеся в них.

Рассмотрим несколько сценариев эксплуатации подобной уязвимости и дадим рекомендации по защите.

Несанкционированная транзакция в мобильном приложении онлайн-магазина

Разработчики онлайн‑магазина GondorRetail не предусмотрели проверку подлинности приложений, используемых для оплаты. Пользователь может выбрать оплату через свой банк, GondorRetail обещает его перенаправить, но на устройстве нет легитимного приложения банка. Зато присутствует вредоносная программа, которая перехватывает вызов и пытается провести несанкционированную транзакцию.

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

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

Для обнаружения уязвимости разработчикам мобильных приложений рекомендуется применять методологии SAST и DAST, для устранения — один из следующих вариантов:

• реализовать проверку подписи приложений, вызываемых для оплаты (или других целей);

• использовать механизм Android App Links.

Рекомендуем разработчикам также обратить внимание на архитектуру single activity и применять ее в своих проектах. Это позволит уменьшить поверхность атаки.

Компания Google представила в Android 15 механизм Google Play Protect, который должен проверять приложения не в Google Play, а непосредственно на устройстве. Если эта функциональность будет успешно развиваться, есть шанс увидеть уменьшение доли атак, требующих установки вредоносного ПО из Google Play. В таком случае злоумышленники будут искать альтернативные способы загрузки вредоносных программ на устройства пользователей.

Для отечественного RuStore разработан механизм проверки установленных приложений на наличие вредоносного кода, а помогают маркету специалисты из «Лаборатории Касперского».

Неявное намерение как способ кражи учетных данных

В уже известном нам GondorRetail, когда пользователь выходит из своего профиля, отправляется неявное намерение для запуска компонента MainActivity. Вместо указания конкретного приложения‑получателя (самого GondorRetail) передается только запрашиваемое действие. В результате операционная система определяет подходящие компоненты и предлагает пользователю выбрать нужный.

Отправка неявного намерения для старта MainActivity

Intent intent = new Intent("GondorRetail.MAIN_ACTIVITY");
intent.setFlags(26*****24);
this$0.f6560a.mo13910b();
this$0.f6565a.startActivity(intent);

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

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

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

Похожие уязвимости в известных компонентах и приложениях:

• CVE-2024–20 810 (PT-2024–18 717). Связана с перехватом неявных намерений компонента Smart Suggestions в смартфоне Samsung и позволяет локальным приложениям получать конфиденциальную информацию.

• CVE-2024–20 822 (PT-2024–18 729). Связана с компонентом AccountActivity магазина Galaxy Store и позволяет злоумышленникам перехватить неявные намерения и получить доступ к конфиденциальной информации.

Небезопасная обработка входных данных

• M4: недостаточная проверка ввода‑вывода

• PT‑MOB-053: небезопасная обработка входных данных

• Операционная система: Android, iOS

Недостаточная фильтрация данных, вводимых пользователем, нередко становится причиной появления уязвимостей: например, связанных с внедрением SQL‑кода, хранимыми XSS‑атаками, десериализацией недоверенных данных. Мобильные клиенты — тоже не исключение. Довольно часто описанные уязвимости приводят к выполнению кода в браузере пользователя, СУБД веб‑приложения или ОС сервера, а также к несанкционированному доступу к данным.

Далее мы рассмотрим ряд сценариев эксплуатации уязвимости.

Общение с технической поддержкой может пойти не по плану

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

На устройстве пользователя обнаружено вредоносное приложение MordorApk. В его файле AndroidManifest.xml определена активность для обработки файлов, а также настроен Intent‑Filter, который определяет соответствующие запросы от других приложений. У злоумышленника все схвачено: на неявное намерение ответит его вредоносное ПО.

Если пользователь выберет зловещий MordorApk, будет выполнена полезная нагрузка из активности прикрепления файлов — и файл из атакуемого приложения отправится на сервер злоумышленника. В чем ценность хранимых на устройстве файлов? Например, нарушитель может получить доступ к файлу с сессией session_storage_prefs.xml и впоследствии скомпрометировать личный кабинет пользователя.

Еще примеры небезопасной обработки входных данных:

• В приложении для путешествий BagginsPass есть активность, которая меняет его состояние (state). При помощи вызова этого состояния можно обойти проверку ПИН‑кода и получить доступ к личному кабинету пользователя.

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

Для устранения уязвимости следует запретить прикреплять к сообщению файлы из внутренней директории приложения /data/.../AppStorage.

Подделка внутренних ссылок

Веб‑адрес, перенаправляющий пользователя на раздел (так называемый deep link) мобильного приложения ресторана MoriaDinner, реализован небезопасно. С помощью специально подготовленного объекта SKIPPED.sdk.internal.service.RemoteMessage можно влиять на содержимое фрагмента PushInfoFragment, отвечающего за отображение уведомлений.

В процедуре обработки deep link из объекта Bundle, информация о котором отправляется в намерение можно извлечь сериализованный объект RemoteMessage с ассоциативным массивом Data. Мобильное приложение MoriaDinner по ключу extra ожидает данные в формате JSON, которые конвертирует в объект класса PushInfo. Это дает возможность злоумышленнику подготовить полезную нагрузку, подменяющую содержимое любых доступных полей в классе PushInfo. Так можно провести фишинговую атаку, например запросить ввод логина и пароля и затем получить доступ к личному кабинету с конфиденциальной информацией (именем, номером телефона, адресом доставки еды и т. п.).

Разработчикам нужно валидировать содержание deep link или использовать иные механизмы для этой функциональности, например push‑уведомления.

Похожие уязвимости в известных компонентах и приложениях:

• CVE-2023–21 431 (PT-2023–18 199). Небезопасная обработка входных данных в Bixby Vision до версии 3.7.70.17 позволяет злоумышленнику получить доступ к ним.

• CVE-2023–21 446 (PT-2023–18 213). Уязвимость MyFiles в ряде версий Android R, S и T позволяет локальному злоумышленнику получить доступ к данным.

• CVE-2023–21 607 (PT-2023–1116). Ряд версий приложения Adobe Acrobat Reader подвержен уязвимости небезопасной обработки входных данных. Это может привести к выполнению произвольного кода от лица пользователя.

• Некорректная проверка deep link во Flickr для Android приводила к зависанию приложения и устройства. Уязвимость описана в отчете #1 157 795 на HackerOne.

• Известный многим Snapchat для Android содержит ряд deep link, предназначенных для запуска функций. Злоумышленник может создать ссылку, нажав на которую жертва инициирует видеозвонок с ним. Уязвимость описана в отчете #2 139 260 на HackerOne.

Кроме того, 27 января компания Apple выпустила новую версию iOS — 18.3, в которой было исправлено более 20 найденных ранее уязвимостей. Многие из них связаны с небезопасной обработкой входных данных.

Открытие недоверенных URL во встроенном браузере

• M8: некорректная конфигурация безопасности

• PT‑MOB-004: выход за пределы разрешенных доменов

• Операционная система: Android

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

В приложении FrodoProfile на платформе Android используется компонент WebView. Исследовав файл манифеста AndroidManifest.xml, эксперты обнаружили, что FrodoProfile обрабатывает deep link вида appname://web?url=https://appname.ru/path/?appname_token={REDACTED_TOKEN}. При переходе в WebView открывается произвольный адрес, указанный в параметре url, без проверки на принадлежность к легитимным доменам. Это позволяет проводить фишинговые атаки на пользователей приложения.

Компонент приложения NazgulVault обрабатывает входящие HTTPS‑ссылки, передаваемые из сторонних приложений. При этом ссылка открывается без тела запроса, но с использованием cookie‑файлов, соответствующих домену разработчиков приложения. Злоумышленник может воспользоваться этой особенностью, отправив произвольный запрос на поддомен разработчиков с cookie‑файлом жертвы, что позволит ему добавлять товары в избранное от имени пользователя.

Что можно сделать: при переходе по URL‑адресам фильтровать значения host и authority по белому списку.

Похожие уязвимости в известных компонентах и приложениях:

• CVE-2024–49 419 (PT-2024–33 529). Недостаточная проверка подлинности URL‑адресов в приложении платформы GamingHub до версии 6.1.03.4 в Корее и 7.1.02.4 в мире позволяет злоумышленникам загружать произвольный URL‑адрес в компонент WebView.

• CVE-2023–41 898 (PT-2023–28 154). Помощник Home Assistant Companion для Android до версии 2023.8.2 уязвим к загрузке произвольных URL‑адресов в компонент WebView. Это позволяет осуществлять всевозможные атаки, в том числе для выполнения произвольного кода на языке JavaScript и кражи учетных данных.

• Приложение Basecamp для Android содержит WebView, в котором загруженные URL‑адреса не очищаются должным образом. Поскольку функциональность представления расширяется через интерфейсы JavaScript, можно внедрить произвольный код на этом языке, который будет выполняться компонентом WebView. Уязвимость описана в отчете #1 343 300 на HackerOne.

Некорректное завершение сессии

• M3: небезопасная аутентификация / авторизация

• PT‑MOB-002: некорректное завершение сессии

• Операционная система: Android, iOS

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

Приложение ShireCart не отсылает запрос на прекращение действия сессионного идентификатора на сервере, в результате чего идентификатор остается валидным после завершения сеанса на устройстве пользователя. Таким образом, из‑за ошибки в механизме управления сессиями на стороне клиента сессия не завершается корректно. Это позволяет злоумышленнику перехватить сессию. Как он может это сделать? Мы рассмотрели несколько вариантов выше.

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

Для устранения описанной уязвимости рекомендуется реализовать механизм завершения сессии в мобильном приложении:

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

• Из клиентской части запрос на прекращение действия сессии должен отправляться при нажатии кнопки «Завершение сеанса».

Рекомендуем также привязывать идентификатор сессии к IP‑адресу устройства на стороне серверной части мобильного приложения.

Похожие уязвимости в известных компонентах и приложениях:

• CVE-2023–40 732 (PT-2023–5189). Модуль QMS.Mobile приложения QMS Automotive не аннулирует токен сессии при выходе из системы. Это может позволить злоумышленнику провести атаку с перехватом сеанса.

Уязвимости, связанные с биометрической аутентификацией в приложениях

• M8: некорректная конфигурация безопасности

• Операционная система: Android

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

В iOS проверка отпечатка пальца носит имя Touch ID, а проверка с помощью технологии распознавания лица — Face ID. Touch ID не хранит изображений отпечатков, а использует только их математические представления, из которых невозможно получить исходный отпечаток. Face ID реализована при помощи камеры TrueDepth, которая распознает геометрию лица. Когда TrueDepth подтверждает присутствие лица и внимание пользователя, она проецирует и считывает тысячи инфракрасных точек для составления карты глубины лица, а также создает двумерное инфракрасное изображение. На основе этих данных выстраивается последовательность двумерных изображений и карт глубины, которые защищаются цифровой подписью и отправляются в Secure Enclave. Там математическое представление лица пользователя под различными углами сохраняется.

Биометрическая аутентификация на Android представляет собой более сложную систему, которую разные производители могут адаптировать под свои нужды. Чтобы учитывать это разнообразие, в документе для определения совместимости с Android предъявлены требования к реализации проверки биометрии и определены классы безопасности. Функция распознавания отпечатков в Android сканирует палец пользователя и проверяет на совпадение с зарегистрированными шаблонами. Если совпадение найдено, результаты передаются в компонент FingerprintService для дальнейшей обработки. Для связи с оборудованием используется специальный язык определения аппаратных интерфейсов (Hardware Interface Definition Language, HIDL). Для сопоставления отпечатков разработчик должен реализовать в своей библиотеке интерфейс IBiometricsFingerprint.hal, экземпляр которого содержит приложение для связи с сенсором и аппаратной абстракцией над ним. Распознавание лица в Android работает схожим образом, но использует компонент FaceService и другие интерфейсы для подключения к библиотекам производителя — IBiometricsFace.hal и IBiometricsFaceClientCallback.hal.

Рассмотрим ряд сценариев, которые иллюстрируют эксплуатацию уязвимостей, связанных с биометрической аутентификацией.

Обход проверки живого присутствия

Злоумышленник запускает приложение MiddleEarthID на виртуальном устройстве, передает на виртуальную камеру предварительно записанные видео и фото и успешно проходит проверку живого присутствия (liveness). Обойти контроль liveness еще проще, если разработчики не предусмотрели проверку консистентности изображений или некорректно реализовали проверку на deepfake.

Что можно сделать:

• Запретить запуск приложения с виртуальных устройств с измененной прошивкой и установленными системными правами (root, jailbreak).

• Обеспечить целостность отправляемых изображений, используя криптографические паттерны (например, шифрование RSA или AES, подпись MAC или ECDSA).

• Увеличить энтропию во время верификации, сделав невозможным предварительную запись всех действий (например, требовать произнести случайную последовательность цифр).

Небезопасная реализация биометрической аутентификации

В приложении MiddleEarthID используется простейшая проверка биометрических данных (BIOMETRIC_WEAK). На основании предъявленной биометрии не генерируются ключи, которые далее могут быть использованы для шифрования критически важной информации. Какие варианты развития событий возможны?

Первый вариант: злоумышленник перехватывает и переопределяет метод authenticate() с помощью вызова функции callback.onAuthenticationSucceeded(). Результат аутентификации становится пустым, а в MiddleEarthID проверка биометрических данных считается пройденной.

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

Чтобы предотвратить возникновение подобных уязвимостей, рекомендуется использовать объекты CryptoObject. Кроме того, следует шифровать критически важные данные приложения ключом, использование которого требует обязательного предъявления биометрии. Для этого нужно включить поддержку StrongBox Keymaster для устройств начиная с Android 9, используя параметры setUnlockedDeviceRequired(true) и setIsStrongBoxBacked(true) при генерации ключа. При применении биометрической аутентификации дополнительно используйте параметр setUserAuthenticationRequired(true), а для устройств начиная с версии Android 11 добавляйте параметр setUserAuthenticationParameters(0, AUTH_BIOMETRIC_STRONG).

Хранение секретов и учетных данных в открытом виде

• M1: неправильное использование учетных данных

• M9: небезопасное хранение данных

• PT‑MOB-041: хранение конфиденциальной информации в журнале регистрации событий

• PT‑MOB-044: хранение конфиденциальной информации в исходном коде приложения

• PT‑MOB-046: хранение пользовательских данных в открытом виде

• Операционная система: Android, iOS

Секреты, имена и пароли пользователей, хранящиеся в журналах регистрации событий, исходном коде и общедоступных директориях в открытом виде, до сих пор являются распространенной проблемой:

• В некоторых случаях access‑токен пользователя сохраняется по пути /data/.../selectedconfig.hive — это можно использовать для получения несанкционированного доступа к приложению.

• Даже если для отправки приложения в Google Play используется безопасный способ хранения учетных данных (например, переменная окружения PLAY_STORE_CREDS), в репозитории могут быть найдены имена и пароли, сохраненные при отправке коммитов разработчиком до изменения способа хранения.

• Некоторые библиотеки (например, f_logs) сохраняют журнал регистрации событий в качестве отдельного файла. В нем могут оказаться передаваемые в открытом виде HTTP‑параметры, пользовательские данные, в том числе номер телефона и пароль, сессионный токен, запрашиваемый URL.

• Приложение может хранить пароль и имя учетной записи в обычных файлах в незашифрованном виде или в LocalStorage (получить эти данные можно в результате эксплуатации других уязвимостей или напрямую из хранилища при наличии root‑доступа). ПИН‑код и учетные данные пользователя, которые хранятся в защищенных хранилищах KeyChain и hardware‑backed keystore, могут быть получены с помощью перехвата вызовов сценариев, выполняемых в контексте приложения. При этом злоумышленнику не требуется знать ПИН‑код: еще до его ввода данные из безопасного хранилища можно обнаружить в памяти.

• В файлах с исходным кодом или в бинарных файлах при дизассемблировании могут содержаться внутренние адреса приложения. Злоумышленник может использовать эти данные при планировании и проведении атак.

Конкретные примеры:

• В приложении ElrondArchive имя, фамилия и номер телефона пользователя хранятся на устройстве во внутренней директории в открытом виде.

• Приложение MoriaLink использует SQLite, где в открытом виде хранятся ПИН‑код, токен доступа и идентификатор пользователя.

Как улучшить ситуацию:

• Хранить зашифрованные данные в директориях с ограниченным доступом, а ключ — на сервере. Можно также использовать ключ, сгенерированный на основе пароля или парольной фразы (комбинации должны быть стойкими).

• Не хранить конфиденциальную информацию в репозитории с исходным кодом. Использовать переменные окружения, системы развертывания CI/CD или специальные решения для хранения секретов. Оперативно сменять данные, утекшие из репозитория. Рекомендуется также применять протекторы мобильных приложений с функцией обфускации для сокрытия забытых в коде секретов.

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

• Использовать протекторы мобильных приложений с функцией автоматического удаления логов.

• При сохранении данных в KeyChain можно использовать флаги управления доступом. Например, при установке kSecAttrAccessibleWhenUnlocked данные доступны, только когда устройство разблокировано, а резервное копирование отключено. Чтобы информация оставалась только на устройстве, а не в резервной копии, необходим параметр ThisDeviceOnly.

• Если в Android ключи хранятся аппаратно, при их создании рекомендуется использовать метод setUserAuthenticationRequired(true): доступ к ним можно будет получить только пройдя аутентификацию.Устройство также может не поддерживать аппаратное хранилище ключей — в этом случае Android Keystore предоставляет возможность хранить и шифровать их на уровне ОС.

Отсутствие защиты от анализа и модификации файлов

• M7: недостаточная бинарная защита

• PT‑MOB-013: отсутствие защиты от внедрения кода и перепаковки

• PT‑MOB-014: отсутствие обнаружения прав root (jailbreak)

• PT‑MOB-015: отсутствие обфускации (кода)

• Операционная система: Android, iOS

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

• Отсутствие контроля целостности исполняемых файлов.

• Отсутствие защиты от модификации кода во время его выполнения.

• Наличие необфусцированного кода.

• Отсутствие проверок для обнаружения прав root (jailbreak).

Незащищенность от реверс‑инжиниринга.Вот сценарии, с которыми неоднократно сталкивались эксперты Positive Technologies:

• Исследуя приложение DurinWallet с помощью инструмента jadx‑gui, обнаружили отладочные необфусцированные файлы с суффиксом -dbg в названии. Внутри содержался исходный код и комментарии разработчиков.

• В приложении AragornMarket не было проверки на root (jailbreak). После того как пользователь авторизовался, вредоносное ПО с повышенными привилегиями могло получить учетные данные. Если приложению на устройстве были доступны системные привилегии, злоумышленник имел возможность реализовывать серьезные угрозы безопасности: беспрепятственно обходить ограничения политик (например, на доступ к файловой системе); получать привилегированный доступ к межпроцессному взаимодействию (например, обращаться напрямую к приватным компонентам Android‑приложения); читать и модифицировать память любого процесса (манипулировать данными и модифицировать выполняемый код); использовать данные, хранимые в защищенном аппаратном хранилище, без их получения (например, применять ключи шифрования из KeyChain); считывать любую информацию, которую вводит пользователь.

• С помощью утилиты objection можно было внедрить в приложение ShireSecurity библиотеку frida‑gadget, чтобы контролировать состояние процесса во время выполнения. Разработчики не предусмотрели механизмы контроля целостности и проверки цифровой подписи. Это позволяло получать и модифицировать данные приложения и обходить ограничения политик безопасности.

Что можно порекомендовать разработчикам

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

Известные реализации программ для обфускации исходного кода:

• ProGuard (или DexGuard) — для Android;

• SiriusObfuscator и SwiftShield — для iOS.

Во‑вторых, рекомендуется предупреждать пользователя, что использовать устройство с правами root (jailbreak) небезопасно, или блокировать работу приложения при обнаружении подобных прав. Стоит отметить, что блокировка может побуждать пользователей скачивать и устанавливать нелегальные и вредоносные версии приложения, в которых ее нет.

Варианты проектов с открытым исходным кодом, в которых реализовано обнаружение использования root (jailbreak):

• RootBeer — для Android;

• iOS Security Suite — для iOS.

В‑третьих, чтобы затруднить динамический анализ мобильного приложения, необходимо контролировать целостность кода во время его выполнения, а также использовать механизмы, препятствующие отладке продуктивной версии. Для защиты от перепаковки рекомендуется проверять целостность исполняемых файлов с помощью контрольной суммы. Лучше задействовать white‑box‑реализации криптографически стойких хеш‑функций, например SHA-256 или SHA-512.

Для защиты целостности кода во время его выполнения рекомендуется придерживаться архитектурных принципов, изложенных на сайте OWASP. В этом случае также обязательно проверять наличие доступа с правами root (jailbreak) на устройстве и принудительно блокировать работу приложения.

Общие рекомендации

При разработке мобильных приложений аналитики PT Cyber Analytics предлагают следовать перечисленным ниже советам:

• Не храните данные в открытом виде в общедоступных директориях и в директориях с ограниченным доступом.

• Ограничьте доступ к временным данным в защищенном хранилище (KeyChain, hardware‑backed keystore), выбрав нужный ключ семейства kSecAttrAccessible (для iOS), или реализуйте механизм аутентификации для доступа к ключу (для Android).

• Храните зашифрованные данные в директориях с ограниченным доступом, а ключ — на сервере (при полном доверии к нему).

• Используйте динамически генерируемые ключи для шифрования: злоумышленник не сможет подобрать их по словарю.

• Используйте явные намерения (explicit intents).

• Контролируйте целостность исполняемых файлов, а также кода во время его выполнения.

• Реализуйте проверку на наличие прав root (jailbreak) на устройстве.

• Используйте методы запутывания кода (обфускацию).

• Проводите статический и динамический анализ исходного кода для обнаружения уязвимостей и аномалий.

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

Для верной настройки конфигурации безопасности:

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

• Не используйте жестко закодированные стандартные учетные данные.

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

• Запрашивайте только те разрешения, которые необходимы для правильного функционирования приложения.

• Отключите отладочные механизмы в продуктивной версии.

• Отключите резервное копирование на устройствах Android, предотвратив тем самым включение конфиденциальных данных в резервную копию.

Подведение итогов

Согласно прогнозам аналитиков PT Cyber Analytics:

1. Хранение пользовательских данных в открытом виде останется в топ-5 уязвимостей мобильных приложений в 2025 году.

2. Неправильная конфигурация безопасности (М8) останется одной из самых популярных уязвимостей в отечественном сегменте.

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

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

---

@ Направление проектов по кибербезопасности, Positive Technologies