Update 1: 15th July, 2009 – Anti-Sec has struck again. It seems they’ve launched a campaign against Full-Disclosure ! Imageshack.us was the latest victim. This time too they have kept the logs, which shows a vulnerability in lighthttpd
Astalavista.com, the ‘Hacking Security Community’ was recently 0wned, literally, by an underground hacker group Anti-Sec. The interesting thing about this attack was that the hackers posted their entire ‘attack log’ online. Leaving out some crucial details (like the 0day which they used to initiate the attack) they demonstrated the inherent weakness of the human mind. Though the attack was personally motivated, it serves as a good learning ground for beginners in the security field…what and where mistakes may occur.
For reference purposes, I’ve added the entire attack log of the Astalavista.com attack here.
So what are the lessons learned from this real-world example
1) You’re never safe from 0-day exploits. Even though it seems that the guys had patched their systems, the anti-sec people were able to launch a script and exploit their ‘LightSpeed’ web server to obtain a shell.
The contents of the script have not been disclosed and it’s speculated that the issue was certainly with LightSpeed which is based on the Apache software.
Interestingly, the shell returned had the ‘apache’ user privileges which allowed the attackers to read almost any file on the system. Note that the user ‘apache’ is not given a default ‘shell’ (check /bin/false), but I believe the ‘g0tshell’ had a shell payload.
2) The owners at Astalavista ‘did’ have some sort of password complexity for much of the users. But the issue lies elsewhere. The attackers were able to obtain plain-text passwords to FTP servers and DBs via configuration files and backup scripts
3) Encrypt your passwords before storing it in the databases. As can be seen in the logs, the users of the database did not encrypt their passwords before storing their passwords there. This requires proper configuration at the database application end.
4) DON’T type passwords onto the command line. The attackers were able to obtain a password to a MySQL database by listing the .bash_history . This file contains all commands typed into the bash prompt after every session (the current session is stored in the RAM). So it becomes necessary to avoid typing passwords into the command prompt. Rather, the server should throw back a password request where the user should type his password. Else expect yourself to be owned by any Tom, Dick and Harry who can view the .bash_history file.
5) Following to the previous point, it is prudent to regularly ( maybe after each session) clear your .bash_history file. Check here for pointers.
6) Anything else ??….right now I’m just able to recollect these points from memory. I might update this later I anything new comes up.
Update 2: 22nd November, 2010: Remaining section of post removed
I hope it is understood that I do not condone such hacking activities. This post was just for educational purposes. As can be seen, we did learn a lot !!