Rules for DNS Kaminsky

Rules for detecting Kaminsky DNS

Can you elaborate more on your request?

I’m in need of a rule that detects Kaminsky attack on IDS suricata.
Kaminsky DNS cache poisoning
Kaminsky cache poisoning was discovered in 2008. As an off-path attack that can be launched continuously, it has attracted widespread attention from academics over the last decade and still remains a major topic. Unlike MitM attacks, an off-path attack can be launched almost anytime, anywhere. But if the attacking target record exists in resolvers’ cache, the attacker cannot trigger the resolver to send external queries through normal queries, thereby cannot poison the cache by forging a response message. Thus, in practice, it is difficult to attack the records in cache directly. Kaminsky cache poisoning solves this problem by enabling the attack to be continuously launched, significantly increasing the success probability of poisoning and reducing attack cost.
1)The attacker sends a query to the target resolver for randomly generated name in the format {random}.foo.com where {random} denotes a random value;
2)The resolver sends a query to an authoritative server as there is a small chance that the random-prefixed name exists in cache;
3)Prior to the authoritative server’s response, the attacker floods the resolver with responses containing the NS record of foo.com associated with a forged glue record. If the challenge words such as TXID in the response match those in the query, the records will be accepted and cached by the resolver;
4)When the A record of www.foo.com in cache expires, the resolver sends an external query to the fake authoritative server referred by the spoofed glue record;

5)The fake authoritative server responds with an A record of www.foo.com which points the domain to a malicious web site controlled by the attacker;
6)Users query for the IP address of domain name when accessing the web site www.foo.com;
7)The resolver answers with the A record of www.foo.com in cache. From this point forward, traffic will be redirected to the attacker’s web server whenever the users visit www.foo.com.

ZHANG, H. et al. Study on the latent state of Kaminsky-style DNS cache poisoning: Modeling and empirical analysis. Computers and Security, v. 110, p. 102445, 2021.

With the ports and query IDs being randomized it’s become almost impossible to accomplish this technique. Of course this may depend on the resolvers settings. I think it may depend on where the sensor is and what it can see. Also, is there a specific domain that’s needed to be protected or trying to detect this attack on any domain.

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

I have some ideas but it will probably depend on where the sensor is.

We will use a HOST IDS that will be together with the DNS server.

If there are specific domains that you are looking to detect against I think you would develop a list of subdomains that belong to each domain and place those in a datasets and use the dns.query sticky buffer to match against the dataset. You would need to negate the dataset so it would only match against requests not in the dataset. You’ll probably still want to match against the domain in question and then try and match subdomains. It may require using flowbits/xbits and multiple signatures, otherwise any request will generate an alert.

If you are trying to detect any domain then it can be more difficult. You can look for request that have a subdomain and then use thresholding to trigger an alert once there have been enough request from a source within a particular time period. You can also use pcre to try and detect randomly generated subdomains along with thresholds.