Funny title. I've now been awake for 44 of the last 48 hours securing, studying, and rebuilding a multiuser public access linux system that got compromised (fully up to date Debian etch). I think I'll go to sleep instead of reading the article though.
From my stored packet and logfile analysis it went about like this:
1. POP/IMAP password driller guesses defunct account password. (Darn Canadians.)
2. 7 minutes after SSHing in, root is compromised.
3. They create a new account with uid=0, how quaint.
4. A trojan /usr/bin/ssh is installed.
5. A couple more accounts have their passwords guessed (probably from a copy of /etc/shadow)
6. The nightly backups failed, catching my attention.
Now I need to take a long think about how to detect and halt this sooner. It was mostly luck that his trojan ssh had a regression bug that tripped on my configuration files.
I rebuilt the machine as a virtual machine inside its physical hardware. I'll see what I can do scanning traffic and manipulating the firewalls of the outer machine. I have high hopes.
Headlines are written to draw attention, but this one is just so wrong I wonder if the writer of it felt the least bit unclean.
The final quote sums it up: "[...] some had found bugs in the Linux operating system but many of them didn't want to put the work into developing the exploit code that would be required to win the contest."
So all three machines had bugs that made them compromisable, yet no one actually WANTED to win by making linux look bad?
Most of the time in contests like these, the participants already know of the vulnerabilities in the OS that they can take advantage of. They work out the exploit code before the competition, which is why the MBA was able to go down in the first couple minutes of that round; the guy already knew what he was going to do. OSS is generally more secure not because it doesn't have vulnerabilities, but because known vulnerabilities are patched up more quickly. It's not about making linux look bad, it's about having to try to generate working code on the spot rather than being able to analyze and test it prior to the event.
From my stored packet and logfile analysis it went about like this:
Now I need to take a long think about how to detect and halt this sooner. It was mostly luck that his trojan ssh had a regression bug that tripped on my configuration files.I rebuilt the machine as a virtual machine inside its physical hardware. I'll see what I can do scanning traffic and manipulating the firewalls of the outer machine. I have high hopes.