Содержание статьи
В лаборатории компании Websense провели интересно исследование вредоносного
кода, внедряемого на сайты буквально каждый день. В исследовании разобраны
вопросы, связанные с внедрением вредоносного кода, от начала и до конца,
разобран "по косточкам" сам код, а также проанализирован сайт, на который он
ссылается и итоги внедрения. Перевод статьи мы предлагаем вам.
Внедренный код
Свою экскурсию мы начнем с преставления конкретного внедряемого кода, который
попал к нам на рассмотрение, однако не забывайте, что других его разновидностей
на данный момент – тысячи. Нам же предстоит иметь дело с довольно специфичной
инъекцией, жертвой которой уже успели стать десятки веб-сайтов, начиная с
правительственных и финансовых ресурсов, и заканчивая спортивными веб-страницами
и онлайн-магазинами.
Приведенный ниже скриншот показывает, сайты каких категорий уже были
скомпрометированы и демонстрирует внедренный в них код:
Внедренный код подвергся лишь самой незначительной обфускации:
последовательность символов Unicode была выведена функцией document.write.
Обычно подвергшийся обфускации код вставляет на сайт IFrame, указывающий на
сайт-источник. При помощи SpiderMonkey деобфускация проводится очень легко, для
этого нужно лишь заменить функцию document.write функцией print. Еще проще
использовать плагин для Firefox FireBug, так как он проводит деобфускацию
автоматически.
Давай посмотрим на то, как, собственно, выглядит сам код:
Как мы и ожидали, это - IFrame. URL, на который он указывает – это адрес
вредоносного сайта. В данном конкретном случае адрес содержит слово "Google",
это сделано для того, чтобы сбивать пользователей с толку. Давайте сейчас на
него посмотрим.
Сайт-источник
Взглянем на исходный код сайта:
Похоже на то, что и этот код подвергся незначительной обфускации, Проведя
деобфускацию, на выходе получаем следующее:
Выясняется, что сайт использует Java Applet, представляющий собой, в
основном, код из class-файла. Такой файл – часть архива JAR, который мы видим в
коде. Получив архив JAR в этом же каталоге, мы можем достать из него и
class-файл. Файлы классов в подобных архивах написаны на Java, и поскольку
исходники Java скомпилированы в байт-код, декомпилировать их обратно в исходный
код не составит никакого труда. Программ для декомпиляции Java сейчас
предостаточно, мы же используем для этих целей JAD:
Изучение кода (на скриншоте показана лишь его часть) сомнений не оставляет –
код загружает в систему какой-то файл с веб-сайта и запускает его. Чтобы атака
сработала, нужно, чтобы у тебя в системе была установлена Java, а сам ты
подтвердил аутентичность сертификата Java Applet.
Java разрабатывалась с учетом соответствия стандартам безопасности, поэтому
произвольные файлы при ее помощи просто так загрузить не получится. Для того,
чтобы код Java Applet получил статус доверенного, требуется наличие цифровой
подписи. Если она (как в нашем случае) отсутствует, мы увидим предупреждающее
диалоговое окно, запрашивающее подтверждение дальнейших действий:
Это как раз тот случай, когда система безопасности призывает к разуму
пользователя, уведомляя его об опасности. Большинство веб-серферов наверняка
воскликнут что-то вроде "Да я бы никогда не стал кликать на этом!", однако
практика показывает, что большинство из нас все-таки совершают такой
опрометчивый шаг.
В сентябре проводилось соответствующее исследование и выяснили, что хакеры не
брезгуют использовать в имени владельца цифровой подписи названия знаменитых
брендов, таких как Google, с тем, чтобы увеличить процент успешных атак
основываясь на добром имени подобных гигантов отрасли.
С примерами социальной инженерии мы сталкиваемся постоянно, поэтому лишний
раз вспоминать о них больше не будем. Напомним лишь, что ущерб, причиняемый
атаками на основе Java, может быть разным, в зависимости от того, какие баги
присутствуют в архитектуре браузера. Например, уязвимость в браузере Chrome от
Google ранее позволяла преспокойно загружать файлы при помощи Java Applets, не
получая при этом вообще никаких уведомлений.
Возвращаясь к показанному нами диалоговому окну отметим, что если
пользователь подтвердит подлинность приложения, в его систему будет загружен и
сразу запущен в ней вредоносный файл под названием GoogleTrax.exe. А раз так, то
пришло время перейти к анализу вредоносного кода.
Анализ вредоносного кода: что скрывается в тени
GoogleTrax.exe выглядит как обычное приложение Visual Basic, скомпилированное
с помощью P-Code, а не исходного кода. Такой подход к обфускации слегка
затрудняет чтение, поскольку код ассемблера здесь не используется, вместо этого
задействован код Visual Basic Pseudo. Тем не менее, при помощи некоторых
свободно распространяемых утилит типа P32DASM можно прочесть Visual Basic Pcode,
и хотя полную декомпиляцию провести не получится, на выходе мы получим рабочую
сборку VB. При условии наличия соответствующих навыков, польза от проведения
таких действий становится очевидной с первого взгляда.
Мы видим, что сначала программа пытается обнаружить SandBox, включая Anubis,
CW SandBox, SandboxIE и прочие. Ниже приведены несколько скриншотов с кодом
обнаружения:
На первом из них видно имя пользователя, занесенное в черные списки, и после
краткого поиска в Интернет мы обнаружили на него одну ссылку. Похоже, имя
каким-то образом связано с CW Sandbox.
При таком методе обнаружения используются черные списки Windows Product ID.
Если Product ID обнаружен, приложение попросту закрывается.
В данном случае речь идет о специфическом dll, и если библиотека подгружена,
GoogleTrax.exe закрывается. Как следует из названия dll, она возможно определяет
наличие SandBoxIE. Прежде чем приступить к распаковке, вредоносные файлы могут
использовать и другие трюки.
В данном случае образец создает дочерний процесс и при помощи
ZwUnmapViewOfSection выделяет себе место в памяти, в которое и распаковывается.
Эта техника не нова и известна довольно давно. Тем не менее, она по-прежнему
широко используется:
В любом случае, новый код в памяти начинает работать и перестает быть
начальным файлом Visual Basic. Файл выглядит так, как будто вручную написан на
ассемблере, по крайней мере, в большей своей части. В итоге он создает мьютекс,
а затем пытается открыть процесс explorer.exe. Если это ему удается, в процесс
встраиваются части кода. Если быть до конца точным, в explorer.exe встраивается
12 частей, последняя из которых – в находящуюся в памяти IAT (Таблица импорта
адресов).
Взглянув на представленный ниже скриншот, ты увидишь полный перечень
внедренных объектов. Первый адрес – это страница памяти, выделенная в Explorer,
а второй адрес – это связанный с ним адрес рассматриваемого нами приложения.
Адреса удаленных процедур могут различаться в зависимости от компьютера,
внедряемого процесса и т.д. Однако все они оказывают негативное влияние на
систему, поскольку, если ты попытаешься после этого вызвать explorer.exe,
система начнет тормозить или даже вылетать.
Функция CreateRemoteThread вызывает исполнение удаленного потока по адресу
0x8E0000 (еще раз напомним, адрес зависит от компьютера), который связан в
адресом 401AB8 в самом инжекторе. Используя эту информацию можно провести анализ
состояния при помощи IDA Pro. В своей работе мы всегда дополняем статический
анализ динамическим, а затем работаем с IDA Pro, если это не отнимает чересчур
много времени. В конечном итоге, мы суммируем информацию, полученную при
использовании всех видов анализа.
Используя еще один отладчик, ты можешь установить прерывание в точке 0x8F0000
и затем возобновить работу инжектора. Программа выполнит удаленный поток и
закроется. Внедренный процесс остановится в твоем отладчике, и ты сможешь
продолжить дальнейшие исследования с нужного места. Это занятие может показаться
тебе весьма затруднительным, поскольку исследуемое приложение использует
множество процессов и выполняет самые разные задачи, однако мы постараемся
обобщить наши выводы по поводу того, что же именно делает рассматриваемая нами
малварь.
Разрешение функций API
Разбор структуры программы отнял у нас порядочное количество времени,
поскольку помимо ExitProcess, других импортированных функций в ней не оказалось,
а в сторонние процессы внедрялось довольно много кода. Каждый раз, когда трояну
требовалось вызвать какую-нибудь процедуру, он делал это динамически:
Каждый раз при вызове или загрузке функции в стек помещался 32-битный хэш.
При этом регистр ESI содержит адрес важных данных, таких как таблица импорта
адресов инжектированная ранее и указатели на различные функции. Например, как
видно на приведенном выше скриншоте, [ESI+ABBh] указывает на kernel32 ImageBase,
наличие этой информации требуется функции HomeGetProcAddress для того, чтобы
осуществлять вызов API. А, скажем, [ESI+0DD] указывает уже непосредственно на
саму HomeGetProcAddress. В общем, примеров масса.
Хэширование – весьма распространенный метод при создании шеллкодов, оно
используется преимущественно для того, чтобы уменьшить их размер. В данном
случае ограничений по размеру нет, и главная цель применения методики – замести
следы. Для того, чтобы определить, что функция вызвана/разрешена, требуется
получить функцию, ссылающуюся на хэш, как на параметр. Ни одна из функций во
внедренных в процессы блоках вредоносного кода не вызывается в открытую.
Все функции впоследствии вызываются CALL EAX. В приведенном выше примере
программа разрешает GetSystemDirectoryA, а затем выполняет ее.
Альтернативные потоки данных в NTFS
После выполнения этого запроса наше приложение открывает само себя на диске,
получает сведения о своем размере и резервирует в оперативной памяти место,
необходимое для создания собственной копии. После этого приложение пытается
удалить себя с диска. Сразу после этого оно предпринимает попытку открыть
"C:\Windows\system32:msupdate.exe".
Ты наверняка заметил двоеточие в середине ссылки на папку назначения и
обратил внимание на название исполняемого файла. Это так называемый NTFS ADS
(альтернативный поток данных NTFS), задача которого состоит в том, чтобы скрыть
исполняемый файл от среднестатистического конечного пользователя, поскольку,
несмотря на свое присутствие, в Windows Explorer он отражаться не будет.
Запустив такой поток приложение проверяет то место, из которого было запущено, и
если оно не соответствует пути, прописанному в ADS, удаляет существующий файл.
Это делается для того, чтобы убедиться, что начальная копия удалена, и
сохранилась лишь копия, использующая ADS. Утилиты для обнаружения руткитов,
такие как "Gmer", могут помочь тебе увидеть ADS:
Внутри процесса explorer внедренный код открывает ветку реестра "HKEY_LOCAL_MACHINE\Software\Microsoft\Active
Setup\Installed Components\" и просматривает там каждое значение CLSID,
сравнивая его с собственным ADS. Если совпадения не обнаружены, приложение
создает свое собственное значение CLSID, в котором в качестве пути к ADS
используется параметр StubPath. Затем это значение устанавливается в "C:\WINDOWS\system32:mspudate.exe"
с тем чтобы при последующей перезагрузке системы инжектор смог внедриться в
процесс explorer.exe:
Для того, чтобы позволить себе запуститься вновь, приложение меняет еще один
ключ реестра. Это делается для того, чтобы обмануть тех людей, которые
попытаются вычистить свою машину от заразы. Добавляется и ключ Windows\Run,
содержащий полный путь к запускаемому приложению:
Вот почему мьютекс был создан так рано. Если бы этого не было сделано, могла
произойти мультиинъекция в explorer.exe, что, скорее всего, привело бы к сбою в
работе системы или существенному ее замедлению. Поэтому за автостарт нашего
трояна отвечает только один параметр.
После этого троян создает два потока. В порядке перечисления они вызывают
функции 0x930000 и 0x960000. Соответственно, в самом инжекторе это 0x402013 и
0x40255D. Сразу после создания потоков они вызывают субфункцию, находящуюся по
адресу 0x920000, который соответствует адресу 0x401DCC в инжекторе. То, что мы
уже знаем, какой адрес в инжекторе имеет соответствие с адресом удаленной
страницы, заметно облегчает нам жизнь.
Внедрение в браузер по умолчанию
Для того, чтобы обойти некоторые фаерволы, в браузер по умолчанию внедряется
еще один блок кода. Внедрение происходит изнутри процесса explorer.exe, а для
того, чтобы вычислить путь к браузеру по умолчанию, анализируется
соответствующая запись в реестре (инъекция выполняется с адреса 0x920000).
Затем осуществляется просмотр процессов, запущенных браузером в оперативной
памяти. И если таковые находятся, происходит попытка внедрения в них. В сам
Internet Explorer внедряется лишь один компонент, копируемый с адреса 0x8B0000,
который соответствует внутреннему адресу инжектора 0x400437. В браузер также
внедряется буфер таблицы IAT.
После этого происходит соединение по выделенному порту на адрес g***v.s***s.net,
возможно, это делается для того, чтобы получить код для дальнейшего исполнения.
На момент написания статьи соединение уже не работало, а в варианте,
рассмотренном два года назад, троян соединялся с удаленным веб-сайтом, и получал
из него код, выполняемый затем в куче. Попытки установки соединения продолжались
до тех пор, пока не удавалось получить код.
Потоки
Перехватчик нажатий клавиш
Первый запущенный поток в конечном итоге вызывает функцию SetWindowsHookExA и
устанавливает перехватчик "WH_JOURNALRECORD", который берет с адреса 0x940000,
соответствующего адресу 0x4020FD в инжекторе. Перехватчик используется для
перехвата нажатий клавиш на клавиатуре и мыши. В предыдущем варианте
использовалась другая его разновидность, а вызываемая функция называлась
GetKeyboardState.
Мониторинг реестра
Второй поток проверяет реестр каждые 5 секунд. Если ключ автоматического
запуска трояна удален, он восстанавливает его. И все то время, пока запущен
процесс explorer.exe, просто так удалить ключ реестра не выйдет. Очевидно, что
приостановка процесса приводит к неработоспособности такой меры защиты. Поэтому
можно просто сменить в параметре Sleep() временной интервал, и вместо пяти
секунд установить бесконечность. После этого программа уже никогда не сможет
проверить реестр.
Выводы
Мы с тобой рассмотрели полностью всю структуру готовой атаки. И хотя она была
ориентирована на слабо защищенные системы, минимально необходимые методы
обфускации все же присутствовали. Впрочем, даже их зачастую бывает достаточно,
чтобы успешно поражать обычные сайты. Также мы уделили внимание роли Java Applet
при организации атак со стороны Сети. На основании проведенной работы можно
сделать заключение о том, что хакеры не стесняются использовать некомпетентность
конечных пользователей при нападении. Не вызывает сомнения и тот факт, что
киберпреступники пристально следят за теми тенденциями, которым следует массовая
аудитория и атакуют самые уязвимые точки очень оперативно. Из анализа собственно
кода следует вывод, что троянописатели не слишком-то утруждают себя обновлением
своих приложений. И понять их нетрудно, поскольку методы упаковки позволяют
преступникам проникать сквозь антивирусные барьеры и спокойно запускать даже
старый код.
И, наконец, самое главное, что бы мы хотели отметить – это важность поднятия
уровня подготовки пользователей интернета. Человеческий фактор нельзя пропатчить
при помощи обновлений, и именно слабая образованность многих людей делает их
самым слабым звеном оборонительного периметра. Мы выражаем надежду на то, что
сознательность наших читателей будет расти, а мы со своей стороны приложим к
этому максимум необходимых усилий.
Оригинал:
http://securitylabs.websense.com/content/Blogs/3239.aspx
