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.

4 comments:

  1. This is going to impact any tool which assumes OpenSSL has SSLv2 enabled--including Nikto.

    In it's case, however, testing should go fine as long as the server supports something besides SSLv2 and the two can negotiate some happiness, so I don't see a lot of fallout from it for Nikto. Good to know, though.

    ReplyDelete
  2. Hi I found your blog page earlier in the year and it was a real help, saves me messing around with wine and THCsslcheck. This week I discovered ssl v2 support has disappered again and I went through the steps above but still no joy.

    New distro time I think...

    ReplyDelete
  3. They've moved some stuff around since, and I'm digging through to figure out how to kill it in 1.01 on Ubuntu 12.04 LTS. Not sure if it's a file name change or a type, but the patch is called "no_sslv2.patch", not no-sslv2.patch.

    ReplyDelete
  4. I recently installed 12.04 and found that the above steps no longer work, because debian has actually started to disable sslv2, also. This is the update I sent out to our team:

    Tonight, I installed ubuntu 12.04 on my lovely personal thinkpad, and found a new error with ssl2. This time, we get an actual "-ssl2 unknown option" response. So, I dug around some, and just like last time, I'm apparently the only guy that cares. I tracked it down to upstream Debian, though, which means that all debian-based distros likely have the -ssl2 option removed. Fortunately, this is a pretty easy fix. Follow the steps as above in the blog post, except:

    1. The ubuntu patch at some point was renamed to no-ssl2.patch, so that line should now be:
    sed -i '/no-ssl2.patch/d' debian/patches/series (or just manually edit this file and remove that patch name)

    2. edit the debian/rules file, remove 'no-ssl2' from the CONFARGS variable

    build packages, install packages, connect to old, old web servers with the glorious SSLv2 protocol.

    ReplyDelete