A while ago I experienced a tedious but nice adventure. We were hosting an old CMS web application on our company dedicated servers. Nearly 3000 customers were using that web application to maintain their web sites. A lot of programmers had worked on the application during almost 7 years and the code was never checked for security holes. So let me list it`s vulnerabilities below starting fro the less dangerous to the most dangerous one:
2.sql injection – an attacker could manipulate the database insert, delete records drop entire tables or even drop databases. but a more sophisticated attack can even execute shell commands. The funny thing about hack attacks in general is that they are getting very easy for everyone to do them with the publication of tools like Havij.
3.Local File Inclusion – an attacker can include for execution a local system file because the programmer is not checking the base path of the included file, and the included file path is a variable which the attacker can access Ex: as a request (post/get) parameter. Typically the attacker will modify his browser agent string and will enter php code instead of the browser name. This code then will be logged in the apache log file. After that the attacker will just have to include the apache log file in the vulnerable code and his malicious code will get executed. Peace of cake for a hacker.
4.Remote File Inclusion – an attacker can include for execution a remote file for the same programmer`s fault to check the include file as above. The attacker will google for a hosted c99, c100, rshell, or any other similiar hacker`s tool and will include that url for execution. Tools such as c100 shell allow the attacker total control over your server.
5.Directory traversal – if an attacker has gained access to a hosted website that is vulnerable, by using the dot dot method he can access all your server file system. This vulnerability is most common in remote file manager applications.
6.Direct code execution – an attacker can insert php code directly in get/post variables and execute this code because the programmer is using the eval() instruction and he is not checking for dangerous code.
7.Unchecked file uploads – an attacker can upload a PHP file and execute it by just calling the url of the uploaded filed. The programmer in that case did not check for the file type uploaded, and is giving execution permission to the uploaded file.
Believe it or not our CMS application suffered from all of this vulnerabilities and it was no surprise that one day we had a lot of phone calls from our customers complaining about offensive content being put on their websites and certainly not by them. We looked immediately at the attacked websites. The attackers were putting photos of Gaza Strip kids injured by Israeli bombs and the were also posting messages like “Fuck you admin”,”Where is you security now” etc…
We analyzed the apache log file to get a complete scenario of how they did get in … We found the below suspicious log entries
91.xxx.138.xxx- - [30/May/2010:21:06:57 +0200] "GET /siti/sito_azzifausto/upload/documenti/2139_xxx1989.php HTTP/1.0" 200 5647 91.xxx.138.xxx - - [30/May/2010:21:07:07 +0200] "GET /siti/sito_azzifausto/upload/documenti/2139_xxx1989.php?act=ls&d=%2Fhome%2Fwebs%2Fwww.xxx.it%2Fpmi%2Fsiti%2Fsito_azzifausto%2Fupload&sort=0a HTTP/1.0" 200 5156 91.xxx.138.xxx - - [30/May/2010:21:07:09 +0200] "GET /siti/sito_azzifausto/upload/documenti/2139_xxx1989.php?act=ls&d=%2Fhome%2Fwebs%2Fwww.xxx.it%2Fpmi%2Fsiti%2Fsito_azzifausto&sort=0a HTTP/1.0" 200 5228 91.xxx.138.xxx - - [30/May/2010:21:07:13 +0200] "GET /siti/sito_azzifausto/upload/documenti/2139_xxx1989.php?act=ls&d=%2Fhome%2Fwebs%2Fwww.xxx.it%2Fpmi%2Fsiti%2Fsito_azzifausto%2Fgrafica&sort=0a HTTP/1.0" 200 5867
Apparently the attackers had uploaded 2139_xxx1989.php which was just c100 shell renamed. They had used an unchecked file upload vulnerability in the CMS`s remote file explorer application.
We had to repair all the vulnerabilities immediately and the investigate further. The attacks were increasing every moment. It was a total disaster. We took those steps to take control of the situation:
1.we blocked all the attacking IP addresses
2.we deleted all the uploaded php shells
3.we automatically changed all usernames and passwords and we automatically emailed them to our customers.
4.we fixed all the vulnerabilities we had in the CMS application PHP code
Than it was time for further investigation…
I launch my favorite tool Nmap. I start a scan on the first attacker IP. It came out that he was not using any proxy.
Nmap finishes the scan quickly…mmm. The attacked is running Windows xp, and port 3306 is Open. He is running MySql locally…
I open Navicat lite, which is my preferred database administration tool and i try to access the attacker MySql with root for the username and blank as password…Surprise surprise I`m in
I browse the databases list and i find a database that is used by phpMyBB a popular opensource forum application. I see, he is testing it locally…After looking at the users table i find two registered test users but they actually had real emails
What can i do with them..? mmm let`s try to send those guys a nice hello email. After two hours one of them replies me:
Scusa ma chi sei..?
Nice guy eh..? He used his personal email address with his real name and surname . I immediately enter his name in the Facebook search and here is simpler than ever a nice picture of our attacker…
I save his profile picture, the police will find it useful. I take a last look at his wall activity…This guy posted every page he hacked on his wall So courageous so stupid.
So thanks Facebook for being an addiction to anyone…