[Из песочницы] Бунт против виртуальной машины
Предлагаю вашему вниманию перевод статьи Rage Against the Virtual Machine.
Антивирусные компании, магазины мобильных приложений и исследователи безопасности используют техники, основанные на динамическом анализе кода, для обнаружения и анализа мобильных вредоносных приложений. В этот статье, представлен широкий диапазон техник противодействия анализу, которые могут быть использованы вредоносными приложения для обхода динамического анализа в эмулируемые средах платформы Android.
Эвристики обнаружения, представленные в этой статье, охватывают три различные категории, основанные на (i) статических свойствах, (ii) динамической информации от датчиков и (iii) тонкостях работы эмулятора Android на виртуальных машинах. Для оценки эффективности представленных методов они были включены в образцы реальных вредоносных приложений и отправлены в публично доступные системы динамического анализа, после чего были получены тревожные результаты. Было обнаружено, что все инструменты и сервисы уязвимы для большинства наших техник уклонения от анализа. Даже тривиальные техники, такие как проверка значения IMEI, достаточны для обхода некоторых существующих сред динамического анализа. Также предложены возможные контрмеры для улучшения устойчивости текущих инструментов динамического анализа против попыток уклонения от анализа.
1. Вступление
Популярность ОС Android в сочетании с открытостью этой платформы, сделало её привлекательной целью для злоумышленников [13]. Производители антивирусов и исследователи отреагировали на эту растущую озабоченность безопасности посредством сервисов и инструментов для анализа вредоносных приложений. Google также создал Bouncer [1], сервис для автоматического сканирования и проверки вредоносных приложений. Сканирование приложения для обнаружения его потенциально скрытых вредоносных действий может быть основано на статическом [22, 25] и динамическом анализе [14, 17, 19, 28]. К сожалению как статический, так и динамический подход можно обойти. Что касается статического анализа, исследователи продемонстрировали серию техник, которые могут обойти текущие доступные инструменты статического анализа [30]. Как будет показано в этой работе, динамический анализ использующий эмуляцию для изучения вредоносных Android-приложений тоже не идеален. Вредоноснаяпрограмма может делать вывод о том, запущена ли она в эмулируемой среде, и вследствии этого уклониться от обнаружения путём приостановки всех вредоносных действий.
Более подробно, в этой статье, рассматривается, как Android-приложения могут делать вывод о том, что они запущены на эмулируемом ARM-процессоре или на реальном устройстве. Вначале создаётся систематика возможных путей для определения особенностей среды выполнения, используя наборы эвристик. Эвристики представленные в данной статье охватывают широкий спектр сложности. Большинство из них простые и им можно помешать простыми изменениями в эмулируемой среде для обмана эвристик, такими как реалистичные значения для статических свойств, например серийный номер устройства (IMEI). Другие же более надёжные, поскольку эмулируемая среда должна предоставлять реалистичные данные от мобильных датчиков, таких как акселерометр. В конечном итоге, тут представлен набор эвристик, для противодействия которому требуется ряд существенных изменений в дизайне эмулируемой среды.
Для оценки важности выводов сделанных в этой статье, был переупакован набор актуальных образов вредоносных приложений. В эти образы были добавлены разработанные эвристики и отправлены в онлайн-инструменты анализа. Как ни странно, но все из протестированных инструментов анализа можно обойти, используя некоторых из представленных эвристик. Не было найдено ни одного сервиса анализа вредоносных приложений, который смог справиться со всеми из протестированных эвристик. Кроме того, по крайней мере 5 из 12 инструментов анализа, которые мы проверили, можно обойти, используя такие простые эвристики как проверка значения IMEI. Более сложные эвристики, основанные на тонкостях работы виртуальных машин, смогли обойти все протестированных сервисов кроме 4. Эти 4 сервиса не поддерживают исполнение машинного кода, и таким образом не могут быть использованы для запуска нашего подмножества Android-приложений. Наконец, все протестированные сервисы уязвимы для эвристик на основе информации от датчиков (сенсоров).
Стоит отметить, что существующие методы анализа вредоносных приложений легко обойти с помощью демонстрации того факта, что актуальные вредоносные приложения могут скрыть вредоносную функциональность от публично доступных сервисов анализа вредоносных приложений. Был предложен набор контрмер для того, чтобы сделать анализ Android-приложений в эмулируемой среде более устойчивым к попыткам его обхода.
2. Техники противодействия анализу
Техники противодействия анализу, которые могут быть использованы в Android-приложениях для обхода обнаружение, можно разделить на три категории: (а) статические эвристики, основанные на статической информации, которая всегда инициализируется фиксированные значения в эмулируемых средах, (b) динамические эвристики, основанные на наблюдении нереального поведения различных датчиков, и (с) эвристики гивервизора, основанные на неполной эмуляции реального оборудования. В таблице 1 приводится краткое описание всех категорий, наряду с некоторыми типичными примерами.
Таблица 1. Краткое описание основных типов эвристик обнаружение виртуальных машин, которые могут быть использованы мобильными вредоносными приложениями, наряду с характерными примерами
2.1. Статические эвристики
Статический набор включает в себя эвристики, которые могут быть использованы для обнаружения эмулированной среды с помощью проверок присутствия или содержащихся значений в уникальных идентификаторах устройств, таких как серийный номер (device ID), текущая версия сборки, значения в таблице маршрутизации.
Серийный номер устройства (device ID). Каждый смартфон содержит IMEI (Международный индентификатор оборудования мобильной станции), который является уникальным номером идентифицирующим его в сетях GSM. IMEI уже использовался вредоносными приложениями для того чтобы помешать анализу с помощью инструментов обнаружения вредоносных программ запущенных в эмуляторах[2]. Другой мобильных идентификатор – это IMSI (Международный идентификатор мобильного абонента), который связан с SIM-картой обнаруженной в телефоне. Простые эвристики уклонения основаны на проверке этих идентификаторов, например, равно ли значение IMEI null, что справедливо для конфигурации эмулятора Android по умолчанию. Для ссылки на данный вид эвристики будет использоваться аббревиатура idH.
Номер сборки. Другой способ идентификации эмулируемой среды — проверка информации, связанной с текущей сборкой, извлекаемой из свойств системы. Например, Android SDK предоставляет публичный класс Build, которые предоставляет информацию о таких полях как PRODUCT, MODEL, и HARDWARE, которые могут быть рассмотрены, для того, чтобы обнаружить, что приложение работает в эмуляторе. Например, стандартный образ Android в эмуляторе имеет значения полей PRODUCT и MODEL равными google_sdk, и значение поля HARDWARE равным goldfish. Были определены несколько эвристик основанные на подобных проверках, на которые далее будем ссылакать с помощью аббревиатуры buildH.
Таблица маршрутизации. Эмулируемые устройства Android по умолчания работает за виртуальным маршрутизатором с адресным пространством 10.0.0.2/24, изолированным от сети целевой машины. Эмулируемый сетевой интерфейс настроен с IP-адресом 10.0.2.15. Конфигурации стандартного шлюза и DNS сервера также содержат фиксированные значения. В данной работе параметры сети используются как ещё одна из эвристик обнаружения. В частности, эвристика проверяет прослушивание сокетов и установку соединения(через /proc/net/tcp), и попытки найти номер порта ассоциированного с адресами 10.0.2.15 и 0.0.0.0., как индикатор эмулируемой среды. Для ссылки на данную эвристику используется аббревиатура netH.
2.2. Динамические эвристики
Мобильные телефоны снабжены различными датчиками, такими как акселерометр, гироскоп, GPS, датчик силы тяжести и т.д. По сути, выходные значения этих датчиков основаны на информации, собранной из окружающей среды, и, следовательно, реалистичная их эмуляция является сложной задачей. Существование датчиков основное различие между смартфонами и традиционными вычислительными системами. Увеличивающееся число датчиков на смартфонах предоставляет новые возможности для идентификации фактических мобильных устройств, и, следовательно, установление различий и обнаружение эмуляторов. Например, есть исследования сосредоточенные на отличительных признаках смартфонов основанных на недостатках и несовершенствах датчиков [3, 20]. Данные подходы, основанные на отличительных признаках, могут быть использованы для обнаружения эмулируемых сред.
По умолчанию, эмулятор Android не поддерживает эмуляцию перемещиний устройства в пространстве; это может быть достигнуто через дополнительные симуляторы датчиков [4]. Текущие сборки эмулятора Android также поддерживают симуляцию других типов датчиков лишь частично или вовсе не поддерживают. При тестировании доступных симулируемых датчиков было обнаружено, что эмулятор генерирует одинаковые значения в равные в среднем интервалы времени по 0.8 секунды с незначительным стандартным отклонением(0.003043 секунды). Функция распределения интервалов времени между событиями акселерометра, наблюдаемая при работе эмулятора Android в течении двух минут, изображена на рисунке 1. Было обнаружено, что эта функция для остальных датчиков придерживается этой же схеме. Эвристики, основанные на датчиках, были реализованы с помощью класса SensorManager [5] из Android API. Была разработана Android Activity(экран приложения), которая пытается зарегистрировать слушателя датчика для отслеживания его выходных значений, используя следующий подход.
Во-первых, происходит регистрация слушателя датчика. Если регистрация не удаётся, то выполнение скорее всего происходит в эмулируемой среде (за исключением случая, когда фактическое устройство не поддерживает конкретный датчик). В противном случае, если регистрация датчика была удачной, происходит проверка значений callback-метода onSensorChanged, который вызывается, когда значения датчика изменяются. Если значения датчиков или наблюдаемых интервалов времени не изменяются при последовательных вызовах этого метода, тогда считается что приложение запущено в эмулируемой среде и производится отмена регистрации слушателя датчика. Были реализованы эвристики основанные на датчиках для акселерометра (accelH), магнитного поля (magnFH), вращения (rotVecH), приближения (proximH) и гироскопа (gyrosH).
Рисунок 1. ФРВ интервалов между событиями акселерометра, наблюдаемая в запущенном эмуляторе Android в течении нескольких минут
2.3. Эвристики гипервизора
Определение переключений контекст QEMU. Данная эвристика связана с механизмом переключения контекст в QEMU [26] и фактом, что QEMU не обновляет значение виртуального счётчика команд (virtual PC) по время выполнения каждой инструкции из-за причин производительности. Поскольку оттранслированные инструкции выполняются на целевой машине, для увеличения виртуального счётчика команд нужна дополнительная инструкция, поэтому достаточно и быстрее обновлять виртуальный счётчик команд только когда выполняется инструкция, которая нарушает линейное выполнение, такая как инструкция перехода. Это значит, если происходит переключение контекста во время выполнения базового блока, будет невозможно посчитать значение виртуального счётчика команд. Из-за этого переключение контекста в среде QEMU происходит только после выполнения базового блока, и никогда во время его выполнения.
Доказательством данной концепции уже разработана техника обнаружения QEMU BT, основанная на гистограмме планирования адресов потока [26]. В неэмулируемых средах может наблюдаться широкий диапазон временных интервалов, когда произошло переключение контекста, поскольку переключение может произойти в любой момент, тогда как в эмулируемой среде, переключение контекста происходит всегда в определённое время, вначале базового блока, поскольку переключение контекста может произойти, только когда выполнение полного базового блока закончено. Данная техника была реализована и использована в проводимых экспериментах в качестве ещё одной эвристики с аббревиатурой BTdetectH. На рис. 2 показаны различия во времени переключения контекста при выполнении этой эвристики в эмуляторе Android и на реальном устройстве.
Рисунок 2. Для оптимизации QEMU не обновляет значение виртуального счётчика комманд после выполнения каждой инструкции, поэтому многие из событий переключения контекста, которые могли иметь место, не нiблюдаются в эмулированной среде
Определение QEMU с помощью выполнение самомодифицирующегося кода. В качестве второй эвристики, была реализована новая техника обнаружения QEMU (под названием xFlowH), основанная на факте, что QEMU не отслеживает модификацию страниц кода. Техника основана на различиях потоков выполнения, вытекающих из-за исполнения самомодифицирующегося кода в эмуляторе и на реальном устройстве.
ARM процессоры содержат два различных кэша, один для доступа к инструкциям (I-Cache) и один для доступа к данным (D-cache). Гарвардские архитектуры (такие как ARM) не обеспечивают когерентность между кэшами данных и инструкций. Поэтому, процессор может выполнять старый (возможно недействительный) участок кода, после того как новый уже записан в основную память. Данная ситуация может быть разрешена соблюдением согласованности между этими двумя кэшами, что может быть достигнуто с помощью двух операций: 1) чистка основной памяти, так что новый код, лежащий в кэше данных перемешается в основную память 2) инвалидация кэша инструкций, так что он может теперь быть заполнен новыми данными из основной памяти. В машинном коде для Android это может быть сделано с помощью вызова функции cacheflush, которая выполняет вышеуказанные операции через системный вызов.
Был реализован пример самомодифицирующегося (машинного) кода, который использует сегмент памяти с правами на выполнение и запись, который перезаписывается несколько раз в цикле содержимым двух различных функций f1 и f2 соответственно. После каждого изменения кода, происходит запуск кода этого сегмента, что по очереди запускает либо f1, либо f2. Это две простые функции, которые обе добавляют своё имя в конец глобальной переменной строки, так что можно сделать вывод о последовательности вызовов функций. Для достижения чередующейся последовательности вызовов, необходимо синхронизировать кэши с помощью вызова cacheflush, как было описано ранее.
Данный код, вместе с дополнительными вызовами для синхронизации после каждого изменения, был запущен на мобильном устройстве и на эмуляторе с одинаковыми результатами – каждый запуск произвел последовательный запуск функций, как и определено в цикле. Затем, был произведён такой же эксперимент, но на этот раз исключили вызов cacheflash. Как и ожидалось, на мобильном устройстве наблюдалась случайная последовательность вызовов после каждого запуска. Поскольку кэши не синхронизируются перед каждым вызовом, кэш инструкций может содержать устаревшие инструкции, поскольку он явно не был признан инвалидным(не действительным). Что интересно, было обнаружено, что данное поведение не наблюдается в эмуляторе. Вместо этого, последовательность вызовов была точно такой же, как и в первом случае, когда кэши были согласованы перед каждым вызовом функции. Такое поведение ожидаемо, поскольку QEMU отбрасывает оттранслированный базовый блок для предыдущей версии кода, и перетранслирует новый сгенерированный код, так как она отслеживает изменения в страницах кода и гарантирует, что сгенерированный код всегда совпадает с целевыми инструкциями в памяти [16].
3. Реализация
Были реализованы эвристики, описанные в разделе 2 с помощью Android SDK. Для BTDetecH и xFlowH был использован Java Native Interface (JNI) для запуска машинного кода, который реализует функциональность каждой эвристики. Было разработано простое Android-приложение (тестовое приложение), которое выполняет предложенные эвристики в фоне и для каждой из них собирает информацию о её эффективности. Собранная информация отправляется на HTTP сервер для сохранения в локальной базе данных. Кроме того, разработанные эвристики были включены в набор известных вредоносных Android-приложений. Для этого мы использовали Smali/Backsmali [7] вместе с Aptktool [8], которые мы использовали для дизассемблирования и повторной сборки (переупаковки приложений). Включение эвристик в вредоносные программы было сделано путём вставки Smali Dalvik байт-кода, сгенерированного с помощью дизассемблера, для каждой эвристики, который был до этого извлечён из разработанных тестовых приложений. Каждое вредоносное приложение было изменено так, чтобы содержать одну из реализованных эвристик, как указано в таблице 2.
Во-первых, каждый оригинальный образец был запущен в эмуляторе и на реальном устройстве, и пронаблюдалось его поведение с помощью команды logcat (системы логирования Android) при запуске главного Активити (экраны приложений), а также сервисов. Впоследствии, в эти компоненты приложения были внесены изменения одной из разработанных эвристик, которые, в зависимости от результатов эвристики, решали останавливать выполнение компоненты или нет.
Таблица 2. Образцы вредоносных приложений, использованные в исследовании
Переупакованные приложения были протестированы в симуляторе и на реальных устройствах для того чтобы убедиться, чтобы вредоносное поведение происходит только на реальном устройстве. Стоить отметить, что кроме вышеуказанных изменений в полученном коде вредоносных приложений, никаких других дополнительных изменений не требуется ни в каких других частях APK файлов, кроме следующих случаев. Эвристика idH требует разрешения READ_PHONE_STATE, явно объявлённого в файле Android манифеста, чтобы иметь возможность считывать состояние телефона. Для эвристик BTDetectH и xFlowH, необходимо создать каталог lib в корневой директории приложения, содержащий требуемый машинный код в виде разделяемых библиотек.
4. Экспериментальная оценка
В этом разделе представлены результаты нашей оценки эффективности эвристик, представленных в разделе 2. Каждая эвристика была добавлена в реальное вредоносное приложение и анализирована с помощью различных сервисов и инструментов динамического анализа. Для каждого случая, происходила запись информации о том, каким эвристикам удалось обнаружить эмулятор и каким нет. Вначале происходит описание набора вредоносных программ и сервисов динамического анализа, использованных в работе, после чего краткий обзор нашей методологии, и в конце представлены и обсуждены полученные выводы.
4.1. Данные и инструменты
Образцы вредоносных приложений. Был добавлен код техник обнаружения, с помощью процесса описанного в разделе 3, в несколько широко известных вредоносных приложений Android. Были использованы 10 образцов из различных семейств вредоносных приложений с различными возможностями, в том числе с эксплоитами повышения привилегий, утечками конфиденциальной информации, СМС-троянами, и так далее. Все протестированные образцы являются публично доступными и являются частью Contagio Minidump [9]. В таблице 2 приведена сводка об использованных образцах вредоносных приложений наряду с эвристиками, использованными в каждом случае.
Сервисы динамического анализа. Сервисы и инструменты динамического анализа, использованные в оценке, приведены в таблице 3. Были использованы как автономные инструменты анализа, доступные для скачивания и локального использования, так и онлайн сервисы, которые анализируют отправленные образцы онлайн.
Были использованы три популярных инструмента для анализа Android-приложений: DroidBox [10], DroidScope [35], и TaintDroid [21]. Все три инструмента выполняют Android-приложение в виртуальном окружении и производят отчёты об анализе. DroidBox предоставляет информацию о входящем/исходящем трафике, операциях чтения/записи, вызываемых сервисах, обходах разрешений приложения, отправленных SMS, сделанных телефонных звонках и т.д. DroidScope выполняет профилирование Android-приложений на уровне вызовов ОС и API, и даёт представление об утечках информации. TaintDroid способен эффективно выполнять общесистемное отслеживание потока данных из нескольких источников конфиденциальных данных.
Таблица 3. Инструменты и сервисы анализа вредоносных приложений Android, использованные в нашей оценке
В дополнение к автономным инструментам, были также использованы публично доступные онлайн-сервисы, которые могут производить динамический анализ Android-приложений, кратко описанные ниже. Andrudis [14] выполняет как статический, так и динамический анализ нежелательных Android-приложений. SandDroid выполняет анализ разрешений/компонент приложения, а также обнаружение/классификацию его вредоносных действий. ApkScan предоставляет информацию, включающую в себя доступ к доступ к файлам, сетевые соединения, телефонные звонки, отправленные SMS, утечки информации, и криптографической деятельности. VisualThreat предоставляет информацию, охватывающую широкий спектр деятельности, начиная от сетевой активности и утечки данных, и заканчивая обнаружение вредоносных семейств приложений с корреляциями API-вызовов. TraceDroid эмулирует некоторые действия при анализе приложения, такие как взаимодействие с пользователем, входящие звонки, SMS сообщения, которые могут обнаружить вредоносные намерения. CopperDroid [31] построен на базе QEMU и «из коробки» может совершать динамический анализ Android-приложений (как на уровне ОС, так и API). APK Analyzer, ForeSafe и Mobile Sandbox [33] также являются сервисами динамического анализа, которые исследуют мобильные вредоносные приложение, следуя подходам упомянутым в выше указанных инструментах.
4.2. Методология
Для оценки эффективности представленных эвристик, были использованы две различных подхода. В первом подходе происходилась отправка экземпляра приложения, содержащего все эвристики, описанные в разделе 3, в каждый онлайн-сервис из нашего набора. В ходе анализа, приложение проверяет эффективность эвристик, применяя их последовательно для заключения того, выполняется ли исполнение в эмулируемой среде или нет. Для каждой проверенной эвристики приложение отправляет результат на HTTP-сервер. После этого, можно определить какие из эвристик были эффективны в выявлении виртуализированной среды, а какие нет.
Для того, чтобы выполнить более реалистичный анализ и продемонстрировать, как такие эвристики могут осложнить работу различных инструментов динамического анализа и не позволить им сделать неправильные выводы, рассмотрим другой подход. Для этого изменяются существующие вредоносные приложение таким образом, чтобы они включали одну эвристику, описанную в разделе 3, и отправляются как оригинальный образец, так и переупакованный в каждый сервис. Затем, собираются сгенерированные отчеты и сравниваются, чтобы найти различия в наблюдаемых поведениях.
Таблица 4. Устойчивость инструментов динамического анализа против техник уклонения от виртуальных машин. «✓» обозначает устойчивость к ним, «✗» обозначает уязвимость к ним и «JNI NS» обозначает отсутствие поддержки JNI(вызова машинных функций из приложений Java)
4.3. Результаты уклонения
Результаты оценки эффективности приведены в таблице 4. Первые три строчки относятся к автономным инструментам анализа, а остальные к онлайн-сервисам анализа. Далее описаны основные выводы, основанные на собранных результатах.
Вывод 1. Все изученные инструменты и сервисы динамического анализа уязвимы для 5 и более эвристик. Как можно видеть в таблице 4, все протестированные инструменты можно легко обойти использую только одну из предложенных эвристик. В частности, только 6 из 12 инструментов являются устойчивыми к простой статической эвристике idH, которая проверяет значение IMEI устройства. Также был обнаружен только один сервис анализа, Apk Analyzer, устойчивым ко всем представленным статическим эвристикам. Кроме того, все сервисы уязвимы для динамических эвристик, которые основаны на использовании датчиков устройства, а также эвристиках гипервизора, которые используют преимущество знаний тонкостей алгоритмов генерации кода QEMU. Обратите внимание, что 4 инструмента (DroidBox, TaintDroid, ApkScan, Apk Analyzer) не поддерживают исполнение машинного кода вовсе, что означает, что невозможно протестировать эффективность эвристик гипервизора на них. Данный вывод был сделан после получения сообщения об исключения при попытке тестового приложения загрузить машинных код через JNI. Все эти сообщения были включены в http-запросы содержащие результаты.
Вывод 2. Всем инструментам анализа не удалось сделать правильный вывод о вредоносном поведении переупакованных образцов вредоносных приложений. Было произведено сравнение всех отчётов, подготовленных вручную при изучении инструментов анализа(как автономных, так и онлайн), придерживаясь нашего второго подхода для оценки, и наблюдаемые результаты согласуются с теми, которые связаны с первой методикой. То есть, переупакованным образцам, содержащим конкретную эвристику, удаётся успешно скрыть их вредоносное поведение и пройти незамеченными от инструментов, которые ранее были обнаружены уязвимыми к этой же эвристике. Это удалось проверять из-за уменьшения числа наблюдаемых инцидентов и деятельности, а также из-за снижения наблюдаемого сетевого трафика.
Вывод 3. Все изученные онлайн-сервисы анализа могут быть охарактеризованы, основываясь на информации о их среде выполнения. Во время анализа не был получен ни одного запрос с результатами от онлайн-сервисов анализа (CopperDroid, Visual Threat и APK Analyzer) при использовании первого подхода. Судя по всему, эти инструменты анализируют приложения в среде с отключённым сетевым подключением. Тем не менее, было обнаружено, что если приложение в процессе анализа пытается записать файл, то его имя будет отражено на странице результатов всех этих инструментов. Таким образом, был использован этот трюк, чтобы протестировать эффективность представленных эвристик с помощью создания файлов со специальными именами, которые будут указывать, была ли конкретная эвристика успешной или нет. Так, с помощью данного подхода, можно сделать вывод о информации об окружающей среде, например информации о сборке, которая может быть использована для характеризации сервисов анализа.
Вывод 4. Только один из изученных инструментов предоставляет информацию о попытках обхода анализа в симуляторе. Было обнаружено путём анализа отчётов, сгенерированных каждым из инструментов анализа, что только Apk Analyzer имеет возможность обнаружение обхода анализа в отправленных образцах, и генерирования соответствующих предупреждений в полученных отчётах (например, была замечено сообщение «Возможно, была попытка обнаружения виртуальной машины, чтобы помешать анализу»). Кроме того, он сообщает о использованных путях для поиска поведения, соответствующего обходу. Например, для переупакованных экземпляров, содержащих эвристики idH и buildH, он упоминает об артефактах виртуальной машины, относящихся к строкам, найденных в памяти во время выполнения образца. Кроме того, эвристика netH также оказалась неэффективно в этом сервисе, поскольку IP-адрес сетевого интерфейса по умолчанию использованного в эмуляторе Android был модифицирован со значение 10.0.2.15 на значение 192.168.0.24. Тем не менее, разработанная нами эвристика netH может быть улучшена, если будет изменена и будет производить поиск произвольного IP-адрес и 0.0.0.0, с которым ассоциирован порт ADB в интерфейсе /proc/net/tcp.
Хотя, Apk Analyzer оказался устойчивым к представленным статическим эвристикам, это не относится к динамическим эвристикам. Действительно, было обнаружено, что достаточно использовать всего одну эвристику, например accelH, в упакованном образце для того чтобы скрыть его поведение от Apk Analyzer’a. Кроме того, было обнаружено, что для всех переупакованных образцов, содержащих динамические эвристики, Apk Analyzer не производит никаких оповещений, связанных с попытками обнаружения виртуальной машины.
5. Контрмеры
Мобильные вредоносные приложения с возможностями обнаружения виртуальной машины могут представлять серьёзную угрозу, поскольку они имеют возможность избежать обнаружения и свести на нет работу инструментов динамического анализа, которые работают на основе эмулятора. Кроме того, Google Bouncer, который является официальным инструментом, используемым для того, чтобы обнаруживать вредоносные приложения, которые могут быть опубликованы в Google Play, основан на динамическом анализе, проведённом в стандартной эмулируемой среде Android на базе QEMU. Google Bouncer также уязвим к техникам обнаружения среды [11]. В этом разделе предложен набор защит, которые могут быть применены в текущей эмулируемой среде Android для того чтобы сделать её более реалистичной.
Модификации эмулятора. Эмулятор Android может быть легко модифицирован для того, чтобы быть устойчивым к представленным статическим эвристикам. Идентификаторы мобильного устройства, такие как IMEI и IMSI, которые используются нашей эвристикой idH, могут быть настроены в эмуляторе Android. С помощью просмотра и анализа исходного кода сервиса «Telephony Manager» в эмуляторе Android, можно найти место, где происходит эмуляция устройства модема, которое реализуется в рамках QEMU [12]. Таким образов IMEI и IMSI могут быть легко модифицированы так, чтобы эмулятор напоминал реальное устройство. Эвристику buildH, которая использует информацию о текущей сборке, можно легко обмануть, изменив свойства сборки, загружаемые в эмулятор Android. Эти свойства определены в файле build.prop исходного кода эмулятора Android. Наконец, сетевые настройки по умолчанию эмулятора Android могут быть модифицированы для защиты от эвристики netH, также как это сделано в Apk Analyzer.
Реалистичная эмуляция событий от датчиков. Второй набор эвристик, динамических эвристик, основан на различных датчиках, поддерживаемых мобильным устройством. Как уже упоминалось, эмулятор Android поддерживает тривиально обнаружимую симуляцию датчиков с событиями датчиков, происходящими через точные интервалы времени, и получаемыми значениями, не меняющимися между последовательными событиями. Все динамические эвристики (accelH, magnFH, rotVacH, proximH и gyroH) основаны на таком поведении. Для того чтобы сделать все динамические эвристики неэффективными нужна лучшая симуляция датчиков. Тем не менее, реалистичная симуляция таких аппаратный компонентов является сложной задачей и требует углублённых знаний как в диапазонах значений, которые могут быть произведены устройством, так и реалистичных моделях взаимодействия с пользователем. В данном контексте, могут быть использованы внешние программы-симуляторы [4] или решения записи и воспроизведения [23] для того, чтобы симулировать данные датчиков в реальном времени как дополнительную компоненту эмулятора Android.
Точная двоичная трансляция. Бинарная двоичная трансляция, используемая в QEMU, на которой основана эвристика BTdetectH, является важной операцией в эмуляторе Android, во время которой каждая инструкция ARM транслируется в эквивалентную инструкцию x86 для того, чтобы было возможном исполнение на целевой машине на базе x86. Эвристика BTdetectH, описанная ранее в разделе 2, основана на фундаментальной операции эмулятора Android, которую очень сложно изменить. Один из способов исправить эту проблему, сделать процесс бинарной трансляции QEMU более точным к реальному исполнению, использованному в процессоре устройства. То есть, виртуальный счётчик команд должен всегда обновляться после инструкции, как происходит, когда инструкция исполняется в процессоре. Таким образом, это требует пересмотра и расширения текущей операция бинарной трансляции в QEMU. С другой стороны, такой подход будет производить более высокую нагрузку на исполнение, что сделает QEMU, а следовательно и эмулятор Android, легко обнаружимым (например, путем сравнения различных времён исполнения для конкретных операций, наблюдаемых в эмуляторе и реальном устройстве).
Поддержка аппаратной виртуализация. Ещё один способ справиться с данным вопросом заключается в использовании поддержки аппаратной виртуализации, которая основана на архитектурной поддержке, которая способствует созданию монитора виртуальных машин, и позволяющей гостевым операционным системам запускаться в изоляции друг от друга. Например, развивающая технология поддержки аппаратной виртуализации ARM [15] может быть использована, чтобы избежать процесса бинарной трансляции и проблем связанных с ней. Заменив инструкцию эмуляции (QEMU) такой технологией, эвристики BTdetecH и xFlowH, которые основаны на таких тонкостях виртуальных машин, станут неэффективными.
Смешанное выполнение приложений. Кроме того, другим решением для эвристик гипервизора было бы использование реальных мобильных устройств для выполнения приложений, содержащих машинный код. Обе эвристики (BTdetecH и xFlowH) требуют выполнения машинного кода для своей работы. Смешанное выполнение приложения будет наиболее безопасным и эффективным способом для инструмента динамического анализа, для уклонения от всех предложенных эвристик. То есть, байт-код приложения может быть запущен в изменённой версии эмулятора Android, экранированной всеми мерами защиты, описанными выше; когда приложение пытается загрузить или запустить машинный код, тогда выполнение машинного кода, может быть перенаправлено и состояться на реальном устройстве.
6. Связанные работы
Растоги и другие [30] сделали оценку лучших коммерческих антивирусных продуктов против различных методов обфускации доступных для Android устройств. Основываясь на их результатах, все протестированные продукты оказались уязвимы для распространённых методов обфускации. Их исследование было основано на статических инструментах анализа. В отличие от них, в данной работе был использован аналогичный подход для оценки динамических инструментов анализа для Android. Савар и другие [32] утверждают, что динамическое отслеживание помеченных данных является неэффективным для выявления утечек конфиденциальных данных во вредоносных приложениях Android, а также реализовали комплекс атак против TaintDroid, которые могут быть использованы вредоносным приложением, чтобы уйти от отслеживания его данных. В данном исследовании также был использован TaintDroid для оценки эффективности представленных эвристик.
Существуют многочисленные исследования, направленные на обход виртуальных машин в обычных системах. Раффетседер и другие [29] представили ряд методов для обнаружения системных эмуляторов. Их методов используют различные особенности, такие как специфические ошибки процессоров, регистры MSR, пределы длин инструкций, измерения относительной производительности и многие другие. Вильемс и другие [34] представили иной подход состоящий в выведении кодовых последовательностей, которые неявно имеют различное поведение в реальной машине и эмуляторе. Эти техники основаны на побочных эффектах конкретных операций и несовершенстве процесса эмуляции (например, приложения могут идти по различных путям потока управления, если они эмулируются на архитектурах, которые поддерживают самомодифицирующийся код), и очень близки к подхо
