Зловреды в метаданных

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

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

На сей раз моё внимание привлекло обнаружение множества PHP-бэкдоров с нетипичными расширениями, таких как JPG и MP3. Возможно, ложное срабатывание? Стоит присмотреться!

Некоторые из этих случаев представляли собой образцы обфусцированного кода PHP, реализующие широко известный C99Shell под другим расширением – в данном случае JPG или MP3:

Можно также найти случаи, когда код JavaScript и iframe цепляются к концу легитимных JPG-файлов:

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

В случае, когда к файлу цепляются iframe, изображения выводятся корректно (JPEG – это действительно гибкий формат), но iframe исполняться не будет. Зачем же его туда поместили? Да ни за чем, просто автоматические скрипты цепляют этот iframe к концу любого файла, найденного на веб-сервере, когда атакующая сторона получает к нему доступ – возможно, используя автоматические инструменты.

Однако в некоторых JPG-файлах я нашёл кое-что реально интересное.

Эти строки соответствуют EXIF-данным изображения.

Обратите внимание на данные EXIF JavaScript в поле Modelo del dispositivo («модель устройства»), а также на строку «/.*/e» в поле Marca del dispositivo («производитель устройства»).

Этот код JavaScript преобразуется в:

Получается, что эта строка оценивает, проходит ли она через параметр zz1 заголовка POST. Но это ведь картинка, как же выполняется этот код? Благодаря PHP-функции exif_read_data…

PHP-функция preg_replace интерпретирует содержимое как  PHP-код благодаря строке «/e» в поле «производитель» в EXIF-данных. Из-за этого выполняется код eval во второй строке («модель устройства»). Таким образом, это по сути бэкдор, исполняющий любую команду внутри параметра zz1 заголовка POST.

Начиная с версии PHP 5.5.0 параметр «/e» не поддерживается. Это хорошая новость.

Таким образом, мы имеем дело с двукомпонентным бэкдором: он состоит из JPEG-файла с вредоносными EXIF-данными и PHP-кода, который его исполняет.

Этот PHP-код легко засунуть в любой другой PHP-файл, который найдётся на сервере; он может остаться незамеченным во время быстрого сканирования.

Это изображение прекрасно интерпретируется – код JavaScript не влияет на визуализацию, поскольку это только EXIF-данные:

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

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

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

Благодаря KSN мы можем посмотреть географическое распределение обнаружений:

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

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

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