R0 CREW

RootSmart Android Malware

Оригинал: resources.infosecinstitute.com
Уровень: Ниже среднего (прим. пер. весьма желательны экстрасенсорные навыки)

Intro

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

Недавно до меня дошли сведения, что еще одна вредоносная программа использовала известный эксплойт GingerBreak для получения привилегий суперпользователя на зараженных телефонах. От людей, которые первыми ее обнаружили, эта малварь получила имя RootSmart. Это второе приложение, найденное в дикой природе, которое использует данный эксплойт. Первым приложением был GingerMaster обнаруженный в конце августа 2011 года.

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

Давайте, исследуем его.

Сведения о приложении

Сэмпл, который я смог найти имеет следующие параметры:

  • Файл: com.google.android.smart.apk
  • Размер: 314.445 байт
  • MD5: F70664BB0D45665E79BA9113C5E4D0F4
  • SHA1: 67CF01EE7FF0E65CB7EC78CDBD274077153ADD4E

На момент написания статьи, уровень обнаружения на VirusTotal был 8/43 (идентифицирован как Android.RootSmart или Android.BMaster)

Анализ манифеста

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

Прежде всего, нам нужно распаковать .apk и преобразовать бинарный XML-файл манифеста в текстовый. Для этого воспользуемся очень удобным инструментом android-apktool.

Введите следующую команду:

java –jar apktool.jar d <.apk name> <destination dir> 

После обработки, файла манифеста, можно найти в указанной папке (destination directory) вместе с полным дизассемблерным представлением приложения в файле .dex. Мы рассмотрим этот файл немного позже, сейчас же давайте сосредоточимся на манифесте:

Можно видеть, что приложение требует много прав доступа; уже это должно предупреждать пользователя, что что-то не так. Некоторые из этих прав требуют поставщиков снихронизации (WRITE_SYNC_SETTINGS, GET_ACCOUNTS, etc…), а некторые еще более интересные вещи.

Этот пакет хочет получить доступ к Интернету, вероятно, даже включает на прямую Wi-Fi (CHANGE_WIFI_STATE). Пакет также интересуется нашим точным местоположением (ACCESS_FINE_LOCATION), но что должно сразу привлечь наше внимание, так это следющие два разрешения: MOUNT_UNMOUNT_FILESYSTEMS и READ_LOGS. Приложение просто кричит: «Эй, я хочу запустить GingerBreak!». Эксплойту необходим доступ к файлу логов для того, чтобы иметь возможность получить адрес, где vold crashed, этот же адрес будет использован позже для перезаписи GOT. Кроме того видно, что требуется разрешение RECEIVE_BOOT_COMPLETED, которое нужно для загрузочных сервисов (boot service), готовых к запуску каждый раз, когда мы включаем наш телефон.

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

  • .WcbakeLockReceivecr – вызывается, когда пользователь начинает взаимодействовать с телефоном.
  • .BcbootReceivecr – вызывается, когда телефон загружается (boots).
  • .ScbhutdownReceivecr – вызывается, когда телеофн выключается (shut down).
  • .PcbackageAddedReceivecr – вызывается, когда мы устанавливаем новое приложение.
  • .LcbiveReceivecr – вызывается, когда мы перезагружаем (reboot) телефон или делаем новый телефонный звонок.

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

Установка

Запустите ваш эмулятор и установите приложение. По сути, сущестует два способа установки приложения. Первый способ – спомощью прямой устновки, используя ADB:

adb install suspect.apk

Второй способ – загрузка и установка пакета, тем же образом, как вы бы зделали с любым другим приложением. Используя этот способ у нас будет возможностить напрямую проверить требуемые разрешения:

Уже только глядя на это – стоит бить в колокола: примерно такие разрешения требуются приложению. Также обратите внимание на то, что оно использует такуюже иконку «Настроек» («Setting»), котора поставляется вместе с подлинным приложением (прим. пер. какое именно имеется ввиду «подлинное приложение» автор видимо забыл упомянуть… Скорее всего он имел ввиду это Quick Settings). Основное отличие заключается в том, что его имя будет на Китайском языке. Ничего неправильного в этом нет, это вредоносное приложение, по сути, предназначено для Китайского рынка.

Попытка открыить приложение приведет в результате к открытию следующего окна из подлинного приложения:

Основная программа, безусловно, является легальной, но она переупакована вместе с вредоносным сервисом загрузки (boot service). Мы знаем, что нет «оффициального» способа для запуска сервиса загрузки (boot service) сразу после его установки, поэтому программа должна «перехватить» («hook») некоторые события, чтобы иметь возможность запуститься. Первым событием будет BOOT_COMPLETED. Мы можем видеть из манифеста, что это действие управляется из скласса com.google.android.smart.BcbootReceivecr. На данный момент, у нас есть достаточно элементов, чтобы иметь возможность начать наш анализ кода.

Анализ кода

Нам нужно дизассемблировать приложение для того, чтобы иметь возможность проанализровать ее код. Для этой задачи мы воспользуемся следующими тремя инструментами: dex2jar, JD-GUI и Baksmali. Первый инструмент используется для преобразования .dex файла в .jar пакет, второй является декомпилятором, который используется для восстановления исходного кода Java, третий является дизассемблером, который может преобразовать .dex файл в понятный человеку вид, представляющий собой код Dalvik. Если вы удевлены, почему мы должны использовать дизассемблер, когда у нас есть полнофункциональный декомпилятор, то вот вам ответ: JD-GUI действительно удобен, но к сожалению он все еще находится на стадии разработки. По этой причине его все еще можно легко обмануть (случаной или нарочно) так, что мы не сможем использоваться его для полного и всестороннего анализа.

Первый шаг: преобразование .apk в .jar пакет:

dex2jar suspect.apk

Второй шаг: откройте его с помощью JD-GUI:

Теперь очевидно, что мы имеем дело с тремя пакетами: малварь com.google.android.smart, легитимное приложение com.bwx.bequick (в Android Markete его называют QuickSettings) и другой пакет, просто называнный a (наиболее вероят, что эта импортируемая библиотека используется для управления SOAP запросами).

Давайте, исследуем класс, который имеет дело с событием BOOT_COMPLETED. К счастью для нас, эта чать была правильно декомпилированна:

Пакет проверяет, находится ли приложение в «спящем» состоянии. Если это не так, то запускает службу (service) из McbainServicce.class, продолжая следить за setAction() и затем перемещается в класс, который управляет созданием и уничтожением службы.

Что тут происходит?

По порядку:

  • Общая пременная (Shared Preference) «last_check_live_time» инициализируется текущим временем.
  • Проверяется флаг «hibernated» и если он существует (true) приложение прекращает работу.
  • Если флаг «firs_strat_time» инициализирован, тогда приложение начинает парсить действия (action)

Настройки (Preferences) хранятся в двух XML-файлах: mms_localinfo.xml и mms_settings.xml. Все они представлены в текстовом виде и могут быть легко получены. Action, посланное классу «action manager», выполняет следующий код:

Имена обфусцированны, но это не так уж плохо. В конце концов, бессмысленные имена лучше, чем имена, вводящие в заблуждение. Таким образом, код говорит нам, что установлен сигнал (alarm), сработывающий через 1-ну минуту, спустя которую будет передан новый action “action.check_live”.

Среди других интересных вещей можно выделить проверку версии OS, которая должна равняться «2.3.4», за которой следует проверка на существование файла shells. Но зачем? Очевидно, что запускается эсклойт, покрайней мере, исходя из имени, оставленного в коде. Класс f устанавливает права доступа на файл, выполняет его с помощью McbainServicce.class Boolean a(String), после чего осуществялет очистку.

Умно. Таким образом, малварь может установить свою оболочку (shell) в системе, а также использовать рут-доступ (root access) для тихой устновки других пакетов. До сих пор у нас небыло следов указывающих на то, что эксплойт встроен в пакет малвари, поэтому мы приходим к выводу, что эксплойт загружается с какого-то сервера.

Откуда именно? Нам нужно вернуться назад, туда, где приложение проверяет наличие файла «shells». Если этот файл не найден, то вызывается метод i.(this.a).a(), но его исследование, используя JD-GUI, не представляется возможным, поскольку он не поддается декомпиляции.

Но это нас не остановит: давайте просто дизассемблируем пакет используя Baksmali. Откройте пакет .apk с помощью любого архиватора (прим. пер. например, с помощью WinRar) и извлеките файл classes.dex. Затем выполните следущую команду:

java –jar –a 8 classes.dex –o baksmalied

Теперь мы можем открыть файл i.smali, чтобы понять, как работае метод a(). Вот дизассемблированная часть этого файла:

Если грубо, то это можно перевести так: проверить существование файла «shells», если вы не можете найти его, то создать URL следующим образом:

String url = "/androidService/" + "resources/commons/shells.zip"

Это не полный URL. У нас не хватает адреса, верно? Адрес экстраполируется из следующего ресурса: res/raw/data_3. Его бинарное содержимое представлено ниже:

ED04FB6CD722B63EF117E92215337BC7358FB64F4166F4EC40C40D21E92F9036

Очевидно, что это не текстовый URL, и действительно, мы правы, это зашифрованный текст, который расшифровывается в методе String s.a().

Мы все любим опкоды Dalvik, не так ли? Не совсем, но в этот раз у нас нет выхода, JD-GUI не помог нам, поэтому, если у нас есть серое вещество, то мы воспользуемся несколькими приемами старой школы для декомпиляции. Оригинальный байт-код выглядит следующим образом:

После тщятельного анализа каждой строки, мы сможем восстановить исходный код:

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

Следует сказать несколько слов об этой части кода: мы должны получить эксплойт с веб-сервера, но его URL, к сожалению, не нахоидтся в чистом виде. Есть защифрованный файл ресурсов. Ключ шифрования не задан жестко. Он генерируется во время выполнения… Как? Псевдо-генератор случайных чисел, на основе SHA1, инициализриется, используя начальное число, хранящееся в манифесте. Вы можете видеть его ниже:

Из дизассемблера ясно, что «packet_id» используется для загрузки в PRNG. Вывод которой используется для инициализации 128-битного ключа, используемого шифром AES и в конечном счете используется для расшифровки URL, который в итоге оказвается «go.docrui.com». В итоге получаем полный URL:

http://go.docrui.com/androidService/resources/commons/shells.zip

Это был умных ход со стороны авторов малвари. С помощью этого фокуса они сделали реверсинг приложения немного сложенее. После того, как файл был получен с помощью класса v, который обрабатывает все стандартные HTTP-запросы, его MD5-хэш проверяется внутри i.a().

const-string v3, "6bb75a2ec3e547cc5d2848dad213f6d3"

После получения и проверки файла, тот же самый пакет распаковывает его с помощью метода s.a(String, String). Пакет содержит три файла:

  • exploit: скомпилированный GingerBreak, проверьте его с помощью любого hex-редактора.
  • install: используется для установки оболочки
  • installapp: используется to copy around a suid root file

В то время как GingerBreak хорошо известен и документирован, интересно взглянуть на скрипты. Начнем с install:

В начале, этот скрипт используется для перемонтирования файловой системы в режиме чтения-запси, а затем для создания новой директории «/system/xbin/smart». Внутри новой директории создается root shell. Затем файловая система перемонтируется в read-only. Скрипт installapp выглядит следующим образом:

Это вспомогательный скрипт, который может записать файл, в любое желаемое место, и предоставить ему режим «+s». Этот же процесс выполняется не только тогда, когда телефон загружается, но даже после осуществления телефонного звонка. Малварь использует эту технику, чтобы иметь еще одину возможность для запуска, прежде чем пользователь перезагрузит телефон.

Цепочка действий

RootSmart может обрабатывать различные actions, отправляемые C&C сервером. Каковы его возможности? Давайте сделаем краткий обзор всех возможных команд:

  • action.host_start: помечает малварь как работающую
  • action.boot: устанавливает 60-секундный таймер (alarm), который проверяет был ли телефон взломан (exploited)
  • action.shutdown: устанавливает время через которое будет запущен бэкдор (если телефон был взломан)
  • action.screen_off: проверяет состояние питания, keeping the device on when needed
  • action.install: загружает и устанавливает эксплойт и root shell
  • action.installed: извлекает информацию о телефоне и завершает установку, установкой бэкдора.
  • action.check_live: планирует почасовую само проверку и определяет версию OS.
  • action.download_shells: загружает пакет содержащий shell из удаленного сервера.
  • action.exploid: распаковывает файл содержащий shell, выполняет эксплойт, проверяет результат (sets the result) и делает очистку.
  • action.first_commit_localinfo: устанавливает флаг местного времени во время первого соединения с удаленным сервером.
  • action.second_commit_localinfo: как и выше, только устанавливает некоторые другие внутренние флаги.
  • action.load_taskinfo: получает IMEI телефона и извлекает информацию о пакетах
  • action.download_apk: загружает требуемый apk и устанавливает его (тихо, если есть root-права)

Управление каждым действием (actions) осуществляется из основного класса McbainServicce. Плюс ко всему, каждое действие запускается в новом потоке. А как насчет других receivers, которых мы извлекли из манифеста? Давайте кратко рассмотрим их:

  • .McbainServicce: управляет действиями (actions), это класс ядра малвари.
  • .WcbakeLockReceivecr: активируется, когда пользователь активен, посылает action.install
  • .BcbootReceivecr: посылает action.boot менеджеру действий (action manager), когда телефон загрузился (booted).
  • .ScbhutdownReceivecr: вызывается, когда мы выключаем (shut down) телефон, чтобы отключить бэкдор.
  • .PcbackageAddedReceivecr: мониторит установку новых приложений.
  • .LcbiveReceivecr: вызывается в разных ситуациях, запускает бэксдор, если он еще не запущен.

Еще несколько классов используются для управления запросами веб-сервера или установкой пакетов. Если вам будут интересны технические детали, то я дам вам несколько наводок:

  • x.class: управляет всеми настройками и флагами, которые использует бэкдор
  • e.class: управляет и создает «custom» заголовки для запросов к C&C
  • l.class e.class c.class: управляет установкой нового .apk
  • v.class: управляет запросами полученными от сервера

Сетевой трафик

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

И хотя никто не любит SOAP, нам придется иметь с ним дело. Первый запрос является своего рода идентификационным пакетом, который отправляет удаленному серверу следующую информацию: IMEI, IMSI, OS Version, CID, LAC, MNC (информация сотовой вышки), rooting status и некоторую информацию о самой малвари – включая ее версию, что может говорить о том, что пакет может быть удаленно обновлен. Всей этой информацией владеет класс g():

[INDENT]Любобытное примечание: проверьте User-Agent используемый для отправки запросов.[/INDENT]

Ответ сервера:

На этой стадии бэкдор будет соеденен с сервером, на постоянной основе, для приема команд.

Из исследованных возможностей, проанализированных во время анализа, мы знаем, что приложение может загружать и устанавливать дополнительные вредоносные пакеты. Если хотите, то вы можете продолжить мониторить трафик до тех пор, пока сервер передает какие-либо действия (action).

Из того, что я видел, была загрузка DroidLive, но все это зависит от настроек, установленных на серверах владальцев C&C. Одна подсказка: попробуйте подключиться, используя Китайские прокси. Иностранные телефоны, похоже, не особо привлекают внимание со стороны серверов. И это имеет смысл, если малварь, загруженная после первого запуска, осуществляет премиум SMS-расслку на Китайские номера.

Заключение

Код, во многих частях, похож на код Android DroidLive, за исключением того факта, что большая часть функций отсутствует. Наиболее вероятно, что это приложение является урезанной версией DroidLive с возможностями для проведения взлома (exploiting), и которое исплользуется в качестве лоадера для загрузки другого вредоносного программного обеспечения. На данный момент, ботнет за которым стоит RootSmart является довольно большым. Согласно данным Symantec насчитывается около 10-30 тыс. активных устройств.

Таким образом, мой вам совет, всегда обращайте внимание на то, что вы загружаете и всегда используйте официальный market (хотя и официальный маркет не всегда является безопасным), будьте осторожны с запрашиваемыми правами доступа и если возможно, обновляйте программное обеспечение вашего телефона, и… Не надо рутать телефон :wink:

© Translated by Prosper-H from r0 Crew

Статья хороша, также есть вопрос по андроиду,
какие вы знаете атаки и уязвимости под эту платформу(нужны конкретные примеры, а не теория аля опасность ssl)? Если скинете материал*на любом языке буду благодарен, пока находил только аналитические статьи про общие и несерьезную уязвимость с куки в хроме.

Этих уязвимостей вообще пшик, я не оговорю уже о каких-то публикациях (по крайней мере я не видел), например:

http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/Google-Android.html
http://web.nvd.nist.gov/view/vuln/search-results?page_num=0&cves=true&query=android&uscert_ta=true&uscert_vn=true&oval_query=true&adv_search=false

Да и в принципе-то не понятно, что ты с ними делать собираешься? Тут даже если зиро-дэй найти, например, в браузере, не ясно как из него, что-то выжать, так как ты будешь, как минимум, работать с ограниченными правами + выполняется все будет в песочнице aka виртуальной машине.

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

Если нет соответствующих прав, то запустить скачаный файл никто не даст. Это не Вантуз.

И к тому же тут не получиться как в Окнах брать и юзать сплойт (не 0day), потому что апдейты накатываются автоматом и профит от не зиро-дэев стремится к нулю.

root
Так в андроид манифесте указывается, какие права и на что разрешить и пользователю при установке показывается это, нажимая кнопку он соглашается с этим.

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

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

Я знаю, что в манифесте указываются права, но мы говорили про браузер, у которого прав на установку приложений (хз-откуда) вроде как нет? Или я что-то путаю? Отсюда следует, что если найти в нем уязвимость, то установить какое-то свое левое приложение (например, что-то типа лоадера) не получится. Про приложения, которые устанавливают сами пользователи тут речи не идет, с этим и так все ясно.

Я уже не помню. У меня сейчас стоит автомат.