Контролируемое заражение. Используем DroidBox для динамического анализа малвари

Введение

Как ты, ско­рее все­го, зна­ешь, сущес­тву­ет два метода ана­лиза при­ложе­ний: ста­тичес­кий и динами­чес­кий. Пер­вый вклю­чает в себя дизас­сем­бли­рова­ние, деком­пиляцию, иссле­дова­ние манифес­та при­ложе­ния. Вто­рой пред­полага­ет запуск при­ложе­ния в спе­циаль­ном окру­жении, поз­воля­ющем про­извести ана­лиз его поведе­ния в так ска­зать реаль­ных усло­виях. На прак­тике, как пра­вило, при­меня­ются оба метода, при­том одновре­мен­но. Но так как ста­тичес­кий метод ана­лиза мы уже рас­смат­ривали (статья «Ана­томия с пре­пара­цией», № 170), в этой статье скон­цен­три­руем­ся на динами­чес­ком.

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

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

DroidBox

DroidBox сос­тоит из двух час­тей, которые условно мож­но наз­вать Host и Target. Target-часть, запус­каемая на эму­лято­ре, пред­став­ляет собой сбор­ку Android 4.1.2 с набором пат­чей, боль­шая часть из которых взя­та из TaintDroid без изме­нений. Пат­чи добав­ляют некото­рые фун­кции для отсле­жива­ния дан­ных на низ­ком уров­не.

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

DroidBox рас­простра­няет­ся как в исходных тек­стах, так и в виде готовых бинар­ников (при этом, разуме­ется, нуж­но иметь Android SDK и соот­ветс­твен­но задан­ную перемен­ную $PATH, куда нуж­но добавить пути к катало­гам tools и platform-tools). Пос­коль­ку он доволь­но дав­но не обновлял­ся, име­ет смысл не мучить­ся со сбор­кой из репози­тория, а взять уже готовый. Перед этим нуж­но пос­тавить некото­рые пакеты:

И ска­чать собс­твен­но DroidBox:

По неиз­вес­тным мне при­чинам основной скрипт DroidBox в архи­ве не генери­рует гра­фики, а ста­рый скрипт, который находит­ся в SVN-репози­тории в катало­ге external, не работа­ет, поэто­му мне приш­лось изме­нять код текуще­го скрип­та, слег­ка испра­вив его и выдер­нув из ста­рого скрип­та нуж­ные час­ти. Мою модифи­кацию скрип­та ты най­дешь на DVD.

За­тем соз­даем AVD (Nexus 4 с Android 4.1.2 на бор­ту) и запус­каем его с помощью скрип­та, находя­щего­ся в све­жерас­пакован­ном катало­ге:

В качес­тве парамет­ра скрипт при­нима­ет имя све­жесоз­данно­го AVD, при этом в конеч­ном сче­те запус­кая не ори­гиналь­ный System image, а тот, который идет в ком­плек­те с DroidBox. Сле­дом нуж­но под­сунуть в эму­лятор при­ложе­ние, которое мы хотим ана­лизи­ровать. В качес­тве подопыт­ных я выб­рал нес­коль­ко сем­плов мал­вари, а имен­но Simplocker, Fakemart, один из бан­ков­ских тро­янов и нашумев­ший Android.OBad.a.

Simplocker

Это отно­ситель­но недав­ний злов­ред, написан­ный по заветам вин­локеров. Пос­ле запус­ка он обви­нит тебя в нек­ропедо­зоофи­лии, зашиф­рует все изоб­ражения, видео и докумен­ты на кар­те памяти и пот­ребу­ет опла­тить их рас­шифров­ку.

За­пус­каем семпл:

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

В ито­ге получа­ем три фай­ла: диаг­рамму обще­го рас­пре­деле­ния опе­раций, гра­фик их рас­пре­деле­ния по вре­мени и собс­твен­но трас­сиров­ку. Име­на пер­вых двух фай­лов сос­тоят из пре­фик­са (tree- для диаг­раммы, behaviorgraph- для гра­фика по вре­мени и trace- для трас­сиров­ки), име­ни пакета, даты и вре­мени. В моем слу­чае имя фай­ла трей­са для Simplocker выг­лядело как trace-org.simplelocker-20141008-1635.png.

Те­перь смот­рим. На гра­фике по вре­мени (см. скрин­шот) пер­вые мгно­вения у нас идет заг­рузка DEX-фай­ла, затем запуск сер­виса и опе­рация с крип­тоAPI Android (судя по все­му, еди­нич­ная), а затем прак­тичес­ки неп­рерыв­но идет поток фай­ловых опе­раций, по срав­нению с которым гре­бешок сетевых опе­раций (net read, net open) кажет­ся ред­ким. Дей­ствия же поль­зовате­ля на эту диаг­рамму не вли­яют.

Другие статьи в выпуске:

Хакер #191. Анализ безопасности паркоматов

• Содержание выпуска
• Подписка на «Хакер»-60%

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

На 0,9 секун­де было исполь­зовано неч­то из крип­тоAPI, ско­рее все­го свя­зан­ное с генера­цией клю­ча, — об этом нам говорит сек­ция CryptoUsage. Там же ука­зан и алго­ритм (AES), и сам ключ (та‑дам!).

Сек­ция dataleaks пус­та — зна­чит, уте­чек сен­ситив­ных дан­ных (IMEI), по всей веро­ятности, не было:

В сек­ции fdaccess мы видим, что при­ложе­ние пос­тоян­но откры­вает, чита­ет и пишет фай­лы, выпол­няя шиф­рование... Но мы видим еще и запись в файл /data/data/org.simplelocker/app_bin/torrctether.

Пре­обра­зуем стро­ку с шес­тнад­цатерич­ными дан­ными (в лис­тинге вмес­то нее "<...>") в ASCII и видим кусок кон­фига Tor. Чуть ниже, на 1,41 секун­де, будет запись в файл /data/data/org.simplelocker/app_bin/privoxy.config. Сно­ва пре­обра­зуем стро­ку... это начало кон­фига Privoxy. Даль­ше у нас ничего инте­рес­ного не будет, поэто­му перей­дем к сетевым опе­раци­ям (ибо сек­ция phonecalls пус­та).

При­ложе­ние ожи­дает дан­ных с пор­та 9051, который явля­ется управля­ющим пор­том Tor (раз­раб явно позабо­тил­ся о сво­ей кон­фиден­циаль­нос­ти). Дан­ные, кста­ти, тек­сто­вые, так что стро­ку мож­но опять же перекон­верти­ровать в ASCII. А отправ­ляет оно дан­ные на тот же порт — зада­ет парамет­ры Tor-соеди­нения.

Мал­варь реаги­рует толь­ко на два интента ("ACTION_EXTERNAL_APPLICATIONS_AVAILABLE" и "BOOT_COMPLETED") и запус­кает служ­бу — но это дос­таточ­но лег­ко узнать и без исполь­зования DroidBox, обыч­ным ста­тичес­ким ана­лизом.

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

Fakemart

Сле­дующим злов­редом будет Fakemart — при­ложе­ние, мас­киру­ющееся под магазин при­ложе­ний и рас­сыла­ющее плат­ные SMS. Запус­каем его и изоб­ража­ем обыч­ного поль­зовате­ля, ожи­дая заг­рузки чего‑то — веро­ятно, «репози­тория». «Заг­рузка», понят­ное дело, до кон­ца не про­ходит — видимо, с рас­четом на то, что его опять запус­тят. Пос­ле нес­коль­ких попыток (мы ведь обыч­ные поль­зовате­ли, прав­да?) оста­нав­лива­ем трас­сиров­ку и смот­рим, что у нас выш­ло.

Гра­фик по вре­мени показы­вает, что в пер­вые мгно­вения была отправ­лена SMS, затем была запись в файл, затем нес­коль­ко сетевых опе­раций, затем сно­ва мно­го записей в файл.

Ди­аграмма рас­пре­деле­ния показы­вает, что да, боль­шую часть опе­раций занима­ет запись в файл, затем идут сетевые опе­рации, а уже потом — доволь­но тол­стый (если срав­нивать с опе­раци­ей заг­рузки клас­сов, DEXLOAD) стол­бик отправ­ки SMS.

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

В файл /data/data/com.android.blackmarket/shared_prefs/XMBPSP.xml зачем‑то записы­вает­ся номер, на который, как мы выяс­ним поз­же, про­исхо­дит отправ­ка SMS. Боль­ше это при­ложе­ние ни в какие фай­лы не пишет.

Се­тевые опе­рации — попыт­ка открыть соеди­нение с опре­делен­ным адре­сом по 80-му пор­ту и затем попыт­ки при­нимать и отправ­лять дан­ные. Впро­чем, сер­вер отве­чает Forbidden, что и неуди­витель­но.

От­прав­ка SMS про­изош­ла три раза, каж­дый раз при попыт­ке запус­ка при­ложе­ния.

Вы­воды: сек­ция "sendsms" крас­норечи­во показы­вает, с чем мы стол­кну­лись. Ни один мар­кет не будет отправ­лять SMS на корот­кие номера, тем более нес­коль­ко раз. DroidBox выдал SMS-тро­яна с пот­рохами. Инте­рес­но, кста­ти, что раз­рабы явно соз­дали защиту от бло­киров­ки плат­ных номеров: опе­рации обме­на дан­ными с сер­вером и записи в файл — это, оче­вид­но, попыт­ка обновле­ния плат­ного номера.

iBanking

А это уже бан­ков­ский тро­ян. Один из его вари­антов, который мы раз­берем, мас­киру­ется под анти­вирус. Пос­ле уста­нов­ки он зап­рашива­ет пра­ва адми­нис­тра­тора устрой­ства.

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

В трей­се же вид­на утеч­ка ICCID. И там же ука­зан спо­соб утеч­ки — SMS. По сети пос­тоян­но совер­шают­ся попыт­ки отпра­вить зап­рос POST.

И это все. Нес­мотря на то что iBanking — один из самых фун­кци­ональ­ных тро­янов для Android, DroidBox поч­ти ничего не смог нам о нем рас­ска­зать. При­чина это­му прос­та: злов­ред ожи­дает команд от сер­вера, и, если их нет, он прос­то спит. Для иссле­дова­ния подоб­ного соф­та при­дет­ся исполь­зовать ста­тичес­кий ана­лиз с его километ­ровыми лис­тинга­ми smali, деоб­фуска­цией и про­чими при­ятностя­ми.

Заключение

В целом DroidBox весь­ма удо­бен, но выг­лядит край­не сыро. Работа­ет толь­ко с опре­делен­ной вер­сией Android (даже мень­ше — толь­ко на эму­лято­ре) и под­держи­вает исклю­читель­но Java API, так что сме­шан­ный код ему под­совывать смыс­ла не име­ет. Сто­ит толь­ко при­ложе­нию обра­тить­ся через JNI к биб­лиоте­кам или, тем паче, к сис­темным вызовам, как оно сра­зу же выходит из поля зре­ния.

Кро­ме того, DroidBox отлавли­вает далеко не все воз­можные дей­ствия и перева­рива­ет не всех злов­редов. Нап­ример, тот самый Android.OBad.a при­ложе­ние отка­залось ана­лизи­ровать, выдав ошиб­ку «Failed to analyze the APK. Terminate the analysis». DroidBox не вно­сит изме­нения в сам эму­лятор, так что при­ложе­ние впол­не спо­соб­но опре­делить, что оно работа­ет под кол­паком. Спо­собов для это­го дос­таточ­но — начиная от баналь­ного ICCID и номера телефо­на до хит­ровывер­нутых инс­трук­ций ARM-ассем­бле­ра.