DNS cache poisoning vulnerability details confirmed
A couple of the handlers tuned into the Blackhat "webinar" today. The topic was Kaminsky's DNS vulnerability. Here are some quick notes...
Dan Kaminsky confirmed the details about the vulnerability. I think he was wanting to save the details until Blackhat, but since it got leaked and exploits have shown up in the last 24 hours, there doesn't seem to be much use in delaying any longer. Dan seemed to confirm that the leaked blog entry and the latest Metasploit module have identified the vulnerability correctly.
In Kaminsky's tests, he was able to poison a nameserver cache in about 5-10 seconds. This bug allows the attacker to overwrite entries that are already in the cache.
Nameservers that are authoritative only are not vulnerable. But setting a high TTL for your hosts which you are authoritative won't help vulnerable resolvers from being poisoned. This attack bypasses the TTL protections on vulnerable resolvers.
DNS client libraries (workstations and servers that resolve to upstream nameservers) need to be patched also. The attacks still work against single unpatched hosts - but the priority should be your resolving nameservers.
Home firewall NAT devices are also proving to be vulnerable as many don't seem to randomize the source port.
If I heard correctly, Joao Damas from ISC (Internet Systems Consortium, maintainers of BIND) reports that he has seen attacks already in the wild for this vulnerability.
UPDATE
There is a tool from our friends at Onzra that appears able to detect cache poisoning attacks: http://www.onzra.com/
"CacheAudit is an open source aplication for monitoring the cache of a Recursive DNS server. It allows providers to detect and respond quickly to Cache Poisoning events."
It's still beta so take it with a grain of salt but it's definitely worth a look.
Mozilla releases Thunderbrid 2.0.0.16, fixes security vulnerabilities
Mozilla yesterday released a new version of Thunderbird, 2.0.0.16, which fixes couple of security vulnerabilities, some of them even allowing remote code execution.
Full list of fixed vulnerabilities is available at http://www.mozilla.org/security/known-vulnerabilities/thunderbird20.html#thunderbird2.0.0.16
If you are running Thunderbird, make sure that you patched it.
What's brewing in Danmec's pot?
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
Comments