My next class:

OpenSSH 0day FUD

Published: 2009-07-09. Last Updated: 2009-07-09 08:40:37 UTC
by Bojan Zdrnja (Version: 1)
6 comment(s)

For the last couple of days we've been all witnesses of FUD surrounding a supposed 0-day exploit for OpenSSH skyrocketing.

At this moment, it definitely looks like we're dealing with a hoax – even more, it's not the first time someone said they have a 0-day exploit for SSH. So, let's see some facts about this.

It appears that the whole story started after a post to the Full-Disclosure mailing list on the 4th of July (http://seclists.org/fulldisclosure/2009/Jul/0028.html). The post supposedly shows a hacker group using a 0-day exploit for SSH to compromise a server. After doing some research here, it appears that this is a long standing argument between two guys (or groups). One of our readers submitted the following URL address (http://flx.me/astahack2.txt), which shows another hack.

The "exploit" used in that file is a brute force attack for sure, as can be seen below:

anti-sec:~/pwn/xpl# ./openPWN -h 66.96.220.213 -p 2222 -l=users.txt

See the "-l" option? That supplies the list of users it will try to brute force.
Additionally, a bit below it even prints which user was hacked:

       [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]

       user: crownvip
       uname: Linux srv01.webhostline.com
2.6.21.5-hostnoc-3.1.7-libata-grsec-32 #1 SMP Mon Feb 11 06:36:58 EST 2008 i686 i686 i386 GNU/Linux


Now, what has been posted on the Full-Disclosure list (the supposed
exploit) looked like this:

anti-sec:~/pwn/xpl# ./0pen0wn -h xx.yy.143.133 -p 22

Same group, same server, same directory – different file name. Why didn't they use the mighty 0-day first time? They brute forced into the server and then had to jail break.
This looks very much like a hoax to me – and this is the only evidence we have about a 0-day? A post from an anonymous e-mail address (hushmail) to the Full-Disclosure mailing list (which, we all have to admit, isn't the best source of verified information)? And this was even enough for some web hosting companies to *shut down* their SSH service? I find this unbelievable.

Finally, OpenSSH developers would probably agree with me – one of the developers sent an e-mail to the Openssh-unix-dev mailing list (http://lwn.net/Articles/340483/) also stating the obvious.

So, I'd like to ask everyone not to spread the FUD anymore. Every piece of evidence we received so far points only to brute force attacks on SSH servers (which have been around for years!). Do keep an eye on your server and install all patches. We will post more information if we receive it, but until then I think there was enough of this FUD.

--
Bojan

 

Keywords: exploit fud openssh
6 comment(s)
My next class:

Comments

Although this all seems to have been another in a series of hoaxes for SSH, there are steps that you can take to prevent brute force type attacks on SSH Servers. After testing a few, I found that DenyHosts to be one of the most effective ways of preventing this.

If this is of interest to you, check out the DenyHosts website at:

http://denyhosts.sourceforge.net/

Ollie
I use DenyHosts as well. It works very well for my application.
Use a port-knocking system, its the big aspirin for such a headache :)
Just a suggestion, but I normally don't have a good reason why I can't lock down SSH on the hardware firewall level to come only from authorized IP addresses.

Another idea is to lockdown all your webserver SSH to only come from workstation "A", which is on a totally different network and ISP. Put Denyhosts on "A" and run no webservices on it, use it at a SSH relay station.

It would certainly keep someone from doing a bruteforce SSH to www.yourhost.com
It does sound like OpenSSH has a vulnerability here:

"... this was even enough for some web hosting companies to *shut down* their SSH service ..."

Someone perpetrated a successful DDoS attack against OpenSSH servers.

Of course, the vulnerability was in the operators, not the software. The technique used was social engineering. It's hard to patch OpenSSH against that.
I suggest using OSSEC, with hosts.deny or iptables active response. SSH is just one possible service that a brute force attack can be attempted against.

Other examples [for some systems] are FTP, POP3, Telnet, or someone with a login repeatedly attempting to 'SU' with various passwords.

Diary Archives