A member of the ‘NULL’ mailing-list today announced a ‘Persistent XSS’ vulnerability in the ‘subject’ parameter of RediffMail’s email application.
This Vulnerability was discovered and reported by w4rl0ck.d0wn and Rockey Killer of h4ck3r crew
Check out their PoC video at:
Posts Tagged ‘0-day’
I know this is ‘old’ news, but I was a bit busy so could not post it here.
ZF05 has been released to stands where the ‘hackers hack the hackers‘ …hehe
Pretty interesting stuff. Make sure to read the hackers comments embedded in between the text – which by the way is pretty huge !!
Check it out at http://r00tsecurity.org/files/zf05.txt
Here’s a snippet of what to expect
- Kevin Mitnick
- Dan Kaminsky
- Hacking in gitmo
- Binary Revolution
-….and many more
I know this blog is turning out to be a propaganda machine for the anti-sec guys, but let me assure you there’s no such thing going on here. It’s just that their antics are generating more interest day-by-day.
Well, now they are rumored to have released (or was it leaked ??) the OpenSSH 0-day ( Open0wn.c )that helped them exploit vulnerable systems on the internet.
Thierry Zoller has disassembled the shellcode to find the that it is actually a hex-coded IRC-bot and the linux command ” rm -rf ~ /* 2> /dev/null “
They seem to have taken their movements to new heights. If this 0-day was really released by the Anti-sec movement, then I’m sure their target were unsuspecting script-kiddies who simply download exploits from the internet and run them against vulnerable systems.
Thierry has done a good job too. Check out his analysis here
For details check out the following links:
Shellcode Disassemly + IRC code –> Thierry Zoller’s analysis
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 !!