Еще один [почти] неудаляемый троянец под Android
В конце прошлого года с помощью функции обнаружения изменений в системной области у некоторых наших пользователей было зафиксировано изменение системного файла /system/lib/libc.so. Это одна из главных библиотек операционных систем на базе Linux, которая отвечает за системные вызовы и основные функции. Подробное рассмотрение этого случая позволило выявить новые образцы из семейства троянцев Android.Xiny, известного нам с 2015 года.
У его представителей мы впервые увидели установку атрибута «неизменяемый» на файлы, что существенно усложняло удаление троянцев с устройств.
Выглядело это довольно занятно: на apk-файл установленного приложения ставился указанный атрибут, попытка удалить это приложение выглядела успешной, его данные удалялись, но сам apk-файл оставался на месте. После перезагрузки устройства приложение снова «появлялось». Об одном из таких троянцев мы рассказали в 2016 году. Для борьбы с подобными угрозами мы добавили в наш антивирус функцию сброса атрибутов у файлов, которая работает при условии, что пользователь предоставил антивирусу root-полномочия.
В этой статье мы рассмотрим еще один интересный метод самозащиты, применяемый новыми версиями Android.Xiny.
Android 5.1? В 2019 году?
Троянец, рассматриваемый в данной статье, работает под ОС Android до версии 5.1 включительно. Может показаться странным, что вредоносное ПО, рассчитанное на столь «древние» версии Android, всё ещё активно (версия 5.1 вышла в 2015 году). Но, несмотря на свой возраст, старые версии всё ещё используются. По данным корпорации Google на 7 мая 2019 года, 25.2% устройств работают под управлением Android 5.1 и ниже. Статистика по нашим пользователям даёт чуть большее число — около 26%. Это значит, что около четверти всех Android-устройств являются потенциальными целями, что не так уж и мало. Учитывая, что указанные устройства подвержены уязвимостям, которые никогда не будут исправлены, неудивительно, что старые версии ОС Android всё ещё представляют интерес для вирусописателей. Ведь права root, которые можно получить с помощью эксплуатации упомянутых уязвимостей, развязывают вирусописателям руки — с их помощью можно делать на устройстве всё что угодно. Хотя чаще всего это сводится к банальной установке приложений.
Основные функции троянца
Начиная с самых ранних версий, главная функция троянца Android.Xiny — установка на устройство произвольных приложений без разрешения пользователя. Таким образом злоумышленники могут зарабатывать, участвуя в партнёрских программах, которые платят за установку. Насколько можно судить, это один из основных источников дохода для создателей данного семейства. После запуска некоторых его представителей можно за несколько минут получить практически неработоспособное устройство, на котором будет установлено и запущено множество безвредных, но ненужных пользователю приложений. Кроме того, данные троянцы могут устанавливать и вредоносное ПО — всё зависит от команды, полученной с управляющего сервера.
Самое интересное, что выделяет новые версии троянца Android.Xiny — это защита от удаления. За неё отвечают два компонента. Рассмотрим их подробнее.
Установщик
sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
детект: Android.Xiny.5261
Данный компонент запускается после получения прав root. Он подменяет собой системные файлы /system/bin/debuggerd и /system/bin/ddexe, чтобы обеспечить свой автоматический запуск, а оригиналы сохраняет под именами с суффиксом _server, действуя как классический вирус-компаньон. Также он копирует в системный раздел ещё несколько исполняемых файлов из папки, переданной в параметрах командной строки. Кроме того, троянец может обновлять компоненты, которые установил в системный раздел, если его запустить с особыми параметрами и указать папку, где лежат новые версии.
Android.Xiny.5261 содержит внушительный список файлов для удаления. В него входят пути, характерные для более старых представителей семейства, а также для конкурирующих семейств троянцев, устанавливающихся в системный раздел. Таких как, например, Triada.
Кроме того, Android.Xiny.5261 удаляет некоторые предустановленные приложения — возможно, чтобы освободить место. Наконец, он удаляет известные приложения для управления правами root – такие как SuperSU, KingRoot и другие. Таким образом, он лишает пользователя возможности использовать root-права, а значит, и удалить троянские компоненты, установленные в системный раздел.
Модифицированная системная библиотека libc.so
sha1: 171dba383d562bec235156f101879223bf7b32c7
детект: Android.Xiny.5260
Этот файл заинтересовал нас больше всего, и с него началось это исследование. При беглом взгляде на него в hiew можно заметить наличие исполняемого кода ближе к концу в секции .data, что подозрительно.
Открываем файл в IDA и смотрим, что это за код.
Выясняется, что в данной библиотеке были изменены следующие функции: mount, execve, execv, execvp, execle, execl, execlp.
Код изменённой функции mount:
int __fastcall mount ( const char * source , const char * target , const char * filesystemtype , unsigned int mountflags , const void * data )
<
unsigned __int8 systemPath [ 19 ] ; // [sp+18h] [bp-1Ch]
bool receivedMagicFlags ; // [sp+2Bh] [bp-9h]
int v13 ; // [sp+2Ch] [bp-8h]
v13 = MAGIC_MOUNTFLAGS ; // 0x7A3DC594
receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS ;
if ( mountflags == MAGIC_MOUNTFLAGS )
mountflags = 0x20 ; // MS_REMOUNT
if ( receivedMagicFlags )
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
if ( mountflags & 1 ) // MS_RDONLY
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
if ( getuid_ ( ) ) // not root
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
memCopy ( systemPath , ( unsigned __int8 * ) off_73210 + 471424 , 8 ) ; // /system
decrypt ( systemPath , 8 ) ;
if ( memCompare ( ( unsigned __int8 * ) target , systemPath , 8 ) || ! isBootCompete ( ) )
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
* ( _DWORD * ) errno_ ( ) = 13 ;
return — 1 ;
>
В начале тут происходит проверка параметра mountflags на наличие «волшебного» значения 0x7A3DC594. Если функции передано это значение, управление сразу передаётся настоящей функции mount. Далее проверяется, происходит ли попытка перемонтировать раздел /system на запись и завершена ли загрузка ОС. Если эти условия выполняются, настоящая функция mount не вызывается и возвращается ошибка. Таким образом, модифицированная троянцем функция mount не даёт перемонтировать системный раздел на запись никому, кроме самого троянца, который вызывает её с «волшебным» параметром.
Код изменённой функции execve (в остальных exec*-функциях всё аналогично):
int __fastcall execve ( const char * filename , char * const argv [ ] , char * const envp [ ] )
<
int v3 ; // r3
if ( targetInDataOrSdcard ( filename ) >= 0 ) // returns -1 if true
<
sub_7383C ( ) ;
v3 = call_real_execve ( filename , argv , envp ) ;
>
else
<
* ( _DWORD * ) errno_ ( ) = 13 ;
v3 = — 1 ;
>
return v3 ;
>
int __fastcall targetInDataOrSdcard ( const char * path )
<
char buf [ 516 ] ; // [sp+8h] [bp-204h]
if ( isDataOrSdcard ( path ) )
return — 1 ;
if ( * path == ‘.’ && getcwd_ ( buf , 0x200u ) && isDataOrSdcard ( buf ) )
return — 1 ;
return 0 ;
>
Здесь проверяется, начинается ли путь к запускаемому файлу с «/data/» и содержит ли «/sdcard». Если одно из условий выполняется, запуск блокируется. Напомним, что по пути /data/data/ находятся директории приложений. Таким образом блокируется запуск исполняемых файлов из всех директорий, в которых обычное приложение может создать файл.
Изменения, внесённые в системную библиотеку libc.so, нарушают работу приложений, предназначенных для получения прав root. Из-за изменений в функциях exec* такое приложение не сможет запустить эксплойты для повышения привилегий в системе, поскольку обычно эксплойты представляют собой исполняемые файлы, которые скачиваются из сети в директорию приложения и запускаются. Если же повысить привилегии всё-таки удалось, изменённая функция mount не даст перемонтировать системный раздел на запись, а значит, и произвести в нём какие-либо изменения.
В итоге, самозащита троянца складывается из двух частей: его установщик удаляет приложения для управления root-правами, а модифицированная библиотека libc.so не даёт установить их снова. Кроме того, эта защита работает и от «конкурентов» — других троянцев, которые получают права root и устанавливаются в системный раздел, поскольку они работают по тому же принципу, что и «хорошие» приложения для получения прав root.
Как бороться с таким троянцем?
Чтобы избавиться от Android.Xiny.5260, устройство можно перепрошить – при условии, что в открытом доступе существует прошивка для него. Но можно ли удалить вредоносную программу другим способом? Сложно, но можно – есть несколько путей. Для получения прав root можно использовать эксплойты в виде so-библиотек. В отличие от исполняемых файлов, их загрузку троянец не заблокирует. Также можно воспользоваться компонентом самого троянца, который предназначен для предоставления root-прав другим его частям. Он получает команды через сокет по пути /dev/socket/hs_linux_work201908091350 (в разных модификациях путь может отличаться). Что касается обхода блокировки mount, можно использовать «волшебное» значение параметра mountflags, либо напрямую вызвать соответствующий syscall.
Реализовывать я это, конечно, не буду.
Если ваше устройство подхватит такого троянца, мы рекомендуем использовать официальный образ операционной системы для его перепрошивки. Однако не забывайте, что при этом удалятся все пользовательские файлы и программы, поэтому заранее позаботьтесь о создании резервных копий.
Источник
Беспроводная отладка Android 11
Режим дебага по WiFi теперь доступен, начиная с версии ОС Android 11. Давайте разберемся, как подключить устройство по Wi-Fi и смотреть логи в Logcat.
Нам необходимо убедиться, что у нас имеется все необходимое для соединения, а именно:
- установлен компонент Android SDK Platform-Tools версии не ниже 30.0.0 (April 2020), но естественно необходимо поставить последнюю версию, в которой разработчики пофиксили существующие на данный момент баги;
- включенрежим разработчика на вашем устройстве;
- на устройстве версия ОС Android 11.
Переходим в режим разработчика на нашем устройстве и активируем «Отладку по Wi-Fi».
Далее необходимо выбрать раздел «Подключить устройство с помощью кода подключения».
В боттомшите отобразится сам код подключения к устройству и IP-адрес и порт.
Откроем Android Studio, перейдем во вкладку Terminal, далее введем и выполним команду adb pair ipaddr:port где ipaddr и port — данные из боттомшита «Подключение к устройству». Следующим шагом — вводим код подключения и получим push на устройство об успешном подключении.
Перейдем на вкладку Logcat и все, что нам осталось — выбрать наше устройстве из списка подключенных устройств, в конкретном примере это Samsung SM-N985F.
Источник
Декомпиляция и отладка Android-приложений
В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения.
В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения. Хорошая новость в том, что для отладки не требуются привилегии суперпользователя. Описанные техники могут быть очень кстати во время пентестов мобильных приложений, поскольку мы можем «проникнуть» в код во время работы программы, получить и записать информацию, к которой обычно у нас нет доступа. Например, можно перехватить трафик перед шифрованием и на лету получить ключи, пароли и любую другую ценную информацию. Статья будет полезна пентестерам и разработчикам мобильных приложений, желающих получить более глубокие знания о возможных атаках на платформе Android.
Требования к тестовой среде:
В статье будет использоваться следующая конфигурация: Windows 8, Android Studio и IntelliJ IDEA. Устройство: Nexus 4 с Android версии 4.4.4. Рекомендую все утилиты добавить в переменную окружения PATH, чтобы облегчить и ускорить доступ к этим инструментам.
Android application package (APK), используемый в статье, можно скачать отсюда: com.netspi.egruber.test.apk.
Инструкция ниже поможет вам подготовить устройство для экспериментов.
Активация раздела Developer Options
Для начала на Android-устройстве должна быть разрешена отладка через USB (опция USB debugging), что позволит «общаться» с девайсом при помощи инструментов из набора Android SDK. Однако перед этим необходимо активировать раздел Developer options. На устройстве зайдите в раздел Settings > About Phone и кликните несколько раз на пункт Build Number, после чего должно появиться сообщение о том, что раздел Developer options активирован.
Рисунок 1: Для того чтобы активировать раздел Developer options, необходимо несколько раз кликнуть на Build number
Разрешение отладки через USB
Чтобы разрешить отладку через USB-порт, зайдите в раздел Settings > Developer options и отметьте флажок напротив USB debugging.
Рисунок 2: Включение опции USB debugging
Подключение устройства и запуск ADB
После подключение устройства к компьютеру через USB-порт, должно появиться сообщение «USB debugging connected on the device». Также следует проверить, можно ли подключиться к устройству при помощи приложения Android Debug Bridge (ADB), входящего в состав Android SDK (пакет Android SDK Platform-tools). В командной строке введите следующую команду:
Устройство должно отобразиться в списке.
Рисунок 3: Список подключенных устройств
Если устройство не отобразилось в списке, то наиболее вероятная причина в некорректно установленных драйверах (в Windows). В зависимости от устройства драйвер можно найти либо в Android SDK, либо на сайте производителя.
Проверка приложения на возможность отладки
Перед отладкой Android-приложений вначале необходимо проверить, есть ли такая возможность. Проверку можно выполнить несколькими способами.
Первый способ – запустить Android Device Monitor, входящий в состав Android SDK (в папке tools). В Windows файл называется monitor.bat. При открытии Android Device Monitor устройство отобразится в разделе Devices.
Рисунок 4: Приложение Android Device Monitor
Если какое-либо приложение на устройстве можно отлаживать, это приложение также отобразится в списке. Я создал тестовую программу, но список пуст, поскольку программу отлаживать нельзя.
Второй способ проверить приложение на возможность отладки – исследовать файл AndroidManifest.xml из пакета приложения (APK, Android application package). APK представляет собой zip-архив, содержащий всю информацию, необходимую для запуска приложения на Android-устройстве.
Всякий раз, когда приложения загружается из Google Play Store, также загружается и пакет приложения. Все загруженные APK-файлы обычно хранятся на устройстве в папке /data/app. Если у вас нет прав суперпользователя, вы не сможете получить список файлов из директории /data/app. Хотя, если вы знаете имя APK-файла, можете скопировать его при помощи утилиты adb. Чтобы узнать имя APK-файла, введите следующую команду:
Появится командная строка устройства. Затем введите следующую команду:
pm list packages -f
Отобразится список всех пакетов на устройстве.
Рисунок 5: Перечень пакетов на устройстве
Глядя на список, находим тестовое приложение.
Рисунок 6: Пакет созданного тестового приложения (выделено белым)
Теперь необходимо скопировать файл пакета. Открываем шелл и вводим следующую команду:
adb pull /data/app/[.apk file] [location]
Рисунок 7: Копируем APK-файл с устройства в систему
Теперь нужно открыть файл пакета и исследовать содержимое AndroidManifest.xml. К сожалению, мы не можем просто так распаковать архив, поскольку APK-файл закодирован в бинарном формате. Для раскодировки чаще всего используется утилита apktool, хотя я использую APK Studio, поскольку у этого приложения дружелюбный графический интерфейс. Далее в статье будет рассказываться об APK Studio.
В APK Studio кликните на маленькую зеленую иконку, задайте имя проекту и укажите путь к APK файлу. Затем укажите пусть для сохранения проекта.
Рисунок 8: Создание нового проекта в APK Studio
После открытия APK выберите файл AndroidManifest.xml и посмотрите параметры тега application. Если флаг android:debuggable отсутствует (или присутствует, но установлено значение false), значит, приложение отлаживать нельзя.
Рисунок 9: Содержимое файла AndroidManifest.xml
Модификация файла AndroidManifest.xml
При помощи утилиты apktool или APK Studio мы можем модифицировать файлы и упаковывать содержимое обратно в пакет. Сейчас мы изменим файл AndroidManifest.xml так, чтобы приложение можно было отлаживать. Добавляем внутрь тега application строчку android:debuggable=»true».
Рисунок 10: Изменяем содержимое тега application
После добавления флага кликаем на иконку «молоток» и заново собираем пакет. Пересобранный пакет будет находиться в директории build/apk.
Рисунок 11: Повторная сборка пакета завершилась успешно
После пересборки пакет подписывается и его можно заново установить на устройстве (все Android-приложения должны быть подписаны). Большинство приложений не проверяет сертификат, при помощи которого происходит подпись. В противном случае необходимо изменить код, выполняющий эту проверку.
Теперь нужно установить пересобранный пакет. Вначале удаляем старое приложение при помощи следующей команды:
adb pm uninstall[package name]
Затем устанавливаем новый пакет:
adb install [.apk file]
Также можно удалить и установить пакет одной командой:
adb install -r [.apk file]
Рисунок 12: Установка пересобранного пакета
Проверьте, чтобы переустановленное приложение корректно запускалось на устройстве. Если все работает, переходим обратно в Android Device Monitor, где должно появиться тестовое приложение.
Рисунок 13: Теперь пересобранное приложение можно отлаживать
Настройка среды разработки (IDE)
Теперь к пересобранному приложению можно подцепить отладчик, но вначале нужно создать проект в среде разработки (в статье используется IntelliJ IDEA). Создаем новый проект. В поле Application name указываем произвольное имя. В поле Package name указываем имя, в точности совпадающее с иерархией папок пересобранного пакета.
Рисунок 14: Создание нового проекта в IntelliJ IDEA
Обычно имя APK-файла совпадает со структурой папок, хотя, если вы не уверены, в APK Studio проверьте иерархию директорий до папки, где находятся файлы приложений. В моем случае имя и структура папок полностью совпадают (com.netspi.egruber.test).
Рисунок 15: Иерархия директорий тестового приложения
Снимите флажок «Create Hello World Activity» и завершите создание проекта (все остальные параметры остаются по умолчанию). Новый проект должен выглядеть примерно так:
Рисунок 16: Иерархия папок и файлов нового проекта
После создания проекта нужно добавить исходный код из APK-файла для того, чтобы отладчик «знал» имена символов, методов, переменных и т. д. Хорошая новость в том, что Android-приложения можно декомпилировать практически без потери качества (исходный код будет совпадать с оригиналом). После декомпиляции исходный текст импортируется в среду разработки (IDE).
Получение исходных текстов из пакета приложения
Для начала необходимо преобразовать APK в jar-файл. Затем мы при помощи java-декомпилятора получим исходный текст приложения. Преобразование в jar будем делать при помощи утилиты dex2jar. У dex2jar есть файл d2j-dex2jar.bat, используемый для конвертирования APK в jar. Синтаксис команды довольно прост:
d2j-dex2jar.bat [.apk file]
Рисунок 17: Преобразование APK в jar
Затем открываем или перетаскиваем полученный файл в JD-GUI (это java-декомпилятор).
Рисунок 18: Структура jar-файла
Jar-файл должен отобразиться в виде иерархической структуры, внутри которой находятся java-файлы с читабельным исходным кодом. Заходим в File > Save All Sources, чтобы упаковать все исходные тексты в zip-архив.
Рисунок 19: Сохранение исходных текстов декомпилированного файла
После сохранения исходных текстов распаковываем архив в отдельную директорию.
Рисунок 20: Распакованный архив
Теперь нужно импортировать обе директории в созданный ранее проект в IDE. В IntelliJ заходим в папку src и копируем туда содержимое распакованного архива (две директории).
Рисунок 21: Обе папки скопированы в директорию src
Возвращаясь в Intellij, видим обновленный проект.
Рисунок 22: В проекте появились исходные тексты
Если мы кликнем на какой-нибудь элемент из списка, то увидим исходный текст. Как видно на скриншоте ниже (исходный текст класса LoginActivity), исходный код обфусцирован при помощи ProGuard.
Рисунок 23: Обфусцированный исходный текст класса LoginActivity
Теперь, когда в проекте появились исходные тексты, мы можем начать устанавливать точки останова на методах и переменных. По достижению точек останова приложение будет останавливаться. В качестве примера я установил точку останова на методе (прямо в обфусцированном коде), отвечающим за обработку информации, введенной в текстовом поле.
Рисунок 24: Поставлена точка останова на обфусцированный метод
Как только появилась точка останова, подключаем отладчик к процессу на устройстве, кликнув на иконку с экраном в правом верхнем углу (на вашей IDE иконка может отличаться).
Рисунок 25: Подключаем отладчик к процессу
Далее вам будет предложено выбрать процесс, к которому нужно подключиться. Будут отображены только процессы с флагом android:debuggable=»true».
Рисунок 26: Перечень процессов для подключения отладчика
После выбора процесса отладчик подсоединится к устройству.
Рисунок 27: Отладчик подключен к процессу, запущенному на устройстве
В текстовое поле я буду вводить число 42 (если помните, на соответствующем методе стоит точка останова).
Рисунок 28: В текстовое поле вводим число 42
После нажатия на кнопку «Enter Code» выполнение приложения прервется на точке останова, поскольку отладчик «осведомлен», какой метод вызывается на устройстве. Скомпилированное Android-приложение содержит отладочную информацию (например, имена переменных), доступную любому отладчику, совместимому с Java Debug Wire Protocol (JDWP). Если в приложении разрешена отладка, отладчик, совместимый с JDWP (в эту категорию попадает большинство отладчиков идущих в составе сред разработки для Java), сможет подсоединиться к виртуальной машине Android-приложения, а затем считывать и выполнять отладочные команды.
Рисунок 29: Сработала точка останова
На скриншоте ниже видно число, которое ранее мы ввели в текстовом поле.
Рисунок 30: Перечень переменных текущего экземпляра класса
Мы можем не только считывать данные в приложении, но и вставлять свои собственные. Это может быть полезно, если мы, например, захотим прервать поток выполнения кода и обойти некоторые участки алгоритма. При помощи отладчика мы можем лучше понять логику работы приложения и проанализировать то, что недоступно обычному пользователю. Например, может оказаться очень полезным просмотр используемых функций шифрования и динамические ключи. Кроме того, иногда при отладке полезно знать, как функции взаимодействуют с файловой системой или базой данных, чтобы понять какая информация сохраняется приложением. Подобные манипуляции доступны на любом Android-устройстве без привилегий суперпользователя.
Источник
