Thursday, February 10, 2011

When Distros (Sneak) Attack

I was re-testing a list of findings from a prior engagement yesterday and eventually worked my way down to the "SSLv2" enabled list. These are pretty much the universal findings, since seemingly few people disable SSLv2 or weak ciphers when standing up a web server. Also, applying the recommended registry fix in Windows isn't always executed to perfection, so SSLv2 tends to linger.

For quick checks like this, I use OpenSSL from the command line:

steve@swt-work:~$ openssl s_client -ssl2 -host some.ssl.host -port 443


If you get a bunch of certificate information back, the site supports SSLv2. If you get an error, it doesn't. Simple, right? Maybe not. I got errors on the first seven or so sites, and that got my spidey sense tingling. Maybe they actually removed SSLv2 successfully on all these systems, but I remain suspicious. So, I tracked down some hosts known to use SSLv2 and all of them reported the same error.

19669:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:


It didn't seem to be an issue with OpenSSL itself, because connections to SSLv3 sites worked as expected. After a few moments of troubleshooting, I turned to Google. No definitive answer was forthcoming, but I did come across a mail list post that indicated that Ubuntu entirely removed SSLv2 from OpenSSL. I jumped onto another Linux distribution and did some parallel testing. OpenSSL in Ubuntu does not support SSLv2, and "null ssl method" is the only message you get. We reviewed the changelog and verified the change.

openssl (0.9.8o-1ubuntu3) maverick; urgency=low

* debian/patches/no-sslv2.patch: disable SSLv2 to match NSS and GnuTLS.
The protocol is unsafe and extremely deprecated. (Debian bug 589706)

-- Kees Cook Tue, 20 Jul 2010 08:24:13 -0700


At this point, I was upset with Ubuntu for wasting my time, and fired off a tweet to that effect. Since I had another distribution available, I moved on with my auditing from there.

Then one of my co-workers wondered if Nessus SSLv2 scans worked on Ubuntu hosts. After some brief testing on other distributions, lo and behold, Nessus plugin 20007 (SSLv2 Enabled) does not recognize SSLv2-enabled servers. Anyone that has been using Nessus on Ubuntu 10.10 since July 2010 for scanning has been unable to detect SSLv2-enabled servers. That's an issue.

I took to the Nessus discussion forums for some guidance, since those guys are so quick to respond. It took all of 20 minutes for Renaud Deraison to reply:
I really like when vendors think they know better -- if a program wants to use SSLv2 they should not get in the way and decide it's bad, without looking at the context.

This probably means that in the not-so-long term, Nessus will ship with its own version of OpenSSL (as we do on Windows and in the "generic" builds).

So, the good news was that Tenable was planning to work around this distro nannyism by shipping their own SSL. The bad news was that we needed a fix in the interim, or our Nessus scans would be suspect.

I then noticed that Kees Cook came across my tweet and responded. After a brief exchange about the removal of SSLv2, he posted a step-by-step guide to reversing the no-ssl2 patch.

$ sudo apt-get install build-essential devscripts
...
$ sudo apt-get build-dep openssl
...
$ apt-get source openssl
$ cd openssl-*
$ quilt pop -a
...
$ sed -i '/no-sslv2.patch/d' debian/patches/series
$ quilt push -a
...
$ dch -n 'Allow dangerous v2 protocol'
$ debuild -uc -us
...
$ ls ../*ssl*.deb


Most of the instructions were familiar, but I hadn't used 'quilt' before. In this case, 'quilt pop -a' removes all patches, and the 'quilt push -a' adds all the patches in debian/patches/series once the "no-sslv2.patch" entry has been deleted. Then the debs are built and easily installed using the 'dpkg -i' command.

Nessus and the openssl s_client were once again able to connect using SSLv2 with the custom debs installed. I reported this back to the Nessus discussion forum thread, and Renaud once again responded with lightning speed.
Nessus 4.4.1 for Ubuntu 10.10 will ship with its own OpenSSL 0.9.8r. ETA is "very soon". Your solution is fine in the meantime, but it's a hack. In the long term, as distributions start to decide they know best about their users needs, we'll probably start shipping OpenSSL with more and more builds
So, in the long run, this will not be an issue for Nessus users on Ubuntu. In the short term, there is a workaround, but system updates will require extra attention, as OpenSSL needs to be rebuilt after every update.