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 :-/

SWARM and Vulnerability Impact

Yesterday the latest D2 exploit pack for CANVAS was released. In it there was an exploit module for the local file include in TP-LINK's TL-WR841N Wireless Router (CVE-2012-6276). I'd been looking at some data in SWARM that had a high concentration of TP-LINK routers so in the back of my mind I thought that it'd be interesting to see if I could find vulnerable routers with a high degree of confidence.

For those of you playing at home SWARM is Immunity's answer to distributed and parallel CANVAS. If you need to scale CANVAS to hundreds of thousands of IPs per hour, then SWARM is the solution. One of the things that SWARM is really good at is recon on a massive scale which can give you perspective on how much you should care about a particular vulnerability. Sure enough today another interesting router vulnerability was disclosed by the folks at www.s3cur1ty.de, and they were nice enough to include some tips on finding these routers. Having looked at well over 100,000,000 IPs with SWARM at this point I decided to see how many of these routers were really available.

We learned a few things:
1) We had much better results parsing the index page for the webserver than relying on server banners because of #2

2) There are a variety of server headers associated with this product. We saw: Mathopd, "Linux, HTTP/1.1, DIR-[3|6]00", obviously spoofed headers, and even blank server headers

3) Sometimes you get the firmware version in the http server header (2.X series), others you have to parse the server's index.html (1.x), occasionally you wouldn't get it at all

4) Some configurations will leak what appear to be internal host names and MAC addresses to unauthenticated users (name=$HOSTNAME&key=$MAC_ADDR is the string if you're curious). They didn't look like SSIDs but without more context it's hard to tell.

5) There aren't that many easily found routers of this type with their web servers exposed to the internet, out of our data set we found ~1500

6) We found only a handful of routers which met the version criteria to be considered vulnerable

A subtle thing people forget with scans of any real magnitude is that they offer a rolling snapshot of the IP space. The results you get for a particular IP reflect only the results for that IP at the time the request was sent. This may seem obvious but if your scan takes two days to run you can't consider the output to be "Thursday's results". Half your requests went out on Thursday the other half Friday. For environments where hosts are statically mapped this isn't as big of an issue but when you look at big networks it becomes a headache. It's fun to see the exact same host pop up at multiple IPs within the same set of results. It's possible you'll miss hosts entirely if they jump from the end of the IP range to the beginning while the scan is running.

Going through this exercise gave me another idea for SWARM. Many American ISPs now bundle anti-virus with their broadband offerings and security is playing a bigger part of the marketing narrative. I think a neat application of SWARM that fits with this is for your ISP to notify you if your router has a public vulnerability. At some set interval the ISP can kick off a scan that finds all the routers with their webservers exposed to the internet, then filter that through some Python to pick out models with public bugs (which is all of them). Easy, automated, helpful.