Какие методы анализа защищенности мобильных приложений бывают

Обновлено: 07.01.2025

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

Однако с хорошей инструкцией даже джуниор может сам провести базовый пентест за 1–2 дня.

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

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

специалист по тестированию на проникновение компании BI.ZONE

Готовим инструменты

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

Если работаете с Android, еще пригодится бесплатная утилита Android Backup Extractor.

Revolut , Санкт-Петербург, Москва, можно удалённо , По итогам собеседования

Из специфически пентестерского арсенала вам хватит единственного инструмента — Mobile Security Framework (MobSF). Это автоматизированный универсальный фреймворк, который помогает проводить аудит безопасности мобильных приложений. Загрузив в него ipa-образ для iOS или apk-образ для Android, вы сможете провести динамический и статический анализ сборки. MobSF полезен и для целей безопасной разработки: к примеру, с помощью раздела Files удобно отслеживать, не попадают ли в релизную сборку лишние файлы.

Следим за лишней информацией в релизных сборках

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

Их нежелательно оставлять по нескольким причинам.

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

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

для iOS-клиента — просмотрите все строки, определенные в ipa-образе, в разделе Scan Options / ViewStrings;
для Android-клиента — проверьте строки в разделе Reconnaissance / Strings, а также обратите внимание на раздел Security Analysis / Code Analysis.

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

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

План действий. Воспользуйтесь инструментами Console.app для iOS и adb для Android, чтобы увидеть, включено ли логирование в релизной сборке приложения и что туда попадает.

Чтобы логи не уходили в релизную сборку, лучшее решение — грамотно спроектировать класс Logger. Если же исправление нужно быстро, настройте в скриптах релизной сборки удаление методов логирования из кода. Для iOS-приложений это делается через препроцессорный макрос, а для Android — с помощью применения правил ProGuard.

Проверяем ограничение на отправку СМС

Следующим шагом ищем уязвимость к SMS Abuse: она одновременно и очень распространена, и весьма критична.

Это важно для приложений, в которых часть действий завязана на СМС: двухфакторная аутентификация, восстановление пароля, перевод денег и так далее.

Полностью защититься от атаки не получится, но можно сделать ее экономически невыгодной для злоумышленника. Для этого введите капчу при множественных запросах для одного пользователя. А еще хорошо, когда неаутентифицированный пользователь не может запрашивать СМС (кроме как для входа, конечно).

Проводим ревизию библиотек

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

План действий. С помощью MobSF посмотрите, какие библиотеки собраны неправильно и чего не хватает: для этого зайдите в раздел Security Analysis / Binary Analysis.

Исследуем компоненты для работы с внешними ссылками

Внешние ссылки (App Links, Deep Links, Universal Links) могли вам потребоваться по разным причинам:

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

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

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

При встраивании компонентов для работы с App Links отдельно убедитесь, что ваш сервер сконфигурирован для проверки подписи вашего приложения (подробнее об этом — в инструкциях для разработчиков на iOS и на Android). Иначе ссылку могут перехватить.

Наконец, если ваше приложение обрабатывает и Deep Links, и App Links, определите для них разные компоненты: в противном случае нивелируются собственные меры безопасности, которые есть у App Links.

Проверяем другие открытые компоненты

В Android-клиентах специально определяют открытые компоненты — activity, сервисы и другие компоненты, которые могут обрабатывать запросы от других приложений, установленных на том же устройстве.

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

План действий. Только вы можете решить, какие компоненты вам действительно важны для работы с другими приложениями и компонентами ОС. А увидеть их все в одном окне можно с помощью MobSF — для этого зайдите в раздел Security Analysis / Manifest Analysis.

Ищем недочеты в работе с компонентом WebView

Этот шаг актуален для приложений, которые задействуют WebView:

отображают с его помощью документы — условия использования приложения, документы о согласии обработки персональных данных и пр.;
проводят авторизацию через сторонний сайт, например Google, Apple, «Яндекс»;
целиком (или отдельный модуль) написаны на фреймворках наподобие React Native.

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

План действий. Если вам нужно показать PDF-документ или статический HTML, не стоит добавлять компонент WebView. Лучше воспользоваться штатными возможностями системы: на iOS — UIDocumentInteractionController, на Android — ACTION_VIEW. Так ваш документ откроется в приложении, которое пользователь чаще всего использует для подобных задач. Это удобнее, проще и безопаснее.

Если задача чуть шире — например, вы показываете отчет, который наполняется динамически — WebView уместен. Главное — убедитесь, что при создании этого компонента вы отключили исполнение JavaScript-кода. Атакующий, как правило, не может повлиять на эти данные, однако отключить поддержку JavaScript-кода стоит из принципа минимальных привилегий.

Для сложных задач предпочтительнее использовать:

на iOS — WKWebView-компонент. SFSafariViewController тоже допустим, но он менее универсален: в нем нельзя отключить обработку JavaScript-кода при необходимости;
на Android — Chrome Custom Tabs вместо WebView. Если же вы используете WebView, включайте поддержку нескольких окон. Это нужно, чтобы защитить пользователей на старых версиях ОС от недавно найденной уязвимости CVE-2020-6506 (если кратко, то это выполнение произвольного JavaScript-кода в документе верхнего уровня).

Изучаем данные в резервных копиях телефона

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

План действий. Чтобы принять решение, проверьте, какую информацию приложение хранит в резервной копии. На iOS проще всего использовать обычный Finder (или iTunes), на Android — adb. Просмотреть содержимое резервной копии можно с помощью программ iMazing и Android Backup Extractor соответственно.

Ориентируемся на лучшие практики

Заключительный шаг проверки посвятим трем так называемым best practices. Их отсутствие само по себе не говорит об уязвимостях — но если встроить эти практики, защищенность пользователя сильно вырастет. А встраивать их несложно.

SSL Pinning

Размытие изображения в фоне

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

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

План действий. Решить, подходит вам эта практика или нет, помогут ответы на два вопроса:

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

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

Аутентификация на телефоне

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

Если в вашем приложении есть аутентификация по отпечатку пальца или графическому ключу, убедитесь, что у вас есть привязка к BiometricPrompt.CryptoObject. С ней вы будете пользоваться всеми возможностями криптографии на Android: при успешной локальной аутентификации приложение будет получать доступ к ключу шифрования, на котором расшифровывается объект, соответствующий сессии пользователя (например, refresh-токен).

План действий. Смотрите пример из мануала для Android-разработчиков: тут в деталях показано, как встроить привязку к CryptoObject.

Резюмируя

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

Но пентест не серебряная пуля. Лучшая защита — у тех приложений, которые создаются в рамках подхода security by design: когда безопасность берут в расчет с самого начала разработки.

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

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

Автор: Михайлова Анна, Angara Technologies Group.

Аннотация

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

Обзор мобильных угроз

Рынок вирусов для мобильных устройств вырос и усложнился. Мобильным устройствам угрожают уже не только относительно безобидные трояны-кликеры, но и полноценные вирусы и шпионское ПО. Большинство вирусных исследовательских компаний выделяют следующие виды угроз:

Adware и кликеры. Иногда для данного вида угроз используется термин «Madware» (Mobile Adware). Основная цель этого класса ВПО – показ пользователю нерелевантной рекламы и генерирование искусственных переходов на сайты рекламодателей. С помощью «Madware» злоумышленники зарабатывают «клики» и демонстрируют оплачивающим их компаниям иллюзию интереса пользователей.

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

Дроппер – ВПО, целью которого является скачивание другого вредоносного ПО.

Вирус – ПО, которое наносит явный вред, например, выводит из строя конкретное приложение или одну из функций устройства.

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

Мобильные устройства также подвержены и традиционным атакам (например, DNS Hijacking, E-mail Phishing), так как используют те же базовые пользовательские сервисы, что и персональные ПК.

Рассмотрим примеры наиболее известного мобильного ВПО: «Агент Смит», Culprit, SockPuppet или Unc0ver, Ztorg, Monokle.

Заподозрить заражение «Агентом Смитом» можно по заметному увеличению показа нерелевантной рекламы. Пока это единственное зафиксированное вредоносное действие этого ВПО, хотя, технически, оно имеет огромный вредоносный потенциал. Масштаб заражения Агентом Смитом – 25 млн. устройств, преимущественно, в Азии. Поведение ВПО частично напоминает работу таких вирусов, как Gooligan, Hummingbad, CopyCat. «Агент Смит» действует следующим образом:

Пользователь скачивает дроппер в составе зараженного приложения (бесплатной игры или приложения с возрастным цензом).

Дроппер проверяет наличие на мобильном устройстве популярных приложений, таких как WhatsApp, MXplayer, ShareIt.

Дроппер скачивает и распаковывает архив, который превращается в APK-файл, при необходимости, обновляет и заменяет легитимное популярное приложение на зараженный вариант.

SockPuppet или Unc0ver – ВПО, позволяющее получить злоумышленнику права суперпользователя для систем iOS и MacOS (Jailbreak). ВПО скачивается в составе зараженного приложения, которое определенный промежуток времени было доступно даже в официальном магазине Apple. ВПО регулярно обновляется и эксплуатирует уязвимость CVE-2019-8605, которая наследуется новыми версиями iOS. В версиях iOS 12.2 и 12.3 уязвимость была закрыта, после чего вновь появилась в версии 12.4 и была пропатчена в версии 12.4.1.

Старый троян Ztorg под ОС Android после установки собирает сведения о системе и устройстве, отправляет их на командный сервер, откуда приходят файлы, позволяющие получить на устройстве права суперпользователя (Jailbreak). ВПО распространяется через зараженные приложения и рекламные баннеры.

Monokle под ОС Android и iOS – троян, позволяющий вести полноценный шпионаж за жертвой: записывать нажатия клавиатуры, фотографии и видео, получать историю интернет-перемещений, приложений социальных сетей и мессенджеров, вплоть до записи экрана в момент ввода пароля. Троян снабжен рядом эксплойтов для реализации необходимых прав в системе, распространяется, предположительно, с помощью фишинга и зараженных приложений. Первые версии ВПО появились под ОС Android, но уже появились версии для устройств Apple.

Источники угроз

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

Установка пакета приложений APK из неофициальных маркетов.

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

Фишинг и социальная инженерия – SMS, MMS с привлекательными для жертвы вредоносным контентом или ссылкой. Или звонок от ложного «оператора связи» или «служащего банка» с требованием передать учетные данные. Известны несколько нашумевших случаев добровольной установки пользователями программы удаленного управления TeamViewer, якобы, по просьбе службы безопасности банка. После установки программы пользователи передавали злоумышленникам учетные данные для удаленного управления, что равнозначно передаче разблокированного телефона в чужие руки.

Концепция Bring Your Own Device, BYOD (использование для работы с корпоративными документами личного устройства) привносит в корпоративный сегмент целый класс угроз – мобильное устройство сотрудника становится точкой входа во внутреннюю сеть предприятия и источником утечек информации.

Основные методы защиты от мобильных угроз

По версии NIST (NIST SPECIAL PUBLICATION 1800-4 Mobile Device Security, Cloud and Hybrid Builds) для снижения риска заражения мобильного устройства и утечки конфиденциальной информации необходимо реализовать следующие методы защиты:

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

Защита сетевого трафика: шифрование канала передачи данных, использование внешних фильтрующих решений для очистки трафика. Использование корпоративного шлюза, сканирующего web и email-трафик, или использование облачных решений очистки трафика от ВПО.

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

Реализация «песочницы»: использование приложения с изолированным контейнером для хранения данных, которое, как правило, выполняет шифрование данных, контроль их целостности, изоляцию данных приложения в оперативной памяти, запрет копирования данных (вплоть до запрета на снятие скриншотов), удаленное уничтожение данных.

Контроль установленных приложений, вплоть до составления «белого» списка разрешенных приложений, контроль их целостности. Контроль целостности приложений при запуске устройства.

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

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

Антивирусная защита: регулярное сканирование системы, файлов, приложений. Сканирование приложений перед их установкой.

Классы решений для защиты мобильных устройств

EMM=MDM+MAM+MCM+EFS

На рынке представлены следующие классы решений для защиты мобильных:

Антивирусные решения. Наиболее популярные среди них: Kaspersky Internet Security, Trend Micro Mobile Security, BitDefender, ESET NOD32 Mobile Security, Avast Mobile Security & Antivirus, Dr.Web Anti-virus, AVG Antivirus, Avira Antivirus Security, Norton Security & Antivirus, McAfee Security & Antivirus.

Mobile Threat Management, MTM (источник термина – IDC) – агент, выполняющий, помимо антивирусной защиты, фильтрацию корпоративного почтового трафика и трафика мессенджеров от вредоносных URL и документов, интеграцию с корпоративным облаком для фильтрации трафика и мониторинга событий. Возможно дополнительное шифрование контейнера данных приложения. На рис. 1 представлен квадрат решений MTM от IDC за 2019 год.

Рис. 1. Квадрат решений MTM 2019, IDC

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

Enterprise Mobility Management, EMM – новое поколение средств защиты мобильных устройств, выросшее из MDM-решений и впоследствии влившееся в концепцию Unified Endpoint Management (UEM). EMM, дополнительно к решениям MDM, включает в себя решения MAM (Mobile Application Management), Mobile Content/Email Management (MCM/MEM), Encrypting File System (EFS), централизованное управление и мониторинг, настройку отдельных приложений, в частности, контроль за установкой приложений из определенного репозитория, удаление приложений, шифрование данных, аудит, проверку на соответствие политикам.

UEM-консоли – общие консоли управления мобильными устройствами и ОС пользователей. В сущности, современные производители средств защиты мобильных устройств предлагают решения, совмещающие набор технологий: MDM, MAM, UEM, MCM/MEM, управление конфигурацией и политиками.

Квадрат Gartner по UEM-решениям за 2019 год представлен на Рис. 2.

Рис. 2. Квадрат Gartner по UEM решениям за 2019 год

Основные выводы

Вслед за развитием мобильных технологий, растет количество и разнообразие ВПО, нацеленного на мобильные устройства.

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

Использование только доверенных официальных прошивок и приложений.

Личная мобильная гигиена в использовании устройств: не устанавливайте неизвестные программы из недоверенных источников, не давайте приложениям избыточные разрешения (например, приложению «Фонарик» не нужен доступ к фотографиям).

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

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

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

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

Для снижения риска заражения вредоносным ПО, обеспечения защиты от утечек конфиденциальных данных и минимизации ущерба в случае потери физического контроля над устройством рекомендуется также использовать специализированные средства защиты – антивирусы, решения класса MTM, а также корпоративные решения классов UEM, MDM, EMM.

Всем привет! Меня зовут Святослав, работаю QA gangsta lead в EVO, а в тестировании уже более 8 лет. Ищу уязвимости свыше 4 лет, веду тренинги по тестированию безопасности, провожу независимые аудиты security и QA. Также у меня есть security QA-блог для начинающих и Telegram-канал.

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

Вступление

В предыдущей статье я писал о том, как с Manual QA перешел к поиску веб-уязвимостей. К чему это я?! Когда занимаешься чем-то одним длительное время, оно надоедает, и я решил попробовать разобраться, как же происходят проверки на уязвимости в мобильных приложениях. Топик взял из списка OWASP TOP 10, только для мобайла. OWASP переехал, поэтому не смогу скинуть ссылку на официальный топик.

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

После того как я открыл список и ознакомился с мобильными топ-уязвимостями, понял, что половина из них полностью похожи на вебовские, то есть OWASP TOP 10 классический, который мы все так привыкли видеть. Так как, по сути, у нативных и веб-приложений один и тот же способ работы — по типу клиент-серверной архитектуры. То есть в мобайле клиентом является нативное приложение, а в вебе — браузер, но и у того, и у другого запросы поступают на сервер. Это и приводит к выводу, что половину техник можно взять из веб-уязвимостей, чтобы применить поиски дыр в нативных приложениях.

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

Что нам понадобится

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

Мобильный девайс. Либо поднятый через эмулятор Genymotion, либо реальный, но обязательно рутированный, так как без рут-привилегий пенетретить не удастся.

Santoku Linux. Этот дистрибутив был создан специально для того, чтобы проверять Android-апликухи на уязвимости. В нем уже из коробки предустановлены все нужные приложения для взлома.

Итак, начнем поиск со статистики распространенности каждой из дыр топа OWASP. Если возьмем статистику 2018 года, то увидим, на какие категории уязвимостей стоит обращать больше внимания при аудите мобильного приложения.

А теперь, думаю, пора перейти к разбору каждой из категорий. Начнем рассматривать их не по порядку, а с M9 — Reverse Engineering, так как пентест начинается именно с нее.

M9 — Reverse Engineering

Реверс-инжиниринг мобильного кода — обычное явление. Это процесс простого и несанкционированного анализа:

исходного кода приложения;
библиотек;
алгоритмов;
таблиц и т. д.

Чтобы получить исходный код приложения, нужно на Santoku Linux закинуть установочный файл мобильного приложения, то есть APK, открыть консоль и выполнить нетрудные команды.

Выполняем команду unzip -d diva-beta base.apk . Как вы догадались, она разархивирует приложение и все файлы положит в папку, которую мы назвали diva-beta.

Далее нужно перейти в эту папку и в ней выполнить следующую команду: d2j -dex2jar classes.dex . С ее помощью мы совершаем декомпиляцию кода, который находится в этом файле. Если мы откроем этот файл без декомпиляции, то увидим в нем только кракозябры. После отработки этой команды в папке появится новый файл с именем classes-dex2jar.jar , в котором будет нормальный исходный код приложения, пригодный для чтения человеком.

Для того чтобы открыть этот файл и начать изучать код приложения, нам понадобится приложение Jadx, которое также установлено в нашем дистрибутиве Linux. Выполняем команду jd-gui classes-dex2jar.jar .

После отработки этой команды откроется приложение Jadx. Мы увидим в нем весь исходный код и сможем понять все его недостатки, то есть найти уже с его помощью какие-то уязвимости.

M1 — Improper Platform Usage

И с M9-категории перейдем к M1. К этой категории относится неправильное использование функции операционной системы или мер безопасности платформы. Это случается часто и может оказать существенное влияние на уязвимые приложения.

Давайте перейдем к примеру. Так как у нас это приложение уже есть с исходным кодом, с помощью предыдущей уязвимости изучим одну из activity этой апки.

Мы видим, что разработчик при дебаге приложения использовал logcat , чтобы понимать, какие ошибки были в данном поле. Но при компилировании приложения в релизную сборку забыл убрать эту команду дебага. Что это может означать для пользователей приложения? То, что действия будут логироваться, если там будут какие-то ошибка или предупреждения. То есть, когда юзер будет писать в форму (а, допустим, это форма для принятия карточных данных), эти данные будут мелькать в логах приложения, если пользователь допустит ошибку при заполнении формы или получит предупреждение по заполнению. Нетрудно догадаться, что к этим логам злоумышленник может получить доступ. Подробнее — в этом видосе.

M2 — Insecure Data Storage

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

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

То есть нужно помнить о двух моментах:

конфиденциальные данные в приложении надо хранить в зашифрованном виде;
приложения могут делиться данными с другими приложениями.

Как пример возьмем форму регистрации в мобильном приложении.

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

M3 — Insecure Communication

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

M5 — Insufficient Cryptography

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

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

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

На картинке выше видим, что разработчик применил метод хеширования MD5, который прям так и кричит: «Ломай меня полностью!» Это один из самых легких методов.

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

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

M4 — Insecure Authentication

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

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

Для примера: злоумышленник может использовать просто какой-то анализатор приложения, допустим тот же Burp Suite. Ему достаточно проанализировать, какие есть страницы у этого приложения.

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

В этом запросе можно:

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

О том, как настраивать анализатор к мобильному приложению, я писал в статье о M3 — Insecure Communication.

M6 — Insecure Authorization

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

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

Поиск можно делать также с помощью Burp Suite, пытаясь выполнить запросы, которые доступны админу, в качестве обыкновенного пользователя. Смотрите уязвимость M4.

M7 — Client Code Quality

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

В пример можно привести историю с WhatsApp, когда его инженеры обнаружили возможность переполнения буфера путем отправки специально созданной серии пакетов. Для этого не нужно было отвечать на вызов, и злоумышленник мог выполнить произвольный код. Оказалось, что такая уязвимость использовалась для установки на телефон программ-шпионов. Эту услугу продала израильская компания NSO Group.

Не стоит использовать функции, которые могут переполнить буфер, вот так:

M8 — Code Tampering

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

к другим приложениям в вашем телефоне;
к поведению пользователя.

M10 — Extraneous Functionality

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

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

Увидим, что здесь разработчик оставил подсказку, что нужно ввести, чтобы получить доступ к необходимым нам данным. Видос здесь.

Подытожим

Теперь вы знаете:

об OWASP Mobile Top 10;
инструменты, с помощью которых можно искать уязвимости;
программах, в которых можно попрактиковаться в поиске уязвимостей.

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

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

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

Останавливаться на исключительно автоматизированном анализе не стоит – точность автоматического анализа обычно уступает экспертному (часто почему-то называемого "ручным"). Компромиссное решение – новые версии продукта исследовать в лаборатории, а текущие обновления и небольшие добавления функционала исследовать в процессе разработки автоматически.

Методы обеспечения защищенности заказного приложения не отличаются от таких же мер для тиражируемого программного обеспечения, однако способы их применения разнятся. Рассмотрим их подробнее.

Статический анализ исходного кода

Распространенный способ анализа приложения – исследование его исходного кода. Иногда для описания такого процесса используется термин whitebox – "белый ящик", в противовес "черному ящику". На этом этапе различными методами находятся некорректные программные конструкции, которые могут привести к некорректной работе приложения. Необязательно эти конструкции после сборки проекта станут уязвимостями или "закладками", они могут, например, просто замедлять работу приложения, что часто случается с неправильно построенными запросами к базе данных.

Список некорректных программных конструкций, которые ищутся на этом этапе исследования защищенности, не очень велик, он насчитывает едва ли несколько сотен названий (в отличие от миллионов записей в антивирусных базах). Но даже настоящая уязвимость, найденная таким способом, может не иметь возможности быть проэксплуатированной в реальной ситуации – приложение в продуктиве может запускаться из-под такой учетной записи и/или с такими настройками, что воспользоваться "дырой" у злоумышленника не будет возможностей. Тем не менее специалисты по безопасности приложений рекомендуют все равно исправлять найденные дефекты кода: во-первых, это быстрее и дешевле, чем проверять гипотезу о том, что этот дефект можно эксплуатировать; во-вторых, настройки и учетные записи могут быть в дальнейшем изменены, код может быть использован снова в другом приложении и т.д., поэтому оставлять подозрительный код в системе с точки зрения управления рисками неправильно.

Динамический анализ приложения

Тестирование приложения методом "черного ящика", также называемое динамическим анализом, позволяет исследовать защищенность приложения, компилируя его с различными параметрами и исполняя его на реальном или виртуальном процессоре. Чтобы исследовать заказное приложение таким способом, необходимо имитировать действия пользователей и администраторов системы, подавать на вход те данные, которые планируются на ввод в реальной системе. Исследуя реакции приложения на разные воздействия, можно обнаружить и нетипичные реакции – например, запросы к данным, скрытый канал передачи данных и т.п.

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

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

Тестирование на проникновение

Еще один способ исследования защищенности приложения – моделирование действий взломщика. Специалисты по взлому пытаются найти лазейки, для того чтобы осуществить атаку с целью похитить находящуюся в нем информацию, "уронить" приложение или добиться отказа в обслуживании (DoS), провести незапланированную операцию и т.д. Тестирование приложения может осуществляться как автоматизированным способом – моделирование программными скриптами известных способов атак, так и вручную – специалистом по "этическому взлому", то есть хакером.

Экспертный анализ приложения

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

Что выбрать и выбирать ли вообще?

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

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

С чего начать?

Содержать у себя квалифицированную экспертизу скорее всего не получится. Дело даже не в заоблачной стоимости таких специалистов, а в возможности загрузить их интересными задачами. Эксперты такого уровня не будут заниматься рутиной ни за какие деньги. Поэтому наиболее простые способы начать контролировать защищенность своего приложения – это автоматизированные способы анализа с помощью быстрых инструментов. Автоматизации хорошо поддается статический анализ и тестирование на проникновение некоторыми, наиболее распространенными моделями атак. Начав с автоматизированного анализа, вы сможете получить информацию о наиболее распространенных уязвимостях как общих для любых приложений, так и специфических конкретно для этого приложения (так называемые application specific vulnerabilities). Конечно, специфические решения вы не сможете получить "из коробки", но интеграторы смогут обучить решение на такие проверки.

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

Содержать у себя квалифицированную экспертизу скорее всего не получится. Дело даже не в заоблачной стоимости таких специалистов, а в возможности загрузить их интересными задачами. Эксперты такого уровня не будут заниматься рутиной ни за какие деньги. Поэтому наиболее простые способы начать контролировать защищенность своего приложения – это автоматизированные способы анализа с помощью быстрых инструментов. Автоматизации хорошо поддается статический анализ и тестирование на проникновение некоторыми, наиболее распространенными моделями атак. Начав с автоматизированного анализа, вы сможете получить информацию о наиболее распространенных уязви-мостях как общих для любых приложений, так и специфических конкретно для этого приложения (так называемые application specific vulnerabilities). Конечно, специфические решения вы не сможете получить "из коробки", но интеграторы смогут обучить решение на такие проверки.

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

Читайте также: