Threat Level: green Handler on Duty: Pedro Bueno

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

What's brewing in Danmec's pot?

Published: 2008-07-24
Last Updated: 2008-07-24 17:22:46 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)

Couple of readers wrote in to tell us about various different things they've noticed on their servers. While the attacks are "plain old" SQL injection attacks we've been writing multiple times about (see http://isc.sans.org/diary.html?storyid=4645) the latest development in those attacks definitely looks suspicious. Here's what's going on.

First of all, it appears that the attackers expanded their target list of applications so they try to attack Cold Fusion applications now as well (previously they tried to attack ASP scripts only). If you are running Cold Fusion applications, this should be a wake-up call for you – make sure that you are not vulnerable to SQL injection. If I remember correctly, Cold Fusion does have some built-in protection against SQL injection attacks but there are clearly cases when that does not work (otherwise the attackers would not be attacking it).

The logs to look for look like this:

GET /shared/cfm/image.cfm?id=125959';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C…)

Notice that they changed the CAST()-ed string as well so it's not Unicode any more (works fine with CAST), but I'll get back to that later.

The other attack we got information about actually looked more interesting. The log file submitted by couple of our readers contained the following SQL injection command:

declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A323027 exec(@q) --

This caught our attention since the encoded part was much shorter than previously. Anyway, as this is plain hexadecimal, it's easy to decode this. Just take the part after 0x and pipe it to the following perl command:

$ echo "57414954464F522044454C4159202730303A30303A323027" | perl -pe 's/(..)/chr(hex($1))/ge'
WAITFOR DELAY '00:00:20'


Interesting! So they are issuing the WAITFOR DELAY command. For those of you not into SQL, the WAITFOR DELAY command simply blocks the execution of the command for the period of time specified after the DELAY keyword (20 seconds in this case).

So what does this do? It's actually a very common way that is used by hackers when they are exploiting blind SQL injection attacks. The idea is to create a condition that, if satisfied, will delay the execution of the script for a certain time period. So, the attacker watches the response time and if it was delayed, he knows that the SQL command was executed successfully.

Here we're not talking about the blind SQL injection, but just a way to check if the script is vulnerable to SQL injection in general. So, the bot issues this command and checks the response time: if the reply came immediately (or in couple of seconds, depending on the site/link speed) the site is not vulnerable. If the reply took 20 seconds then the site is vulnerable.

This gives them an easy way to detect vulnerable sites and (probably) create a list of such sites that they might attack directly in the future. And the site owner will not notice anything (unless he/she is checking the logs).

Something big coming? I guess we'll have to wait and see.

Thanks to Justin and Tony for sending reports.

UPDATE

From the information I received from some other security researchers (thanks Josh), it appears that this is not the work of Danmec (the bot) but probably a result of manual attacks, maybe even with the tool I analyzed back in April (see http://isc.sans.org/diary.html?storyid=4294).

In any case, this looks pretty scary as it's almost a book example of reconnaissance - the attacker first enumerates vulnerable sites and then attacks them!


--
Bojan
 

0 comment(s)
Diary Archives