Trying to skip the fish

Automated Web application security testing tool “skipfish” was released recently which seem to have generated a lot of attention in the “security community”. So,I decided to give it a try and install it in my lab.

Unfortunately, I run very old Linux distros in my lab (like RedHat 9 for example) and I am too lazy to upgrade to newer versions. Anyways, during installation I soon realized that it’s not that easy to get skipfish up and running on RH9. 

As with any installation on Linux, I had a quick look at the readme and skipfish wiki and went ahead with “make” command only to end up with -

/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
In file included from /usr/include/openssl/ssl.h:179,               from http_client.h:26,

To fix this, I had to edit the “Makefile” in the skipfish dir and add the following entry to the “CFLAGS_GEN” variable –

“-I /usr/kerberos/include/”

Hoping to compile skipfish successfully this time, I proceeded with the make command and was greeted with a different error this time -

http_client.c:39:18: idna.h: No such file or directory

Apparently, I assumed libidn to be present on RH9 and had not read the “knownIssues” doc properly. Thankfully, downloading libidn source and installing was pretty straight forward and went without a glitch. Finally, skipfish compiled successfully !

Sadly, my problems were not over :(. When I tried to run it, I got the following error -

./skipfish: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory

After some googling I found a way to fix this. Just add “/usr/local/lib” to “/etc/ld.so.conf” and rebuild the dynamic run-time bindings cache using “ldconfig –v”.

That did the trick and I had skipfish version 1.13b running on my RH9 system.

Happy skipfish’ing… :)

CVE-2010-0188 Adobe Reader TIFF vulnerability

The recent Adobe reader vulnerability (CVE-2010-0188) seems to be doing lot of rounds these days. Thanks to Mila (contagio blog), I got a chance to look at the malicious PDF file.

A Quick look at the stats using pdf-parser tool reveals the structure of this file -

C:\Analyze>pdf-parser.py -a "2010 March Luncheon Invitation_FINAL.pdf"
Comment: 4
XREF: 0
Trailer: 0
StartXref: 2
Indirect object: 43
12: 44, 45, 46, 55, 91, 92, 112, 114, 115, 117, 115, 135
/Catalog 1: 43
/EmbeddedFile 9: 2, 3, 5, 6, 7, 121, 122, 123, 124
/Filespec 2: 116, 134
/Metadata 2: 13, 13
/ObjStm 9: 125, 126, 127, 128, 129, 130, 131, 132, 136
/XObject 6: 56, 57, 113, 118, 119, 120
/XRef 2: 133, 137

Since most of the PDF exploits are created using embedded JavaScript, my instinct was to look for JavaScript object streams inside the PDF. But that didn’t reveal any interesting results, so I turned my attention to other objects.

The actual shellcode appears to be present in object 119 -

..while the TIFF file in object 122 is used to cause the overflow in the ImageConversion.api -

Finally object 3 contains the reference to TIFF file -

All the streams in the PDF file are compressed, so I had to use the “-f” option with pdf-parser tool to inflate them and see the content. There was also a wave file stream in the PDF which is a little strange, but I could not get it to play !

Both the dropped files appear to be the same as explained in Mila’s previous analysis on the Contagio blog. Lastly, the PDF seems to have been created on 25-Feb-2010 and modified on 03-Mar-2010 using Adobe LiveCycle Designer ES 8.2.

After reading some more on the exploit, I found that the exploit for this vulnerability does not use JavaScript. Which means even if you have disabled JavaScript in Adobe reader, this exploit will work and that probably explains why bad guys are going after this vulnerability despite Adobe releasing the patches last month !