Home / server / Questions / 37208
Accepted
sucuri
Asked: 2009-07-08 09:47:58 +0800 CST

SSH server zero-day exploit - Suggestions to protect ourselves

  • 772

According to the Internet Storm Center, there seems to be a SSH zero-day exploit out there.

There is some proof of concept code in here and some reference:

This seems to be a serious issue, so every Linux/Unix system administrator should be careful.

How do we protect ourselves if this issue is not patched on time? Or how do you handle zero-day exploits in general?

*I will post my suggestion in the replies.

linux exploit security ssh hacking

9 Answers

  1. My suggestion is to block SSH access on the firewall to everyone else besides your ip. On iptables:

    /sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP
    • 11
  2. Best Answer

    Comment from Damien Miller (OpenSSH developer): http://lwn.net/Articles/340483/

    In particular, I spent some time analysing a packet trace that he provided, but it seems to consist of simple brute-force attacks.

    So, I'm not pursuaded that an 0day exists at all. The only evidence so far are some anonymous rumours and unverifiable intrusion transcripts.

    • 7

  3. According so the SANS post, this exploit does not work against current versions of SSH, and thus isn't really a 0day. Patch your servers, and you should be fine.

    • 5

  4. Complain to your vendors

    That way everybody gets the newer version.

    • 3

  5. I don't run ssh on port 22. Since I often login from different machines, I don't like preventing access via iptables.

    This is good protection against zero-day attacks - which surely will go after the default configuration. It's less effective against someone who is trying to compromise just my server. A port scan will show which port I'm running ssh on, but a script attacking random SSH ports will skip over my hosts.

    To change your port, simply add/modify the Port in your /etc/ssh/sshd_config file.

    • 3

  6. FYI, the original source of the story: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

    There are also two similar stories (hacking astalavista.com and another site): romeo.copyandpaste.info/txt/astalavista.txt
    romeo.copyandpaste.info/txt/nowayout.txt

    It seems like someone has an agenda: romeo.copyandpaste.info/ ("Keep 0days private")

    • 3

  7. I would firewall and wait. My gut instinct is one of two things:

    A> Hoax. By the little and miss-information given so far, it is either this..

    or...

    B> This a "smoke and deception" attempt, to cause concern over 4.3. Why? What if you, some hacker organisation, find a really cool zero-day exploit in sshd 5.2.

    Too bad only cutting edge releases (Fedora) incorporate this version. No substantial entities use this in production. Plenty use RHEL/CentOS. Big targets. It's well known RHEL / CentOS backport all of their security fixes to retain some sort of basic version control. The teams behind this are not to be sneezed at. RHEL has posted (I read, would have to dig up the link) that they have exhausted all attempts to find any flaw in 4.3. Words to no be taken lightly.

    So, back to idea. A hacker decide to somehow cause a stir about 4.3, causing mass hysteria to UG to 5.2p1. I ask: how many of you have already?

    To create some "proof" for missdirection, all "said group" would have to do now is take over some previously compromised system (WHMCS? Previous SSH?), create some logs with some half-truths (attack-ee verified "something" happened, yet some things unverifiable by target) hoping someone would "bite". All it takes is one larger entity to do something drastic (...HostGator...) to make it a bit more serious, amidst the growing anxed and confusion.

    Many large entities may backport, but some may just upgrade. Those that upgrade, now open to the real zero-day attack with no disclosure as of yet.

    I've seen stranger things happen. Like, a bunch of celebrities dying all in a row...

    • 2

  8. I compile SSH to use tcprules, and have a small number of allow rules, denying all others.

    This also ensures that password attempts are very nearly eliminated, and that when I am sent reports about breakin attempts, I can take them seriously.

    • 1

  9. Switch to Telnet? :)

    Joking aside, if you have your firewall properly configured it is already only allowing SSH access to a few hosts. So your are safe.

    A quick fix might be to install SSH from the source ( downloading it from openssh.org ), instead of using old versions that are present on the latest Linux distributions.

    • 0