It's SSL Story Time with SILICA

The latest release of SILICA has extended its fake AP service impersonation attacks to support the stealing of passwords from secure protocols such as HTTPS, SMTPS, POP3S, IMAPS and also supports the interception of CRAM-MD5 password hashes in a way that can be easily cracked.

But of course you are thinking to yourself "But Mark, in order for that to work the victim would need to accept a counterfeit SSL certificate before any of the traffic could be decrypted! Of course nobody is going to accept your fake certificate!".  This has lead me to believe that some of you would think that the following is a true story:

A guy was driving to a really important meeting (the kind of meeting that would literally change his life for the better) but he noticed a sign on the only road that led to the meeting saying "You probably should not go down this road because someone could be trying to take advantage of you in uncommon and unlikely ways".  So he didn't.  And he missed his meeting.  He won at life.

Now admit that the above scenario would never actually happen as we are brave, curious, and sometimes an incurably idiotic species and consider the true outcome of the story above where he says

"Screw it - I've seen this sign in the past and nothing bad has happened to me.  I'm going to this meeting." and drove to the meeting without a care in the world.

The same is true when presenting a victim with a fake SSL certificate.  MOST ARE GOING TO ACCEPT IT, whether your choose to believe it or not.  In fact, we have calculated a 90% acceptance rate of SILICA's fake SSL certificates (that are generated on-the-fly to appear as legitimate as possible) coming from the domains that are being impersonated.

The truth is that passwords just completely flood into SILICA now from all targeted protocols as if it's a new popular trend. In fact it's borderline ridiculous.  Phones are the worst.  Like a well-trained dog your phone is eager to log in and fetch your daily life and place it at your feet.  This is good for convenience but bad for security.  As soon as an attacker becomes the access point to which your phone automatically connects the attacker almost immediately harvests web site passwords, social networking application passwords and email service passwords.  The following is a screenshot of SILICA stealing passwords (out from under SSL-enabled protocols).

Facebook, Twitter, Hotmail and Gmail account passwords intercepted in SSL traffic during a controlled phishing attacked using SILICA.

Here is a practical example of an attack - you open your iPad and you want to check your Gmail account.  So you open your email client like normal but this time you are presented with a popup message that looks like this:

90% of people will click "Continue" to get what they came for and give SILICA the passwords.

If you click "Continue" (which 90% of you will) then SILICA gets the username and password of your  Gmail account.  This is why it doesn't matter if someone clicks "Cancel" - because 90% of the victims have already given up the goods.

SILICA, Two-factor Authentication and Twitter Account Takeover

Phishing is a very effective method of stealing passwords as humans are typically the easiest service to enumerate them from.  I wrote a small extension to SILICA's phishing engine that demonstrates how to successfully take over a Twitter account even when two-factor authentication is enabled.  Hopefully this will help remove the false sense of security from your minds this is the magic solution to prevent account takeovers.

The victim user in this case will log into Twitter as normal, receive an SMS on the phone associated with the account with the legitimate token and unknowingly give them both to SILICA that will be displayed in the interface like so:

Using SILICA to successfully phish for a legitimate Twitter two-factor authentication token.

It's that easy.  Two-factor authentication just adds one more step to the entire phishing process.  Keep in mind that two-factor authentication is only meant to mitigate authentication attacks where the attacker has access to the password but not the token - it does nothing to protect the session after successful authentication has already taken place.  The new features of SILICA have the capability of taking advantage of both of these scenarios (as an example).  If it can work on Twitter then it can work on the applications that you encounter during your penetration tests.

Also keep in mind that two-factor authentication will not prevent attackers from taking over your account if they are already on your machine, in your browser or on your network.

Conclusion

In reality the Internet does not run on protocols that were built with security in mind.  Security is usually an afterthought after someone takes advantage and a band-aid is needed.  The protocols that you use to get your web traffic and mail are no different.

And what's worse - the protocols that attempt to secure you are still at your mercy - you are given the choice to [sometimes unknowingly] disable all security mechanisms with an innocent looking popup message that just asks you to "Continue" or with an annoying browser warning that says "blah blah maybe you shouldn't click ok blah blah blah NOW CLICK OK TO GET WHAT YOU CAME FOR".

Author

Mark Wuergler

You can bother him here: @MarkWuergler

Jinx Part 2: nginx CVE-2013-2028

Who doesn't love vulnerabilities in web servers? We've written nginx bugs before and it was a lot of fun. Now Immunity is pleased to release to its CEU customers the 64 bit version of CVE-2013-2028 written up by a new member of the Linux exploit team. Since this is exploit is in recent versions of nginx only and in our experience most modern web servers tend to be 64 bit, we decided to develop against that architecture. This particular exploit is a good example of a modern remote exploit against hard to exploit software. There has been some good analysis of this vulnerability thus far but as Immunity has a working exploit we thought it worthwhile to chime in.

One of the first hurdles to overcome is not knowing a function's location in memory, ASLR has made information leak vulnerabilities very valuable as a result of its widespread implementation. In the absence of an information leak an attacker is left with brute force or another alternative that we'll discuss later. From there it's on to a ROP chain which may be very dependent on the version of libraries available on the system. Complicating all this is the fact that compiling software from scratch on Linux systems is very common, system administrators may pass any number of configuration or compiler options that change things just enough to break exploits that make too many assumptions.

A problem with basing targeting for exploits on pre-compiled binaries that you might get through apt-get or yum is that maintaining a list of targets and offset combinations becomes very cumbersome. And you've got to test against a large cross section of distribution and server version combinations which can be time intensive. When developing the exploit for this vulnerability we decided to make it as universal as possible and find all the memory locations we would need manually. This has the consequence of taking more time to run (5-20 minutes) but the benefit of working out of the box against more environment combinations. You may remember a similar situation with our exploit for Samba's CVE-2012-1182.

With this vulnerability the exploit takes over an nginx worker process (defined in conf/nginx.conf, default 4) and that process will not respond to other normal nginx work while your shell is active so launching a trojan and getting out of the worker if there aren't many will help avoid detection. In talking with the developer who wrote up this exploit another interesting issue presented itself. There is a condition whereby the target is vulnerable but not exploitable. If the stack canary or function addresses we use from libc contain bad bytes then that can cause exploitation to fail. The worker processes inherit their canaries from the parent and therefore killing them won't grant you a new canary and if by some cosmic roll of the dice libc is in a bad location then you're just out of luck. The upshot is that failed exploitation attempts will only kill the worker process and you can try again.

This exploit reuses the socket that established the connection to the web server in the first place. This is very helpful when dealing with hosts that have strict egress filtering, for instance where web servers are not able to initiate outbound connections. So before you upload and execute your trojan to get out of the worker process you'll want to determine what egress filtering (if any) may be in place. If you anticipate strict egress filtering is present then compromising the server during off hours and automating finding an egress part should be part of your game plan. The likelihood of crashing the server or the parent nginx process with this exploit is very low, nor did we observe the case of a worker process getting hung and no longer being available. In our testing we found the exploit to reliably get a shell over 90% of the time. The exploit presents a low risk high reliability method for getting a shell on an nginx webserver.

An Unusual MDaemon Exploit (a.k.a it's not always about shells)

In penetration testing there is an enormous focus on obtaining shells; and rightly so. Having that level of access to a host, regardless of privilege level, is incredibly useful for an attacker and is usually just the start of a full compromise of a host. Getting a shell can be difficult with all the modern memory corruption protections. Maintaining a shell isn't easy either as you have to contend with all manner of IDS, egress filtering, host monitoring and so forth.

Luckily having a shell isn't the only path to victory. MDaemon is a Windows based mail server (owned by BlackBerry) that is an alternative to Microsoft Exchange, it provides much of the same basic functionality but in a simpler to manage package. Using SWARM we were able to determine that while certainly not as popular as Exchange, MDaemon does have a pretty significant presence. It's not just in the commercial space either - there are government servers in various countries using this software as well.

The new CANVAS exploit takes advantage of a patched vulnerability in several versions of MDaemon that allows account takeover. Since there's not a lot of information on this vulnerability publicly available that's where I'll leave it - the curious have a low cost method for satisfying their curiosity. Many of the versions for 12.X and below are vulnerable though we have not been able to confirm how far back it goes. Account takeover allows for a lot of different interesting risks, such as getting passwords to cloud services such as Twitter reset, or social engineering other people in your organization.

We used SWARM to examine the version distribution of MDaemon for over a million IP addresses and I've summarized the results in a table below.

 

Version	Percentage
13.X	12.6%
12.X	21.5%
11.X	20.4%
10.X	21.1%
9.X	17.4%
8.X	2.8%
7.X	2.7%
6.X	1.4%

The results are pretty interesting in a number of respects. Firstly there is a big legacy presence of MDaemon and given some of the disclosures, especially in the web portion, there are many paths to victory. Second - there are some users who just seem unable to ever upgrade their MDaemon. The rough right leaning bell curve shape of the versions is common to almost any server that does not auto update.

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