Как не нужно писать софт или сказ о том, как работают антивирусные лаборатории

Агиевич Игорь (https://twitter.com/shanker_sec)

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

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

Рисунок 1.

Приложение состояло из:

• Клиентского ПО. Его задача - синхронизировать данные (файлы, переписку) с облаком. Загружать обновления, логировать возникшие ошибки (сбор информации о системе, код ошибки и отправка на веб-сервер).
• Скриптов web-сервера. Его задача – управлять потоком данных от клиентов, и так же логирование ошибок. Логирование ошибок включало в себя проверку корректности HTTP-запроса в соответствии с правилами и сохранение тела ошибочного запроса.

Через некоторое время в логах ошибок веб-сервера начали появляться следующие записи:

Remote IP: 109.74.154.83
User-agent : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
REQUEST_METHOD : GET
HTTP_ACCEPT : */*

User-Agent с точки зрения нашего приложения 100% не валидный, IP-адрес не относится к нашей организации. GeoIP выдаёт по этому IP Словакию. Первая мысль, что какие-то хакеры собрались поломать наш бедный сервер! Решили посмотреть вывод nslookup по обнаруженному IP. Тут и началось самое интересное. Дальнейшая работа по отладке проблем превратилась в настоящий цифровой триллер. На самом деле, была уверенность, что будет какой-нибудь proxy\VPN провайдер или VDS и т.д. Но в реальности все оказалось веселей:

General Information
Hostname
109-74-154-83.ptr.eset.com
IP
109.74.154.83
Preferable MX
a.mx.eset.com

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

Решили посмотреть другие записи логов:

Remote IP: 193.71.68.2
User-agent : Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.4) Gecko/20100513 Firefox/3.6.4
QUERY_STRING :
HTTP_REFERER:
REQUEST_METHOD : HEAD
HTTP_ACCEPT : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_LANGUAGE :
HTTP_ACCEPT_CHARSET :

Воспользуемся командой nslookup в Ubuntu:

nslookup 193.71.68.2
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
2.68.71.193.in-addr.arpa name = norman.norman.no.

Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: norman.no
Address: 87.238.40.68
Name: norman.no
Address: 193.71.68.1

Т.е. этот запрос пришёл из сети, приписанной к антивирусу Norman.

Следущая запись:

Remote IP: 150.70.172.108
User-agent : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
QUERY_STRING :
HTTP_REFERER:
REQUEST_METHOD : GET
HTTP_ACCEPT : */*
HTTP_ACCEPT_LANGUAGE : en-us
HTTP_ACCEPT_CHARSET :
HTTP_X_FORWARDED_FOR : 150.70.172.108

Делаем привычный запрос nslookup:

$ nslookup 150.70.172.108
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
108.172.70.150.in-addr.arpa name = 150-70-172-108.trendmicro.com

Спустя несколько часов опять trendmicro:

Remote IP: 150.70.64.197
User-agent : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
QUERY_STRING :
HTTP_REFERER:
REQUEST_METHOD : GET
HTTP_ACCEPT : */*
HTTP_ACCEPT_LANGUAGE : en-us
HTTP_ACCEPT_CHARSET :
HTTP_X_FORWARDED_FOR : 150.70.64.197

Обратите внимание: в HTTP-запросах заполнены только поля User-agent. И, иногда, HTTP_ACCEPT или HTTP_ACCEPT_LANGUAGE. Чего маловато для настоящих браузеров.

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

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

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

На веб-сервер начали приходить логи ошибок от клиентского ПО, установленного непонятно где. И этих данных было достаточно, чтобы подкрепить ранее высказанную догадку.

Лог ошибок клиентского модуля содержал в том числе результаты выполнения команд: ipconfig,dir C:, dir D:, systeminfo, tasklist (функционал был добавлен в наше ПО для упрощения воссоздания окружения при отлове бага).

Результат ipconfig с одного из клиентов:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter
Physical Address. . . . . . . . . : 00-50-56-8E-01-10
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.100.136
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.100.254
DNS Servers . . . . . . . . . . . : 8.8.8.8

Здесь видно, что используется решение виртуализации на базе VMware. Да и MAC-адрес 00-50-56-*-*-* через публичные сервисы можно привязать к Vmware.

Дальше — ещё интереснее. Результат dir C:, dir D: с другого клиента:

Volume in drive C has no label.
Volume Serial Number A489-F54E
Directory of c:\
04/16/2010 12:25 0 AUTOEXEC.BAT
04/16/2010 12:25 0 CONFIG.SYS
04/16/2010 12:27 <DIR> Documents and Settings
04/12/2012 13:17 459,982 A0iYkCc.exe
04/16/2010 12:27 <DIR> Program Files
12/11/2011 13:02 <DIR> WINDOWS
3 File(s) 459,982 bytes
3 Dir(s) 8,396,890,112 bytes free
Volume in drive D CDROM
Volume Serial Number D792-AEDF
Directory of d:\
04/12/2012 13:17 33 AUTORUN.INF
04/12/2012 13:17 252 RUN.BAT

04/12/2012 13:17 114 RUN.VBS
04/12/2012 13:17 459,982 SAMPLE.EXE
4 File(s) 459,982 bytes
0 Dir(s) 0 bytes free

Видно, что наш бедный файл был размещен на эмуляторе CD-диска и приобрел имя SAMPLE.EXE. Также был скопирован на диск C: со случайным именем.

Результат systeminfo:

Название ОС: Microsoft Windows XP Professional
Версия ОС: 5.1.2600 Service Pack 3 Build 2600
Дата установки: 2010-4-29, 5:35:19
Изготовитель системы: Red Hat
Модель системы: KVM
Тип системы: X86-based PC
Процессор(ы): [01]: x86 Family 6 Model 6 Stepping 3 AuthenticAMD ~2608 Mhz
Версия BIOS: QEMU - 1

Очень интересное сочетание Windows XP и Red Hat в одном устройстве. Не находите? Видно, что тут используется средство виртуализации от QEMU.

Весьма странно, что не были заменены идентификаторы виртуализации. Ведь нормальные зловреды определяют, что запущены на виртуалке и могут прикидываться чем-то безвредным. А для определения виртуализации, в данном случае, достаточно найти строчку в подстроке. Еще было замечено что на 2012 год использовались только виртуалки Windows XP.

Результат tasklist:

System Idle Process 0 Console 0 28 K Running NT AUTHORITY\SYSTEM
python.exe 1776 Console 0 4,412 K Running Admintrator
pythonw.exe 1820 Console 0 6,352 K Running Admintrator
hookanaapp.exe 1316 Console 0 5,048 K Running Admintrator

Здесь, судя по всему, используются средства анализа сэмплов использующее python. Возможно, наподобие immunity debugger. А также некое самописное ПО: hookanaapp.exe

Давайте теперь всё увиденное соберём воедино.

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

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

LONG res;
TCHAR szUrl[] = _T(«http://SERVER/bin.exe»);
TCHAR szTempName[] = _T(«C:\\bin.exe»);
// загрузка и запуск файла
res = URLDownloadToFile(NULL,szUrl,szTempName,NULL,NULL);
if (res == S_OK)
{
ShellExecute(NULL,_T(«open»), szTempName, NULL, NULL, SW_HIDE);
}

Подведём резюме: некое ПО при запуске на системе сразу же собирает информацию о системе и имеет код для выполнения Download&Execute. Волнения антивирусов насчёт вирусного происхождения подобного ПО вполне обоснованы. Впоследствии мы изменили логику работы нашего ПО. И наши “цифровые встречи” с антивирусами в работе разработчиков прекратились.

А вот кое-что ещё, выловленное из логов в тот же день:

Remote IP: 69.164.111.198
User-agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC)
QUERY_STRING :
HTTP_REFERER:
REQUEST_METHOD : GET
HTTP_ACCEPT : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_LANGUAGE :
HTTP_ACCEPT_CHARSET :

whois возвращает строчку:

OrgName: Sungard Network Solutions, Inc.

Вот их сайт: http://www.sungard.com

А вот совсем уж неведома зверушка из Германии:

Remote IP: 91.20.15.86
User-agent : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
QUERY_STRING :
HTTP_REFERER:
REQUEST_METHOD : GET
HTTP_ACCEPT : */*
HTTP_ACCEPT_LANGUAGE :
HTTP_ACCEPT_CHARSET :

Из who:

person: Security Team
remarks: * Hack Attacks, Illegal Activity, Violation, Scans, Probes, etc.

Выводы:

Попавшее на исследования по ложному обвинению криво написанное ПО позволяет сделать несколько выводов о работе антивирусных лабораторий. Во-первых, антивирусные лаборатории используют различные среды виртуализации при автоматическом детектировании подозрительного ПО. Также совершают автоматический запрос к серверам управления прямо из своих сетей, без использования VPN/прокси. Причём HTTP-запросы делаются не настоящим браузером. Это всё может вовремя предупредить чутких владельцев ботнета и привести к своевременному переводу работающей части бот-сети на другой сервер управления. И, наконец. Некоторые антивирусные лаборатории передают информацию о подозрительном ПО каким-то сторонним организациям, вроде “Sungard Network Solutions”.