CC BY
46
doi: 10.36724/2409-5419-2023-15-1-27-36
РАЗРАБОТКА АЛГОРИТМА ВЫЯВЛЕНИЯ ВРЕДОНОСНЫХ ПРОГРАММ ДЛЯ ПЛАТФОРМЫ ANDROID ПУТЕМ ПРОВЕДЕНИЯ АНАЛИЗА ФАЙЛА МАНИФЕСТА
БАИРАШНЫИ
Алексей Олегович1
БОЛЬШАКОВ
Александр Сергеевич2
АННОТАЦИЯ
Введение: Введение: имеющиеся алгоритмы выявления вредоносного программного обеспечения могут недостаточно эффективно обнаруживать модифицированные виды вирусов в приложениях смартфонов. В связи с этим рассмотрены вопросы, связанные с использованием анализа файла манифеста приложения операционной системы Android. Предложено проведение комплексного анализа кода и манифеста мобильного приложения с целью формирования атрибутов вредоносного программного обеспечения и создания алгоритмов выявления для операционной системы Android. Цель исследования: показать актуальность реверс-инжиниринга и разработать алгоритм эвристического анализа, позволяющий обнаруживать наличие скрытого вредоносного кода в мобильных приложениях посредством анализа метаданных кода манифеста приложения. Методы: в статье использован метод реверс-инжиниринга на примере актуальных троянов для формирования атрибутов, характеризующих возможность наличия скрытого вредоносного кода в мобильном приложении. Предложенный алгоритм обеспечивает принятие совокупного решения о возможности наличия скрытой вредоносной нагрузки с учетом рангов и логических значений анализируемых атрибутов. Результаты: предложенный подход протестирован с использованием базы данных VirusTotal для оценки ошибок первого и второго рода и показал 78% эффективность по выявлению вредоносного программного обеспечения по метаданным кода манифеста с использованием предложенных атрибутов, не требует сложных вычислений и трудоемких затрат и может быть основанием использования искусственного интеллекта в сочетании с проведением статического и динамического анализа для выявления вирусов операционной системы Android. Практическая значимость: разработанный алгоритм может быть использован в виде дополнительного элемента в комплексной системе антивирусной защиты смартфона от заражения вредоносом.
Сведения об авторах:
1 бакалавр МТУСИ, Москва, Россия, [email protected]
2 к.т.н., доцент кафедры ИБ МТУСИ, КЛЮЧЕВЫЕ СЛОВА: манифест приложения; антивирусная защита; информационная Москва, Россия, [email protected] безопасность; вредоносное ПО; Android-Banking.
Для цитирования: Байрашный А.О., Большаков А.С. Разработка алгоритма выявления вредоносных программ для платформы Android путем проведения анализа файла манифеста // Наукоемкие технологии в космических исследованиях Земли. 2023. Т. 15. № 1. С. 27-36. doi: 10.36724/2409-5419-2023-15-1-27-36
Введение
Вредоносное программное обеспечение (ВПО или вредо-нос), нацеленное на пользователей устройств на базе операционной системы (ОС) Android, развивается быстрее многих других видов вирусного программного обеспечения, в основном из-за того, что исходный код этой платформы является открытым и устройства этой ОС пользуются наибольшей популярностью. При этом одним из источников распространения вредоносов такого типа является официальный магазин Play Маркет.
Функциональные особенности многих вредоносов для Android-банкинга позволяют осуществлять кражу банковских данных жертв с целью совершения несанкционированных покупок, а также перевода денежных средств на сторонние счета.
С каждым годом появляется огромное число новых вирусов, которым удаётся обходить автоматизированные средства защиты. И именно поэтому специалистам информационной безопасности так необходимо исследовать новые вирусы, чтобы улучшать алгоритмы выявления угроз. Под исследованием понимается реверс-инжиниринг вредоноса с целью получения кода ВПО для анализа его методов скрытия от антивирусов, нанесения ущерба или кражи информации.
Так, например, в феврале 2022 года специалисты Threat-Fabric обнаружили новый банковский троян для Android, который они назвали ХепотогрЬ-ом [1]. Он скрывался в общеизвестном магазине приложений Play market под видом приложения «Fast Cleaner», предназначенного для ускорения работы устройства и очистки лишних данных.
Произведя анализ кода, специалисты выявили его особенности, цели и методы. Однако это не было бы возможно без реверс-инжиниринга, так как вредоносная нагрузка зашифрована, а динамический анализ не даёт полной картины его возможностей, что обусловливает актуальность проведения реверс-инжиниринга.
В ряде статей [2, 3, 4, 5] было отмечено, что для автоматизированного обнаружения вирусов используется эвристический анализ кода, который представляется в виде решения задачи с использованием методов искусственного интеллекта, поэтому в данной статье была предпринята попытка сформировать атрибуты, которые бы легли в основу машинного обучения, и разработать соответствующий алгоритм, позволяющий выявлять наличие ВПО.
К сожалению, практика показывает [6, 7], что при скачивании мобильных приложений сигнатурный и поведенческий анализы не всегда позволяют определить наличие «полезной вредоносной» нагрузки. В связи с этим предложено использовать метод реверс-инжиниринга для формирования атрибутов, характеризующих возможность наличия скрытого вредоносного кода в мобильном приложении с целью идентификации вредоносности приложения.
Результаты диссертации (https://ugatu.su/assets/files /documents/dissov/07/2017/GavrilovGN/Dissert-GavrilovGN.pdf) показали высокую эффективность выявления вредоносов
(93%) с помощью нейронной сети, в то время как большинство антивирусов выявляли вредоносы с вероятностью обнаружения от 43% до 80%. В этой диссертации рассматривалось принятие решения нейросети по системным вызовам, манифесту и коду. Что позволяет сделать вывод о том, что эффективность данной нейронной сети может быть улучшена за счёт добавления новых атрибутов. Именно поэтому авторы статьи предлагают произвести реверс-инжиниринг вредоносов для формирования новых атрибутов и произвести тестирование их эффективности на разработанном алгоритме с их использованием.
В статье основной акцент при проведении реверс-инжиниринга смещён в сторону анализа манифеста (файл, в котором содержатся точки входа, метаданные и разрешения, запрашиваемые приложением) поскольку автоматизация его анализа - гораздо проще, чем автоматизация анализа обфусцирован-ного (запутанного) кода.
В данной работе авторы статьи предлагают использование реверс-инжиниринга на примере актуального по версии ThreatFabric [8] вредоноса Hydra для демонстрации структуры ВПО и формирования атрибутов, указывающих на признаки ВПО. С использованием данного вредоноса продемонстрировано практическое использование результатов реверс-инжиниринга в сочетании с разработанным эвристическим алгоритмом и исследована эффективность такого алгоритма, которая подтвердила актуальность применения реверс-инжиниринга.
1. Формирование атрибутов наличия ВПО
Поскольку вредоносы пытаются обойти проверки антивирусов, они зачастую прячут и шифруют вредоносную нагрузку от них. Поэтому проводят реверс-инжиниринг, чтобы понять каким образом они обходят проверки антивирусов и как улучшить выявление вредоносов.
1.1. Формированиеатрибута А
Проводя реверс инжиниринг самых активных вредоносов по версии ThreatFabric [8], была выявлена следующая закономерность: отсутствие имён классов, заявленных в манифесте, в открытой части кода, но присутствующих в скрытой части кода, содержащей вредоносную нагрузку. В статье выполнен поиск такой закономерности на примере банковского трояна Hydra.
Все файлы, полученные в результате реверс-инжиниринга вредоноса Hydra, были открыты в среде разработки IntelliJ Idea как проект для удобства анализа его кода. Алгоритм проведения анализа ВПО представлен на рисунке 1.
После открытия файла манифеста среда разработки при помощи статического анализа определила отсутствующие классы, которые она выделила красным цветом. Фрагмент манифеста после статического анализа показан на рисунке 2. Определить отсутствующие классы можно и вручную, проводя поиск каждого в коде, но это не рациональный путь.
«application android :aUo*8ockbji:'tNrt' android; icon:M(?hlpMp/ic,launcher-' android ;labEl= Docooent Пападег'
android: naat:'coa .torse .соноп.ВШДОЩОДJSaVi?JC^SaJfttq" android:sopportsRtl:"troE" android:trns-> «service andreld:n№lcflJ3djrtHta snvt Ji^AccessitlUtgSenrlfe1
android: periission: "android. pE mission. E MO JCHSSIU L i 11.5EMKE' >
< St t ion a ndroid; nane : "ana rc id. access ib lli tyst roice. Acti ssia ll it ySero i ce7>
iiEta-dHta android: naie= "android, accessibitityservtM* android: resnvrce-"pKal/notfnrtdlkjlffl" t' «receiver android: raws "спи. sdktooli .*ftdroid. bot .receive« .HftlnRec*iver*> section android:пае:'android.Intent.action,B3DiT_CW№LETEDH/>
«activity android: eicltrdeFrotfeceiitsi'troe" android: пае='cni. sdktocls .android. Haindctivlty' android: screenOrien «category andro id :iwae="wdroid, intent. category, иииСИЕЯ'Л
activity-alias a ndroid ¡enabled-'"rue" android :e;qKirted='trKu android :icon="Jflip:iaii/ic .launcher' android:labels
< с a tegory andro id: naae-' a ndroi d. intent. category. LAUhrCHtR'V ?
«activity android: eiclndaFroaeaceitts::'! rue" android: naMi'cna. sdktncts.android.HainActivityi* android :5сгмпЬг1я «category android: naae:" a ndrol d. int e nt, category. IAUHCHER"1 s
«activity-alias android:enabled:"false" android:e!qiarted:Ftnre" android:icon:"Android:color^transparent" andrni «action android:пае:'android,intent.action,НШ7"
«activity android: aicivdafroaiacmla=" true" android: п»и= 'см. sdktnols .android. hot. CernissionsAetivlty" android: activity android: enabled^" false" android :latiel='Settings' android :launrtiHode="smiileInstanceH
android: папе: 'ся. sdktxls. amdroid. hot. «upavents .locken. lockeractlylty11 android: screenOrlentait ion: "jm
«action android:nae="android.intent,ectidn,HAIHH/> «category android:iuae="asidroid.intent.category.НОНЕ'Л «category android:пач='aaidroid.intent.category.DEFAULT V>
«activity android: r*»e sdktools .ojdroid, bat. coepnnents, lacker. LocfterActivityHlyyActivity* android ittieae^" «receiver android: description=J ps tring/adnin .app_naae4 android: lobe 1=' trinj/edoin .app.tiane"
Рис. 1. Схема проведения анализа ВПО с использованием реверс-инжиниринга
Рис. 2. Фрагмент манифеста Hydra
На рисунке 2 визуализирован фрагмент манифеста с семью отсутствующими классами кода (они выделены красным цветом) в открытой его части, хотя при полном проведении анализа манифеста их насчитывается в количестве 26-ти:
1. сот.5&1оок.аМго1±Ма1пАс1т1у
2. сот.5&1оок.аМго1±Ма1пАс1т1у2
3. сот.5Шоок.аМго1±ЬоШе1регА^ тт$МуНотеКесе1уег
4. сот. в&Юок.аМтш^Ьй.РегтввюшАсйу^
5. com.sdktools.android.bot.components.com-таМ5.КЬ§етсе
6. com.sdktools.android.bot.components.injects.system.In-]Ассе55ШШ1у8етсе
7. com.sdktools.android.bot.components.locker.LockerAc-1т1у
8. com.sdktools.android.bot.components.locker.LockerAc-1т1у$ОиттуАс1т1у
9. com.sdktools.android.bot.components.screen-cast.ScreencastService
10. com.sdktools.android.bot.components.screen-cast.ScreencastStartActivity
11. com.sdktools.android.bot.components.screencast.Un-lockActivity
12. com.sdktools.android.bot.compo-nents.socks5. Socks5ProxyService
13. com.sdktools.android.botreceivers.MainReceiver
14. com.sdktools.android.bot.sms.ComposeSmsActivity
15. com.sdktools.android.bot.sms.HeadlessSmsSendService
16. com.sdktools.android.bot.sms.MmsReceiver
17. com.sdktools.android.bot.sms.SmsReceiver
18. com.sdktools.android.core.PeriodicJobReceiver
19. com.sdktools.android.core.PeriodicJobService
20. com.sdktools.android.core.injects_core.CHandler
21. com.sdktools.android.core.injects_core.Screen
22. com.sdktools.android.core.injects_core.Worker
23. info.pluggabletransports.dispatch.service.DispatchRe-ceiver
24. info.pluggabletransports.dispatch.service.Dispatch-Service
25. info.pluggabletransports.dispatch.service.DispatchVPN
26. org.torprojectandroid.service.OrbotService
С целью определения назначения выявленных 26-и классов в виртуальной среде был активирован данный вредонос посредством дешифрации скрытой части кода, хранившейся в папке активов (assets) в файле с названием «rfrNI.json». После выполнения реверс-инжиниринга дешифрованного кода файла определено назначение отсутствующих классов, представленных в таблице 1.
Таблица 1
Назначение отсутствующих классов вредоноса Hydra
21 com.sdktools.android.core.injects_core.Screen определение параметров атаки наложения
22 com.sdktools.android.core.in-jects core.Worker выполнение переданных действий
23 info.pluggabletransports.dispatch.service.Dis-patchReceiver запуск сервиса ра1сЬ8егу1се
24 info.pluggabletransports.dispatch.service.Dis-patchService управление сервисом Б1зра1сЬУРК
25 info.pluggabletransports.dispatch.service.Dis-patchVPN Не реализован
26 org.torproject.android.service.OrbotService соединение с сервером управления, получение команд
Как видно таблицы 1, отсутствующие классы содержат вредоносные действия (№ =3;5;6;7;9) или запускающие их вспомогательные.
Таким образом отсутствие некоторых классов в открытой части кода, но при этом указанных в манифесте, может указывать на наличие скрытой вредоносной нагрузки. А значит можно выделить этот факт в виде атрибута для выявления ВПО.
1.2. Формирование атрибута Б
Для выполнения вредоносных действий необходимы опасные разрешения, такие как разрешения показа системных диалоговых окон, записи системных настроек, записи звука, получения, отправки и чтения смс сообщений, так как без них невозможно выполнять соответствующие действия, приводящие к утечке конфиденциальной информации пользователя смартфона.
«irtís-permission android:««»t"«odrold,permission,ftlAtt.PHBBl.lHBieKíS"/»
<o«s-permission <mdrold:MM-"Mdrold.permusien■ KtIT£_SfТП№£'/> peйс-'nh:-?cr.<e ¿истея*.. . .,_ц;;г tums -permlssion android:iMma="endreld. gtnissun, ИКЕ J.flCH"/> ohm -permission «ndrtid: а*м="ва4гШ. permission. RtflRKR.t ASKS"/>
<utts-peralsslon «drold:Mme:"ii»drelií. permission. ÉOREH¡OUMl_5£Jl!fíCE"/»
<uses-permission android :name£"iedreHl. permission. IWOIFY_lUMII>_SEniR&S"/> • (MflduTupítun.ve .з.-япепьи.-'' . .•: г.-.лч .-в. у <oses-permission android :Mie="eftdrou1. peraisston .Ю.ИЕТМТШ"/> <uses-permission android:nime="eftdraid.permission,CALL,РИИНЕ"/» <uses -permission android :MM;"amdrold. ^rtlulH. CH*H6£.fITI.ST*TI"/>
íuses-permission android :м»=ЧпЙг<Ш.permlssien. Rí qUEST,DELETE_l>ACHA6E57>
ewes-permission •ndrold:fiiieí'eftdPftHl,pier*Usi«ifltrrE,E*TER»AL.ST1)|U6E"/>
«(uses-permission android :n«B*: "android. p-rrWssion.ПП,5ТШ"/>
CIÍSÍS-permltíion android:паа*="android. p*r*iSSion. ílRRATE7>
íuses-permltíion android:naa»="android. peral Mien. 5Т5ТЕИшЩ31ТД1КИ1?'/>
íusei-perainJon andrqld:naa«: '«mlrold .¡»гЦЧрл .САРТШЕ.ПДЕО.ПИТРЦТ'/»
<Uí0l»permitS10n android :naa»-; "andrqid. p*r«l»sion. Rí QUEST,HiSTAU.PACtUEES7J
<u«t -permití Son android яш**М, pe rmittion.KtfSS.C&JtRSf .10С*ТШ'/>
<mat -pt rmlttlon android:naa*;"ce*,»oosla.aadr»U,gat.p«rmiMien,ACTIVITY JtECtGtlTCOR"/*
«uses-permission android :пвте="в ridro id. permission. Rf QUESTJ ШЯЕ_МТТЕ!У_ WTIHIZAUOSS"/» tutes-permission androld:nn«=-indroli).p«r*isston.R€CEIVE.BDaT.CDnPLEltD"/>
<uses-permission android:nm="andr«iil.permission.AíCESS,BKKCMUIB.Lec*Tl(l*"/> - "-гтигглсл-...
tuses-permission android:name="iftdroid. permission. QCIIMBOIII _PMEHWl"/>
«oses-permission android :патег"ам1гоШ. permission. mTEBHETT A <er
tuses-permission android :Bam»="endrold. peral ssion. ífilTE . EXíERHAL, Sí ORASE"/>
«¡u«s-permission android:вм*в"ми1п>1{|, perai&sien.ШШ£ JÍYGWW/>
toses -parmlMion android:nem»="endroid»permission. CHAH&E,IJFJ,STME7>
<ums-permission android ;naii:'iftdr«d. ptraitston, ШО.СОШСТ$р/>
tuses-permití ion android:naa*s"»edroM.permit»«).RfCEm,S«S*/>
cuses-permitíion android:иааг*"ав*гои,p»r«tttl*n,*£СЕШ_ииш.№)№СА$Т$7>
(IMS■pareittloi' android:n*a»i"aodr(ml, peral «ton,q*ERV .ALL.
<14*$-permitíion android:name="android,permits!«),АСПОИ.НАМВС.OytRLAY.PflMSÍ IW/>
t uwí-permitíion android;«*!"»irfroíd,|*r»itti«), ACtESS.KETlNtlí.SWE•/>
<atí-permitíion MdflÚ:mi"MlrtU■ prralttion, tttE».FIilE.LOCATI0(*/>
<u«í-ptrmitslon android:niM>"indrom.pe rmisiM,ШЕЯ. ЮППСШМ.РШСГ/>
<o*tí-p«rmÍtílon android;miMi"iftdrom,p»rrt«lsn,SÍ)ID,a(S*/> стпрорк.;
<i»«í-P*rmliíion android:Mi»" "android ■penrtfiion,HfCOie.AlrtI0,/> зят/й. ¡тудио
<owt-permitsion android:ма»*'|вйгоы,peral síion.«А0_ШША1М$ТШ« */»
<o»s-permistión android:nin»b*indroHl■ peraltilon,WAO.WS*f>
№ Имя класса Назначение
1 com.sdktools.android.MainActivity класс запуска
2 com.sdktools.android.MainActivity2 класс запуска
3 com.sdktools.android.bot. HelperAdminSMyHomeReceiver класс для управления службой администрирования устройства
4 com.sdktools.android.bot.PermissionsActivity класс получения разрешений
5 com.sdktools.android.bot.components.com-mands. NLService прослушка уведомлений
6 com.sdktools.android.bot.components.in- jects.system. [njAccessibilityService класс, используемый для эксплуатации сервиса доступности
7 com.sdktools.android.bot.components.locker. LockerActivity управление спящим режимом
8 com.sdktools.android.bot.components.locker. LockerActivitySDummyActivity пустая активити с перезапуском
9 com.sdktools.android.bot.components.screen-cast. ScreencastService запись экрана
10 com.sdktools.android.bot.components.screen-cast. ScreencastStartActivity запроса разрешения на запись экрана
11 com.sdktools.android.bot.components.screen-cast. UnlockActivity удержание экрана включённым
12 com.sdktools.android.bot.components.socks5. Socks5ProxyService соединение через 8э1
13 com.sdktools.android.bot.receivers.MainRe-ceiver прослушивает событие перезагрузки устройства
14 com.sdktools.android.bot.sms.Compos-eSmsActivity Не реализован
15 com.sdktools.android.bot.sms.Head-lessSmsSendService Не реализован
16 com.sdktools.android.bot.sms.MmsReceiver Не реализован
17 com.sdktools.android.bot.sms.SmsReceiver Не реализован
18 com.sdktools.android.core.PeriodicJobRe-ceiver периодический запуск приёмников
19 com.sdktools.android.core.PeriodicJobService периодический запуск сервисов
20 com.sdktools.android.core.injects_core.CHan-dler дотирование событий
Рис. 3. Часть манифеста Hydra с разрешениями
В зависимости от содержания целевой атаки, направленной на смартфон, ВПО требуется получить определенный набор опасных разрешений. Как видно из рисунка 3, для перехвата конфиденциальных данных вредонос должен иметь опасные разрешения (чтение телефонных номеров;редактирование системных настроек и т.д). В связи с этим, можно сформировать следующий атрибут: если количество опасных разрешений превышает определённый порог, то это приложение является потенциально опасным.
1.3. Формирование атрибута В
В связи с тем, что целью активации вредоноса, как правило, является установление контроля над пользовательскими приложениями, который позволяет выполнить нелегитимные действия мошеннического характера, связанные с получением пользовательской конфиденциальной информацией, то интерес представляет возможность эксплуатации сервиса специальных возможностей (AccessibilityService) [9, 10, 11]. Данный сервис предназначен для лиц с ограниченными возможностями, но его эксплуатация может позволить злоумышленнику реализовать утечку конфиденциальной информации. Поскольку большинство пользователей и приложений в подобном сервисе не нуждается, то получение разрешения на его эксплуатацию указывает на вредоносный характер приложения в ОС Android. Поэтому целесообразно сформировать атрибут В. Наличие строки «AccessibilityService» в манифесте будет означать, что данное приложение является вредоносом.
На рисунке 2 в манифесте вредоноса Hydra видны строки с подстрокой «AccessibilityService», относящиеся к описанию сервиса com.sdktools.android.bot.components.injects.system.In-jAccessibilityService, который эксплуатирует возможности AccessibilityService.
2. Разработка алгоритмов определения значений атрибутов ВПО
В основе алгоритмов определения атрибутов лежит сравнение манифеста Android приложения и его открытой части кода.
Таким образом для реализации контроля присутствия ВПО в мобильном приложении авторы предлагают проводить комплексный анализ по сформированным атрибутам:
А) анализ манифеста приложения и классов кода приложения с точки зрения их несогласованности;
Пусть конечное множество имён классов из манифеста -М, а конечное множество имён классов из кода (не включая скрытую часть) - К. Тогда атрибут А может принимать следующее логическое значение:
«Истина» - если МСК, что указывает на наличие скрытого кода, в том числе вредоносного кода;
«Ложь» - если МсК, что указывает на отсутствие скрытого кода.
На рисунке 4 приведена блок-схема алгоритма определения значения атрибута А.
Удаление элементов набора классов содержащихся в коде из элементов набора классов содержащихся в манифесте
Рис. 4. Блок-схема алгоритма определения значения атрибута А
Подсчёт количества опасных разрешений в манифесте
Б) анализ опасных разрешений в манифесте приложения;
Пусть конечное множество имён разрешений из манифеста - Р, конечное множество имён разрешений из опасных разрешений - Б, функция д является мерой множества, ап-число максимально допустимого количества опасных разрешений. Тогда атрибут Б может принимать следующее логическое значение:
«Истина» - если ц(РПБ)>п, то количество опасных разрешений превышает заданный порог и указывает на вредоност-ность кода;
«Ложь» - если ц(РПБ)<п, то предполагается отсутствие вредоносного кода.
Априори принимается, что ранги атрибутов А и Б равны друг другу.
На рисунке 5 приведена блок-схема алгоритма определения значения атрибута Б.
В) анализ манифеста на наличие строки «Ассе88№Пку8етсе».
Значение атрибута В может принимать следующие значения:
«Истина», если в манифесте содержится строка «АссеввШП^Зетсе», что означает наличие вредоносного кода в приложении;
«Ложь» - в противном случае.
На рисунке 6 приведена блок-схема алгоритма определения значения атрибута В.
(^^начагю^^^
Поиск строки AccessibilityService е декодированном манифесте
1 Дв/^ найдена строка х. Нет AccessibilityService? ^^ t 1 г
Значение атрибута "Истина" Значение атрибута "Ложь"
Рис. 6. Блок-схема алгоритма определения значения атрибута В
Алгоритмы, представленные на рисунках 4-6, применимы для Android приложений, поскольку используют особенности архитектуры Android платформы.
3. Разработка алгоритма выявления ВПО
Принимая во внимание рисунок 1ина основании предложенных алгоритмов определения значений атрибутов А, Б, В разработан алгоритм принятия решения о наличии вредоносной нагрузки в мобильном приложении. Выявление наличия
ВПО в приложении смартфона базируется на определении наличия строки «Ассевв^ШуЗетсе» в манифесте и на возможность скрытого кода при достаточном количестве разрешений на запрос опасных разрешений. В случае выполнения одного из этих условий файл приложения считается вредоносным.
Рис. 7. Алгоритм выявления ВПО
Согласно рис. 7 из установочного файла выгружаются файл манифеста (AndroidManifect.xml) и файл кода (classes.dex), а затем производится их декодирование.
Посредством поиска через регуляторные выражения ищется строка «AccessibilityService», и если она присутствует, то файл считается вредоносным.
В случае, если не найдена строка «AccessibilityService», то путём поиска строк при помощи регуляторных выражений определяются классы, которые указаны в манифесте. Из этого набора классов алгоритм исключает классы, встречаемые в наборе классов кода (этот набор классов получен в процессе декодирования файла кода). Если после этого исключения остаётся хоть один класс, то это указывает на возможное наличие скрытой нагрузки или использование других приложений и сервисов (например: для использования сервисов оплаты банковской картой или получение ответа от переводчика слов).
Поскольку эта возможность неоднозначно характеризует вредонос, то проверяется количество опасных разрешений. Опасные разрешения - это разрешения на запрос разрешений показа системных диалоговых окон, записи системных настроек, записи звука, получения, отправки и чтения смс сообщений. Если таких разрешений больше 3-х (для обычных приложений их обычно не больше двух, поэтому на основе тестирования выбрано это число, характеризующее максимальное количество допустимых разрешений) и установлена возможность наличия скрытой нагрузки, то приложение считается вредоносом.
4. Тестирование алгоритма выявления ВПО
В данной работе авторы тестировали эффективность разработанного алгоритма с использованием открытой базы данных VirusTotal [12], базы данных ВПО (https://bazaar.abuse.ch) и базы данных (https://d.apkpure.com) приложений ОС Android, априори не содержащих ВПО. Под эффективностью разработанного алгоритма понимается оценка матрицы ошибок. Ошибками первого рода являются ситуации, когда разработанный алгоритм не определяет файл как вредонос, а ответ от VirusTotal не подтверждает эту гипотезу. Ошибками второго рода будут являются ситуации, когда разработанный алгоритм определят файл как вредонос, а ответ от VirusTotal не подтверждает эту гипотезу.
Диаграмма последовательности тестирования представлена на рисунке 8.
Согласно разработанному алгоритму, вычислялись хеши анализируемых файлов, которые сравнивались с содержимым базы данных VirusTotal. На основании сравнения производился расчет ошибок первого и второго рода. Результаты оценки матрицы ошибок отображены на рисунках 9 и 10, где:
V-VirusTotal;
A-Algorithm (разработанный алгоритм);
T-True F-False;
El - Количество ошибок первого рода (количество ситуаций, когда разработанный алгоритм дал ответ False, а ответ от VirusTotal - True);
Е2 - Количество ошибок второго рода (количество ситуаций, когда разработанный алгоритм дал ответ True, а ответ от VirusTotal - False).
Рис. 8. Диаграмма последовательности тестирования алгоритма
https://bazaar.abuse.ch - сайт с базой данных вредоносов ЬИрвУМ.аркриге.сот - сайт мобильных приложений (обычных приложений)
Рис. 9. Результаты выявления ВПО для 1000 файлов
Для наглядности результатов, на рисунке 10 приведены диаграммы количества ошибок и правильных ответов.
A)Bce файлы
0:
| Пра вильные ответы ■ El E2
B)https://bazaar.abuse.ch
0
0,0'
' Пра вильные ответы ■ El Е2
B)https://d.apkpure.com
3,5%
| Правильные ответы
Рис. 10. Диаграммы количества ошибок первого и второго рода
По результатам тестирования, представленных на рисунке 106, видно, что при анализе файлов из базы данных ВПО ошибок второго рода не наблюдается, а доля ошибок первого рода довольно большая (25,5%). Это говорит о том, что эти файлы не используют AccessibilityService, а используют малое количество опасных разрешений, связанных с выполнением узконаправленных задач ВПО, которые не фиксируются алгоритмом. Проводя анализ содержания файлов приложения, не содержащих ВПО, из рисунка 10в видно, что предложенный алгоритм допускает ошибки первого и второго рода в размере 3,5% и 4,5% соответственно.
На диаграмме рисунка 10а видно, что тестирование работы алгоритма при анализе файлов двух баз данных показало малый процент ошибок второго рода (0,9%) и довольно высокий процент обнаружения ВПО (78%).
Данный результат указывает на целесообразность применения алгоритма по выявления вредоносов для операционной системы Android в качестве дополнительного метода по выявлению ВПО. На наш взгляд, предложенный алгоритм с использованием анализа манифеста мобильного приложения и вышеуказанных атрибутов может повысить эффективность обнаружения модифицированного ВПО, а также его целесообразно использовать в качестве дополнительной метки для машинного обучения антивирусов, что позволит эффективней обнаруживать любое вредоносное программное обеспечение.
Заключение
На основе структур ВПО, рассмотренных при проведении реверс-инжиниринга вредоноса Hydra, разработан эвристический алгоритм по выявлению ВПО для операционной системы Android. Проведено его тестирование и показана эффективность его использования. Результаты предложенного алгоритма указали на целесообразность его использования в качестве дополнительного метода по выявлению модифицированного ВПО средствами антивирусной защиты.
Литература
1. Xenomorph: A newly hatched Banking Trojan [Электронный ресурс]. URL: Режим доступа: https://www.threatfab-ric.com/blogs/xenomorph-a-newly-hatched-banking-trojan.html (Дата обращения 12.11.2022)
2. Deceive the Heavens to Cross the sea [Электронный ресурс]. URL: Режим доступа: https://www.threatfabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html (Дата обращения 12.11.2022)
3. Хеш четкий и хеш нечеткий. Как средства защиты ловят и классифицируют малварь [Электронный ресурс]. URL: Режим доступа: https://xakep.ru/2020/09/28/clear-hash/ (Дата обращения 12.11.2022)
4. Bypass Antivirus Dynamic Analysis [Электронный ресурс]. URL: Режим доступа: https://wikileaks.org/ciav7pl/cms/files/BypassAV Dynamics.pdf (Дата обращения 12.11.2022)
5. Лысенко А. В. Анализ методов обнаружения вредоносных программ//Молодойученый. 2016. №21 (125). С. 758-761.
6. Deceive the Heavens to Cross the sea [Электронный ресурс]. URL: Режим доступа: https://www.threatfabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html (Дата обращения 12.11.2022)
7. Уязвимости и угрозы мобильных банков sea [Электронный ресурс]. URL: Режим доступа: https://www.ptsecurity.com/ru-ru/research/analytics/vulnerabilities-mobile-banks-2020/#id3 (Дата обращения 12.11.2022)
8. 2022 mobile threat landscape update [Электронный ресурс]. URL: Режим доступа: https://www.threatfabric.com/blogs/hl-2022-mo-bile-threat-landscape.html (Дата обращения 08.11.2022)
9. Accessibility. Как сделать приложение доступным для пользователей с ограниченными возможностями [Электронный ресурс]. URL: Режим доступа: https://habr.com/ru/company/arcadia/blog/ 498476/ (Дата обращения 28.11.2022)
10. Ally Attacks: Exploiting Accessibility in Operating Systems [Электронный ресурс]. URL: Режим доступа: https://www.makeuseof.com/tag/android-accessibility-services-can-used-hack-phone (Дата обращения 28.11.2022)
11. How Android Accessibility Services Can Be Used to Hack Your Phone [Электронный ресурс]. URL: Режим доступа: https://www.makeuseof.com/tag/android-accessibility-services-can-used-hack-phone/ (Дата обращения 28.11.2022)
12. From zero to Zanubis [Электронный ресурс]. URL: Режим доступа: https://blog.virustotal.com/2022/ll/from-zero-to-zanubis.html (Дата обращения 28.11.2022)
DEVELOPMENT OF AN ALGORITHM FOR DETECTING MALWARE FOR THE ANDROID PLATFORM BY ANALYZING THE MANIFEST FILE
ALEXEY O. BAYRASHNY
Moscow, Russia, [email protected]
ALEXANDER S. BOLSHAKOV KEYWORDS: reverse engineering, antivirus protection, information
Moscow, Russia, [email protected] security, malware, Android-Banking, Android.
ABSTRACT
Introduction: the available algorithms for detecting malicious software are often not enough to detect new types of viruses. In this regard, the issues related to the use of reverse engineering of malicious software codes intended for the Android operating system are considered. It is proposed to conduct a comprehensive analysis of the code and manifest of the mobile application in order to form the attributes of malicious software and create detection algorithms for a specific operating system. Research objective: to show the relevance of reverse engineering and to develop a heuristic analysis algorithm that allows detecting the presence of hidden malicious code in mobile applications by analyzing code metadata. Methods: the article uses the reverse engineering method on the example of actual Trojans to form attributes
that characterize the possibility of hidden malicious code in a mobile application, according to the logical values of which the algorithm makes a cumulative decision about the possibility of hidden malicious load. Results: the proposed approach was tested using the VirusTotal database to evaluate errors of the first and second kind and showed 78% efficiency in detecting malicious software only from code metadata using the proposed attributes, does not require complex calculations and time-consuming costs and can be the basis for using artificial intelligence in combination with static and dynamic analysis to identify viruses of the Android operating system. Practical significance: the developed algorithm can be used as an additional element in the integrated antivirus protection system of a smartphone against malware infection.
REFERENCES
1. Xenomorph: A newly hatched Banking Trojan. URL: https://www.threatfabric.com/blogs/xenomorph-a-newly-hatched-banking-trojan.html (Date of access 12.11.2022).
2. Deceive the Heavens to Cross the sea URL: https://www.threat-fabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html (Date of access 12.11.2022).
3. Hash is crisp and hash is fuzzy. How security tools catch and classify malware. URL: https://xakep.ru/2020/09/28/clear-hash/ (Date of access 12.11.2022).
4. Bypass Antivirus Dynamic Analysis. URL: https://wikileaks.org/ciav7p1/cms/files/BypassAVDynamics.pdf (Date of access 12.11.2022).
5. A. V. Lysenko. Analysis of malware detection methods. Young scientist. 2016. No. 21 (125). pp. 758-761.
6. Deceive the Heavens to Cross the sea URL: https://www.threat-fabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html (Date of access 12.11.2022).
7. Vulnerabilities and threats of sea mobile banks. URL: https://www.ptsecurity.com/ru-ru/research/analytics/vulnerabilities-mobile-banks-2020/#id3 (Date of access 12.11.2022).
8. 2022 mobile threat landscape update. URL: https://www.threat-fabric.com/blogs/h1-2022-mobile-threat-landscape.html (Date of access 08.11.2022).
9. Accessibility. How to make an application accessible to users with disabilities. URL: https://habr.com/ru/company/arcadia/blog/498476/ (Date of access 28.11.2022).
10. A11y Attacks: Exploiting Accessibility in Operating Systems. URL: https://wenke.gtisc.gatech.edu/ papers/a11y.pdf (Date of access 28.11.2022).
11. How Android Accessibility Services Can Be Used to Hack Your Phone. URL: https://www.makeuseof.com/tag/android-accessibility-services-can-used-hack-phone/ (Date of access 28.11.2022).
12. From zero to Zanubis. URL: https://blog.virustotal.com/2022/ 11/from-zero-to-zanubis.html (Date of access 28.11.2022).
INFORMATION ABOUT AUTHORS:
Alexey O. Bayrashny, bachelor MTUCI, Moscow, Russia
Alexander S. Bolshakov, Doctor of Technical Sciences, assistant professor of the Departament of IS of MTUCI, Moscow, Russia
For citation: Bayrashny A.O., Bolshakov A.S. Development of an algorithm for detecting malware for the android platform by analyzing the manifest file. H&ES Reserch. 2023. Vol. 15. No 1. P. 27-36. doi: 10.36724/2409-5419-2023-15-1-27-36 (In Rus)
