Differences

This shows you the differences between two versions of the page.

--- session:extra:advanced-attacks [2014/08/07 04:11]
magetoader
+++ session:extra:advanced-attacks [2020/07/19 12:49] (current)
@@ Line 1: / Line 1: @@
-= Session 14
+====== 0x0E. Topics on Advanced Attacks ======
 ===== Slides =====
-<note warning>
+{{:session:14-advanced-topics.pdf|}}
-TODO
-</note>
 ===== Tutorials =====
-This session will provide a quick intro into Windows Land. We will first explore the windows PE (Portable Executable) file format. On key elements we will try and present the differences between it and what
+Install angr. See [[http://angr.io/install.html]]
-we know about the ELF format. We will briefly explore how certain parts of a PE file get mapped into memory as well as how dynamic library calls are triggered focusing on the elements which are more important for our exploitation needs.
+<note important>You need to use a virtualenv for the installation. It will not work correctly otherwise</note>
-When it comes to exploitation everything in Windows is more verbose an generally harder. Given that the Windows will be featured in only one class we will not be able to feature the bypassing of all its mechanisms.
+Download {{:session:session-14.tgz|}}
-As a target Windows XP will be used (and before you cringe know that it currently has 25% market share vs 6% market share for Window 8). As a debugger we will be using windbg, because the ones with fancy interfaces and plugins are still stuck in 32-bit land, and when it comes to writing or finding rootkits it's basically all you've got. Initially we will explore what it means to explore a vanilla stack overflow and how much more complicated windows shellcode is compared to Linux. Then we will move on to bypassing canary values, and the to exploiting SEH (structured exception handling), as well as it accompanying mitigation strategy called SafeSEH.
-This will be done in a DEP and ASLR free environment.
+Switch to task-0 and first analyze the binary manually (IDA, gdb, etc). Then analyze the Angr solver: where the state starts, the avoided branches and the target state. Check that it works as expected.
+===== Tasks =====
+Switch to task-1. The task performs a hash on the input and overwrites the return address with the function output. Use this to jump to the win() function.
+  * Solve the task by hand
+  * Solve the task using the provided skeleton script.
-==== Brief History ====
-The PE file format has a common ancestor with ELF in the COFF file format and has been around since Win 3.1. Unlike ELF its consistent across all architectures that windows supports and currently comes in tow flavours PE32 and PE32+(for 64bit). In order to interpret the contents  of a binary ELF file, a program will find its specification in the WINNT.H file. Below you can notice a birds eye view of  the PE file  format and awe at its size.
-{{ :session:pe_format_small.jpg?nolink&500 |}}
-In Windows there are a lot of things that constitute an PE file, among which:
- * **.exe** - Executable file
- * **.cpl** - Control panel
- * ** .scr** - Screensaver
- * **.dll** - Dynamic Link Library
- * **.sys/.drv** - System file (Kernel Driver)
- * ** .ocx** - ActiveX control
-<note >
-Static libraries in Windows, that usually carry the **.lib** extentsion are not in PE file format
-</note>
-==== PE structure ====
-Obviosly we cannot go through all the elements of the PE file in one sitting so are just going to focus on the things that help us figure out what we are looking at in memory.
-<note important>
-There are a lot of tools to help you peer into the an PE file. Among the most used:
-* [[http://www.ntcore.com/exsuite.php|CFF Explorer]] powerful x64 suppport a tad on the windows explorer side
-* [[http://wjradburn.com/software/|PEView]] lightweight, portable but only x32 support
-* [[http://www.woodmann.com/collaborative/tools/index.php/LordPE|LORDPE]] portable, x64 compatible with support for runtime process analysis
-The good news is that we don't need to know everything about the PE structure for exploitation, so at each important section we will just be talking about the things that do help us.
-Refer to the first link below to view all the elements
-</note>
-<note important>
-**For a more useful/complete reference use the following links:**
-  * [[https://docs.google.com/file/d/0B3_wGJkuWLytbnIxY1J5WUs4MEk/edit|Magnified]] PE32 and PE32+ formats
-  * [[https://docs.google.com/file/d/0B3_wGJkuWLytQmc2di0wajB1Xzg/edit|Memory Layout]]
-  * [[http://https://i.imgur.com/tnUca.jpg|PE]]  executable walkthrough
-  * [[http://msdn.microsoft.com/en-us/magazine/cc301805.aspx| Part 1]] An In-Depth Look into the Win32 Portable Executable File Format
-  * [[http://msdn.microsoft.com/en-us/magazine/cc301808.aspx| Part 2]] An In-Depth Look into the Win32 Portable Executable File Format
-</note>
-The following image illustrates a rough estimate of what gets loaded into memory
-{{ :session:pe_in_memory.gif?nolink&300 |}}
-=== Image DOS Header ===
-**e_lfanew** - specified the file offset for the next header
-=== Image NT Header  ===
-**Signature** - PE written in ASCII format
-**FileHEader** -  the File Header
-**OptionalHeaderr** -  the Optional header
-=== Image File Header  ===
-**Machine** - states if it's a x86 (014c) bit or a x86-64(8664) bit binary
-**TimeDateStamp** - Unix style timestamp (measuring since 01.01.1970) applied when the executable was linked
-**NumberOfSections** - States the number of sections that follow
-**Characteristics** - gives us an idea of the type of file we are dealing with a few of which are:
-* System file - IMAGE_FILE_SYSTEM(0x1000)
-* Executable File - IMAGE_FILE_EXECUTABLE_IMAGE(0x0002)
-* 32 bit machine - IMAGE_FILE_32BIT_MACHINE(0x1000)
-=== Image Optional Header  ===
-**Magic** - State if it's a PE32(10c) or PE32+(20B) file
-**AddressOfEntryPoint ** - specifies the RVA(Relative Virtual Address) where the code will start executing after the loader has finished
-**SizeOfImage** -  the size of the contiguous memory that needs to be reserved to load the file in memory
-**SectionAlignment ** - the file sections are aligned in memory to this boundary
-**FileAlignment** -data alignment in boundary on disk
-**ImageBase ** - preferred virtual address where the PE file should be loaded.
-**DLLCharacteristics ** - specifies the important security attributes of the executable and more
-  * IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE  - can be used with ASLR
-  * IMAGE_DLLCHARACTERISTICS_NX_COMPAT - can be used with DEP
-  * IMAGE_DLLCHARACTERISTICS_NO_SEH -do not generate  a structured excheption handler chain, making SEH exploits not fesable
-=== Sections  ===
-After the headers that we have just listed will follow a list of sections. Sections inside the PE file serve a similar purpose to those in the ELF file format.
-Each section entry in the _IMAGE_SECTION_HEADER holds the following useful information:
-** Name ** the name of the section
-** VirtualAddress ** - the RVA relative to the ImageBase defined in the Optional Header
-** PointerToRawData ** - relative offset from the beginning of the file where the section starts
-** VirtualSize ** - size that the section occupies in memory
-** SizeOfRawData ** - size that the section occupies on disk
-=== Import table  ===
-The import table  is Windows's .PLT table basically. It doesn't necessarily work in the same way, but provides the same role, namely as mechanism for calling external functions at runtime.
-{{ :session:iat_table.gif?nolink&542x352 |}}
-**OriginalFirstThunk** - is a RVA to the INT( Import names table), import names table, that is basically an array of IMAGE_THUNK_DATA structs
-**FirstThunk ** - is the RVA to the IAT( Import Address Table), also an array of IMAGE_THUNK_DATA structs
-**Name ** - is the name of the module from where the functions will be imported
-<code text>
-typedef struct _IMAGE_THUNK_DATA32 {
-    union {
-        DWORD ForwarderString;      // PBYTE
-        DWORD Function;             // PDWORD
-        DWORD Ordinal;
-        DWORD AddressOfData;        // PIMAGE_IMPORT_BY_NAME
-    } u1;
-} IMAGE_THUNK_DATA32;
-</code>
-Initially both IAT and INT entries point to a IMAGE_IMPORT_BY_NAME structure which has the following key elements:
-**Hint** - using the ordinal of an imported function as a reference from in the exports table of dynamic library
-**Name** - function name in ASCII used for name resolution
-The INT structures are always interpreted as a u1.AddressOfData as a RVA of an  IMAGE_IMPORT_BY_NAME structure. At runtime the IAT structures are resolved by the OS Loader and are subsequently interpreted as u1.Function, as actual memory addresses in where the dynamic library was loaded in the process memory space.
-Linux provides the ability of statically linking a dynamic library by including all its code in the executable. In windows you can fill in the IAT entries at link time provided that the DLL you are linking against has a specific version. This functions in a predictable manner because, the PE file format provides an on disk map to find the exact position where a library function will be loaded in process memory. To figure out if the DLL present on disk is the the one we are bound imports are used who's structure is described by IMAGE_BOUND_IMPORT_DESCRIPTOR.
-**TimeDateStamp** - is matched against the same field in Export Address Table  of the DLL on disk to verify that the versions match
-**OffsetModuleName** - is the RVA calculated from the beginning of the  IMAGE_BOUND_IMPORT_DESCRIPTOR table
-<note important>
-Bound imports are not compatible with ASLR
-</note>
-=== Delay Loaded imports  ===
-Delay loaded imports are the very close in functionality to the way that .PLT is used to call external functions at runtime. This is used for calling functions in DLLs that will not be available at load time. In order to achieve a list of IMAGE_DELAY_IMPORT_DESCRIPTOR structures is used out of which the most important elements are:
-**rvaDLLName** the name in ASCII for the DLL
-**rvaIAT** - a RVA to a separate IAT structure
-**rvaINT** - a RVA to a separate INT structure
-{{ :session:delay_load.gif?nolink&365x189 |}}
-Initially the delay loaded IAT entry contains a RVA to some stub code that will basically perform these actions:
-) Check if the DLL has been loaded into memory
-) If not it will call the **LoadLibrary()** function to add the DLL
-) Then it will call the **getProcAddress()** function to map the external function address as it was loaded into memory
-) It will fill in the IAT entry with the function address so that subsequent calls will happen directly
-=== Exports ===
-For a dynamic library to be useful it must expose an API to call the function it implements. Dynamic libraries in Windows do this by using a mechanism called the Exports Address Table that resides in the IMAGE_EXPORT_DIRECTORY struct. The most important elements are:
-**TimeDateStamp** is used by the bound imports mechanism to match the version of the on disk DLL and figure out if it should be matched into memory
-**AddressOfFunctions** - is a RVA which points to the beginning of an array of function RVA called the EAT ( Export Address Table)
-**AddressOfNames** RVA which points to the beginning of an array of RVAs to the function names called the ENT (Export Names Table)
-**AddressOfNameOrdinals** - RVA that point to the beginning of an array of ordinals
-**Base ** value that is subtracted from the entry  in  table pointed to by the AddressOfNameOrdinal to get the zero-indexed offset in the EAT
-**NumberOfFunctions**  number of functions that can be called by ordinal
-**NumberOfNames** the number functions that can be called by name
-Currently the all the entries in the ENT are sorted so a simple binary search by name will quickly give us the RVA of the function we are lookig for but in the days of old it wasn't so easy and best practice dictated that you use ordinals, hence the need for the two indexing schemes. To maintain backward compatibility the current scheme still involves using ordinals.
-) Get the index of the name in ENT, pointed to by AddressOfNames
-) Get the value from the same index in the ordinals table, pointed to by AddressOfNameOrdinals
-) Use the value as an index into EAT, pointed to by AddressOfFunctions
-{{ :session:eat_table.gif?nolink&277x209 |}}
-=== Relocations ===
-Each PE specifies a base address as a preference for where to be loaded into memory. As more DLL's get loaded into memory, the posibility of the same virtual address being requested by multiple libraries gets higher. In ELF, relocations are present in many structures, in windows it's just a standard section called **.reloc**. Relocations are stored in an array of IMAGE_BASE_RELOCATION structures.
-<code text>
-typedef struct _IMAGE_BASE_RELOCATION {
-    DWORD   VirtualAddress;
-    DWORD   SizeOfBlock;
-} IMAGE_BASE_RELOCATION;
-</code>
-After each relocation structure we can find an array of 16bit values that specify where and how each relocation will be applied.
-The first for bits specify a IMAGE_REL_BASED_xxx value that states how the relocation will be applied and the last 12 bits are interpreted based on the specific algorithm.
-The most used one is IMAGE_REL_BASED_HIGHLOW which means that the relocation will be applied in VirtualAddress+the lower 12 bits
-**VirtualAddress** - is the RVA  to which the retractions will be relative to.
-**SizeOfBlock** - the number of WORD (16bit) sized relocation targets added to the size of the structure itself
-=== PEB and TEB ===
-When a executable file gets loaded into memory aside from the elements that are mapped from the PE file on disk two very important structures get created in memory.
-{{ :session:peb_teb.png?nolink&527x475 |}}
-Every process is represented in kernel space by an EPROCESS which in turn references several ETHREAD  structures for threads. These in turn point in  user space to PEB and TEB structure containing some of the following information.
-** PEB( Process Environment Block) **
- * basic image information (base address, version numbers, module list)
- * process heap information
- * environment variables
- * command-line parameter
- * DLL search path
-** TEB( Process Environment block) **
- * stack information (stack-base and stack-limit)
- * TLS (Thread Local Storage) array
-==== WINDBG ====
-Like mention previously there are lot of fancy tools out there like Immunity and OllyDBG, but WindBG is the most powerful and complete, being currenltly the only solution if you want to debug kernel stuff. And because your debugging skill is directly proportionate to you exploitation skill a tool like WinDBG is the only way to go.
-{{ :session:windbg_main_window.png?nolink&800 |}}
-For exploitation the following setup is reccomended
-** Dismissasembly** - actively disassembling the code as EIP move
-** Memory ** it's usually recommended that you set ESP so you can actively monitor the stack
-** REgisters ** - it custmoizable
-** Command ** - command window
-You can add/remove windows from the View menu as you wish. To save a layout open windbg without attaching to a process setup the windows and go to File> Save Workspace. Whe you attach to a process ore just start one in windbg you can go to File > Open Workspace and instantly load all the process data to the workspace you wish.
-When starting up windbg from the command line some of the following flags are important
-**QY** - Suppresses the "Save Workspace?" dialog box and automatically saves workspaces
-**c** - specify a comma separated list of command to be run at startup
-<code text>
-windbg -QY SSS_example.exe [program arguments]
-</code>
-For a more complete list of commands:
-<note>
-For a more complete list of commands
-* [[http://msdn.microsoft.com/en-us/library/windows/hardware/ff561306(v=vs.85).aspx|WinDBG]] command line flags
-</note>
-After you've started a program  in windbg in order to reset use Ctrl+Shift-F5
-=== List of basic commands ===
-**bp** - set a breakpoint that will be removed when restarting
-<code text>
-:000> bp 0x00401c21
-</code>
-**bu** - set a breakpoint that will be won't be removed when restarting
-**t** - step into
-**p** - step over
-**g** - run until next breakpoint/end
-**u** - start dissasembling the code starting from a certain address
-<code text>
-:000> u 00401c20
-SSS_example!main [c:\class\sss_example\sss_example\sss_example\sss_example.cpp @ 6]:
-c20 55              push    ebp
-c21 8bec            mov     ebp,esp
-c23 81ec04020000    sub     esp,204h
-c29 68c8224000      push    offset SSS_example!GS_ExceptionPointers+0x8 (004022c8)
-c2e 8b450c          mov     eax,dword ptr [ebp+0Ch]
-c31 8b4804          mov     ecx,dword ptr [eax+4]
-c34 51              push    ecx
-c35 ff15a8204000    call    dword ptr [SSS_example!_imp__fopen (004020a8)]
-</code>
-**?** - an excelent operator for perfoming a lot of stuff the most useful being bytewise operations
-<code text>
-:000>? esp+4
-Evaluate expression: 1245040 = 0012ff70
-:000> ?00401c35 + 0x34
-Evaluate expression: 4201577 = 00401c69
-</code>
-**dd** dump memory and interpret it as a double words
-<code text>
-:000> dd 00401c20
-c20  81ec8b55 000204ec 22c86800 458b0040
-c30  04488b0c a815ff51 83004020 458908c4
-c40  fc7d83fc 68137500 004022cc 20ac15ff
-c50  c4830040 ffc88304 558b35eb 08428b0c
-c60  b415ff50 83004020 858904c4 fffffdfc
-c70  51fc4d8b fdfc958b 6a52ffff 00858d01
-c80  50fffffe 20a415ff c4830040 8bc03310
-c90  00c35de5 00000000 00000000 00000000
-</code>
-**.hh** -  open up a Windows help listing on any command
-**a** - modify instructions on the fly as the program is execution you must hit enter after each instruction and the a final enter to implement the changes
-<code text>
-:000> a 00401c3e
-c3e jmp 0x6
-jmp 0x6
-c43
-</code>
-**.load** - load windbg plugins
-**!teb** - list the TEB information
-<code text>
-:000> !teb
-TEB at 7ffdf000
-    ExceptionList:        0012ffa8
-    StackBase:            00130000
-    StackLimit:           00126000
-    SubSystemTib:         00000000
-    FiberData:            00001e00
-    ArbitraryUserPointer: 00000000
-    Self:                 7ffdf000
-    EnvironmentPointer:   00000000
-    ClientId:             00000ccc . 00000d40
-    RpcHandle:            00000000
-    Tls Storage:          00000000
-    PEB Address:          7ffd5000
-    LastErrorValue:       0
-    LastStatusValue:      c0000135
-    Count Owned Locks:    0
-    HardErrorMode:        0
-</code>
-**!peb** - list the PEB information
-<code text>
-!peb
-PEB at 7ffd5000
-    InheritedAddressSpace:    No
-    ReadImageFileExecOptions: No
-    BeingDebugged:            Yes
-    ImageBaseAddress:         00400000
-    Ldr                       00251ea0
-    Ldr.Initialized:          Yes
-    Ldr.InInitializationOrderModuleList: 00251f58 . 00252170
-    Ldr.InLoadOrderModuleList:           00251ee0 . 00252160
-    Ldr.InMemoryOrderModuleList:         00251ee8 . 00252168
-            Base TimeStamp                     Module
-53e2a7ae Aug 07 01:09:50 2014 C:\class\SSS_example\SSS_example\Debug\SSS_example.exe
-c900000 4d00f29d Dec 09 17:15:41 2010 C:\WINDOWS\system32\ntdll.dll
-c800000 49c4f2bb Mar 21 15:59:23 2009 C:\WINDOWS\system32\kernel32.dll
-        10200000 488ef6c7 Jul 29 13:53:59 2008 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll
-    SubSystemData:     00000000
-    ProcessHeap:       00150000
-    ProcessParameters: 00020000
-    CurrentDirectory:  'C:\class\SSS_example\SSS_example\Debug\'
-    WindowTitle:  'C:\class\SSS_example\SSS_example\Debug\SSS_example.exe'
-    ImageFile:    'C:\class\SSS_example\SSS_example\Debug\SSS_example.exe'
-    CommandLine:  'SSS_example.exe C:\attack.bin'
-    DllPath:      'C:\class\SSS_example\SSS_example\Debug;C:\WINDOWS\system32;C:\WINDOWS\system;C:\WINDOWS;.;C:\Program Files\Debugging Tools for Windows (x86)\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Debugging Tools for Windows (x86);c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\'
-    Environment:  00010000
-        =::=::\
-        =C:=C:\class\SSS_example\SSS_example\Debug
-        ALLUSERSPROFILE=C:\Documents and Settings\All Users
-        APPDATA=C:\Documents and Settings\Administrator\Application Data
-        CLIENTNAME=Console
-        CommonProgramFiles=C:\Program Files\Common Files
-        COMPUTERNAME=XP_HOST
-        ComSpec=C:\WINDOWS\system32\cmd.exe
-        FP_NO_HOST_CHECK=NO
-        [output-omitted]
-</code>
-**!exchain** - list the SEH chain
-<code text>
-:000> !exchain
-ffa8: SSS_example!_except_handler4+0 (00401a40)
-  CRT scope  0, filter: SSS_example!__tmainCRTStartup+1dd (0040131d)
-                func:   SSS_example!__tmainCRTStartup+1f8 (00401338)
-ffe0: kernel32!_except_handler3+0 (7c839aa8)
-  CRT scope  0, filter: kernel32!BaseProcessStart+29 (7c8438c2)
-                func:   kernel32!BaseProcessStart+3a (7c8438d8)
-Invalid exception stack at ffffffff
-</code>
-<note>
-Some other cheat sheets:
-* [[https://labs.snort.org/awbo/windbg.txt|Quick]] cheat sheet
-* [[http://windbg.info/doc/1-common-cmds.html|Big]] cheat sheet
-</note>
-==== Mona ====
-Like we discussed previously windows shellcode is not for the faint hearted. There is no .PLT and no return2lib, if you want something you need to follow that path listed in delay loaded import. Specifically your shellcode needs to see if the DLL to the needed function is in memory, if not it calls LoadLibrary() and then GerProcessAdress(). To get an idea of  how much more code that is below you can find two listing showing first linux then windows style shellcode that just echoes "hello world".
-{{ :session:linux_shellcode.png?nolink&277 |}}
-{{ :session:windoes_shellcode.png?nolink&500 |}}
-As such it is highly unfesable to write your own every time. To this extent, the  **msfpayload** metaploit script is more than useful at providing the windows shellcode for all your exploitation needs
-Windbg is a very powerful tool  but it wasn't exactly geared toward exploit development. If GDB has PEDA , windbg has mona. Mona is a powerful python script than can be loaded in winbg with the help of the python extention plugin.
-<note important>
-Before you can use mona the following things need to happen
-  - Install the [[https://labs.snort.org/awbo/windbg.txt|Python extension plugin]] along with python
-  - Download the [[https://github.com/corelan/windbglib|windbglib]] script from the corelan github and place it in the Windows  Debugging tools folder , where the windbg.exe resides
-  - Download the [[https://github.com/corelan/monab|mona]] script from the corelan github and place it in the Windows  Debugging tools folder , where the windbg.exe resides
-</note>
-To use mona on the current process you are debugging just run:
-<code text>
-load pykd.pyd
-:000> !py mona help
-Hold on...
-     'mona' - Exploit Development Swiss Army Knife - WinDBG (32bit)
-     Plugin version : 2.0 r494
-     Written by Corelan - https://www.corelan.be
-     Project page : https://redmine.corelan.be/projects/mona
-    |------------------------------------------------------------------|
-    |        _ __ ___    ___   _ __    __ _     _ __   _   _           |
-    |       | '_ ` _ \  / _ \ | '_ \  / _` |   | '_ \ | | | |          |
-    |       | | | | | || (_) || | | || (_| | _ | |_) || |_| |          |
-    |       |_| |_| |_| \___/ |_| |_| \__,_|(_)| .__/  \__, |          |
-    |                                          |_|     |___/           |
-    |                                                                  |
-    |------------------------------------------------------------------|
-</code>
-While using mona a lot of files get created. In order to be more organised when starting to exploit a process you should define a separate working directory
-<code text>
-!py mona config -set workingfolder C:\Mona\%p
-</code>
-The above command will store all the generated files int the Mona\//process_name// folder and also generate a mona.ini file in the directory where the current executable resided so you don't have to redefine the working folder each time you restart windbg
-<note>
-For more information on how to use mona refere to the following links
-* [[https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/|Mona Manual]]
-* [[http://www.slideshare.net/ajin25/exploit-research-and-development-megaprimer-monapy-exploit-writers-swiss-army|Mona Presentation]]
-</note>
-==== Basic Buffer Overflow ====
-By now everybody should be familiar with how a buffer overflow works, so we're not going to get into that. Instead let's say how we can use mona for exploitation in the fast lane.
-We run the executable compiled from the following code with no protections activated.
-<code text>
-#include <stdio.h>
-#include <string.h>
-#include <windows.h>
-int main(int argc, char **argv)
-{
-	FILE *fp;
-	int bytes_to_read;
-	char buf[500];
-	fp = fopen(argv[1], "rb");
-	if (fp == NULL)
-	{
-		printf("Can't o pen file\n");
-		return -1;
-	}
-	bytes_to_read=atoi(argv[2]);
-	fread(buf,1,bytes_to_read,fp);
-	return 0;
-}
-</code>
-It is quite clear that the program is vulnerable to a classic buffer overflow. Let's generate a binary file using the hex editor of choice ,generate 600 bytes of data and run the executable inside windbg.
-<code text>
-windbg -QY basic_vuln.exe C:\attack.bin 600
-</code>
-The output in the **Command** window in windbg should be something allong these lines.
-<code text>
-:000> g
-(7ac.3ec): Access violation - code c0000005 (first chance)
-First chance exceptions are reported before any exception handling.
-This exception may be expected and handled.
-eax=00000000 ebx=00000000 ecx=7855065f edx=003429d0 esi=00000001 edi=00403394
-eip=41414141 esp=0012ff84 ebp=41414141 iopl=0         nv up ei pl zr na pe nc
-cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
-41414141 ??              ???
-<code>
-So now instead of doing the heavy lifting let's put mona to work.
-<code text>
-.load pykd.pyd
-:000>!py mona config -set workingfolder C:\Mona\%p
-:000>!py mona pc 700
-Hold on...
-Creating cyclic pattern of 700 bytes
-</code>
-This should create a special patter and store it in the pattern.txt file in the C:\Mona\executable_name folder. We open the pattern file eliminate everything but the pattern and serve is as input to the vulnerable executable again. After the crash run the following command
-<code text>
-:000> !py mona findmsp
-Hold on...
-[+] Looking for cyclic pattern in memory
-    Cyclic pattern (normal) found at 0x00344170 (length 700 bytes)
-    Cyclic pattern (normal) found at 0x0012fd7c (length 600 bytes)
-[+] Examining registers
-    EIP contains normal pattern : 0x41327241 (offset 516)
-    ESP (0x0012ff84) points at offset 520 in normal pattern (length 80)
-    EBP contains normal pattern : 0x31724130 (offset 512)
-</code>
-After the crash mona will scan the process memory to figure out where in memory the vulnerable stack buffer is and write offsets from the buffer to various information structures in **findmsp.txt** file in the defined mona working folder. The vulnerable stack buffer is located at **0x0012fd7c** and the address that will lead to EIP overwrite must be positioned at an offset of 516 bytes in the input file. All we have to do now is place the address of the buffer starting at offset 516 in the file , and the shell code we wish to execute at the beginning of the file
-==== SEH Overflow ====
-One of the key protection mechanisms that has also been implemented in windows are stack canaries. As you already know these value prevent classic buffer overflows by checking some values that have been placed on the stack frame between local variable and the return addreses. Exception handling is built into the Windows operating system and helps make applications more robust. Even if the program developer has not set up any exception handling every thread of every process has at least one handler that is setup on thread initialization. Information about exception handlers is stored on the stack in an EXCEPTION_REGISTRATION structure and a pointer to the first EXCEPTION_REGISTRATION structure is stored in the Thread Environment Block.
-{{ :session:seh_table.png?nolink&500 |}}
-But the entries to the default SEH handlers are just some other entries on the stack. Essentially if an attacker can generate enough data he can ovewrite them and by triggering an exception he could bypass the canary value cheking entirely by interrupting normal execution flow.
-{{ :session:seh_overflow.png?nolink200 |}}
-Again let's put mona to work. Just like above let's generate an attack pattern but this time let's use 1000 bytes.
-<code text>
-:000> g
-(dac.db0): Access violation - code c0000005 (first chance)
-First chance exceptions are reported before any exception handling.
-This exception may be expected and handled.
-eax=00000041 ebx=000003e7 ecx=00000059 edx=00000000 esi=003443f4 edi=00130000
-eip=7855aed8 esp=0012fca4 ebp=0012fcac iopl=0         nv up ei pl nz na po nc
-cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
-MSVCR90!memcpy+0xb8:
-aed8 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
-:000> g
-(dac.db0): Access violation - code c0000005 (first chance)
-First chance exceptions are reported before any exception handling.
-This exception may be expected and handled.
-eax=00000000 ebx=00000000 ecx=74413973 edx=7c9032bc esi=00000000 edi=00000000
-eip=74413973 esp=0012f8d4 ebp=0012f8f4 iopl=0         nv up ei pl zr na pe nc
-cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
-74413973 ??              ???
-</code>
-As we can see the buffer overflow occurred but due to the far larger payload an exception also happened in the memcpy function, but when Windows move to call the appropriate exception handler it was already overwritten. we issue the mona findmsp command and the following output is yeilded.
-<code text>
-!py mona findmsp
-Hold on...
-[+] Looking for cyclic pattern in memory
-    Cyclic pattern (normal) found at 0x00344170 (length 1000 bytes)
-    Cyclic pattern (normal) found at 0x0012fd7c (length 644 bytes)
-    -  Stack pivot between 1192 & 1836 bytes needed to land in this pattern
-[+] Examining registers
-    EIP contains normal pattern : 0x74413973 (offset 568)
-    ECX contains normal pattern : 0x74413973 (offset 568)
-[+] Examining SEH chain
-    SEH record (nseh field) at 0x0012ffb0 overwritten with normal pattern : 0x41387341 (offset 564), followed by 72 bytes o
-</code>
-Apparently all we would have to do is pute the buffer address at offset 564 and we're done. But due to the fact that this buffer was severely exploited in Microsoft inserted a sanity check that prohibits the structured exception handler from treating stack addresses as valid addresses to handlers. In order to bypass we must understand how the exception chain is used.
-{{ :session:seh_chain.png?nolink&400 |}}
-== Tasks
-<note warning>
-TODO
-</note>

Security Summer School

User Tools

Site Tools

Differences

Page Tools