-=[!]=-

ForbiddenBITS 2013 - Crunch - 250

2013-03-19T09:26:00.002+00:00

We get a PNG image that's all black. Looking at the structure there doesn't appear to be any other data, only a single IDAT chunk with deflated image bytes. Decompressing the data we can see a lot of runs with NULL bytes. So this is likely to be an image very limited in color, perhaps all black. After some trial and error we can "highlight" actual content by changing the gamma of the PNG, either via CLI or in Gimp using "Color" -> "Auto" -> "Normalize". This results in an image of a QR-Code that decodes to a URL.

$ pngtopnm -gamma 8 spawn.png > spawn.ppm
$ file spawn.ppm
spawn.ppm: Netpbm PPM "rawbits" image data
$ zbarimg spawn.ppm
QR-Code:http://forbiddenbits.net/060645cc5ebdf80e84ebc91547641b49
scanned 1 barcode symbols from 1 images in 0.12 seconds

The downloaded content is a long ASCII string of HEX characters, which after conversion results in a data blob.

$ xxd -l64 060645cc5ebdf80e84ebc91547641b49

0000000: 3939 6261 3964 3839 3734 3633 3263 3234 99ba9d8974632c24

0000010: 3262 3266 3734 3732 3637 3633 3632 3231 2b2f747267636221

0000020: 3734 3362 3636 3632 3964 6232 3734 3330 743b66629db27430

0000030: 3636 3633 3633 3638 3735 3732 3637 3633 6663636875726763

>>> from binascii import unhexlify

>>> dat = open("060645cc5ebdf80e84ebc91547641b49", "rb").read(1024*1024)

>>> open("blob.dat", "wb").write(unhexlify(dat))

$ xxd -l512 blob.dat

0000000: 99ba 9d89 7463 2c24 2b2f 7472 6763 6221 ....tc,$+/trgcb!

0000010: 743b 6662 9db2 7430 6663 6368 7572 6763 t;fb..t0fcchurgc

0000020: 6368 7572 6763 6368 7572 6763 6368 7572 churgcchurgcchur

0000030: 6763 6368 7572 6763 6368 7572 6763 6368 gcchurgcchurgcch

0000040: 7572 6763 6368 7572 6763 6368 7572 6763 urgcchurgcchurgc

0000050: 6368 7572 6763 6368 758c bd62 2168 7572 churgcchu..b!hur

0000060: 6763 6368 7572 6763 6368 7572 6763 6368 gcchurgcchurgcch

0000070: 7572 6763 6368 7572 6763 6368 7572 6763 urgcchurgcchurgc

0000080: 6368 7572 6763 6368 7572 6763 6368 7572 churgcchurgcchur

0000090: 6763 6368 7572 6763 6368 7572 6763 9da9 gcchurgcchurgc..

00000a0: 7462 6e63 7768 0a70 6773 626b 6572 6573 tbncwh.pgsbkeres

00000b0: 6396 b073 7962 6269 7372 6763 6368 7473 c..sybbisrgcchts

00000c0: 6662 6269 7473 6566 676f 737b 6f68 6262 fbbitsefgos{ohbb

00000d0: 7571 99a6 6203 6473 6661 616e 737b 6064 uq..b.dsfaans{`d

00000e0: 6162 7375 6d6b 626a 7076 6764 7369 7674 absumkbjpvgdsivt

00000f0: 7576 4358 5032 3703 13e8 847b 7341 515d uvCXP27....{sAQ]

0000100: e5d2 a76b 702d c5a2 8774 472a 2017 9757 ...kp-...tG* ..W

0000110: 311d 6351 5420 273b 2110 e2f6 c663 6c11 1.cQT ';!....cl.

0000120: 0311 17dd 5245 14e1 f1ab 5344 e4e7 f0cb ....RE....SD....

0000130: d1c6 a2b6 802f 02e6 f0c1 d0da b787 99a6 ...../..........

0000140: 6274 7573 6461 6368 7572 6762 6269 7473 btusdachurgbbits

0000150: 6662 6269 7070 6364 6561 7571 6f9d a669 fbbippcdeauqo..i

0000160: 2162 6662 616d 7274 6066 666b 7376 6364 !bfbamrt`ffksvcd

0000170: 6569 7570 6262 606c 6575 4753 2338 8474 eiupbb`leuGS#8.t

0000180: 7203 13e8 d5c2 7471 f3a8 a592 6e77 4698 r.....tq....nwF.

0000190: 6256 5230 405c 6350 2337 10fb b655 5426 bVR0@\cP#7...UT&

00001a0: e0cb 6c45 2400 d060 5335 3534 805a 4330 ..lE$..`S554.ZC0

00001b0: 0207 16cc 8ba9 666e 6168 7471 7761 7369 ......fnahtqwasi

00001c0: 4b73 ebff 1087 ad72 7dad 46a2 769d 6438 Ks.....r}.F.v.d8

00001d0: b219 95ff aa93 bd46 9017 4f10 4601 cb43 .......F..O.F..C

00001e0: e5bf 05ff 0dc4 9368 f3c8 2ec2 72c3 93e2 .......h....r...

00001f0: 8cbc 7d05 fd6f 27ab f03c f67f 7559 8841 ..}..o'..<..uY.A

So, we can see that there's some structure to the decoded data blob, but it seems to be non-sense except for the header part, which may contain "encoded" ASCII characters. We could try and guess the file format and at least attempt basic XOR decryption with common magic values as the key in order to get the real key. Another approach is to assume that the header will contain runs of NULL bytes in which case in simple XOR the key will be as plain-text.

In the end it turned out to be a JPEG image XOR encrypted using the "fbbits" key. The image contains the flag in form of a hash string overlayed in red on top of the image. Also, notice that the "fbbits" key was in fact present in the data blob where the real JPEG had a run of NULL bytes at offset 0xC0, which is part of Huffman table.

Nuit du Hack 2013 Quals - Crackme3 - 300

2013-03-11T22:23:00.001+00:00

We get credentials to a SSH server which has two files in the home directory once logged in. One is the challenge binary and the other is a Linux kernel image, both are 64-bit. Running the binary we get a password prompt and no matter what is entered is incorrect.
$ ./crackme
Password: qwerty
You loose :(

After downloading the binary and looking at the assembly it quickly becomes obvious that static analysis won't work. The "main()" function contains what appears to be garbage code and the ELF header has some unknown flags set. Also, running the binary on anything other than their server causes a segfault, since instructions make no sense.

$ readelf -h crackme

ELF Header:

Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00

Class: ELF64

Data: 2's complement, little endian

Version: 1 (current)

OS/ABI: UNIX - System V

ABI Version: 0

Type: EXEC (Executable file)

Machine: Advanced Micro Devices X86-64

Version: 0x1

Entry point address: 0x400610

Start of program headers: 64 (bytes into file)

Start of section headers: 4752 (bytes into file)

Flags: 0x20

.text:0000000000400610 start proc near
.text:0000000000400610 and ebp, [rsi-6E561383h]
.text:0000000000400616 xchg eax, esp
.text:0000000000400617 jp short near ptr _malloc+2
.text:0000000000400617
.text:000000000040061A out 0D5h, al
.text:000000000040061C rol dword ptr [rsi], 1
.text:000000000040061E xlat
.text:000000000040061F mov bl, 0Ah
.text:0000000000400621 lock sbb eax, 0FF98C41Bh
.text:0000000000400627 xchg eax, ebx
.text:0000000000400628 xor ch, fs:[rax-47h]
.text:000000000040062C jrcxz near ptr byte_40066F
.text:000000000040062C
.text:000000000040062E rcpps xmm4, xmm6
.text:0000000000400631 loopne near ptr word_4005FA
.text:0000000000400631
.text:0000000000400633 adc ch, [rbx+30879A93h]
.text:0000000000400639 sub [rdx+8], bl

$ ./crackme

Segmentation fault (core dumped)

$ gdb crackme

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /mnt/hgfs/data/dxp/ctf/2013/ndh/crackme3/crackme...(no debugging symbols found)...done.

gdb$ r

Program received signal SIGSEGV, Segmentation fault.

--------------------------------------------------------------------------[regs]

EAX: 0x0000001C EBX: 0x00000000 ECX: 0x00000FFF EDX: 0xF7DE9740 o d I t s z a p c

ESI: 0x00300000 EDI: 0xF7FFE2C8 EBP: 0x00000000 ESP: 0xFFFFE530 EIP:Error while running hook_stop:

Value can't be converted to integer.

0x0000000000400610 in ?? ()

gdb$ x/5i $pc

=> 0x400610: and ebp,DWORD PTR [rsi-0x6e561383]

0x400616: xchg esp,eax

0x400617: rex.XB jp 0x4005f2

0x40061a: out 0xd5,al

0x40061c: rol DWORD PTR [rsi],1

gdb$ i r

rax 0x1c 0x1c

rbx 0x0 0x0

rcx 0xfff 0xfff

rdx 0x7ffff7de9740 0x7ffff7de9740

rsi 0x300000 0x300000

rdi 0x7ffff7ffe2c8 0x7ffff7ffe2c8

rbp 0x0 0x0

rsp 0x7fffffffe530 0x7fffffffe530

r8 0x1 0x1

r9 0x4 0x4

r10 0xd 0xd

r11 0x10800 0x10800

r12 0x400610 0x400610

r13 0x7fffffffe530 0x7fffffffe530

r14 0x0 0x0

r15 0x0 0x0

rip 0x400610 0x400610

eflags 0x10202 [ IF RF ]

cs 0x33 0x33

ss 0x2b 0x2b

ds 0x0 0x0

es 0x0 0x0

fs 0x0 0x0

gs 0x0 0x0

Initially, I tried dumping the memory from the binary on their server but without much success as the server was constantly dropping connections and it was nearly impossible to get anything done remotely. Later they removed GDB stating it was causing resource exhaustion problems. Considering that they also supplied a kernel image it would make sense to assume that the execution of certain files has to go through a decryption routine, similar to how iPhone executes encrypted apps. In the iPhone apps case the entire ".text" section is encrypted and the decryption key is within a kernel module. Thus, the idea is to analyze the supplied kernel image and identify where decryption occurs.

Poking around the kernel initially did not yield anything useful. Looking at the normal process execution sequence via the "execve()" call and following the entire procedure from start to finish did not yield anything that may indicate handling encryption. The typical sequence is for the correct system call stub to be called, which then goes into "sys_execve()" and onto "do_execve()" where the bulk of the logic is located. Nothing related to encryption stood out.

There's also functionality for handling various binary formats during process loading as well as the default ELF handling functions. The major one to parse the binary is the "load_elf_binary()" function. The function itself is a bit large, but not too complex and having a copy of the source code allows to go through it quicker and make sense of the structure parsing code.

Eventually, at very end of the function there's a rather peculiar code which first initializes a stack buffer with 35 constant values and then in a loop XORs a previously allocated buffer.

.text:FFFFFFFF8117A39C mov byte ptr [rbp+var_53], 12h

.text:FFFFFFFF8117A3A0 mov byte ptr [rbp+var_53+1], 43h ; 'C'

.text:FFFFFFFF8117A3A4 mov byte ptr [rbp+var_53+2], 34h ; '4'

.text:FFFFFFFF8117A3A8 mov byte ptr [rbp+var_53+3], 65h ; 'e'

.text:FFFFFFFF8117A3AC mov rax, rsi

.text:FFFFFFFF8117A3AF mov byte ptr [rbp+var_53+4], 78h ; 'x'

.text:FFFFFFFF8117A3B3 mov byte ptr [rbp+var_53+5], 0CFh ; '-'

.text:FFFFFFFF8117A3B7 sub rax, rdx

.text:FFFFFFFF8117A3BA mov byte ptr [rbp+var_53+6], 0DCh ; '_'

.text:FFFFFFFF8117A3BE mov byte ptr [rbp+var_53+7], 0CAh ; '-'

.text:FFFFFFFF8117A3C2 mov byte ptr [rbp+var_4B], 98h ; 'ÿ'

.text:FFFFFFFF8117A3C6 mov byte ptr [rbp+var_4B+1], 90h ; 'É'

.text:FFFFFFFF8117A3CA sub rcx, rax

.text:FFFFFFFF8117A3CD mov byte ptr [rbp+var_4B+2], 65h ; 'e'

.text:FFFFFFFF8117A3D1 mov byte ptr [rbp+var_4B+3], 31h ; '1'

.text:FFFFFFFF8117A3D5 xor edx, edx ; cnt = 0

.text:FFFFFFFF8117A3D7 mov byte ptr [rbp+var_4B+4], 21h ; '!'

.text:FFFFFFFF8117A3DB mov byte ptr [rbp+var_4B+5], 56h ; 'V'

.text:FFFFFFFF8117A3DF xor eax, eax

.text:FFFFFFFF8117A3E1 mov byte ptr [rbp+var_4B+6], 83h ; 'â'

.text:FFFFFFFF8117A3E5 mov byte ptr [rbp+var_4B+7], 0FAh ; '·'

.text:FFFFFFFF8117A3E9 mov [rbp+var_43], 0CDh ; '-'

.text:FFFFFFFF8117A3ED mov [rbp+var_42], 30h ; '0'

.text:FFFFFFFF8117A3F1 mov [rbp+var_41], 0FDh ; '²'

.text:FFFFFFFF8117A3F5 mov [rbp+var_40], 12h

.text:FFFFFFFF8117A3F9 mov [rbp+var_3F], 84h ; 'ä'

.text:FFFFFFFF8117A3FD mov [rbp+var_3E], 98h ; 'ÿ'

.text:FFFFFFFF8117A401 mov [rbp+var_3D], 0B7h ; '+'

.text:FFFFFFFF8117A405 mov [rbp+var_3C], 54h ; 'T'

.text:FFFFFFFF8117A409 mov [rbp+var_3B], 0A5h ; 'Ñ'

.text:FFFFFFFF8117A40D mov [rbp+var_3A], 62h ; 'b'

.text:FFFFFFFF8117A411 mov [rbp+var_39], 61h ; 'a'

.text:FFFFFFFF8117A415 mov [rbp+var_38], 0F9h ; '·'

.text:FFFFFFFF8117A419 mov [rbp+var_37], 0E3h ; 'p'

.text:FFFFFFFF8117A41D mov [rbp+var_36], 9

.text:FFFFFFFF8117A421 mov [rbp+var_35], 0C8h ; '+'

.text:FFFFFFFF8117A425 mov [rbp+var_34], 94h ; 'ö'

.text:FFFFFFFF8117A429 mov [rbp+var_33], 12h

.text:FFFFFFFF8117A42D mov [rbp+var_32], 0E6h ; 'µ'

.text:FFFFFFFF8117A431 mov [rbp+var_31], 87h ; 'ç'

Converting this code to Python and applying it to the extracted ".text" section from the binary we get the "executable" code section. Simply replacing the original section with the new one allows us to run the binary offline. However, we still get the same "Password" prompt and have to figure out the correct input to get the key.

The logic of the binary is to read a stream of bytes from STDIN, check for specific characters and either increment or decrement two variables depending on the characters used. Next, the variables are used as offsets into an array of ones and zeros and when the value of "1" is indexed into the process will exit with failure. Thus, the solution is to construct the correct character sequence that results in proper indexing without hitting a "1" and the length of input must be 80 characters.

The array represents a 15x15 matrix which is a maze that has a single solution. In this case it was easier to just print out the maze and apply the character sequences (w, s, a, d) which represent direction (up, down, left, and right) without coding a maze solver. Start from top-left and finish at the bottom-right.

$ pyton maze.py

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

$ ./crackme

Password: ssddsssassdddssssdssaawaasssddddddwwwwwwddwwwwwdwwdddsssssaassssaasssddddwwddsss

You win !

HITB 2011 Amsterdam Round Two Quals Binary

2011-04-09T23:38:00.001+00:00

The provided binary is a ELF file designed to be run by inetd and accepts several character based commands followed by their parameters. The main loop reads a character from STDIN (in inetd a socket is duplicated into standard I/O descriptors) and based on the value picks a handler from an array of function pointers. The following commands exist:

'f' - return meta data for a given file name
'l' - list filenames from the home directory
'q' - terminate the process
's' - return symbolic link's path name
'v' - verify input with a key file's data

After mapping out all the available handlers and reviewing how they work there were no obvious vulnerabilities (e.g. buffer overflow). The handler functions that expect additional input first allocate some heap-based memory to store this input and care is taken to make sure it's not overflowed. After the handler completes its work the memory is freed. However, there's a design flaw in the way allocated memory is used when the key text is verified. Specifically, the key data is read into a allocated buffer and compared to the string supplied by a user. Once this is done the memory is simply freed, which returns the memory block to the free pool still containing the key data.

As a result, we can use another handler, which allocates memory for its operation and returns the results to the user. One such command is the 's' character, which accepts a symbolic link as a parameter. Additionally, after listing the contents of the home directory using the 'l' command we find few symbolic links that can be used for the 's' command. Thus, when requesting to view a symbolic link the real path will be copied to a allocated buffer. Since the buffer will come from the free pool and the contents were not cleared then whatever data was there will also be displayed. If the resulting path is shorter in length than the data size of the "KeyFile" we can disclose part of the secret key string.

Looking at the handler for the 'v' command it was identified that a string comparison is performed only on the last 14 bytes of the key file. This tells us how much of the disclosed key file's data we need to grab. Thus, to reproduce we need to submit the 'v' command with any key, which stores the key data into a buffer, but does not clear it after the comparison. Then, submit the 's' command to display the path of the "t1" link, which is short enough to disclose more than 14 bytes of the key file. Finally, take the last 14 bytes and submit them via the 'v' command again and this time the comparison succeeds and gives us the solution key.

The solution string is (w/o quotes): "DwightIzK00l"

Codegate 2011 Quals - Binary 300

2011-03-07T23:44:00.001+00:00

The question is:

Find a malicious ID!!

The binary is a Browser Helper Object (BHO) DLL with a static XOR key "securecodegate", which is used to decrypt few arrays with statically assigned characters to each index. The "sub_1000233E" function is called with the array and a XOR key as input to perform the decryption. This occurs three times within a handler function "sub_1000270A".

The first two calls are irrelevant as they result in decryption of "google_ads_frame" (key "secure") and "client" (key "code"). However, the third call produces the answer string using the "gate" key.

This was identified by looking for various interesting strings in the binary and locating their use references. The XOR decryption routine is fairly simple and can be performed via a IDC script.

We used a lazy/simple option. Register the DLL ("regsvr32 b300.dll"). Launch Internet Explorer, attach a debugger, locate the handler function ("sub_1000270A"). Modify EIP to jump to the buffer initialization sequence, which is right before the decryption function call (e.g. @ 0x10002C96 for the "gate" key).

The answer is:

ca-pub-0123456789012345

Codegate 2011 Quals - Binary 200

2011-03-07T23:31:00.002+00:00

The question is:

Reverse Me!!

The binary is a console based PE file. Running the file produces no output due to a certain routine terminating the process before the "main()" function starts. Looking around the code the "sub_401130" function stands out due to initialization of a local array with various bytes. At the end of this function a decryption routine is called ("sub_401070") with the array as input. The decryption loop performs an XOR operation using the string's length as the key.

To obtain the answer a breakpoint was placed @ 0x00401494, which calls the "ExitProcess()" library function prior to "main()". Next, modify EIP to point to the start of the array initialization routine and execute until the decryption function is called. Let it do its XOR job and look at a local buffer once complete to get the answer string.

The answer is:

http://forensic-proof.com/archives/552

Codegate 2011 Quals - Forensics 300

2011-03-07T23:21:00.002+00:00

The question is:

we are investigating the military secret's leaking. we found traffic with leaking secrets while monitoring the network. Security team was sent to investigate, immediately. But, there was no one present. It was found by forensics team that all the leaked secrets were completely deleted by wiping tool. And the team has found a leaked trace using potable device. Before long, the suspect was detained. But he denies allegations.

Now, the investigation is focused on potable device. The given files are acquired registry files from system. The estimated time of the incident is Mon, 21 February 2011 15:24:28(KST). Find a trace of portable device used for the incident.

The Key : "Vendor name" + "volume name" + "serial number" (please write in capitals)

Enumerate a timeline of USB activity from the backup system hive

...
Disk&Ven_Corsair&Prod_UFD&Rev_0.00,Thu Feb 17 04:41:02 2011,ddf08fb7a86075&0,Thu Feb 17 04:41:03 2011,Corsair UFD USB Device,
Disk&Ven_FM&Prod_Memorette_Swing&Rev_1.00,Thu Feb 17 06:38:21 2011,2008090256000000000000BE&0,Thu Feb 17 06:38:22 2011,FM Memorette Swing USB Device,
...

The enumeration shows all of the USB devices ever connected to the system. The registry last modified times are written the first time the device is connected, but are not updated when a device is subsequently connected.

Running a timeline on the registry (via "regripper"), we see that only one USB device is connected on Feb 21:

Mon Feb 21 06:24:21 2011Z HKLM\ControlSet001\Enum\WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_CORSAIR&PROD_UFD&REV_0.00#DDF08FB7A86075&0#\Properties\{80d81ea6-7473-4b0c-8216-efc11a2c4c8b}

From there, we know that the suspect device vendor is "CORSAIR" and the serial number of the device is "DDF08FB7A86075". Inspection of this registry path reveals that the default name of the device has been changed. The registry key "FriendlyName" has a value of "PR0N33R", which is the displayed volume name when the device is connected.

The answer is:

CORSAIRPR0N33RDDF08FB7A86075

Thanks to our team member tina for the solution.

Codegate 2011 Quals - Network 100

2011-03-07T22:50:00.002+00:00

The question is:

This data is related to any attack.
calculate the md5sum of the intended file.

(calc md5 uppercase)

The provided binary is a PCAP file containing bunch of HTTP traffic and some SMB chatter. The question mentions an attack. Since it's heavy on HTTP usage then it made sense to get a list of all requests. Two strange requests stand out:

GET /H1A1.html HTTP/1.1
GET /H1A1.exe HTTP/1.1

Carving out (using Wireshark's "Follow TCP Stream" -> "Save As") the "H1A1.exe" response and removing the HTTP response header we end up with a regular PE file. Next, calculate its MD5 checksum and convert to upper case.

The answer is:

7A5807A5144369965223903CB643C60E

The Manifesto

2010-05-26T20:32:00.004+00:00

+++The Mentor+++
Written January 8, 1986

Another one got caught today, it's all over the papers. "Teenager Arrested in Computer Crime Scandal", "Hacker Arrested after Bank Tampering"...

Damn kids. They're all alike.

But did you, in your three-piece psychology and 1950's technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him?

I am a hacker, enter my world...

Mine is a world that begins with school... I'm smarter than most of the other kids, this crap they teach us bores me...

Damn underachiever. They're all alike.

I'm in junior high or high school. I've listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. "No, Ms. Smith, I didn't show my work. I did it in my head..."

Damn kid. Probably copied it. They're all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me.. Or thinks I'm a smart ass.. Or doesn't like teaching and shouldn't be here...

Damn kid. All he does is play games. They're all alike.

And then it happened... a door opened to a world... rushing through the phone line like heroin through an addict's veins, an electronic pulse is sent out, a refuge from the day-to-day incompetencies is sought... a board is found. "This is it... this is where I belong..." I know everyone here... even if I've never met them, never talked to them, may never hear from them again... I know you all...

Damn kid. Tying up the phone line again. They're all alike...

You bet your ass we're all alike... we've been spoon-fed baby food at school when we hungered for steak... the bits of meat that you did let slip through were pre-chewed and tasteless. We've been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now... the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn't run by profiteering gluttons, and you call us criminals. We explore... and you call us criminals. We seek after knowledge... and you call us criminals. We exist without skin color, without nationality, without religious bias... and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it's for our own good, yet we're the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can't stop us all... after all, we're all alike.

BIND 9 Dynamic Update DoS

2009-08-06T15:48:00.002+00:00

Vulnerability described in CVE-2009-0696 is very easy to exploit and the consequences can be disastrous.

All it takes is a singled DNS UDP packet with Dynamic Update structure specially crafted for any Zone which the target server is Master and the named process will exit.

As stated by ISC BIND's update ACLs do not mitigate this vulnerability. Since this is UDP then source IPs can be spoofed and nearly impossible to track down. Even DNS infrastructures which are designed to expose only slave servers to the Internet can be vulnerable if any of them have Master Zones for netblocks mentioned in RFCs 1912 Section 4.1 and 1918 Section 3.

Anyone who wishes to audit their environment can utilize the following Python script. Make sure you have permission to test your targets!.

Given the criticality of this vulnerability several IDS vendors have released detection signatures. However, as of this writing the above script evades the following signatures: Sourcefire and Emerging Threats. Both groups will be notified with necessary information.

milw0rm is gone

2009-07-08T16:00:00.003+00:00

This was on the site before it went down:

Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don’t :(. For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn’t fair to the authors on this site. I appreciate and thank everyone for their support in the past.
Be safe, /str0ke

PS: I'm keeping their link here for historical reasons.

Tornado exploit pack

2009-05-29T04:41:00.007+00:00

Like most other exploit packs it's written in PHP with a MySQL backend. Control panel supports configuration options for several users (attackers).

Has the ability to control incoming traffic. It can either:

- Ignore
- Redirect
- Display custom page

based on several criteria such as:

- Country of origin
- Visitor uniqueness
- Vulnerable client
- Not vulnerable client

Displays several different statistics based on:

- Victim's Country
- Originating web site (referer)
- Exploits used
- Detailed Log (IP, time, browser, exploit used, infected (yes/no), and referer)
- Overall Summary - OS and Browser breakd down of traffic and exploit effectiveness

Exploit is delivered in the form of obfuscated javascript. Obfuscated ASCII encoded code and decryption function are delivered to the client as a single long line. This content is unique on every visit except certain parts of the decryption routine. Upon successful exploitation another request will be made to the exploit server to a different script which will deliver the binary to execute.

The following is a list of exploits available to the attacker, which can be individually selected to target:

- MDAC (RDS)
- WebViewFolderIcon.SetSlice
- VML
- MS06-044
- WMF Firefox
- WMF Opera 7
- QuickTime
- WinZip
- Zenturi
- Yahoo Webcam
- Opera 9 - 9.20
- XML Core Services
- Java bytecode
- ANI

Default script for exploit delivery is "count.php", while individual exploit modules are located in the "exploits/" directory with the following naming convention: "x#.php" where # is the numeric value starting with one (1).

Upon successful exploitation another request will be made to retrieve a binary for execution on victim's computer. By default the requested script will be "getexe.exe" with the following parameters:

?o= integer value to identify attacker
&t= integer value represents time the exploit was generated
&i= integer value represent IP address of victim
&e= integer value represents exploit number used

Following is the schema of the database:

CREATE TABLE `stats1` (
`ip` int(10) unsigned default NULL,
`time` int(10) unsigned default NULL,
`country` tinyint(3) unsigned default NULL,
`browser` tinyint(4) default NULL,
`version` varchar(8) default NULL,
`os` tinyint(4) default NULL,
`refdom` varchar(32) default NULL,
`status` tinyint(4) default NULL,
`loader` tinyint(4) default NULL,
`expl` tinyint(4) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

CREATE TABLE `users` (
`id` smallint(5) unsigned NOT NULL auto_increment,
`user` varchar(16) default NULL,
`pass` varchar(32) default NULL,
`premis` tinytext,
`options` tinytext,
`lasttime` int(10) unsigned default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1;

Improvements to Zeus

2009-05-23T01:47:00.006+00:00

Zeus's development is active these days. Below is a table of release dates for each version:

2008/12/20 - 1.2.0.0
2008/12/30 - 1.2.1.0
2009/03/11 - 1.2.2.0
2009/03/28 - 1.2.3.0
2009/04/02 - 1.2.4.0

This change log entry states that during HTTP communication of the Trojan with the C&C server the User-Agent used will be that of system's Internet Explorer. Before, it was a constant string embedded in the binary, which could have raised suspicion or blocked by ISPs.

Zeus / Zbot / Prg / Ntos / Wsnpoem

2009-04-26T16:28:00.005+00:00

Real name of the trojan package is Zeus. It comes with a PHP based control panel and a Windows executable to build the trojan. Builder's job is to parse a text based config file, encrypt it, and embed some options into the trojan. The builder can also remove the infection from the system.

Main scripts of the control panel are:

"in.php"

Script which controls authentication to the admin panel as well as all reporting and configuration options of the botnet.

"s.php"

This is the script which accepts all communication from the bot client on a compromised computer. Depending on configured options it will either insert the data into a MySQL database, or store inside a seperate directory, or both.

It's responsable for decrypting the POST data and parsing individual stolen records. Basically, this is the main C&C script of the botnet.

Keep in mind that these filenames are not hardcoded anywhere but are only the defaults. If the filename is changed on the server then the bot client must be updated with a new configuration file, which it periodically polls off the server. Typical configuration file will have entries similar to the ones on this screenshot.

Currently, Zeus' build tree is 1.2.x.x which, depending on subversions, will utilize either RC4 encryption or a simpler form of it. Otherwise, the record and configuration structures remain the same between different 1.2.x.x builds. Older versions, prior to 1.2.x.x used a completely different structure and obfuscation method. They contained a unique field in the HTTP headers during C&C communication and thus were easily detected via IDS signatures from Emerging Threats (2003182, 2003183, 2007688, 2008100, 2008326)

So, what can this bot/trojan do?
It has the following abilities:

Credential stealing of FTP and POP3 on any TCP port.

Via a custom build can capture any data.

Capture of HTTP and HTTPS traffic.

Proxy server via Socks 4/4a/5, even if compromised device is behind a NAT.

Screenshot capture of the desktop.

Theft of "Protected Storage" data.

Here's an example how a communication flow between bot/trojan and C&C server will look like.

Unique Pack

2009-02-28T14:31:00.005+00:00

Exploits for Opera9, Firefox, Internet Explorer 4, 5, 6, and 7. Seperate module to exploit Adobe Reader util.printf() (CVE-2008-2992) vulnerability. Also, includes a module to deliver binaries via social engineering the visitor into accepting the download, similar to Fake AV.

So, what's so unique about it? Nothing really. Perhaps the fact that it obfuscates its PHP code which contains exploits, which isn't difficult to take off. Also, maybe because it doesn't use any parameter passing to scripts via URL, as most other packs do. Here's a summary of some scripts:

"cfg/config.php"

Defines variables for loader and exploit URLs, database credentials, and control panel credentials.

URLs are defined for loader script ("load.php") and Adobe PDF exploit ("pdf.php").

Filename of binary which will be dropped ("1.exe").

Database host, name, credentials. Default DB name is "spl".

Control Panel's script name ("admcp.php"), username, and password (double MD5 hash of real pass). Default user is "root".

"cfg/options.php"

Defines functions and text for 404 page. Functions to identify browser, operating system, country (based on GeoIP), and encoding function to Unicode for Javascript (eg: "%u9090").

"cfg/mod_vparivatel.php"

Configuration variables for social engineering module to convince the user to download the binary, similar to the idea used in RogueAV schemes.

"install.php" or "_install.php"

Database creation script. Will connect to the database with configured credentials and create necessary table.

CREATE TABLE `statistic` (
`id` int(10) NOT NULL auto_increment,
`ip` varchar(15) default NULL,
`os` varchar(30) default NULL,
`br` varchar(30) default NULL,
`country` varchar(2) default '--',
`good` int(1) NOT NULL default '0',
`mv` int(1) NOT NULL default '0',
`refer` varchar(300) NOT NULL,
`date` datetime default '2008-10-01 00:00:00',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1;

"index.php"

Checks for presence of "install.php" and executes it. If visitor's IP was already logged then aborts with HTTP 200 status but shows a 404 page as defined in the variable of the "cfg/options.php" file.

Identifies country, browser, operating system, referer, IP address and updates the database. Includes "sploit.php" file for exploit generation.

"sploits.php"

Checks if "Unique" name is defined and aborts with 404 message from predefined variable if not defined. Determines the browser and loads appropriate exploit script:
"sploit/op9.php" - Opera
"sploit/ff.php" - Firefox
"sploit/ie7.php" - Internet Explorer 7
"sploit/ie.php" - Internet Explorer 4, 5, or 6.

"load.php"

Reads the executable which was defined in config file and serves it to the user. Updates database column "good" for this connection's IP address.

"pdf.php"

Contains the exploit for Adobe Reader ; CVE-2008-2992 ; util.printf(). Interestingly, the file contains obfuscated PHP script to generate the exploit. It has some protection against people attempting to modify the code and print out the exploit. It reads itself and looks for calls to "print | sprint | echo" and aborts if found. This prevents people from simply modifying the "eval" statement to see the real exploit code.

"vparivatel.php"

Delivers an executable file using social engineering technique similar to RogueAV by convincing the user of a threat or some required update. Messages can be customized per browser, operating system, and country.

Checks if visiting IP was already given a binary using this method and aborts if found.

If GET parameter "?a" is set then delivers the binary otherwise displays a convincing message and redirects back to itself with proper parameter.

Armitage 1.0

2009-01-12T03:11:00.002+00:00

This is a rather old version dated back to November 2007 but perhaps someone will find this info useful.

On the server side it's driven by PHP with MySQL as the backend. File structure is similar to other packs. One noticable difference in the way statistics are tracked, as all packs track visitors and these numbers are used in marketing of packs.

Armitage has an additional section to calculate how many visitors were actually compromised. Typically this is done by recording how many people request a download of a loader (trojan binary) which means the exploit worked. However, this does not account for the fact that loader may have been blocked on the client due to various defenses. Any pack's job is to deliver an exploit and load some binary and many packs are satisfied with just recording such requests. In Armitage's case it is accomplished by recording an additional request which must be made by this loader. This statistic will represent how many devices have been compromised and have gotten the loader to fully execute and check-in. It is unclear why this decision was made for a generic pack since loaders will now have to be specifically written to perform this check-in function. Such loader was not distributed with the pack itself so it is possible that this was not written for general public.

"config.php"

Contains password variables for admin and guest.

"db.php"

Defines variables needed to establish database connection (host, schema, user, and password).

"install.php"

Establishes a database connection and creates the necessary tables. Once complete shows a link to admin page and required credentials.

"admin.php"

Defines two valid accounts admin and guest. Shows traffic and loads statistics as well as has the ability to upload a new trojan and change passwords.

"index.php"

Defines various functions which identify the visitor based on UAS.

Creates the URL for loader "exe.php" and if GET contains "?ex=" integer then this value will be passed to "exe.php?ex=".

Checks visitor's IP address for previous visits and aborts if one is found. String "^_~" is returned upon abort.

Identifies the browser, the following list is used: Opera, Konqueror, Lynx, Links, Internet Explorer, Netscape, Firefox, Mozilla, Other.

Identifies the OS with the following list: Windows (95, NT 4, 98, ME, 2000, XP, 2003, Vista), Linux, Mac OS, Other.

Identifes the Country based on GeoIP library from visitor's IP address. Geoip files are borrowed from Icepack.

Updates statistics for HTTP Referrer, domain only. Sanitizes the referrer domain to avoid SQL injection.

Updates statistics for Browser, OS, and Country. Inserts visitor's IP address and time of visit.

Exploit is served for Internet Explorer from "e.php", for Opera from "opera.php", and Firefox from "ff.php".

"exe.php"

Second stage of the exploit sequence, which serves the binary file. By default it is "./load/file.exe", but if GET "?ex=" integer was set then file with that value is delivered (eg: "./load/file20.exe"). Identifies the visitor (Browser, OS, Country) and updates "loads" statistics table.

"lds.php"

Identifies the Country based on Geoip of the connection and updates the "ots" (otstuk) statistics table. This is the place where loader's check-in stats are kept.

"e.php"

Serves the MDAC exploit slightly obfuscated. CVE-2006-0003 ; MS06-014 ; MDAC (BD96C556-65A3-11D0-983A-00C04FC29E36). If this fails then will load "bof.php".

"bof.php"

Contains the shellcode for buffer overflow exploits.

Serves the WFI exploit. CVE-2006-3730 ; MS06-057 ; "WebViewFolderIcon.WebViewFolderIcon.1.setSlice()".

At the end display the 404 Not Found page which is fake since real HTTP Status code is still 200 OK.

"ff.php"

Serves exploits for Firefox browsers

"opera.php"

Serves exploits for Opera browsers

PE offsets within malware

2009-01-04T15:19:00.003+00:00

Building on work mentioned in the previous post couple of more interesting facts were identified. Realizing that implementing the Snort's SO rule may not be feasible in some infrastructures, depending on the design and configuration of the sensors, it would be beneficial to identify most common offsets used by malware and how they compare to legitimate executables.

After reviewing offsets found in an installation of Windows XP SP2 system utilizing 8000 samples, both executable and DLL files, and then comparing with offsets found in malware collected over the last year and a half (450 samples) there were several unique offset identified which were solely used by malware.

As a result of this several regular Snort signatures can be written which will alert on download of binaries which should raise suspicion.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE under 128)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,<,128,58,relative,little; content:"PE|00 00|"; rawbytes; within:130; sid:62; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 12)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,12,58,relative,little; content:"PE|00 00|"; rawbytes; within:14; sid:53; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 16)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,16,58,relative,little; content:"PE|00 00|"; rawbytes; within:18; sid:54; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 64)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,64,58,relative,little; content:"PE|00 00|"; rawbytes; within:66; sid:55; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 96)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,96,58,relative,little; content:"PE|00 00|"; rawbytes; within:98; sid:56; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 124)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,124,58,relative,little; content:"PE|00 00|"; rawbytes; within:128; sid:57; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 144)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,144,58,relative,little; content:"PE|00 00|"; rawbytes; within:146; sid:58; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 152)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,152,58,relative,little; content:"PE|00 00|"; rawbytes; within:154; sid:59; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 160)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,160,58,relative,little; content:"PE|00 00|"; rawbytes; within:162; sid:60; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 512)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,512,58,relative,little; content:"PE|00 00|"; rawbytes; within:514; sid:61; rev:1;)

Couple of interesting and important notes. There was not a single legitimate binary which contained a PE offset under 128 bytes. The offsets in malware which did not match those of legitimate files occured in %25 of malicious samples.

All offsets found:

Suspicious PE offsets (malware of 467 samples):
-----------------------------------------------
12, 16, 64, 96, 124, 144, 152, 160, 512

Legitimate PE offsets (XP Sp2 8582 samples):
--------------------------------------------
128, 168, 176, 184, 192, 200, 208, 216, 224, 232, 240, 248, 256, 264, 272, 280, 288, 296, 304, 312, 320, 336, 344, 392, 584, 592, 600, 608, 616, 624, 632, 1024, 7680

Detecting packed/crypted executables with Snort

2008-11-16T03:17:00.005+00:00

As a result of some research into various trojans it was identified that majority of them rely on packers, crypters, and anti debugging tricks. Nothing new here. However, what was interesting is that some of them were completely missed by Snort. Rulebase included default signatures that come with base installation, community rules, and Emerging Threats (ET).

It turns out that analyzed trojans modified the executable's header which did not fall within signature's patterns. This can be partly fixed by creating a signature to detect the PE header's magic value within a certain distance from the start of the DOS header. However, the trick here is to pick a distance which will not produce false negatives. If it's too short then it's doomed to miss lots of stuff. Higher values may produce false positives, more research into this is needed.

It's best to detect executables by reading their structure. PE/COFF format states that the offset to start of PE header is found 0x3C bytes from start of DOS header. I was not able to achieve desired results using the regular Snort rule syntax but using the dynamic rules feature worked perfectly. It's written C and must be compiled. Download it here.

Importance of verifying vendor's protection claims

2008-10-26T17:59:00.003+00:00

One of my favorite fundamental security principles is perfectly summarized by this blog post: "Are you Secure? Prove it.

This is true for any situation more so for high severity issues like the MS08-067 vulnerability. So, one of the big names in enterprise security products came out with couple of signatures in their end user protection product. I won't name which one since it doesn't really matter in this context.

Taking into account that not all organizations can patch immediately, in large enterprises there are many factors which can contribute to the delay, the last resort to protect users is to rely on security software on their workstations. Antivirus can only go so far and it's largely useless these days. However, some HIPS signatures can limit the exposure.

So, this HIPS product rolled out signatures to supposedly detect and prevent the attack. After testing their claims it turned out that it only blocks exploit attempts from the workstation which has this HIPS installed. Any attacks against this workstation will be successful. It is beyond me why this decision was made. It'll stop the worm from spreding but it won't protect the client from being infected by the trojan which can easily be downloaded by the shellcode.

Interestingly, the response from the vendor was that they created detection for the most common exploit vector. I understand that it's not always possible to create signatures for the vulnerability, product has its limitations, thus only specific exploit vectors are detected.

But in this case it wasn't event the most common vector. My tests used the code which was published on milw0rm by stephenl and at that time had just over 10,000 views, currently at over 16,000. I would think that the vector used in that PoC would be the most common since it's quickly copied by many other hacking sites.

Thus, if organizations rely on their security vendor's claims and don't have in-house expertise to verify those claims then they're at a high risk of having a false sense of security. Considering that this product is from a rather large security vendor then the list of those organizations is rather large.

On the upside, vendor was notified and is currently working on updating their detection.

Neosploit devel/updates retired! However...

2008-08-27T04:35:00.003+00:00

It seems that development of this exploit pack has ended. The message basically states that efforts which are put into development are not returning enough income and supported is ending.

However, this does not mean that you will no longer see exploits delivered via this framework. There are many installations of it out there and it's still one of the best exploit packs, although it was expensive. Also, the Neo folks have released instructions/script on how to move the CGI program from one server to another. Previously, this had to be done with the help of Neosploit Support, as the binary was compiled for specific server. If source code is leaked out or released then it's highly likely that more malware will be delivered through it.

Now, that background info behind us, we have seen something interesting which leaves more questions then answers. We have identified a site which utilizes this pack to drop a binary which seems to be associated with the recent fake Antivirus malware.

What is of most interest is the fact that the obfuscated script, mainly the deobfuscation function has some modifications to its code. Several key statements were rearranged in such a way that logic isn't changed.

Why make such a change? Is it a change or some older build which had a short life span and wasn't updated since? We've been keeping an eye on Neosploit's progress for many months now and have never seen this code sequence. We have observed similar minor changes before, during active development, but now since it's supposedly retired the update does stand out. Is it possible that source code was leaked? or did someone just modify the binary in place, and for what purpose, evade detection?

More research is needed to confirm if this change occurs elsewhere, on other domains hosting Neosploit.

le fiesta - another exploit pack

2008-08-23T06:07:00.002+00:00

This is yet another web based exploit pack which utilizes PHP and SQL. Overall, it's similar to the other PHP based packs except here the file structure is much more compact, not that it really matters, and it's less smart about serving out exploits (not loaders) to already visited victims.

Uses two layers of encryption/obfuscation via Javascript with random function and variable names upon each visit. Here's a rough list of included exploits:

COM objects
(see metasploit)

"?spl=com"
EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F CreateControlRange

"?spl=vml2"
DirectAnimation.PathControl

"?spl=wfi"
WebViewFolderIcon.WebViewFolderIcon.1 setSlice()

"?spl=zango1"
8C875948-9C60-4381-9248-0DF180542D53 DownloadAndExec()

"?spl=zango2"
BFC08CFF-C737-4433-BD5A-0EE7EFCFEE54 DownloadAndExec()

"?spl=myspace"
48DD0448-9209-4F81-9F6D-D83562940134

"?spl=ymj"
5F810AFC-BB5F-4416-BE63-E01DD117BD6C AddImage()

"?spl=buddy"
Sb.SuperBuddy.1 LinkSBIcons()

The ?spl= parameter will be passed to "load.php" which will update statistics of each exploit.

"Army cyber ops"...

2008-08-22T02:50:00.003+00:00

In a Government Computer News article there was an interesting fact mentioned which hints at Army's cyber command centers ability to handle contigency issues.

It was stated that many of their links utilize undersea cables but some also use land based fiber. One of such land links was severed by a garbage truck, disabling service to their northern and southern continental CC for several hours.

Now, I know how difficult it can be to design and run a full contigency operation but one would think that with the budget and resources of a government such a goal should not pose too much of a problem. Apparently, this is not so for Army's cyber ops.

To be honest, it's a big surprise to me. I've seen companies not lose a single tcp connection upon core router/switch failures, cable cuts in server racks, and power outages in data centers and they don't have the same resources as the government can afford.

This isn't a good sign especially in light of more and more talk regarding large scale cyber warefare. Hopefuly, that garbage truck incident served as a lesson. On a bright side, at least the guys at the monitoring consoles got a decent break :)

Why I love cons...

2008-08-16T04:41:00.003+00:00

Some great talks, interesting presentations and new ideas. Also, you get to meet very interesting people and get to pick their brains or just hang out and enjoy their strange and wonderful personalities.

However, the best is when you discover people who are true hackers. By that I mean people with a certain state of mind who take a creative approach to solve problems.

Here's an example which proves that a real hacker does not need a computer but only his brain:

And yes, this guy was hacking away at deciphering some message.

Analysis of the Adobe exploit within Neosploit

2008-05-24T03:32:00.007+00:00

It appears that currently the toolkit is under active development. Adobe vulnerability which is exploited is one from CVE-2007-5659 disclosure.

We have seen some old exploit being added, removed, then added again. This was the MS06-067 DirectAnimation.PathControl.KeyFrame() vulnerability. More on this one later.

The function which exploits Adobe vulnerability (CVE-2007-5659) will try to load ActiveX controls in the following order:

1. AcroPDF.PDF
2. PDF.PdfCtrl

If successful then it'll identify the version in use and will continue only if it's below 8.1.2, which makes sense since Adobe realeased an unpdate with this version that fixed the issue. Then, the version is inserted into an already embedded URL string to download the actual PDF file.

Returned PDF file is around 10K in size and contains Zlib compressed obfuscated Javascript. Thus, any IDS detection which looks for the vulnerable code will not pick this one up. Obfuscation method is the same as for all other pages. After peeling this layer off one finds the familiar heap spray function to populate memory with the shellcode. Then, once again a version check is performed. Finally, a long string is created (~ 44K) and used as an argument to Collab.collectEmailInfo() method.

If the overflow works, then the shellcode will GET a URL which is the same as the one before except for one changed byte (from 01 -> 02), perhaps to track which stage is requested. That file is an Executable which will be saved in the user's Temp directory as "sxoC.exe".

For those who rely on HIDS/HIPS, AV, nIDS/nIPS chances are nothing will be seen, unless the dropped binary gets picked up by AV (right!).

Neosploit development update

2008-05-20T19:26:00.002+00:00

For the past month or so we have been observing more activity in Neosploit's development. Exploits are being removed then added and new ones introduced. To be fair in relation to the previous post we can now confirm that Adobe exploit IS being used by this toolkit.

Another interesting change is less obvious and not so important to Incident Responders but more so for Intrusion Detection folks. The main Javascript deobfuscation function has seen some changes recently. So, those of you who depend on IDS to detect the script should probably review their traffic, honeypots, hids, etc... for new changes.

Neosploit update and changes

2008-05-13T04:23:00.004+00:00

Some interesting changes we have observed:

- URL scheme changed
- Javascript deobfuscation updated
- Vulnerabilities exploited changed

Javascript deobfuscation code has changed a bit. Previously, to get to the actual exploit code one had to go through two decryption stages, this time an additional stage is added to the very first layer. This additional layer does not make a request out to the server.

Basically, upon first visit to the Neosploit site a browser gets one big obfuscated Javascript page. It executes the decryption function which results in another obfuscated javascript layer. This second layer decrypts itself and then runs real javascript of the first stage. This stage adds some encoded parameters to the URL for the second stage.

URL scheme for requests to exploits and binaries has been updated. It appears that a full structure is passed as a parameter to the main script. This struct is hex encoded as a string and uses various flags and variables to track victims and statistics.

Javascript decryption function utilizes the "arguments.callee" trick to convert itself into an uppercase string and use offsets within this string to decrypt the payload. This is the main deobfuscation characteristic of Neosploit. Several changes have been made previously which break down the methods into seperate variables instead of using them directly.

An interesting addition has been included recently, which appends Neosploit's web address to the decoding offset string. Thus, to successfully decrypt the payload the original full address of the script must be known. Also, at the exploit stage there's a function which sets a unique cookie ("ID") with a specific value for a given exploit.

Stage 1

First stage is the initial visit (iframe, redirect, ...) to Neosploit page. At this point a structure is created based on public variables such as the User Agent string and IP address. Then the server returns obfuscated Javascript page, which is dynamically generated with random variables, and contains the first part of the URL for the next stage.

Stage 2

This stage is obfuscated with two layers and then attempts to identify the victim's Service Pack level, and system's language then builds a request string with these parameters to get the second stage. This request URL has a specific argument to the main script. First part is added by the server upon initial visit and consists of various hashed parameters then SP level and language string is appended.

Stage 3
Deobfuscation yields the exploit code for the following vulnerabilities (in exploit order):

- CVE-2006-0003 ; MS06-014 ; MDAC (BD96C556-65A3-11D0-983A-00C04FC29E36)
- CVE-2006-5820 ; "Sb.SuperBuddy.LinkSBIcons()" ; Cookie ID = 9
- CVE-2007-5779 ; "GomWebCtrl.GomManager.1.OpenURL()" ; Cookie ID = 13
- CVE-2008-1472 ; CA BrightStor ArcServe Backup AddColumn() (BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3) ; Cookie ID = 21
- CVE-????-???? ; "QuickTime.QuickTime.4" ; Cookie ID = 6

PS: Symantec stated that recent Adobe vulnerability was being exploited by this toolkit, however the instance which was analyzed for this post did not include any Adobe exploits.