Мобильные платформы предоставляют множество различных услуг, от аутентификации, до обеспечения безопасного хранения данных, для защиты сетевых коммуникаций. Таким образом, если некорректно использовать какую-либо часть платформы, можно выставить данные незащищенными или разрешить соединения с ненадежными хостами. В данном разделе про Android часть 12 мы суммировали все сказанное в предыдущих частях и привели контрольный список Android.
Небезопасное использование криптографии распространено в большинстве мобильных приложений, которые используют шифрование. Существует два основных способа, по которым некорректная криптография проявляется в мобильных приложениях. Во-первых, мобильное приложение может использовать процесс шифрования/дешифрования, который в корне ошибочен и может быть использован злоумышленником для дешифрования конфиденциальных данных.
Во-вторых, мобильное приложение может реализовать или использовать алгоритм шифрования/дешифрования, который является слабым по своей природе и может быть непосредственно расшифрован злоумышленником. В следующих подразделах более подробно рассматриваются оба этих сценария:
1 Опора на встроенные процессы шифрования кода. Обход встроенных алгоритмов шифрования кода в лучшем случае тривиален. Всегда предполагайте, что злоумышленник сможет обойти любое встроенное шифрование кода, предлагаемое базовой операционной системой.
2 Некорректно произведенный процесс управления ключами. Для лучших алгоритмов не имеет значения, правильно или неправильно вы используете свои ключи. Многие ошибаются в использовании правильного алгоритма шифрования, вместо этого они реализуют свой собственный протокол для его использования.
3 Создание и использование пользовательских протоколов шифрования. Всегда используйте современные алгоритмы, которые воспринимаются сообществом безопасности как сильные, и, когда это возможно, используют современные API-интерфейсы шифрования на вашей мобильной платформе.
Бинарные атаки могут привести к тому, что злоумышленник определит общие библиотеки, которые вы использовали вместе с любыми жестко закодированными ключами в двоичном формате. В случаях с очень высокими требованиями к безопасности, которые связаны с шифрованием, вам следует серьезно подумать об использовании white-box криптографии.
4 Использование небезопасных и/или устаревших алгоритмов. Многие криптографические алгоритмы и протоколы не должны использоваться, поскольку они показали, что имеют значительные недостатки или же являются недостаточно современными, чтобы удовлетворить требования безопасности. К ним относятся:RC2,MD4,MD5,SHA1.
Название теста Описание
Мощная защита хранилища с помощью надежной криптографии -
Определение небезопасных/устаревших криптографических алгоритмов (RC4, MD5, SHA1) в исходном коде.
Некорректно произведенный процесс управления ключами - Идентификация жестко закодированного ключа в приложении или ключей, которые могут быть перехвачены с помощью бинарных атак.
Использование пользовательских протоколов шифрования - Определить реализацию собственного протокола.
M6 – Небезопасная авторизация - Контрольный список безопасности Android
Чтобы протестировать некорректные схемы авторизации, тестировщики могут выполнять бинарные атаки против мобильного приложения и пытаться выполнять функции, для которых требуются определенные права доступа, и которые должны выполняться только пользователем с более высокими привилегиями, в то время как мобильное приложение находится в режиме «офлайн».
Тестировщики должны попытаться выполнить любую привилегированную функциональность в сеансе с низкими правами доступа в пределах соответствующих запросов POST/GET для чувствительных функций на второстепенном сервере. Некорректная авторизация или её отсутствие позволяют злоумышленнику выполнять функциональные возможности, на которые они не должны иметь прав, используя аутентифицированного пользователя с более низкими привилегиями мобильного приложения.
Требования авторизации являются более уязвимыми, когда решение принимается в мобильном устройстве, вместо удаленного сервера. Это может быть требование, которое необходимо ввиду того, что мобильные телефоны часто могут работать офлайн.
Технический эффект может носить широкий характер и зависит от выполняемой сверхпривилегированной функциональности. Например, сверхпривилегированное выполнение функций удаленного или локального администрирования может привести к разрушению систем или доступу злоумышленника к конфиденциальной информации.
Название теста - Описание
Запоминание функциональности учетных данных (Постоянная аутентификация) - Определяет пароль пользователя или сеансы на устройстве.
Недостатки аутентификации на стороне клиента - Выполняет бинарные атаки против мобильного приложения, чтобы обойти автономную (офлайн) аутентификацию.
Нарушения авторизации на стороне клиента - Выполняет бинарные атаки против мобильного приложения и пытается выполнять привилегированные функции, которые должны выполняться только пользователем с более высокими правами доступа.
Обход недостатков бизнес-логики - Определение контроля доступа к отсутствующему функциональному уровню (Missing Function Level Access Control), тестирование отрицательных значений.
Данные пользователя в Logcat -- Важные технические данные в Logcat.
Проверяет adb logcat - Проблемы с кодом и неправильное использование состояния приложения. Обход эффективных механизмов проверки подлинности и выдача себя за законного пользователя. Поднятие привилегий учетной записи злоумышленника в среде, которая в противном случае считалась бы «защищенной от дурака» (foolproof). (Эскалация привилегий). Манипулирование значениями на стороне сервера косвенными методами, которые невозможно предсказать или обнаружить.
Обход недостатков бизнес-логики - Определение контроля доступа к отсутствующему функциональному уровню (Missing Function Level Access Control), тестирование отрицательных значений.
Данные пользователя в Logcat. Важные технические данные в Logcat - Проверка adb logcat.
Проблемы с кодом и неправильное использование состояния приложения - Обход эффективных механизмов проверки подлинности и выдача себя за законного пользователя. Поднятие привилегий учетной записи злоумышленника в среде, которая в противном случае считалась бы «защищенной от дурака» (foolproof). (Эскалация привилегий). Манипулирование значениями на стороне сервера косвенными методами, которые невозможно предсказать или обнаружить.
Общедоступные цели - Проверка заданных явных и неявных целей.
Разрешения и цифровые подписи. Разделение буфера обмена - Проверьте, возможно ли удаление подписи в поле цифровой подписи. Проверьте, могут ли быть обнаружены нежелательные разрешения в манифесте android.
Режим конкуренции (Race Conditions), Взаимная блокировка (Deadlocks), и Угрозы параллелизма (Concurrency Threats) - Режим конкуренции: проверьте, не работает ли один или несколько потоков внутри одного приложения. Взаимная блокировка: проверьте, не застряли ли параллельные модули, ожидая друг друга, чтобы что-то сделать. Угрозы параллелизма: проверьте, как потоки в системе взаимодействуют для выполнения заданий, которые были им назначены.
Устройство DoS (Denial of Service) атаки - Инструменты DoS, такие как LOIC и Packet Generator, с удобными интерфейсами из проверенных источников, таких как магазин Play в Google.
M7 – Качество клиентского кода - Контрольный список Android
Инъекция на стороне клиента приводит к выполнению вредоносного кода на мобильном устройстве через мобильное приложение.
Лучший способ узнать, является ли приложение уязвимым для инъекций, - это определить источники ввода и подтвердить, что данные, предоставленные пользователем/приложением, подлежат проверке ввода, запрещая инъекцию кода. Проверка кода - это быстрый и достаточно точный способ проверить правильность обработки данных.
Инструменты анализа кода могут помочь аналитику безопасности найти использование интерпретаторов и проследить поток данных через приложение. Пентестеры, которые проводят тестирование на проникновение вручную, могут подтвердить наличие этих проблем, создав эксплойты, которые подтверждают уязвимость.
Поскольку данные могут поступать из многих источников в мобильных приложениях, важно перечислить их, и четко определить, чего они пытаются достичь. В общем, инъекционные атаки (injection attacks) на мобильные устройства нацелены на следующее:
Данные на устройстве:
SQL инъекция: SQLite (механизм хранения данных по умолчанию для многих телефонов) может подвергаться инъекции также, как и в веб-приложениях. Угроза видеть данные с использованием этого типа инъекций является рискованной, когда в вашем приложении размещается несколько разных пользователей, платный/разблокируемый контент и т. д.
Импликация локального файла: обработка файлов на мобильных устройствах имеет те же риски, что и были упомянуты выше, за исключением того, что она имеет отношение к чтению файлов, которые могут быть представлены вами в директории приложения.
Сессия мобильных пользователей: JavaScript инъекция (XSS, Etc): мобильный браузер также подвержен JavaScript-инъекции. Обычно мобильный браузер имеет доступ к куки-файлу мобильных приложений, что может привести к краже сеанса.
Интерфейсы или функции приложения:
Несколько интерфейсов приложений или языковые функции могут принимать данные и могут быть искажены, чтобы вызвать сбой в приложении. В то время как большинство из этих недостатков не приводят к перегрузкам из-за управляемого кода платформ телефона, тем не менее, было несколько, которые использовались в качестве эксплойта «userland» в цепочке эксплойтов, нацеленной на rooting или джейлбрейк устройства. Сам двоичный код:
Мобильное вредоносное программное обеспечение или другие вредоносные приложения могут выполнять двоичную атаку на представительском уровне (HTML, JavaScript, Cascading Style Sheets CSS) или на фактический двоичный код исполняемого файла мобильного приложения. Эти инъекции кода выполняются либо фреймворком мобильного приложения, либо самим двоичным кодом в период работы.
Название теста - Описание
Недостаточное усиление WebView (XSS) - Определение неправильной конфигурации на "android.webkit.WebSettings". (Javascript/File access/Plugins), XSS через UIWebview
Поставщики контента: SQL инъекции и включение локального файла - Определите SQLi и LFI в компоненте поставщика контента
Инъекция (SQLite Инъекция, XML Инъекция) - Идентификация SQL и XML в приложении
Включение локального файла через NSFileManager или Webviews - Проверьте LFI на приложении (../, ../../blah\0). Webviews FileAccess Атака через setAllowFileAccess
Подписание кода - Проверьте, что приложение подписано цифровым способом и его файлы .apk оптимизированы
Отображение внешних интерфейсов Java в Web Views DOM. Риски выполнения JavaScript в WebViews - Проверка веб-просмотров - двумя наиболее важными обратными вызовами являются WebChromeClient для событий браузера и WebViewClient для веб-событий.
Загрузка динамического DEX на Dalvik - Убедитесь, что приложение для Android вместо загрузки файлов Dalvik («dex») из местоположения по умолчанию может загружать их из других мест, таких как внутреннее хранилище или по сети.
Открытые секреты кода NDK - Проверьте наличие открытого кода ndk по следующему пути ANDROID_HOME и ANDROID_NDK_HOME при локальной установке SDK и NDK.
Tapjacking - Проверьте, могут ли определенного рода действия в одном приложении Android собирать входные данные, в то время как оверлей активен в другом приложении
Некорректное использование решения выполнения динамического кода - В Android DexClassLoader позволяет приложению загружать классы из файлов jar и apk. Проверьте, можем ли мы создавать файлы apk для загрузки в другое приложение в период работы.
Обнаружение искажения либо подделки кода является превентивной мерой, используемой в мобильных приложениях, чтобы гарантировать, что третья сторона не перекомпилировала и не опубликовала ваше приложение под своей учетной записью или не хранила его без вашего согласия.
Чтобы обнаружить и смягчить фальсификацию приложений для Android:
- Проверьте, было ли приложение переименовано.
- Проверьте, было ли приложение опубликовано без вашего согласия.
Название теста - Описание
Неправильное использование компонентов Android через IPC задачи («экспортировано» и «фильтр целей/задач») - Идентификация экспортированных компонентов Android
Неправильное использование URL схем - Для iOS: определение схем URL через info.plist и Clutch + Strings для получения структур схемы URL. Для Android: определение схем URL через исходный код или файл apk
Чтобы перепроектировать файл APK из его источника, вам необходимо сделать следующее:
- Exploding APK
- Извлечь Java классы
- Декомпилировать Java источники
- Изучить APK содержимое
Обратная разработка кода приложения - Разборка и декомпиляция приложения, проверка обфускации
Неавторизированное изменение кода - Бинарная атака через манипуляцию в период работы и изменение кода кода. Binary attack through run-time manipulation and code modification
Отладка поведения приложения с помощью анализа его периода работы - Определить атрибут “android:debuggable”. Использование GDB / LLDB для приложения.
M10 – Внешняя функциональность - Контрольный список Android
Эта категория относится к обработке сеанса и различным способам его небезопасного выполнения. Неправильное поведение во время сеанса обычно приводит к тем же результатам, что и некорректные действия во время аутентификации. После аутентификации и входа в сеанс, он может позволить получить доступ к мобильному приложению. Код мобильного приложения должен защищать пользовательские сессии так же тщательно, как и его механизм аутентификации.
Вот несколько примеров того, как это часто делается неправильно:
1 Неудача в признании недействительными сеансов в выходном буфере
2 Отсутствие достаточной защиты с помощью лимита времени
3 Неправильная замена файлов cookie
4 Небезопасное создание токена
Неудача в признании недействительными сеансов в выходном буфере
Многие разработчики делают недействительными сеансы в мобильном приложении, а не на стороне сервера, оставляя большое окно возможностей для злоумышленников, которые используют инструменты манипуляции HTTP. Убедитесь, что все события аннулирования сеанса выполняются на стороне сервера, а не только на мобильном приложении.
Отсутствие достаточной защиты с помощью лимита времени
Любое мобильное приложение, которое вы создаете, должно иметь достаточную защиту с помощью лимита времени на компонентах выходного буфера. Это помогает предотвратить вредоносный потенциал неавторизованного пользователя, который намеревается получить доступ к существующему сеансу и принять на себя роль этого пользователя.
Приемлемый период ожидания может сильно различатся в зависимости от чувствительности приложения, собственного профиля риска и т. д., но мы хотим предложить вам некоторые хорошие рекомендации:
- 15 минут для приложений с высокой степенью защиты
- 30 минут для приложений со средней степенью защиты
- 1 час для приложений с низкой степенью защиты
Взаимодействия, как правило, являются спорадическими, непредсказуемыми и вытягиваются на более длительный срок, чем в традиционных веб-приложениях. В некоторых случаях, имеет смысл установить более длительные лимиты времени, поскольку интервал между транзакциями может быть намного длиннее.
Однако это увеличенное окно таймаута сеанса увеличит риск его кражи, если обработка сеанса не будет выполнена должным образом. Является очень важным повысить этот риск с помощью полномочий, чтобы обеспечить правильную обработку сеанса.
Неправильная замена файлов cookie
Еще одна серьезная проблема с реализациями управления сеансом - это отказ должным образом сбросить файлы cookie во время изменений состояния аутентификации. Изменения состояния аутентификации включают в себя такие события, как:
- Переход от анонимного пользователя к зарегистрированному пользователю
- Переход от любого зарегистрированного пользователя к другому зарегистрированному пользователю
- Переход от обычного пользователя к привилегированному пользователю.
- Истечение лимита времени.
- Для каждого из этих типов событий крайне важно, чтобы сеансы были уничтожены на стороне сервера и что файлы cookie, представленные как часть предыдущих сеансов, больше не принимаются. В идеале, если даже ваше приложение обнаружило бы любое использование указанных файлов cookie, то оно сразу бы сообщило об этом соответствующей группе безопасности.
В дополнение к своевременному признанию недействительными токенов (на стороне сервера) во время ключевых событий приложения, также важно, чтобы сами токены генерировались должным образом. Как и в случае с алгоритмами шифрования, разработчики должны использовать как хорошо зарекомендовавшие себя, так и стандартные методы создания токенов. Они должны быть достаточно длинными, сложными и псевдослучайными, чтобы быть стойкими к атакам с угадыванием (guessing attacks)/ожиданием (anticipation attacks).
Название теста - Описание
Признание недействительными сеансов в выходном буфере - Убедитесь, что все события и меры для аннулирования сеанса выполняются на стороне сервера, а не только на мобильном приложении.
Защита сеанса с помощью установки лимита времени - Мобильное приложение должно обладать достаточной защитой с помощью лимита времени в компонентах выходного буфера.
Замена куки - Убедитесь, что сброшенные файлы cookie правильно обрабатываются во время изменений состояния аутентификации. (Anonymous<->User, User A<->User B, Timeout)
Создание токена - Они должны быть стандартным алгоритмом, достаточно длинным, сложным и псевдослучайным, чтобы быть стойкими к атакам с угадыванием (guessing attacks)/ожиданием (anticipation attacks).
Наслаждайтесь тестированием на проникновение Android
