You've surely heard about the DNS Cache Poisoning Flaws disclosed today. Metasploit has a working module to exploit this, here come the kiddies!!
I didn't think we were going to be able to do this in regular syntax, but the collaboration of many very sharp people brought out a better solution. Rather than tracking QIDs and ports over many requests looking for brute forcing we believe by looking for excessive amounts of dns response packets with:
1. One or more answer included
2. AND one or more additional record
The reason being is that this vulnerability gets the attacker an advantage ONLY when they are able to get a response in to the resolver before the real response, and that response includes an ADDITIONAL record. That additional record wil be automatically trusted by the resolver and added to the cache. So the attacker would make the client do many lookups for bogus555.google.com, and try to beat google with a response, but it's additional record would be for www.google.com. That resolver will assume the additional record is correct since the QID matches it's request, and add the incorrect information to it's local cache thus serving up a bad lookup for as long as the TTL is on the bogus record.
More than 100 from the same source in 10 seconds is a huge deal. I can't imagine a legitimate situation where that could happen, and an attacker is going to have to send many more responses than that for a long time to get a good match. The short time period should keep the tracking load on Snort under control. So here's what has been forged to date:
http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/
This is live in the ruleset now. Please test and report and issues ASAP!!!
With metasploit having a module out that works to exploit this we're going to see a LOT of these attacks, as in it's already started!
Matt
| < Prev | Next > |
|---|
