Программист
0,0
рейтинг
2 ноября 2015 в 18:01

Разработка → Бунт против виртуальной машины из песочницы

Предлагаю вашему вниманию перевод статьи 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 не обновляет значение виртуального счётчика комманд после выполнения каждой инструкции, поэтому многие из событий переключения контекста, которые могли иметь место, не наблюдаются в эмулированной среде

Определение 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] представили иной подход состоящий в выведении кодовых последовательностей, которые неявно имеют различное поведение в реальной машине и эмуляторе. Эти техники основаны на побочных эффектах конкретных операций и несовершенстве процесса эмуляции (например, приложения могут идти по различных путям потока управления, если они эмулируются на архитектурах, которые поддерживают самомодифицирующийся код), и очень близки к подходу использованному в эвристике xFlowH.

Палеари и другие [27] представили автоматический способ генерации «красных пилюль», кусков кода, способных обнаружить запускаются они в эмулируемом процессоре или физическом. Их подход был реализован в качестве прототипа, который был использован для открытия новых «красных пилюль», включающих сотни различных кодов инструкций, для двух эмуляторов процессора: QEMU и BOCHS. Линдорфер и другие [24] представили DISARM, систему обнаружения вредоносных приложений чувствительных к среде выполнения. Образец вредоносного приложения запускался в различных песочницах анализа, и поведение, наблюдаемое в различных песочницах анализа, сравнивалось для того, чтобы обнаружить вредоносные приложение с техниками уклонения от анализа. Все эти исследования предлагают техники, которые могут быть использованы вредоносными приложениями для обнаружения виртуализированных сред x86. Представленное в данное статье исследование предлагает аналогичные методы, которые могут быть использованы в мобильных вредоносных приложения и, в частности, в вредоносных приложениях для Android (в основном относящихся к архитектуре ARM).

7. Заключение


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

Список использованной литературы


[1] googlemobile.blogspot.com/2012/02
android-and-security.html.
[2] vrt-blog.snort.org/2013/04/changingimei-provider-model-and-phone.html.
[3] blog.sfgate.com/techchron/2013/10/10
stanford-researchers-discover-alarmingmethod-for-phone-tracking-fingerprintingthrough-sensor-flaws/.
[4] code.google.com/p/openintents/wiki
SensorSimulator.
[5] developer.android.com/reference
android/hardware/SensorManager.html.
[6] bluebox.com/corporate-blog/androidemulator-detection.
[7] code.google.com/p/smali.
[8] code.google.com/p/android-apktool.
[9] contagiominidump.blogspot.com.
[10] code.google.com/p/droidbox.
[11] www.duosecurity.com/blog/dissectingandroids-bouncer.
[12] codepainters.wordpress.com/2009/12/11
android-imei-number-and-the-emulator/.
[13] 99% of all mobile threats target Android devices. www.
kaspersky.com/about/news/virus/2013/99_of_all_
mobile_threats_target_Android_devices.
[14] Anubis/Andrubis: Analyzing Unknown Binaries. http://
anubis.iseclab.org/.
[15] Arm: Virtualization extensions. www.arm.com
products/processors/technologies/
virtualization-extensions.php.
[16] QEMU Internals. ellcc.org/ellcc/share/doc
qemu/qemu-tech.html.
[17] T. Bläsing, A.-D. Schmidt, L. Batyuk, S. A. Camtepe, and
S. Albayrak. An android application sandbox system for suspicious
software detection. In MALWARE, 2010.
[18] Bramley Jacob. Caches and Self-Modifying Code. http://
community.arm.com/groups/processors/blog/2010/
02/17/caches-and-self-modifying-code.
[19] J. Calvet, J. M. Fernandez, and J.-Y. Marion. Aligot: cryptographic
function identification in obfuscated binary programs. In CCS, 2012.
[20] S. Dey, N. Roy, W. Xu, and S. Nelakuditi. Acm hotmobile 2013
poster: Leveraging imperfections of sensors for fingerprinting
smartphones. SIGMOBILE Mob. Comput. Commun. Rev., 17(3),
Nov. 2013.
[21] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel,
and A. N. Sheth. Taintdroid: An information-flow tracking system
for realtime privacy monitoring on smartphones. In OSDI, 2010.
[22] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A study of
android application security. In USENIX Security,, 2011.
[23] L. Gomez, I. Neamtiu, T. Azim, and T. Millstein. Reran: Timingand touch-sensitive record and replay for android. In ICSE, 2013.
[24] M. Lindorfer, C. Kolbitsch, and P. Milani Comparetti. Detecting
environment-sensitive malware. In RAID, 2011.
[25] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. CHEX: Statically Vetting
Android apps for Component Hijacking Vulnerabilities. In CCS,
2012.
[26] F. Matenaar and P. Schulz. Detecting Android Sandboxes. http://
www.dexlabs.org/blog/btdetect.
[27] R. Paleari, L. Martignoni, G. F. Roglia, and D. Bruschi. A fistful of
red-pills: how to automatically generate procedures to detect cpu
emulators. In WOOT, 2009.
[28] T. H. Project. Android Reverse Engineering (A.R.E.) Virtual
Machine. www.honeynet.org/node/783.
[29] T. Raffetseder, C. Kruegel, and E. Kirda. Detecting system
emulators. In ISC, 2007.
[30] V. Rastogi, Y. Chen, and X. Jiang. Droidchameleon: evaluating
android anti-malware against transformation attacks. In ASIA CCS,
2013.
[31] A. Reina, A. Fattori, and L. Cavallaro. A system call-centric analysis
and stimulation technique to automatically reconstruct android
malware behaviors. In EUROSEC, 2013.
[32] G. Sarwar, O. Mehani, R. Boreli, and D. Kaafar. On the effectiveness
of dynamic taint analysis for protecting against private information
leaks on android-based devices. In SECRYPT, 2013.
[33] M. Spreitzenbarth, F. Freiling, F. Echtler, T. Schreck, and
J. Hoffmann. Mobile-sandbox: Having a deeper look into android
applications. In SAC, 2013.
[34] C. Willems, R. Hund, A. Fobian, D. Felsch, T. Holz, and
A. Vasudevan. Down to the bare metal: Using processor features for
binary analysis. In ACSAC ’12, 2012.
[35] L. K. Yan and H. Yin. DroidScope: Seamlessly reconstructing the
OS and Dalvik semantic views for dynamic Android malware
analysis. In USENIX Security, 2012
Михаил @melon
карма
9,0
рейтинг 0,0
Программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (18)

  • +1
    Итого: гонять надо на реальном железе, подключенном по JTAG?
    • 0
      как один из вариантов. Но JTAG есть далеко не во всех мобильниках(производители его отключают насколько мне известно), а вирусописатели могут затачиваться под конкретные уязвимости в прошивках определённых устройств.
  • 0
    А подход, аналогичный BOCHS — т.е. точная эмуляция аппаратуры, пусть медленнее, чем в реальном мире, но зато для виртуальной машины это выглядит как работа с нормальной скоростью, а значения датчиков туда вообще отправлять записанные с реального устройства? Вроде все эти эвристики должны сливать — как это можно обнаружить, если эмулятор «не палится» (не использует хорошо известных фиксированных значений, подставляет реальные или реалистичные идентификаторы на место IMEI и т. д.)?
    • –1
      в разделе 2.3. написано как определяют QEMU с помощью самомодифицирующегося кода и по работе механизма переключения конктекста.
      • 0
        Подход QEMU отличается от подхода BOCHS. Я про второй — там идея в том, чтобы точно сэмулировать поведение аппаратуры, как бы это неэффективно в смысле производительности ни оказалось.
        • 0
          Википедия говорит, что на эмуляцию 1 такта виртуального процессора уходит 260 тактов физического процессора. Если я правильно понимаю, это замедление в 260 раз, я думаю это будет оооочень медленно. Но да, с таким подходом, мы палиться не будем палиться, если только приложение не завязано на каком-нибудь взаимодействии со внешним миром(по сети например). Именно поэтому сейчас смотрят в сторону применения гипервизоров, а не виртуальных машин в этой области, потому что они дают маленький оверхед и могут быть запущены на реальном устройстве, чтобы не эмулировать всю эту аппаратуру, потому что спецификаций нету и на эмуляцию могут уйти годы. А устройства клепаются сейчас достаточно быстро. systems.cs.columbia.edu/projects/kvm-arm — вот эти ребята из Columbia University пилят. Мне почему-то кажется, что за этим подходом будущее, хотя полная и точная эмуляция аппаратуру это тоже круто конечно!
          • 0
            А зачем поддерживать эмуляцию всех фич всех новых устройств, если мы таким способом собираемся тестировать прикладное ПО? Достаточно, чтобы оно запускалось и работало на эмулируемой платформе.
            • 0
              Всё зависит от задачи которая перед нами стоит. Если мы хотим запустить конкретный эксплоит, то он может быть завязан на уязвимостях конкретной прошивки устройства, а это значит нам нужно запускать на нём. Ведь как показывает практика 70% уязвимостей Android — это уязвимости в прошивках устройств от вендоров. Официальный Android не такой дырявый и достаточно постоянно обновляется.
  • +1
    С другой стороны, такой подход будет производить более высокую нагрузку на исполнение, что сделает QEMU, а следовательно и эмулятор Android, легко обнаружимым (например, путем сравнения различных времён исполнения для конкретных операций, наблюдаемых в эмуляторе и реальном устройстве).
    Так можно и время тикать подопытному медленнее. Ну и другие операции типа i/o тоже замедлить. В итоге если хорошо подобрать все коэффициенты замедления, то отличить будет очень сложно.
    • 0
      Согласен, но представь если у нас замедленее в 10 раз и в приложение соединяется по сети и на сокетах установлен тайм-аут и если у нас очень медленно работает приложение сокеты вылетают по тайм-ауту. Или же значения времени берётся по зашифрованному каналлу по сети. Так что и да, и нет одновременно.
      • 0
        Так ведь и сеть может быть ненастоящая, с задержками специально подобранными!
        Ну или вместо гигабитного 4G будет канал через VPN по Bluethooth с сервером на другом полушарии.

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

        Существует печальный пример защиты от копирования Starforce, в том числе использовавшей измерения времён доступов к приводу для различения виртуальных и реальных.

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

        • +1
          Согласен, многие недостатки указанные в статье можно исправить. Правда второй тест с самомодифицирующимся кодом исправить намного сложнее чем тест с прерываниями, и поскольку я не специалист в бинарной трансляции я не скажу как, хотя возможно уже есть решения. Данная же статья лишь отражает текущее положение дел и показывает векторы развития. На текущий момент мы имеем что все песочницы «палятся». Особенно печальным мне кажется что палится Google Bouncer, которым проверяют приложения в маркете. А это значит залить вредоносное приложение в маркет не составляет труда. Обфусцировать его, чтобы никто не догодался что на самом деле делает приложение и ву-а-ля, отличный вектор атаки.
          • 0
            > Правда второй тест с самомодифицирующимся кодом
            А вот это вообще уже не тест, а криминал — софт использует неопределённое поведение железа. При отсутствии вызовов cacheflush в исполняться будет не f1 или f2, а чаще всего смесь этих функций — часть байт из одной, часть — из другой, т.е. мусор. Опять же содержимое страницы будет зависеть от размера кэш-линии, политик вытеснения и замещения, иерархии кэшей, т.е. от марки ЦПУ, вендора, варианта микроархитектуры и прочих факторов. Да и вообще кэш может быть вырублен.
            Т.е. на одной железке это будет работать, а на другой — нет. Ложноположительные срабатывания на аппаратуре, отличной от использованной при разработке, обеспечены.

            • 0
              мне кажется функция достаточно маленькая и умешается в одну страницу кэша, хотя я могу ошибаться. Так что варианта, что будет испольняться часть кода одной функции и часть другой мне кажется не будет. Самомодифицирующийся код никакой не криминал, а нормальная ситуация для малвари. Если этот код будет работать на более чем 50% устройств, я думаю авторов малвари это устроит) Но мне всё же кажется, что поведение на реальном оборудовании всегда будет отличаться от поведения в эмуляторе, потому что кэш на реальном устройстве не обновляется сразу и я не верю в то, что он может быть выключен, потому что иначе всё будет работать дико медленно и такие телефоны и устройства вряд ли кому нужны.
              • 0
                >мне кажется функция достаточно маленькая и умешается в одну страницу кэша
                Если размер линии определён архитектурно, то да. В таком случае Qemu может повторять логику железа и просто моделировать кэш-линии. Это будет несколько накладно, однако вполне реализуемо. Симулятор уже следит за страницами, может следить и за более мелкими единицами, особенно если они связаны с кодом, а не с данными.
                Если размер кэш-линии не задан архитектурно, то он может быть и 2 байта, и 16, и 1024, и 8192. Нельзя думать, что если сейчас все кэш-линии размером в 16 байт, то завтра (буквально завтра, как часто и бывает!) не будет выпущена серия процов с размеров кэш-линии в 8 байт или в 64 байта.

                > Самомодифицирующийся код никакой не криминал
                Дело не в SMC, а в отсутствии гарантий на когерентность содержимое кэша и памяти. SMC не только для малвари нужен. Опять же, где гарантии, что на аппаратуре «на мобильном устройстве наблюдалась случайная последовательность вызовов» — ведь последовательность f1 f1 f1 f1 f1 f1 f1 тоже вполне валидная выборка для случайной последовательности. Т.е. опять же требуется проверка статистической гипотезы. Но нужно отметить, что этот противоотладочный метод известен довольно давно, значит, он на практике эффективен.

                >поведение на реальном оборудовании всегда будет отличаться от поведения в эмуляторе
                never say «never». Дело в том, что чёткой границы «симулятор-реальность» не существует.

                > я не верю в то, что он может быть выключен
                Это да, кэш никто в здравом уме на телефонах отключать не будет. Но вот от девайса к девайсу его характеристики и алгоритмы могут отличаться в разы.
                • 0
                  Механизм работы бинарной трансляции устроен таким образом, что он отслеживает изменения оперативной памяти и оттранслированный блок сразу аннулируется и вытесняется из кэша, как только произошло изменение памяти на которую он ссылался. Именно поэтому в эмуляторе всегда будет f1 f2 f1 f2 f1 f2. Да, я согласен что это поведение также можно изменить, просто это сложнее и тут нужно хорошее понимание алгоритма бинарной трансляции. Но ничего невозможно нет, тут ты прав) И никогда не говори никогда, тоже соглашусь с тобой. Про «случайную последовательность» я думаю они имели ввиду, что на их устройствах так. Но даже если будет f1 f1 f1 f1 f1, мы сможем отличить её от последовательности эмулятора f1 f2 f1 f2 f1 f2. Гарантий что это будет работать устройствах я дать не могу, как и авторы статьи вроде бы тоже их не дают. Они дают всего лишь набор эвристик, которые работают у них.
                  • 0
                    >что он отслеживает изменения оперативной памяти и оттранслированный блок сразу аннулируется и вытесняется из кэша
                    Можно привязать инвалидацию блоков трансляции к выполнению той самой инструкции cacheflush, а до того момента задерживать перетрансляцию кода в модифицированных секциях. Такое поведение, как и оригинальное с энергичной инвалидацией, будет удовлетворять спецификациям аппаратуры, которая не гарантирует консистентности кода до выполнения cacheflush, но и не запрещает её. Даже может быть в производительности чуть-чуть выиграем. Но соглашусь, такой путь усложняет модель.
  • 0
    Не рекламы ради. Моя подруга из университета Люксембурга ищет как-раз PhD студента (аспиранта по-нашему) и Post-Doc'а на проект, основная цель которого как-раз определять вирусы, в которых содержится подобная функциональность (context-sensitive mobile malware detection). Знаю, что здесь очень много толковых ребят, так что если есть интерес, то пишите мне в личку — дам подробные объяснения и контакты.

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