Анализ защищенности приложений для операционной системы Android

1. Удалось каким-либо образом вынудить жертву добавить сертификат сервера злоумышленника в системное хранилище на устройстве.

2.В случае компрометации одного из CA из системного хранилища устройства.

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

Процесс обнаружения

Обнаружить данный недостаток можно двумя способами:

1. При анализе исходного кода убедиться, что отсутствуют вызовы библиотечных методов, отвечающих за проверку сертификатов. И/или отсутствует файл network_security_config.xml.

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

Рекомендации по устранению недостатка

Для устранения возможности такого исхода, следует добавить в приложения механизм certificate pinning, один из способов реализации которого был описан в главе выше.

2.8 Прочее

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

2.8.1 Использование директивы android:installLocation со значением “auto”

Уровень критичности: информационный

В случае, если будет указано “auto”, это значит, что нет предпочтений, где должно быть установлено приложение, соответственно оно может быть установлено во внешнее хранилище мобильного устройства. Система Android в зависимости от различных факторов (например, заполненность внутреннего хранилища) сама решит, куда устанавливать приложение.

Соответственно в случае, если оно будет установлено во внешнее хранилище, то любое стороннее приложение сможет получить доступ к файлам приложения. [60]

Процесс обнаружения недостатка

Для обнаружения данного недостатка достаточно открыть файл AndroidManifest приложения и используя поиск по ключевым словам найти директиву “android:installLocation”.

Анализ критичности

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

Рекомендации по устранению

Рекомендуется использовать данную директиву только со значением internalOnly.

2.8.2 Отсутствие FLAG_SECURE у Activity в которых отображается конфиденциальная информация

Уровень критичности: информационный

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

Использование данной директивы запрещает явное и неявное снятие снимков экрана для конкретного Activity.

Процесс обнаружения

Для обнаружения недостатка достаточно воспользоваться поиском по ключевому слову FLAG_SECURE.

Анализ критичности

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

Рекомендации по устранению

Для устранения недостатка рекомендуется добавить в код в вызовы onCreate() Activity следующий код:

window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

Пример 39: использование FLAG_SECURE.

Тем самым, данное Activity будет нельзя заснять на снимок экрана, а также при открытии диспетчера задач, предпросмотр приложения будет заменен на «заглушку». [60]



2.8.3 Риск утечки данных через вредоносную клавиатуру

Уровень критичности: информационный

Эксплуатация данного недостатка возможно в том случае, если приложение использует системную клавиатуру для работы с полями ввода конфиденциальной информации, например, ввод пароля, ОТП-кода и т. д. [6]

Процесс обнаружения

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

Далее открыть в исходного коде необходимый Activity и проанализировать код на наличие вызовов нативной клавиатуры.

Например, строки подобного содержания:

val keyboard = (MyKeyboard) findViewById(R.id.keyboard)

Пример 40: передача переменной keyboard ссылку на разметку клавиатуры.

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

Анализ критичности

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

Рекомендации по устранению

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



2.8.4 Чрезмерное использования логирования в приложении

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

if (error){ Log.d("LOG", "Sanitized report is: $log") }

Пример 41: логирование в приложении.

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

Недостаток заключается в том, что существует вероятность того, что приложение с использованием логирования может оказаться в продукционной среде, что не является рекомендуемой практикой с точки зрения чистоты кода, а также, потенциально, в лог могут попасть конфиденциальные данные (например, в случае если при отладке использовалось логирование для записи ошибок при аутентификации). [60]

Процесс обнаружения недостатка

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

Рекомендации по устранению

При выпуске приложения в продукционную среду рекомендуется очистить код от использования Log.

2.8.5 Использование allowBackup со значением true в AndroidManifest.xml приложения

Уровень критичности: средний

Приложения для ОС Android которые написаны и выполняются на устройствах с версией API 23 имеют функциональность автоматической резервации данных (каждые 24 часа) в пользовательский Google Drive.

В резервную копию попадают такие файлы как SharedPreferences, файлы сохраненные во внутреннем и внешнем хранилище приложения, а также файлы, созданные с помощью класса SQLiteOpenHelper. [30]

Процесс обнаружение недостатка

Для обнаружения недостатка достаточно открыть файл AndroidManifest.xml приложения и убедиться, что директива allowBackup используется со значением true (как на примере ниже).

<application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name"

Пример 42: allowBackup= “true”.

Анализ критичности

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

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

Рекомендации по устранению

Рекомендуется установить значение false для allowBackup.

2.8.6 Использование android:debuggable в продукционной версии приложения

Уровень критичности: высокий

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

Процесс обнаружения недостатка

Для поиска данного недостатка достаточно открыть файл AndroidManifest.xml приложения и убедиться, что он содержит похожий с примером код.

android:debuggable="true" android:theme="@style/AppTheme">

Пример 43: debuggable= “true”.

Анализ критичности

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

Рекомендации по устранению

Рекомендуется явно указывать значение false для флага android: debuggable.



ГЛАВА 3. РЕЗУЛЬТАТЫ АНАЛИЗА

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

Рис 3. Таблица с недостатками.

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

Рис 4. Соотношение недостатков и их критичности.

Исходя из диаграммы мы видим, что наибольшее количество недостатков имеют информационный уровень критичности - 12, среднего уровня критичности - 4, низкого - 3 и высокого уровня критичности - 2.

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

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

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

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

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

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

Далее, основываясь на рассмотренных недостатках, появляется возможность предложить альтернативный подход, к анализу мобильных приложений для ОС Android.

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

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

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

1. Методология не дает оценки критичности описываемых недостатков.

2. Методология не ставит целью формирование более общего представления о процессах анализируемого приложения.

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

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

В предлагаемой методологии процесс анализа мобильного приложение разбивается на пять этапов:

1. Этап первый - обнаружение и анализ компонентов, которые в качестве входного параметра получают недоверенные данные.

2. Этап второй - анализ защищенности коммуникаций приложения.

3. Этап третий - анализ используемых механизмов хранения данных.

4. Этап четвертый - анализ компонентов WebView.

5. Этап пятый - анализ и выявление компонентов подверженных риску утечки данных через сторонние каналы.

6. Этап шестой - анализ недостатков в AndroidManifest.xml.

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

Этап первый

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

Можем видеть, что основные компоненты, через которые вредоносное приложение или злоумышленник могут попытаться внедрить контролируемый ими ввод -- это Activity, Content Provider, Broadcast Receiver и Service.

Рис 5. Компоненты, через которые могут передаваться недоверенные данные.

Эти компоненты имеют схожую структуру что упрощает процесс выявления недостатков.

Предлагаемая последовательность действий:

1. Обнаружение и запись всех указанных выше компонентов взаимодействие с которыми возможно вне контекста приложения (например, через intent, xported=true и т. д.)

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

3. Эксплуатация тех компонентов, в которых были обнаружены уязвимости.

Этап второй

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

Рассмотрим схему:



Рис 6. Коммуникации.

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

Предлагаемая последовательность действий при анализе:

1. Анализ реализации механизмов, связанных с безопасностью коммуникаций клиент-сервер, в частности, Certificate Pinning, исследование network_security_config.xml и т. д.

2. Анализ компонентов, ответственных за передачу данных внутри приложения.

3. Анализ компонентов, ответственных за передачу данных сторонним приложениям.

4. Эксплуатация тех компонентов, в которых были обнаружены уязвимости.

Рис 7. Хранение данных.



Этап третий

На этом этапе предлагается проанализировать реализацию механизмов направленных на защиту хранимых данных. Предлагаемая последовательность действий:

1. Поиск и анализ вызова методов ответственных за хранение данных во внешнем хранилище.

2. Поиск и анализ вызова методов ответственных за хранение данных в SharedPreferences.

3. Поиск и анализ вызова методов ответственных за хранение данных в SQLite.

4. Поиск и анализ вызова методов ответственных за хранение данных во внутреннем хранилище.

5. Поиск и анализ вызова методов связанных с KeyStore.

Этап четвертый

Наиболее критическими недостатками, которые характерны на этом этапе являются, в первую очередь, использование в коде JavaScript-интерфейсов и наличие доступа к локальным файлам приложения. Соответственно, на этапе анализа следует сфокусироваться на поиске компонентов Activity которые работают с WebView и проанализировать следующие аспекты:

1. Разрешено ли в контексте WebView выполнение JavaScript - кода.

2. Используются ли в вызываемых классах интерфейсы JavaScript.

3. Используются ли вызовы методов, дающих доступ WebView к локальным файлам в приложении.

4. В случае, если HTML страницы загружаются локально, убедиться, что они загружаются из доверенного источника.

Этап пятый

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

Предлагаемая последовательность действий

1. Проанализировать код приложения на использование FLAG_SECURE в компонентах Activity которые содержать конфиденциальную информацию

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

3. Исследовать код на предмет логирования конфиденциальной информации.

Этап шестой

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

Предлагаемая последовательность действий

1. Поиск директивы android:debuggable со значением true

2. Поиск директивы allowBackup со значением true



ЗАКЛЮЧЕНИЕ

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

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

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

Размещено на Allbest.ru