Last updated at Fri, 21 Jul 2017 13:44:46 GMT

A Post-POODLE World

Well, it's another week, and another infosec community panic attack. If you're reading this blog, you're almost certainly the sort of person who already heard about the POODLE attack on SSLv3 from Google, or saw our own Jen Ellis's writeup over on Rapid7's Information Security blog. This week's Metasploit release addresses POODLE in a few ways to make sure that our beloved penetration testers don't get bit by this bug, as well as to ensure that our own exploits and auxiliary modules still function as expected in a post-POODLE networked world.

The Metasploit Web UI

Metasploit Pro, Metasploit Express, and Metasploit Community now only support TLSv1 and later as minimum cipher levels. If you're using a browser that doesn't support TLSv1, well... you probably shouldn't be mucking around with penetration testing software, since you're on a browser and operating system that almost certainly has other remote code execution bugs. It would be a bummer if one of your targets started hacking you back, after all.

Metasploit Modules

Metasploit modules which target services over HTTPS now automatically negotiate TLS/SSL versions by default. This is an important change, because previously, we preferred SSLv3 for targets. Before this week, nearly all web servers -- especially those hosting vulnerable applications -- would accept SSLv3, but may or may not accept TLSv1. In today's post-POODLE world, though, we can't be sure that's the case. This is an improvement to SSL negotiation for attack traffic that's been a long time coming anyway, so thanks to Google for making this announcement! Also, if there is an attack or probe that must use SSLv3 due to legacy enforcements, then module writers can prefer that version specifically. Handy!


Meterpreter sessions now prefer TLSv1, but can fall back to SSLv3 if needed. Like the module change, this is mostly to ensure continued functionality. We're predicting that sites that have deep packet inspection (DPI) devices, such as intrusion prevention systems (IPSes) and protocol-aware firewalls, will likely start blocking SSLv3 as a matter of course to avoid giving away their users' secrets to nosy Internet scoundrels. Therefore, we want to ensure our not-quite-benign traffic can also communicate across these egress-controlled networks. You can see the difference in Meterpreter traffic on OJ @TheColonial Reeve's testing screenshots.

Metasploit RPC

The Metasploit RPC client now prefers TLSv1 over SSLv3, like all normal clients should.

Lessons learned

This flurry of activity is but one example of custom, non-browser, SSL-aware software that needed human intervention to ensure functionality in the face of the death of SSLv3. I doubt we're alone here; I imagine there are hundreds to thousands of similar applications that use the normal SSL APIs common for all operating systems that chose SSLv3 as a then-sensible default, banking on the fact that pretty much anything can talk SSLv3. Thanks to Cloudflare's statistics, we now know that SSL traffic (as opposed to TLS traffic) seems to account for around two percent of all Internet traffic -- and most of that is automated crawlers and malicious traffic. Hey, who's calling Meterpreter malicious? It's merely a remote administration tool... right?

New Modules

Since I somehow managed to skip last week's update blog post, here are the new modules landed in the last couple weeks. Of special note is the Bluetooth Personal Area Networking (BthPan.sys) local privilege elevation exploit from our friends at @KoreLogic. You remember that XP is end of life, right? This means the liklihood of a patch for this vuln is extremely small -- you can bet that this will remain a reliable vector for extending control on XP platforms forever.

Exploit modules

Auxiliary and post modules