This incident came about when some concerned web site administrators noticed a high load on their email system. Thousands of messages had been inserted into the delivery queue within a matter of minutes. By extracting one of the queue files and examining it, we learned that they were phishing emails. Someone had compromised the web server and used it's local MTA (sendmail) to initiate the flood.

This particular web server ran a shared environment, so there were many virtual sites to possibly attack. One of the email headers made investigating this a little easier, because it contained the name of the malicious PHP script. In addition, it showed which source IP address had connected to the web server in order to make the POST request which launched the emails:

X-PHP-Script: censored.org/catalog/images/x.php for 172.173.29.234

Now we know some good criteria for searching through access logs - a script name and a source IP.

# grep x.php * | head -n 1
censored.org.1145232000:172.173.29.234 - - \
[17/Apr/2006:12:13:47 -0700] "GET /catalog/images/x.php HTTP/1.1" \
200 3323 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; \
SV1; .NET CLR 1.1.4322)"

So the first access was 12:13 on the 17th of April. Its probably safe to assume 172.173.29.234 has been compromised and the attackers are using it as a proxy. The next search was to locate the very first hit to the web server from this particular client.

# grep 172.173.29.234 * | head -n 1
172.173.29.234 - - [17/Apr/2006:12:11:40 -0700] "GET \
/admin/backup.php?selected_box=tools&osCAdminID= \
7a8678183c38056670a9740c69cab2f6 HTTP/1.1" 200 11277 \
"http://www.altavista.com/web/results?itag=ody&q= \
osCommerce+Tools+Reports+Customers+Modules+Configuration\
&kgs=0&kls=0&stq=580" "Mozilla/4.0 (compatible; MSIE 6.0; \
Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

This is just minutes before the first hit to x.php and it is accessing /admin/backup.php - a page it found as a result of searching for "osCommerce Tools Reports Customers Modules Configuration" on the altavista.com search engine. This technique is known as "Google Hacking" - although in this case the Google search engine wasn't used. Basically attackers find a vulnerability in some software. Then they take basic strings found on those pages and enter them into a search engine in order to find thousands of others. Search engines in this case are just huge databases of exploitable servers.

After executing the above query and obtaining the results, it was hardly a challenge to compromise the web server in question. The attacker(s) simply browsed from the backup page to the file_manager.php location and uploaded x.php. On this occassion, the vulnerability is not a software coding flaw, it is a simple configuration error. osCommerce comes with the ability to password protect the admin area of the product, however a large number of administrators choose to not implement the security...and leave it wide open.

Johnny's (Google Hacking Database) contains the most comprehensive list of queries for locating exploitable servers and poor configurations.