Удаление блокировки Android-устройства из любого мобильного приложения

Удаление блокировки Android-устройства из любого мобильного приложения

Недавно была раскрыта новая уязвимость платформы Android (CVE-2013-6271: Remove DeviceLocks from Android Phone), присутствующая как в устройствах на базе Android Jelly Bean (JB) 4.3, так и, как выяснилось в ходе моих тестов, в более ранних версиях, например, в Android Ice Cream Sandwich (ICS) 4.0.3. Брешь позволяет любому мобильному приложение удалить код-пароль или блокировку на Android-устройствах вне зависимости от механизма ее реализации: PIN-код, пароль или парольная фраза, рисунок, жест или разблокировка по лицу.

Автор: Raul Siles

Недавно была раскрыта новая уязвимость платформы Android (CVE-2013-6271: Remove DeviceLocks from Android Phone), присутствующая как в устройствах на базе Android Jelly Bean (JB) 4.3, так и, как выяснилось в ходе моих тестов, в более ранних версиях, например, в Android Ice Cream Sandwich (ICS) 4.0.3. Брешь позволяет любому мобильному приложение удалить код-пароль или блокировку на Android-устройствах вне зависимости от механизма ее реализации: PIN-код, пароль или парольная фраза, рисунок, жест или разблокировка по лицу. Список довольно внушительный.

В Android реализован процесс межпроцессорного сообщения (Inter Process Communication, IPC) через сообщения, называемых Интентами (Intents). Около года назад мы начали анализировать Интенты посредством фреймворка Mercury, разработанного MWR InfoSecurity. Более подробно об этой теме вы можете прочитать в предыдущей статье Криса Кроули (Chris Crowley). Недавно курс SEC575 обновился, и теперь вместо Mecury используется Dozer. Поскольку фреймворк Dozer упоминается в соответствующем разделе статьи, где описывается уязвимость, я подумал, что это прекрасный повод продемонстрировать анализ Android-приложения. В этой статье я опишу методы и утилиты, которые мы, как пентестеры и специалисты по безопасности, можем использовать для глубокого анализа этой уязвимости, которая все еще очень распространена в Android-приложениях.

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

В курсе SEC575 при статическом анализе Android-приложений фокус внимания в основном смещен на анализ сторонних приложений, например тех, которые вы загружаете из Google Play (это официальный магазин Android-приложений) или любого другого стороннего источника. Если вам нужно проанализировать стандартное Android-приложение (например, Settings) на предмет присутствия уязвимости CVE-2013-6271, то процесс анализа претерпит некоторые изменения.

Замечание: В процессе анализа в качестве родительской операционной системы используется Windows 7, а в качестве целевой мобильный платформы – эмулятор Android. Хотя, та же самая последовательность действий может быть использована и при анализе приложения на реальном мобильном устройстве или любой другой родительской операционной системе.

Статический анализ Android-приложений

Для того чтобы проанализировать любое Android приложение, первым делом необходимо раздобыть копию соответствующего Android-пакета (файл .apk) из магазина Google Play или непосредственно с мобильного устройства. Этот пакет представляет собой сжатый ZIP-файл, который можно легко проанализировать. Внутри файла вы можете найти информацию о ресурсах и сертификатах, а также два наиболее важных файла Android-приложения: AndroidManifest.xml (который, среди прочего, содержит привилегии, требуемые приложением и публично экспортируемые компоненты), и classes.dex (бинарный файл приложения в формате Dalvik Executable или DEX):

Рисунок 1: Содержимое файла .apk

Хотя стандартные системные Android-приложениям оптимизированы для увеличения скорости во время их загрузки и запуска, вследствие чего соответствующий пакет .apk не содержит файл classes.dex. У таких приложений бинарный файл выведен за пределы пакета .apk и сконвертирован в файл с расширением .odex (Optimized DEX).

Уязвимость CVE-2013-6271 затрагивает системное приложение Settings (определяемое как «com.android.settings»). Приложение Settings находится в папке «/system/app/» на Android-устройствах и состоит из двух файлов: Settings.apk и Settings.odex. Утилита adb, доступная в Android SDK, может использоваться для извлечения этих двух файлов:

Рисунок 2: Процедура извлечения файлов приложения

Поскольку файл .apk не содержит бинарного файла приложения, мы будем анализировать файл .odex. Файл .odex должен быть деоптимизирован и дизассемблирован для дальнейшего изучения (утилиту для решения этой задачи можно скачать отсюда). Приложение baksmali помогает нам сделать деоптимизацию и дизассемблирование Android-приложения и на входе требует четыре аргумента: Android API level (аргумент –a), целевой файл .odex (аргумент –x), директорию, где содержатся библиотеки фрейморка (аргумент –d) и выходную директорию для сохранения дизассемблированного кода приложения (аргумент –o).

Полная версия команды выглядит так:

C:\> baksmali -a 18 -x Settings.odex -d framework -o Settings

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

Содержимое директории, содержащей все библиотеки фреймворка, можно сформировать посредством копирования файлов и папок, информация о которых содержится в переменной окружения BOOTCLASSPATH на устройстве на базе Android 4.3. Здесь нам вновь поможет утилита adb:

Рисунок 3: Получаем содержимое переменной окружения BOOTCLASSPATH

Теперь вы можете скопировать и вставить значение переменной BOOTCLASSPATH в текстовый файл («BOOTCLASSPATH-jar.txt»), а затем обработать этот файл в Windows (при помощи команды adb pull) для того, чтобы получить все библиотеки с устройства и соответствующие .odex файлы. Следующий перечень команд упрощает этот процесс (в разделе «Дополнительные ресурсы» приводится ссылка на скрипт «BOOTCLASSPATH.bat»):

C:\> set /p BCPJAR= < BOOTCLASSPATH-jar.txt
C:\> echo %BCPJAR:.jar=.odex% > BOOTCLASSPATH-odex.txt
C:\> set /p BCPODEX= < BOOTCLASSPATH-odex.txt
C:\> echo %BCPJAR% && echo %BCPODEX%
C:\> FOR %a in (%BCPJAR::= %) do @echo %a >> BOOTCLASSPATH-jar-lines.txt
C:\> FOR %a in (%BCPODEX::= %) do @echo %a >> BOOTCLASSPATH-odex-lines.txt
C:\> mkdir framework
C:\> cd framework
C:\> FOR /F %i in (..\BOOTCLASSPATH-jar-lines.txt) DO adb pull %i
C:\> FOR /F %i in (..\BOOTCLASSPATH-odex-lines.txt) DO adb pull %i

После выполнения вышеупомянутых команд директорию «framework» можно использовать как значение аргумента -d утилиты baksmali.

После выполнения этой команды будет создана новая директория «Settings», содержащая деоптимизированный и дизассемблированный Smali-код. Ту же самую утилиту можно использовать для повторной компиляции Smali-кода в формат Dalvik EXecutable (файл с расширением .dex). При повторной компиляции требуется ввести два аргумента: ранее созданную директорию Settings и имя выходного DEX-файла (аргумент –o). Команда выглядит так:

C:\> smali Settings -o Settings.dex

В результате выполнения команды будет создан новый файл с именем «Settings.dex», который содержит деоптимизированную версию бинарного файла приложения Settings. Этот файл схож с файлом «classes.dex», доступный в пакете APK для случая со сторонними приложениями. Теперь мы можем использовать утилиту dex2jar, которая декомпилирует DEX-файл и извлечет соответствующий Java байт-код (файлы .class):

C:\> dex2jar Settings.dex

Утилита dex2jar создаст новый файл «Settings_dex2jar.jar», содержащий Java байт-код для приложения Settings. При помощи декомпилятора Java (например, JD-GUI) можно открыть этот .jar файл и получить исходный код Java (или приблизительную его версию) целевого приложения.

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

Фреймворк Drozer предоставляет продвинутые возможности для взаимодействия с Android-приложениями и их компонентами. После установки Drozer-агента на целевом Android-устройстве, которое будет функционировать как вредоносное приложение, становится возможным установить связь между консолью и агентом Drozer. Из консоли можно получить список всех пакетов, связанных со словом «setting», для того, чтобы попытаться опознать приложение Settings («com.android.settings»):

Рисунок 4: Перечень пакетов содержащих слово «setting»

В состав утилиты Drozer входят несколько модулей, позволяющих выполнять более глубокий анализ компонент используемых приложением и, в частности, потенциально уязвимый Activity из списка с перечнем в 104 элемента, экспортируемых приложением, с именем «com.android.settings.ChooseLockGeneric»:

Рисунок 5: Перечень Activity (черным цветом выделен искомый нами Activity)

Теперь мы можем использовать декомпилятор JD-GUI, чтобы открыть Java байт-код приложения Settings (.jar файл) и исследовать тот класс, который нас интересует, используя детали уязвимости CVE-2013-6271 и имя Activity, найденного в предыдущем шаге («com.android.settings.ChooseLockGeneric»). Проинспектировав исходный код этого класса, мы можем увидеть как во время создания Activity (внутри функции «onCreate()») из Интента извлекается и оценивается дополнительный булевой параметр «confirm_credentials» на предмет того, требуется ли подтверждение со стороны пользователя.

Рисунок 6: Содержимое функции onCreate()

Кроме того, из Интента ожидается дополнительный целочисленный параметр «lockscreen. password_type», который связан с Activity, используемым для обновления настроек блокировки:

Рисунок 7: Ожидание дополнительного параметра lockscreen. password_type

Затем приложение вызывает функцию «updateUnlockMethodAndFinish()», которая содержит последний участок уязвимого кода, если значение предыдущего упомянутого параметра равно 0 (после прохождения через функцию «upgradeQuality()» и соответствующего ей кода):

Рисунок 8: Последний участок уязвимого кода

После исследования исходного кода, мы опознали два дополнительных параметра, которые требует "com.android.settings.ChooseLockGeneric" и теперь сможем выполнить уязвимый код. Фреймворк Drozer помогает создать новый экземпляр Activity и передать Интент с двумя дополнительными параметрами:

Рисунок 9: Передача Интента с установленными дополнительными параметрами

Если целевое устройство защищено кодом-паролем (например, PIN-кодом), то после пересылки Интента с установленными дополнительными параметры из Drozer-агента к целевому приложению Settings, уязвимый код, упомянутый выше, будет запущен и блокировка устройства будет немедленно удалена, как показано на рисунке ниже:

Рисунок 10: Разблокировка устройства

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

Контрмеры, принятые в Android 4.4

Во время того же самого анализа для Android 4.4 и использования Dozer’a для эксплуатации уязвимости, появились некоторые изменения при попытке удалить блокировку на устройстве. На обновленной платформе при попытке со стороны пользователя или приложения изменить код-пароль или удалить блокировку, мобильное устройство выдавало сообщение, запрашивая предыдущий пароль (например, пользователь должен ввести предыдущий PIN-код):

Рисунок 11: При попытке изменить пароль или удалить блокировку появляется окно с требованием ввода предыдущего пароля

Углубленный анализ обновленного приложения Settings для платформы Android 4.4 выявляет способ устранения уязвимости в последней версии платформы. Системное приложение Setting на платформе Android 4.4 хранится в другой папке («/system/priv-app/»). В этой папке теперь по умолчанию хранятся все привилегированные приложения (вместо старой папки «/system/app», используемой для хранения всех системных приложений в предыдущих версиях Android):

Рисунок 12: Теперь приложение Settings находится в новой папке

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

Рисунок 13: Подробная информация о приложении Settings

Файл Settings.odex все также можно проанализировать при помощи методов, описанных выше. Основное отличие заключается в расширенном наборе библиотек, которые использует фреймворк платформы Android 4.4. Вот что содержится в переменной окружения BOOTCLASSPATH:

Рисунок 14: Содержимое переменной окружения BOOTCLASSPATH

В результате чего, следующие три изменения помогают устранить описанную уязвимость и сделать платформу Android 4.4 устойчивой к подобному виду атак. Исходный код класса «com.android.settings.ChooseLockGeneric» содержит новый подкласс «InternalActivity» в самом низу исходного кода:

Рисунок 15: Появился новый подкласс «InternalActivity»

Быстрое сравнение исходного кода класса «ChooseLockGeneric» платформ Android 4.4 и Android 4.3 выявило следующие изменения. Теперь внутри функции «onCreate()» происходит проверка, является ли Activity экземпляром нового подкласса «InternalActivity», что не позволяет создать Activity во внешних приложениях:

Рисунок 16: Сравнение исходного текста класса «ChooseLockGeneric» на двух платформах Android

Файл AndroidManifest.xml у приложения Settings также претерпел изменения в новой версии Android, чтобы не происходило публичного экспорта «InternalActivity». Теперь этот XML-файл в бинарном формате, и можно использовать утилиту AXMLPrinter2 для его конвертации в текстовый формат и дальнейшего детального анализа. Команда выглядит так:

C:\> AXMLPrinter2 AndroidManifest.xml > AndroidManifest.txt

Рисунок 17: Сравнение двух XML файлов

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

Перечень используемых утилит

AXMLPRinter2: http://code.google.com/p/android4me/
dex2jar: https://code.google.com/p/dex2jar/
Drozer: https://labs.mwrinfosecurity.com/tools/drozer/
JD-GUI: http://jd.benow.ca/#jd-gui
smali/baksmali: https://bitbucket.org/JesusFreke/smali/

Примечание: В процессе анализа использовались пакетные скрипты, которые запускали соответствующее Java-приложение (например, baksmali) в действительности выполняя команду «java -jar baksmali-2.0.2.jar %*»

Дополнительные ресурсы

BOOTCLASSPATH.bat: пакетный скрипт Windows, который создает директорию «framework» со всеми библиотеками фреймворка Android (файлы с расширением .jar & .odex), упомянутыми в файле «BOOTCLASSPATH-jar.txt», взятыми при помощи команды «adb pull» из локального Android-устройства или эмулятора Android (AVD).

BOOTCLASSPATH-jar_4.3.txt: Перечень библиотек фреймворка платформы Android 4.3.
BOOTCLASSPATH-jar_4.4.txt: Перечень библиотек фреймворка платформы Android 4.4.

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!