Yet Another Java Security Warning Bypass

Not so long ago we posted about a JavaSecurity Warning bypass that used a serialized applet instance.

That bypass was fixed in Java 7 update 13 so we had to keep looking at new ways of defeating the warning pop-up that requires user interaction in order to run applets.

We continued auditing the code that performed the checks when starting an applet and ended up arriving at the method “sun.plugin2.main.client.PluginMain.performSSVValidation(Plugin2Manager)”

This method will end up calling some other methods in the com.sun.javaws.ui.SecureStaticVersioning class that will show us that annoying security warning pop up.

But just take a quick look at the performSSVValidation method implementation:

What is that __applet_ssv_validated parameter??

Obviously this is an internal undocumented parameter and, as you can see, it turns out that if it is set to true, no checks are performed.

The first thing we tried was to simply set that parameter to true in our evil applet, but it didn't work.

While debugging we noticed that the parameter was not set on the applet despite our setting it to true.

Basically sun.plugin2.main.server.MozillaPlugin.addParameter(String, String) is filtering the parameters:

But as you may know, Java provides another way of launching applets in a browser besides using the applet, object or embed tags.

Java Web Start technology is what we can use.

Now the applet description is provided by using a JNLP file and parameters can be set to the applet by using the <param> tag.

We can see that when using Java Web Start, the performSSVValidation method is also called

So lets try to launch an applet with Java Web Start and set the __applet_ssv_validated parameter to true with a JNLP file like this one:

And by know you have already realized that this just works and parameters are not filtered.

The Security Warning pop-up message is not displayed and our applet happily runs!

Ironically on Tuesday 16th April, exactly while I was at the Infiltrate MasterClass  teaching how to audit and exploit Java, Oracle released update 21 which fixed this bypass and a ton of others.

The time investment for stealthily exploiting Java is increasing but finding bypasses like this makes it worth the time!

Esteban Guillardoy

WIN at CBC

I win at the demo-run of Immunity Web Hacking class today. Who want to try to be "superuser" ? 

Immunity Releases an Exploit for the Linux Kernel PTRACE vulnerability

Linux PTRACE CVE_2013_0871

Solar Designer calls this one of the more dangerous Linux local exploits since  CVE-2010-3081. (c.f. http://seclists.org/oss-sec/2013/q1/342 )

There's some contention over how easy it is to exploit, and like many race conditions, it's not simple. Our current version works on 64 bit kernels in VM's (which have not been patched). To be perfectly honest, we largely tested this on VMWare VMs, so on other hypervisors YMMV.

2.6.29 changed the creds structure, so currently our released exploit is only 2.6.29 or greater. We do have a 32 bit version and a 2.x version which we'll finish testing and release at some point in the near future. And we'll try to fix the 64 bit version to work on non-VM's. It's going to be a while until this hits normal CANVAS as we need to finish 64-bit Linux MOSDEF in order to integrate it properly.

That said, VM's are in fairly common use at the moment so we thought people would get value out of it as-is.

Enjoy!

Exploit discussed in this blog post is here: https://ceu.immunityinc.com/immpartners/linux_ptrace_setregs.tar

Of course, you'll need a CANVAS Early Updates subscription to download this. You can email sales@immunityinc.com if you don't have one.

Hacking the web: Exploiting CBC with Padding Oracle

The process of writing the material of a training is very organic. Not in the way where you replace meat with tofu, but rather a process of evolving the material for each new edition.

No matter how experienced a teacher can be on the subject, students learning process are different for everyone and so is their background experience. In short, building training that is effective for a large range of people is as hard as building an exploit that is effective against a large range of machines.

That's why after each edition we try to re-write what we think are the weakest parts to make the training more targeted towards how students learn best.

As a good example, last year the Web Hacking class had a Padding Oracle section. Not only it was very a novel technique, but we where seeing all kind of bad implementations on our consulting gigs that we were exploiting with this. We decide it to rush it into our class, and fit it into a two hours period. Whether most people in the class understood it and was able to exploit it at the end, we felt that they might have not have grasped the whole concept, so this year we decide it to turn it in a whole Web Crypto day.

Importantly, we decided to build an interactive framework for ECB and CBC (if you're not sure the difference, you should attend the class!), so you could understand how to exploit Padding Oracle in a Web 2.0 environment.

It was painful, but the results are looking good:

Kudos to Matias for the great work, and we are hoping to see you there in less than a month at INFILTRATE 2013's Web Hacking class!

Infiltrate Preview - TrueType Font Fuzzing and Vulnerability

TrueType font files are made up of a number of tables; each table begins on a 4 byte boundary that comprises an outline font and must be long aligned and padded with zeroes if necessary. Referring to the “TrueType 1.0 Font File Technical Specification”, provided by Microsoft; the TrueType font file begins at byte 0 with the Offset Table. Offset Table is divided into 5 subtable:

sfnt version : 65536(0x0001 0000) for version 1.0

numTables : Number of tables

searchRange : (Maximum power of 2 ≤ numTables) x 16

entrySelector : Log2(Maximum power of 2 ≤ numTables)

rangeShift : numTables x 16 – searchRange

Beginning at byte 12, after the Offset Table, is the Font Table Directory. Entries in the Table Directory must be sorted in ascending order by ‘tag’ name. Overall, the Font Table Directory Header consists of:

tag : 4 byte identifier

checkSum : checksum of the table

offset : Beginning offset of the font table entry

length : Length of the table

The Structure of True Type Font Directory

The required tables in the Font Table Directory:

cmap : character to glyph mapping

glyf : glyph data

head : font header

hhea : horizontal header

hmtx : horizontal metrics

loca : index to location 

maxp : maximum profile

name : naming table

post : PostScript information

OS/2 : OS/2 and Windows specific metrics

The optional tables in the Font Table Directory:

cvt : Control Value Table

EBDT : Embedded bitmap data

EBLC : Embedded bitmap location data

EBSC : Embedded bitmap Scaling data

fpgm : font program

gasp : grid-fitting and scan conversion procedure

hdmx : horizontal device metrics

kern : kerning

LTSH : Linear threshold table

prep : CVT Program

PCLT :PCL5

VDMX : Vertical Metrics header

vhea : Vertical Metrics

Due to font validation purposes, the dumb fuzzing technique is not recommended for these fields: ‘checkSum’, ‘offset’, ‘length’ and ‘Table’. To reduce the number of irrelevant tests, a checksum validation program is used to determine the checksum of ‘head’ table.

Fix the Checksum value of the “head” Font Table Directory

During the fuzzing process, the table checksum has to re-compute. The checksum calculation implies 4 byte boundaries as shown in Python program below:

<NOTE TO NICO: NO PYTHON PROGRAM IS HERE>

Our font fuzzer is to fuzz the TrueType font file into different sizes which enables the generation of the test cases to determine the size of font in triggering the vulnerability. Each fuzzing process starts with automating the installation of the mutated font in Windows system. It will then display the font; both in open the font file via fontview.exe and displaying the character maps. Lastly, uninstall the font and repeat the process if no vulnerability is found.

The windll.gdi32.AddFontResourceExA function is used to automate the installation of the crafted font into the “C:\Windows\Fonts” folder.

htr = windll.gdi32.AddFontResourceExA(FileFont, FR_PRIVATE, None)

Once the fuzzing environment is ready, a LOGFONT object is created to define the attributes of a font. 

lf=win32gui.LOGFONT()

Assuming no vulnerability has been found at a font with a specified size that has been called; the windll.gdi32.RemoveFontResourceExW function will be called to remove the fonts in “C:\Windows\Fonts” folder.

windll.gdi32.RemoveFontResourceExW(fileFont, FR_PRIVATE, None)

Another size of font in the range that has been set will be called and the same process will repeat until vulnerability is found or the list of font size elements under a loop function has all been called and no vulnerability is found.

Figure below shows the Blue Screen of Death (BSOD) proof of concept via our font fuzzer. [Editor's note: BOOM! :>]

BSOD of Windows 8 Pro 

The details of the fuzzer and findings will be discussed in the talk. Looking forward to see you guys in INFILTRATE 2013.

--- Ling Chuan Lee & Lee Yee Chan from F13 Labs