Date: Mon, 4 Aug 2008 18:22:46 -0400 From: Robert Edmonds To: dns-operations Subject: [dns-operations] release of ISC SIE cache poisoning attempt detection tool hi, ISC SIE has developed a tool for detecting cache poisoning attempts. it consists of two parts: ncaptool, the part which performs packet gathering, reassembly, and dns filtering; and mod_urstate, a message processing module which attempts to statefully detect unsolicited responses that may be indicative of cache poisoning attempts. specifically, the tool is designed to listen at the network layer of a recursive dns server, auditing the query-response stream between recursive and authoritative dns servers. when a potential cache poisoning attempt is detected, both the offending and original dns responses will be emitted into the output stream. ncaptool and mod_urstate may be obtained via ftp:

ftp://ftp.isc.org/isc/ncap/

the defaults are tuned for a dedicated IDS-style setup; e.g. fairly fast machines with >= 1 GB of memory and aggregated taps of dns traffic between recursive and authoritative nameservers. it ought to be possible to run it directly on a machine running a recursive nameserver, however. we would like people to use it, and if possible provide feed back or contribute the data it generates to SIE. mod_urstate is an ncaptool dns message parsing plugin that attempts to detect unsolicited dns responses that may be indicative of cache poisoning attempts. it does this by statefully tracking the application layer state of the dns transactions between recursive and authoritative dns servers. it gracefully handles query retransmissions due to client timeouts and byte identical responses from dns authorities. two data collections are employed by mod_urstate:

1. a fifo cache of the query / response payloads generated by dns transactions. a hard limit on the number of entries in this cache will be enforced to bound memory consumption. the default limit of 1048576 entries tends to consume around 700 MB of memory. the larger this cache is, the more accurate the output will be. as a rule of thumb, the cache should be large enough to hold at least 5 to 30 seconds or so of the most recent dns transactions.
2. an associative array for locating entries in the cache based on a tuple of fields from the packet headers and payload.

when a query for a previously unknown tuple arrives, the query payload is cached so that subsequent byte identical queries may be discarded. when the first response for this query arrives, its payload is also cached. the vast majority of dns queries will only elicit a single response, so most cache entries will be quietly expired in fifo order. however, in the usual case that a domain name's authoritative nameservers are reachable and functioning, a potentially successful cache poisoning attempt has these properties:

• the malicious response payload differs in some way from legitimate response payloads.
• the malicious response matches the tuple for an outstanding query.
• the malicious response arrives at approximately the same time as a legitimate response.

(it should be noted that certain types of benign dns responses unfortunately also match these criteria. it will be possible to filter these out in the post-processing / analysis phase.) the mod_urstate module will output dns responses matching the above criteria. this output can then be analyzed to help answer the following questions:

• was an attempt made to introduce malicious data into my cache?
• did the attempt succeed? i.e., did the malicious response arrive prior to the legitimate response?
• what are the contents of the malicious dns response? e.g., in the most common scenario, where is the attacker's doppelgaenger located?

it should be noted that an out of band method of distinguishing malicious from legitimate responses will be needed by the analyst. -- Robert Edmonds