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.

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.
–
CianJul 26 '09 at 17:57

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

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.

@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)
–
user14898Jul 30 '09 at 9:24

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

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.