К чему приводит публикация PoC

Мечта злодея

Две ключевые особенности системы защиты ОС Android заключаются в том, что:

1. На чистом устройстве нельзя произвести скачивание файла незаметно от пользователя;
2. На чистом устройстве нельзя инициировать установку приложения из стороннего источника без ведома пользователя.

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

Скрытная установка вредоносного приложения на мобильное устройство без участия пользователя наверняка является мечтой многих вирусописателей. Чтобы это проделать, необходимо найти и проэксплуатировать уязвимость в системе Android. И такие уязвимости уже были обнаружены ранее, речь идет о CVE-2012-6636, CVE-2013-4710, CVE-2014-1939.

Эти уязвимости позволяют выполнить произвольный код на устройстве при помощи специально созданной HTML-страницы с JavaScript. И они уже давно закрыты – начиная с Android 4.1.2.

Хотелось бы тут сказать, что все хорошо, но – увы – это не так. Не стоит забывать о третьей особенности ОС Android: созданием и распространением обновлений для той или иной модели устройства управляет изготовитель устройства.

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

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

Публичное детальное описание уязвимостей для Android вооружает вирусописателей нужными им знаниями. При этом потенциальные жертвы эксплуатации уязвимости могут оставаться таковыми продолжительное время – назовем это бесконечным 0-day. Решить проблему может только покупка нового гаджета.

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

Заражение сайтов

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

Способ размещения вредоносного кода и другие особенности атаки позволяют выделять сайты, зараженные одной и той же «инфекцией». Довольно долго мы наблюдали характерную инфекцию на группе, как минимум, из нескольких десятков российских сайтов различной направленности и посещаемости, включая довольно известные и популярные ресурсы (например, сайты с суточной аудиторией примерно в 25000 и 115000 пользователей). Заражение сайтов из этой группы характеризуется использованием одних и тех же промежуточных доменов, идентичностью как самого размещаемого на них вредоносного кода, так и способа его размещения (код размещается в большинстве случаев в отдельном JavaScript-файле на том же домене), а также быстротой и синхронностью изменений кода на всех зараженных сайтах после его детекта.

Схема атаки была стандартной (хотя и претерпевала некоторые изменения) и использовалась по крайней мере с 2014 года. Стандартной она была в том числе и потому, что была ориентирована на пользователей ОС Windows. Однако, некоторое время назад, после очередного изменения злоумышленниками кода на зараженных сайтах, мы обнаружили вместо «обычного» скрипта, загружающего Flash-эксплойты, новый. Он проверял наличие подстроки «Android 4» в user-agent и оперировал инструментами, не характерными для Windows. Эта странность побудила нас тщательно изучить его функционал и пристальней понаблюдать за инфекцией.

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

Скрипты

Нам удалось обнаружить два основных варианта скрипта.

Скрипт 1: отправка SMS

Единственная задача первого скрипта – отправка на номер злоумышленников SMS с текстом «test». Для этого вирусописатели воспользовались возможностями клиента Android Debug Bridge (ADB), который присутствует на всех устройствах. Скрипт исполняет команду на уточнение версии ADB на устройстве, используя демон Android Debug Bridge (ADBD). Результат исполнения этой команды отправляется на сервер злоумышленников.

Код отправки SMS закомментирован, в реальности он не запустится. Однако если его раскомментировать, то устройства с Android младше 4.2.2 могли бы выполнить команды вирусописателей. На более новых версиях соединение с ADBD локально (в режиме Loopback) на устройстве запрещено.

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

С первым вариантом скрипта у пользователей не должно было возникнуть больших проблем, даже если бы злоумышленникам удалось отправить SMS на короткий номер. У большинства сотовых операторов существует механизм Advice-of-Charge, при котором первичная SMS на премиальный номер не тарифицируется – нужно отправить еще одно сообщение с определенным текстом. В данном случае сделать это из JavaScript невозможно. Поэтому, видимо, и появился второй вариант скрипта.

Скрипт 2: файл на SD карте

Второй скрипт по сути – дроппер, он выбрасывает из себя на SD карту вредоносный файл.

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

Затем строка записывается на SD карту в файл MNAS.APK:

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

Однако пока этот код тоже закомментирован.

Рассмотрим более внимательно сам скрипт. В скрипте реализована проверка на нужную версию Android (должна быть 4).

Очевидно, что вирусописатели знают, какие версии уязвимы, и не пытаются запустить скрипт на Android 5 или 6.

Так же, как и в первом скрипте, во втором реализована проверка версии ADB на стороне центра управления:

В данном случае проверка ни на что не повлияет, однако версия ADB действительно существенна, так как не все версии поддерживают локальное соединение с ADBD.

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

Так, некоторые ранние версии скрипта отправляют центру управления информацию о каждой выполненной команде:

В данном случае производится проверка на наличие файла MNAS.lock на SD-карте, если его там нет, то скрипт при помощи утилиты touch пытается создать файл MNAS.APK нулевого размера.

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

В результате выполнения команды ECHO на SD-карте создается вредоносный APK-файл.

Троянец

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

Выбрасываемый из скрипта APK-файл детектируется «Лабораторией Касперского» как Trojan-Spy.AndroidOS.SmsThief.ay. С начала 2016 года нам удалось найти четыре версии этого троянца.

В коде троянца вирусописатели используют имя «example.training»:

При этом вредоносный файл обладает достаточными возможностями для проведения полноценных атак на кошелек жертвы посредством отправки SMS:

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

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

Также перехваченные сообщения будут отправлены на сервер злоумышленников:

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

Управляющий номер изначально присутствует в коде зловреда:

Троянец ждет определенных команд от центра управления и в SMS от управляющего номера.

С сервера злоумышленников может прийти команда на изменение управляющего номера:

С управляющего номера могут прийти следующие команды:

• SEND – отправить SMS на указанный номер с указанным текстом;
• STOP – прекратить перенаправление SMS;
• START – начать перенаправление SMS.

Пока функциональность троянца сводится к перехвату и отправке SMS-сообщений.

Заключение

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

Интерес вирусописателей к drive-by атакам на мобильные устройства вряд ли уменьшится, и они продолжат искать способы реализации таких атак.

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

Также очевидно, что как бы ни прельщала исследователей публикация 0-day уязвимости, стоило бы воздержаться от детальных примеров эксплуатации (Proof of concept). Публикация таких примеров с большой вероятностью приведет к созданию рабочей версии зловреда.

Хорошая новость для владельцев старых девайсов: наше защитное решение Kaspersky Internet Security имеет возможность проверять изменения на SD-карте в реальном времени и удалять вредоносный код, как только тот будет записан на SD-карту. Поэтому наши пользователи защищены от известных «Лаборатории Касперского» угроз, доставляемых методом drive-by-download.