How common is common? Exim and Dovecot

Introduction:
Today a really neat advisory was released by the folks over at RedTeam Pentesting GmbH (RTP) involving a common misconfiguration when using Exim and Dovecot together. The high level is that when you use Exim as an MTA (what sends and receives mail from other servers) and Dovecot as an LDA (serves the mail to users via IMAP/POP3 etc) the example Exim configuration file Dovecot provides to make the MTA->LDA connection work has a bad configuration option whereby an attacker could get command injection on your mail server via sending mail! This is totally rad for a few reasons. First, this is going to be very reliable as it's command injection so there's no memory corruption voodoo to go wrong. Secondly, the vulnerability was introduced from one product into another by way of the admin! Plus the idea of doing command injection via email is pretty great.

In the advisory RTP released they mention that using Exim with Dovecot is a very common configuration, so I decided to see how how common it really was. To do this you'd need SMTP/IMAP/POP3 banners for large IP space, which we have courtesy of SWARM. So I wrote a few MongoDB queries and did some basic work with sets in Python and came up with some interesting answers. Without expounding too much about these data sets, they're non-overlapping IP space. We'll leave it at that as it will give affected admins more time to fix their configs. I've put the results from a few of our largest data sets into a table.

DB Size (IPs)*	Exim banners	Dovecot banners**	Exim + Dovecot	(Exim + Dovecot) / Total Exim
2,086,479	50,533	69,433	36,557	72.3%
1,668,143	629	11869	324	51.1%
753,486	22019	24494	20157	91.5%

* IPs that returned results from a SWARM module, a subset of all hosts scanned for that job
** We counted unique hosts that had at least one Dovecot banner on either IMAP or POP3

Limitations:

1. We did not look at IMAPS or SSL-POP
2. If Exim and Dovecot are not run on the same server it wouldn't be included in our results
3. If IMAP/POP3 are run on non-standard ports it wouldn't be included in our results
4. We did not confirm the presence of the vulnerability beyond banner parsing
5. According to RTP the errant config was introduced in 2009, we could also filter by the presence of dovecot versions released only after 2009. Though this wouldn't take into account configurations that had remained static through upgrades

Conclusion:
When running Exim and IMAP/POP3, Dovecot is an extremely popular choice for an LDA. I think it's fair to say that a majority of administrators would reference the Dovecot wiki or documentation when configuring this setup. As a result this vulnerability is probably present on over a hundred thousand servers. Interestingly there is a lot of regional variance for both Exim and Dovecot, though in all Dovecot appears to be more popular in our data.
Pulling this data out with SWARM was pretty easy and it gave me a rough idea of the impact of the vulnerability. Some folks only rely on the CVSS score but fail to see the larger picture. If you have reliable unauthenticated remote code execution on Bob's Fancy FTP Server that would probably score a 10 on the CVSS scale. But if there are 15 total installs of that software anywhere on the planet, the impact is going to be minimal.

Also, after the fact I learned that Mongo has a built in MapReduce which I need to learn how to use :-/

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!