Didier Stevens

Thursday 10 April 2014

Heartbleed: Packet Capture – Full TLS

Filed under: Networking,Vulnerabilities — Didier Stevens @ 22:34

Yesterday I posted my heartbleed packet capture with an unencrypted heartbeat record.

Now I post a capture with full TLS session setup, hence here the heartbeat records are encrypted. I use heartbleed.c by HackerFantastic.

heartbleed_packet_capture_tls.zip (https)
MD5: 7D19146C2ACC28AFAD6E1FD217E908BB
SHA256: 7FDECDD05269731EDD57FFEE24323C672D620A533CD412089F055D6266C76164

Wednesday 9 April 2014

Heartbleed: Packet Capture

Filed under: Networking,Vulnerabilities — Didier Stevens @ 21:39

I could call this a cardiogram, but let’s not get carried away…

I took a packet capture of the heartbleed bug (CVE-2014-0160) in action: I have OpenSSL 1.0.1 14 March 2012 running on Apache2 (Ubuntu, VMware) and executed Jared Stafford’s ssltest.py script. One small modification to the script: I removed line 132 (the script transmits 2 heartbeat requests, I want only 1 request).

PS: as I expected, I didn’t find an entry in the Apache logs for this request.

heartbleed_packet_capture.zip (https)
MD5: 8302CDF315A91DD6FC32BB81AE0FB80D
SHA256: 7029CF9C2AF3CE7649501D15AD58439513F02B1B9ECD23343F6C6A6B2D87D344

Wednesday 31 October 2012

“Please Buy Our Competitor’s Products”

Filed under: Hacking,Vulnerabilities — Didier Stevens @ 19:55

I had a very good Samurai WTF training at Brucon by Raul Siles.

When Raul discussed the fact that clients are not worried about cross-site scripting when you demonstrate it with an alert box, I got the following idea:

Let’s redirect the customer to the competitor’s website. So instead of alert(“XSS”); let’s do window.location = “www.competitor.com”;. This will demonstrate that a cross-site script can cost your client money.

BTW, our training took place in a church:

Wednesday 8 August 2012

Video: Hardening Windows processes

Filed under: My Software,Vulnerabilities — Didier Stevens @ 8:04

Help Net Security recorded a video with me speaking about EMET and HeapLocker at Hack In The Box Amsterdam 2012.

Sunday 23 October 2011

HeapLocker 64-bit

Filed under: My Software,Vulnerabilities — Didier Stevens @ 19:40

I’m releasing my first 64-bit version of my HeapLocker tool.

I had to change many pointer calculations, and had to replace 32-bit shellcode with 64-bit shellcode.

This 64-bit version gets configured via the registry, exactly like the 32-bit version of HeapLocker. The only difference is when you want to protect specific addresses, you need to use a QWORD registry value in stead of a DWORD (QWORD is 64-bit wide, DWORD is 32-bit wide).

And there is a new feature: Bottom Up Randomization. To enable it, create a DWORD registry value with name BottomUpRandomization and value 1.

I will be adding this feature to HeapLocker 32-bit too, but I want to do this from the same code base. The next release of HeapLocker 32-bit will be compiled from Visual Studio 2010 and not from Borland C++ anymore.

HeapLocker64_V0_0_1_0.zip (https)
MD5: F3D43A29CE64F9418AA154C66B0B06A4
SHA256: 7EFF1D9EA20B522D76034DC4CB66E2FD7AC43E585987FC9ABF7EF8EB801FBC6C

Tuesday 18 October 2011

HeapLocker: Preventing Heapsprays

Filed under: My Software,Vulnerabilities — Didier Stevens @ 8:34

I’ve been using my HeapLocker tool for almost a year now, and I’ve encountered no issues, except for the NOP sled detection. When used with Adobe Reader, HeapLocker will generate too many false positives when looking for NOP sleds. So I’ve disabled NOP sled detection for Adobe Reader.

The last feature I want to talk about is heap spray mitigation.

Like EMET, HeapLocker can pre-allocate memory pages so that they can’t be used by the heap. And this renders a heap spray useless, as it will not be able to inject shellcode at the addresses HeapLocker protects. But unlike EMET, HeapLocker has 2 modes of pre-allocating memory pages. The first mode is just like EMET, while the second mode will write special shellcode to the pre-allocated pages. When this shellcode is hit due to an exploit, it will callback to HeapLocker which will suspend all threads and display a warning dialog. This is what you see in the video. There are 2 advantages to this mode: the user is warned that she opened a malicious document, and you can also use this in a malware lab to find out which address the exploit is hitting.

To prevent the HeapLocker shellcode from being used for ROP exploits, I randomized the injected NOP sled and shellcode. But if you still find this too risky, just use the standard mode for pre-allocating pages.

For more details about the exact way to configure this, read the documentation found in the HeapLocker download.

FYI: I’m also working on a 64-bit version of HeapLocker.

Thursday 29 September 2011

Add Bottom Up Randomization To (Your Own) Source Code

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 19:14

EMET’s new Bottom Up Randomization spectacularly increased the entropy of DLL’s base addresses loaded into my test program. Instead of 15 different addresses, I had more than 200.

Matt Miller told me how he implemented Bottom Up Randomization:

“It works by reserving a random number (between [0,256]) of 64K regions via VirtualAlloc. This has the effect of consuming a small portion of the bottom part of the address space. Since the Windows kernel assigns base addresses for collided DLLs by searching for a free region starting at the bottom of the address space, bottom up randomization ensures that a random base address will be assigned. Without bottom up randomization the bottom part of the address space remains fairly static (with some exceptions, such as due to heap, stack, and EXE randomization).”

So I decided to add this algorithm at the start of my test program:

int iIter;
int iRand;

iRand = rand() % 256 + 1;
for (iIter = 0; iIter < iRand; iIter++)

Again, the result is spectacular. In stead of 15 base addresses, with the most frequent address being using 30% of the time, my Bottom Up Randomization implementation gives me more than 300 addresses after 150.000 runs. And there’s no single address being used more than 0,5% of the time.

From now on, I’m going to include this in my programs, and I advise you to do the same with your programs. Or to open source programs you use.

Thursday 1 September 2011

Bottom Up Randomization Saves Mandatory ASLR

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 17:32

I recently found out that pseudo-ASLR (or mandatory ASLR in EMET) has a lower entropy than real ASLR. While real ASLR has a 8-bit entropy for base addresses, mandatory ASLR turned out only to have about 4 bits of entropy, and the distribution was far from uniform. What I forgot to tell you in that post, is that I just enabled Mandatory ASLR as mitigation in EMET, and nothing else:

Matt Miller told me that a new feature of EMET version 2.1, Bottom Up Randomization, would greatly improve the entropy of mandatory ASLR.

The results are spectacular. When I let my test program run around 500,000 times, I get almost 200 different base addresses. And the distribution is more uniform too, no address appears more frequently than 3% of the time.

To get decent protection from mandatory ASLR, be sure to use the latest version of EMET (2.1) and enable Bottom Up Randomization. This gives you the same entropy than real ASLR, with the added bonus that the base address will change each time the application is started, compared to real ASLR which requires a reboot.

Tuesday 16 August 2011

So How Good is Pseudo-ASLR?

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 0:29

Let me first define what I mean with pseudo-ASLR. Address Space Layout Randomization (introduced in Windows Vista) loads executable files at different memory addresses. Studies have shown that ASLR uses 256 different base addresses and that the distribution is pretty uniform.

Pseudo-ASLR is what EMET and my tool SE_ASLR enforce. When a DLL does not support ASLR, memory at the base address of this DLL is allocated right before the DLL is loaded into the process. Since the address is not free, the image loader will load the DLL at a different address, thereby « randomizing » the base address. But how good is this randomization?

As I pointed out in my article on EMET, this base address is different each time a new process is started (unlike ASLR which needs a reboot for the base address to change). So maybe this is better ?

I developed a test program that loads a DLL but pre-allocates memory at the address of the DLL before loading. Then I ran that program thousands of times on a Windows 7 32-bit machine.

Running this program about 50.000 times gives me 68 different addresses. That’s by far not as good as 256 with ASLR. But what’s more important, is that the distribution of these addresses is not uniform at all:

There’s one address (0x000E0000 in my test) that is used 30% of the time. 2 other addresses are used 10% of the time. Rebooting the machine does not change this distribution.

When I do the same test, but enforce ASLR with EMET, I get a similar result:

Again there’s an address that is selected 30% of the time, but it’s different from my previous test. Rebooting the Windows 7 machine doesn’t change the address.

In this test, EMET uses only 15 different addresses, compared to the 68 addresses in the first test. I’ll have to research this difference, I’ve no explanation for it.

Conclusion from this simple test: pseudo-ASLR is rather weak, because I can predict the base address and I will be right one time out of three, which is not bad at all when I can launch my attack several times.

Wednesday 10 August 2011

Force “ASLR” on Shell Extensions

Filed under: My Software,Vulnerabilities — Didier Stevens @ 0:49

I’ve written about Shell Extension without ASLR support before.

Not only do they open up explorer.exe to ROP attacks, but other applications too, like Adobe Reader and Microsoft Office.

You could use EMET to force ASLR on these DLLs, assuming you know which applications load shell extensions. Because shell extensions are not only loaded into explorer.exe, but other programs too, I wrote a tool to force Shell Extension DLLs to load at another address than their base address, effectively simulating ASLR.

When my tool, SE_ASLR.dll, is loaded into a process, it will check for the presence of comdlg32.dll inside the list of loaded modules. When comdlg32.dll is used by an application, the likelihood of shell extensions being loaded into the process by user interaction with the file dialogs is significant.

Hence SE_ASLR will patch the IAT to intercept calls to LdrLoadDll. Each time the application loads a DLL (all DLLs, not only shell extension), SE_ASLR will check if the DLL supports ASLR. If it doesn’t, SE_ASLR will pre-allocate a memory page at the base address of the DLL, thereby forcing the loader to load the DLL at another address.

Although SE_ASLR’s primary goal is to relocate shell extensions, it will effectively relocate all DLLs without ASLR support once SE_ASLR is loaded into the process.

You need to load my tool into all applications that could use shell extension, for example via the AppInit_DLLs registry key. But before you do, be sure to test this out on a test machine. Not all shell extensions support relocation.

SE_ASLR_V0_0_0_1.zip (https)
MD5: 9D6AE1A96D554AEE527EB802FE59FB20
SHA256: 8A6C1406A757CD9788A2630D76A497E2C058333EE4D44CA0B85B2A05A39F257E

Next Page »

The Rubric Theme Blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 196 other followers