Задолго до того, как в Google Play была загружена первая вредоносная программа, команды разработчиков операционной системы Android и специалистов по безопасности приняли несколько архитектурных решений, призванных защитить пользователей от вредоносных программ. Например, для изоляции приложений Android друг от друга они повторно использовали систему учётных записей Linux. Благодаря этому приложениям стало очень трудно злонамеренно взаимодействовать с другими приложениями или похищать их данные из файловой системы. Любой вредоносной программе, которой требовалось это сделать, приходилось ослаблять защиту устройства с помощью эксплойтов для получения root-прав или иных столь же редко встречающихся способов повышения привилегий. Аналогичным образом появление системы разрешений приложений стало большим шагом вперёд по сравнению с более старыми операционными системами, поскольку пользователи получили более точный контроль над тем, к каким конфиденциальным данным и функциям разрешён доступ приложениям.

Когда в Google Play обнаружили первую вредоносную программу, картина угроз изменилась. К тому времени Android приобрёл такую популярность, что разработчики вредоносных программ уже зарабатывали на злоупотребляющих возможностями Android приложениях, а те, кто прежде мог разрабатывать вредоносные программы для других платформ, начали всерьёз присматриваться к Android.

В ответ на новые угрозы команда Android Security сосредоточилась на глубокоэшелонированной защите. Google разработала ключевые компоненты экосистемы Android - прежде всего Google Play, операционную систему и аппаратную часть телефонов (устройства Nexus и Pixel), - благодаря чему заняла сильную оборонительную позицию. По мере появления новых атак команда Android Security могла им противостоять, укрепляя платформу Android, пересматривая правила Google Play и совершенствуя сканер приложений, который находит вредоносные функции в программах, загружаемых разработчиками Android.

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

Первый уровень модели безопасности Android - изоляция приложений. Как уже упоминалось, с самой первой версии Android операционная система использует систему учётных записей Linux, чтобы изолировать приложения и процессы друг от друга. Каждому приложению назначается новый идентификатор пользователя Linux (UID), не имеющий доступа к закрытым данным или памяти процессов других приложений.

Со временем Google дополнила эту модель песочницы другими технологиями. В Android 4.3 (Jelly Bean) впервые была применена система Security-Enhanced Linux, более известная как SELinux. SELinux - модуль ядра Linux, с помощью которого настраивают политики безопасности управления доступом для разных частей системы. Хотя SELinux печально известна сложностью развёртывания и редко включается по умолчанию в других версиях Linux, она обладает исключительной мощью, благодаря чему её внедрение стало одной из важнейших функций безопасности Android, защищающих от вредоносных программ, повышающих привилегии. Даже вредоносные программы, которые с помощью эксплойтов для получения root-прав обретают повышенные привилегии, остаются связанными её правилами управления доступом.

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

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

Изоляция приложений не помогает против атак, способных вырваться из пользовательского пространства Linux или обойти SELinux. Второй уровень модели безопасности Android - сокращение поверхности атаки, то есть практика сведения к минимуму доступа потенциального злоумышленника к коду, API, службам и другим частям приложения.

Существует множество способов уменьшить поверхность атаки. Самый очевидный - удалить ненужный код, системные модули, открытые порты или API, доступные злоумышленникам; систему с небольшим количеством открытых компонентов защитить легче, чем систему, в которой таких компонентов много. Аналогичным образом сокращение сложности и объёма кода считается хорошей практикой безопасной разработки программного обеспечения. Сложность делает код трудным для понимания, защиты и простым для эксплуатации, поскольку программисту приходится учитывать неуправляемое количество пограничных случаев. Меньше кода означает меньше возможностей для ошибок программирования и меньше потенциальных точек атаки.

Если уменьшить сложность невозможно, почти столь же хорошей стратегией становится недоступность кода для эксплойтов; за многие годы команда Android неоднократно применяла этот подход. Например, в ответ на ряд уязвимостей, получивших общее название Stagefright, команда Android Security полностью переработала уязвимый компонент mediaserver в Android 7.0 (Nougat), чтобы свести к минимуму количество открытых API. Кроме того, рискованный код перенесли в более надёжные специализированные песочницы, а ненужные функции, такие как execmem - опасное разрешение SELinux, позволяющее помечать страницы памяти как исполняемые, - удалили. Дополнительные сведения приведены в опубликованной в 2016 году записи блога Android Security «Hardening the Media Stack».

Ещё одной добавленной командой Android Security технологией сокращения поверхности атаки стала seccomp, появившаяся в Android 8.0 (Oreo). Это сокращение от secure computing mode - «режим безопасных вычислений»; seccomp представляет собой технологию Linux, которая работает как межсетевой экран между процессами пользовательского уровня и ядром. С помощью правил фильтрации, записанных на языке Berkeley Packet Filter (BPF), она может блокировать попытки процесса пользовательского уровня выполнить определённые системные вызовы, а также завершать такие процессы. Включение seccomp в Android устраняет системные вызовы, которые в противном случае были бы доступны приложениям при попытке повысить привилегии.

В Android 9.0 (Pie) потенциальная поверхность атаки для вредоносных приложений вновь была значительно сокращена: приложениям запретили обращаться к внутренним методам Android API посредством рефлексии или нативного кода. Начиная с этой версии, приложениям оставались доступны только методы, относящиеся к общедоступному Android API. Это изменение не только повысило совместимость приложений между версиями Android, вынуждая их обращаться к официальным API, но и сыграло важную роль в обеспечении безопасности. До введения данного ограничения разработчикам приложений Android иногда удавалось находить способы вызова внутренних API через закрытые методы, обходившие систему разрешений и другие ограничения.

Сокращение поверхности атаки может принимать и совершенно иную форму. Например, согласно статистике, собранной командой Android Security, до настоящего времени наиболее часто эксплуатируемые уязвимости Android были связаны с повреждением памяти. В состав последних версий Android начали включать компоненты, написанные на Rust - языке программирования, обеспечивающем безопасность памяти и, как ожидается, способном сократить количество ошибок, связанных с её повреждением.

Android - сложная операционная система общего назначения, содержащая миллионы строк кода. Какой бы объём кода ни был удалён, сделан недоступным или помещён в песочницу, возможности для появления уязвимостей останутся всегда. Поэтому многие команды безопасности исходят из предположения, что каждому злоумышленнику однажды повезёт; однако вероятность того, что ему повезёт дважды, уже ниже. Так в упрощённом виде обосновываются многочисленные средства Android для смягчения последствий эксплуатации уязвимостей, призванные затруднить успешную компрометацию системы в результате атаки или сделать её невозможной. На официальном сайте Android Security поддерживается подробный список усовершенствований безопасности, появившихся начиная с Android 1.5: source.android.com.

В ранних версиях Android основное внимание уделялось внедрению методов смягчения последствий эксплуатации уязвимостей, чтобы догнать уже существовавшие средства защиты других операционных систем. До Android 4.0 (Ice Cream Sandwich) в систему добавили такие защитные технологии, как рандомизация размещения адресного пространства (ASLR), аппаратная защита No eXecute (NX), а также методы повышения безопасности выделения и освобождения памяти.

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

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

В Android 4.4 (KitKat) появилась технология Verified Boot, которая не позволяет злоумышленникам изменять загрузчик. По существу, Verified Boot обеспечивает проверку целостности каждого компонента процесса загрузки устройства до его выполнения. Если проверку не проходит какая-либо часть процесса загрузки, пользователь получает предупреждение о том, что его устройство подверглось вмешательству и безопасность устройства не может быть гарантирована.

В Android 5.0 (Lollipop) в качестве дополнительной возможности включили полное шифрование диска, а в Android 6.0 (Marshmallow) оно стало обязательным. Кроме того, в Android 7.0 (Nougat) появилось пофайловое шифрование - усовершенствование полного шифрования диска, позволяющее шифровать разные файлы на диске разными ключами. В Android 10 пофайловое шифрование стало обязательным. Полное и пофайловое шифрование не защищают от эксплойтов, выполняющихся на устройстве, однако помогают защититься от злоумышленников, которые получили физический доступ к устройству и пытаются прочитать или изменить данные на диске.

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

В ранних версиях Android все разрешения, которые хотело использовать приложение, нужно было предоставить до его установки. Пользователи, не желавшие выдавать все запрошенные разрешения, не могли установить приложение, что было неудобно и часто становилось причиной злоупотреблений и жалоб. Начиная с Android 6.0 (Marshmallow) в Android была реализована система разрешений времени выполнения, в которой приложения запрашивают разрешения во время своей работы. Это изменение улучшило управление приложениями, поскольку теперь пользователи могли по отдельности предоставлять или отклонять более детальные разрешения на конфиденциальные операции. Например, если пользователь не возражал против отправки приложением текстовых сообщений, но не хотел предоставлять ему доступ к списку контактов, он мог разрешить отправку сообщений, одновременно запретив доступ к контактам.

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

Некоторые разрешения, доступные приложениям Android, особенно чувствительны и не могут быть предоставлены через стандартные диалоговые окна разрешений. Например, если приложение хочет устанавливать другие приложения, пользователь сначала должен перейти в настройки устройства и выдать ему такое разрешение. Аналогичным образом, если приложение хочет использовать Accessibility API - программный интерфейс, который изменяет отдельные части модели безопасности Android для более качественной поддержки пользователей с ограниченными возможностями, - пользователю сначала придётся пройти через ряд диалоговых окон с предупреждениями.

Модель безопасности Android предусматривает регулярные обновления безопасности. Чем быстрее такие обновления доставляются на устройства и устанавливаются пользователями, тем меньше времени остаётся у злоумышленников на эксплуатацию обнаруженных уязвимостей.

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

Со временем операционная система Android сделала системные обновления гораздо удобнее как для пользователей, так и для изготовителей устройств. Теперь обновления выполняются в фоновом режиме во время обычного использования устройства, а перезагрузить его пользователю нужно только для завершения процесса. Архитектура процесса обновления также была усовершенствована. Многие критически важные компоненты, которые прежде обновлялись в ходе обновления системы, были переписаны в виде самостоятельных приложений, обновляемых посредством обычного процесса обновления приложений Google Play. Один из важнейших примеров - стандартный компонент WebView, предназначенный для разбора и отображения содержимого HTML. Сложность кода процесса разбора и отображения делает WebView одной из главных целей злоумышленников. В настоящее время, если об уязвимости WebView сообщают команде Android Security или если эксплойт обнаруживают в реальных атаках, обновить компонент WebView можно за несколько дней, а не месяцев.

Изменение архитектуры, позволившее независимо обновлять основные компоненты, проникло и в саму операционную систему Android. В Android 8.0 (Oreo) Google анонсировала Project Treble, где появился механизм уровня абстракции, отделяющий операционную систему от изменений и расширений, добавленных изготовителями устройств. Цель Treble состояла в том, чтобы быстрее доставлять обновления основной операционной системы, исключив изготовителей устройств из этого процесса: они должны были отдельно и в собственном темпе обновлять свои дополнения и изменения.

Android 9.0 (Pie) и Android 10 дополнительно помогли изготовителям оригинального оборудования эффективнее выпускать обновления благодаря универсальным образам системы, или GSI, которые ускорили тестирование новых версий Android, и Project Mainline, позволившему изготовителям распространять системные обновления через Google Play. В совокупности эти изменения сделали Android 10 быстрее всего развёртывавшейся версией Android в истории: темпы её внедрения примерно вдвое превысили показатели Android 9.0 (Pie) и в четыре раза - показатели Android 8.0 (Oreo).

Седьмой уровень модели безопасности Android охватывает дополнительные службы безопасности и защиты, работающие в инфраструктуре Google. В зависимости от конкретной службы они доступны либо разработчикам приложений, либо пользователям.

Одна из таких служб - сканер вредоносных программ Android, обеспечивающий работу Google Play Protect, системы Google для обнаружения вредоносных программ на устройстве и предупреждения о них. В этот сканер непрерывно поступают сигналы о приложениях и решения, выработанные людьми и машинами, благодаря чему он заблаговременно выявляет и блокирует угрозы на уровне приложений как на устройстве, так и в Google Play. Пользователи могут просматривать результаты проверки своих устройств на вредоносные программы в приложении Google Play или в настройках безопасности устройства.

Службы для разработчиков представлены такими API, как Safe Browsing и SafetyNet. API Safe Browsing защищает пользователей от вредоносных сайтов в Chrome, Firefox и других браузерах, в которые интегрирована технология Safe Browsing. API SafetyNet позволяет любому приложению проверить множество аспектов целостности устройства перед выполнением конфиденциальных операций, например сбором учётных данных пользователя или платёжной информации. Поскольку работа этих служб зависит от доступа к серверной инфраструктуре Google, они доступны только на сертифицированных устройствах Android, поставляемых с Google Play и модулем Google Play Services.

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

Например, Android Security взаимодействовала с командой, отвечающей за введение новых правил Google Play, многие из которых призваны затруднить попадание в Google Play приложений, допускающих злоупотребления. В мае 2017 года команда разъяснила, что приложение не должно загружать дополнительный код из каких-либо источников, кроме Google Play, поскольку этот приём остаётся одним из основных способов, с помощью которых вредоносные программы обходят сканеры Google Play.

Приведём ещё несколько примеров. В августе 2019 года Google Play запретил приложениям, не предназначенным для работы в качестве прокси, перенаправлять сетевой трафик. Это решение было принято в ответ на появление прокси-инструментов, которые без согласия пользователей продавали доступ к ресурсам и сетям их устройств. В апреле 2020 года Google Play занял более жёсткую позицию в отношении сталкерских программ, обязав приложения для слежения выполнять минимальный набор мер, ограничивающих возможности злоупотребления ими. Команда Google Play Policy ведёт сайт support.google.com, где перечислены изменения правил Google Play начиная с 2016 года.

Работая над удалением вредоносных программ из Google Play, команда Android Security осознала, что установка приложений из сторонних источников, то есть из источников, отличных от Google Play, представляет гораздо большую опасность. Согласно ежегодным отчётам Android Security Year in Review, за пределами Google Play вредоносные программы встречаются приблизительно в 7-15 раз чаще, поэтому одной лишь защиты Google Play недостаточно для всей экосистемы Android.

Для защиты от вредоносных программ, устанавливаемых из сторонних источников, команда Android Security разработала и в 2012 году запустила систему защиты от вредоносных программ SafetyNet. Эта уже упоминавшаяся технология в конечном итоге превратилась в Google Play Protect. SafetyNet незаметно работала в фоновом режиме на всех устройствах Android с приложением Google Play. Пользователи взаимодействовали с SafetyNet лишь тогда, когда система обнаруживала на устройстве вредоносную программу. Поскольку на большинстве устройств Android вредоносные программы никогда не устанавливаются, большинству пользователей не доводилось взаимодействовать с SafetyNet.

Затем, в ответ на обнаружение вредоносных программ, которые различные изготовители предустанавливали на устройства, команда Android Security создала системы защиты предустановленных приложений. В частности, в 2018 году команда запустила Build Test Suite (BTS). BTS проверяет системные образы всех устройств под брендом Android, поставляемых с обычным набором приложений Google, включая Gmail, Google Play и Google Maps. Такая проверка проводится для всех изготовителей независимо от их популярности. В среднем новое устройство поставляется примерно с 400 предустановленными приложениями, в создании, сопровождении и передаче которых изготовителям участвует множество компаний. При такой модели и отсутствии контроля пользователи некоторых новых устройств Android могли бы намеренно или случайно подвергнуться воздействию проблемных приложений.

На протяжении многих лет команда Android Security в Google отслеживала множество категорий вредоносных программ. Приложение, демонстрирующее поведение хотя бы одной из перечисленных далее категорий, считается вредоносным независимо от того, намеренно ли разработчик включил в него опасный код, и будет соответствующим образом помечено сотрудниками команды Android Security и платформой обнаружения вредоносных программ. Важно отметить, что на практике приложение может демонстрировать сразу несколько видов опасного или вредоносного поведения и потому относиться более чем к одной категории.

Многие категории вредоносных программ обладают общими чертами. Можно сказать, что в целом вредоносная программа часто пытается: 1) избежать обнаружения, скрывая свои вредоносные функции от сканеров и аналитиков безопасности; 2) остаться установленной и не допустить удаления пользователем или защитным программным обеспечением; 3) прямо или косвенно заработать деньги, например собирая и продавая пользовательские данные, устанавливая другие приложения, искусственно создавая клики по рекламным объявлениям либо злоупотребляя системами или сетями, доступными с устройства.

В следующих разделах описаны категории вредоносных программ, влияющие на экосистему Android и её пользователей.

Отказ в обслуживании (denial of service, DoS) означает нарушение доступности устройства, системы или службы. Атаку DoS можно провести, например, воспользовавшись нарушением целостности системы - такой ошибкой повреждения памяти стека или кучи, которая приводит к сбою системы, - либо перегрузив систему запросами, количество которых превышает имеющиеся у неё ресурсы для обработки. Пытаясь обработать запросы, система может завершить работу или, по крайней мере, на некоторое время перестать отвечать на новые запросы.

Последствия DoS-атаки могут быть тяжёлыми. Например, для систем, принимающих заказы или платежи через интернет, любой простой способен непосредственно повлиять на итоговую прибыль предприятия. Восстановление после DoS-атаки также может оказаться дорогостоящим, поскольку иногда требует модернизации системы, установки исправлений, внедрения новых средств и инструментов защиты, увеличения производительности и так далее. Для критически важной инфраструктуры, включая больницы, цепочки поставок продовольствия и коммунальные службы, DoS-атака может причинить не только экономический ущерб, но и создать масштабные угрозы общественной безопасности.

В случае Android основная опасность DoS заключается в том, что большое количество устройств может превратиться в орудие злоупотребления против целей, выбранных злоумышленником. Некоторые DoS-атаки проводятся без ведома пользователя; во многих случаях его устройство добавляют в ботнет - совокупность устройств, находящихся под управлением определённого злоумышленника, целью которого является распределённая атака типа «отказ в обслуживании» (distributed denial-of-service, DDoS). Во время такой атаки множество устройств с одним и тем же установленным вредоносным приложением может отправлять по сети большое количество HTTP-запросов целевому веб-серверу. Объём трафика оказывается настолько велик, что в конечном счёте сервер не справляется с чрезмерной нагрузкой, переполняющей входную очередь и другие внутренние структуры данных. В результате сервер начинает отбрасывать или отклонять новые запросы, в том числе законные, и фактически перестаёт быть доступным.

DDoS-атаки могут принимать разные формы. В некоторых случаях их выполняет код, входящий в состав приложения уже во время установки. В других код с логикой DDoS динамически загружается с сервера управления во время выполнения вместе с такими данными, как IP-адрес цели, дата и время начала, а также продолжительность атаки. Команда Android Security встречала и приложения, установленные на множестве устройств и использующие WebView для непрерывной повторной загрузки одного и того же ресурса, например файлов изображений с веб-сервера, что приводило к стремительному падению производительности и невозможности отвечать на запросы. В иных случаях вредоносное приложение поддерживает разнообразные функции злоупотребления, которые может выполнять по запросу удалённого сервера управления. Сервер отправляет конкретные параметры выполнения всем устройствам, на которых установлено приложение.

До настоящего времени подобные атаки мобильных ботнетов встречались очень редко, и компании в сфере безопасности открыто описали лишь несколько из них. Однако по мере того, как мобильная связь во всём мире становится стабильнее и мощнее, мы ожидаем изменения этой ситуации. Кроме того, о непреднамеренных DDoS-атаках сообщают далеко не всегда. Они возникают, когда разработчики жёстко задают в коде подключения к веб-серверу по расписанию. Если приложение с таким подключением становится популярным, все устройства с этим приложением могут одновременно соединиться с веб-сервером. Небольшой веб-сервер, неожиданно получивший в полночь миллион запросов, легко столкнётся с проблемами. Примерно в половине случаев DDoS, выявленных за последние несколько лет, команде Android Security приходилось выступать посредником между неумелыми разработчиками приложений и недовольными владельцами веб-серверов, которые не могли справиться с огромным количеством соединений, внезапно поступивших от устройств Android.

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

Приложения-бэкдоры выполняют широкий спектр операций, включая:

• установку приложений, загруженных с подконтрольного злоумышленнику сервера, с использованием повышенных привилегий системного приложения, например тех, которыми обладают предустановленные приложения;

• получение root-прав на устройстве для возможности свободно записывать данные в файловую систему;

• сбор пользовательской информации с устройства, в том числе списков контактов, данных о местоположении, текстовых сообщений, номера телефона и журнала вызовов пользователя, а также имён пакетов установленных приложений;

• отправку текстовых сообщений на платные SMS-номера;

• перехват конфиденциальных данных, включая учётные данные, и предложение пользователю заполнить веб-форму, отправляющую эти сведения мошеннику;

• загрузку и показ рекламы.

Связь приложений-бэкдоров с серверами управления часто скрыта, осуществляется косвенно либо защищена с помощью методов обфускации или шифрования. Например, некоторые семейства вредоносных программ применяют распространённые алгоритмы шифрования, такие как AES и 3DES, для шифрования данных или кода, Base64 или XOR - для кодирования, а сжатие кода - для обфускации. Они могут избегать обнаружения, переключаясь между портами TCP и используя скрытые каналы на таких платформах, как чаты IRC, Firebase и X (прежде Twitter). Если пользователь заблокирует канал связи между сервером управления и приложением, заражённым устройством больше нельзя будет управлять, поэтому многие авторы вредоносных программ стараются защитить этот канал как можно лучше.

Известны приложения-бэкдоры, которые настойчиво пытаются обеспечить своё постоянное присутствие на устройстве, чтобы пользователи или сканеры вредоносных программ не могли легко их отключить. Один из подходов состоит в использовании предустановленных приложений, уже содержащих логику бэкдора. Однако более распространённый подход заключается в том, чтобы с помощью системных привилегий сравнительно простого предустановленного приложения позднее установить приложение-бэкдор и устанавливать его заново при обнаружении удаления. К другим способам сохранить вредоносную программу на устройстве относятся сокрытие значка приложения с главного экрана, создание ярлыка вместо значка приложения, отключение антивирусного программного обеспечения и перемещение приложения в доступное только для чтения место, например /system/app.

В Android приложением для получения root-прав называется непривилегированное приложение, которое эксплуатирует уязвимости операционной системы Android или компонентов устройства, характерных для конкретного изготовителя, чтобы получить возможность выполнения кода и привилегии уровня администратора, то есть статус root - наиболее привилегированного пользователя системы с идентификатором пользователя (UID) 0. Поскольку Android применяет ряд механизмов изоляции ресурсов приложений и операционной системы, включая разрешения файловой системы Linux, выполнение процессов с разными UID и политики управления доступом SELinux, непривилегированное приложение, желающее выполнять привилегированные операции, должно найти брешь в безопасности, позволяющую обойти эти механизмы.

Приложения для получения root-прав обычно опираются на известные уязвимости Android, сведения о которых были опубликованы и которым присвоены идентификаторы Common Vulnerabilities and Exposures (CVE). Если исправление такой уязвимости не установлено на устройстве, она может позволить повысить привилегии до уровня root. Однако приложения, эксплуатирующие новые, прежде неизвестные уязвимости, то есть уязвимости нулевого дня, встречаются всё реже. В настоящее время они почти исключительно относятся к сфере деятельности поддерживаемых государствами участников, стоящих за рядом так называемых развитых устойчивых угроз (advanced persistent threats, APT).

Эти уязвимости часто представляют собой ошибки повреждения памяти в компонентах ядра Linux и драйверах устройств, которые служат интерфейсами между системными службами и периферийными устройствами, с одной стороны, и непривилегированными приложениями - с другой. После компрометации этих компонентов, например посредством повреждения стека или внедрения кода, злоумышленник может получить возможность выполнить свой код в контексте привилегированных процессов. Обретя привилегии root, вредоносное приложение может выполнить дополнительные операции, чтобы обеспечить постоянное присутствие в системе, прочитать конфиденциальные данные либо загрузить и установить другие приложения. Например, оно способно прочитать пользовательские данные из каталога другого приложения; изменить конфигурацию системы, в том числе разрешить установку приложений из сторонних источников или отключить Google Play Protect; прочитать токены аутентификации и получить доступ к учётной записи пользователя; либо внедрить вредоносный код в системные библиотеки среды выполнения, чтобы продолжать исполняться даже после перезагрузки.

Получение привилегий root вредоносным приложением на устройстве не означает автоматического получения полного доступа к системным ресурсам. В некоторых случаях, в зависимости от версии операционной системы Android и конфигурации SELinux на устройстве, даже приложения, работающие с правами root, не имеют доступа к некоторым из этих методов, применяемых после получения root-прав. Тем не менее, поскольку конфигурация каждого устройства отличается и может меняться со временем, некоторым приложениям для получения root-прав всё же удаётся добиться успеха.

Некоторые вредоносные программы для получения root-прав несут с собой целую батарею эксплойтов, избирательно запускаемых в зависимости от определённых параметров, например версии Android на скомпрометированном устройстве и наличия конкретных драйверов. В других случаях приложение может последовательно, один за другим, запускать все эксплойты, пока один из них не сработает. Кроме того, как и в других семействах вредоносных программ, приложение способно попытаться динамически загрузить вредоносный код на более позднем этапе. Например, приложение для получения root-прав довольно часто собирает идентифицирующие сведения об устройстве, на котором работает, и отправляет их удалённому серверу, а тот возвращает модуль эксплойта для конкретного устройства. Благодаря этому приложение остаётся приспособленным к новым типам устройств. В то же время разработчику эксплойтов не приходится раскрывать свои карты, передавая всю библиотеку эксплойтов.

Важно отметить различие между невредоносными и вредоносными приложениями для получения root-прав. Невредоносные приложения открыто заявляют, что являются инструментами для получения root-прав на устройстве, и не выполняют в фоновом режиме других опасных действий. Вредоносное получение root-прав, напротив, имеет место, когда приложение не раскрывает своего назначения и пытается получить root-прав без согласия пользователя. В обоих случаях команда Android Security пометит такие приложения как вредоносные из-за их влияния на безопасность системы. Однако, хотя запуск невредоносного приложения для получения root-прав может оставить систему в уязвимом состоянии, пользователи всё равно вправе установить его и проигнорировать предупреждения Google Play Protect или других сканеров вредоносных программ. Экосистема Android предоставляет пользователю такую свободу.

Приложения-трояны выглядят безобидно, например могут выдавать себя за популярное приложение, но содержат скрытые функции, выполняющие нежелательные действия. У таких приложений есть безвредный компонент, который завоёвывает доверие пользователя, предоставляя ему полезные функции. Однако помимо этого компонента в них присутствует невидимая пользователю вредоносная логика.

Один из очень распространённых приёмов, применяемых создателями троянов и других вредоносных программ для уклонения от обнаружения, состоит в том, чтобы сначала опубликовать чистый APK, проходящий все проверки Google Play и попадающий на устройства пользователей. Через несколько дней или недель они создают и публикуют новую версию APK, на этот раз включающую вредоносные функции, которые пользователь установит в составе обновления приложения. Преимущество данного приёма в том, что вредоносное приложение успевает сформировать базу установок, не опасаясь удаления из Google Play или с устройств пользователей. Если опасное обновление успешно пройдёт проверку Google Play, новые функции могут быть установлены на тысячах устройств.

Вредоносные приложения, включая трояны, также злоупотребляли доступной в Android функцией, которая позволяет Java-коду вызывать код не на Java, скомпилированный для аппаратной части устройства. Этот интерфейс Java Native Interface (JNI) позволяет приложению загружать библиотеки, обычно хранящиеся в файлах .so, которые входят в APK и могут содержать вредоносный код. Если сканер вредоносных программ проверяет только байт-код Java или декомпилированный Java-код, вредоносная логика в таких специализированных аппаратных библиотеках может остаться для него невидимой. Мы действительно встречали образцы вредоносных программ, которые явно использовали нативный код без какой-либо причины, кроме сокрытия от сканеров. Например, некоторые вредоносные программы целиком написаны на Java, за исключением простейшей функции расшифрования в нативном коде или даже небольшой функции нативного кода, которая лишь возвращает ключ шифрования, используемый Java-кодом. Механизмы статического анализа, не поддерживающие межархитектурный анализ потоков управления и данных, окажутся в тупике даже перед такими простыми приёмами.

Приложения-трояны способны скрытно выполнять самые разные операции. Например, некоторые банковские трояны атакуют пользователей мобильного банкинга, выдавая себя за популярные приложения для денежных переводов, внесения чеков и других операций со счётом. Если пользователя обманом заставят загрузить поддельное приложение, он может в итоге передать мошенникам учётные данные своего счёта. Другие приложения могут дождаться запуска законного банковского приложения, а затем попытаться перехватить имена пользователей и пароли, накладывая поверх законного приложения формы ввода, которые собирают пользовательские данные. Во время аутентификации банковское приложение может отправить на устройство пользователя одноразовый пароль (OTP), а приложение-троян - попытаться прочитать соответствующее текстовое сообщение.

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

За последние несколько лет некоторые приложения прокси-сетей были помечены как вредоносные. Подобные прокси-службы позволяют платящим клиентам анонимно обращаться к сетевым ресурсам, которые в противном случае были бы защищены межсетевыми экранами и ограничениями по IP-адресам. Например, с их помощью пользователь из страны A может получить доступ к ресурсу в стране B. Проблема этих приложений в том, что они часто не сообщают пользователю о превращении его устройства в выходной узел прокси-сети и о том, что ресурсы его системы будут передавать чужой трафик, потенциально связанный с незаконной деятельностью.

Ещё один тип троянов, появившийся несколько лет назад, - вредоносные программы для добычи криптовалюты. Они заражают большое количество устройств и используют их системные ресурсы, какими бы ограниченными те ни были, для фоновой добычи криптовалюты. Во многих случаях добыча ведётся без какого-либо уведомления пользователя, и без его согласия расходуются заряд аккумулятора и вычислительная мощность устройства. Даже когда пользователь знает о добыче, возможная финансовая выгода для него крайне мала.

Некоторые приложения-трояны позволяют злоумышленнику дистанционно управлять целевым устройством. Они обладают рядом общих черт с приложениями-бэкдорами и обычно называются троянами удалённого доступа (remote access trojans, RAT). Вредоносная программа RAT скрывает своё назначение, выдавая себя за безобидную, и часто использует перехватчики нажатий клавиш, получение root-прав и другие способы устанавливать приложения, выполнять команды и похищать пользовательские данные.

Цель шпионской программы - без согласия пользователя найти, собрать и передать его персональные данные. Эти данные могут быть проданы третьей стороне или использованы для изучения поведения пользователя, например чтобы предлагать ему приложения, которые могут его заинтересовать. В наиболее серьёзных случаях приложение может фактически следить за пользователем, получая доступ к его физическому местоположению посредством чтения данных GPS или иными способами, фотографиям, истории просмотра сайтов, истории поиска, списку установленных приложений, текстовым сообщениям и журналу вызовов. Некоторые шпионские программы доходят до включения камеры или микрофона, пытаясь установить личность пользователя, наблюдать за его действиями или прослушивать разговоры.

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

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

В определении шпионской программы, которым пользуется команда Android Security, основное внимание уделяется сбору данных, при котором личность жертвы не имеет значения: собранные сведения массово перепродаются или иным образом монетизируются без учёта интересов затронутых людей. Вредоносные программы, применяемые для слежения за конкретными известными лицами, называются сталкерскими программами (stalkerware), а иногда - коммерческими шпионскими программами или программами для слежения за супругами (spouseware).

Разумеется, мобильные приложения, рекламируемые как средство слежения за кем-либо, могут применяться с полного согласия всех заинтересованных сторон. Однако некоторым из таких приложений не хватает надлежащих средств контроля, и в результате злоупотреблений они превратились в распространённый инструмент нездоровых отношений; их можно найти на миллионах телефонов. Если кто-либо хочет отслеживать местоположение партнёра или видеть отправляемые и получаемые им текстовые сообщения, быстрый поиск в интернете по фразе «слежка за девушкой/парнем/мужем/женой» обнаружит процветающую отрасль, где подобное программное обеспечение для наблюдения можно приобрести примерно за 50 долларов.

Сталкерские приложения, как бесплатные, так и платные, не уведомляют владельца устройства о своём присутствии достаточно заметным образом. Например, некоторые приложения могут рекламироваться как средства родительского контроля, позволяющие членам семьи присматривать друг за другом и в отдельных случаях управлять мобильными устройствами родных, в том числе видеть установленные приложения и посещённые URL-адреса. Однако при неправильном проектировании эти приложения могут позволить одному пользователю тайно следить за другими.

Обычно преследователь устанавливает сталкерское приложение на оставленное без присмотра устройство жертвы. Во время настройки он указывает в приложении свой адрес электронной почты или номер телефона. Многие коммерческие сталкерские продукты предлагают даже веб-интерфейс. После этого преследователь может с удобством полностью управлять устройством через данный веб-интерфейс.

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

Фишинговые приложения пытаются похитить учётные данные или платёжную информацию пользователя, запрашивая её у него либо перехватывая при передаче. Их частыми целями становятся номера кредитных карт, номера банковских счетов, учётные данные криптовалютных кошельков, имена пользователей, пароли, персональные идентификационные номера (PIN) и другие факторы аутентификации, например одноразовые пароли. Перехватив данные, приложение отправляет их по сети в систему, контролируемую третьей стороной. В некоторых случаях, если похищенные учётные данные открывают доступ к закрытой системе или сети, последствия могут затронуть не только отдельного человека и привести к масштабному взлому, шпионажу или краже конфиденциальной информации, включая интеллектуальную собственность.

Приложения применяют различные фишинговые методы. Например, отдельные фишинговые приложения выдавали себя за популярные приложения электронной почты, социальных сетей или финансовых служб, используя похожие имена пакетов, логотипы и оформление. Сразу после запуска приложение может попросить пользователя ввести учётные данные, затем сообщить об ошибке при входе и перенаправить его на правильный сайт. К этому моменту вред уже причинён: приложение отправит учётные данные на сервер, где централизованно собираются похищенные сведения, которые впоследствии могут быть проданы в даркнете или на других подпольных форумах. Такой приём использовался и во вредоносных кампаниях, направленных против приложений криптовалютных кошельков и выманивающих учётные данные кошелька пользователя. Эти сведения позволяют злоумышленнику перевести средства на собственные счета.

Приложения для обмена сообщениями и иные коммуникационные приложения также могут способствовать фишингу. Встроенные в сообщение ссылки подвергают пользователей риску, если ведут на фишинговые сайты или сайты загрузки приложений. С помощью социальной инженерии злоумышленник может убедить пользователей перейти по ссылке, в результате чего они загрузят вредоносное приложение или раскроют конфиденциальные сведения мошенническому сайту.

К категории фишинговых вредоносных программ относятся и приложения, перехватывающие учётные данные при передаче, а не получающие их непосредственно от пользователей. Например, известные вредоносные программы злоупотребляли службой, позволяющей операторам мобильной связи передавать телефонам конфигурацию маршрутизации трафика, чтобы вставить прокси-сервер между устройством и оператором. Установленное на устройстве приложение сначала извлекает международный идентификатор абонента мобильной связи (International Mobile Subscriber Identity, IMSI) с помощью разрешения Android READ_PHONE_STATE и передаёт его серверу управления. Затем сервер отправляет устройству текстовое сообщение с параметрами Open Mobile Alliance Client Provisioning (OMA CP), предлагая пользователю установить новую конфигурацию с изменённой маршрутизацией пакетов данных. В результате трафик приложений на устройстве, включая электронную почту и веб-трафик, которые могут содержать учётные данные для аутентификации, платёжные сведения или другую пользовательскую информацию, будет направлен через прокси-сервер, контролируемый третьей стороной.

Если приложение часто загружают, обычно возникают возможности его монетизации. Этот стимул привёл к созданию большого количества приложений, основная задача которых - устанавливать другие приложения. Разработчики безвредных приложений иногда платят таким установщикам за улучшение своих показателей. К сожалению, теми же службами пользуются некоторые разработчики вредоносных программ. Приложение, которое не совершает ничего опасного, кроме загрузки вредоносных приложений, считается враждебным загрузчиком. За прошедшие годы приложения этого типа становились отправной точкой многочисленных вредоносных кампаний.

Некоторые враждебные загрузчики каждый раз устанавливают один и тот же набор приложений. В других случаях тип и количество устанавливаемых ими приложений меняются. Во всех случаях для определения того, следует ли считать приложение враждебным загрузчиком, нужны данные о типах установленных приложений и количестве установок. Например, одни приложения устанавливают очень небольшое количество опасных программ, тогда как другие главным образом распространяют вредоносные программы. Команда Android Security использует различные критерии, определяющие границу между безвредными и враждебными загрузчиками, и помечает приложение как вредоносное, когда оно эту границу пересекает. Например, на момент написания книги приложение считается враждебным загрузчиком, если вредоносные программы составляют не менее 5 процентов его загрузок и оно загрузило как минимум 500 приложений, безвредных или иных. Основные браузеры и приложения для обмена файлами не считаются враждебными загрузчиками при условии, что загрузка требует взаимодействия с пользователем и загрузку любой вредоносной программы непосредственно инициирует сам пользователь.

Для установки других приложений враждебные загрузчики обычно используют два доступных разрешения: INSTALL_PACKAGES и REQUEST_INSTALL_PACKAGES. Первое из них, INSTALL_PACKAGES, обладает большей силой, поскольку позволяет приложению устанавливать другие приложения без участия пользователя. Из-за риска злоупотребления этим разрешением могут пользоваться только предустановленные приложения.

Более безопасное разрешение REQUEST_INSTALL_PACKAGES появилось в Android 8.0 (Oreo) и доступно всем приложениям Android. Оно позволяет приложению запрашивать установку других приложений, например после успешной установки исходного приложения. Если REQUEST_INSTALL_PACKAGES объявлено в файле манифеста приложения, перед использованием намерения ACTION_INSTALL_PACKAGE для установки APK у пользователя будет запрошено подтверждение. Это разрешение затрудняет разработчикам враждебных загрузчиков принудительную установку приложений, поскольку требует вмешательства пользователя. До Android 8.0 (Oreo) все приложения могли запускать процесс установки с согласия пользователя. Новое разрешение явно показывает пользователю, какие приложения способны устанавливать другие приложения.

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

Враждебные загрузчики, не имеющие разрешения устанавливать другие приложения, могут искать альтернативные способы. Например, они могут попытаться получить root-права на устройстве, чтобы обратиться к файловой системе и скопировать APK. Затем они способны попытаться злоупотребить PackageManager в некоторых версиях Android, чтобы фактически установить приложения. Последние версии Android запрещают непосредственное копирование файлов по абсолютным путям, чем пользовались некоторые враждебные загрузчики, и требуют применять FileProvider - более безопасный способ обработки файлов. В отдельных случаях, если приложение нельзя быстро получить и установить, враждебный загрузчик может сначала скачать файл .apk с помощью разрешения INTERNET, а затем записать его на SD-карту, например в папку Downloads, с помощью разрешения WRITE_EXTERNAL_STORAGE. Позже, на втором этапе, загрузчик попытается получить разрешение INSTALL_PACKAGES и установить ранее загруженные файлы.

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

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

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

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

2. Приложения, которым удаётся найти способы обхода разрешений.

3. Приложения, отключающие функции безопасности и защиты на устройстве.

4. Приложения, не позволяющие пользователю управлять своим устройством.

Приложения, которые отключают функции безопасности или изменяют конфигурацию системы таким образом, что устройство остаётся в уязвимом состоянии, помечаются как приложения для повышения привилегий. В качестве примера можно привести предустановленные приложения, злоупотребляющие системными привилегиями, например разрешением WRITE_SECURE_SETTINGS или методами Settings.Global и Settings.Secure, чтобы перед собственным обновлением либо загрузкой и установкой других вредоносных программ отключить проверку Google Play Protect. В прошлом другие приложения для повышения привилегий добивались той же цели - отключения параметров безопасности - посредством выполнения команд оболочки вместо использования Android API, а третья группа изменяла параметры безопасности, модифицируя настройку package_verifier_enable, от которой зависит поведение проверки вредоносных программ на устройстве.

Ещё одной целью вредоносных программ была SELinux, дополняющая модель разрешений файловой системы политиками, которые запрещают доступ к конфиденциальным ресурсам независимо от разрешений конкретного файла. При включённой SELinux некоторые эксплойты могут не сработать, поскольку полученных в результате привилегий окажется недостаточно для доступа к желаемым ресурсам. Например, некоторым приложениям для взлома лицензий, которые изменяют код игровых приложений ради обхода проверки лицензии и покупки, необходим доступ на запись к файловой системе, чтобы создавать исправленные версии приложения. При включённой надлежащей политике SELinux подобные изменения блокируются, и одним из первых действий вредоносной программы должна стать попытка отключить SELinux. Например, для этого она может выполнить команду setenforce 0, переводящую SELinux из так называемого принудительного режима в разрешительный. Следует отметить, что на современных устройствах как минимум с Android 5.0 (Lollipop) разрешительный режим поддерживается только в сборках userdebug и eng - особых конфигурациях устройств Android, обычно предназначенных для разработки и тестирования. На обычных устройствах конечных пользователей отключить SELinux быть не должно.

Некоторые приложения в целях повышения привилегий изменяют настройку install_non_market_apps. Устройства Android позволяют пользователю устанавливать приложения из любого источника. Однако данная настройка запрещает приложениям устанавливать дополнительные приложения из источников, отличных от Google Play, поскольку в таких источниках выше риск распространения вредоносных программ. Если приложение автоматически и без согласия пользователя изменяет эту настройку, оно будет помечено как вредоносное, поскольку может оставить устройство в уязвимом состоянии.

Авторы вредоносных программ также злоупотребляли API управления устройством, реализованными в таких классах, как DevicePolicyManager или DeviceAdminReceiver. Эти интерфейсы позволяют управлять устройством посредством набора политик, прежде всего в корпоративных развёртываниях, в том числе сбрасывать пароли и ограничивать срок их действия, стирать разделы с пользовательскими данными посредством сброса до заводских настроек и требовать шифрования хранимых данных. Разработчики вредоносных программ использовали API управления устройством, чтобы предотвратить удаление своих приложений. Например, некоторые семейства вредоносных программ, встречавшиеся в реальных условиях, вызывают resetPassword и lockNow, чтобы заблокировать устройство, когда действие пользователя приводит к обратному вызову onDisableRequested, который пытается отозвать у потенциально опасного приложения привилегии администратора устройства. В других случаях приложение может отслеживать обращения пользователя к системным настройкам и запускать то же поведение, лишая владельца доступа к устройству.

Начиная с Android 9.0 (Pie) API управления устройством постепенно выводятся из употребления, отчасти в ответ на злоупотребления вредоносных программ, поскольку в прошлом ряд приложений для повышения привилегий использовал их как средство управления устройством без согласия пользователя. До этого интерфейсы претерпели изменения, сократившие возможности злоупотребления ими. Например, начиная с Android 7.0 (Nougat)

метод resetPassword можно использовать только для установки новых паролей устройства, но не для изменения уже существующих. Благодаря этому пользователи, у которых на устройстве уже задан пароль, не могут лишиться доступа к нему.

Последняя настройка, о которой следует упомянуть, - upload_apk_enable. Она определяет, передаёт ли устройство образцы APK системе Google Play Protect, чтобы помочь выявлять вредоносные программы. Авторы вредоносных программ могут пытаться отключить её, желая замедлить обнаружение своих приложений.

Следует также отметить, что некоторые приложения перед запуском полагаются на другие приложения, ослабляющие защищённость устройства. Например, отдельные семейства вредоносных программ включают компонент для получения root-прав, задача которого состоит в ослаблении защиты среды выполнения и файловой системы в качестве подготовки к тому, чтобы другие приложения фактически получили доступ к ставшим доступными данным. Некоторые из этих вторичных приложений пользуются уязвимым состоянием системы, чтобы обращаться, например, к файлу accounts.db, содержащему токены, которые позволяют устройству получать доступ к ряду служб. Такие приложения могут прочитать, а затем отправить основные токены Google OAuth и токены ClientLogin для Google Play. В других случаях атрибутами файлов манипулируют, чтобы затруднить их изменение или удаление: например, объявляют файлы доступными только для чтения, перемещают их в привилегированные разделы либо усложняют удаление с помощью команды оболочки chattr, устанавливая атрибуты +ia. Файл с этими атрибутами можно открыть для записи только в режиме добавления; удалить или переименовать его нельзя.

Приложение считается программой-вымогателем, если оно получает контроль над данными или устройством пользователя и выдвигает требования за освобождение от этого контроля. Такие требования могут включать выплату выкупа или просьбу к пользователю совершить действие против своей воли. В экосистеме Android наблюдаются два основных способа работы программ-вымогателей: лишение доступа к пользовательским данным посредством их шифрования на устройстве ключом, контролируемым злоумышленником, и блокировка доступа пользователей к устройствам либо с помощью настоящего механизма блокировки экрана, либо путём приведения графического интерфейса в состояние, в котором невозможно использовать ничего, кроме приложения-вымогателя.

Программам-вымогателям, шифрующим пользовательские данные, сначала требуется получить разрешение на запись в файловую систему, например WRITE_EXTERNAL_STORAGE. После этого они могут исследовать файловую систему, проверяя состояние определённых файлов и каталогов посредством getExternalStorageState. В некоторых случаях приложение считывает все файлы из внешнего хранилища и записывает их обратно в зашифрованном виде с помощью методов java.io.File.* и ключа шифрования. В других случаях шифруются только изображения и сообщения, но не файлы иных форматов. При любом варианте приложение показывает пользователю уведомление, объясняющее порядок отправки платежа; часто в нём требуют криптовалюту, чтобы скрыть личность преступника. В сообщении также описывается, как пользователь получит ключ расшифрования и восстановит свои файлы.

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

Другие приложения не шифруют никаких данных, а вместо этого блокируют доступ к устройству, показывая записку вымогателя, которая занимает весь экран и которую пользователь не может закрыть. Записка остаётся даже после перезагрузки. Такая атака не позволяет пользователю обращаться к интерфейсу устройства и выполнять в том числе такие действия, как совершение звонков или чтение сообщений. Для показа подобного окна поверх остальных некоторые приложения используют разрешение SYSTEM_ALERT_WINDOW. Сначала они определяют работающие на устройстве процессы, вызывая getRunningServices, проверяя идентификаторы процессов в /proc из командной строки или выявляя активность на переднем плане посредством getRunningTasks. Затем они вызывают startActivity, чтобы отобразить своё окно поверх других работающих приложений.

Приложение-вымогатель также может использовать доступное в некоторых версиях Android разрешение BIND_DEVICE_ADMIN, а затем вызывать методы DevicePolicyManager, например resetPassword и lockNow, чтобы изменить пароль устройства.

Некоторые приложения причиняют пользователю прямой финансовый ущерб. Именно так действуют вредоносные программы, использующие текстовые сообщения для мошенничества. Категория мошенничества с SMS включает приложения, отправляющие сообщения SMS или MMS на специальные номера, называемые короткими. Обычно они содержат от трёх до восьми цифр, например 1234, а отправка SMS на такой номер оплачивается пользователем по повышенному тарифу. Подобные платные сообщения были созданы для законных целей: например, чтобы пользователи могли отправлять пожертвования пострадавшим от стихийных бедствий, голосовать за исполнителя в телевизионном шоу или подписываться на информационные службы с доставкой по SMS, в том числе на ежедневные новости, шутки, прогноз погоды или гороскопы. Хотя операторы связи поддерживают такие сообщения, сами услуги могут оказывать третьи стороны.

Мошеннические приложения отправляют SMS намеренно обманным способом. Они злоупотребляют разрешением SEND_SMS, вызывая без участия пользователя такие API, как sendTextMessage, sendMultimediaMessage или sendMultipartTextMessage, и активно подавляют любые уведомления, чтобы избежать обнаружения. В некоторых случаях пользователь узнаёт о мошеннических списаниях со своего счёта, только когда просматривает телефонный счёт.

Даже если получатель является обычным номером, но приложение не сообщает пользователю об отправляемых текстовых сообщениях, оно может быть заблокировано за нарушение правил Google Play, которые защищают пользователей от отправки SMS без согласия. Однако если номер короткий и предназначен для платных услуг, приложение будет помечено как вредоносное, поскольку такие SMS непосредственно создают для пользователя расходы. Android предупреждает пользователя об отправке платного SMS. Однако это предупреждение не считается уведомлением о поведении приложения; отправляющее сообщение приложение должно само ясно и заметно сообщить о таком действии.

Иногда мошеннические SMS-приложения содержат готовый список платных номеров. Затем они проверяют страну и оператора мобильной связи устройства, чтобы выбрать из списка определённый номер. В других случаях номер получателя динамически загружается с сервера управления, что предоставляет мошеннику гибкость и возможность добавлять новые номера.

Такие приложения могут также маскировать подписку на платные SMS, скрывая соглашения об условиях либо сообщения мобильного оператора, уведомляющие пользователя о списаниях или новых подписках.

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

Многие технологии платежей и расчётов позволяют пользователям приобретать товары и подписываться на услуги, просто добавляя платёж в счёт за мобильную связь. Это удобное решение для стран, где кредитные или дебетовые карты не получили широкого распространения. К таким технологиям относятся прямое выставление счетов оператором (direct carrier billing, DCB), протокол беспроводных приложений (Wireless Application Protocol, WAP) и передача средств мобильной связи (mobile airtime transfer, MAT), которые учитывают баланс данных и времени связи пользователя, его действия и покупки. Поскольку эти системы управляют списаниями, а покупки можно совершать относительно незаметно - в некоторых случаях одним нажатием или простым подтверждением номера телефона, на который будет выставлен счёт, - они становятся привлекательной целью для мошенников.

Одно из первых действий, которое приложения для мошенничества с платными услугами выполняют ради выставления счёта через оператора, - отключение Wi-Fi. Когда устройство пользуется сетью Wi-Fi, оно не задействует управляемое оператором мобильное соединение для передачи данных, например LTE, 3G или 4G. Вместо этого весь создаваемый устройством трафик проходит через точку доступа Wi-Fi пользователя и поставщика услуг интернета (ISP). Приложения могут отключить Wi-Fi, например с помощью API setWifiEnabled, и включить мобильную передачу данных посредством API setMobileDataEnabled. После этого приложение может открыть в WebView с включённым JavaScript веб-страницу подписки на услугу, а затем внедрить JavaScript, который автоматически нажмёт кнопки для оформления подписки. Служба может отправить на мобильное устройство текстовые сообщения с подтверждением подписки, но мошенническое приложение перехватит и удалит их, не позволив пользователю узнать о мошеннических действиях.

Приложения для мошенничества с платными услугами часто злоупотребляют следующими разрешениями: CHANGE_WIFI_STATE, необходимым для перехода на мобильную передачу данных; RECEIVE_SMS или READ_SMS, позволяющими читать коды подтверждения и уведомления о подписке; READ_PHONE_STATE, позволяющим получить номер телефона или иные идентификаторы устройства, необходимые для подписки пользователя на услугу. В последнее время, после изменения правил Google Play, ужесточившего требования к приложениям, использующим текстовые сообщения, приложения для мошенничества с платными услугами начали злоупотреблять разрешением BIND_NOTIFICATION_LISTENER_SERVICE для доступа к входящим сообщениям.

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

Категория вредоносных программ для мошенничества со звонками состоит из приложений, которые без согласия или ведома пользователя звонят на платные номера и тем самым создают начисления в его телефонном счёте. Как и мошенничество с SMS, данный вид злоупотребления опирается на удобную функцию, предлагаемую многими операторами связи: возможность приобретать товары и подписываться на услуги по телефону с добавлением их стоимости в телефонный счёт пользователя для последующей оплаты. В некоторых случаях расчётный счёт может быть связан с автоматическими платежами с кредитной карты или банковского счёта. Тогда пользователь может не заметить, что с него взимается плата за звонки на платные номера.

Чтобы скрыть звонки, мошеннические приложения могут применять разрешение CALL_PHONE, которое позволяет начинать их без интерфейса приложения Dialer на устройстве, иначе пользователь получил бы визуальное предупреждение. Тем не менее пользователь потенциально способен услышать звонок. Для отключения звука некоторые вредоносные программы используют метод setStreamVolume класса AudioManager, управляющий громкостью аудиопотоков, и устанавливают минимальный уровень громкости.

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

Спам-приложения отправляют пользователям незапрошенные сообщения или используют устройство как ретранслятор почтового спама, зачастую для рекламы товаров или услуг.

Список целей для рассылки спама может быть получен из телефонной книги пользователя или списков контактов приложений социальных сетей, например Facebook и WhatsApp. Он также может динамически предоставляться сервером управления или загружаться с веб-сервера. Собрав список целей, приложение начинает незаметно отправлять им сообщения. В некоторых случаях используются текстовые сообщения. В других приложение может попытаться отправлять сообщения через API, например Facebook API, хотя для этого пользователь должен войти в систему. В настоящее время вредоносные программы для рассылки спама встречаются редко. Мы включили их сюда для полноты.

Многие приложения Android способны получать рекламу из рекламной сети и показывать её пользователю. Когда приложение показывает объявление, издателю и сети засчитывается его показ - показатель, называемый impression. Когда пользователь действительно нажимает объявление, рекламодатели обычно вознаграждают издателей за клики, которые те помогли получить.

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

При мошенничестве с кликами приложение получает объявления из рекламной сети и без участия или уведомления пользователя автоматически создаёт клики. Например, это могут быть смоделированные через Java API клики внутри приложения или клики, инициированные JavaScript-кодом, загруженным в WebView. В некоторых случаях приложение скрывает объявления, затрудняя их обнаружение пользователем, посредством минимальных размеров, например 1 x 1 пиксель. В других случаях пользователь видит объявление, но не понимает, что приложение создаёт события клика в фоновом режиме.

Трафик приложений для мошенничества с кликами искусственно завышает количество кликов, связанных с объявлением. Сеть отслеживает это количество и сообщает его рекламодателю, который платит за клики, хотя они не были вызваны настоящим интересом пользователей. Такие вредоносные программы обманывают рекламодателей, чьи рекламные бюджеты и показатели конверсии могут пострадать, подрывая их доверие к экосистеме. Мошенничество с кликами способно затронуть и пользователей, когда значительный объём поддельного рекламного трафика расходует лимит мобильных данных и заряд аккумулятора, а пользователям показывают нерелевантные объявления.

Второй класс мошенничества с рекламой - мошенничество с атрибуцией, которое происходит, когда приложение пытается изменить данные, используемые для отнесения показа объявления или установки приложения к определённому источнику перехода или издателю. Например, если показанное приложением объявление связано с идентификатором источника перехода, рекламная сеть отслеживает этот идентификатор, чтобы вознаграждение получил надлежащий источник. Однако приложение для мошенничества с атрибуцией может прослушивать широковещательные намерения, содержащие идентификаторы источника перехода, а затем отправлять рекламной сети поддельный трафик, который изменяет идентификатор. В результате вознаграждение за показы получит кто-то другой. Иногда код, реализующий мошенничество с атрибуцией, входит в комплект разработчика программного обеспечения (SDK) - набор инструментов, который разработчики приложений могут включить в свои программы, не зная, что тот содержит код, пытающийся перенаправить вознаграждение за рекламу или установку приложения.

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

Команда Android Security определяет последнюю категорию вредоносных программ: угрозы не для Android. Такие приложения содержат определённое вредоносное поведение, но не способны непосредственно причинить вред пользователям Android. В большинстве случаев эта категория применяется для маркировки приложений Android, содержащих вредоносную программу для Windows, почти всегда потому, что компьютер разработчика приложения во время сборки был заражён вредоносной программой Windows. Использование этой категории приносит пользу прежде всего разработчикам приложений, поскольку сообщает им о проблеме с программой. Пользователям Android вредоносные компоненты приложения фактически не причинят вреда.

Злоумышленники быстро обнаружили Android. Платформа появилась в 2008 году, когда преступные предприятия, создававшие вредоносные программы, уже начали злоупотреблять другими операционными системами. Всего через полтора года быстро завоёванная доля рынка сделала Android коммерчески интересной для преступных авторов вредоносных программ, а в 2010 году первый образец вредоносной программы для Android появился в Google Play, который тогда назывался Android Market.

По сей день почти все известные вредоносные программы для Android нацелены на незаконное получение прибыли. Это отличает их от гораздо более старого мира вредоносных программ DOS, Windows и Linux, где десятилетия технических новшеств предшествовали превращению прибыли в основную мотивацию авторов. В сравнении с ними вредоносные программы для Android интересны прежде всего исследованием всё новых способов массовой эксплуатации смартфонов для заработка, невозможных на настольных системах.

После первых громких инцидентов команда Android Security разработала план защиты Google Play от вредоносных программ. Для обхода новых средств защиты их авторы выбрали несколько стратегий: продолжать разрабатывать вредоносные программы для выпуска в Google Play, что требовало вложений в способы обхода сканеров Google Play; разрабатывать вредоносные программы для распространения через сторонние сайты и магазины приложений, то есть установки из сторонних источников, что требовало вкладываться в привлекающие пользователей методы продвижения; разрабатывать вредоносные программы для предустановки на устройства, что требовало вложений в социальную инженерию и такие стратегии, как создание подставных компаний, которые обманом убеждали изготовителей включать вредоносные программы в устройства во время производства. В этой главе подробно рассматриваются вредоносные программы, распространяемые всеми перечисленными способами.

В августе 2010 года российская компания в сфере безопасности «Лаборатория Касперского» обнаружила вредоносную программу за пределами Google Play. Она получила название DroidSMS и была описана в записи блога «First SMS Trojan for Android»; её часто считают первым семейством вредоносных программ для Android.

DroidSMS использовалась для отправки с устройств пользователей дорогостоящих SMS на платный номер, заранее зарегистрированный мошенниками. Когда пользователь устанавливал и запускал DroidSMS, приложение незаметно отправляло сообщение. Затем с пользователя списывалась небольшая сумма, поступавшая авторам вредоносной программы. Пострадавшие узнавали о незаконном списании только после получения следующего телефонного счёта, и то лишь в том случае, если удосуживались проверить его на наличие необъяснимых начислений.

Вся эта тайная деятельность с SMS происходила в пределах модели безопасности платформы Android. В частности, система разрешений Android работала как задумано: она показывала диалоговое окно с вопросом, разрешает ли пользователь DroidSMS отправлять сообщения. В то время Android часто предоставляла пользователям право принимать решения, влияющие на безопасность. Согласно господствовавшему тогда взгляду, Android являлась открытой системой, поэтому пользователи должны были самостоятельно выбирать параметры безопасности и конфиденциальности, а Android и Google Play - лишь предоставлять сведения, необходимые для таких решений. Однако вскоре в Google Play стали появляться приложения, злоупотреблявшие отсутствием у многих пользователей привычки думать о безопасности.

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

Через несколько месяцев после появления DroidSMS положение с вредоносными программами для Android ухудшилось. В марте 2011 года расположенная в Сан-Франциско компания Lookout Mobile Security обнаружила в Google Play нового трояна, которому дала имя DroidDream. Как рассказывалось в записи блога Lookout «Security Alert: DroidDream Malware Found in Official Android Market», DroidDream пошла дальше прежних вредоносных программ для Android, вырвавшись за границы модели безопасности Android. Используя эксплойт для повышения привилегий Rage Against the Cage, также известный как CVE-2010-EASY, DroidDream эксплуатировала уязвимость операционной системы Android и получала привилегии root.

DroidDream стала поворотным моментом для команды Android Security. Поскольку затронутые устройства оказывались скомпрометированы навсегда и пользователи не могли вернуть их в безопасное состояние, проверка безопасности приложений Google Play до их попадания к пользователям стала обязательной. Команда Android Security быстро объявила, что удалит с устройств уже установленные экземпляры DroidDream, что должно было спасти хотя бы тех пользователей, которые установили, но ещё не открыли заражённые приложения.

Ранее попыток дистанционно удалять приложения не предпринималось, а удаление DroidDream с устройств опиралось на специальный обходной механизм, встроенный в приложение Google Play. Учитывая очевидную ценность дистанционного удаления, команда Android Security добавила его в Google Play Protect как официальную функцию. В настоящее время команда регулярно защищает пользователей Android, дистанционно удаляя подозреваемые вредоносные приложения из категорий высокого риска, например банковский фишинг и программы-вымогатели, а также трояны для получения root-прав, подобные DroidDream.

Это крупное семейство вредоносных программ для мошенничества с SMS, существовавшее в ранние годы Android, делало вид, что предлагает обои для главного экрана. Несмотря на масштаб семейства, до сих пор оно не было открыто описано.

Как и все ранние вредоносные программы Android, оно не защищалось от анализа. Приложения выполняли вредоносную нагрузку без какой-либо обфускации или иных уловок, способных сбить исследователей безопасности со следа. Например, в листинге 2-1 показана функция мошенничества с SMS в com.kk4.SkypeWallpapers (v3, 8cab). Приложение проверяет, работает ли оно на российском телефоне, и, если да, вызывает метод makeRelation, чтобы без уведомления отправить платное SMS.

Листинг 2-1. Мошенничество с платными SMS в com.kk4.SkypeWallpapers (v3, 8cab)

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

Это крупное безымянное семейство вредоносных программ для мошенничества с SMS не имеет общедоступной документации. Оно часто маскировалось под приложения камеры или другие системные служебные программы, начало действовать в середине 2011 года и оказалось сложнее семейства Wallpaper.

Вместо того чтобы атаковать только российских пользователей, вредоносная программа собирала сведения о стране устройства и операторе мобильной связи, отправляла их серверу управления и получала в ответ номер телефона и текст SMS для отправки. Этот приём позволял действовать в разных странах и выходить в новые страны без обновления приложений. В листинге 2-2, взятом из com.batterypro (v4, 29ee), показан сбор данных для профилирования устройства.

Листинг 2-2. Приложение com.batterypro (v4, 29ee) собирает сведения об устройстве, которые позднее используются для настройки мошенничества с SMS

Как безвредные, так и вредоносные приложения часто записывают собираемые этой программой данные, например международный идентификатор мобильного оборудования (International Mobile Equipment Identity, IMEI) устройства. Поскольку номера IMEI являются глобально уникальными идентификаторами, их можно использовать для создания цифровых отпечатков устройств, распознавания отдельных пользователей и связывания других собранных данных с конкретным устройством.

Чтобы ограничить злоупотребление IMEI для отслеживания пользователей, Android 10 начала защищать доступ к IMEI и другим подобным аппаратным идентификаторам с помощью специального разрешения READ_PRIVILEGED_PHONE_STATE. Это разрешение недоступно приложениям из Google Play. Приложениям, которым нужен доступ к таким аппаратным идентификаторам, приходится искать другие способы распространения.

Хотя в 2012 году мошенничество с SMS составляло около 20 процентов вредоносных программ Android и привлекало больше всего внимания общественности, наличие конфиденциальных данных на мобильных телефонах также привело к появлению шпионских программ. Более того, в ранние годы Google Play именно шпионские программы были самой распространённой категорией вредоносных программ, а крупнейшим из ранних семейств являлась Cricketland.

Cricketland, до настоящего времени не описанная публично, представляла собой SDK, встроенный в выглядевшие законными приложения из Вьетнама. Неясно, знали ли разработчики приложений, использовавшие этот SDK, о его шпионских функциях. Без согласия пользователя SDK отправлял сведения из его списка контактов на удалённый сервер. Команда Android Security назвала семейство Cricketland по имени пакета SDK - net.cricketland.

Код Cricketland не отличался особой сложностью. Когда приложение с Cricketland инициализировало SDK, тот собирал всевозможные сведения и загружал их на страницу, размещённую в Google Drive. Одним из примеров приложения, использовавшего SDK Cricketland, было masteryourgames.amazingalextoolbox (v12, c4f0). Код сбора данных показан в листинге 2-3.

Листинг 2-3. Код сбора данных Cricketland в masteryourgames.amazingalextoolbox (v12, c4f0)

Команда Android Security считает шпионским любое приложение, которое без согласия пользователя собирает его список контактов. Сбор сведений о местоположении телефона или учётных записях без согласия пользователя также проблематичен и подпадает под правила Google в отношении нежелательного программного обеспечения для мобильных устройств. Поскольку сведения об учётных записях включают все учётные записи, зарегистрированные на устройстве, вредоносная программа может с их помощью связать адрес электронной почты пользователя с его профилем LinkedIn, именем в X, страницей Facebook и другими ресурсами.

Опасность сбора сведений об учётных записях для построения межплатформенных профилей пользователей должна быть очевидна. В Android 8.0 (Oreo) команда Android исключила возможность незаметно собирать эти сведения без согласия пользователя.

Ещё одной заметной сетью шпионских программ 2012 года была Dougaleaker, нацеленная на сведения из списков контактов граждан Японии. Её обнаружила американская компания в сфере безопасности McAfee и описала в записи блога «Android Malware Promises Video While Stealing Contacts».

В конце концов японская полиция арестовала авторов Dougaleaker. Их судили за распространение шпионских программ, однако японский суд признал их невиновными. В англоязычной прессе доступно мало сведений об этом деле, но некоторую предысторию приводит опубликованная в The Register статья «5 Tokyo Devs Cuffed over ‘The Movie’ Android App Scam».

После запуска пользователем приложения Dougaleaker, например jp.co.dougastation (v2, 83fd), шпионская функция отправляет сведения из его списка контактов на веб-сервер (листинг 2-4).

Листинг 2-4. Шпионский код Dougaleaker в jp.co.dougastation (v2, 83fd)

Ограниченные шпионские возможности Dougaleaker и узкая направленность позволяют предположить, что программа создавалась с единственной целью: составить карту социальных связей всех жителей Японии. Учитывая чрезвычайно большое количество установок приложения, авторы, вероятно, достигли своей цели.

BeeKeeper - ещё одно прежде не описанное крупное семейство вредоносных программ для мошенничества с SMS, нацеленное на российских пользователей Android. Ради увеличения числа установок вредоносные приложения выдавали себя за программы популярных брендов. Команда Android Security назвала семейство BeeKeeper, поскольку оно преимущественно атаковало мобильные телефоны в сети российского оператора «Билайн».

С технической точки зрения BeeKeeper представляла интерес по двум причинам. Во-первых, она использовала мощную для своего времени архитектуру управления: поддерживала более десятка команд с такими именами, как sendContactList, sendSms, catchSms и openUrl. Сервер контролировал каждое действие BeeKeeper на устройстве.

Во-вторых, BeeKeeper применяла рефлексию в качестве метода обфускации, скрывавшего её поведение от статического анализа. Рефлексия - функция Java, позволяющая разработчикам исследовать, изменять и вызывать классы, объекты и методы программы. Она добавляет уровень косвенности, из-за которого статический анализ приложения становится затруднительным. В частности, благодаря рефлексии код может ссылаться на классы и методы через обфусцированные, закодированные и зашифрованные строки.

В листинге 2-5 показано, как BeeKeeper с помощью рефлексии динамически разрешала метод Android API SmsManager.sendTextMessage, а затем отправляла им текстовые сообщения.

Листинг 2-5. Приложение com.qiwi.application (v4, 37f3) выдавало себя за службу цифрового кошелька Qiwi и применяло рефлексию, чтобы скрыться от статического анализа

Сначала вредоносная программа создаёт объект класса Android SmsManager, способный отправлять SMS. Затем она находит метод sendTextMessage с его пятью аргументами типов String и PendingIntent. Наконец, программа вызывает API sendTextMessage, чтобы отправить дорогостоящее SMS на конкретный номер телефона.

По сей день рефлексия остаётся одним из самых распространённых способов обхода анализа и обнаружения вредоносных программ. Обычно обфускацию на основе рефлексии понять не так легко, как в случае BeeKeeper, поскольку современные вредоносные программы для Android, как правило, шифруют и обфусцируют строковые аргументы, передаваемые API рефлексии. Некоторые инструменты анализа вредоносных программ не умеют обрабатывать такое сочетание шифрования и рефлексии, поэтому не способны эффективно анализировать современные вредоносные программы Android.

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

Теперь, для разнообразия, мы расскажем об образце вредоносной программы Android, созданном не ради прибыли. Android.Dogowar, впервые описанная американской компанией в сфере безопасности Symantec в опубликованной в августе 2011 года записи блога «Animal Rights Protesters Use Mobile Means for Their Message», изменяла законную, но неоднозначную игру Dog Wars, добавляя две функции. Во-первых, она отправляла всем контактам из списка на устройстве текстовое сообщение: «Мне нравится причинять боль маленьким животным, просто решил, что вам следует это знать». Во-вторых, программа отправляла SMS на платный номер 73822, подписывая устройство на предоставляемую организацией People for the Ethical Treatment of Animals (PETA) новостную службу о защите животных. Очевидно, разработчик вредоносной программы был оскорблён как игрой, имитировавшей собачьи бои, так и всеми её игроками.

Среди других примеров ранних вредоносных программ, найденных в Google Play, были Plankton, DroidKungFu, ggTracker, DroidDream Light и Gingermaster. Поскольку исследователи безопасности подробно их описали, здесь мы их не рассматриваем. Дополнительные сведения легко найти быстрым поиском в интернете.

Историю ранних вредоносных программ, устанавливавшихся из сторонних источников и предустанавливавшихся на устройствах, восстановить сложнее. В то время команда Android Security и независимые исследователи безопасности уделяли основное внимание Google Play, поэтому сведения за 2011 и 2012 годы, описывающие прочие вредоносные программы, отрывочны и труднодоступны. Команда безопасности ведёт исторический журнал всех приложений Google Play, но для приложений из сторонних источников такого журнала нет. Судя по имеющимся у нас ограниченным данным, DroidDream Light - шпионская разновидность DroidDream без эксплойтов для повышения привилегий - могла быть самой часто устанавливаемой из сторонних источников вредоносной программой 2011 года. В 2012 году наиболее популярной вредоносной программой из сторонних источников, вероятно, стала RuFraud - ещё одно семейство для мошенничества с платными SMS, нацеленное на Россию.

Нам неизвестны какие-либо предустановленные вредоносные программы, то есть программы, заранее установленные на устройства Android, действовавшие с 2010 по 2012 год. Впрочем, мы сомневаемся, что в те ранние годы исследователи вообще искали предустановленные вредоносные программы, поэтому не исключено, что они существовали, но о них никто не знал.

2013 год стал историческим для вредоносных программ Android. Предыдущие образцы иногда причиняли серьёзный ущерб, а порой широко распространялись, но редко сочетали оба свойства. Ни одна вредоносная сеть не достигала одновременно выдающихся результатов в распространении, технологии и прибыльности. Положение изменилось в 2013 году, когда появилось несколько семейств, созданных разработчиками, понимавшими составные части успешного предприятия по выпуску вредоносных программ. Эти разработчики, вероятно, организовали небольшие компании по созданию программного обеспечения, в отличие от одиночек и мелких групп, предположительно действовавших в прежние годы.

Хотя в 2013 году по-прежнему преобладали мошенничество с SMS и шпионские программы, в совокупности составлявшие более 50 процентов всех вредоносных программ в Google Play за год, заметную роль играли также враждебные загрузчики (20 процентов) и трояны для получения root-прав (20 процентов).

Среди всех новых сложных семейств вредоносных программ, доступных в Google Play в 2013 году, крупнейшей была Ghost Push, на долю которой приходились почти все трояны для получения root-прав того года. Её разработчики создали масштабную прибыльную сеть из тысяч приложений и совершенствовали её в последующие годы, а возможно, обновляют до сих пор.

Команде Android Security это семейство известно с 2014 года, однако его открытое описание появилось лишь в сентябре 2015 года, когда китайская компания в сфере безопасности Cheetah Mobile рассказала о нём в записи блога на китайском языке. Несмотря на масштаб сети, поставщики антивирусов не обнаруживали её примерно два года.

Точно понять действия Ghost Push трудно. Хотя анализ любого отдельного файла не представляет сложности, Ghost Push входит в огромную отрасль распространения вредоносных программ, действующую из Китая, и при любом анализе необходимо учитывать этот контекст. По крайней мере с 2013 года эта отрасль создаёт больше вредоносных программ для Android, чем любой другой источник. Насколько нам известно, она состоит из неопределённого количества создателей и распространителей вредоносных программ. Распространители проникают в Google Play, сторонние магазины и к изготовителям устройств, чтобы построить надёжные каналы распространения. Их приложения используют систему подключаемых модулей для загрузки вредоносных компонентов, предоставляемых создателями вредоносных программ.

Такой способ распространения скрывает количество участвующих лиц и компаний. Мы встречали образцы, загружавшие более 20 вредоносных подключаемых модулей с различными функциями. Сколько из этих модулей создано одними и теми же людьми? Являются ли распространители и создатели вредоносных программ полностью независимыми организациями или частично пересекаются? Эти вопросы остаются открытыми. Одно нам известно точно: эта отрасль предельно сосредоточена на получении прибыли любыми способами, будь то рекламный спам, мошенничество с кликами, платное навязывание установок приложений или что-либо другое.

В 2013 году вредоносные программы для мошенничества с SMS продолжали атаковать российских пользователей. BadNews была семейством враждебных загрузчиков, впервые обнаруженным Lookout Mobile Security в апреле 2013 года и описанным в записи блога «The Bearer of BadNews».

RuPlay и RuFraud образовывали сеть семейств вредоносных программ, которые до настоящего времени открыто не описывались: находившиеся в Google Play приложения RuPlay действовали как враждебные загрузчики и скачивали из других источников приложения RuFraud.

Как и многие другие семейства вредоносных программ, приложения RuPlay выдавали себя за популярные в то время программы. Разработчики RuPlay зарегистрировали десятки доменов с такими именами, как subwaysurfcheats.com и angrybirds.p.ht. Они создавали сайты, копировавшие внешний вид Google Play, и под ложными предлогами убеждали пользователей загружать приложения, например получать обновления популярных игр Subway Surfer и Angry Birds. Они также применяли спам с ключевыми словами и другие недобросовестные способы манипулирования местами в результатах поиска Google Play, обманывая пользователей и заставляя их загружать подделки вместо законных приложений.

Конечным местом загрузки приложений RuPlay для мошенничества с SMS был сайт hotdroid-apps.pm. Этот сайт давно исчез, а большинство его вредоносных приложений потеряно для истории. Одно из сохранившихся приложений - flv.app (v118, 6ed2), которое многие антивирусные продукты распознают как вредоносную программу под названием FakeApp, FakeInst или Agent. Оно было создано для мошенничества с SMS, но содержало и другие интересные идеи.

Например, сервер управления мог приказать приложению перенаправлять исходящие звонки пользователя. Поскольку у нас нет доступа к журналам сервера, назначение этой функции неизвестно, но, вероятно, приложение пыталось перехватывать звонки пользователей мобильным операторам, чтобы предотвратить жалобы на неизвестные списания. Вместо горячей линии оператора пользователь, сам того не зная, звонил мошенникам. В листинге 2-6 показано, как это работает.

Листинг 2-6. Приложение flv.app (v118, 6ed2) перенаправляет телефонные звонки пользователя

Сервер управления приложения поддерживал и команды, не связанные с текстовыми сообщениями и звонками. Например, команда antiUninstall выводила системное диалоговое окно для предоставления приложению прав администратора устройства и показывала пугающее сообщение, загруженное с сервера. На протяжении многих лет вредоносные программы Android использовали права администратора, чтобы пользователи не могли удалять вредоносные приложения. Со временем команда Android Security совместно с командой операционной системы удаляла свойства администратора устройства, которыми злоупотребляли вредоносные программы, пока в Android 9.0 (Pie) сам API не был объявлен устаревшим. В Android 10 этот API вообще перестал что-либо делать.

Ещё одно семейство для мошенничества с SMS, WallySMS, было нацелено на страны Западной Европы. В листинге 2-7 приведён образец из com.albertech.harlemshake (v2, 31f8), который по коду страны мобильной связи (mobile country code, MCC) проверяет, находится ли устройство во Франции, Испании или Германии. Затем он назначает устройству закодированный в Base64 платный номер SMS для мошеннических действий.

Листинг 2-7. Приложение com.albertech.harlemshake (v2, 31f8) содержит платную SMS-нагрузку только для Франции (MCC 208), Испании (MCC 214) и Германии (MCC 262)

Динамический анализ этого образца показал, что при запуске на устройстве, настроенном для любой другой страны, приложение не проявляет вредоносной активности.

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

Самые совершенные инструменты анализа вредоносных программ передают сведения между механизмами статического и динамического анализа.

В ответ на распространённость мошенничества с SMS в ранние годы Android команда операционной системы внесла несколько изменений для более надёжной защиты пользователей. В 2012 году в Android 4.2 (Jelly Bean) появилось диалоговое окно предупреждения, открывающееся всякий раз, когда приложение отправляет текстовое сообщение на платный номер. Примерно к 2014 году эта версия Android получила критически широкое распространение. Небольшое изменение значительно снизило прибыльность мошенничества с SMS и перекрыло самый прямой способ незаконного заработка на Android. Хотя некоторые семейства вредоносных программ для мошенничества с SMS продолжали загружать в Google Play, ни одно из них не достигло огромного масштаба и не поддерживалось изощрёнными авторами. Вместо этого управлявшие профессиональными предприятиями по выпуску вредоносных программ люди начали искать другие способы быстро заработать на пользователях Android.

Следующим по привлекательности способом обмануть пользователей стали другие виды мошенничества с телефонными счетами. Во многих странах пользователи телефонов могут оплачивать услуги с помощью технологии выставления счетов по протоколу беспроводных приложений (Wireless Application Protocol, WAP). К серверам выставления счетов WAP можно обращаться по HTTP, поэтому вредоносным приложениям легко с ними соединяться. Недостаток для мошенников заключается в том, что оплата через WAP распространена не так широко, как оплата через SMS, поэтому они ограничены целями в нескольких странах, включая Россию, Таиланд, Вьетнам, Испанию и Великобританию.

Mono WAP, крупнейшее семейство для мошенничества с WAP в 2014 году, представляло интерес не только широким распространением: примечательны также выбранный язык программирования и крошечный размер вредоносного кода, затруднявший его обнаружение.

В отличие от других крупных семейств вредоносных программ Android, почти исключительно написанных на Java, Mono WAP была создана на Mono for Android - платформе программного обеспечения с открытым исходным кодом, позволявшей разработчикам создавать приложения Android на языках .NET, например C#. В 2016 году Microsoft приобрела компанию, стоявшую за Mono for Android, и переименовала платформу в Xamarin.Android. Такой выбор языка создавал серьёзные трудности для антивирусных технологий, способных анализировать только Java-код.

Другая интересная особенность семейства Mono WAP заключалась в том, что оно содержало очень мало кода и действовало исключительно незаметно. Программа загружала страницы мошеннической оплаты WAP в WebView - стандартный компонент Android для отображения веб-страниц без браузера - и оформляла для пользователя возобновляемую подписку на платную услугу. До того как мобильные операторы усилили защиту оформления подписок через WAP, приложению Mono WAP было достаточно собрать идентификатор Android устройства и отправить его на домен, размещённый мошенниками.

Например, образец com.baibla.krasive (v1, 9604) отправлял запросы по следующим URL:

Параметр URL app, предположительно, обозначал приложение, от которого поступил запрос, а параметр aid идентифицировал пользователя, которого следовало подписать на платную услугу.

Эта простая схема работала только на устройствах, подключённых к сети оператора, предоставлявшего услугу платной подписки. Если устройство было подключено к Wi-Fi или мобильной сети другого оператора, оформить подписку было невозможно. Тем не менее простота оформления платных услуг через обычные HTTP-соединения затрудняла выявление мошенничества с WAP. Как отличить законный HTTP-запрос от запроса, который против воли пользователей подписывает их на услуги? В ранние годы мошеннические WAP-приложения зачастую обнаруживали только после того, как на нежелательные списания жаловалось достаточное количество пользователей.

С годами мобильные операторы улучшили защиту от мошенничества с помощью двухфакторной аутентификации и других механизмов, подтверждающих, что пользователь разрешил платёж. В некоторых странах государства изменили законодательство об оплате через WAP в пользу потребителей. По мере укрепления операторами защиты страниц оформления WAP-подписок мошеннические приложения становились всё сложнее: теперь вредоносным программам требовалось перехватывать сообщения двухфакторной аутентификации и с помощью JavaScript или иных методов вводить код подтверждения в диалоговое окно.

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

В 2014 году также начали распространяться вредоносные программы Android, связанные с криптовалютами. В то время ограниченных аппаратных возможностей мобильных телефонов ещё хватало для добычи многих криптовалют, особенно если злоумышленники контролировали большое количество устройств и превращали их в майнинговый ботнет. Сначала скрытая добыча была нацелена на такие криптовалюты, как Bitcoin и Litecoin, но вскоре сосредоточилась на Monero. По замыслу для добычи Monero требовалось менее мощное оборудование, чем для других криптовалют того времени, поэтому она прекрасно подходила для мобильных телефонов.

Главным преимуществом добычи Monero был сайт Coinhive, позволявший любому человеку добывать монеты Monero с помощью единственной строки JavaScript-кода. Вскоре авторы вредоносных программ повсюду, не только на Android, встроили такие однострочные майнеры Coinhive в приложения, сайты, рекламные объявления и всё остальное, что могло выполнять JavaScript. Из-за масштаба злоупотреблений антивирусное программное обеспечение и другие защитные продукты начали блокировать все соединения с сайтом. В марте 2018 года журналист в области компьютерной безопасности Брайан Кребс опубликовал подробное расследование под названием «Who and What Is Coinhive?», где изложил сомнительную историю сайта и стоявших за ним людей. Coinhive прекратил работу в начале 2019 года, и с тех пор ни один другой сайт не пошёл по его стопам. Закрытие фактически положило конец скрытой добыче криптовалют вредоносными программами Android.

Когда в 2020 и 2021 годах цены на криптовалюты поднялись до новых рекордных уровней, авторы вредоносных программ перешли от добычи к фишингу. Фишинговые приложения взламывали учётные записи и кошельки криптовалют, после чего переводили все остатки средств на счета разработчиков вредоносных программ. Защита пользователей во всей разнообразной криптовалютной экосистеме, где тысячи валют проходят через циклы ажиотажа, оказалась настоящей проблемой. Даже простое отслеживание имён, логотипов и сайтов всех этих криптовалют, а также их официальных и неофициальных приложений-кошельков требует полной занятости целой команды.

За пределами Google Play положение с вредоносными программами оставалось непрозрачным. Мы полагаем, что в период с 2012 по 2014 год чаще всего из сторонних источников устанавливалась RuFraud, рассмотренная ранее в этой главе. Тысячи известных образцов приложений действовали сходным образом, но неясно, составляли ли они единое семейство вредоносных программ или группу семейств с одинаковой тактикой. DroidDream Light, сохранявшая активность в 2013 году, исчезла в 2014-м.

Другим крупным семейством 2014 года, распространявшимся вне магазинов, были приложения Taicliphot для мошенничества с SMS, нацеленные на любителей порнографии во Вьетнаме. Эти программы почти не содержали кода и сразу переходили к функции мошенничества с SMS в методе onCreate основной активности. В листинге 2-8, взятом из ncn.taicliphot (v1, 38a3), показана эта функция.

Листинг 2-8. Приложение ncn.taicliphot (v1, 38a3) отправляет платные SMS без согласия пользователя

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

В 2014 году мы также встретили несколько ранних примеров предустановленных вредоносных программ. Китайская компания в сфере безопасности Qihoo 360 обнаружила предустановленное семейство OldBoot, которое описала в опубликованной в январе записи блога «Oldboot: The First Bootkit on Android». Вскоре после этого «Лаборатория Касперского» обнаружила на китайских устройствах UUPay - семейство вредоносных программ, которое без согласия собирало конфиденциальные сведения о пользователе и потенциально создавало начисления в его телефонном счёте, - и рассказала о нём в мартовской записи блога «Caution: Malware Pre-Installed!».

Lookout Mobile Security обнаружила DeathRing - семейство троянов, способных совершать мошенничество с SMS и WAP. О нём можно прочитать в материале «DeathRing: Pre-Loaded Malware Hits Smartphones for the Second Time in 2014», опубликованном в декабре того года.

Четвёртым открытием года стала CoolReaper, о которой сообщила Palo Alto Networks и которая была описана в декабрьской публикации «CoolReaper Revealed: A Backdoor in Coolpad Android Devices». CoolReaper была мощным семейством бэкдоров, устанавливавшимся на устройства китайским изготовителем Coolpad.

В 2015 и 2016 годах вредоносные программы Android продолжали быстро развиваться, и эти годы стали самыми интересными для их исследования. Поскольку изменения защиты Android снизили прибыльность мошенничества с SMS, авторы вредоносных программ обратились к другим формам злоупотребления. В этом разделе рассматриваются самые разные примеры: от троянов и фишинга до DDoS-атак, мошенничества с WAP и многого другого.

В 2014 году в Google Play появилось и вскоре приобрело дурную славу новое семейство вредоносных программ - Turkish Clicker. Приложения Turkish Clicker загружали JavaScript-код с серверов управления и выполняли его в WebView. Команда Android Security узнала об этом семействе, когда в том же году вредоносная программа использовала заражённые устройства для DDoS-атаки на Google Play. Мы не знаем, была ли эта атака преднамеренной или стала побочным результатом чрезмерно агрессивной попытки манипулировать механизмом ранжирования приложений Google Play. В любом случае команда Android Security быстро остановила Turkish Clicker, удалив её приложения с устройств и тем самым прекратив атаку.

В 2015 году Turkish Clicker вернулась с удвоенной силой и превратилась в крупнейшую на тот момент вредоносную сеть, когда-либо встречавшуюся в Google Play. Это была первая сеть, поставившая на поток создание учётных записей разработчиков Google Play: за прошедшие годы их были созданы тысячи. Авторы вредоносных программ экспериментировали с разными схемами заработка и в конечном итоге остановились на мошенничестве с кликами и WAP, сосредоточившись на турецких пользователях. Общественность узнала об этой сети в январе 2016 года, когда американо-израильская компания в сфере безопасности Check Point рассказала о ней в записи блога «Turkish Clicker: Check Point Finds New Malware on Google Play».

В листинге 2-9 показана приведённая в удобочитаемый вид нагрузка, которую приложение Turkish Clicker com.gkrj.djjsas (v2, c901) загрузило со своего сервера управления.

Листинг 2-9. Нагрузка для мошенничества с кликами, загруженная приложением com.gkrj.djjsas (v2, c901)

IP-адрес в первой строке, который приложение, по-видимому, игнорировало, мог принадлежать выходному узлу Tor. URL во второй строке указывает на вторичный сервер управления, откуда вредоносная программа загружает список целевых сайтов. Далее в листинге JavaScript-код содержит функцию мошенничества с кликами, которая нажимает объявления на целевых сайтах. Во время анализа в 2016 году все эти цели являлись порнографическими сайтами.

В то время как крупнейшие вредоносные сети 2015 года сосредоточились на мошенничестве с WAP, сети среднего размера проявляли настоящую изобретательность. Несколько сетей начали захватывать учётные записи социальных сетей в таких приложениях, как Instagram или российская сеть VK, похищая учётные данные пользователей. Другая сеть, Shuabang, создавала бесчисленные новые учётные записи Gmail, чтобы манипулировать продуктами Google. Испанская компания в сфере компьютерной безопасности ElevenPaths впервые описала Shuabang в опубликованной в ноябре 2014 года записи блога «Shuabang Botnet: BlackHat App Store Optimization (BlackASO) in Google Play».

Ещё одна сеть под названием Gaiaphish, описанная в отчёте 2017 Android Security Year in Review, выманивала учётные данные Google. Кроме того, её приложения динамически загружали код для злоупотребления различными сайтами Google. Например, skt.faker.world (v3, 936c) содержало закодированные в Base64 URL-адреса для загрузки дополнительных файлов подключаемых модулей, нацеленных на рекламные ресурсы Google, социальную сеть Google+ и сам Google Play (листинг 2-10).

Листинг 2-10. Строки в кодировке Base64 в skt.faker.world (v3, 936c)

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

Загруженный подключаемый модуль скрывал вредоносные функции в официально звучащих именах пакетов, таких как com.google.android.* и com.google.dex.*. Инструкции конфигурации содержали десятки параметров. Некоторые из них показаны в листинге 2-11.

Листинг 2-11. Параметры конфигурации Gaiaphish из skt.faker.world (v3, 936c)

Одна из забавных функций Gaiaphish заключалась в том, что её приложения публиковали в Google Play поддельные отзывы, предположительно за плату, чтобы повысить популярность и репутацию других приложений. Образцы Gaiaphish содержат множество таких поддельных отзывов о приложениях в виде жёстко заданных строк. Небольшая подборка приведена в листинге 2-12.

Листинг 2-12. Поддельные отзывы пользователей Google Play из skt.faker.world (v3, 936c)

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

Judy, второе по величине семейство вредоносных программ 2016 года, зарабатывала на мошенничестве с рекламой. Компания Check Point первой обнаружила это семейство и описала его в опубликованной в мае 2017 года записи блога «The Judy Malware: Possibly the Largest Malware Campaign Found on Google Play». Приложения Judy были предназначены для мошенничества с кликами в рекламных продуктах Google.

Код приложений Judy может быть довольно запутанным. Он использует внутреннюю систему обмена сообщениями, чтобы находить объявления Google и выполнять мошеннические клики посредством JavaScript. Приведённый в удобочитаемый вид код в листинге 2-13 показывает мошеннические клики в air.com.eni.AnimalJudy035 (v1250000, a72a).

Листинг 2-13. Приложение air.com.eni.AnimalJudy035 (v1250000, a72a) нажимает случайный пиксель внутри ранее найденного объявления

Клик происходит в потоке, запущенном после получения сообщения LODING5. Чтобы выполнить этот клик, код вычисляет случайные координаты x и y внутри объявления. Затем он нажимает объявление двумя вызовами API dispatchTouchEvent.

После 2016 года среди вредоносных программ Android стало преобладать мошенничество с рекламой, будь то мошенничество с кликами или иные методы. Эта прибыльная категория остаётся одним из немногих прямых способов заработка для авторов вредоносных программ теперь, когда мошенничество с SMS и добыча криптовалют стали менее выгодными. Многие другие категории вредоносных программ допускают лишь косвенную монетизацию. Например, чтобы заработать на похищенных данных, автору вредоносной программы необходимо найти покупателя. Аналогичным образом для заработка на программе-вымогателе нужно найти жертву, которая согласна и способна заплатить выкуп.

У мошенничества с рекламой есть ещё одно преимущество: оно может оставаться совершенно невидимым для пользователей. Это важно, поскольку более навязчивые виды вредоносных программ, например фишинг, пользователь способен заметить и понять, а затем удалить подозреваемое в нечестном поведении приложение. Мошенничество с рекламой может годами оставаться незамеченным на устройствах и долго приносить доход авторам вредоносных программ.

У DressCode - крупной вредоносной сети, обнаруженной Check Point и описанной в опубликованной в августе 2016 года записи блога «DressCode Android Malware Discovered on Google Play», - был другой новаторский способ заработка. Она превращала заражённые устройства в узлы прокси-ботнета. Затем авторы вредоносной программы могли направлять через эти устройства трафик, например вредоносный трафик для мошеннических кликов по рекламе, и скрывать его источник.

Приложения DressCode реализуют вредоносные функции всего в нескольких классах. Авторы повторно использовали пример кода, опубликованный в 2000 году на CodeProject (codeproject.com), а затем добавили классы, необходимые им для проксирования. В листинге 2-14 показан приведённый в удобочитаемый вид код из com.dark.kazy.goddess.lp (v1, d858). После соединения с заранее настроенным сервером управления код разбирает полученные от него текстовые команды и открывает новые прокси-соединения с другими серверами, указанными в команде CREATE.

Листинг 2-14. Приложение com.dark.kazy.goddess.lp (v1, d858) разбирает различные команды прокси-сервера, поступающие с сервера управления

Получив управление прокси-ботнетом, авторы вредоносных программ могут зарабатывать несколькими способами. Например, помимо описанного выше варианта, они способны продавать доступ к ботнету другим преступным группам, желающим проводить DDoS-атаки, или превращать заражённые устройства в выходные узлы для поставщиков VPN.

В период с 2016 по 2021 год вариант с VPN стал одной из самых распространённых форм злоупотребления вредоносными программами Android. По мере роста спроса пользователей на персональные VPN-службы сомнительные VPN-компании строили свой бизнес за счёт ничего не подозревавших пользователей Android. Эти компании создавали SDK прокси-сетей и платили известным разработчикам Android за включение их в популярные приложения. Устройства пользователей, установивших приложения с такими SDK, превращались в конечные узлы проксируемого сетевого трафика. Разумеется, пользователям об этом не сообщалось.

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

Joker, вероятно, является крупнейшим семейством вредоносных программ в истории Google Play, превосходящим по масштабу даже Turkish Clicker. Начиная с 2016 года её разработчики создают приложения для мошенничества с SMS и WAP, предназначенные для Google Play.

Команда Android Security впервые упомянула Joker в отчёте 2017 Android Security Year in Review под названием BreadSMS. Затем, в июне 2019 года, датская CSIS Security Group заново обнаружила Joker и описала её в записи блога «Analysis of Joker - A Spy & Premium Subscription Bot on GooglePlay». Технические сведения об этом семействе приведены в той публикации и в следующей записи блога команды Android Security «PHA Family Highlights: Bread (and Friends)», вышедшей в январе 2020 года.

Начиная с 2019 года Joker неоднократно находили в Google Play, и о ней сообщали многие исследователи безопасности. Вероятно, первоначальные разработчики Joker по сей день продолжают создавать приложения для мошенничества с WAP, нацеленные на Юго-Восточную Азию, но мы также полагаем, что после публичного успеха Joker появились разработчики вредоносных программ-подражателей. Сегодня Joker - обобщающее название мошенничества с WAP в Google Play, охватывающее неизвестное количество отдельных семейств вредоносных программ.

Самые интересные стороны Joker - её масштаб и сложные методы уклонения от обнаружения. С 2016 по 2022 год разработчики вредоносных программ создали тысячи приложений Joker. По мере того как команда Android Security и антивирусные компании учились обнаруживать Joker, разработчики совершенствовали защиту, чтобы избежать выявления. За прошедшие годы создатели вредоносных программ и защитники многократно повторяли эту игру в кошки-мышки. В результате недавние приложения Joker запутаннее большинства других семейств вредоносных программ.

Приложение Joker com.guo.smscolor.amessage (v5, 5445), появившееся в ноябре 2021 года, показывает, насколько далеко всё зашло. Оно содержит зашифрованный файл assets/extersion/ex_compose, который в действительности представляет собой нативный код ARM. После расшифрования и выполнения приложением этот файл раскрывает зашифрованный DEX-код, который также расшифровывается и выполняется. Код загружает файл adal.jar из облачной службы AliBaba и тоже выполняет его. Именно в adal.jar находится настоящий код мошенничества с WAP. Разумеется, на каждом этапе применяется и россыпь других методов защиты, включая обнаружение эмулятора, обфускацию и шифрование кода.

В листинге 2-15 показан код из com.guo.smscolor.amessage (v5, 5445), предназначенный для мошенничества с WAP в Южной Африке и Таиланде. Мы намеренно оставили его обфусцированным, чтобы показать, насколько трудно понимать современный код Joker.

Листинг 2-15. Пример кода из приложения com.guo.smscolor.amessage (v5, 5445)

Этот пример показывает, как adal.jar выбирает разные страны и операторов. Android API getSimOperator возвращает строку из пяти или шести цифр, содержащую код страны мобильной связи телефона и код мобильной сети (mobile network code, MNC). Затем код проверяет, начинается ли значение с 655 - MCC Южной Африки. В другом месте значение сравнивается с 52001, 52003 и 52023. Префикс 520 обозначает Таиланд, а суффиксы 01, 03 и 23 - три крупнейшие мобильные сети Таиланда: AIS, AIS-3G и MTS. Joker атакует эти сети для мошенничества с WAP.

Южная Африка и Таиланд входят в число наиболее частых целей мошенничества с WAP. Среди других популярных целей - страны Юго-Восточной Азии, особенно Вьетнам и Индонезия, и Ближнего Востока, включая Египет, Объединённые Арабские Эмираты, Саудовскую Аравию и другие.

Когда ранее в этой главе мы обсуждали Ghost Push, то описали процветающую китайскую отрасль вредоносных программ, состоящую из связанных создателей и распространителей. К другим ранним образцам вредоносных программ из этой сети относятся Triada и Chamois в 2014 году, Gooligan, Snowfox и YouTube Downloader в 2015-м, а также Hummingbad в 2016-м. Эти семейства имели огромный масштаб и сложные модели распространения. Хотя ранние версии сетей распространялись через Google Play и установку из сторонних источников, позднее их распространители сосредоточились на гораздо более эффективном способе: проникновении в процесс производства устройств и его подрыве.

Удобно для злоумышленников, что большинство устройств Android производится в Китае, поэтому китайским авторам вредоносных программ легко получить к ним доступ. По-видимому, один из распространённых способов такого доступа - создание подставных компаний, выдающих себя за законных разработчиков программного обеспечения. В действительности создаваемые ими программы содержат бэкдоры и другие встроенные вредоносные функции. Мы видели, как такие подставные компании разрабатывали решения для обновления по беспроводной сети, программы разблокировки по лицу и программы управления шрифтами с бэкдорами, а затем дёшево продавали эти технологии изготовителям устройств. В ходе интеграции подставные компании просят изготовителей предоставить их программам привилегированный доступ к глубинным частям систем Android, благодаря чему вредоносные программы могут выполнять функции, для которых прежде требовались эксплойты получения root-прав.

Triada, возможно, является самым известным семейством предустановленных вредоносных программ Android. Впервые она была описана «Лабораторией Касперского» в двух записях блога за март 2016 года: «Triada: Organized Crime on Android» и «Everyone Sees Not What They Want to See». Она достигла редко встречавшегося прежде уровня сложности. В июне 2019 года команда Android Security опубликовала дополнительные технические сведения о возможностях Triada в материале «PHA Family Highlights: Triada». В том же месяце технический журналист Брайан Кребс исследовал происхождение Triada и стоявших за ней людей в статье «Tracing the Supply Chain Attack on Android».

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

Корни Triada уходят по меньшей мере в сентябрь 2014 года, когда появился образец с именем пакета com.untory.run1 (v1, 251c). Это приложение легко понять, поскольку оно применяет мало защитных методов. Пакеты Java security.*, tools.* и util.* содержат ядро кода Triada. Единственная попытка обфускации - несколько зашифрованных строк, которые приложение расшифровывает во время выполнения с помощью функции нативного кода во встроенном файле libhzwtool.so. Как использование .NET семейством мошеннических программ Mono WAP, описанным ранее в этой главе, код нативных библиотек способен обходить инструменты проверки приложений, анализирующие только Java-код. Надеясь уклониться от таких ограниченных инструментов, авторы Triada намеренно применили нативный код как уловку против анализа; функция расшифрования строк не содержит никакого поведения, которое нельзя было бы реализовать на Java.

Алгоритм расшифрования строк принимает на вход шестнадцатеричную строку и два 16-байтовых ключа. Затем он выполняет XOR каждого байта шифротекста с соответствующими байтами двух ключей. Эти ключи считываются со смещений 0x08 и 0x18 файла ресурсов assets/hzwLib. На протяжении многих лет Triada прячет ключи шифрования в файлах ресурсов и применяет простые алгоритмы расшифрования с двойным XOR, благодаря чему новые образцы легко распознавать.

Для получения root-прав образец com.untory.run1 (v1, 251c) использует EasyRoot. Это разработанный китайским технологическим конгломератом Baidu SDK для Android, который содержит эксплойты получения root-прав для разных устройств и бесплатно доступен разработчикам Android для включения в приложения. Triada хранит эксплойты в пакете com.baidu.easyroot.

Мы полагаем, что переход к проникновению в производственные компании отчасти произошёл потому, что получать root-права на устройствах Android стало труднее. Мы никогда не видели, чтобы одна из этих китайских сетей развёртывала эксплойты нулевого дня для получения root-прав, а значит, прежде они, вероятно, полагались на эксплойты, разработанные другими. После 2015 года общедоступные эксплойты для получения root-прав стали настолько редки, что между их выпусками могли проходить годы. Устав ждать, разработчики вредоносных программ, вероятно, были вынуждены найти альтернативный способ получения привилегированного системного доступа.

У проникновения к изготовителям устройств есть и другие преимущества. Предустановленное программное обеспечение способно изменять устройство так, как недоступно даже эксплойтам получения root-прав, например менять параметры безопасности вроде SELinux. Кроме того, значительно проще быстро сформировать большую базу установок: распространителям вредоносной программы достаточно обмануть одну компанию и заставить её установить программу на сотни тысяч устройств. Это гораздо легче, чем рекламировать продукт отдельным пользователям Android в надежде, что они решат его установить! Благодаря этим преимуществам в 2015 году предустановленные вредоносные программы начали стремительно распространяться.

Последовавшая по пути Triada программа Chamois, возможно, была самым влиятельным ботнетом 2018 года. Впервые команда Android Security открыто описала её в марте 2017 года в записи блога «Detecting and Eliminating Chamois, a Fraud Botnet on Android», однако появилась она ещё в ноябре 2014 года.

Chamois превзошла Triada в нескольких отношениях, и особенно заметным стало внедрение сложных функций противодействия анализу. Она содержит несколько слоёв зашифрованного нативного кода, намного более сложного, чем у Triada, а затем скрывает не менее 45 проверок окружения, определяющих, работает ли программа в эмулируемой среде или анализируется исследователями безопасности. Подобные проверки уже имелись во многих образцах вредоносных программ Android, но 45 проверок по меркам того времени были исключительным количеством. Команда Android Security подробнее рассматривает эти функции в статье 2018 года для Virus Bulletin «Unpacking the Packed Unpacker: Reversing an Android Anti-Analysis Native Library».

Chamois также стала ранним примером вредоносной программы, которая перешла от использования Google Play как канала заражения к предустановке на устройства пользователей. После того как в 2017 году команда Android Security впервые удалила из Google Play все приложения Chamois, разработчики начали обращаться к изготовителям устройств Android. Официально они предлагали решение для мобильных платежей, но оно содержало скрытый код, загружавший и выполнявший вредоносные функции, например мошенничество с рекламой или SMS.

Два других китайских семейства вредоносных программ Android, Gooligan и Snowfox, в 2015 и 2016 годах скомпрометировали миллионы учётных записей Google. Вместо выманивания учётных данных Google у пользователей эти семейства похищали токены учётных записей из защищённой части операционной системы Android. Такие токены предоставляли злоумышленникам полный контроль над учётной записью жертвы. Например, они могли войти в Gmail жертвы, загрузить её файлы из Google Drive или просмотреть фотографии, сохранённые в Google Photos.

Обычные приложения не имеют доступа к области операционной системы, где хранятся токены доступа к учётным записям Google. Для их кражи стороннее приложение должно повысить привилегии с помощью эксплойта либо быть предустановлено с уже предоставленными повышенными привилегиями. Gooligan делала и то и другое. Как описала Check Point в публикации за ноябрь 2016 года «More Than 1 Million Google Accounts Breached by Gooligan», Gooligan использовала несколько эксплойтов, чтобы повысить обычные привилегии приложения до уровня root. Она собирала сведения о конфигурации устройства, отправляла их серверу управления и загружала подключаемые модули эксплойтов, специально предназначенные для распознанного типа устройства.

Snowfox, названная по характерному имени пакета com.snowfox, представляет собой SDK, обнаруженный после Gooligan. В отличие от Gooligan, она не загружала подключаемые модули эксплойтов для получения root-прав. Вместо этого программа либо была предустановлена на устройствах, либо при установке из стороннего источника рассчитывала на то, что устройства уже имеют root-права. Snowfox обладала чрезвычайно широкими возможностями и развитой системой подключаемых модулей, которая загружала дополнительный код с сервера управления. Мы наблюдали более 30 разных файлов модулей с такими функциями, как кража токенов учётных записей Google, мошенничество с рекламой и возможность загружать и устанавливать дополнительные приложения. Первое описание Snowfox команда Android Security опубликовала в отчёте 2018 Android Security Year in Review.

Один из примеров приложения Snowfox - com.zg.magicDrop (v1, 9097). После связи с серверами управления по зашифрованным каналам приложение загружает вредоносные подключаемые модули, например snowfox_v19n.jar. Код модуля обфусцирован плохо. Например, в листинге 2-16 показана функция кражи токенов учётных записей Google. Сначала она копирует базу данных Accounts в другое место, а затем извлекает токены из базы командами SQLite.

Листинг 2-16. Приложение com.zg.magicDrop (v1, 9097) похищает токены учётных записей Google

Результаты антивирусной проверки VirusTotal связывают snowfox_v19n.jar с Xinyinhe - другим семейством вредоносных программ, созданным одноимённой китайской компанией. Калифорнийская компания FireEye рассматривает это семейство в записи блога 2015 года «Guaranteed Clicks: Mobile App Company Takes Control of Android Phones», описывая функции и структуру, похожие на Gooligan и Snowfox. Неясно, принадлежат ли эти приложения одному семейству и разработаны ли одними людьми, поскольку система подключаемых модулей, применяемая многими китайскими семействами вредоносных программ, затрудняет атрибуцию.

В 2016 году Check Point обнаружила Hummingbad - сложное семейство предустановленных китайских вредоносных программ с множеством динамически загружаемых функций. Особый интерес представляет то, что Hummingbad внедряла код в процессы посредством системного вызова Linux ptrace. Технические подробности описаны в июльском отчёте «From Hummingbad to Worse».

В образце com.swiping.whale (v262, 783a) код внедрения находится в пакете Java com.ry.inject.JNI. В перехвате Google Play участвуют два файла ресурсов: assets/inject и assets/libhooker.so. Файл inject представляет собой обычный исполняемый файл Linux, принимающий аргументы командной строки для управления процессом перехвата. В листинге 2-17 показано, как Hummingbad строит полную команду внедрения в процесс.

Листинг 2-17. Hummingbad запускает внедрение в процесс Google Play

Первый аргумент - имя перехватываемого процесса (com.android.vending, то есть Google Play), а второй - внедряемый двоичный файл libhooker.so. Третий аргумент - экспортируемая функция libhooker.so, которая вызывается после внедрения двоичного файла в процесс Google Play.

Этот двоичный файл также содержит файл Java-кода, отвечающий за взаимодействие с Google Play после внедрения. Код позволяет Hummingbad манипулировать интерфейсом Google Play: например, нажимать кнопку установки и устанавливать приложения без согласия пользователя.

YouTube Downloader была сравнительно небольшим семейством вредоносных программ, предустановленным на недорогих устройствах Android. Чтобы распространить программу, человек, имевший доступ к процессу производства устройств, внедрил вредоносный код в приложения Google, например YouTube, откуда и произошло название семейства, фактически подменив законные приложения.

Внедрение вредоносной программы в предустановленные приложения Google значительно затрудняет антивирусным приложениям очистку устройств. Из-за технических ограничений предустановленные приложения невозможно удалить с устройства; их можно лишь отключить, чтобы прекратить выполнение. Однако попытка ради защиты пользователей отключить популярное приложение, такое как YouTube, скорее всего, не увенчается успехом: пользователи, вероятно, включат его снова, чтобы смотреть видео.

Приложения YouTube с предустановленной вредоносной программой нельзя обновить до законной версии. Оригинальные приложения YouTube подписаны секретным закрытым ключом Google. Внедрив вредоносный код в законное приложение YouTube, разработчики вредоносной программы должны заново подписать изменённое приложение, чтобы подтвердить его целостность системе Android. Но поскольку закрытого ключа Google у них нет, приходится использовать собственный. В результате при установке законного обновления YouTube Android обнаруживает несовпадение ключей и запрещает установку, обращая защитную функцию подписи кода против пользователя. В конечном итоге единственный способ очистить устройство с поддельным приложением YouTube - выпуск изготовителем полного системного обновления, удаляющего это приложение.

YouTube Downloader определила направление развития вредоносных программ на несколько следующих лет. Многие их разработчики перестали создавать новые предустановленные вредоносные приложения и вместо этого сосредоточились на внедрении вредоносного кода в законные системные приложения. Со временем места размещения кода становились всё более скрытными. Мы встречали код, внедрённый в процесс системного интерфейса, процесс обновления и даже в сам Android API. Отключение этих чувствительных приложений и файлов делает устройства непригодными для использования, что ставит антивирусные продукты в затруднительное положение при попытке защитить пользователей.

Кроме способа распространения, файлы YouTube Downloader ничем особенно не интересны. Образцы вроде com.google.android.youtube (v1599000099, 428a) содержат только функции загрузки и установки других приложений. Мы не приводим код таких образцов, поскольку в нём нет новых методов.

В 2017 году разработчики вредоносных программ Android пришли к единому мнению о лучших способах извлечения прибыли. Это изменение завершило разнообразный исследовательский период предшествующих лет, когда успешные разработчики использовали множество методов заработка. Начиная с 2017 года крупнейшими семействами стали прокси-сети наподобие Idle Coconut, семейства для мошенничества с WAP вроде уже описанных Joker и Turkish Clicker, посредники по продаже данных вроде OneAudience и семейства для мошенничества с рекламой, например Android.Click.312.origin. В этом разделе мы рассмотрим два последних варианта.

Хотя на первый взгляд современные вредоносные программы разнообразны, большинство из них следует общей схеме. Во-первых, они невидимы для пользователей. Пользователям не нравится оскорбительное, вредоносное или раздражающее поведение приложений. Если приложение кажется им проблемным, они удаляют его, лишая разработчика возможности получать доход. Создание сетевых прокси, поглощение данных или нажатие невидимых объявлений - поведение, которое пользователю трудно заметить или связать с конкретным приложением. Приложения с такими невидимыми функциями могут оставаться на устройствах месяцы или годы и работать в фоновом режиме, даже если пользователи давно о них забыли.

Во-вторых, современным вредоносным программам нужно очень мало разрешений Android. Для создания сетевых прокси, генерации мошеннических кликов по рекламе или соединения с сайтами мошенничества с WAP им требуется только разрешение INTERNET. Это разрешение запрашивает почти каждое приложение в экосистеме Android, поэтому авторы вредоносных программ могут использовать его, не привлекая нежелательного внимания. Отсутствие чувствительных или необычных разрешений крайне затрудняет компаниям в сфере безопасности сканирование и обнаружение подобных злоупотреблений. Когда единственная активность программы состоит в сетевых запросах, отличить её от законного приложения практически невозможно.

В-третьих, современные вредоносные программы находятся в серой правовой и моральной зоне. Автор вредоносной программы, который похитит банковские учётные данные пользователя и опустошит его счёт, привлечёт пристальное внимание правоохранительных органов. Но разработчика, который платит создателям приложений за внедрение прокси-SDK или сбор пользовательских данных, вряд ли будут преследовать. Поэтому разработчикам вредоносных программ необязательно быть подпольными преступными организациями. Такие приложения способны создавать внешне законные компании по разработке программного обеспечения с офисными зданиями, присутствием в социальных сетях и венчурным финансированием.

Кроме того, многие успешные современные семейства вредоносных программ Android используют SDK. Мошенники с рекламой, прокси-сети и посредники по продаже данных получают с каждого заражённого устройства лишь небольшую сумму, поэтому им необходимо охватить огромное количество устройств. Для этого разработчики создают SDK и убеждают разработчиков законных программ использовать их в приложениях добровольно или за плату. В нескольких открыто описанных случаях вредоносные SDK были встроены в приложения, установленные сотни миллионов раз. Ни один другой известный способ не позволяет разработчикам вредоносных программ достичь такого масштаба.

Чтобы убедить разработчиков законных приложений внедрить SDK, не задавая лишних вопросов, необходимо хотя бы создавать видимость законности. Этим объясняется, почему многие компании, выпускающие вредоносные программы, притворялись законными участниками экосистемы Android. У них есть профессиональные сайты, присутствие в LinkedIn и даже штатные менеджеры по работе с клиентами, выстраивающие отношения с законными разработчиками популярных приложений.

Метод SDK также переносит расходы и риски с разработчиков вредоносных программ на ничего не подозревающих законных разработчиков. Когда вредоносный SDK разоблачён, прекращение угрожает учётной записи Google Play законного разработчика. Стоящие за SDK мошенники скрывают следы за подставными компаниями в таких странах, как Сейшельские Острова. Подставную компанию, заработавшую дурную репутацию, легко заменить новой, управляемой теми же людьми.

Посредники по продаже данных существуют столько же, сколько Android, но их популярность выросла примерно в 2017 году, когда всё больше таких компаний начали создавать SDK и платить законным разработчикам за тайное внедрение в приложения. Эти SDK собирают как можно больше сведений об истории местоположений пользователя, использовании приложений и поведении при просмотре сайтов. Поскольку потенциальных покупателей таких данных предостаточно, многие компании испытывают границы того, какие виды сбора разрешены правилами Google Play.

Основанная в 2016 году американская компания OneAudience стала одним из первых участников этой области. Она заявляла, что её цель - «помогать разработчикам получать новый доход, обогащая сведения о пользователях приложений аналитическими данными об аудитории, которых жаждут рекламодатели». В 2019 году выяснилось, что OneAudience предоставляла Android SDK, который без согласия пользователей собирал сведения из Twitter, переименованного в X в 2023 году, и Facebook. После разоблачения компания быстро объявила о закрытии. Позднее Facebook подала против разработчика иск в связи с практиками доступа компании к данным. Стороны урегулировали спор, как описано в записи блога Facebook за февраль 2020 года «Taking Action Against Platform Abuse». OneAudience признала факт урегулирования на своём сайте, однако продукт и компания остались закрыты.

Технические подробности доступа OneAudience к учётным записям Twitter и Facebook раскрывают проблему безопасности, общую для всех популярных операционных систем. Современные приложения строятся сочетанием собственного кода с множеством дополнительных SDK. По умолчанию весь этот код выполняется в одном процессе. Внутри процесса нет границ безопасности, поскольку операционная система предполагает, что весь код одного процесса одинаково заслуживает доверия. К сожалению, эта модель устарела и нереалистична. Существуют недобросовестные SDK, имеющие полный доступ ко всем остальным SDK и основному коду приложения.

В листинге 2-18, взятом из приложения com.bestcoolfungames.cockroachsmasher (v10617, 52f2), показано, как SDK OneAudience с помощью рефлексии получает доступ к сведениям пользователей Facebook и Twitter. Такое поведение возможно потому, что SDK Facebook и Twitter работают в одном процессе приложения с SDK OneAudience. Если пользователь прежде входил в Twitter или Facebook внутри приложения, SDK Twitter и Facebook содержат его токены аутентификации. OneAudience собирает эти токены и тайно подключается с ними к учётным записям Twitter и Facebook пользователя, извлекая личные сведения.

Листинг 2-18. OneAudience использует рефлексию для доступа к токенам аутентификации Twitter и Facebook

Помимо сведений Twitter и Facebook, OneAudience также собирала адреса электронной почты пользователя, историю телефонных звонков, список контактов, местоположение, перечень установленных приложений и многое другое.

В 2018 году российская антивирусная компания «Доктор Веб» обнаружила крупнейшее семейство того года для мошенничества с кликами. В записи блога за август 2019 года «Doctor Web: Clicker Trojan Installed from Google Play by Some 102,000,000 Android Users» компания дала семейству невзрачное имя Android.Click.312.origin. Это обобщённое название преуменьшает значение семейства, которое сохраняло заметное положение в 2019 и 2020 годах.

Android.Click.312.origin - типичный SDK для мошенничества с кликами. Он использует сильно обфусцированные имена классов и переменных и шифрует все строки собственным алгоритмом. В листинге 2-19 показан фрагмент из приложения com.happylife.callflash (v26, dca4).

Листинг 2-19. С помощью обфускации имён и собственного шифрования строк Android.Click.312.origin защищается от примитивного анализа

Под всей этой обфускацией и шифрованием Android.Click.312.origin устроена незамысловато. По прошествии определённого времени SDK начинает создавать невидимые объекты WebView и выполнять JavaScript-код, который мошеннически нажимает рекламные объявления.

В ноябре 2018 года BuzzFeed News опубликовала статью «These Hugely Popular Android Apps Have Been Committing Ad Fraud Behind Users’ Backs» о серьёзной форме рекламного мошенничества, обнаруженной американской рекламной компанией Kochava. В статье китайская компания по разработке мобильных приложений Cheetah Mobile обвинялась в обмане законных рекламодателей с помощью метода, называемого мошенничеством с атрибуцией установок. После выхода статьи BuzzFeed News деятельность Cheetah Mobile в Google Play была окончательно приостановлена.

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

В ответ на обвинения BuzzFeed News и Kochava представители Cheetah Mobile опубликовали цикл из девяти записей блога со своей точкой зрения. Отрицая ответственность за мошенническое поведение, Cheetah Mobile возложила вину на несколько SDK, встроенных в её приложения, прежде всего на Batmobi, Duapps и Altamob, которые сами были разработаны тремя китайскими компаниями в области мобильной рекламы.

Определение виновника мошенничества, как и вопрос о том, были ли действительно поданы иски, которыми стороны угрожали друг другу, выходит за рамки этой книги, но давайте посмотрим, как работает данная схема. Для мошенничества с атрибуцией установок SDK непрерывно отслеживают установки из Google Play. После нескольких проверок правдоподобия, скрывающих мошенническую деятельность, они передают широковещательное сообщение com.android.vending.INSTALL_REFERRER, заявляя себя источником новой установки приложения. Этот простой мошеннический приём показан в листинге 2-20.

Листинг 2-20. SDK отправляет сообщение об источнике установки, чтобы мошеннически объявить себя источником установки приложения

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

В 2019 году широкую известность получил другой проблемный вид SDK - финансовые SDK для борьбы с мошенничеством. Встроенные в финансовые приложения, обычно программы для получения личных займов, такие SDK определяют, является ли пользователь настоящим человеком. На первый взгляд подобная практика кажется совершенно разумной мерой защиты клиентов. Проблема заключается в том, что SDK собирают с устройств так много данных, что переходят в область шпионских программ. Например, крупнейший из них, названный командой Android Security Loan Spy, злоупотребляет API специальных возможностей, чтобы получить доступ к сообщениям WhatsApp, а затем по характеру использования WhatsApp оценивает, является ли пользователь настоящим.

Об этих SDK открыто известно мало, но в октябре 2019 года китайский новостной сайт China Money Network сообщил, что власти провели обыск в офисах технологической компании Tongdun в связи с одной из таких схем. В статье «China Cracks Down on Malicious Lending and Web Crawlers, Temasek-Backed Tongdun Tech Implicated» говорится:

Как и конкуренты, Loan Spy получает доступ к настоящему длинному перечню конфиденциальных сведений на устройстве пользователя: журналу звонков, SMS, спискам контактов, данным GPS о местоположении и так далее. Однако больше всего тревожит то, что Loan Spy злоупотребляет API специальных возможностей, чтобы нарушить границы песочницы между приложениями Android. Этот API содержит вспомогательные инструменты, такие как экранные дикторы, имитация ввода и другие функции, которые игнорируют песочницу между приложениями, чтобы полноценно взаимодействовать со всеми программами в системе.

Возможно, вы задаётесь вопросом, как эти SDK могут получить широкое распространение, если они нацелены только на приложения финансовых учреждений. Ответ заключается в том, что ситуация с кредитованием в Юго-Восточной Азии разительно отличается от западного мира. В годы перед 2020-м спрос на персональные кредитные линии значительно вырос, что привело к созданию и публикации более 10 000 небольших приложений персонального кредитования для пользователей этого региона. Всем таким приложениям нужны способы определить, не выдают ли они деньги вымышленным лицам, поскольку в этом случае вероятность последующего возврата займа была бы невелика. Поэтому присутствие Loan Spy на устройствах Android достигло масштаба, сопоставимого с намеренно мошенническими вредоносными сетями.

В годы перед 2023-м пользователи приложений широко сообщали ещё об одной проблеме программ персонального кредитования. Используя ранее собранные с устройств персональные данные, кредитные компании звонили людям, просрочившим платежи, и угрожали им или даже их друзьям и родственникам. В апреле 2023 года команда правил Google Play отреагировала запретом приложениям персональных займов запрашивать разрешения Android, связанные с такими персональными сведениями, как списки контактов, номера телефонов, фотографии и местоположение. В дальнейшем приложения персонального кредитования не смогут использовать эти разрешения ни по какой причине.

Двумя крупнейшими семействами вредоносных программ, обнаруженными вне Google Play начиная с 2017 года, были Loapi/Podec и HDC Bookmark. Из них Loapi/Podec представляет больший интерес. Российская компания «Лаборатория Касперского» впервые описала Podec в опубликованной в марте 2015 года записи блога «SMS Trojan Bypasses CAPTCHA». Последующая публикация за декабрь 2017 года «Jack of All Trades» связала новую разновидность, названную Loapi, с Podec.

Возможно, Loapi/Podec начиналась как простая вредоносная программа для мошенничества с SMS, но со временем превратилась в мощный троян-бэкдор. По данным «Лаборатории Касперского», версия 2015 года, Podec, обрабатывала 16 разных команд серверов управления. Хотя большинство команд относилось к оформлению платных подписок или общему злоупотреблению SMS и телефонными звонками, одна примечательная команда приказывала заражённым устройствам выполнить DDoS-атаку на указанную цель.

Разновидность 2017 года, Loapi, расширила возможности Podec сложной системой подключаемых модулей, которая могла загружать и выполнять дополнительные вредоносные компоненты в соответствии с указаниями сервера управления. В частности, «Лаборатория Касперского» отмечает способность трояна заниматься мошенничеством с рекламой, добывать криптовалюту Monero и выполнять множество других действий.

Второе крупное семейство того периода, устанавливавшееся из сторонних источников, HDC Bookmark, оказалось менее сложным. Его автор массово создавал многие тысячи приложений, имена пакетов которых начинались с com.hdc.bookmark и заканчивались случайным числом, например com.hdc.bookmark52428 (v1, 1dda). Эти программы были нацелены на Вьетнам и, по-видимому, связаны с apkfull.mobi - вьетнамским сайтом, существовавшим с 2013 по 2018 год и предлагавшим взломанные версии приложений и игр Android. Приложения HDC Bookmark позволяли загружать их за небольшую плату около 0,65 доллара.

Хотя поначалу это, вероятно, приносило прибыль, мы не считаем, что семейство добилось долгосрочного успеха. Приложения не защищаются от обнаружения, и большинство распространённых антивирусных продуктов Android надёжно их выявляет. Кроме того, теперь операционная система Android защищает процесс оформления подписки на услуги через SMS, показывая пользователям предупреждение о попытке приложения отправить дорогостоящее сообщение. Это может объяснять исчезновение сайта apkfull.mobi в 2018 году.

Однако в приложениях HDC Bookmark есть коварная функция, позволяющая отправлять платные сообщения, даже если пользователь явно отказался. Зашифрованные файлы ресурсов, например assets/map.lib, содержат параметры конфигурации в формате JSON. Если задан параметр url_config_auto_sms, приложение отправляет платное SMS независимо от желания пользователя платить 15 000 вьетнамских донгов за пиратское приложение. В листинге 2-21 приведён обработчик нажатия кнопки Cancel в диалоговом окне подписки.

Листинг 2-21. Независимо от выбора пользователя com.hdc.bookmark52428 (v1, 1dda) можно настроить так, чтобы приложение всегда отправляло платные SMS

Если auto_sms отключён, после отказа пользователя от предложения приложение завершает работу. Но если auto_sms включён, приложение проверяет, услугами какого вьетнамского мобильного оператора пользуется устройство, и отправляет платное SMS. Такое поведение является мошенническим.

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

Одним особенно неприятным семейством предустановленных вредоносных программ была EagerFonts - троян, замаскированный под приложение управления шрифтами и загружавший вредоносные модули в фоновом режиме. Разработчики EagerFonts убедили поставщика наборов микросхем включить приложение в свой SDK для разработки. В результате были заражены устройства всех изготовителей, использовавших SDK этого набора микросхем. В общей сложности EagerFonts скомпрометировала более 12 миллионов устройств свыше 1 000 моделей, созданных сотнями изготовителей.

EagerFonts наглядно показывает простую истину о компрометации цепочки поставок: чем выше по цепочке происходит компрометация, тем больше заражённых устройств. Убедить одного изготовителя включить вредоносную программу в устройства выгодно, но убедить поставщика более чем 100 изготовителей - всё равно что выиграть в лотерею. Даже если злоупотребление будет обнаружено, удаление вредоносной программы потребует многомесячной координации между поставщиками и, вероятно, не охватит значительную долю заражённых устройств. Всё это время программа будет продолжать приносить деньги разработчикам.

Технические подробности этой вредоносной программы команда Android Security описала в докладе BlackHat USA 2019 «Securing the System - A Deep Dive into Reversing Android Pre-Installed Apps». Слайды доклада свободно доступны в интернете. Как и у большинства предустановленных бэкдоров, основное назначение EagerFonts - загрузка подключаемых модулей с вредоносными функциями. Она соединяется с сервером управления pushstablev9.ekesoo.com, как показано в листинге 2-22. На этом домене преимущественно размещён порнографический сайт.

Листинг 2-22. EagerFonts связывается со своим сервером управления

Кроме кода для загрузки вредоносных подключаемых модулей и управления ими, EagerFonts содержит мало других функций. Загруженные модули весьма разнообразны и принадлежат таким китайским семействам вредоносных программ, как Chamois и Snowfox, рассмотренным ранее в этой главе.

Разработчики вредоносных программ неоднократно атаковали одну конкретную часть цепочки поставки предустановленных приложений: сторонних поставщиков обновлений по беспроводной сети (over-the-air, OTA). Программное обеспечение OTA загружает и устанавливает системные обновления на устройства Android, будь то небольшие ежемесячные обновления безопасности или новые версии Android. Для установки обновлений программы OTA должны вносить изменения глубоко внутри системы Android, поэтому им предоставляются одни из самых высоких доступных привилегий. Такое привилегированное положение делает их главной целью разработчиков вредоносных программ Android.

Изготовители управляют обновлениями устройств и распространяют их с помощью нескольких стратегий. Крупные компании, например Samsung и Xiaomi, самостоятельно управляют инфраструктурой и программным обеспечением обновлений OTA. Google предоставляет GOTA - бесплатное решение для распространения обновлений OTA и управления ими на устройствах с Google Play Services. Изготовители, которые не могут или не хотят использовать GOTA, могут выбрать примерно из десятка коммерческих поставщиков решений OTA. После ряда проблем безопасности исследователи начали изучать таких коммерческих поставщиков.

Первым рассматриваемым поставщиком OTA является тайбэйская General Mobile Corporation (GMobi). Опасения по поводу приложения OTA компании GMobi впервые стали известны, когда в марте 2016 года российская компания «Доктор Веб» опубликовала запись блога «New Adware for Android Attacked Firmware and Apps by Well-Known Companies». Исследователи «Доктора Веб» отметили такие возможности, как сбор данных, например адресов электронной почты пользователя и его GPS-координат, показ нежелательной рекламы и установка новых приложений без согласия пользователя. В частности, возможность устанавливать приложения привела к инцидентам с вредоносными программами: например, в октябре 2015 года GMobi установила приложение Ghost Push почти на миллион устройств.

Несколькими месяцами ранее, в январе 2015 года, статья Tech in Asia описала бизнес-модель GMobi. В статье под названием «Meet the Company Stamping Bloatware on Millions of Emerging Market Smartphones» говорилось:

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

GMobi привлекла внимание и других компаний в сфере безопасности. Немецкая антивирусная компания Avira описала проблемы рекламного программного обеспечения GMobi в апрельской записи блога 2016 года «Trojan Adware Hits Budget Androids - And Some Well-Known Apps». В июле 2018 года статья The Washington Post «App Traps: How Cheap Smartphones Siphon User Data in Developing Countries» использовала исследование британской компании Upstream Systems для дальнейшего изучения практик GMobi по сбору данных.

Ещё один поставщик OTA с документированной историей проблем безопасности - шанхайская компания Adups. В октябре 2016 года компания Kryptowire разоблачила шпионское поведение программного обеспечения OTA Adups. В её отчёте «Android Firmware Sharing Private Data Without Consent» отмечается, что программа Adups собирает текстовые сообщения, сведения из списков контактов и журнал вызовов устройства, включая полные номера телефонов.

Как и GMobi, программа Adups способна загружать и устанавливать другие приложения без согласия пользователя. Первое открытое свидетельство этой функции относится по меньшей мере к январю 2015 года, когда пользователь Reddit опубликовал в подразделе /r/india следующее сообщение:

Adups продолжала развивать эти возможности и загружала и устанавливала приложения, входившие в крупные китайские ботнеты, такие как Ghost Push и Snowfox. Некоторые версии Adups привлекли такое внимание исследователей безопасности, что американская оборонная некоммерческая организация MITRE Corporation теперь включает её в MITRE ATT&CK - отраслевой стандартный репозиторий тактик и методов вредоносных программ.

Третьей компанией OTA с историей проблем безопасности является пекинская Redstone Sunshine. В апреле 2021 года американская компания по борьбе с вредоносными программами Malwarebytes выразила обеспокоенность Redstone в статье «Pre-Installed Auto Installer Threat Found on Android Mobile Devices in Germany». Статья вызвала немалый резонанс в технической прессе. Например, крупнейший немецкий компьютерный журнал Computer Bild подхватил эту историю, а немецкое Федеральное управление по информационной безопасности (Bundesamt für Sicherheit in der Informationstechnik) выпустило предупреждение для немецких пользователей затронутых устройств.

В ноябре 2021 года «Доктор Веб» описал ряд проблем со сбором данных и скрытой установкой приложений, затрагивавших умные часы Elari Kidphone 4G. В записи блога «Doctor Web Discovered Vulnerabilities in Children’s Smart Watches» рассказывается, как компонент OTA можно было использовать для «кибершпионажа, показа рекламы и установки нежелательных или даже вредоносных приложений». В тексте «Доктор Веб» не упоминает Redstone, но многие представленные в публикации вредоносные файлы принадлежат решению OTA компании Redstone. Это можно проверить по сведениям о подписи показанных файлов приложений.

Компания Digitime из китайского Шэньчжэня оставалась незамеченной профессиональным сообществом безопасности и технической прессой до 2019 года. В том году независимый исследователь безопасности под псевдонимом Ninji задокументировал проблемы с функциями программного обеспечения OTA Digitime. В декабрьской записи блога «Researching the Digitime Tech FOTA Backdoors» Ninji описывает развитую систему подключаемых модулей Digitime на основе Lua, которая загружает дополнительные модули с проблемными функциями. В их число входит возможность устанавливать и удалять любые приложения на устройстве и предоставлять им любые разрешения без запроса.

Полгода спустя программное обеспечение обновлений OTA компании Digitime вызвало общественное беспокойство. Malwarebytes обнаружила проблемы безопасности и конфиденциальности недорогого устройства UMX U683CL, созданного китайской компанией TeleEpoch, выпущенного под брендом китайского изготовителя Unimax и продававшегося американским оператором мобильной связи Assurance Wireless. Несмотря на участие малоизвестных изготовителей, эта модель устройства заслуживает внимания. Она входила в Lifeline - федеральную программу снижения ежемесячной стоимости телефонной связи и интернета для имеющих право на помощь граждан США. Обнаружение у этого созданного в Китае устройства функций бэкдора и шпионской программы вызвало шум в национальной прессе, хотя Digitime временно осталась невредимой: Malwarebytes ошибочно приписала программное обеспечение OTA компании Adups. Затем, в июле 2020 года, анонимный участник под именем Concerned_Citizen опубликовал на общедоступном форуме Malwarebytes тему «Pre-Installed Malware on Lifeline Phones», где объяснил, как применил руководство Ninji по обратной разработке к Lua-коду программы и обнаружил, что настоящей компанией, стоящей за приложением, была Digitime.

Со временем Digitime создала всё более сложную схему обфускации и шифрования, скрывающую механизм подключаемых модулей на Lua. Последние версии, например com.qiot.update (v1032, 4529), впервые появились в сентябре 2019 года и были установлены на таких устройствах, как Oukitel C22 и Okapi 10 Pro. На этих устройствах Digitime изменяет системный компонент Android frameworks.jar, добавляя нестандартные пакеты с именами com.internal.jar.pl.*. Код этих пакетов обращается к нативной библиотеке ELF /system/lib64/libpowerhalwrap_jni.so. Пройдя всевозможные проверки против анализа, библиотека ELF сохраняет два файла DEX и ZIP-файл со стандартной платформой Lua.

Интерпретатор Lua статически скомпонован с библиотекой ELF, но содержит одно дерзкое изменение: метод luaL_loadfile, отвечающий за загрузку сценариев Lua, модифицирован для загрузки нестандартных файлов Lua, зашифрованных простым алгоритмом XOR. Поэтому после извлечения сценариев аналитики должны их расшифровать, прежде чем загружать в инструменты обратной разработки Lua, например LuaDec.

К счастью, алгоритм шифрования прост. Изменённый метод luaL_loadfile использует XOR-блокнот, который можно создать кодом Python из листинга 2-23.

Листинг 2-23. Код Python для расшифрования зашифрованных сценариев Python компании Digitime

Если сценарии Lua выполняются успешно, они связываются с сервером управления по адресу rp1.androidevlog.com:10000, получают параметры конфигурации и загружают дополнительные модули Lua. Они загружают вредоносные подключаемые модули с таких доменов, как google-global.com, facebook-3rd.com, bugreportsync.com, flurrydata.com и gmscenter.org, которые выдают себя за законные компании экосистемы Android и, вероятно, были выбраны для обмана исследователей безопасности, читающих журналы или исходный код.

Дополнительные сведения о технических возможностях программного обеспечения Digitime и их развитии со временем команда Android Security представила на конференциях Virus Bulletin 2022 и BotConf 2023 в двух докладах под названием «You OTA Know: Combating Malicious Android System Updaters».

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

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

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

При профессиональном анализе вредоносных программ редко приходится исследовать случайный образец приложения, о котором ничего не известно. Обычно специалисты по обратной разработке изучают конкретное приложение, чтобы подтвердить или опровергнуть ранее сформированные предположения о его свойствах. Такие сведения могут поступить от сканеров вредоносных программ, которые пометили приложение в вашей системе, из случайного обсуждения в X, из результатов быстрого запуска в механизме анализа или из исследования связанных образцов. При таком направленном анализе специалисты обычно знают, с чего начать поиски. Разборы вредоносных программ в этой и следующей главах являются ненаправленными: мы приступаем к работе без каких-либо предварительных сведений об образцах. Все открытия предстоит сделать посредством исследования приложений.

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

Самый простой способ избежать полной проверки кода - научиться понимать SDK, используемые в приложениях. По нашим оценкам, около 80 процентов кода среднего приложения поступает из сторонних SDK. Специалистам по обратной разработке Android нужны инструменты распознавания SDK; иначе они будут кропотливо заново открывать сведения, которые могли бы узнать из общедоступной документации SDK.

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

Опыт показывает, что аналитикам вредоносных программ следует либо действовать быстро, оперативно подтверждая вредоносность приложения, чтобы принять меры по его отключению, либо работать медленно, проводя углублённое исследование и попутно узнавая, как усовершенствовать свои инструменты и процессы. Избегайте продолжительного анализа вредоносной программы, если вряд ли извлечёте уроки, которые облегчат будущие исследования.

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

Разрешения часто оказываются первым, о чём люди думают при обсуждении безопасности приложений Android. Чтобы использовать чувствительные Android API, приложения должны объявить разрешения, а пользователи - предоставить их, прежде чем программы получат доступ к этим API. Поскольку такая модель разрешений опирается на взаимодействие и согласие пользователя, она хорошо заметна всем владельцам телефонов Android. Однако и пользователи, и специалисты по обратной разработке нередко делают неверные выводы о приложениях на основании разрешений. В конечном счёте система разрешений - джентльменское соглашение между приложением и пользователем: приложение заявляет, что будет использовать разрешение для объявленной цели, но операционная система не способна проверить, что программа в действительности с ним делает.

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

Тем не менее разрешения по-прежнему дают разумный способ составить представление о неизвестной вредоносной программе. Программы, вступающие в сговор с другими приложениями или использующие эксплойты для повышения привилегий разрешений, встречаются редко. Если нет никаких признаков того, что перед вами такая программа, разумно считать объявленные приложением разрешения границами его возможностей.

Приложения должны объявлять все разрешения, которые хотят использовать, в файле AndroidManifest.xml, находящемся в корневой папке APK приложения Android. На рисунке 3-2 показано начало файла манифеста нашего образца, который можно просмотреть в jadx, перейдя к Resources > AndroidManifest.xml.

Рисунок 3-2. Просмотр разрешений приложения в jadx

Здесь видны некоторые запрошенные приложением разрешения. Другие, объявленные далее в файле, на снимке экрана не показаны. С помощью тегов <uses-permission> образец объявляет намерение использовать следующие разрешения:

• INTERNET

• WAKE_LOCK

• RECEIVE_BOOT_COMPLETED

• READ_CONTACTS

• READ_PHONE_STATE

• CHANGE_NETWORK_STATE

• ACCESS_NETWORK_STATE

• BIND_GET_INSTALL_REFERRER_SERVICE

С помощью тегов <service> он также объявляет намерение использовать следующие разрешения:

• BIND_NOTIFICATION_LISTENER_SERVICE

• BIND_JOB_SERVICE

При анализе вредоносных программ не все разрешения одинаково важны. Например, разрешение WAKE_LOCK не кажется особенно интересным, поскольку относится к API, не позволяющим устройствам засыпать или пробуждающим их. Разрешение INTERNET также бесполезно: его использует почти каждое приложение, поэтому оно не помогает отличать вредоносные программы от безвредных. С другой стороны, потенциальный интерес представляют любые разрешения доступа к данным, имена которых начинаются с READ_. Например, зачем приложению для измерения показателей сахара в крови доступ к вашему списку контактов?

Чтобы находить вредоносный код по объявленным приложением разрешениям, необходимо также знать, какие Android API они защищают, или ограждают. Выяснить это на удивление сложно, поскольку официального справочника с подобными сведениями не существует. На протяжении многих лет несколько академических исследовательских групп пытались создать карты разрешений Android API. Это также оказалось непростой задачей: каждая новая версия Android вносит изменения в систему разрешений, поэтому поддерживать карты API в актуальном состоянии утомительно, - но такие карты помогают находить API, защищённые разрешениями. В 2016 году исследователи Саарского университета и Университета штата Пенсильвания создали подобную карту, доступную по адресу github.com. Ещё один вариант - карта, разработанная исследователями Университета Пердью в 2018 году и доступная по адресу arcade-android.github.io.

К сожалению, jadx не умеет автоматически показывать API, защищённые разрешениями. Для их быстрого поиска в приложении можно использовать версию jadx для командной строки, а затем написать сценарий, который разбирает одну из карт разрешений и сравнивает её с декомпилированным кодом приложения. Со временем серьёзным специалистам по обратной разработке Android следует создать более надёжное решение этой задачи.

Ещё один подход к поиску API, защищённых разрешениями, в хорошо разработанных приложениях - искать код, который запрашивает согласие пользователя на применение этих разрешений. Например, можно искать строки, содержащие слово permission, или API, используемые для запроса доступа. Хорошо написанные приложения должны спрашивать согласие непосредственно перед использованием API, поэтому соответствующий код должен находиться рядом.

Разрешение READ_CONTACTS наглядно показывает ещё одну проблему карт разрешений: в Android разрешения защищают не только API. Они также защищают поставщиков содержимого, которые служат источниками конфиденциальных данных. Хотя упомянутые в предыдущем разделе карты показывают несколько весьма малоизвестных API, скрытых за разрешением READ_CONTACTS, обычно оно просто предоставляет доступ к списку контактов пользователя через поставщиков содержимого content://contacts или content://com.android.contacts.

Таким образом, заметив это разрешение, вы можете сначала подумать, что оно используется для кражи сведений из чьего-либо списка контактов. Но почему тогда шпионское приложение не запрашивает также разрешения READ_SMS, READ_CALENDAR и READ_CALL_LOGS, чтобы похищать сведения из SMS, календаря и журнала звонков? Шпионская программа, нацеленная только на сведения из списка контактов, безусловно, может существовать, но встречается гораздо реже шпионских программ, собирающих больше информации.

В jadx можно использовать сочетание клавиш Ctrl-Shift-F для поиска по всему коду приложения и файлам ресурсов. Однако поиск слова contact с отключённым учётом регистра в нашем образце возвращает лишь несколько результатов, включая объявление разрешения в файле манифеста. Несколько строк кода в классах из пакетов, имена которых начинаются с androidx.activity или com.google.android.gms, выглядят как API, предоставленные Google. Поиск вредоносных функций с помощью READ_CONTACTS для этого образца ничего не дал.

Впрочем, у вывода о том, что разрешение не используется во вредоносных целях, снова есть оговорки. Вредоносный код, использующий READ_CONTACTS, может находиться в зашифрованном разделе кода или быть иным образом скрыт от ручного анализа. Или в файлы кода, описанные как Google API, мог быть внедрён вредоносный код. А возможно, эти файлы вообще не связаны с SDK Google и являются вредоносными файлами, перенявшими стандартную схему имён классов Google.

Любой из этих вариантов возможен, но мы рекомендуем сначала исследовать приложение вширь и лишь затем углубляться. Пока существуют другие способы продвигаться по приложению, изучите найденные зацепки, прежде чем погружаться в возможные, но маловероятные сценарии вроде изменённых SDK Google. Последние определённо существуют в настоящих вредоносных программах, но редко встречаются в каждом отдельно взятом образце. Далее в этой главе мы выясним, что вредоносная программа всё-таки использует READ_CONTACTS. От беглого анализа это применение скрыто.

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

Это разрешение всегда связано со службой, получающей обновления о новых уведомлениях. В листинге 3-1 показано, как наше приложение объявляет использование разрешения и связанной с ним службы.

Листинг 3-1. Объявление службы прослушивания уведомлений, получающей сведения о входящих уведомлениях

Имя класса службы объявлено как com.bp.statis.bloodsugar.PE, но, если поискать этот класс в файловом браузере jadx, найти его не удастся. Это примечательно. Зачем приложению объявлять службу, для которой отсутствует код? Возможно, в приложении есть ошибка, но далее в этой главе мы обнаружим, что класс действительно скрыт от анализа. Пока мы мало что можем сделать, поскольку найти код службы не удаётся. Ради краткости сходный анализ остальных объявленных разрешений оставим читателю в качестве упражнения.

У приложений Android на удивление много точек входа, то есть частей кода, с которых операционная система Android начинает выполнение программы. К распространённым точкам входа относятся экспортированные активности, в том числе основная активность приложения; широковещательные приёмники, обрабатывающие сообщения операционной системы или других программ; службы, определённые приложением для выполнения продолжительных операций; подклассы класса android.app.Application. Изучение кода в этих точках может стать плодотворным способом поиска вредоносного кода, поскольку опасные функции стремятся запуститься как можно раньше. Зачем ждать, пока пользователь 10 минут взаимодействует с приложением, если можно украсть его сведения сразу при запуске?

Тем не менее вредоносный код одинаково вероятен не во всех точках входа, и сначала следует рассмотреть те, что чаще используются вредоносными программами. Например, основная активность есть у каждого вредоносного и безвредного приложения, но начинать в ней поиск вредоносных функций, вероятно, не стоит. Напротив, изучение широковещательного приёмника событий BOOT_COMPLETED может быть перспективнее. Вредоносные программы стремятся закрепиться на устройствах, а распространённый способ добиться этого - заставить систему выполнять программу при каждой перезагрузке.

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

Не все активности являются точками входа в приложения. Чтобы определить такие точки, нужно различать так называемые экспортированные и неэкспортированные активности. Активности, помеченные в файле манифеста атрибутом android:exported="true", могут быть запущены извне текущего приложения и потому считаются точками входа. Активности с атрибутом android:exported="false" можно запускать только внутри текущего приложения, поэтому точками входа они не являются.

Однако найти экспортированные активности бывает непросто. До Android 12 разработчики могли не указывать тег android:exported в объявлениях активностей. В таких случаях значение по умолчанию - true или false - зависело от других свойств конфигурации. Это сбивало разработчиков с толку и приводило к ошибкам и уязвимостям безопасности из-за случайно экспортированных активностей, поэтому начиная с Android 12 для всех активностей приложения требуется явное объявление. При анализе приложений, разработанных для более ранних версий, до Android API 31, мы рекомендуем один раз изучить правила и закодировать их в небольшом вспомогательном инструменте, способном выделять экспортированные активности. Иначе специалисты по обратной разработке рискуют повторить ошибки разработчиков приложений.

Наш образец объявляет лишь одну интересную активность - основную, показанную в листинге 3-2. Остальные активности поступают из SDK Google, и пока мы считаем их законными и не подвергшимися вредоносным изменениям.

Листинг 3-2. Объявление основной активности нашего образца

XML-код объявления основных активностей полон шаблонных конструкций. Для нас важна только одна часть - имя активности com.bp.statis.bloodsugar.MainActivity. Двойной щелчок по этому имени в jadx немедленно переносит к её определению. К сожалению, оно состоит более чем из 600 строк кода пользовательского интерфейса без каких-либо интересных функций. Поскольку у приложения нет других экспортированных активностей, больше в этом разделе искать нечего.

Ещё одно ключевое понятие Android - широковещательные приёмники, часть системы обмена сообщениями Android. Все приложения Android могут отправлять сообщения, или широковещательные передачи, друг другу либо самим себе, а широковещательные приёмники получают и обрабатывают входящие сообщения.

С точки зрения обратной разработки широковещательные приёмники делятся на две отдельные категории: их можно объявить в файле манифеста, так называемые приёмники, зарегистрированные в манифесте, либо программно зарегистрировать во время работы приложения, то есть зарегистрировать в контексте. Объявленные в манифесте приёмники легко заметить, поскольку от аналитиков вредоносных программ их скрыть нельзя. Зарегистрированные во время выполнения обнаружить не так просто: они могут быть спрятаны зашифрованным или обфусцированным кодом, который выполняет необходимые для настройки приёмников вызовы API.

Начиная с Android API 26 система пробуждает приложения только с помощью приёмников, объявленных в манифесте. Зарегистрированные в контексте приёмники способны работать лишь тогда, когда приложение уже запущено. Поэтому при поиске точек входа в приложения следует рассматривать только приёмники, объявленные в манифесте.

Хотя файл манифеста нашего образца объявляет восемь широковещательных приёмников с помощью тега <receiver>, все они указывают на классы, которые, по-видимому, поступают из стандартных SDK Google. Несмотря на то что в данном случае широковещательные приёмники не дают полезных точек входа, многие образцы вредоносных программ их используют. Например, регистрация для получения сообщений BOOT_COMPLETED - популярный способ снова запустить вредоносную программу после перезагрузки системы. Далее в этой главе вы также увидите, что образец настраивает зарегистрированные в контексте приёмники, от которых в файле манифеста нет никаких следов. В частности, вредоносная программа регистрирует приёмник RECEIVE_SMS, чтобы перехватывать входящие SMS и похищать одноразовые пароли.

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

Наш образец объявляет девять служб, восемь из которых снова, по-видимому, относятся к SDK Google. Оставшаяся служба - com.bp.statis.bloodsugar.PE, которую мы уже обсуждали при анализе разрешений. Она получает и перехватывает входящие уведомления всех приложений в системе.

Другими законными, хотя и несколько малоизвестными точками входа в приложения Android являются подклассы класса android.app.Application. По умолчанию во всех приложениях Android имеется реализация этого Java-класса. Программы, которым требуется отклониться от стандартного поведения приложения, могут создать подкласс стандартного класса. Если приложение использует такой подкласс, его имя можно найти в теге <application> файла манифеста.

Наш образец действительно объявляет подкласс стандартной реализации android.app.Application. Внутри тега <application> вы должны увидеть следующее объявление, где полное имя, указанное как значение атрибута android:name, переопределяет стандартный класс:

Судя по пути, класс androidx.multidex.MultiDexApplication поступает из стандартного SDK Google. Из официальной документации можно узнать, что он появился для обхода ограничений размера крупных приложений. По нашему опыту, современные приложения всё чаще используют этот атрибут, поэтому он встречается довольно часто.

Однако в нашем образце этот класс был вредоносно изменён. Двойной щелчок по имени класса в jadx открывает код из листинга 3-3.

Листинг 3-3. Вредоносный код запускается из подкласса android.app.Application

Большая часть кода является шаблонной, за исключением строки new b(this).o(). Создание экземпляра объекта класса d.b и вызов его метода o крайне необычны. Двойной щелчок по d или o в jadx переносит к сильно обфусцированному коду. Мы ещё вернёмся к нему.

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

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

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

Обнаружение и понимание методов противодействия анализу само по себе является наукой. Для начала можно прочитать раздел «Defense Evasion» платформы MITRE ATT&CK для Android - свободно доступного стандарта документирования методов вредоносных программ. Со временем мы рекомендуем специалистам по обратной разработке создавать инструменты для точного обнаружения методов противодействия анализу в приложениях. Выполнять эту работу вручную трудно и долго, поскольку существуют и открыто описаны сотни отдельных методов.

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

Более умные вредоносные приложения применяют сложные методы, учитывающие сведения извне устройства. Например, мы встречали приложения, которые проверяют, опубликованы ли они по-прежнему в Google Play или поступает ли соединение с их серверами из диапазона IP-адресов определённой страны. Особенно распространённый в наши дни приём - проверять, было ли приложение установлено через оплаченный автором вредоносной программы клик по рекламе. Приложение выполняет вредоносные функции, только если пользователь установил его из этого объявления; автоматизированные защитные инструменты, которые не устанавливали программу посредством клика по рекламе, не смогут запустить вредоносную нагрузку. Этот метод становится особенно сложным, когда некоторые свойства рекламной кампании используются как ключи расшифрования последующих этапов кода. Без сведений из рекламного клика расшифровать отдельные части вредоносного кода может оказаться невозможно.

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

Эти инструменты нередко применяют сложные статические методы противодействия анализу. Чтобы затруднить понимание исходного кода, они могут реализовать обфускацию потока управления, искажающую первоначальный ход выполнения кода в приложении, или обфускацию потока данных, усложняющую отслеживание взаимодействия переменных. Самые сложные упаковщики даже берут исходный код приложения и повторно компилируют его в собственный специализированный код. Для понимания преобразованного кода требуются знания байт-кода, определённого упаковщиком, и абстрактной машины, которая его интерпретирует.

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

API рефлексии Java, определённые в пакете java.lang.reflect, используются для динамического поиска, создания экземпляров и вызова классов и методов. Они позволяют приложениям динамически загружать код, который мог отсутствовать во время компиляции, например подключаемые модули. Безвредные приложения тоже часто используют эти API. Например, они могут загружать безопасные подключаемые модули, выбирать разные API в зависимости от текущей версии операционной системы или обращаться к закрытым API, которые предполагалось скрыть от приложений.

Тем не менее поиск API рефлексии эффективен при анализе вредоносных программ, поскольку факт использования рефлексии скрыть нельзя. Более того, безвредное и вредоносное применение зачастую легко различить. Почти во всех случаях безопасная рефлексия передаёт API рефлексии постоянные аргументы. Например, приложение может искать закрытые Android API по имени. Вредоносная рефлексия обычно использует непостоянные аргументы, составляемые во время выполнения, либо зашифрованные или обфусцированные строки, которые декодируются непосредственно перед передачей API рефлексии. Поэтому человек способен очень быстро просмотреть случаи применения рефлексии и найти наиболее вероятные вредоносные варианты.

В декомпилированном коде jadx все классы, использующие рефлексию, начинаются с инструкции импорта API рефлексии, поэтому поиск в диалоговом окне строки import java.lang.reflect должен вернуть все такие классы. Для нашего образца поиск выдаёт 293 результата, показывая, насколько распространена рефлексия. Снова предположив, что стандартные классы SDK не были вредоносно изменены, можно отбросить все результаты в пакетах Java androidx.*, kotlin.* и com.google.*. Остаётся несколько совпадений в пакетах, начинающихся с b.*, d.* и e.*. Пакет d.* мы уже определили как вероятного кандидата на вредоносный код, поэтому сначала рассмотрим два остальных.

Случайно выбранный класс b.j.k показывает пример кода рефлексии, который, вероятно, безвреден. Как видно в листинге 3-4, код пытается загрузить класс, имя которого содержит строку _LifecycleAdapter. Он не выглядит достаточно обфусцированным или динамическим для вредоносной рефлексии.

Листинг 3-4. Безвредное использование рефлексии в приложении

Что важнее, класс содержит две примечательные строки: _LifecycleAdapter и The observer class has some methods that use newer...; последняя ради краткости не включена в листинг. Быстрый поиск в интернете показывает, что эти строки взяты из стандартного класса Android androidx.lifecycle.ClassesInfoCache, а значит, код, вероятно, безвреден.

Большинство средств обфускации сохраняет иерархию пакетов при преобразовании исходного кода в обфусцированный. Поэтому соседние пакеты в обфусцированном коде, вероятно, были соседними и в исходном. Если класс b.j.k является androidx.lifecycle.ClassesInfoCache, весьма вероятно, что все классы пакета b.j принадлежат androidx.lifecycle, а все классы b.* - androidx.*. Пока примем это предположение, объявим все случаи рефлексии в b.* безопасными и двинемся дальше. Сходный анализ кода рефлексии в пакете e.* показывает, что он, вероятно, тоже является стандартной библиотекой.

Помимо API рефлексии Java из пакета java.lang.reflect, Android предоставляет несколько других API загрузки кода, которые часто применяют как безвредные, так и вредоносные приложения. Два самых распространённых - dalvik.system.DexClassLoader и dalvik.system.DexFile, причём последний объявлен устаревшим в Android API 26. Эти API могут загружать целые файлы кода Android и часто используются для загрузки подключаемых модулей. У Java и Android имеются и другие связанные API, обычно называемые API ClassLoader. Мы рекомендуем разобраться в них, а ещё лучше - разработать автоматизированный инструмент, выявляющий их в приложениях. В частности, API для загрузки кода из массивов байтов в памяти вместо файлов на диске становятся всё популярнее во вредоносных программах Android. Благодаря этому методу программы не оставляют артефактов, которые могли бы обнаружить исследователи безопасности.

Попробуйте найти в нашем образце строку dalvik.system.Dex. Поиск должен вернуть лишь один случай за пределами стандартных SDK - снова в вероятно вредоносном пакете d.*.

Современные приложения Android можно писать на множестве языков программирования и платформ, отличных от Java. В их число входят Flutter, Kotlin, Xamarin.Android и ReactNative. Разработчики вредоносных программ намеренно используют эти новые технологии, чтобы затруднить анализ.

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

Два наиболее распространённых языка программирования, которые, по нашим наблюдениям, стратегически используют вредоносные программы, - JavaScript и нативный код ARM. JavaScript, скорее всего, применяется не столько как чистый метод противодействия анализу, сколько как средство взаимодействия с сайтами. Нативный код ARM, создаваемый на C, C++ или других языках, компилируемых в код ARM, регулярно используется для сокрытия вредоносных функций. Например, вредоносная программа часто поставляется с двоичными файлами нативного кода, которые содержат всего одну процедуру расшифрования, вызываемую из Java-кода.

При анализе вредоносных программ Android мы рекомендуем искать альтернативные языки, уделяя особое внимание JavaScript и нативному коду ARM. Вредоносные приложения способны скрывать их использование, но часто оставляют характерные признаки. Например, нативный код нередко находится в папке lib файла APK. Весомыми признаками использования приложением нативного кода ARM также служат ключевые слова Java для взаимодействия с нативным кодом, например native, или API System.loadLibrary. JavaScript следует искать в объектах WebView, особенно объявляющих интерфейс JavaScript посредством API addJavascriptInterface.

В нашем образце нет очевидных признаков использования нативного кода ARM или JavaScript. Отсутствуют файлы ресурсов с нативным кодом, случаи применения упомянутых API и ключевые слова, указывающие на их присутствие. Позднее вы узнаете, что приложение всё-таки использует JavaScript, однако это скрыто и не обнаруживается без труда.

Разработчики вредоносных программ обожают шифровать и кодировать строки. Более того, использование криптографических API может подсказать местонахождение вредоносных функций. Их разработчики часто применяют стандартные реализации Java таких алгоритмов шифрования, как AES или RSA, из пакета javax.crypto. Также распространено использование java.util.Base64 или android.util.Base64. Поиск ссылок на эти пакеты может помочь быстро найти интересные методы, например расшифровывающие сообщения, полученные с серверов управления. Однако за пределами безопасных SDK Google наш образец не использует очевидным образом какие-либо API из javax.crypto. Гораздо чаще он применяет java.util.Base64, в том числе в обфусцированном пакете b.*, который мы ранее объявили безвредным.

Зайдя в тупик, специалисты по обратной разработке могут начать просматривать строки и имена методов приложения в надежде обнаружить интересные зацепки. Это занимает всего пару минут и способно привести к новым открытиям. Например, разработчики могли забыть удалить чувствительные строки журнала, либо поиск может выявить вызов API для чтения SMS пользователя.

Однако без тщательного планирования поиск строк и имён методов может оказаться пустой тратой времени, поскольку больше зависит от удачи, чем от мастерства. Чтобы придать поиску структуру, можно, например, разработать регулярное выражение, возвращающее все интересные строки и имена методов, которые приходят в голову. В него могут входить имена API для SMS или списка контактов, а также строки, соответствующие URL либо интересным поставщикам содержимого. Регулярному выражению необязательно быть идеальным, чтобы приносить пользу; его можно совершенствовать по мере обнаружения дополнительных интересных API и шаблонов строк. Например, в нашем образце поиск подозрительных строк и имён API возвращает URL в ранее выявленном вредоносном пакете d.*.

До сих пор в этой главе мы несколько раз встречали подозрительный пакет d.*. Наконец пришло время его проанализировать. Удобно, что пакет прост и состоит всего из двух классов: d.a и d.b. Интересно, что приложение, по-видимому, вообще не использует d.a, тогда как d.b выполняется прямо из точки входа приложения в подклассе android.app.Application.

Неясно, почему d.a присутствует в приложении. Возможно, разработчик использовал класс для тестирования и забыл удалить перед выпуском вредоносной программы. На его код, по-видимому, нигде нет ссылок и он ниоткуда не вызывается, его функции ограниченны и не обфусцированы, а URL сервера управления указан открытым текстом. Соединение с URL из этого файла приводит к загрузке другого файла кода с дополнительным вредоносным содержимым.

Класс d.b представляет собой первую часть вредоносных функций приложения. Мы уже знаем, что его конструктор и метод o запускаются сразу при старте программы. Просмотр класса также обнаруживает интенсивную обфускацию и шифрование кода. Например, в листинге 3-5 показан единственный конструктор класса.

Листинг 3-5. Конструктор вредоносного класса d.b

Код конструктора содержит несколько методов обфускации, встречающихся и в других местах класса. Например, многим атрибутам присваиваются кажущиеся произвольными строковые и целочисленные значения. Они выглядят обфусцированными или зашифрованными. Кроме того, код содержит сложные на вид арифметические выражения и непрозрачные предикаты. Непрозрачными предикатами называются выражения, которые вычисляются как истинные или ложные и выглядят сложными для расчёта, но всегда принимают одно и то же значение. Вредоносные программы используют их, чтобы запутать ручной и автоматизированный анализ, например затруднить отслеживание ветвления инструкций if или количества повторений циклов.

Класс d.b использует два вида условий с непрозрачными предикатами. Один из них показан в инструкции if листинга 3-5, которая сравнивает версию Android SDK с 93. Эта проверка бессмысленна: на момент написания книги до API уровня 93 остаётся более 60 версий и много десятилетий. В настоящее время выражение всегда будет возвращать false, а инструкции внутри блока if никогда не выполнятся.

Второе условие с непрозрачным предикатом в этом классе использует Java API java.util.Calendar, как показано в листинге 3-6.

Листинг 3-6. Вредоносный класс d.b использует API Calendar для построения непрозрачных предикатов

Код запрашивает у стандартного системного календаря номер текущей недели в текущем месяце. Возвращаемые этим API значения должны находиться между 0 и 6, поэтому выражение никогда не может быть истинным, а инструкции в данном блоке if также никогда не выполняются.

Мы определили методы, которыми d.b затрудняет анализ, но нам всё ещё необходимо их преодолеть, чтобы понять действия вредоносной программы. К счастью, её авторы допустили несколько важнейших ошибок, которыми мы можем воспользоваться. Без этих ошибок пришлось бы продираться почти через 1 000 строк мучительного для чтения кода.

Первая ошибка разработчиков - повторное использование нескольких одних и тех же методов. Для непрозрачных предикатов легко на глаз определить, проверяется ли настоящая версия API или реалистичная календарная дата. Арифметические выражения и присваивания атрибутам кажущихся случайными значений также выглядят одинаково. Человек может воспользоваться способностью мозга распознавать закономерности, быстро просмотреть код и найти визуально отличающиеся инструкции. В следующем разделе, когда мы восстановим алгоритм расшифрования строк класса, вы увидите, что только эти отличающиеся инструкции и имеют значение.

Вторая ошибка разработчиков - строки в классе были оставлены на своих местах. Хотя их обфусцировали до полной нечитаемости, они по-прежнему находятся точно там, где передаются стандартным API, как показано в листинге 3-7.

Листинг 3-7. Вредоносный класс d.b шифрует строки, но оставляет их на месте

Поскольку для работы API рефлексии требуется необфусцированная строка открытого текста, очевидно, что метод p возвращает именно её. Более того, весьма вероятно, что аргумент p является обфусцированной и зашифрованной строкой, а p расшифровывает её в строку с именем метода, ожидаемую API getMethod.

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

Напомним, что важнейший аспект этого метода - возвращаемое значение, которое должно быть расшифрованной строкой, передаваемой API рефлексии. Если удалить все инструкции, кроме возвращающей значение, останется код из листинга 3-8.

Листинг 3-8. Метод p, сокращённый до возвращаемого значения

Поскольку нам фактически нужно только содержимое sb, теперь следует вернуть все строки, влияющие на его значение. В jadx можно выбрать переменную sb, чтобы выделить все остальные случаи её использования. После добавления этих строк получается код из листинга 3-9.

Листинг 3-9. Метод p с добавленными ссылками на sb

Поскольку при таком расширении кода появилась ещё одна переменная, length, необходимо также добавить все строки кода, которые ею манипулируют. Это сделано в листинге 3-10.

Листинг 3-10. Полный метод расшифрования

На последнем шаге новые переменные не появились, поэтому работа закончена. Из 50 исходных строк p только эти строки участвуют в расшифровании. Остальной код авторы вредоносной программы добавили, чтобы ввести нас в заблуждение. Компиляция и запуск этого кода на Java подтверждают, что он расшифровывает строку qmqMRa3e34OrqtqLdSAnAjne4p4ssoXYOMh в openStream - имя метода, которое ищется посредством рефлексии.

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

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

Теперь, когда мы поняли метод расшифрования и восстановили его на Java, можно легко декодировать все строки класса d.b. Если разработчики вредоносной программы не прилагают особых усилий для сокрытия этой связи, обычно существует сильная корреляция между длиной обфусцированной или зашифрованной строки и её важностью. Строка, начинающаяся с PnPt, выглядит самой длинной и после декодирования действительно превращается в URL.

Декодированный URL совпадает с ранее найденным в классе d.a. Подключившись к нему, мы смогли загрузить файл ban, содержащий код следующего этапа. Остальной код d.b загружает этот файл кода и подгружает его через API рефлексии. Проследить данный процесс мы оставляем читателю в качестве упражнения.

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

Файл ban содержит два пакета: yin.* и com.*. В пакете yin.* всего три небольших класса. Один из них, yin.Chao, загружается первым этапом в d.b, как показано в листинге 3-11.

Листинг 3-11. Вредоносная программа скрывает вызов yin.Chao с помощью зашифрованных строк

Три обфусцированные строки расшифровываются соответственно в dalvik.system.DexClassLoader, loadClass и yin.Chao.

Рассмотрим код yin.Chao.yin - метода, из которого основное приложение выполняет подключаемый модуль. Как показано в листинге 3-12, он запускает новый поток, откуда вызывает несколько других методов.

Листинг 3-12. Метод yin.Chao.yin является точкой входа во второй этап вредоносной программы

Беглый взгляд на остальные методы показывает, что последние два, Chao.Nti и b.a, могут представлять интерес. Код Chao.Nti, приведённый в листинге 3-13, проверяет, предоставил ли пользователь приложению разрешение обрабатывать уведомления всех остальных программ. Если нет, приложение показывает диалоговое окно для выдачи этого разрешения.

Листинг 3-13. Chao.Nti пытается получить доступ ко всем уведомлениям приложений

Напомним, ранее мы видели в файле манифеста объявление службы обработки уведомлений приложений, но не могли найти её код. По-видимому, перед нами именно этот код.

Метод b.a, полное имя которого - com.gppp.hk.a.b.a, ещё интереснее. Как видно в листинге 3-14, он открывает соединение с xn3o.oss-accelerate.aliyuncs.com, загружает оттуда ещё один этап кода и выполняет его с помощью API DexClassLoader.

Листинг 3-14. Метод com.gppp.hk.a.b.a загружает третий этап вредоносной программы

Два других метода, вызываемых yin.Chao.yin, выглядят менее интересными. Hook.hook2 содержит код объединения стандартного загрузчика классов приложения с новым загрузчиком. По-видимому, его скопировали из китайских учебных материалов по подключаемым модулям Android, что напоминает о необходимости всегда искать в интернете любой шаблонный код, встречающийся при анализе. Вызов registerActivityLifecycleCallbacks регистрирует функцию обратного вызова, которая на разных этапах жизненного цикла приложения предлагает пользователю предоставить определённые разрешения.

Прежде чем переходить к третьему этапу, быстро рассмотрим второй пакет ban - com.*. В нём множество подпакетов с разными именами, но сходным кодом. Например, в пакете com.bp.statis.bloodsugar находится один класс PE. Это служба прослушивания уведомлений, объявленная в файле манифеста. Её код крошечный: он лишь передаёт входящее уведомление родительскому классу com.gppp.hk.b.a. Большинство других подпакетов com.* имеют сходную структуру. Можно предположить, что имена подпакетов принадлежат другим образцам вредоносных программ того же семейства.

Код родительского класса com.gppp.hk.b.a столь же мал. Как показано в листинге 3-15, он принимает входящие уведомления, передаёт их другим частям приложения широковещательным сообщением, а затем скрывает исходное уведомление от пользователя.

Листинг 3-15. Класс com.gppp.hk.b.a перехватывает уведомления всех остальных приложений на устройстве

Этот код использует зарегистрированные в контексте сообщения и широковещательные приёмники, не объявленные в файле манифеста. Где-то ещё, вероятно в том же приложении, должен находиться широковещательный приёмник, который прослушивает передачи типа action_text. Часто найти такой приёмник трудно, но в данном образце вредоносной программы это не так. Если поискать action_text в коде третьего этапа, вы его обнаружите.

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

Третий и основной этап этого образца содержит большую часть его вредоносных функций. В нём больше классов и гораздо больше кода, чем на двух предыдущих этапах. Загрузка третьего этапа в jadx показывает код в пакетах com и vgy7.vgy7.vgy7.vgy7.*.

Эти два пакета сильно различаются. В пакете com находится всего один класс - com.xn3o. Пакет vgy7.vgy7.vgy7.vgy7.* содержит 10 классов, распределённых между несколькими подпакетами. Авторы вредоносной программы приложили определённые усилия для обфускации имён переменных и строк, но общее происходящее всё ещё можно понять на глаз. Например, класс vgy7.vgy7.vgy7.vgy7.vgy7 содержит множество плохо обфусцированных строк, указывающих на сетевые, телефонные функции и JavaScript.

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

Декомпиляция кода com.xn3o.xn3o превосходит возможности jadx, что иногда происходит при загрузке крупных и сложных фрагментов кода. В качестве первого обходного решения попробуйте параметр jadx Show Inconsistent Code, который показывает части кода, не поддавшиеся правильному дизассемблированию. Несогласованный код в основном правилен, но не идеален. Если метод важно понять точно, например метод расшифрования, лучше получить второе мнение.

Получить его можно с помощью других декомпиляторов Android. Например, инструмент Bytecode Viewer включает шесть разных декомпиляторов Android. Обычно хотя бы один из них способен создать достаточно разумный декомпилированный код для любого приложения Android.

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

Переименование искажённых имён не только облегчает понимание кода. Оно также помогает отслеживать уже проанализированные части. Увидев неискажённое имя, вам не придётся беспокоиться, встречалось ли оно раньше: удобочитаемое имя распознать легче, даже если это что-либо вроде unknown_string или not_sure. Свободно переименовывайте искажённые сущности, даже если пока не до конца понимаете назначение имени.

При восстановлении имён мы также рекомендуем вносить в них некоторую структуру. Хотя в современной разработке программного обеспечения этот стиль не одобряется, мы обнаружили, что венгерская нотация - соглашение об именовании, при котором сведения о типе переменной включаются в её имя, - чрезвычайно полезна для данной цели. Например, целое число можно назвать iLen, строку - strName и так далее. Эту схему можно применять даже для восстановления имён методов: например, простую функцию получения значения, которая возвращает строку, названную нами name, можно назвать getStrName.

Наконец, восстановление имён способно снизить зрительную нагрузку. Старайтесь заменять длинные имена короткими, а имена с числами или символами Unicode - простыми именами только из символов ASCII. При встрече с каждым методом искажения подумайте, зачем он был применён, а затем воспользуйтесь функцией переименования инструмента, чтобы нейтрализовать эффект. Создатели методов искажения считают умным использовать только случайные символы Unicode, сокращать все имена до одного символа или даже менять направление текста так, чтобы имена читались сверху вниз, а не слева направо. Однако специалистам по обратной разработке все эти приёмы позволяют чрезвычайно легко увидеть разницу между искажёнными и уже восстановленными именами. Гораздо сильнее их сбивает с толку, когда все имена являются случайными английскими существительными либо, как нам доводилось видеть в настоящих вредоносных программах, когда имена взяты из исходного кода, но случайным образом переставлены, так что вредоносная программа использует, например, int socket и Socket i вместо int i и Socket socket.

Вооружившись этими принципами восстановления имён, попробуем привести в порядок образец кода третьего этапа. В листинге 3-21 показан исходный код с сохранёнными искажёнными именами.

Листинг 3-21. Исходный искажённый код, созданный jadx

Очистим его: уберём длинные имена пакетов, чтобы снизить зрительную перегрузку, присвоим осмысленные имена, с помощью венгерской нотации сделаем сведения о типах легко доступными и пометим ничего не делающий код как noOp (no operation). Восстановленная версия в листинге 3-22 намного понятнее.

Листинг 3-22. Код, очищенный с помощью функции переименования jadx

Мы по-прежнему не знаем, что означают настройки в bshwai и tffhhk и для чего используется URL urlUtansy, но преобразованный код теперь можно читать относительно свободно. Обратите также внимание, что двум разным переменным мы дали одно имя context. В программировании это было бы серьёзным нарушением, поскольку компиляторы не допускают двух переменных с одинаковым именем в одной области видимости. Однако в обратной разработке такое вполне допустимо и, возможно, даже желательно. Например, переименование каждого неинтересного имени в знак подчёркивания (_) может значительно снизить когнитивную нагрузку.

В этом разделе мы рассмотрим части xn3o, чтобы объяснить работу мошеннического приложения. Выполнение третьего этапа динамично: сервер управления сообщает вредоносной программе, что и в каком порядке делать. Чтобы следить за разбором, необходимо понять, как программа связывается с сервером.

Вы заметите, что мы покинули область чистого статического анализа. На данном этапе ограничиваться только статическим подходом слишком неудобно. Чтобы понять связь вредоносной программы с серверами управления, обычно проще просто запустить её и перехватить трафик. Однако, чтобы сохранить направленность этой главы на статический анализ, объяснение инструментов динамического анализа мы отложим до следующей главы, а здесь сосредоточимся на сведениях, которые можно получить из кода.

Как вы увидите, приложение совершает мошенничество с прямым выставлением счетов оператором, или мошенничество с платными услугами, подписывая пользователей без их ведома или против их воли. Некоторые программы для такого мошенничества действуют исключительно посредством социальной инженерии: показывают пользователям похожие на фишинговые страницы оформления подписки и надеются, что те сами завершат регистрацию. Однако представленная здесь программа применяет второй распространённый метод: имитирует действия пользователя с помощью Android API и JavaScript API и незаметно оформляет подписку на платные услуги. Несмотря на всю автоматизацию, вредоносная программа выполняет лишь несколько ключевых шагов:

• загружает сайт перехода, который перенаправляет на платную услугу;

• с помощью кода автоматически взаимодействует со страницей платной услуги и подписывает пользователя без его согласия;

• перехватывает и извлекает одноразовый пароль, отправленный по SMS;

• вставляет одноразовый пароль на страницу платной услуги, чтобы завершить регистрацию.

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

Вся связь с сервером управления зашифрована с помощью простого алгоритма, находящегося в классе vgy7.vgy7.vgy7.vgy7.bhu8. Вспомните, что мы обнаружили этот метод vgy7 в листинге 3-20. Как показано в листинге 3-23, он принимает два аргумента. Второй аргумент определяет, будет ли строка, переданная первым аргументом, зашифрована (z = true) или расшифрована (z = false).

Листинг 3-23. Метод vgy7 способен шифровать и расшифровывать обмен данными с сервером управления.

Алгоритм шифрования явно самодельный и очень слабый. Чтобы зашифровать строку, он сначала выбирает случайную строчную и случайную прописную буквы. Затем вычитает ASCII-код второй буквы из кода первой и прибавляет пять. Зашифрованная выходная строка начинается с двух случайных букв, после которых следуют буквы шифруемой входной строки. В тех позициях строки, где остаток от деления номера позиции на результат вычитания с прибавленными пятью равен нулю, алгоритм вставляет случайный символ, не несущий никакого смысла. Например, третий символ зашифрованной строки (иными словами, нулевой символ преобразованной входной строки) всегда случаен, поскольку остаток от деления нуля на любое значение всегда равен нулю.

Теперь, когда мы знаем, как работают шифрование и расшифрование, можно написать небольшой сценарий для взаимодействия с сервером управления вредоносной программы и исследования его команд и ответов. Поскольку процедура шифрования и расшифрования целиком содержится всего в одном методе, мы вставили код из jadx в два файла, Encrypt.java и Decrypt.java, которые можно запускать из командной строки. Здесь для взаимодействия с сервером вредоносной программы используется командная строка Linux:

Эта команда кодирует JSON-аргумент со значениями, собранными приложением (они объясняются далее в этом разделе), передаёт командой echo его нашему сценарию Encrypt, удаляя перевод строки с помощью флага -n, направляет зашифрованную полезную нагрузку в cURL, работающую в тихом режиме (-s) и режиме POST (-d), а затем расшифровывает команду, полученную от сервера. Вывод будет выглядеть примерно так: "bshwai": 5320786, "xjnguw": "".

Теперь, когда мы можем отправлять на сервер зашифрованные полезные нагрузки и расшифровывать его ответы, можно начать разбираться, как вредоносная программа взаимодействует с ним. Здесь мы покажем сведения, которыми обмениваются вредоносная программа и её сервер управления, имитируя работу программы на реальном устройстве, подключённом к мобильной сети бельгийского оператора Orange. Поскольку для идентификации мобильного оператора телефона вредоносная программа использует в обмене с сервером управления значение поля worikt, замена этого значения идентификаторами других операторов позволяет легко экспериментировать с различными мобильными операторами в разных странах.

Первое соединение с сервером управления вредоносная программа устанавливает для регистрации на нём. Она отправляет регистрационные сведения на https://www.utansy.com/xn3o/in в виде зашифрованного JSON. Сервер отвечает зашифрованным JSON-объектом, который программа расшифровывает и обрабатывает.

Во всех случаях обмена зашифрованными JSON-сообщениями разработчики вредоносной программы заменили содержательные имена полей JSON бессмысленными, чтобы затруднить анализ. Как это выглядит, можно увидеть в листинге 3-24, где показан расшифрованный JSON-объект, отправленный серверу управления на этапе регистрации.

Листинг 3-24. Расшифрованная полезная нагрузка регистрационного сообщения

Чтобы понять эти бессмысленные имена, полезно подойти к задаче с двух сторон. Встречая в коде бессмысленные поля JSON, документируйте присваиваемые им значения. Затем делайте то же самое, когда встречаете бессмысленные поля JSON в расшифрованном обмене данными. О значении некоторых полей, таких как josiwo, можно догадаться по присвоенным им значениям. Назначение других, таких как kdthit, приходится выяснять посредством изучения кода.

К счастью, вредоносная программа не пытается скрывать бессмысленные строки в коде или повторно использовать одни и те же бессмысленные имена в разных контекстах. Например, поиск josiwo в jadx возвращает только одно место, показанное в листинге 3-25. Этот код содержит в точности те же имена полей, что и расшифрованный JSON-объект в листинге 3-24. Можно с уверенностью предположить, что данный код отвечает за присваивание значений этим бессмысленным полям.

Листинг 3-25. Формирование полезной нагрузки JSON регистрационного сообщения

Благодаря этому дополнительному контексту мы видим, что josiwo - это явно собственное имя пакета вредоносного приложения, а qredyb - уровень сборки SDK устройства. Строка kdthit всегда содержит число 6, но его значение неясно. Возможно, это код версии, который помогает клиенту и серверу согласовать протокол связи.

Значение worikt и zubfih неочевидно, однако, проследив код до места присваивания этих двух переменных, можно понять их смысл: worikt - код оператора SIM-карты устройства, возвращаемый TelephonyManager.getSimOperator (код 20610 соответствует оператору Orange Belgium). Значение zubfih сложнее. В зависимости от уровня API устройства оно принимает либо временную метку Unix времени установки приложения, либо Android ID устройства.

После успешного регистрационного запроса сервер управления отвечает строкой, расшифровывающейся в JSON-объект, показанный в листинге 3-26.

Листинг 3-26. Ответ сервера управления на регистрацию нового клиента

Точное значение возвращаемого поля bshwai неясно, но это может быть идентификатор, присвоенный клиенту. Исследование сервера управления с помощью cURL возвращает для bshwai одно и то же значение, пока в поле запроса zubfih не будет отправлено новое значение временной метки. Вероятно, сервер использует временную метку установки, чтобы различать заражённые клиенты, и на её основе присваивает новые идентификаторы клиентов. Поскольку идентификаторы клиентов, по-видимому, увеличиваются линейно, это значение также можно использовать для оценки числа заражённых устройств и скорости заражения новых устройств.

Второе возвращаемое значение, xjnguw, также весьма интересно. В наших тестах оно почти всегда было пустым. По-видимому, оно зависит от имени пакета приложения, потому что сервер возвращал непустое значение, когда мы меняли параметр имени пакета в josiwo, например, на com.takela.message - имя пакета другого образца вредоносной программы из того же семейства. Возвращаемые непустые значения выглядят как 1_1487372418053478, где 1 (или иногда 2) перед знаком подчёркивания - идентификатор версии загружаемого четвёртого этапа, а часть после знака подчёркивания - идентификатор приложения Facebook, используемый для инициализации Facebook SDK, включённого в этот четвёртый этап. Четвёртый этап загружается с https://xn3o.oss-accelerate.aliyuncs.com/fbhx1 или https://xn3o.oss-accelerate.aliyuncs.com/fbhx2 в зависимости от кода версии. В конце этой главы мы рассмотрим эти подключаемые модули.

После регистрации на сервере управления вредоносная программа подключается к https://www.utansy.com/xn3o/ti, чтобы получить команды для выполнения. Эти команды используются для подключения к партнёрскому сайту, который перенаправляет на страницу оформления платной подписки. После загрузки страницы скачанные команды начинают взаимодействовать с ней и подписывают пользователя без его согласия. Плата будет включена в следующий счёт пользователя за телефон, а партнёр, приведший его к оформлению подписки, получит вознаграждение.

Полезная нагрузка запроса, отправляемая по URL команд, содержит сведения о состоянии устройства, собранные вредоносной программой. В листинге 3-27 показан пример запроса.

Листинг 3-27. Полезная нагрузка, отправляемая серверу управления для запроса команд

Поле eymbmw указывает, подключено ли устройство к мобильной сети (для оформления подписки на многих сайтах прямого выставления счетов оператором устройствам требуется мобильное подключение). Поле rktfht указывает, имеет ли приложение разрешение получать входящие SMS-сообщения или доступ к уведомлениям приложений, необходимый для извлечения одноразового пароля в процессе оформления платной подписки. Поле segdip указывает, имеет ли приложение разрешение отправлять SMS-сообщения, которое необходимо для подтверждения платной подписки на некоторых страницах. Поле elbcnf содержит номер телефона устройства, а dgebpf - список всех учётных записей, зарегистрированных на устройстве. В зависимости от устройства зарегистрированными учётными записями могут быть адрес электронной почты человека, номер WhatsApp, имя учётной записи X или идентификатор профиля LinkedIn. Непонятно, зачем вредоносная программа собирает эти сведения. Кроме того, сюда включены значения zubfih и bshwai, встречавшиеся в регистрационном запросе.

Интерпретировать ответ, полученный с URL команд, сложно, но в листинге 3-28 показаны два наиболее очевидных поля.

Листинг 3-28. Ответ содержит код JavaScript для перемещения по страницам оформления подписки.

Поле gooycf содержит партнёрский URL, который будет загружен на следующем этапе мошенничества. Поле jxdkqb содержит список инструкций JavaScript. Они используют объект-мост JavaScript, внедрённый на сайт оформления платной подписки, и позволяют вредоносному коду JavaScript взаимодействовать с вредоносным кодом Java в xn3o.

После загрузки партнёрского URL и команд JavaScript вредоносная программа открывает партнёрский URL в специализированном WebView. Все изменения WebView связаны с перехватом загружаемых сайтов и манипулированием ими: отчасти для обхода защиты от ботов на странице оформления подписки, а отчасти для взаимодействия с этой страницей с целью имитации законного пользователя.

Если открыть показанный в ответе с командами партнёрский URL в мобильном веб-браузере, произойдёт перенаправление на сайт, показанный на рисунке 3-3.

Рисунок 3-3. Страница оформления подписки на бельгийскую платную услугу

Это первый этап оформления подписки на платную услугу, на котором пользователь вводит номер телефона. Внизу мелким шрифтом указана стоимость услуги - шесть евро в неделю - и приведены инструкции по отмене подписки.

После загрузки страницы оформления подписки вредоносная программа начинает взаимодействовать с ней через интерфейс JavaScript - стандартный Android API, с помощью которого приложение может создать мост между собой и сайтом в объекте WebView. Простой поиск Android API addJavascriptInterface в jadx показывает место в xn3o, где это происходит (листинг 3-29).

Листинг 3-29. Настройка интерфейса JavaScript для манипулирования страницей оформления подписки

Первый аргумент, передаваемый addJavascriptInterface, - объект Java, который становится доступен сайтам, загруженным в WebView. Второй аргумент - имя, которое следует присвоить объекту в JavaScript. Код JavaScript может обращаться к объекту по этому имени и вызывать определённые в нём методы. В случае вредоносной программы это имя - просто JBridge.

Класс Java zse4, определяющий объект-мост JavaScript, имеет только один метод с декоратором @JavascriptInterface - метод call. Из JavaScript доступны лишь методы, отмеченные этим декоратором, поэтому это единственный метод, который может вызывать JavaScript-часть вредоносной программы. Внутри метода call находится длинная цепочка операторов if...else, которая во вредоносной программе часто указывает на участок кода, интерпретирующий команды. Обнаружение интерпретатора команд вредоносной программы - настоящий джекпот для специалистов по обратной разработке, поскольку позволяет увидеть, какой код отвечает за каждую команду. Благодаря этому они могут быстро разобраться в значительной части вредоносных функций.

Уже по аргументам call видно, что первый аргумент - имя команды, а второй - параметры команды. Длинная цепочка if...else проверяет имя команды и вызывает различный код в зависимости от команды, которую требуется выполнить. Фрагмент этой функциональности показан в листинге 3-30.

Листинг 3-30. Обработка команд JavaScript в классе zse4

В этом коде аргумент str поочерёдно сравнивается со строковыми значениями finish, schedule, textTo и popMsg. Проследив методы, вызываемые внутри ветвей if, можно найти код, реализующий эти команды.

Теперь, когда вы понимаете реализацию объекта-моста JavaScript на Java, внимательнее рассмотрите загруженные команды JavaScript, показанные в листинге 3-31.

Листинг 3-31. Код JavaScript используется для оформления подписки на платную услугу.

Сначала код пытается найти поле ввода номера телефона на сайте подписки с помощью метода querySelector. Обнаружив его, код вводит в поле номер телефона устройства, средствами JavaScript нажимает кнопку подписки и вызывает метод nextThings.

В листинге 3-32 показан фрагмент кода из nextThings, где многие строки вызывают метод call объекта-моста. Поскольку объект-мост определён классом Java zse4, мы без труда можем проследить, что делают эти строки. Анализ zse4 подтверждает соответствие имён команд их назначению: код JavaScript пытается перехватить входящее SMS-сообщение (popMsg) и отправить подтверждающее SMS-сообщение на номер 9956, чтобы завершить процесс регистрации (textTo).

Листинг 3-32. Полезная нагрузка соединяет код Java и JavaScript через интерфейс JavaScript JBridge.

Остаётся одна загадка: как команды JavaScript фактически выполняются в контексте сайта подписки? Для этого существует стандартный Android API: WebView.evaluateJavascript, позволяющий приложению внедрять в сайт любой код JavaScript.

В другом месте кода читается список vgy7Var.yhn6 и обрабатываются перехваченные SMS-сообщения и уведомления. Быстрая проверка ссылок в jadx показывает, что единственное место в коде, где читается этот список, находится в методе bhu8.

Этот метод, показанный в листинге 3-33, принимает строковый аргумент вида number::string, который разбивает по двойному двоеточию (::). Первая часть этого аргумента используется как регулярное выражение для разбора SMS. Вторая часть содержит номер группы захвата регулярного выражения, в которой ожидается одноразовый пароль. Метод также принимает целочисленный аргумент, используемый для приостановки текущего потока, если ожидаемое SMS найти не удалось. Вероятно, это делается, чтобы дождаться поступления SMS, а затем снова проверить его наличие.

Листинг 3-33. Извлечение одноразового пароля

Метод bhu8 вызывается из двух мест в xn3o: один раз с жёстко заданным строковым аргументом, сформированным для разбора SMS-сообщений с определённых тайских сайтов подписки, и один раз из обработчика команды popMsg. Для бельгийского сайта подписки вредоносная программа использует второй вариант. Теперь мы знаем, что код JavaScript, показанный в листинге 3-34 и ранее загруженный с сервера управления, представляет собой простой экстрактор числа длиной от трёх до шести цифр.

Листинг 3-34. Извлечение одноразового пароля для бельгийской страницы оформления подписки

Примечательно, что происходит после вызова метода popMsg. Листинг 3-32 показал: какое бы число ни было извлечено из SMS, приложение продолжает оформление подписки, отправляя сообщение ok на номер телефона 9956. Хотя у нас нет доступа к настоящему бельгийскому телефону, чтобы наблюдать полный процесс оформления подписки, можно предположить, что эта платная услуга вообще не использует одноразовые пароли. Возможно, пользователи могут подтвердить подписку, просто отправив сообщение ok на платный номер услуги.

В анализе программ и обратной разработке термин динамический анализ, или динамический анализ кода, означает применение методов анализа, которые выявляют свойства исследуемой программы посредством выполнения её кода. Он противопоставляется описанному в предыдущей главе статическому анализу, цель которого - обнаружить свойства программы путём изучения её кода и структуры без выполнения.

Конечно, одного запуска приложения недостаточно, чтобы понять, что оно делает. Динамический анализ задействует целый арсенал инструментов, которые наблюдают за приложением и взаимодействуют с ним, включая отладчики и программы для перехвата вызовов API, создания дампов памяти или исследования сетевого трафика. Другие инструменты могут реализовывать способы взаимодействия с графическим интерфейсом приложения либо автоматически проверять свойства его безопасности на наличие потенциальных уязвимостей. При совместном запуске эти инструменты должны сформировать картину взаимодействия приложения с устройством. Чем больше инструментов вы развёртываете для наблюдения за устройством, тем полнее становится ваше понимание приложения. Однако развёртывание и сопровождение всех этих инструментов может потребовать значительных затрат времени и денег.

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

Ярким примером различий между статическим и динамическим анализом служит объём усилий, необходимых для их подготовки. Для статического анализа достаточно загрузить приложение в jadx. Динамический же анализ требует сначала настроить устройство (настоящее или виртуальное), способное выполнять программу, а затем убедиться в возможности перехватывать и регистрировать системные вызовы, сетевой трафик, изменения файловой системы и любые другие изменения устройства, которые может вносить приложение. Наконец, необходимо выполнить приложение и взаимодействовать с ним в надежде активировать вредоносные функции. Это может оказаться сложнее, чем вы ожидаете, поскольку вредоносные приложения часто применяют множество приёмов противодействия анализу и отказываются работать, когда считают, что находятся под наблюдением в тестовой среде исследователя безопасности.

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

Ещё один аспект, в котором динамический и статический анализ дополняют друг друга, - покрытие кода, то есть мера того, какой объём кода способен исследовать метод анализа. При статическом анализе доступен весь код приложения. При динамическом анализе можно рассматривать лишь выполненный код. Разница между ними может быть огромной. Даже при лучших сеансах динамического анализа приложения удаётся выполнить лишь от 5 до 10 процентов его кода. Остальные 90-95 процентов остаются загадкой и могут быть раскрыты только посредством статического анализа.

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

Эмулятор дёшев и позволяет быстро вернуть среду анализа в исходное состояние, если что-либо пойдёт не так. Кроме того, начать работу с ним несложно. С другой стороны, большинство вредоносных программ Android пытаются определить, не работают ли они в эмуляторе, и ведут себя иначе, если считают, что подвергаются анализу, из-за чего можно потратить впустую очень много времени. Настоящее устройство позволяет легко пройти такие проверки.

Для динамического анализа в этой главе мы воспользуемся стандартным эмулятором Android, который поставляется с интегрированной средой разработки Android Studio и Android SDK. Мы рекомендуем установить Android Studio целиком: программа сама настроит необходимые пакеты SDK и предоставит удобный пользовательский интерфейс. Можно установить только Android SDK, но это потребует гораздо больше ручной настройки. Android Studio можно загрузить по адресу developer.android.com. Для установки следуйте инструкциям на странице developer.android.com.

Прежде чем запускать эмулятор, необходимо создать образ системы, который он сможет загрузить. Удобнее всего сделать это с помощью Android Studio. Откройте экран настройки диспетчера устройств, выбрав Tools > Device Manager. Диспетчер устройств проведёт вас через процесс создания образов системы для эмулятора Android.

Здесь мы используем образ системы, настроенный для устройства Pixel XL с API 30 и скомпилированный для 32-разрядной архитектуры x86. Мы выбрали эту архитектуру, чтобы ускорить эмулятор, поскольку такие образы могут задействовать средства виртуализации центрального процессора настоящего компьютера. Выбор образа для процессора ARM приведёт к более медленной работе, так как хост-компьютеру x86 придётся эмулировать архитектуру ARM. Разумеется, если ваш хост-компьютер основан на ARM, по той же причине следует выбрать образ системы Android для ARM.

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

Эта команда принимает всего два аргумента. С помощью @ мы передаём имя образа системы Pixel XL с API 30, созданного в Android Studio в предыдущем шаге. Второй аргумент, -no-boot-anim, отключает системную анимацию загрузки, чтобы ускорить запуск системы.

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

Самый простой способ вернуться к чистому состоянию - стереть все данные эмулятора Android и восстановить его исходное состояние. Для этого эмулятор предоставляет удобный аргумент командной строки -wipe-data:

Настоятельно рекомендуем активно использовать этот аргумент между запусками вредоносной программы.

Для взаимодействия с эмулируемым устройством мы будем использовать инструмент командной строки Android Debug Bridge, adb, который поставляется с Android SDK и способен связываться с устройствами по USB или TCP/IP. Этот инструмент поддерживает около десятка команд, подробнее узнать о которых можно, выполнив adb --help. На протяжении главы мы будем с помощью команд adb устанавливать приложения на устройство, загружать на него файлы и скачивать файлы с него.

Помимо эмулятора Android, при анализе мы воспользуемся несколькими сторонними приложениями: tcpdump - для перехвата и регистрации сетевого трафика эмулятора, Wireshark - для анализа этого трафика и Frida - для манипулирования исследуемой вредоносной программой.

Инструмент командной строки tcpdump регистрирует и анализирует сетевой трафик. Мы будем с его помощью захватывать весь сетевой трафик между вредоносной программой и её сервером управления, чтобы исследовать собираемые программой данные и получаемые ею команды.

Поскольку tcpdump имеет открытый исходный код, его можно загрузить с tcpdump.org. Официальный сайт распространяет только исходный код, поэтому вам придётся скомпилировать его для архитектуры процессора Android вашего тестового устройства. Инструкции по компиляции tcpdump находятся в официальном репозитории GitHub по адресу github.com. На сторонних сайтах также размещаются предварительно скомпилированные исполняемые файлы tcpdump для различных архитектур процессоров Android, однако мы не знаем, насколько можно доверять этим сайтам, поэтому будьте осторожны.

Затем установите tcpdump на Android с помощью adb, отправив исполняемый файл на устройство и пометив его как исполняемый:

Команда adb push передаёт файл с хост-компьютера на устройство Android, а adb shell выполняет на устройстве команды оболочки. Обратите внимание, что Android использует MirBSD Korn Shell (mksh), поведение которой может отличаться от поведения более популярной оболочки Bash, к которой вы, вероятно, привыкли.

Wireshark - анализатор сетевого трафика с открытым исходным кодом. Мы будем использовать его в качестве графического интерфейса для данных, захваченных tcpdump. Загрузить программу можно с официального сайта wireshark.org. Поскольку Wireshark устанавливается на хост-систему, а не в эмулятор Android, выберите установщик для своей хост-системы. Например, если вы работаете в Windows, установите Wireshark для Windows.

Frida - инструментарий динамического инструментирования, с помощью которого можно анализировать работающие приложения, регистрировать выполняемые ими действия и манипулировать ими во время выполнения. Он имеет открытый исходный код и поддерживает множество операционных систем и форматов исполняемых файлов. Официальный способ установки Frida использует pip - установщик пакетов для языка программирования Python, поэтому в качестве предварительного условия необходимо сначала установить последние версии Python 3 и pip с python.org и pypi.org. Затем установите Frida, выполнив pip install frida-tools.

Подобно adb, Frida использует клиент-серверную архитектуру: исполняемый файл сервера (frida-server) работает на устройстве Android, а клиент (frida) - на хост-компьютере и взаимодействует с устройством Android. Загрузите frida-server со страницы Frida на GitHub (github.com), где предлагаются предварительно скомпилированные исполняемые файлы для множества операционных систем и архитектур процессоров, затем установите его на устройство Android с помощью adb и сделайте файл исполняемым:

Теперь выполним приложение, пока инструменты динамического анализа работают в фоновом режиме и наблюдают за его действиями. Этот рабочий процесс составляет сущность динамического анализа, а подход данного раздела повторяет шаги, использованные для поиска точек входа в главе 3. Разница в том, что теперь вместо поиска структурных свойств приложения (таких как разрешения, API или точки входа) мы наблюдаем различные воздействия вредоносной программы на окружение и используем их как подсказки для дальнейшего анализа её функций. В частности, мы рассмотрим взаимодействие вредоносной программы с файловой системой эмулятора, её сетевые соединения и системный журнал.

Чтобы запустить приложение, можно открыть его из списка приложений в эмуляторе, как обычный пользователь, либо воспользоваться командной строкой с несколько необычной командой adb для запуска приложений:

Изначально разработанная для тестирования приложений программа-помощник monkey в Android имитирует взаимодействие настоящего пользователя с целевым приложением. Здесь мы используем лишь её способность запускать указанное по имени приложение. Завершающая цифра 1 обозначает количество событий пользовательского интерфейса, которые monkey должна имитировать в целевом процессе. В нашем случае требуется только один раз запустить приложение.

Теперь, когда приложение работает, оно должно показывать экран, изображённый на рисунке 4-1.

Рисунок 4-1. Первый экран вредоносного образца

Как видите, приложение пытается убедить пользователя предоставить ему доступ к мощному API специальных возможностей. Нажатие большой круглой кнопки внизу открывает системный диалог, в котором пользователь может предоставить приложению это разрешение. Пока мы не будем давать доступ к специальным возможностям или углубляться в приложение. Вместо этого перейдём к следующему шагу анализа.

Теперь, когда приложение работает, можно ещё раз взглянуть на его стандартный каталог файлов. Чтобы сделать вывод полезнее, уточним команду adb, добавив вывод типов всех файлов в этом каталоге. Кавычки необходимы из-за завершающей точки с запятой:

Вывод показывает создание множества новых файлов. Многие из них являются стандартными файлами Android, однако два выделяются. Первый - shared_prefs/ring0.xml, имя которого выглядит шуткой: на некоторых компьютерах нулевое кольцо представляет собой наивысший уровень привилегий выполнения. Второй - app_DynamicOptDex/hq.json с расширением, указывающим, что это текстовый файл. Однако команда file определила его как ZIP-файл. Следует исследовать это несоответствие между заявленным расширением файла и его содержимым.

Для дальнейшего исследования файлов, сохранённых приложением, можно скачать их все с устройства на хост-компьютер с помощью adb pull. Эта команда способна загружать как отдельные файлы, так и целые каталоги:

Теперь быстро исследуем два подозрительных файла:

Файл ring0.xml, по-видимому, содержит параметры конфигурации неизвестного назначения, но среди них есть интересное доменное имя. Файл hq.json, судя по строке classes.dex, по-видимому, содержит DEX-код. Предположительно, вредоносная программа записывает этот файл на диск и загружает его.

На этом этапе у нас появились зацепки, которые можно развивать дальше. Что представляет собой подозрительный домен в XML-файле? Что означают остальные параметры конфигурации? Откуда берётся DEX-файл и что он делает? Пока мы не будем развивать эти направления. Вместо этого воспользуемся другими инструментами динамического анализа, чтобы узнать о вредоносной программе больше.

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

Перед захватом сетевого трафика важно вернуть эмулируемое устройство в чистое состояние. В противном случае приложение может не повторить некоторые сетевые запросы, уже выполненные при предыдущих запусках. Что, если, например, файл DEX-кода hq.json был загружен из интернета? Приложение может не скачать его снова, поскольку он уже находится на диске. Тогда при попытке понять происхождение этого DEX-файла вы окажетесь в тупике.

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

Для захвата сетевых данных мы используем команду adb exec-out, чтобы запустить исполняемый файл tcpdump в эмуляторе. Затем с помощью adb exec-out передаём двоичные данные из эмулятора в хост-систему, направляя их по конвейеру в Wireshark для удобного использования. Стоит отметить, что захватывать сетевой трафик можно только при условии, что adbd работает на устройстве с правами root. Если после сброса эмулятора вы ещё не перевели adbd в режим root, сейчас самое время это сделать:

Параметр командной строки tcpdump -i any используется для захвата трафика со всех сетевых интерфейсов. Сочетание -U и -w гарантирует, что захваченные пакеты немедленно записываются в выходной файл. Аргументы командной строки Wireshark -k -S немедленно запускают захват и отображение пакетов. Аргумент -i - сообщает Wireshark, что сетевые пакеты следует ожидать из стандартного ввода, куда они поступают по конвейеру из adb.

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

После запуска tcpdump и Wireshark можно приступить к изучению захваченного трафика. На рисунке 4-2 показан пример сеанса Wireshark с пакетами, захваченными во время работы com.spike.old. В верхней трети окна Wireshark находится сводка всех захваченных сетевых пакетов. В средней трети показаны разобранные сведения о выбранном сетевом пакете HTTP. В нижней трети находится шестнадцатеричный дамп полезной нагрузки выбранного пакета.

Рисунок 4-2. Wireshark показывает сетевой трафик, захваченный у вредоносного приложения

Часть сведений с рисунка 4-2 воспроизведена в листинге 4-1 для удобства чтения. В частности, мы решили показать структурированные сведения о пакете HTTP.

Листинг 4-1. Подробные сведения о сетевом соединении, захваченном в Wireshark

Из этого мы узнаём, что перехваченный пакет представляет собой HTTP-запрос POST к http://simpleyo5.tk/ping - URL в том же домене, который мы ранее видели в подозрительном файле конфигурации ring0.xml. Сокращённый шестнадцатеричный дамп внизу листинга показывает, что полезная нагрузка POST (данные, отправленные домену), по-видимому, является текстом в формате JSON с ключами hash и id и значениями, которые выглядят закодированными в Base64.

Захват сетевого трафика оказался успешной стратегией. Мы подтвердили, что вредоносная программа использует домен simpleyo5.tk и что данные в формате JSON, закодированные в Base64, отправляются в конечную точку /ping этого домена. Кроме того, нам известны некоторые ключи JSON в открытом виде. Добавим эти выводы к собранным направлениям дальнейшего исследования.

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

К счастью для нас, com.spike.old относится именно к таким приложениям. Оно активно использует журналирование, причём записываемые им сведения настолько подробны, что мы намеренно поместили этот раздел после обсуждения захвата сетевого трафика и анализа файловой системы, чтобы не раскрывать слишком много информации заранее.

Стандартный способ получить доступ к системному журналу Android - использовать инструмент logcat, например посредством команды adb logcat. По умолчанию logcat выводит весь файл системного журнала, обычно содержащий многие тысячи строк. Чтобы отфильтровать несущественные подробности, можно указать идентификатор процесса исследуемого приложения, как показано здесь:

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

Листинг 4-2. Вывод logcat для com.spike.old

Строка pioneer_bridge_over_white_rabbits заслуживает внимания. Это отладочная строка, которую приложение использует как префикс своих записей журнала. Зачем она включена в приложение, неясно. В других частях данных журнала (не приведённых здесь) можно найти сведения о сетевых полезных нагрузках, сопоставление зашифрованных и расшифрованных JSON-объектов, довольно подробные сведения о выполняемых классах и многое другое.

Одно из преимуществ logcat заключается в том, что операционная система буферизует и некоторое время сохраняет журнал. Это означает, что наблюдать за logcat во время работы приложения необязательно: сведения из системного журнала можно получить намного позже, уже после прекращения выполнения исследуемого приложения. Поскольку размер logcat ограничен, доступность данных приложения зависит от того, сколько записей журнала будет создано на устройстве Android до удаления более ранних записей. На практике они обычно остаются доступными несколько часов.

До сих пор мы использовали инструменты adb, logcat, tcpdump и Wireshark, чтобы быстро обнаружить свойства исследуемого приложения. Однако эти инструменты не позволяют связать наблюдаемые свойства приложения с конкретными участками его кода. Теперь мы знаем, что com.spike.old сохраняет файлы на диск, соединяется с сервером управления и шифрует обмен данными, но нам неизвестны подробности того, где, зачем и как оно всё это делает. Эти связи можно установить с помощью Frida.

Frida - мощный инструмент, и объяснению всех его функций можно было бы посвятить ещё одну книгу. Здесь мы рассмотрим только те из них, которые помогают нам понять вредоносный образец. В частности, мы воспользуемся frida-trace, чтобы быстро выяснить, какие интересные API Java использует вредоносная программа. Кроме того, с помощью сценариев Frida мы найдём эти интересные API в коде программы. Любознательным читателям рекомендуем подробнее изучить многочисленные способы применения Frida, поскольку эта глава охватывает лишь около 1 процента возможностей инструмента.

Вы уже должны были установить frida-server на устройство и сделать его исполняемым. Теперь его необходимо запустить, чтобы он мог связываться с клиентом frida на хост-системе и взаимодействовать с вредоносной программой. Снова воспользуемся adb shell для запуска frida-server:

Важно учитывать, что frida-server должен работать с правами root.

Инструмент frida-trace способен динамически отслеживать вызовы методов в исследуемом приложении и выводить некоторые основные свойства используемых им API. Инструмент принимает список методов для перехвата и отправляет их входные и выходные данные в стандартный вывод. Он поддерживает регулярные выражения, благодаря чему наблюдать за всеми методами класса или даже пакета очень просто. Например, следующая команда выводит сведения о том, как вредоносная программа использует все методы классов Cipher и SecretKeySpec из стандартного пакета криптографии Java:

Эта команда выводит сотни строк сведений об использовании данного криптографического API. В листинге 4-3 показана малая часть. Мы видим, как вредоносная программа задаёт ключ шифрования AES и вектор инициализации (IV), а затем использует определённый этими свойствами шифр для расшифрования массива байтов.

Листинг 4-3. Вывод frida-trace, относящийся к криптографическим API

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

В главе 3 мы рекомендовали специалистам по обратной разработке составлять список интересных методов API для поиска при анализе кода программы. Этот же список можно использовать с frida-trace, чтобы перехватывать и регистрировать способы применения API вредоносной программой. Помимо криптографических API, можно попробовать перехватывать API, связанные с сетевым обменом, доступом к файловой системе или конфиденциальным данным.

Недостаток frida-trace заключается в том, что он не может связать наблюдаемые API с кодом вредоносной программы. Теперь нам может быть известно, что программа использует шифрование и даже как она настраивает свои шифры, но мы не знаем, где это происходит. Чтобы установить такую связь, можно использовать сценарии Frida.

Создание сценариев - вероятно, самая полезная возможность Frida. Она позволяет пользователям Frida писать собственный код на различных языках программирования для взаимодействия с исследуемой программой. В этом разделе мы воспользуемся данной возможностью, чтобы связать вызовы API с лежащим в их основе кодом вредоносной программы посредством наблюдения за трассировками стека интересующих функций.

С помощью frida-trace мы узнали, что вредоносная программа вызывает стандартный криптографический API Java Cipher.doFinal для шифрования и расшифрования данных. Теперь можно специально нацелить на этот API собственный сценарий Frida, который обнаружит места вредоносной программы, вызывающие API. В листинге 4-4 показан очень простой сценарий Frida на JavaScript, перехватывающий API Cipher.doFinal. Сохраните его в файл xeno-dofinal.js.

Листинг 4-4. Сценарий Frida, перехватывающий API doFinal

Мы используем Java.perform из JavaScript API Frida, чтобы убедиться, что текущий поток присоединён к виртуальной машине, а затем выполнить функцию, переданную в аргументе. В нашем примере предоставленная функция содержит код, отвечающий за перехват Cipher.doFinal. Для перехвата метода Java сначала необходимо получить оболочку JavaScript для его класса. Для этого применяется JavaScript API Frida Java.use, который принимает в качестве аргумента полное имя класса Java.

Перед перехватом и заменой метода необходимо определить, существует ли в перехватываемом классе несколько методов с одинаковым именем. Если да, их следует различить с помощью функции overload, явно передав ей типы Java параметров метода. Здесь мы делаем это для метода doFinal, передавая аргумент "[B", который в синтаксисе типов Java обозначает массив байтов.

Найдя нужный перегруженный метод, мы заменяем свойство implementation объекта простым присваиванием собственной функции. Теперь всякий раз, когда приложение вызывает перехваченный API, вместо исходного кода API выполняется наш код. Кроме того, для определения текущего места мы применяем старый приём Java: создаём новое исключение и выводим его трассировку стека. Наконец, возвращаем ожидаемое значение doFinal, вызывая его исходную реализацию.

Выполните сценарий Frida из командной строки хост-компьютера:

Аргумент -U указывает Frida искать устройство, подключённое по USB, аргумент -f запускает процесс вредоносного приложения, а аргумент -l задаёт файл сценария для выполнения. После запуска этой команды должна открыться оболочка Frida, которая создаст процесс вредоносной программы в приостановленном состоянии. Чтобы продолжить его выполнение, введите в оболочке %resume:

В листинге 4-5 показан вывод сценария. Этот журнал следует читать сверху вниз. Каждая напечатанная трассировка стека начинается с java.lang.Exception, за которым следует наблюдаемый вызов doFinal. После него вы увидите фрагмент кода, вызывающий doFinal.

Листинг 4-5. Вывод сценария Frida показывает места вызова doFinal.

Первая трассировка стека показывает функцию encryptMessage, а вторая - decryptMessage. Впервые мы можем сформировать представление о потоке управления приложения. Вывод сценария точно показывает, как метод doFinal вызывается из нестандартного пакета com.sniff, который, должно быть, является частью вредоносной программы, выполняющей шифрование.

Чтобы получить дополнительные сведения о вредоносной программе, этот процесс можно повторить для других интересных функций. Например, нам может потребоваться найти, где ring0.xml и hq.json записываются на диск и где настраивается сетевое соединение с сервером управления. Эти задачи мы оставляем читателю в качестве упражнения.

Как и в предыдущей главе, одно из важнейших свойств вредоносной программы, которое нам потребуется восстановить, - её зашифрованный обмен данными с сервером управления. Взлом шифрования позволит лучше понять поддерживаемые ею команды. Вместо статического анализа и чтения кода для выяснения принципов этого обмена мы воспользуемся динамическим анализом. tcpdump, logcat и Frida вместе предоставляют все необходимые инструменты.

После проведённого ранее анализа с помощью tcpdump и Wireshark мы знаем, что первым соединением вредоносной программы является HTTP-запрос POST к http://simpleyo5.tk/ping. В этом запросе программа отправляет JSON-объект с четырьмя элементами, как показано в листинге 4-6.

Листинг 4-6. Полезная нагрузка JSON, отправленная по URL /ping

Пока неясно, что представляют собой эти значения. Единственная запись в открытом виде, "type": "request_verify", позволяет предположить, что назначение соединения - запросить проверку клиента вредоносной программы. Здесь мы сократили значение id; первоначально оно содержало более 7 000 байтов. Его длина указывает на то, что это может быть основная полезная нагрузка сообщения. Назначение hash пока неизвестно, как и значение iv с примечательным именем. Не является ли оно вектором инициализации, используемым для шифрования полезной нагрузки? Позднее мы подтвердим, что это так.

CyberChef (gchq.github.io) - веб-приложение с открытым исходным кодом для шифрования, кодирования, сжатия и анализа данных. Оно разработано Центром правительственной связи (GCHQ), британским аналогом АНБ, и, вероятно, является наиболее удобным для пользователя способом манипулировать данными, преобразовывать и расшифровывать их при анализе вредоносных программ. В этом разделе мы воспользуемся им, чтобы поэкспериментировать с протоколом зашифрованного обмена данными вредоносной программы.

На рисунке 4-3 показан интерфейс CyberChef. В правом верхнем углу можно ввести открытые данные для преобразования. В правом нижнем углу находится поле вывода преобразованных данных. Слева можно выбрать одно из десятков преобразований данных и перетащить его в центральную область.

Рисунок 4-3. Использование CyberChef для получения шестнадцатеричных значений байтов строки, закодированной в Base64

В показанном примере мы ввели значение iv из полезной нагрузки JSON предыдущего раздела. Затем выбрали два преобразования данных: декодирование Base64 и преобразование результата в шестнадцатеричную строку. В результате выводится строка 33 42 9c 49 1c 0e 32 f2 a7 6c d7 78 4c 4e f5 f5, соответствующая байтам значения iv до кодирования в Base64.

Вывод Frida сообщил нам, что вредоносная программа применяет шифрование AES в так называемом режиме CBC для шифрования и расшифрования полезных нагрузок. Чтобы успешно расшифровать полезную нагрузку, необходимо восстановить ключи шифрования и векторы инициализации алгоритма. В журналах logcat, самой полезной нагрузке JSON и выводе Frida нам встретилось несколько потенциальных ключей шифрования и векторов инициализации. В следующем разделе мы представим более систематический подход к обнаружению этих значений, но пока воспользуемся IV из полезной нагрузки JSON и ключом шифрования, найденным в системном журнале. Этих сведений достаточно, чтобы завершить рецепт CyberChef, правильно выбрав форматы ввода полезной нагрузки, ключа и IV (в нашем случае Raw, Hex и Base64). Результат показан на рисунке 4-4.

Рисунок 4-4. Расшифрование обмена данными с сервером управления с помощью CyberChef

В листинге 4-7 мы полностью воспроизвели расшифрованную полезную нагрузку JSON.

Листинг 4-7. Расшифрованная полезная нагрузка JSON, отправленная по URL /ping

Поле api, вероятно, содержит версию Android API устройства (вспомните, что в начале главы мы настроили значение 30). Далее следует список apps, предположительно содержащий приложения, установленные в системе. Поля imei и model, вероятно, представляют номер IMEI и модель устройства. Что означает numbers, неясно, но это может быть номер телефона устройства или телефонные номера контактов из списка. Поле tag, вероятно, идентифицирует само вредоносное приложение, а uid может быть неким уникальным идентификатором пользователя.

Разумеется, теперь необходимо рассмотреть данные, возвращаемые сервером. В листинге 4-8 показан ответ на запрос POST.

Листинг 4-8. Ответ JSON, полученный с URL /ping

Значение response_verify поля type соответствует полю request_verify полезной нагрузки POST. Три других поля, hash, id и iv, также соответствуют полям запроса POST. Их значения, по-видимому, закодированы в Base64.

Попытка расшифровать поле id с помощью использованного ранее ключа шифрования и значения IV из ответа POST не сразу даёт удобочитаемый результат. Расшифрованное значение представляет собой 16-байтовый массив из кажущихся случайными байтов. Их назначение и значение пока неясны. Точно так же нам не удаётся легко расшифровать полезные нагрузки POST последующих соединений с сервером управления. Необходимо стратегически исследовать вредоносную программу глубже.

Хотя наш сценарий Frida предоставляет сведения о зашифрованных полезных нагрузках, он не связывает их с URL-соединениями. Однако, если мы не хотим полностью автоматизировать анализ, этого и не требуется. Мы уже зарегистрировали HTTP-соединения и их полезные нагрузки с помощью tcpdump и можем просмотреть их в Wireshark. Сравним полезные нагрузки из файлов, записанных Frida, с видимыми в Wireshark. Поскольку вредоносная программа устанавливает очень мало соединений со своим сервером, продолжить без автоматизации этого шага вполне реально.

Когда мы записывали сетевой трафик с помощью tcpdump и Wireshark, то узнали, что первое соединение вредоносная программа устанавливает с http://simpleyo5.tk/ping. Кроме того, нам удалось расшифровать его полезную нагрузку на основе сведений из Frida и logcat. Самую большую часть полезной нагрузки составлял список установленных приложений. Сервер ответил полезной нагрузкой JSON похожего формата, но намного меньшего размера. Более продолжительный запуск tcpdump и Wireshark, по-видимому, не меняет эту полезную нагрузку и ответ. Хотя приложение устанавливает последующие соединения с этим URL, данная команда, судя по всему, используется только для уведомления сервера о доступном клиенте.

Если ещё раз взглянуть на Wireshark, можно заметить другой URL, к которому подключается вредоносная программа, и он гораздо интереснее. После первого соединения с /ping программа начинает подключаться к http://simpleyo5.tk/metrics. Эти соединения происходят чаще и имеют более разнообразные полезные нагрузки в обоих направлениях.

При первом соединении с конечной точкой /metrics вредоносная программа передаёт JSON-файл с ключами в открытом виде и зашифрованными значениями, похожий на передаваемый в /ping. Например, он может выглядеть как показанный в листинге 4-13.

Листинг 4-13. Полезная нагрузка JSON, отправленная по URL /metrics для команды jni_update

Значения полей hash, id и iv, вероятно, играют ту же роль, что и в полезной нагрузке для /ping. Поле metrics является новым и заменяет передаваемое в /ping открытое значение поля type.

Оказывается, metrics расшифровывается как {"type":"inj_update"}, что выглядит простым запросом приложения к серверу на получение сведений об «инъекциях», чем бы они ни были. Сервер отвечает длинным сообщением, которое расшифровывается в полезную нагрузку JSON из листинга 4-14.

Листинг 4-14. Расшифрованный ответ JSON с URL /metrics

Этот длинный список имён пакетов приложений и URL представляет интерес. Сегодня эти URL давно недоступны, но мы исследовали их во время предыдущего анализа и можем показать здесь. Каждый HTML-файл является фишинговой страницей для отдельного законного приложения. На снимке экрана на рисунке 4-5 показана фишинговая страница, связанная с com.android.vending - именем пакета приложения Google Play.

Рисунок 4-5. Поле ввода для кражи сведений о банковской карте в Google Play

Помимо inj_update, URL /metrics может принимать по меньшей мере ещё одну команду. При последующем соединении вредоносная программа отправляет ему команду get_coms, полезная нагрузка которой показана в листинге 4-15.

Листинг 4-15. Расшифрованная полезная нагрузка JSON, отправленная по URL /metrics для команды get_coms

Кроме поля type, указывающего тип сообщения, очевидным выглядит только назначение поля user_present. Неясно, к чему относится rm_triggered, и точный смысл поля permissions также остаётся загадкой. Тем не менее мы получаем дополнительную подсказку о том, что приложение интересуют уведомления приложений.

В наших тестах get_coms была самой частой командой из отправлявшихся серверу. К сожалению, единственным наблюдавшимся ответом была пустая полезная нагрузка {'type': 'get_coms', 'coms': []}. К тому времени, когда мы приступили к углублённому анализу, серверы управления уже были отключены, поэтому для рассуждений о поведении вредоносной программы пришлось использовать полезные нагрузки, ранее собранные в архивах нашего сканера вредоносных программ.

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

Ключ шифрования 5f 9e 4a 92 b1 d8 c8 b9 8d b9 b7 f8 f8 80 0d 2e, обнаруженный нами ранее, используется только для первоначального обмена данными с сервером управления при первом соединении с URL /ping. Вспомните, что ответная полезная нагрузка /ping содержит поле JSON id. В этом поле находится новый ключ шифрования. Само поле зашифровано, но его можно расшифровать с помощью первоначального ключа и вектора инициализации из поля iv ответа.

Оказывается, приложение также записывает этот новый ключ в системный журнал. Его можно получить с помощью logcat:

Закодированное в Base64 значение в конце каждой строки журнала представляет собой новый ключ шифрования. Журнал также показывает, что ключ меняется и далее, предположительно при каждом вызове /ping, поскольку между любыми двумя вызовами /ping он, по-видимому, остаётся неизменным.

Запуск приложения и исследование его сообщений с сервером управления дали нам несколько направлений для дальнейшей работы. Мы знаем, что приложение хочет получить разрешение на использование API специальных возможностей, интересуется установленными приложениями и разрешениями службы прослушивания уведомлений. Воспользуемся этими сведениями, чтобы копнуть глубже.

Наш анализ уже несколько раз подтверждал наличие пакета Java с именем com.sniff. Одним из следующих шагов может стать исследование этого пакета с помощью Frida.

Можно было бы наивно попытаться использовать frida-trace, чтобы перехватить все методы пакета и зарегистрировать их использование, аргументы и возвращаемые значения. Однако простой запуск команды, похожей на применявшуюся ранее в этой главе для перехвата криптографических API, не даст хорошего результата, как видно здесь:

Как показывает вывод, Frida удаётся найти лишь четыре метода в классе MainApplication. Это происходит потому, что к моменту перечисления загруженных классов инструментом frida-trace загрузчик классов Java ещё не успевает завершить загрузку всех классов приложения.

Есть два способа выполнить более полную трассировку. Во-первых, команду frida-trace можно изменить так, чтобы она подключалась к уже существующему процессу, а не запускала новый. Сделать это легко, но тогда будут пропущены все вызовы методов между запуском приложения и присоединением Frida к процессу. Другой вариант - написать более сложный сценарий Frida, который дождётся завершения работы загрузчика классов, перечислит все методы и перехватит их. Для нашей цели должен неплохо подойти небрежный вариант с подключением к работающему процессу благодаря особенности вредоносной программы. Поскольку программа блокирует выполнение большинства своих функций, пока пользователь не предоставит ей разрешение использовать API специальных возможностей, мы просто запускаем приложение, оставляем его на экране запроса доступа к специальным возможностям и присоединяем Frida к процессу.

Чтобы указать frida-server присоединиться к процессу вместо запуска собственного, можно заменить аргумент -f на -p и передать ему идентификатор процесса вместо имени пакета. Также можно подключиться к процессу по имени, но в Android это неудобно, поскольку Frida ожидает имя приложения, а не имя пакета. Обычно при анализе вредоносной программы вы быстро узнаёте имя пакета приложения, но не его текстовое имя. Здесь мы подключаемся к com.spike.old по идентификатору процесса 24606:

Мы значительно сократили вывод для этой книги. На практике сценарий создаёт сотни строк в секунду. Даже этот частичный журнал, охватывающий 700 мс активности, содержит множество сведений. Мы видим дополнительные имена классов и пакетов в com.sniff, а также то, как вредоносная программа считывает URL сервера управления из файла конфигурации ring0.xml и использует шифрование. Всё это связывает воедино загадочный класс KingService.

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

Мы упоминали, что первым делом приложение просит пользователей разрешить ему использовать API специальных возможностей. Зачем ему требуется это разрешение, всё ещё неясно, поэтому исследуем вопрос глубже. Для этой задачи можно снова использовать frida-trace, чтобы охватить широкий диапазон и зарегистрировать все обращения приложения к API специальных возможностей:

После того как мы вручную предоставим приложению доступ к API специальных возможностей в эмуляторе, команда frida-trace создаст несколько мегабайт вывода. Однако в эмуляторе вы почти ничего не увидите, кроме главного экрана и двух диалогов разрешений - на чтение SMS-сообщений и совершение телефонных вызовов, - которые появляются и исчезают. Предположительно, приложение само предоставляет себе эти разрешения, имитируя нажатие пользователем кнопок диалогов.

Продирание через мегабайты журналов использования API специальных возможностей - утомительная задача. Однако начать можно с поиска определённых закономерностей. Исследуя трассировки вызовов во Frida ранее в этой главе, мы определили com.sniff.sibling как потенциально интересный пакет Java во вредоносной программе. Поиск в файле журнала обнаруживает два интересных класса Java:

Класс PermissionActivity может быть активностью, отвечающей за нажатие кнопок в диалогах разрешений на SMS и вызовы, а AccessibilityEnableHintActivity может быть активностью, показывающей окно с просьбой к пользователю предоставить разрешение специальных возможностей.

Другой способ взглянуть на файл журнала - попытаться понять, какие классы API специальных возможностей использует приложение. Оказывается, очень многие. Ответ следующей команды оболочки Linux содержит около 50 разных классов, что создаёт намного более сложную ситуацию, чем наш предыдущий эксперимент с перехватом криптографических API:

Без представления о том, что искать дальше, этот метод исследования может завести в тупик. Мы достигли точки, в которой чистый динамический анализ становится слишком громоздким и, возможно, следует перейти к смешанному исследованию программы с помощью статического анализа.

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

Первая часть анализа, которую мы можем завершить, связана с сервером управления. С помощью динамического анализа мы обнаружили домен simpleyo5.tk с двумя конечными точками, /ping и /metrics. Поиск этого домена в jadx находит одну строку. Этот код и окружающие его строки из com.sniff.sibling.Constants показаны в листинге 4-16.

Листинг 4-16. Доменные имена и ключ шифрования внутри com.spike.old

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

Очень часто при анализе вредоносных программ интересные части функциональности расположены в коде рядом. Например, взгляните на строки из файла com.sniff.sibling.Constants, показанные в листинге 4-17.

Листинг 4-17. Другие интересные строки, найденные в com.sniff.sibling.Constants

Вы должны узнать эти строки по предыдущим этапам анализа. В частности, строки из четырёх прописных букв были именами XML-тегов из загадочного файла конфигурации ring0.xml. Мы видим, что эти имена тегов являются не просто случайными символами, а сокращениями, указывающими на их назначение. Один динамический анализ не смог бы это раскрыть. Аналогично наличие лишь двух строк, начинающихся с api*, служит некоторым свидетельством того, что /ping и /metrics - единственные конечные точки, поддерживаемые серверами управления вредоносной программы.

Ещё один фрагмент кода в com.sniff.sibling.Constants представляет особый интерес. В статическом инициализаторе рядом с инициализацией массива серверов управления находятся инструкции, указывающие на разрешения, используемые вредоносной программой. Они показаны в листинге 4-18.

Листинг 4-18. Строки разрешений в com.sniff.sibling.Constants

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

Анализ com.sniff.sibling.Constants раскрыл все серверы управления вредоносной программы и их URL, но у нас по-прежнему нет полного списка команд, которые способно выполнять приложение. Это иллюстрирует ещё одну проблему чистого динамического анализа: если сервер не прикажет вредоносной программе выполнить определённые команды во время наблюдения, среда динамического анализа никогда о них не узнает.

Мы знаем, что URL /metrics поддерживает по меньшей мере две команды: inj_update и get_coms. Чтобы найти другие потенциальные команды, можно выполнить поиск известных и надеяться, что остальные определены рядом. Поиск строк этих двух команд показывает, что они встречаются в четырёх местах кода, три из которых весьма интересны.

Сначала мы находим ссылку на inj_update внутри com.sniff.sibling.Api.Controllers.ApiOperationsController. Показанный в листинге 4-19 код, использующий эту строку, имеет удачное имя parsePayload.

Листинг 4-19. Код в parsePayload подтверждает существование трёх команд.

Код излишне сложен, поскольку всего лишь разбирает ранее расшифрованный ответ сервера, чтобы определить, имеет ли полученный JSON-объект тег type со значением notif_ic_update, get_coms или inj_update. Ранее мы не встречали notif_ic_update, но эта команда, по-видимому, не используется, поскольку с ней не связана ни одна ветвь завершающей инструкции if. Возможно, поэтому мы не наблюдали её отправку с сервера.

Эти строки снова встречаются внутри загадочного класса KingService, который мы уже несколько раз видели во время анализа. Показанная в листинге 4-20 функция, использующая их, по-видимому, является главным циклом выполнения вредоносной программы. В ней описан каждый этап работы программы, и всё совпадает с тем, что мы наблюдали с помощью logcat и Frida.

Листинг 4-20. Главный цикл выполнения вредоносной программы, найденный в классе KingService

Код прямо показывает, что вредоносная программа сначала пытается подключиться к интернету и прекращает действия, если сеть недоступна. Затем она проверяет, занята ли сеть, то есть выполняется ли какая-либо другая команда сервера. Кроме того, программа проверяет следующее: прошёл ли клиент проверку и, если да, не истёк ли срок её действия; не пора ли отправить серверу команду inj_update; не пора ли отправить команду get_coms;

предоставлены ли необходимые разрешения; предоставлен ли вредоносной программе доступ к уведомлениям. Наконец, она запускает режим doze - настройку, связанную с оптимизацией энергопотребления.

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

Третий интересный фрагмент кода, ссылающийся на строку inj_update, находится в классе com.sniff.sibling.Api.TDP.ApiGetCommandsResponsePayload, содержащем код для дальнейшего разбора ответа сервера get_coms. Его сокращённое ради краткости начало показано в листинге 4-21.

Листинг 4-21. Код, раскрывающий дополнительные команды сервера

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

• app_list - загружает на сервер сведения об установленных приложениях;

• sms_log - загружает на сервер все SMS-сообщения с устройства;

• notif_ic_enable - начинает перехватывать уведомления на устройстве;

• notif_ic_disable - прекращает перехватывать уведомления на устройстве;

• sms_ic_enable - начинает перехватывать SMS;

• sms_ic_disable - прекращает перехватывать SMS;

• inj_enable - включает фишинговые окна-накладки;

• inj_disable - отключает фишинговые окна-накладки;

• inj_update - запрашивает у сервера новые фишинговые окна.

Помимо этих команд, вредоносная программа ищет множество команд, за которыми не стоит никакого кода. Это указывает на то, что программа находится в стадии интенсивной разработки и в будущем может получить дополнительные функции. Нереализованные команды: self_kill, fg_disable, inj_list, self_cleanup, notif_ic_update, fg_enable, app_kill, sms_ic_update, sms_ic_list и notif_ic_list. Об их назначении можно судить лишь по именам.

Теперь мы знаем всё о серверах управления: их домены, URL и команды. Кроме того, нам известны собираемые вредоносной программой данные и фактически реализованные команды. Это даёт очень хорошее представление о её возможностях и ещё раз доказывает, что понимание обработчика команд вредоносной программы является ключом к пониманию её функциональности.

В этом разделе мы обсудим несколько известных методов классификации. Как вы увидите, классификаторы работают по-разному.

Алгоритм классификации с помощью дерева решений строит дерево, каждый узел которого сравнивает один признак с одним значением. Таким образом, каждый путь дерева соответствует сложному логическому условию «и» вместе с меткой класса, показывающей класс, который лучше всего соответствует условию. Предположим, нам дан обучающий набор T, векторы признаков которого взяты из n-мерного пространства. Образцами являются приложения Android, которые требуется классифицировать по двум классам: доброкачественные и вредоносные программы. Для этого каждому приложению a мы сопоставляем вектор признаков f_a, состоящий из n признаков. На рисунке 5-4 показан пример дерева решений для классификации приложений.

Рисунок 5-4. Пример дерева решений

Каждый узел дерева решений неявно представляет подмножество обучающего набора. Например, корень дерева решений на рисунке 5-4 представляет обучающий набор из 1 000 приложений. Каждый узел содержит логическое условие, разделяющее набор на два непересекающихся множества: одно состоит из всех элементов, удовлетворяющих условию, а другое - из всех элементов, которые ему не удовлетворяют. Например, в корневом узле условие проверяет, меньше или равно 1989,5 число вызовов кода операции iget-boolean. Этот код операции считывает логическое поле экземпляра из регистров и представлен как байт-код в формате Dalvik - наборе инструкций, используемом средами выполнения Android. Все приложения, удовлетворяющие условию, связаны с левым дочерним узлом корня, а не удовлетворяющие ему попадают во множество приложений, связанное с правым дочерним узлом.

Узлы также содержат другие сведения, помогающие классифицировать приложения как вредоносные или доброкачественные. Например, в корневом узле указано количество образцов - 1 000 - и то, что каждый из двух классов (сначала доброкачественные, затем вредоносные программы) содержит 500 приложений. Поскольку в корневом узле классы разделены поровну, этот узел можно пометить любым из них. В данном случае мы решили назвать его доброкачественным. Теперь взгляните на левый дочерний узел корня. Мы видим, что он содержит 519 приложений. (То есть 519 образцов из обучающего набора удовлетворили условию корневого узла.) Из поля Value видно, что 39 из этих 519 приложений являются доброкачественными, а остальные 480 - вредоносными. Поэтому узел помечен как вредоносный, поскольку так классифицируется большинство его приложений.

Теперь естественным образом возникают два вопроса. Во-первых, как алгоритм дерева решений определяет, какое условие выбрать в каждом узле дерева? Во-вторых, что представляет собой поле Gini, показанное в узлах на рисунке 5-4? Ответы тесно связаны. Каждое дерево решений рассматривает некоторое семейство ограничений, чтобы выбрать условия, которыми будут помечены узлы. В нашем примере дерева этот класс состоит из ограничений вида признак <= значение. Помимо этого алгоритм опирается на значение Джини - попытку измерить неоднородность классов, представленных во множестве приложений обучающего образца для узла. В корневом узле на рисунке 5-4 неоднородность максимальна, поскольку оба класса представлены поровну. Однако в его левом дочернем узле подавляющее большинство приложений являются вредоносными. Метрика Джини присваивает высокое значение неоднородным узлам и низкое - однородным. Следовательно, значение Джини корневого узла выше, чем его левого дочернего узла. Само значение Джини определяется так:

Gini(X) = 1 - P(malware|X)^2 - P(goodware|X)^2

Поскольку в корневом узле вероятность того, что приложение является доброкачественным, совпадает с вероятностью того, что оно является вредоносным, и равна 50 процентам, значение Джини корня составляет 1 - (0,5)^2 - (0,5)^2 = 0,5. Для левого дочернего узла корня вероятность того, что приложение является доброкачественным, равна 480/519. Поэтому его значение Джини составляет 1 - (39/519)^2 - (480/519)^2 = 1 - 0,075^2 - 0,925^2 = 1 - 0,0056 - 0,856 = 0,139.

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

Существует множество вариантов деревьев решений. Некоторые используют для оценки качества возможных способов разделения узла такие критерии, как энтропия, а не оценки Джини. Другие варианты изменяют типы условий в каждом узле и даже устраивают всё так, чтобы дерево решений принимало в каждом узле трёхвариантное или n-вариантное решение вместо бинарного. Подробнее о построении деревьев решений и их вариантах можно прочитать в работах Лиора Рокача и Одеда Маймона «Top-Down Induction of Decision Trees Classifiers - A Survey» и Насиба С. Гилла и Рины Худы «Optimizing Multi-Path Decision Tree by Clustering and K-Nearest Neighbor Methods».

Бэггинг и случайный лес (random forest, RF) - классические примеры ансамблевых классификаторов, то есть алгоритмов, объединяющих прогнозы нескольких других классификаторов. Ансамблевые классификаторы обычно начинают с известного классификатора, иногда называемого слабым учеником. В случае бэггинга и RF это часто дерево решений.

Алгоритмы бэггинга и RF используют два средства для повышения устойчивости результата классификации на основе обучающего набора. Первое - случайный выбор некоторого количества подмножеств из обучающего набора. Второе - случайный выбор подмножества признаков. Обычно к построению этих подмножеств не предъявляется иных требований, кроме того, что размер каждого должен составлять некоторый процент размера исходного обучающего набора, например 65 или 80 процентов. Затем на каждом подмножестве отдельно и независимо обучается слабый ученик, выдающий метку класса. Класс нового приложения объявляется классом, предсказанным большинством слабых учеников.

Бэггинг не требует, чтобы слабым учеником было дерево решений: им может быть классификатор любого типа. С другой стороны, классификаторы случайного леса предполагают, что слабый ученик - дерево решений. Для каждого рассмотренного ранее подмножества строится дерево решений, и в каждом узле любого из задействованных деревьев заданный набор атрибутов считается активным. Активными являются атрибуты, которые ещё не использовались на пути от корня дерева решений к этому узлу. Затем в каждом узле случайным образом выбирается подмножество активных атрибутов, а лучшее условие разделения выбирается только из условий, определяемых активными атрибутами; неактивные атрибуты не рассматриваются, даже если обеспечивают лучший результат Джини. После этого каждое дерево решений, как и прежде, создаёт метку, и класс, получивший больше «голосов», назначается данному приложению.

Алгоритм метода опорных векторов (support vector machine, SVM) пытается найти гиперплоскость, разделяющую пространство признаков на две части таким образом, чтобы векторы признаков, связанные с одним классом (в нашем случае вредоносными программами), преимущественно находились по одну сторону гиперплоскости, а векторы другого класса (доброкачественных программ) - по другую. Две такие гиперплоскости были показаны на рисунке 5-2. В двумерном пространстве признаков гиперплоскость является просто прямой линией. Однако гиперплоскостью также может быть квадратичная линия или даже синусоида.

Линейный SVM использует в качестве разделителей только прямые линии. В пространствах большей размерности линейная гиперплоскость имеет следующий вид:

a_1x_1 + a_2x_2 + ... + a_nx_n = b

Здесь x_1, ..., x_n представляют n признаков, а a_1, ..., a_n и b являются константами. Такая гиперплоскость делит пространство признаков на две части: одну, удовлетворяющую a_1x_1 + a_2x_2 + ... + a_nx_n >= b, и другую, удовлетворяющую a_1x_1 + a_2x_2 + ... + a_nx_n <= b. Идея состоит в том, что большинство вредоносных программ окажется в одной из этих частей, а большинство доброкачественных - в другой. Разработчики должны решить, что делать с приложениями, векторы признаков которых находятся непосредственно на разделяющей линии.

Чтобы найти хорошую разделяющую гиперплоскость в линейном SVM, обычно рассматривают два основных фактора: однородность векторов признаков по обе стороны гиперплоскости и отсутствие векторов признаков вблизи неё. В плане однородности желательно, чтобы большинство векторов признаков приложений с одной стороны разделителя относились к вредоносным программам, а большинство векторов с другой стороны - к доброкачественным. Например, вспомните горизонтальное разделение на рисунке 5-2, где новое приложение классифицировалось простым подсчётом числа выполненных им вызовов классов определённого пакета: если их было больше 3 000, приложение классифицировалось как доброкачественное, в противном случае - как вредоносное. Разумеется, это сильно упрощённый пример. В реальной ситуации реализация рассматривала бы намного больше признаков, а уравнение разделяющей линии, скорее всего, было бы гораздо сложнее.

Второй основной фактор при проектировании SVM связан с векторами признаков, расположенными очень близко к разделяющей линии, например с образцом вредоносной программы, изображённым крестиком в правой части рисунка 5-2 непосредственно под обеими разделяющими линиями. Насколько мы можем быть уверены, что такие образцы классифицированы правильно? Чтобы увеличить расстояние между векторами признаков и разделяющей линией, используются опорные векторы - векторы признаков обучающего набора, расположенные как можно ближе к разделяющей линии. Расстояние между разделяющей линией и её опорными векторами называется зазором. SVM пытаются найти ближайшую разделяющую линию, максимизирующую зазор, что отражает интуитивное стремление не располагать обучающие точки слишком близко к границе.

Цели максимизации зазора и минимизации ошибок классификации часто противоречат друг другу. Поэтому задачу поиска лучшей разделяющей линии обычно формулируют как задачу оптимизации. В этой главе мы не будем углубляться в математические детали SVM, но заинтересованный читатель может найти дополнительные сведения в работах Коринны Кортес и Владимира Вапника «Support-Vector Networks» и Кристофера Дж. Бёрджеса и Бернхарда Шёлькопфа «Improving the Accuracy and Speed of Support Vector Machines».

Существует также множество нелинейных вариантов SVM. Например, квадратичные SVM позволяют разделяющей гиперплоскости принимать форму квадратичной кривой и работать с более сложным распределением векторов признаков. Другие виды SVM используют ядерные трюки, которые отображают исходный вектор признаков в новый. Отображение обычно выполняется нелинейным методом. Применение линейного SVM к этому нелинейному преобразованию даёт нелинейный разделитель исходных данных. В результате разделители могут иметь необычную форму. Например, на рисунке 5-5 в части (a) показан изменённый обучающий набор, похожий на визуализации обучающих наборов ранее в этой главе. В частях (b), (c) и (d) показаны разделители, созданные SVM с разными видами ядер.

Рисунок 5-5. Примеры нелинейных разделителей SVM, созданных с помощью ядер для обучающего набора: (a) векторы признаков вредоносных программ (крестики) и доброкачественных программ (точки), (b) разделитель SVM с полиномиальным ядром, (c) разделитель SVM с квадратичным ядром и (d) разделитель SVM с радиально-базисным ядром

Обратите внимание, что созданные области не так легко описать, как области с линейными разделителями.

Классификатор k ближайших соседей очень прост. В действительности он не «обучает» модель. Он принимает вектор признаков ранее не встречавшегося приложения, с помощью некоторой метрики расстояния (например, евклидова или косинусного расстояния) находит в обучающих данных k векторов признаков, ближайших к вектору приложения, а затем определяет классы этих k приложений. Если более половины из них являются вредоносными, классификатор объявляет новое приложение вредоносным; в противном случае - доброкачественным. Например, рассмотрим два приложения, A1 и A2, показанные на рисунке 5-6.

Рисунок 5-6. Пример классификатора k ближайших соседей при k = 3

Предположим, мы рассматриваем трёх ближайших соседей (иными словами, k = 3). Для A1 два из трёх ближайших соседей являются доброкачественными, поэтому приложение A1 будет считаться доброкачественным. Однако для A2 два из трёх ближайших соседей классифицированы как вредоносные, следовательно, и это приложение будет классифицировано как вредоносное.

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

Чтобы классифицировать приложения как доброкачественные или вредоносные, классификатор наивного Байеса может вычислять так называемые условные вероятности класса. Для данного класса (в нашем случае доброкачественных либо вредоносных программ) можно использовать обучающий набор, чтобы вывести условную вероятность того, что i-й признак вектора признаков имеет определённое значение при условии, что приложение принадлежит конкретному классу. Рассмотрим небольшой обучающий набор, показанный в таблице 5-2.

Признаки A и B представляют соответственно вызовы APIPackage:android.app и Opcode:if-eq. Вероятности P(A = 10|0) и P(A = 10|1) являются условными вероятностями класса того, что атрибут A имеет значение 10 при классах 0 и 1 соответственно. Из обучающего набора видно, что P(A = 10|0) равна 0,2, поскольку у 2 из 10 доброкачественных приложений значение A равно 10. P(A = 10|1) также равна 0,2. В отличие от них, P(A = 3|0) равна 0, а P(A = 3|1) - 0,3.

Таблица 5-2. Пример обучающего набора

Классификатор наивного Байеса также может вычислять априорную вероятность каждого класса, то есть просто вероятность того, что случайное приложение из обучающего набора принадлежит данному классу. В нашем небольшом обучающем наборе эти априорные вероятности равны 0,5 для каждого из двух классов, поскольку данные содержат 10 доброкачественных и 10 вредоносных образцов. Для нового приложения a со связанным вектором признаков, состоящим из значений f_a = (v_1, ..., v_n), наивный Байес вычисляет вероятность принадлежности приложения классу c по правилу Байеса:

P(c|f_a) = (P(f_a|c) × P(c)) / P(f_a)

Обычными словами, вероятность принадлежности приложения a классу c равна вероятности того, что вектор признаков a создан классом c, умноженной на априорную вероятность класса c и разделённой на априорную вероятность вектора признаков приложения a.

Чтобы определить класс нового приложения a с вектором признаков f_a, наивный Байес находит класс c, для которого P(c|f_a) максимальна среди всех возможных классов. Результат совпадает с нахождением класса c, для которого максимально произведение P(f_a|c) × P(c), поскольку знаменатель формулы вероятности остаётся одинаковым независимо от рассматриваемого класса. Назовём это произведение псевдовероятностью. Требуется найти класс c, максимизирующий псевдовероятность.

Теперь рассмотрим новое приложение a с вектором признаков (3, 1), то есть признак A равен 3, а B равен 1. Обратите внимание, что в обучающем наборе нет приложения с таким вектором. Наивный Байес вычисляет вероятность появления вектора (3, 1), делая предположение о независимости: вероятность появления вектора признаков считается произведением вероятностей появления каждого его компонента. Формально это можно записать так:

P(f_a|c) = ∏_(i=1)^n P(f_a^i = v_i|c)

Здесь P(f_a^i = v_i|c) - условная вероятность того, что f_a^i = v_i, при условии принадлежности приложения классу c, а f_a^i представляет i-й компонент вектора признаков f_a приложения a. Возвращаясь к примеру из таблицы 5-2, видим, что псевдовероятности для вектора (3, 1) определяются следующим образом:

Поскольку второе значение больше первого, данное приложение с вектором признаков (3, 1) классифицируется как вредоносное.

У классификаторов наивного Байеса есть несколько проблем. Часто, особенно при длинном векторе признаков, числитель при вычислении произведения оказывается равным нулю, в результате чего вероятность также равна нулю. Ряд вариантов наивного Байеса исправляет такие проблемы, делая разные предположения о распределении значений каждого признака. Например, гауссовский наивный Байес предполагает, что они распределены в соответствии с нормальным распределением, среднее и стандартное отклонение которого вычисляются по наблюдаемым значениям признака в обучающих данных. Дополнительные сведения о классификаторах наивного Байеса и их вариантах можно найти в работе Кончи Бьельсы и Педро Ларраньяги «Discrete Bayesian Network Classifiers: A Survey».

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

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

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

Например, предположим, что мы пытаемся отличать шпионские программы Android от доброкачественных. В большинстве доступных сегодня общих наборов вредоносных программ число образцов шпионского ПО будет значительно меньше числа доброкачественных образцов. Причина может заключаться в том, что набор собирался для отделения всех видов вредоносных программ, а не только шпионских, от доброкачественных. Если обучать классификатор отделять шпионские программы от доброкачественных, число образцов шпионского ПО окажется относительно малым по сравнению с числом доброкачественных.

Такой дисбаланс размеров классов способен серьёзно повлиять на эффективность алгоритмов классификации.

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

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

В литературе эффективность многих основанных на машинном обучении алгоритмов обнаружения вредоносных программ оценивалась с помощью k-блочной перекрёстной проверки - метода, который случайным образом разделяет обучающие данные на k непересекающихся частей, называемых блоками, а затем выполняет k итераций по этим блокам. На каждой итерации соответствующий блок (например, третий на третьей итерации) удаляется, а некоторый классификатор заданного типа (например, SVM) обучается на всех оставшихся блоках. Затем модель делает прогнозы для удалённого блока, и её эффективность вычисляется только на этой итерации с помощью такой рассмотренной ранее метрики, как AUC или оценка F1. После этого метод даёт итоговую оценку типа модели (например, SVM), вычисляя агрегированное значение метрики эффективности по всем k блокам.

Однако перекрёстная проверка не всегда уместна, поскольку вредоносные программы развиваются со временем, а k-блочная перекрёстная проверка игнорирует время первого появления данного приложения из обучающих данных в реальных условиях. В результате блоки, используемые на любой итерации, могут включать приложения, выпущенные после некоторых приложений из удалённого блока. Интуитивно это означает, что мы, вероятно, предсказываем состояние некоторых приложений на основе сведений из будущего, что может искусственно завысить эффективность классификатора.

В отличие от этого, прогнозирование со скользящим окном сортирует приложения a_1, ..., a_n в наборе данных по времени появления каждого из них в реальных условиях. Затем мы предполагаем, что для качественного обучения требуется не менее j приложений. Для каждого i, такого что j < i <= n, мы обучаем модель на наборе {a_1, ..., a_j} и оцениваем эффективность P_i* заданного классификатора. Общей эффективностью классификатора считается среднее значение P_i* для i < j <= n. Эта методика исключает возможность использования сведений из будущего для прогнозирования прошлого.

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

Внутри APK есть несколько файлов и папок, свойства и содержимое которых можно преобразовать в признаки машинного обучения. Один из источников - файл AndroidManifest.xml, находящийся в корневом каталоге каждого APK. Как обсуждалось в главе 3, файл манифеста определяет структуру и метаданные приложения Android, включая имя пакета и версию приложения. Он также может содержать XML-узлы, описывающие основное поведение приложения, и запрашиваемые им разрешения. В листинге 6-1 показан фрагмент файла манифеста вредоносного приложения Fakebank com.a (v152, 0add), ссылающийся на XML-узлы.

Листинг 6-1. XML-узлы в манифесте Android, связанные с приложением Fakebank

Признаки также можно найти в папке с исходным кодом Java. В приложениях Java эта папка является частью исходного кода и отсутствует в скомпилированном APK-файле. Другие интересующие папки - Res, lib и assets. Папка Res содержит все некодовые ресурсы приложения, например XML-макеты и изображения. Папка lib непроста, поскольку после компиляции её назначение меняется: в исходном коде Android она часто используется для хранения общих файлов, служебных классов и импортированных зависимостей приложений, тогда как в скомпилированных APK-файлах в ней хранится нативный код приложения. Папка assets может включать широкий спектр файлов, например текст, XML, шрифты, музыку и видео. Ещё один источник признаков - файл build.gradle, содержащий настройки сборки. Он присутствует только во время разработки и не включается в окончательный APK.

Для многих признаков можно определить две версии. Бинарная версия признака принимает значение 0 или 1 в зависимости от отсутствия или наличия признака. Например, можно связать признак с вызовом функции API. Если приложение выполняет в коде хотя бы один вызов этого API, бинарной версии присваивается 1; в противном случае - 0. Статистическая версия того же признака может отражать количество вызовов API приложением. Либо она может регистрировать число вызовов функции API с определёнными входными данными и возвращать такую статистическую величину, как среднее, медиана или стандартное отклонение результатов. В литературе по обнаружению вредоносных программ на основе машинного обучения часто встречаются следующие признаки:

Можно разработать ряд признаков, связанных с разрешениями, которые запрашивает приложение. Например, можно создать бинарный признак для каждого разрешения. Также можно определить статистические признаки, соответствующие числу запрошенных обычных, подписных и опасных разрешений. Согласно официальному сайту разработчиков Android, опасные разрешения либо связаны с личными данными пользователей, либо могут повлиять на такие данные. Например, мы уже видели, что вредоносная программа com.bp.statis.bloodsugar, обсуждавшаяся в главе 3, запрашивает разрешение READ_CONTACTS, хотя нет особых оснований считать, что приложению для отслеживания уровня сахара в крови требуется доступ к контактам пользователя.

Как обсуждалось в главе 3, активности реализуют визуальный интерфейс приложения Android и объявляются в файле манифеста. Можно создать набор бинарных признаков, показывающих, используется ли каждая активность. Потенциальным признаком также является общее число активностей.

Приложения используют службы для реализации длительных фоновых операций, обеспечивающих взаимодействие с системой. Как и в случае активностей, можно определить бинарные признаки, показывающие, используется ли каждая служба. Кроме того, можно определить простые счётчики и статистические признаки. Например, для службы com.bp.statis.bloodsugar.PE, обсуждавшейся в главе 3, мы могли бы установить это значение в 1, поскольку нет особых причин, по которым приложению для отслеживания уровня сахара в крови следовало бы прослушивать входящие уведомления всех приложений системы.

Поставщик содержимого инкапсулирует данные и предоставляет их другим приложениям. Для каждого поставщика может существовать признак со значением 0, если он отсутствует, и 1, если присутствует в приложении. Кроме того, можно создать признак количества используемых приложением поставщиков содержимого.

Компонент широковещательного приёмника приложения позволяет ему получать широковещательные сообщения от системы или других приложений. Как и в предыдущих случаях, для таких приёмников можно создавать бинарные признаки, счётчики и статистические признаки. Однако, хотя широковещательные приёмники, объявленные в файле манифеста, найти легко, обнаружить объявленные во время выполнения удаётся не всегда, особенно если они являются частью зашифрованного или обфусцированного кода. Кроме того, некоторым приложениям может требоваться регистрация приёмника RECEIVE_SMS, позволяющего перехватывать входящий SMS-трафик, например одноразовые пароли или предупреждения о подозрительной активности.

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

Платформа Android предоставляет набор пакетов API, которые разработчики могут использовать для создания приложений. Можно создать бинарные признаки для каждого пакета API (в зависимости от того, вызывается он или нет), а также для каждого класса внутри пакетов (в зависимости от того, вызывается ли класс). Кроме того, числовые признаки пакета API могут отслеживать, сколько раз приложение вызывает класс внутри пакета или функцию внутри класса. Далее в этой главе мы подробно представим признаки API, поскольку на их основе можно создавать более сложные признаки.

Исходный код приложения Android может содержать множество сетевых элементов, например IP-адреса, URL и имена узлов. Их можно собирать для формирования бинарных и статистических признаков, например количества имён узлов в файле. В качестве признака также можно использовать число внешних URL, упоминаемых в коде.

Автор вредоносной программы может пытаться затруднить статический анализ с помощью различных средств. К ним относятся использование непонятных имён переменных, шифрование частей кода и другие методы обфускации, например рефлексия (см. главу 3). Можно также определить статические признаки, описывающие наличие подобных явлений в коде приложения и частоту их появления.

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

Для создания многих таких признаков приложению необходимо подать некоторый набор входных данных, например взаимодействия приложения с пользователем (примером служит команда monkey, обсуждавшаяся в главе 4). Можно запустить приложение с первыми входными данными и получить некоторые результаты, затем запустить со вторыми и получить дополнительные результаты, продолжая процесс до исчерпания всех входных данных набора. Кроме того, признаки можно извлекать путём анализа сетевого трафика, создаваемого при запуске приложения через такие программы, как tcpdump и Wireshark.

В литературе широко обсуждались следующие динамические признаки платформы Android:

Можно создавать динамические признаки, регистрирующие каждую запущенную службу. Они могут быть бинарными (в зависимости от того, запускает ли приложение данную службу) или числовыми (например, среднее число вызовов службы по набору входных данных). Потенциальным признаком также является общее число запущенных служб. Кроме того, последовательность служб можно связать с признаком, регистрируя, вызывает ли приложение когда-либо эту последовательность (бинарный признак) или сколько раз в среднем оно вызывает её по набору входных данных (числовой признак).

Это стандартный Android API, используемый для загрузки классов из файлов .jar и .apk, содержащих файл classes.dex. Вредоносные приложения часто используют этот API для уклонения от статического анализа, поскольку он позволяет выполнять код, не происходящий из исходного кода приложения (один из примеров - семейство вредоносных программ Xenomorph, обсуждавшееся в главе 4). Можно создать признак со значением 1, если приложение вызывает DexClassLoader, и 0 в противном случае. Дополнительные признаки можно определить по числу вызовов, последовательностям n-грамм и другой статистике.

Можно создать бинарные признаки, регистрирующие вызов приложением API, которому требуется определённое разрешение, даже если само разрешение отсутствует в коде приложения. Хотя приложения Android обязаны явно объявлять все запрашиваемые разрешения в файле манифеста, они могут пытаться обойти это требование, получая разрешения иными способами. Одна из стратегий - использование скрытого канала, например обмена данными между несколькими APK. Такое поведение создаёт проблему для специалистов по динамическому анализу, поскольку их лабораторные среды должны уметь одновременно запускать несколько взаимодействующих приложений. Как и в предыдущих случаях, на основе разрешений можно создавать статистические признаки и признаки n-грамм. Например, для вредоносной программы Xenomorph мы зарегистрировали бы факт вызова API специальных возможностей, присвоив этому значению 1.

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

Можно определить признак, отслеживающий выполнение приложением любых криптографических операций. Когда APK выполняет операции шифрования, например для хранения зашифрованных файлов, песочница, в которой он запущен, может это отследить и зарегистрировать. Бинарному признаку можно присвоить 1, если приложение создаёт какие-либо зашифрованные файлы во время выполнения, и 0 в противном случае. Такое поведение наблюдается в приложении Xenomorph: см. функцию encryptMessage в листинге 4-5, которую приложение может вызвать ноль или несколько раз во время выполнения в среде песочницы.

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

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

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

Можно захватывать намерения, на которые приложение отвечает во время выполнения, и регистрировать их как динамические признаки.

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

Вместо использования вызовов методов API по отдельности можно создать более устойчивую группу признаков, полученных из особого класса графов, называемых триадными графами подозрительности (triadic suspicion graphs, TSG). По существу, TSG стремится понять различия между использованием пакета API доброкачественными программами, с одной стороны, и разными видами вредоносных приложений - с другой. На рисунке 6-1 показан TSG, сравнивающий доброкачественные программы с банковскими троянами. В следующих абзацах мы рассмотрим его элементы.

TSG состоит из вершин, соединённых рёбрами. В данном контексте TSG содержит три вида вершин: полный набор вызовов пакетов API, определённых в Android API, выбранные доброкачественные программы и выбранные вредоносные программы, случайным образом взятые соответственно из более крупных коллекций доброкачественных и вредоносных программ. Рёбра TSG определяются следующим образом:

1. Для каждой доброкачественной программы g и каждого вызова пакета API a, если g хотя бы один раз вызывает метод из a, существует ребро из g в a.

2. Для каждой пары вызовов пакетов API a_1 и a_2, если a_1 вызывает любой метод из a_2, существует ребро из a_1 в a_2.

3. Для каждой вредоносной программы b и каждого вызова пакета API a, если b хотя бы один раз вызывает любой метод из a, существует ребро из b в a.

Рисунок 6-1. Частичный TSG, содержащий три доброкачественных образца

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

Мы также предлагаем сохранять размеры наборов относительно небольшими и тоже изменять их. Например, имея доступ к 1 миллиону доброкачественных и 10 000 вредоносных образцов, на первой неделе можно выбрать лишь по 1 000 образцов для каждой группы, на следующей - 1 322, на третьей - 1 127 и так далее. Частое изменение размеров выборок - ещё один способ оставить злоумышленника в неведении относительно характера используемой защиты; однако количество образцов в двух наборах должно быть примерно одинаковым.

Определив вершины и рёбра TSG, мы взвешиваем рёбра с помощью весовой функции. В данном контексте веса отражают число вызовов приложением методов соответствующего пакета API. Для любого ребра из доброкачественного или вредоносного приложения v в пакет API a обозначим через f(v, a) число вызовов приложением v методов из a. Следующие уравнения демонстрируют пять правдоподобных определений весовой функции w. Функции w_1, w_2 и w_3 представляют соответственно линейную, квадратичную и кубическую зависимости между частотой вызовов пакета API и весом ребра, а w_4 и w_5 описывают другие возможные нелинейные зависимости:

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

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

Взвешенные рёбра показаны на рисунке 6-1, где используется функция w_1, а направленные стрелки отображают отношения вызовов между парами пакетов API. Теперь можно заметить, что ни один из трёх доброкачественных образцов не вызывает пакет API android.app.admin, тогда как два из трёх банковских троянов вызывают его несколько раз. Подобные закономерности могут помочь выявлять вредоносные приложения.

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

Мы определяем 12 возможных функций оценки подозрительности, от sus_1 до sus_12. Наличие нескольких функций-кандидатов снижает склонность к переобучению заранее определённой модели. Когда эти оценки и другие признаки подаются на вход, методы машинного обучения могут определить, какая функция оценки подозрительности лучше всего отличает доброкачественные приложения от вредоносных. Можно заметить, что приведённые далее определения функций тесно связаны с весовыми функциями от w_1 до w_5:

Все эти функции оценки подозрительности используют индикаторную функцию I(v_1, v_2) для обозначения существования ребра из вершины v_1 в v_2, где v_1, v_2 ∈ A ∪ G ∪ M. Иными словами, если f(v_1, v_2) больше 0, то I(v_1, v_2) равна 1; в противном случае она равна 0. (Фактически функцию I(v, a) для рёбер из приложений в пакеты API можно рассматривать как ещё один вид весовой функции.) Через n мы обозначаем число вредоносных образцов, а через m - число доброкачественных образцов.

Например, согласно первой функции, sus_1, если пакет API a_j вызывается 100 вредоносными приложениями b и 10 доброкачественными приложениями g из наших выборок, мы обоснованно считаем приложения, вызывающие этот пакет API, более подозрительными, чем те, которые его не вызывают. Определение sus_7 - другой способ выразить ту же интуицию: функция API, которую вредоносные приложения вызывают активнее, чем доброкачественные, будет иметь более высокую оценку подозрительности. Уравнения от sus_7 до sus_12 основаны на предположениях, сходных с предположениями от sus_1 до sus_6, за исключением того, что они оценивают подозрительность одного пакета API относительно всех пакетов API, а не только относительно него самого.

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

Идею использования ориентиров можно применить для определения нового пространства признаков Android-приложений. Предположим, существует набор Android-приложений, включающий как доброкачественные, так и вредоносные приложения, и каждое приложение имеет некоторый вектор признаков. Этот вектор признаков можно рассматривать как точку в пространстве признаков приложений, подобно тому как дом можно охарактеризовать точкой в пространстве признаков жилья. Рассматривая покупку дома, мы сравниваем его с похожими домами; то же самое можно делать с приложениями, пытаясь определить, являются ли они вредоносными или доброкачественными.

Чтобы использовать подход на основе ориентиров, сначала выбираем подмножество образцов приложений и назначаем их ориентирами. Затем для каждого приложения определяем новые признаки в наборе данных, сравнивая его с каждым ориентиром. Мы рекомендуем сохранять размер набора ориентиров достаточно небольшим. Например, если общий набор приложений содержит 1 миллион образцов, можно выбрать 1 000 ориентиров. Тогда противникам будет трудно угадать выбранные ориентиры, что ещё сильнее затруднит угадывание признаков на основе ориентиров.

Мы предлагаем три метода выбора набора ориентиров из набора образцов. Первый, наивный подход, заключается в их случайном выборе. Другой метод - выбор на основе кластеризации, при котором приложения сначала группируются в кластеры. Существует множество хорошо изученных алгоритмов кластеризации, таких как кластеризация k-средних, кластеризация k-медиан, кластеризация со сдвигом среднего, пространственная кластеризация приложений с шумом на основе плотности (density-based spatial clustering of applications with noise, DBSCAN), кластеризация методом максимизации ожидания с использованием гауссовых смесевых моделей и агломеративная иерархическая кластеризация. Каждый алгоритм кластеризации имеет собственные преимущества и недостатки. Кроме того, из-за особенностей набора данных они могут показывать разные результаты.

При таком подходе после группирования приложений в кластеры из каждой группы выбирается одно приложение в качестве ориентира. Основная идея заключается в том, что при группировании всех приложений в кластеры похожие приложения оказываются в одном кластере, после чего из каждого кластера можно выбрать одно репрезентативное приложение. Возвращаясь к нашей аналогии с жильём, дома в одном кластере могут иметь похожие районы, местные школы, площадь, цены и количество спален. Решая, хорош ли дом, можно использовать по одному представителю каждого кластера в качестве ориентира. Получив кластеры, можно выбирать представителя каждой группы множеством способов. Например, можно случайным образом выбрать приложение из кластера. В качестве альтернативы можно вычислить сумму расстояний от каждого приложения в кластере до каждого из остальных приложений в этом кластере, а затем использовать в качестве ориентира приложение с наименьшей суммой - самое «центральное» приложение кластера. (Расстояние между двумя приложениями можно вычислить как расстояние между их векторами признаков с помощью такой метрики, как евклидово или косинусное расстояние.)

Поскольку можно использовать не менее 6 алгоритмов кластеризации и не менее 2 способов выбора приложения-ориентира из каждого кластера, существует по меньшей мере 12 способов выполнения выбора ориентиров на основе кластеризации, даже без учёта изменчивости гиперпараметров, внутренне используемых некоторыми методами кластеризации. В действительности способов выбора ориентиров на основе кластеризации гораздо больше, например за счёт изменения k в алгоритмах кластеризации k-средних и k-медиан.

Третий метод, эвристический выбор по максимальному расстоянию, предоставляет алгоритм выбора ориентиров, рассеянных по базовому пространству признаков. На вход он принимает набор приложений D, число выбираемых ориентиров N_L, а также функцию расстояния d, используемую для оценки расстояния между двумя образцами приложений на основе их векторов признаков. Например, можно использовать такие известные функции расстояния, как евклидово расстояние, манхэттенское расстояние, косинусное расстояние или расстояние Хэмминга. Алгоритм имеет следующий вид:

1. Случайным образом выбрать приложение из D и добавить его в набор ориентиров L′.

2. Если |L′| < N_L, извлечь из D - L′ случайный набор приложений R.

3. Выбрать лучший ориентир из R одним из следующих методов:

4. Добавить выбранный ориентир в L′.

5. Когда |L′| = N_L, использовать L′ в качестве набора ориентиров L.

Алгоритм начинает со случайного выбора приложения из D в качестве ориентира и добавления его в текущий набор выбранных ориентиров L′ (шаг 1). Затем он итеративно добавляет новые ориентиры (шаги 2-4). На каждой итерации из D - L′ случайным образом извлекается набор приложений (шаг 2), после чего выбирается приложение, наиболее удалённое от текущего набора ориентиров L′ (шаг 3).

Расстояние можно вычислять различными способами. Например, предположим, что на некоторой итерации алгоритма имеются 3 ориентира ℓ_1, ℓ_2, ℓ_3, а D - L′ содержит 100 ориентиров ℓ′_1, ℓ′_2, ..., ℓ′_100. В этом случае любой из 100 ориентиров можно добавить в L′ в качестве четвёртого. Можно добавить ориентир ℓ′_j, который максимизирует расстояние от кандидата на роль четвёртого ориентира в D - L′ до ранее выбранных ориентиров в L′, иными словами максимизирует сумму Σ_(i=1)^3 d(ℓ_i, ℓ′_j). В качестве альтернативы можно выбрать в качестве четвёртого ориентира элемент D - L′, максимизирующий либо среднее, либо медианное расстояние до ранее выбранных ориентиров ℓ_1, ℓ_2, ℓ_3, например выбрав ℓ_j = arg max_(ℓ′_i) mean({d(ℓ′_i, ℓ_1), d(ℓ′_i, ℓ_2), d(ℓ′_i, ℓ_3)}). В этом алгоритме d является функцией расстояния. Через d(ℓ, r) мы обозначаем расстояние между векторами признаков двух приложений ℓ и r. Этот шаг гарантирует, что выбранный ориентир достаточно удалён от ранее выбранных ориентиров, обеспечивая некоторое разнообразие набора ориентиров.

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

Три описанных нами метода выбора ориентиров предоставляют множество способов выбора набора ориентиров L из набора D для каждого значения N_L. Однако, чтобы ещё сильнее запутать потенциальных противников, мы рекомендуем специалистам по безопасности периодически использовать новый набор ориентиров, изменять метод выбора ориентиров или делать и то и другое, а затем заново вычислять признаки на основе ориентиров. Выполняя это раз в одну-две недели, вы заставите любого противника гадать и создадите защиту с движущейся целью.

Выбрав ориентиры, мы используем их для вычисления признаков на основе ориентиров для каждого образца приложения i из набора D. Ниже приведён алгоритм создания признаков на основе ориентиров:

1. Создать набор ориентиров L с помощью S.

2. Для каждого ориентира ℓ ∈ L в каждом образце приложения i ∈ D вычислить d(i, ℓ).

3. Вычислить признаки следующим образом:

В качестве входных данных используются набор Android-приложений D со связанными с ними векторами признаков F = {f⃗_i}_i, число выбираемых ориентиров N_L, метод выбора ориентиров S (и его параметры, если применимо) и функция расстояния d(·).

Мы создаём набор ориентиров L с помощью S (шаг 1). Затем итеративно вычисляем векторы признаков ориентиров для каждого образца приложения i (шаги 2 и 3). Этот процесс начинается с вычисления расстояния d(i, ℓ) от образца i до каждого ℓ ∈ L, после чего из этих расстояний строится N_L-мерный вектор признаков на основе ориентиров. Иными словами, первый элемент этого вектора является расстоянием между приложением i и первым ориентиром, второй элемент - расстоянием между приложением i и вторым ориентиром и так далее.

Рисунок 6-3 представляет собой простую иллюстрацию признаков на основе ориентиров. Предполагается, что в наборе D имеется шесть образцов (на практике это число было бы гораздо больше), каждый из которых имеет четырёхмерный вектор признаков API.

Рисунок 6-3. Признаки на основе ориентиров для шести приложений, двух ориентиров и евклидовой функции расстояния

Предположим, что методом случайного создания ориентиров в качестве ориентиров выбраны два из шести образцов - Perfect Girls и Marcher. Затем мы создаём признаки на основе ориентиров с помощью евклидовой функции расстояния. Здесь можно увидеть евклидово расстояние от каждого образца приложения i до каждого ориентира. Тогда вектор признаков на основе ориентиров, например для Regon, равен (3551,33, 677,93), а для Perfect Girls - (0, 2903,66).

Некоторые создаваемые нами признаки могут иметь сходные отношения с меткой, которую мы пытаемся предсказать. В таком случае эти признаки можно объединить, чтобы создать меньший, но, возможно, более репрезентативный набор новых признаков. Подход, называемый кластеризацией признаков, сначала группирует набор базовых признаков в ряд категорий, а затем получает агрегированные признаки из каждой категории. Эти новые признаки мы называем признаками FC. Подробнее об этом подходе можно прочитать в работе «Android Malware Detection via (Somewhat) Robust Irreversible Feature Transformations» Цяня Ханя и соавторов.

Для получения признаков FC мы используем следующий алгоритм:

1. Взять из D подмножество образцов D′.

2. Получить матрицу признаков F′ для образцов из D′.

3. С помощью Clu сгруппировать n базовых признаков в G групп в соответствии с векторами столбцов {f_ij}_i′ в F′.

4. Для каждой группы признаков F_g в каждом образце приложения i сопоставить группе значение:

5. Выполнить это вычисление для каждого образца приложения:

В качестве входных данных алгоритм принимает набор D всех образцов Android-приложений и n-мерный базовый вектор признаков каждого из них; число кластеров G, на которые требуется разделить n признаков; используемый алгоритм кластеризации Clu; а также ⊕ - алгоритм агрегирования признаков внутри одной группы. Можно использовать любое подмножество или все представленные нами базовые признаки статического и динамического анализа, а также признаки, определённые другими исследователями.

Мы извлекаем подмножество образцов приложений D′ из D (шаг 1) и используем значения их признаков (шаг 2), чтобы сгруппировать n признаков в G групп (шаг 3). Мы используем подмножество D, а не сам набор D, по трём причинам. Во-первых, набор данных может быть огромным и кластеризация всего набора может оказаться очень затратной. Во-вторых, использование подмножества образцов для кластеризации затрудняет противнику определение принципа работы кластеризации признаков. В-третьих, когда набор D расширяется за счёт добавления новых приложений, признаки FC новых приложений можно вычислить без повторного запуска алгоритма и новой кластеризации базовых признаков. Более того, как и в случае TSG, можно периодически обновлять используемую выборку и повторно вычислять кластеры признаков, заставляя противников гадать о характере применяемой защиты.

После кластеризации признаков мы берём любое приложение и с помощью ⊕ сопоставляем каждому кластеру признаков одно значение (шаг 4). Это значение может быть суммой, минимумом или максимумом значений признаков внутри данного кластера либо статистической величиной, полученной из набора, например медианой, стандартным отклонением, дисперсией или энтропией. Мы выполняем это действие для всех кластеров в каждом приложении из D (шаг 5).

Алгоритм кластеризации признаков можно вызывать со множеством возможных методов кластеризации и агрегирования признаков. В качестве алгоритма кластеризации можно использовать любой из шести методов, упомянутых при обсуждении признаков на основе ориентиров, или совершенно другой алгоритм. Для алгоритма агрегирования признаков ⊕ также можно выбрать один из множества вариантов. Ниже приведены некоторые возможности:

Произведение. Новый признак вычисляется как произведение элементов набора.

Среднее. В качестве значения нового признака используется среднее значение набора значений.

Медиана. В качестве значения нового признака используется медианное значение набора значений.

Сумма. Новый признак вычисляется как сумма элементов набора.

Взвешенная сумма. Значение нового признака вычисляется как взвешенная сумма элементов набора. Вес признака j обратно пропорционален расстоянию между вектором признака и вектором значения центроидного признака группы j_c, {f_ijc}_i′, которое мы обозначаем через d(j, j_c). Таким образом, значение признака вычисляется следующим образом, где α - параметр нормализации:

Обычно выбирается размер кластера G, значительно меньший общего числа признаков, чтобы это число резко сократилось. Например, если базовый вектор признаков содержит 100 элементов, можно установить G равным 8. На рисунке 6-4 показан пример кластеризации признаков с использованием образцов приложений и четырёхмерных признаков API.

Рисунок 6-4. Пример кластеризации признаков с двумя группами, четырёхмерными базовыми признаками API и агрегированием признаков посредством усреднения

В этом примере мы кластеризуем четыре приложения в две группы и используем для ⊕ подход со средним значением. Получаем показанные в таблице справа признаки FC для каждого приложения.

Будучи весьма репрезентативными, признаки FC в то же время трудны для угадывания противниками, поскольку при их создании специалистам по безопасности приходится делать несколько вариантов выбора, которые вносят в процесс значительную неопределённость и плохо поддаются обратному проектированию. Эти варианты включают используемое подмножество образцов приложений, число создаваемых кластеров, метод кластеризации и его гиперпараметры, а также оператор агрегирования ⊕ (вместе с его гиперпараметрами, когда ⊕ вычисляет взвешенную сумму).

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

Для выполнения преобразования признаков на основе корреляционного графа мы используем следующий алгоритм:

1. Взять из D подмножество образцов D′.

2. Получить матрицу признаков F′ для образцов из D′.

3. Вычислить n × n весов рёбер корреляционного графа в соответствии с векторами столбцов F′.

4. Получить G сообществ из n базовых признаков в соответствии с корреляционным графом и алгоритмом обнаружения сообществ.

5. Для каждого сообщества признаков C_g в каждом образце приложения i применить оператор агрегирования:

6. Для каждого образца приложения i вычислить его вектор признаков CG:

В качестве входных данных алгоритм принимает набор приложений D, матрицу признаков этих приложений F, алгоритм обнаружения сообществ C, требуемое число сообществ G и ассоциативный и коммутативный оператор ⊕. На выходе получается корреляционный граф с G-мерными векторами признаков для образцов приложений из D.

Мы начинаем с выбора подмножества образцов приложений D′ из D (шаг 1) и извлечения их матрицы признаков F′ (шаг 2), как и при вычислении признаков FC. Затем вычисляем корреляцию между каждой парой признаков с помощью коэффициента корреляции Пирсона (шаг 3). Это значение становится весом ребра между каждой парой признаков в корреляционном графе.

Затем мы применяем алгоритм обнаружения сообществ C (шаг 4), чтобы получить G сообществ. Наконец, мы создаём признаки CG для каждого приложения D, используя признаки в каждом сообществе и ассоциативный и коммутативный оператор агрегирования признаков ⊕ (шаги 5 и 6).

Оператор ⊕ можно определить теми же пятью способами, что и при кластеризации признаков. Кроме того, можно выбрать множество возможных алгоритмов обнаружения сообществ C, включая метод минимального разреза, алгоритм Гирвана - Ньюмана, максимизацию модулярности, статистический вывод и методы на основе клик. Подробнее об этих алгоритмах можно прочитать в источниках, перечисленных в разделе «Дополнительная литература».

На рисунке 6-5 показан пример создания признаков на основе корреляционного графа. Предположим, требуется сгруппировать четыре признака API в два сообщества, как показано в левой части рисунка. В правой части можно увидеть признаки CG для каждого образца приложения, созданные с помощью метода агрегирования признаков посредством усреднения.

Рисунок 6-5. Создание признаков CG с двумя сообществами и методом агрегирования признаков посредством усреднения

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

Чтобы показать, чем признаки вредоносных программ для получения root-прав отличаются от признаков доброкачественных приложений, мы воспользуемся семейством вредоносных программ Rootnik. Rootnik доставляет свою вредоносную программу для получения root-прав через различные приложения, например com.web.sdfile (v2, f214), которые якобы управляют документами, видео, изображениями, музыкой и другими файлами на устройстве пользователя. После установки приложение связывается с сервером управления и контроля, откуда по своему усмотрению загружает код для выполнения длинного перечня вредоносных действий: от отправки порнографии и рекламы на устройство до скрытой установки новых приложений. Оно встраивается в самые разные легитимные приложения, а после получения root-прав на устройстве похищает сведения Wi-Fi, включая пароли и ключи, местоположение пользователя и MAC-адрес устройства.

Рисунок 7-1. 20 важнейших признаков, лучше всего отличающих вредоносные программы Android для получения root-прав от доброкачественных программ

В этом разделе мы рассмотрим набор из 1 829 хешей Rootnik. Из них 444 являются различными в том смысле, что приводят к разным векторам признаков того типа, который обсуждался в главах 5 и 6. Мы рассмотрим 20 признаков, лучше всего отличающих вредоносные программы для получения root-прав от доброкачественных программ при использовании классификатора Extra-Trees (сокращение от extremely randomized trees, чрезвычайно рандомизированные деревья, варианта классификатора случайного леса), который случайным образом выбирает несколько подмножеств обучающего набора, обучает дерево решений для каждого подмножества, а затем агрегирует деревья решений. Эти признаки показаны на рисунке 7-1.

В их число входят девять статических признаков, связанных с разрешениями, статический признак на основе метода sendnet, статический признак вызова API, шесть признаков оценки подозрительности, два признака ранга подозрительности и один признак корреляционного графа. Метод sendnet будет подробнее объяснён далее в этой главе.

В листинге 7-1 показаны все разрешения, запрашиваемые Rootnik в файле манифеста приложения.

Листинг 7-1. Все разрешения, запрашиваемые Rootnik

Приложения запрашивают привилегированное разрешение INSTALL_PACKAGES, когда хотят устанавливать другие пакеты или приложения во время выполнения. На протяжении многих лет разработчики вредоносных программ пытались использовать его для установки новых пакетов из сторонних источников. Одно из больших преимуществ этого разрешения заключается в возможности устанавливать приложения без согласия пользователя, в отличие от его непривилегированного аналога REQUEST_INSTALL_PACKAGES. Затем приложения, установленные из сторонних источников, могут запрашивать произвольные разрешения и становиться плацдармом для ещё более вредоносных атак. Результаты классификатора показывают, что это разрешение запрашивают 20,27 процента вредоносных программ для получения root-прав и только 0,22 процента доброкачественных программ. Это ожидаемо, поскольку привилегированное разрешение доступно только приложениям, уже успешно повысившим уровень своих привилегий выше уровня обычных приложений.

Разрешение GET_PACKAGE_SIZE позволяет приложению получать размер пакетов других приложений. Из результатов классификатора видно, что это разрешение запрашивают 30,75 процента вредоносных программ для получения root-прав и лишь 1,86 процента доброкачественных программ. Исторически Android использовала разрешение GET_PACKAGE_SIZE для защиты только одного Android API (PackageManager.getPackageSizeInfo), который был удалён в Android 8.0 (Oreo). Выборочная проверка нескольких приложений для получения root-прав показала, что хотя они запрашивают это разрешение, они, по-видимому, его не используют.

Разрешение KILL_BACKGROUND_PROCESSES позволяет Android-приложению завершать процессы, без видимых проявлений работающие в фоновом режиме. Приложения могут запрашивать это разрешение как по легитимным, так и по вредоносным причинам. Например, доброкачественному приложению оно может понадобиться для освобождения системных ресурсов, когда другое приложение работает в фоне, но активно не используется. С другой стороны, вредоносные приложения могут запрашивать это разрешение, чтобы завершать работающие в фоне процессы безопасности. Можно видеть, что это разрешение запрашивают 28,33 процента вредоносных программ для получения root-прав, но только 2,04 процента доброкачественных программ.

Ещё одно важное разрешение - GET_TASKS. Хотя в 2014 году оно было объявлено устаревшим, оно позволяет приложению определять процессы, работающие на устройстве. Как видно из результатов классификатора, это разрешение запрашивают 67,81 процента вредоносных программ для получения root-прав и всего лишь 13,57 процента доброкачественных программ. Таким образом, приложение, запрашивающее его, почти в пять раз чаще оказывается вредоносной программой для получения root-прав, чем доброкачественной программой. Android значительно ограничила эту возможность, чтобы дополнительно улучшить изоляцию приложений в песочнице.

Приложения запрашивают разрешение MOUNT_UNMOUNT_FILESYSTEMS, чтобы монтировать или размонтировать файловые системы устройства. Это также позволяет им добавлять новые файлы, удалять или изменять файлы в ранее ограниченных частях устройства. Такое разрешение часто используется для размещения исполняемого файла BusyBox в каталоге /system/bin. Поскольку BusyBox предоставляет множество стандартных команд Linux в одном исполняемом файле, это удобный способ получить на устройстве с root-правами множество стандартных возможностей вредоносных программ без необходимости загружать, копировать и устанавливать слишком много отдельных исполняемых файлов. Затем вредоносная программа может использовать эти возможности по мере необходимости. Вероятность запроса разрешения MOUNT_UNMOUNT_FILESYSTEMS вредоносной программой для получения root-прав составляет 42,65 процента, тогда как для доброкачественной программы - 4,21 процента, поскольку непривилегированные приложения вообще не могут использовать это разрешение.

Разрешение SYSTEM_ALERT_WINDOW позволяет приложению отображать всплывающие окна предупреждений, даже когда приложение в данный момент не используется, что создаёт очевидные и широкие возможности для злоупотреблений посредством фишинга. Мы не встречали случаев такого неправильного использования в приложениях для получения root-прав, однако многие вредоносные программы для получения root-прав могут встраивать свой код в доброкачественные приложения, которые используют это разрешение для обычной работы. Вредоносные программы для получения root-прав запрашивают этот признак гораздо чаще доброкачественных программ (53,76 процента против 11,13 процента).

Разрешение RECEIVE_BOOT_COMPLETED позволяет приложению узнать, когда система завершила загрузку или перезагрузку. И доброкачественные, и вредоносные приложения могут использовать это широковещательное сообщение для запуска после завершения загрузки. Результаты классификатора показывают, что это разрешение запрашивают 66,41 процента вредоносных программ для получения root-прав и 24,38 процента доброкачественных программ. По-видимому, вредоносные программы чаще хотят запускаться сразу после перезагрузки, чем доброкачественные, которые обычно запускаются лишь тогда, когда пользователь хочет с ними взаимодействовать.

Вредоносные приложения также часто запрашивают разрешения READ_PHONE_STATE и ACCESS_WIFI_STATE. Доброкачественные приложения могут использовать первое из них для получения номера IMEI телефона и сведений о видах сетей, к которым подключён телефон. Например, мобильным платёжным приложениям могут понадобиться сведения такого рода для проверки личности устройства, отправляющего платёжный запрос. Вредоносные программы могут использовать это разрешение для захвата конфиденциальных сведений о телефоне жертвы и запрашивают его более чем вдвое чаще: разрешение READ_PHONE_STATE запрашивают 35,98 процента доброкачественных программ и 83,01 процента вредоносных программ для получения root-прав. Аналогичным образом злоумышленники могут использовать ACCESS_WIFI_STATE для захвата идентификаторов набора служб Wi-Fi (SSID). Это разрешение запрашивают 80,57 процента вредоносных программ для получения root-прав, тогда как вероятность его запроса доброкачественной программой вдвое ниже (40,02 процента).

Помимо признаков, связанных с разрешениями, выявлять вредоносные программы для получения root-прав алгоритмам машинного обучения помогают признаки, связанные с сетевыми коммуникациями приложения. Например, статическому признаку sendnet присваивается количество вызовов методом sendnet в коде приложения для отправки данных через интернет. Сведения такого рода можно собирать, запуская Android-приложение в среде песочницы Android под названием DroidBox, которая позволяет безопасно запускать Android-приложения и собирать динамические признаки того вида, который упоминался в главе 6. В листинге 7-2 показан вызов sendnet вредоносной программой Rootnik.

Листинг 7-2. Метод sendnet, используемый Rootnik для отправки данных через интернет

Вывод DroidBox показывает, что Rootnik отправляет трафик на внешний URL abc.jxyxteam.com, который, вероятно, принадлежит сайту, управляемому разработчиками вредоносной программы.

Значение признака sendnet гораздо чаще превышает ноль у вредоносных программ для получения root-прав, чем у доброкачественных программ. Результаты классификатора показывают, что этот метод используют 7,65 процента вредоносных программ и всего 0,057 процента доброкачественных программ, то есть вероятность его использования вредоносным приложением для получения root-прав примерно в 134 раза выше, чем доброкачественным.

Другой признак, используемый для отделения вредоносных программ для получения root-прав от доброкачественных, - org.apache.http.conn.scheme, который отражает количество вызовов протоколов HTTP или HTTPS кодом приложения. Вредоносные программы для получения root-прав вызывают этот признак гораздо чаще доброкачественных (33,27 процента против всего лишь 1,59 процента). В листинге 7-3 можно увидеть, как вредоносная программа Rootnik для получения root-прав вызывает API org.apache.http.conn.scheme.

Листинг 7-3. API org.apache.http.conn.scheme, вызываемый в Rootnik

Следует помнить, что в использовании этого метода нет ничего изначально вредоносного: он может поддерживать как доброкачественный, так и вредоносный трафик.

Теперь обсудим признаки, лучше всего отличающие вредоносные программы для получения root-прав от других форм вредоносных программ. На рисунке 7-2 показаны 20 наиболее сильных признаков для этой цели, выявленных классификатором Extra-Trees.

В их число входят 10 признаков, связанных с разрешениями, 8 признаков оценки или ранга подозрительности, 1 признак, связанный с API, и 1 признак на основе ориентиров. В этом разделе мы рассмотрим некоторые основные моменты. Поскольку вредоносные программы для получения root-прав гораздо больше похожи на другие формы вредоносных программ, чем на доброкачественные программы, обсуждаемые здесь различия меньше.

Десять разрешений помогают классификатору Extra-Trees отделять вредоносные программы для получения root-прав от других вредоносных программ. Первое - GET_PACKAGE_SIZE. Приложения, запрашивающие это разрешение, гораздо чаще оказываются вредоносными программами для получения root-прав, чем другими формами вредоносных программ: его запрашивают 30,15 процента вредоносных программ для получения root-прав и только 7,83 процента других вредоносных программ. Однако сам факт запроса этого разрешения некоторыми приложениями необязательно является вредоносным.

Следующие четыре разрешения - MOUNT_UNMOUNT_FILESYSTEMS, GET_TASKS, ACCESS_WIFI_STATE и INSTALL_PACKAGES - также входили в число 20 признаков, наиболее полезных для отделения вредоносных программ для получения root-прав от доброкачественных программ. Ещё два разрешения, которые вредоносные программы для получения root-прав запрашивают немного чаще других вредоносных программ, - READ_LOGS и RESTART_PACKAGES. Разрешение READ_LOGS предоставляет привилегированным приложениям доступ ко всем системным журналам, а непривилегированным приложениям - только к собственным журналам; RESTART_PACKAGES объявлено устаревшим начиная с API 15. Во всех этих случаях различия между долями вредоносных программ для получения root-прав и других видов вредоносных программ, запрашивающих разрешения, невелики, и использование любого из этих

Рисунок 7-2. 20 важнейших признаков, лучше всего отличающих вредоносные программы Android для получения root-прав от других форм вредоносных программ

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

Наконец, мы уже видели, что READ_PHONE_STATE и RECEIVE_BOOT_COMPLETED были важны для отделения вредоносных программ для получения root-прав от доброкачественных программ. Любопытно, что рисунок 7-2 показывает: вредоносные программы для получения root-прав немного реже запрашивают эти разрешения, чем другие формы вредоносных программ, которые могут использовать их для запуска при каждой перезагрузке системы или захвата сведений IMSI и IMEI об устройстве.

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

Здесь также полезен признак API org.apache.http.conn.scheme, который отражает количество вызовов протоколов HTTP или HTTPS в коде приложения. Хотя 63,27 процента вредоносных программ для получения root-прав выполняют в своём коде хотя бы один вызов одного из этих протоколов, другие формы вредоносных программ используют библиотеки Apache гораздо реже (хотя для той же цели они могут применять другие библиотеки). Этот класс представляет ряд протоколов и описывает свойства протокола, например используемый сокет.

На рисунке 8-1 показаны 25 важнейших признаков для отделения шпионских программ Android от доброкачественных программ с помощью классификатора случайного леса (обсуждавшегося в главе 5).

Рисунок 8-1. 25 важнейших признаков, лучше всего отличающих шпионские программы Android от доброкачественных программ

Как можно видеть, 14 из этих признаков связаны с разрешениями, 4 являются статическими, а 2 - динамическими. В нашем обсуждении мы сосредоточимся на признаках, связанных с разрешениями.

Многие из важнейших признаков для отделения шпионских программ от доброкачественных связаны с разрешениями, причём четыре из них относятся к возможностям SMS. Разрешения SEND_SMS, RECEIVE_SMS, WRITE_SMS и READ_SMS позволяют шпионским программам получать и читать сообщения (например, от банков и интернет-магазинов), чтобы собирать сведения, которые приложения впоследствии могут отправить в свой центр управления и контроля. Когда сведения попадают в центр управления и контроля, разработчики вредоносных программ могут продавать их в интернете и (или) использовать для совершения различных видов мошенничества, например мошенничества с кредитными картами или банковского мошенничества. Кроме того, разрешения WRITE_SMS и SEND_SMS можно использовать, например, для записи и отправки фишинговых URL с телефона владельца устройства его контактам с целью заражения их устройств. Вероятность запроса этих четырёх разрешений шпионскими программами гораздо выше вероятности запроса тех же разрешений доброкачественными программами.

Размер файла также является важным фактором. Из рисунка 8-1 видно, что шпионские программы обычно гораздо меньше доброкачественных. Мы предполагаем, что это связано с тем, что шпионским программам требуется меньше занимающих много места ресурсов, например мультимедийных материалов высокого разрешения, часто необходимых легитимным приложениям. Кроме того, шпионские программы могут использовать меньше сторонних SDK, что дополнительно уменьшает размер их файлов.

Как упоминалось в предыдущей главе, разрешение READ_PHONE_STATE позволяет злоумышленникам захватывать такие сведения об устройстве, как номера IMEI и IMSI. Вероятность запроса этих разрешений шпионскими программами более чем вдвое выше, чем доброкачественными программами. Эти значения могут быть особенно полезны при продаже и покупке похищенных данных, поскольку уникальность таких аппаратных идентификаторов делает их удобными первичными ключами для объединения наборов данных из разных источников.

Аналогичным образом шпионские программы запрашивают разрешение GET_TASKS более чем втрое чаще доброкачественных программ. Это разрешение, с которым мы встретились в предыдущей главе, позволяет приложению видеть процессы, работающие на устройстве. Например, оно может использовать его для обнаружения процессов, связанных с антивирусными программами, или отслеживания данных об использовании приложений, чтобы собирать и продавать их специалистам по маркетингу. Однако следует учитывать, что это разрешение объявлено устаревшим начиная с Android 5.0 (Lollipop) и потому на момент написания книги вряд ли оказывает какое-либо влияние.

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

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

На рисунке 8-1 показаны ещё несколько важных разрешений, которые шпионские программы запрашивают чаще доброкачественных, а также следующие признаки:

num_std_permissions. Число разрешений, определённых официальными руководствами для разработчиков Android и объявленных в манифесте, независимо от того, считаются они опасными или нет.

num_std_permissions_dangerous. Число разрешений, считающихся опасными, поскольку они предоставляют приложениям расширенный доступ к ограниченным данным или позволяют выполнять ограниченные действия.

num_non_std_permissions. Число объявленных в манифесте разрешений, определённых источниками, отличными от официального Android SDK.

В таблице 8-1 показана эффективность различных классификаторов машинного обучения при прогнозировании того, является ли приложение шпионской или доброкачественной программой, для разных наборов признаков.

Таблица 8-1. Показатели оценки шпионских и доброкачественных программ Android

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

Как можно видеть, позднее слияние с использованием классификатора XGBoost обеспечивает превосходные результаты, практически не допуская ошибок на данных, использованных при тестировании. Это удивительно: почти никакие алгоритмы машинного обучения не обеспечивают 100-процентную эффективность.

Теперь перейдём к вопросу о том, чем шпионские программы отличаются от других форм вредоносных программ. На рисунке 8-2 показаны 25 важнейших признаков, используемых для этой цели.

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

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

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

Важное разрешение, не рассматривавшееся в предыдущих главах, ACCESS_FINE_LOCATION, предоставляет чрезвычайно ценные сведения. Приложение с этим разрешением обычно способно определить местоположение жертвы с точностью до нескольких метров. Злоумышленники могут использовать эти сведения для множества целей. Например, они могут построить модель дней недели и времени, когда жертва обычно находится в определённом месте (скажем, в конкретной кофейне по понедельникам с 11:00 до 12:00 или на совещании в здании B в кампусе Google по четвергам с 15:00 до 16:00). Они также могут определить, какие магазины посещают жертвы, и на этой основе решить, являются ли те подходящими целями: например, пользователь, заходящий в относительно дорогие магазины, такие как Whole Foods, Nordstrom и Neiman Marcus, может привлечь больше внимания, поскольку выглядит состоятельнее человека, главным образом посещающего магазины повседневного спроса вроде 7-Eleven. Мы считаем, что такие подробные сведения о местоположении людей являются самыми востребованными данными на рынках данных.

Рисунок 8-2. 25 важнейших признаков, лучше всего отличающих шпионские программы Android от других вредоносных программ

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

Разрешения READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE запрашиваются шпионскими и другими вредоносными программами почти с одинаковой частотой. Эти разрешения позволяют вредоносным программам читать данные с SD-карты устройства, где другие приложения хранят потенциально конфиденциальные файлы, и записывать данные на неё. Одно особенно интересное применение WRITE_EXTERNAL_STORAGE, которое мы наблюдали, встречается в расширенном шпионском приложении и трояне Claco: оно сохраняет файлы на SD-карте в надежде заразить системы Windows, подключённые к Android-устройству через USB. Следует отметить, что после появления изолированного хранилища в Android 10 большинство ранее доступных конфиденциальных файлов больше не должно быть доступно непривилегированным шпионским приложениям.

В предыдущей главе мы обсуждали важное разрешение KILL_BACKGROUND_PROCESSES. Шпионские программы могут использовать его для завершения фоновых процессов, принадлежащих определённому приложению, например антивирусу. Наконец, некоторые признаки, помогающие отделять шпионские программы от доброкачественных, также помогают отделять шпионские программы от других вредоносных программ. К ним относятся разрешения SYSTEM_ALERT_WINDOW, MOUNT_UNMOUNT_FILESYSTEMS, READ_PHONE_STATE и ACCESS_NETWORK_STATE, а также такие признаки, как filesize, num_std_permissions и num_non_std_permissions. Количество запрашиваемых опасных разрешений, являющееся важнейшим признаком для отделения шпионских программ от доброкачественных, по-видимому, менее важно при отделении шпионских программ от других форм вредоносных программ.

В таблице 8-2 показана прогностическая эффективность классификаторов машинного обучения при решении задачи отделения шпионских программ от других форм вредоносных программ.

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

Таблица 8-2. Показатели оценки шпионских и других вредоносных программ Android

На рисунке 9-1 показаны 20 важнейших признаков для отделения ABT от доброкачественных программ с помощью классификатора Extra-Trees, обсуждавшегося в главе 7.

Девять из этих признаков связаны с разрешениями, а ещё девять являются расширенными признаками, связанными с оценками подозрительности, рангами подозрительности и кластеризацией признаков. Только два относятся к конкретным видам вызовов API.

Вы сразу должны заметить, что разрешения SEND_SMS, RECEIVE_SMS, WRITE_SMS и READ_SMS, связанные с SMS, играют огромную роль в отделении ABT от доброкачественных программ. Таблица 9-1 показывает, что практически каждое семейство вредоносных программ, обсуждавшееся ранее в этой главе, запрашивает все эти разрешения, за двумя исключениями: BankBot не запрашивает READ_SMS, а Xbot не запрашивает WRITE_SMS.

Таблица 9-1. Разрешения, связанные с SMS, запрашиваемые основными семействами ABT

Результаты классификатора показывают, что доля ABT, запрашивающих эти разрешения, очень высока: от 70 до 85 процентов против менее 5 процентов доброкачественных программ. Причина проста: большинство банковских приложений реализуют двухфакторную аутентификацию посредством кода, отправляемого на телефон пользователя, поэтому ABT должны перехватить такие сообщения, чтобы пройти аутентификацию перед попыткой совершить какое-либо мошенническое действие.

Рисунок 9-1. 20 важнейших признаков, лучше всего отличающих ABT от доброкачественных программ

ABT также запрашивают множество разрешений, не связанных с SMS. В качестве примера в листинге 9-1 показан список разрешений, запрашиваемых вредоносной программой BankBot com.interactive.crutch (v1, 9b14).

Листинг 9-1. Все разрешения, запрашиваемые BankBot

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

Более 90 процентов ABT запрашивают READ_PHONE_STATE - разрешение, также распространённое среди вредоносных программ для получения root-прав, тогда как среди доброкачественных программ его запрашивают около 30 процентов. ABT могут использовать это разрешение для захвата конфиденциальных данных о телефоне жертвы, например номера IMEI. Как упоминалось в главе 7, сведения такого рода критически важны для мобильных платёжных приложений, которым требуется проверять личность устройства, отправляющего платёжный запрос. За исключением Cerberus, это разрешение запрашивают все семейства ABT, обсуждавшиеся ранее в этой главе.

Ещё одно разрешение, популярное среди вредоносных программ для получения root-прав и часто запрашиваемое ABT, - SYSTEM_ALERT_WINDOW: его запрашивают более 60 процентов ABT, тогда как среди доброкачественных программ - около 10 процентов. Предоставление приложению этого разрешения позволяет ему отображать всплывающие окна предупреждений. Эта функция имеет очевидную ценность для ABT: она позволяет показывать поддельные экраны банковских приложений поверх настоящих банковских приложений. Из семи ABT, обсуждавшихся ранее в этой главе, это разрешение запрашивают FakeSpy, Medusa, Xbot и Zitmo, а BankBot, Cerberus и Marcher его не запрашивают.

Разрешение GET_TASKS позволяет приложению определять процессы, работающие на устройстве. Как видно из результатов классификатора, ABT запрашивают это разрешение гораздо чаще доброкачественных программ: почти 80 процентов ABT против примерно 15 процентов доброкачественных программ. Наш опыт показывает, что многие банковские трояны запрашивают разрешение GET_TASKS, чтобы отслеживать запуск легитимных банковских приложений и в нужный момент накладывать свои фишинговые окна. Именно по этой причине Android значительно ограничила эту возможность. Из семи семейств ABT, упомянутых ранее в этой главе, это разрешение запрашивают FakeSpy, Marcher, Medusa и Xbot.

Разрешение, которое ABT запрашивают часто, а вредоносные программы для получения root-прав - нет, называется CHANGE_NETWORK_STATE и позволяет приложению подключаться к сети Wi-Fi. Его запрашивают более 40 процентов ABT против менее 5 процентов доброкачественных программ. Из представленных ранее семейств ABT это разрешение запрашивают Marcher, Medusa, Xbot и Zitmo. Любопытно, что мы не наблюдали использования этого разрешения другими ABT для выполнения вредоносных задач.

Разрешение RECEIVE_BOOT_COMPLETED - ещё одно разрешение, которое мы обсуждали в контексте вредоносных программ для получения root-прав. Оно позволяет приложению узнать, что устройство завершило процесс загрузки. ABT может захотеть получить это уведомление, чтобы запуститься сразу после начала работы устройства и продолжить отслеживать SMS-трафик или ждать, пока пользователь запустит банковское приложение. Это разрешение запрашивают все семь семейств ABT, упомянутых ранее в этой главе.

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

Насколько эффективно классификаторы предсказывают, что приложение является ABT, а не доброкачественной программой или другой формой вредоносных программ? Результаты в таблице 9-2 показывают нашу способность делать такие прогнозы при сравнении приложений с доброкачественными программами. Строки этой таблицы показывают используемые виды признаков: базовые признаки API, статические и динамические признаки; расширенные признаки на основе TSG, ориентиров, кластеризации признаков и корреляционного графа; а также комбинации этих видов.

Таблица 9-2. Показатели оценки ABT и доброкачественных программ

Алгоритмы машинного обучения способны с высокой эффективностью отделять ABT от доброкачественных программ: лучший результат позднего слияния обеспечивает оценку F1 0,9819, точность 0,9905 и полноту 0,9736. Это отличные показатели, свидетельствующие о том, что большинство приложений, классифицированных как ABT, действительно являются ABT, а классификаторы обнаружили большинство ABT в наборе приложений.

На рисунке 9-2 показаны 20 важнейших признаков для отделения ABT от других форм вредоносных программ.

В данном случае 14 из 20 признаков связаны с разрешениями. Тринадцать из них представляют разрешения, запрашиваемые приложением, а один признак указывает число запрашиваемых опасных разрешений. Остальные шесть являются расширенными признаками.

Как и при отделении ABT от доброкачественных программ, наиболее важны разрешения, связанные с SMS. Мы видим, что доля ABT, запрашивающих разрешение RECEIVE_SMS, более чем вдвое превышает долю других форм вредоносных программ. То же самое относится к WRITE_SMS и READ_SMS, вероятно, потому, что другим формам вредоносных программ, например программам-вымогателям, может быть не нужно отслеживать сообщения двухфакторной аутентификации, отправляемые банками, и отвечать на них.

Рисунок 9-2. 20 важнейших признаков, лучше всего отличающих ABT от других вредоносных программ

В таблице 9-3 показаны четыре разрешения, не связанные с SMS, которые ABT запрашивают чаще других форм вредоносных программ, а также указано, какие из обсуждавшихся ранее в этой главе ABT их используют.

Таблица 9-3. Разрешения, не связанные с SMS, запрашиваемые основными семействами ABT

Одно из ключевых разрешений, CALL_PHONE, позволяет злоумышленникам совершать звонки с телефона совершенно незаметно для пользователя. Возможно, они могут использовать это разрешение для подтверждения банковской транзакции. За исключением FakeSpy, это разрешение запрашивают все семейства вредоносных программ, представленные в этой главе. Xbot использует его для настройки переадресации вызовов на заражённом устройстве, вероятно, чтобы перенаправлять входящие звонки из банка пользователя мошенникам. Образцы семейства Medusa используют это разрешение для звонков на случайные телефонные номера по указанию сервера управления и контроля вредоносной программы.

Ещё одно разрешение, отличающее ABT от других вредоносных программ, - WAKE_LOCK, которое гарантирует, что телефон останется включённым. Использование этого разрешения широко распространено среди ABT; его часто применяют, чтобы принудительно не давать устройству перейти в спящий режим в критические моменты, когда вредоносная программа пытается похитить данные или деньги. Например, BankBot не даёт устройству отключиться, одновременно отключая экран блокировки и принудительно вызывая взаимодействия с пользовательским интерфейсом. Семейство Marcher действует менее скрытно: оно заставляет устройство постоянно оставаться включённым. За исключением Cerberus, это разрешение запрашивают все семейства вредоносных программ, рассмотренные в этой главе. Хотя его могли бы использовать другие формы вредоносных программ, например шпионские программы и приложения для мошенничества с SMS, в других категориях вредоносных программ оно запрашивается реже.

Разрешение WRITE_CONTACTS, позволяющее приложению записывать данные в список контактов, - ещё одно разрешение, отличающее ABT от других вредоносных программ. Им можно злоупотреблять множеством способов: например, записать новый телефонный номер вашего банка, а затем позвонить вам с этого номера, создавая впечатление, будто номер злоумышленника принадлежит банку. Из семи обсуждавшихся нами семейств вредоносных программ это разрешение запрашивает только Zitmo. На практике мы не наблюдали злоупотреблений им.

Последнее разрешение, отличающее ABT от других вредоносных программ, - READ_CALL_LOG. Оно позволяет приложению видеть, кто звонил на телефон, в какие дни недели и время суток совершались звонки, и другие сведения. В принципе, эта привилегия может позволить мошенникам выдать себя за человека, ранее звонившего жертве. Например, они могут отправлять поддельные сообщения со ссылкой на реальный разговор жертвы, чтобы обманом заставить пользователя передать им деньги или сведения. Хотя ни одно семейство вредоносных программ, обсуждавшееся ранее в этой главе, не запрашивает это разрешение, наши классификаторы обнаружили его связь с ABT.

В таблице 9-4 показана способность алгоритмов машинного обучения отделять ABT от других вредоносных программ.

Таблица 9-4. Показатели оценки ABT и других вредоносных программ

Лучший результат позднего слияния в данном случае обеспечивает оценку F1 0,9507 при точности 0,9447 и полноте 0,9576. Хотя это превосходные показатели, они немного ниже показателей отделения ABT от доброкачественных программ. Этого следовало ожидать: ABT часто имеют общие характеристики с другими категориями вредоносных программ, что затрудняет их отделение. Например, некоторые ABT, такие как FakeSpy, похищают списки контактов - такое поведение также наблюдается у шпионских приложений. Другие, например Xbot, обладают и поведением ABT, и возможностями программ-вымогателей.

На рисунке 10-1 показаны 20 признаков, играющих наибольшую роль в отделении программ-вымогателей от доброкачественных программ с помощью классификатора Extra-Trees, обсуждавшегося в главе 7.

Как можно видеть, 11 из 20 важнейших признаков связаны с разрешениями. Обратите внимание, что, в отличие от ABT, разрешения, связанные с SMS, не слишком важны для отделения программ-вымогателей от доброкачественных. Рассмотрим более полезные разрешения.

Разрешение MOUNT_UNMOUNT_FILESYSTEMS является одним из важнейших для классификации программ-вымогателей: его запрашивают более 40 процентов приложений-вымогателей и лишь около 5 процентов доброкачественных программ. Это удивительно, поскольку данное разрешение требует использования эксплойта повышения привилегий, позволяющего приложениям манипулировать файловой системой. Нам неизвестны программы-вымогатели Android, содержащие такой эксплойт, поэтому на практике вредоносная программа не смогла бы воспользоваться этим разрешением. Вероятно, небольшое число семейств программ-вымогателей искажает статистическое распределение этого признака. Несколько семейств программ-вымогателей запрашивают десятки разрешений, включая MOUNT_UNMOUNT_FILESYSTEMS, но фактически их не используют.

Мы описывали разрешение GET_TASKS в предыдущих главах. Вкратце, оно позволяет приложению видеть процессы, работающие на устройстве. Это разрешение также можно использовать в защитных целях, например для проверки наличия программного обеспечения безопасности на устройстве или принудительного взаимодействия пользователя с интерфейсом определённым образом. Семейство программ-вымогателей Svpeng использует это разрешение, чтобы гарантировать предоставление пользователем административных разрешений устройства на экране администрирования, а семейство Simplocker постоянно отслеживает приложение на переднем плане и пытается как можно быстрее завершить его, если пользователь начинает взаимодействовать с любым приложением, кроме самой программы-вымогателя. Программы-вымогатели запрашивают это разрешение примерно в четыре раза чаще доброкачественных программ.

Разрешение INSTALL_PACKAGES позволяет привилегированному приложению незаметно устанавливать другие приложения. Поскольку это разрешение привилегированное, обычные приложения не могут его использовать, а доброкачественные почти никогда его не запрашивают. Однако его запрашивают более 20 процентов приложений-вымогателей по неясным причинам. Как и в случае MOUNT_UNMOUNT_FILESYSTEMS, программы-вымогатели фактически не могут использовать это разрешение, а выборочная проверка образцов программ-вымогателей из нашей библиотеки показала, что большинство образцов, запрашивающих INSTALL_PACKAGES, также запрашивают непривилегированное и требующее согласия пользователя разрешение REQUEST_INSTALL_PACKAGES. Возможно, разработчики программ-вымогателей запрашивают оба разрешения на случай, если приложение каким-либо образом получит повышенные привилегии.

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

Разрешение ACCESS_WIFI_STATE предоставляет доступ к Android WifiManager для получения состояния Wi-Fi-соединения устройства. Мы видели, как приложения-вымогатели, например Simplocker, используют это разрешение для принудительного установления Wi-Fi-соединения и обеспечения связи программы-вымогателя со своим сервером управления и контроля. Это разрешение запрашивают более 80 процентов образцов программ-вымогателей, что более чем вдвое превышает долю доброкачественных приложений.

Неудивительно, что приложения-вымогатели используют разрешение SYSTEM_ALERT_WINDOW, чтобы разместить окно поверх всего экрана, предположительно для показа требования выкупа. Важно, что окно наложения не позволяет пользователю управлять устройством. Вероятность запроса этого разрешения программой-вымогателем примерно в четыре раза превышает вероятность его запроса доброкачественной программой.

Разрешение READ_LOGS программы-вымогатели также запрашивают примерно в четыре раза чаще доброкачественных программ. Однако мы не наблюдали его использования для функций, связанных с блокировкой телефонов или требованием выкупа, и предполагаем, что оно является артефактом технологических решений разработчиков программ-вымогателей. Например, несколько семейств программ-вымогателей используют коммерческие инструменты защиты приложений, такие как Tencent Legu или Qihoo 360 Jiagu, чтобы защититься от обратного проектирования. Эти инструменты защиты используют разрешение READ_LOGS для сбора журнальных сведений с целью диагностики сбоев. Из-за небольшого числа семейств программ-вымогателей технологические решения даже нескольких из них оказывают непропорционально большое влияние на признаки машинного обучения.

Доброкачественные программы почти никогда не используют разрешение KILL_BACKGROUND_PROCESSES, но его запрашивают более 25 процентов программ-вымогателей. Это разрешение позволяет программе-вымогателю завершать любые процессы антивирусов, которые могут работать на устройстве. Как упоминалось ранее, некоторые семейства программ-вымогателей, например Simplocker, также пытаются без разбора завершать все процессы, кроме процесса самой программы-вымогателя, а некоторые разрешают явно заданный список системных диалогов настроек, с которыми программа-вымогатель хочет заставить пользователя взаимодействовать.

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

Разрешение RESTART_PACKAGES - ещё одно разрешение, которое редко используется доброкачественными программами, но запрашивается более чем 25 процентами программ-вымогателей. Мы не обнаружили его использования в реальном поведении программ-вымогателей, но иногда оно применяется SDK, встроенными в приложения-вымогатели. Даже это удивительно, поскольку данное разрешение было объявлено устаревшим в 2011 году, в Android 4.0.3 (Ice Cream Sandwich).

В таблице 10-1 показаны некоторые распространённые разрешения, запрашиваемые шестью важными семействами вредоносных программ. Мы видим, что некоторые семейства, например Simplocker, запрашивают практически все разрешения, тогда как другие гораздо более избирательны.

Таблица 10-1. Разрешения, запрашиваемые семействами программ-вымогателей

Некоторые разрешения, например RECEIVE_BOOT_COMPLETED, запрашивают все шесть изученных нами семейств, тогда как другие, например READ_LOGS и KILL_BACKGROUND_PROCESSES, запрашивает лишь одно приложение. Этот простой анализ показывает разнообразие поведения программ-вымогателей.

Программы-вымогатели обычно выполняют больше вызовов org.apache.conn и org.apache.conn.scheme, чем доброкачественные программы, возможно, чтобы поддерживать соединения между скомпрометированным устройством и сервером управления и контроля разработчиков вредоносной программы. Поскольку приложения-вымогатели на Android редки, а число выявленных семейств невелико, использование библиотек Apache даже несколькими из них делает прогностическую силу признаков, связанных с такими вызовами, относительно высокой, что и объясняет эти наблюдения.

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

В таблице 10-2 показана эффективность выбранных классификаторов машинного обучения при отделении программ-вымогателей от доброкачественных программ для разных наборов признаков. В первом столбце перечислены виды признаков, используемых для прогнозирования, включая базовые признаки API, статические и динамические признаки, а также расширенные признаки, полученные из TSG, ориентиров, кластеризации признаков и корреляционных графов. Кроме того, показаны комбинации этих видов. Во втором столбце указан лучший подход к классификации с использованием набора признаков из данной строки, а в последующих столбцах - различные показатели прогностической эффективности.

Таблица 10-2. Показатели оценки программ-вымогателей и доброкачественных программ Android

Как можно видеть, описанные в этой книге подходы машинного обучения способны обеспечить точность почти 92 процента и полноту более 96 процентов, что является превосходными показателями эффективности.

На рисунке 10-2 показаны 20 важнейших признаков для отделения программ-вымогателей от других форм вредоносных программ.

Разрешения играют здесь наибольшую роль, поэтому мы сосредоточимся на них. Кроме того, программы-вымогатели, по-видимому, выполняют больше вызовов android.security, android.content.pm и android.database, чем другие категории вредоносных программ, но эти различия довольно малы. Аналогично мы снова видим, что программы-вымогатели выполняют больше вызовов функций org.apache.http.conn, org.apache.http.conn.schema и org.apache.http.params, чем другие вредоносные программы.

Вы сразу должны заметить, что другие вредоносные программы запрашивают разрешения SEND_SMS, RECEIVE_SMS и WRITE_SMS, связанные с SMS, чаще программ-вымогателей. Это неудивительно, поскольку другие формы вредоносных программ используют эти разрешения для таких задач, как перехват сообщений двухфакторной аутентификации, чего программам-вымогателям делать не требуется.

Рисунок 10-2. 20 важнейших признаков, лучше всего отличающих программы-вымогатели Android от других вредоносных программ

С другой стороны, программы-вымогатели чаще других форм вредоносных программ запрашивают разрешения RESTART_PACKAGES и READ_LOGS, которые были описаны в предыдущем разделе. Ещё одно разрешение, которое приложения-вымогатели запрашивают гораздо чаще других форм вредоносных программ, - DIAGNOSTIC, позволяющее приложениям читать диагностические ресурсы и записывать в них. Однако это разрешение привилегированное, поэтому непривилегированные приложения, включая все известные нам современные семейства программ-вымогателей, не могут его использовать.

В таблице 10-3 показано, насколько эффективно алгоритмы машинного обучения отделяют программы-вымогатели от других форм вредоносных программ.

Таблица 10-3. Классификация программ-вымогателей Android и других вредоносных программ

Точность и полнота в этом случае ниже и составляют соответственно немногим более 87 процентов и около 95 процентов. Неудивительно, что отделить программы-вымогатели от других вредоносных программ сложнее, чем от доброкачественных, поскольку программы-вымогатели часто имеют больше общего с другими категориями вредоносных программ, чем с доброкачественными.

Если посмотреть на 20 важнейших признаков для отделения доброкачественных программ Android от приложений, участвующих в мошенничестве с SMS (рисунок 11-1), можно заметить нечто интересное: хотя 11 из этих признаков связаны с разрешениями, среди них нет разрешений SMS. Возможно, причина в том, что такие разрешения могут использовать различные легитимные приложения, например чтобы позволить отправлять сообщения из приложения. Другие возможности мы обсудим в разделе «Отсутствие разрешений SMS» на странице 270.

Как и программы-вымогатели и вредоносные программы для получения root-прав, приложения для мошенничества с SMS чаще доброкачественных программ вызывают API org.apache.http.com.scheme и org.apache.http.com. С другой стороны, доброкачественные программы обычно выполняют больше вызовов многих Android API, таких как android.content.res, android.view, android.media.session, android.view.accessibility и android.os. Единственное исключение - API Wi-Fi (android.net.wifi), предоставляющий классы для Wi-Fi-соединения. Мы не знаем, почему приложения для мошенничества с SMS используют его чаще доброкачественных. Возможно, это просто артефакт прежних вредоносных программ, созданных теми же разработчиками.

Многие важные разрешения мы описали в предыдущих главах. Некоторые из них, по-видимому, не служат никакой цели. Например, MOUNT_UNMOUNT_FILESYSTEMS и INSTALL_PACKAGES являются привилегированными разрешениями, а приложения для мошенничества с SMS обычно объявляют их, но никогда не используют. Эти приложения также могут запрашивать разрешение READ_LOGS, хотя непривилегированным приложениям оно не предоставляет вредоносных возможностей.

Другие разрешения могут позволять приложению выполнять задачи, распространённые среди многих форм вредоносных программ. Например, разрешения KILL_BACKGROUND_PROCESSES и RESTART_PACKAGES, второе из которых было объявлено устаревшим в Android 4.0.3 (Ice Cream Sandwich), могут использоваться для завершения нежелательных процессов в рамках защитной стратегии. Кроме того, разрешение RECEIVE_BOOT_COMPLETED предоставляет вредоносной программе простейший способ закрепиться, автоматически перезапускаясь после перезагрузки телефона.

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

Рисунок 11-1. 20 важнейших признаков, лучше всего отличающих вредоносные программы Android для мошенничества с SMS от доброкачественных программ с помощью классификатора Extra-Trees

В главе 10 мы отмечали, что приложения могут использовать разрешение ACCESS_WIFI_STATE для доступа к Android WifiManager и получения состояния Wi-Fi-соединения устройства. Мошенничество с SMS происходит через телефонный стек, а не стек Wi-Fi; несмотря на это, несколько семейств для мошенничества с SMS пытаются определить состояние Wi-Fi устройства. Возможно, причина в том, что эти приложения хотят иметь стек Wi-Fi в качестве резервного варианта. Вероятность запроса этого разрешения приложениями для мошенничества с SMS почти ровно вдвое выше вероятности его запроса доброкачественными программами.

Приложения используют разрешение GET_TASKS для определения процессов, работающих на устройстве. Это разрешение запрашивают почти 70 процентов приложений, участвующих в мошенничестве с SMS, против менее 20 процентов доброкачественных программ. Вредоносные приложения могут запрашивать его по ряду причин, например чтобы выяснить, работает ли антивирусный механизм.

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

Отсутствие разрешений, связанных с SMS, в списке 20 важнейших признаков могло вас удивить. Несомненно, приложению для мошенничества с SMS необходимо записывать и отправлять SMS-сообщения, чтобы выполнять свою вредоносную работу. Если посмотреть на 50 важнейших признаков, разрешение WRITE_SMS обнаружится на позиции 33, что позволяет предположить, что оно действительно несколько важно для отделения приложений для мошенничества с SMS от доброкачественных программ.

Тем не менее нехватка других разрешений, связанных с SMS, вызывает недоумение. Поскольку разные классификаторы выявляют важные признаки разными способами, мы проверили, сочтут ли другие классификаторы эти разрешения более значимыми. На рисунке 11-2 показаны 20 важнейших признаков, созданных классификатором случайного леса.

Как можно видеть, для отделения доброкачественных программ от приложений для мошенничества с SMS этот классификатор использует признаки, сильно отличающиеся от признаков классификатора Extra-Trees. Фактически он ставит SEND_SMS на первое место по важности! Согласно этой модели, вероятность запроса данного разрешения приложениями, участвующими в мошенничестве с SMS, более чем в восемь раз выше вероятности его запроса доброкачественными программами. Разрешения RECEIVE_SMS, WRITE_SMS и READ_SMS также входят в список 20 важнейших признаков, причём приложения для мошенничества с SMS запрашивают их значительно чаще доброкачественных программ.

Мы также рассмотрели важнейшие признаки, предложенные классификатором XGBoost и показанные на рисунке 11-3. И здесь мы увидели другой набор признаков, определённых как важные, причём SEND_SMS и RECEIVE_SMS входят в число 20 важнейших.

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

Рисунок 11-3. 20 важнейших признаков, лучше всего отличающих вредоносные программы Android для мошенничества с SMS от доброкачественных программ с помощью классификатора XGBoost

Как показывают эти результаты, разные методы машинного обучения могут определять разные признаки как наиболее важные. Например, один метод может рассматривать каждый признак из общего набора и измерять ценность каждого, вычисляя снижение прогностической эффективности алгоритма машинного обучения при удалении этого признака. Чем больше снижение, тем важнее признак. Другие методы могут использовать известные статистические модели, например взаимную информацию или анализ главных компонент (principal component analysis, PCA). Помимо используемых статистических методов, на выявление разных наборов значимых признаков влияют конструкция и структура самих классификаторов.

Наконец, мы построили дерево решений для отделения приложений для мошенничества с SMS от доброкачественных программ. Первые три уровня дерева решений показаны на рисунке 11-4.

Рисунок 11-4. Дерево решений глубиной три для отделения вредоносных программ Android для мошенничества с SMS от доброкачественных программ

Это дерево решений переходит к левому дочернему узлу, когда условие, указанное в узле, истинно; в противном случае оно переходит к правому. Разрешение SEND_SMS находится на втором уровне дерева, сразу под корнем, что подтверждает важность, которую придаёт ему этот вид классификатора.

Правый дочерний узел этого узла проверяет количество вызовов классов пакета android.content.res в исходном коде приложения. Этот пакет содержит классы, используемые для доступа к различным файлам и мультимедийным материалам, а также к параметрам, настраивающим устройство. Если число вызовов меньше или равно 82,0 и приложение запрашивает разрешение SEND_SMS, вероятность того, что оно является приложением для мошенничества с SMS, составляет 1106/1108 (почти 100 процентов).

Любопытно, что две другие ветви этого дерева решений совершенно не зависят от использования разрешения SEND_SMS, что может объяснить, почему исходный набор из 20 важнейших признаков, созданный классификатором Extra-Trees, не выявил разрешений, связанных с SMS. Один из путей проверяет следующее: число вызовов классов пакета android.content.res меньше 82, приложение не запрашивает разрешение SEND_SMS, а число вызовов классов org.apache.http.conn.scheme превышает 1,5. Если выполняются все эти условия, вероятность того, что приложение является вредоносной программой для мошенничества с SMS, составляет 100 процентов. Другой путь проверяет, что число вызовов классов android.content.res превышает 82, а число вызовов классов org.apache.http.conn.scheme превышает 5,5, что также даёт 100-процентную вероятность мошенничества приложения с SMS.

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

В таблице 11-1 показана эффективность различных классификаторов машинного обучения при прогнозировании того, участвует ли приложение в мошенничестве с SMS или является доброкачественным, для разных наборов и комбинаций базовых и расширенных признаков.

Таблица 11-1. Оценка вредоносных программ Android для мошенничества с SMS и доброкачественных программ

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

На рисунке 11-5 показаны 20 важнейших признаков для отделения приложений для мошенничества с SMS от других форм вредоносных программ согласно классификатору Extra-Trees. Как можно видеть, разрешения, связанные с SMS, играют здесь важную роль, поэтому мы сосредоточимся на них.

Хотя классификатор Extra-Trees не опирается на разрешения, связанные с SMS, при отделении вредоносных программ для мошенничества с SMS от доброкачественных программ, он считает их полезными для отделения этого вида вредоносных программ от других форм. Разрешения SEND_SMS, READ_SMS и RECEIVE_SMS запрашивают около 70 процентов приложений для мошенничества с SMS против менее 20 процентов других вредоносных программ. Аналогично разрешение WRITE_SMS запрашивают 50 процентов приложений для мошенничества с SMS против примерно 20 процентов других вредоносных программ. Возможно, вы задаётесь вопросом, почему некоторым приложениям для мошенничества с SMS эти разрешения не нужны. Причина в том, что некоторые из таких приложений обманом заставляют пользователя самостоятельно отправлять премиальные SMS-сообщения. Для этого не требуется разрешение SEND_SMS: приложение открывает стандартное приложение SMS и надеется, что пользователь сам нажмёт кнопку «Отправить».

В связи с этим мы видим, что приложения для мошенничества с SMS более чем вдвое чаще других видов вредоносных программ запрашивают разрешение CALL_PHONE (более 40 процентов против менее 20 процентов других вредоносных программ). Одним из объяснений такого различия может быть то, что некоторые семейства для мошенничества с SMS также занимаются другими формами мошенничества, связанного с телефонией. Например, семейство RuPlay содержит код для перенаправления исходящих вызовов на телефонный номер, предоставленный разработчиками вредоносной программы, а семейство BeeKeeper - код как для перенаправления исходящих вызовов, так и для совершения новых звонков на эти номера. Для перенаправления исходящих вызовов также требуется разрешение PROCESS_OUTGOING_CALLS, которое прежде всего позволяет приложениям узнавать об исходящих вызовах.

Рисунок 11-5. 20 важнейших признаков, лучше всего отличающих вредоносные программы Android для мошенничества с SMS от других вредоносных программ с помощью классификатора Extra-Trees

Также следует отметить, что приложения для мошенничества с SMS обращаются к разрешениям READ_LOGS, ACCESS_WIFI_STATE и RESTART_PACKAGES реже других вредоносных программ. Однако, как и программы-вымогатели, они вызывают функции org.apache.http.conn и org.apache.http.conn.schema чаще других форм вредоносных программ. То же самое относится к org.apache.http.params и некоторым Android API, например из пакетов android.app, android.net, android.content и android.content.pm.

В таблице 11-2 показано, как наши подходы машинного обучения справляются с отделением приложений, участвующих в мошенничестве с SMS, от других форм вредоносных приложений.

Таблица 11-2. Показатели оценки вредоносных программ Android для мошенничества с SMS и других вредоносных программ

Неудивительно, что точность прогнозирования снижается при отделении приложений для мошенничества с SMS от других вредоносных программ. Точность падает ниже 93 процентов, а полнота - чуть ниже 92 процентов. Тем не менее это по-прежнему хорошие результаты.

Чтобы спрогнозировать будущие тенденции вредоносных программ Android, можно обратиться к опыту Microsoft Windows, популярность и доступность которой сопоставимы с Android. Поскольку Windows более чем на 20 лет старше Android, ряд методов вредоносных программ, которые мы наблюдаем и ожидаем увидеть в будущем на Android, уже появился в Windows, что позволяет легко проводить параллели между ними. Однако другие аспекты операционных систем, включая лицензирование и архитектуру программного обеспечения, сильно различаются и плохо поддаются сравнению. Поэтому некоторые технологические тенденции вредоносных программ Android могут не относиться к Windows, и наоборот.

Начиная с 1980-х годов Microsoft и сотни сторонних компаний по безопасности помогали защищать пользователей и компьютеры от вредоносных программ Windows, а также от вредоносных программ, нацеленных на её предшественницу MS-DOS. В результате эти вредоносные программы прошли множество циклов совершенствования, используя недавно обнаруженные ниши в этих операционных системах, прежде чем Microsoft успевала принять ответные меры.

В качестве примера вспомним вирусы, заражавшие файлы в первые годы существования этих операционных систем. Файловые вирусы изменяли доброкачественные исполняемые файлы, внедряя в них вредоносный код. Этот вид вредоносных программ был чрезвычайно распространён, пока Microsoft не добавила в Windows подписание исполняемых файлов. Сегодня файловые вирусы редки, поскольку большинство доброкачественных исполняемых файлов подписаны закрытым ключом, известным только первоначальным разработчикам программного обеспечения. Неосторожное изменение таких подписанных исполняемых файлов, например файловым вирусом, желающим внедрить вредоносный код, нарушает целостность файла, и Windows не позволяет запускать изменённые файлы.

В конце 1990-х годов вредоносные макросы Office превзошли по популярности файловые вирусы в Windows. Злоумышленники встраивали вредоносный код в файлы продуктов Office, таких как Word или Excel, что позволяло мощным сценариям выполнять множество разных атак на затронутые системы. Пользователей обманом заставляли открывать файлы .doc или .xls, отправленные в нежелательных электронных письмах с заманчивыми сообщениями, обещавшими деньги или особенно пикантные сведения, например утёкшие данные о зарплатах у их работодателя. Microsoft вновь приняла ответные меры и закрыла этот вектор атаки, сделав открытие документов Office по умолчанию более безопасным. Кроме того, для противодействия такому виду злоупотреблений она запустила дополнительные функции безопасности, например возможность навсегда отключить макросы Office во всей организации.

В начале 2000-х годов компьютеры Windows, подключённые к зарождавшемуся интернету, регулярно подвергались атакам ранних интернет-червей с такими именами, как Code Red, Nimda и SQL Slammer. Эти черви использовали установки Windows, в которых по умолчанию интернету было открыто множество служб (такое происходило даже на компьютерах обычных пользователей, которые могли вовсе не знать о существовании этих служб). Лёгкость распространения интернет-червей и трудности, с которыми сталкивались защищавшиеся пользователи, сделали их первыми вредоносными программами, вызывавшими страх во всём мире. Однако эпоха интернет-червей быстро достигла пика и продлилась лишь несколько лет. Под давлением Microsoft вновь пересмотрела безопасность Windows: установки Windows по умолчанию открывали интернету меньше служб, а действительно необходимые включённые службы были значительно укреплены против червеобразных атак.

Работа Microsoft по повышению безопасности своих продуктов впечатляет и не ограничивается этими примерами. Новые вредоносные программы Windows должны находить свежие пути для злоупотреблений, что создаёт затраты для разработчиков вредоносных программ. Кроме того, антивирусные компании, специализирующиеся на Windows, десятилетиями развивали мощные возможности обнаружения злоупотреблений и защиты от них. После обнаружения антивирусными инструментами срок жизни новой вредоносной программы Windows сокращается. Сегодня успешные образцы должны быть гораздо сложнее успешных вредоносных программ Android, поскольку экосистема Windows прошла намного больше циклов эксплуатации и укрепления.

Как всё это связано с будущим вредоносных программ Android? Наш обзор Windows позволяет предположить, что лучший способ остановить вредоносные программы Android в долгосрочной перспективе - всесторонне повысить безопасность экосистемы Android. Защитники не могут победить, ограничиваясь стратегией обнаружения и удаления вредоносных программ.

Как обсуждалось в части I, Android уже прошла несколько циклов укрепления: авторы вредоносных программ обнаруживают пути атак, после чего Google усиливает безопасность операционной системы. Среди наиболее успешных примеров защиты - реакция Android на попытки отправки мошеннических премиальных SMS-сообщений. Теперь операционная система показывает предупреждающее диалоговое окно каждый раз, когда приложение пытается отправить премиальное SMS, что почти лишает вредоносные программы возможности злоупотреблять этим вектором. Ещё один пример - объявление устаревшим API администрирования устройства, которым вредоносные программы злоупотребляли для закрепления на устройствах. Будущим вредоносным программам Android придётся постоянно реагировать на такие изменения, отказываться от ранее прибыльных методов атак и переходить к менее защищённым частям экосистемы.

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

Однако во многих отношениях модель угроз Android совершенно отличается от модели Windows. Первая версия Windows была разработана, когда персональные компьютеры имелись у немногих, а ещё меньше людей подключали свои компьютеры к каким-либо общедоступным сетям; число преступных групп, пытавшихся злоупотреблять подключёнными к сети компьютерами, было практически нулевым. Android с самого начала работала на миллионах (а позднее миллиардах)

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

Вредоносные программы Windows более развиты, чем вредоносные программы Android, в одном конкретном аспекте: методах противодействия анализу, которые их разработчики внедряли на протяжении многих лет. Эти методы делают анализ с помощью типичных инструментов, таких как виртуальные машины, дизассемблеры и декомпиляторы, гораздо сложнее и утомительнее. Что ещё лучше для авторов вредоносных программ, для Windows существует множество бесплатных и коммерческих упаковщиков исполняемых файлов, обфускаторов и других средств защиты, поэтому им не приходится тратить время на создание собственных механизмов защиты. Они могут использовать свободно доступные инструменты либо купить, похитить или незаконно скопировать мощные коммерческие продукты.

Хотя аналогичные средства защиты приложений существуют и на Android, обычно они не столь совершенны. Например, авторы вредоносных программ Windows могут выбирать из большого набора средств защиты исполняемых файлов с такими расширенными функциями, как обфускация потока управления. Некоторые инструменты даже преобразуют исходный исполняемый код в код виртуальной машины, специфичный для средства защиты. Для Android доступно гораздо меньше готовых средств защиты, а предоставляемые ими функции значительно менее совершенны. Мы ожидаем, что в ближайшие годы сложность защиты от анализа и упаковщиков исполняемых файлов на платформе Android возрастёт; однако многие методы, используемые в Windows, совершенно невозможны на Android из-за жёсткой изоляции операционной системы.

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

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

Исторически разработчики вредоносных программ писали код на Java или Kotlin и компилировали его в DEX, как и большинство разработчиков легитимных приложений. Однако определённые технические свойства кода DEX упрощают его анализ исследователями безопасности. Авторы вредоносных программ прекрасно это понимают, поэтому мы наблюдаем их отход от кода DEX.

Наиболее очевидная альтернатива коду DEX - использование нативного машинного кода, обычно ARM, скомпилированного из таких языков, как C++. Нативный машинный код не обладает удобными техническими свойствами кода DEX, и его гораздо труднее разбирать и анализировать. Большинство, если не все, компаний, занимающихся сегодня анализом вредоносных программ Android, обладают более развитыми возможностями анализа DEX, чем анализа ARM. Мы считаем, что авторы вредоносных программ знают об этом и используют данный факт в своих интересах.

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

Если механизм статического анализа не обладает возможностями анализа потока данных, способными пересекать границы кода ARM-DEX, ему будет трудно пометить вредоносное поведение, скрытое в зашифрованных строках кода DEX. Вероятно, авторы вредоносных программ правильно предполагают, что большинство компаний по безопасности не обладают возможностями межархитектурного анализа потока управления и потока данных.

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

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

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

Ещё один способ лишить продукты для борьбы с вредоносными программами видимости - использовать необычные языки программирования. Можно с уверенностью предположить, что защитники способны анализировать код Java и (в определённой степени) нативный машинный код ARM. Но сколько компаний по борьбе с вредоносными программами умеют анализировать более новые среды разработки приложений, такие как Flutter или ReactNative? И у скольких есть механизмы анализа языков, занимающих нишевое положение на Android, например Lua или Python, особенно когда эти сценарии взаимодействуют с Android API?

Мы видели один особенно новаторский образец вредоносной программы, который загружал оболочку Bash, а затем использовал её для вредоносной деятельности. Сначала он выполнял внутри оболочки команду установки пакетов Linux apt-get, чтобы установить несколько стандартных модулей Linux, например OpenSSL и libcurl, а также Python. Затем он загружал сценарии Bash для выполнения вредоносного кода из оболочки. Очень немногие компании по безопасности способны автоматически анализировать такие конфигурации.

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

Святой Грааль сокрытия от исследователей безопасности - вообще не раскрывать никакого кода. По мере того как пользователи всё больше заботятся о конфиденциальности и начинают внимательно изучать практики сбора данных технологических компаний, мы наблюдаем переход проблемных компаний-брокеров данных к тому, что называем системами без SDK или системами «сервер-сервер».

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

В мире без SDK брокеры данных вообще не предоставляют разработчикам приложений никакого кода. Вместо этого они предоставляют конечную точку сервера, на которую приложения должны отправлять собранные сведения. Ответственность за сбор и передачу данных несёт разработчик приложения. Чтобы избежать обнаружения, разработчики сначала отправляют данные на собственные серверы, а затем пересылают их в системы брокера данных. Поскольку никто не может исследовать трафик между этими серверами, первоначального разработчика приложения нельзя будет связать с продажей пользовательских данных брокеру, а сам брокер вовсе не будет иметь очевидной связи со сбором пользовательских данных.

Если, например, приложение для отслеживания физической активности собирает GPS-местоположение устройства или приложение резервного копирования списка контактов отправляет сведения из этого списка на свой сервер резервного копирования, кто сможет проверить, не перепродают ли они затем эти данные без согласия пользователя? Исследователям безопасности придётся найти способы отслеживать такие продажи данных, выходящие за рамки анализа приложений, поскольку в самих приложениях ничего подозрительного не происходит.

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

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

Эксперты строят предположения о том, как может происходить компрометация цепочки поставок. Судя по известным нам историям, наиболее успешные авторы вредоносных программ создают кажущиеся легитимными компании, разрабатывающие приложения или SDK с желательными функциями. Затем эти компании обращаются к производителям, входящим в цепочку поставок, и предлагают партнёрство для лицензирования приложений или SDK. Производители не знают, что эти продукты поставляются с бэкдорами или другими вредоносными функциями, работающими в фоне. Такой вид атаки очень эффективен и опасен, поскольку авторы вредоносных программ обычно предлагают функции, проникающие глубоко в операционную систему Android, что предоставляет вредоносным приложениям и другим вредоносным изменениям системы гораздо больше привилегий и разрешений, чем они получили бы в качестве обычных приложений.

Рассмотрим реальный пример приложения управления шрифтами EagerFonts с бэкдором, описанного в главе 2. Разрабатывать программное обеспечение для управления шрифтами внутри компании невыгодно, поэтому производители часто лицензируют его у специализированного стороннего разработчика. Кроме того, производители, вероятно, не станут задавать слишком много вопросов, если разработчики попросят предоставить коду дополнительные привилегии: диспетчер шрифтов может быть частью основной функции операционной системы и требовать больше привилегий, чем обычные приложения. После этого скрытый бэкдор сможет использовать повышенные привилегии.

Атака на цепочку поставок вместо отдельных Android-устройств требует больших первоначальных вложений, но имеет ряд преимуществ. Например, авторам вредоносных программ не нужно разрабатывать приложения, привлекающие множество пользователей. Вместо этого им достаточно убедить нескольких лиц, принимающих решения, в каком-либо звене цепочки поставок, что можно сделать более целенаправленно. Использование Google Play для распространения вредоносных программ требует создания эффективных маркетинговых материалов и рекламных кампаний; кроме того, приложения не должны казаться плохими или бесполезными, иначе пользователи быстро их удалят. Дополнительная опасность быть обнаруженными Google и удалёнными из Google Play делает такие усилия рискованными.

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

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

По сходным причинам предустановленные вредоносные программы гораздо труднее удалять с устройств. Обычные приложения можно просто удалить. С предустановленными приложениями дело обстоит иначе. Обычно пользователи могут лишь отключить их, поэтому вредоносная программа потенциально может быть включена вновь. Во многих случаях невозможно даже отключить предустановленную вредоносную программу. Авторы вредоносных программ поняли, что, внедрив код в критически важные приложения, поставляемые с устройством, они не позволят продуктам для борьбы с вредоносными программами отключить их. Например, очень распространённой целью для вредоносного внедрения кода является процесс системного интерфейса. Защитники не могут отключить этот процесс, не сделав устройство непригодным для использования, поскольку он отвечает за отображение экрана.

Распространение вредоносных программ, устанавливаемых из сторонних источников, разумеется, продолжится до тех пор, пока Android позволяет пользователям устанавливать приложения из источников, отличных от Google Play. По сравнению с другими методами распространения установка из сторонних источников проще и с меньшей вероятностью привлечёт внимание множества исследователей безопасности. Авторы вредоносных программ могут легко настроить собственные серверы распространения вредоносных программ или загрузить свои приложения в альтернативные магазины приложений, которые могут иметь меньше средств защиты, чем Google Play (но также предоставляют доступ к меньшему числу потенциальных жертв).

Семейство вредоносных программ Flubot, поразившее Европу, Австралию и Новую Зеландию в 2021 году, ясно показало, что вредоносные программы из сторонних источников могут добиться успеха, если на протяжении процесса установки к пользователям активно применяется социальная инженерия. Разработчики Flubot смогли заставить жертв массово устанавливать из сторонних источников свои приложения для банковского фишинга, рассылая пользователям в затронутых странах огромное количество SMS-сообщений, подразумевавших необходимость срочно загрузить и установить вредоносное приложение по ссылке. Чаще всего в спам-сообщениях Flubot утверждалось, что пользователь должен получить посылку, но ему необходимо запланировать время доставки через приложение по ссылке. Flubot доказала, что сотни тысяч пользователей готовы пройти пять и более предупреждающих диалоговых окон операционной системы Android, Google Play Protect и приложения Google Messenger, чтобы запланировать доставку входящей посылки. Другие разработчики вредоносных программ заметили успех Flubot и, вероятно, попытаются подражать этой тактике.

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