Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Jul 26 '09 at 6:20

This question came from our site for professional and enthusiast programmers.

    
Well, if the logs are true, then it's a configuration issue of exposed services and nothing to do with programming whatsoever. –  blowdart Jul 26 '09 at 6:02

5 Answers 5

up vote 34 down vote accepted

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

share|improve this answer
2  
Require a valid public-key to be able to log in through OpenSSH. Not fool proof, but helps. Good post btw. –  Andrioid Jul 26 '09 at 9:58
    
Good point, added :) –  Andrew H Jul 26 '09 at 10:22
1  
It's worth pointing out that the OpenSSH version string is far from a reliable guide as to whether vunerabilites have been patched, due to various linux versions backporting fixes. Also, none of the bugs here are likely to allow a user to login without some fairly serious other breachers. –  Cian Jul 26 '09 at 17:57

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.

share|improve this answer
    
one suggestion was a white-list? –  pageman Jul 26 '09 at 6:06
    
which is still not a programming issue, it's a configuration issue –  blowdart Jul 26 '09 at 6:11
    
news.ycombinator.com/item?id=723956 –  Sneakyness Jul 26 '09 at 6:11
    
@Sneakyness I'm not a security expert by any means - but thanks for pointing it out - that's I ask these questions, so I can learn - and thanks for attempting to preclude me from writing about something I would like to learn about - whether it's a programming or not a progamming question - I'll leave it to security experts to answer - YOU included (I'm assuming you are one based from your educational comment) –  user14898 Jul 30 '09 at 9:24

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

share|improve this answer
    
Our we sure this was even a zero day? –  Josh Brower Jul 27 '09 at 13:09

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.