Detect DNS answers that were manipulated for privacy

[AlyaGomaa]

Created by Sebastian Garcia via monday.com integration. 🎉

[eldraco]

In develop  Slips. Version 1.0.3 (ceddfcda) 

It seems that some DNS servers (maybe privacy-preserving DNS server) or maybe some adblockers like pihole?, change the IP address in some DNS queries to 0.0.0.0 or maybe 127.0.0.1  First we need to detect these as non-malicious evidence Second we need to AVOID generating the alert "DNS resolution without connection" in these cases, since there will never be a connection.  Example flows  output/aa/zeek_files/dns.log:{"ts":1576516553.774394,"uid":"CNU66O1GgSALsLLMva","id.orig_h":"192.168.254.181","id.orig_p":42497,"id.resp_h":"172.16.1.2","id.resp_p":53,"proto":"udp","trans_id":35437,"rtt":0.00043201446533203125,"query":"ad.doubleclick.net","qclass":1,"qclass_name":"C_INTERNET","qtype":1,"qtype_name":"A","rcode":0,"rcode_name":"NOERROR","AA":true,"TC":false,"RD":true,"RA":true,"Z":0,"answers":["0.0.0.0"],"TTLs":[2.0],"rejected":false}

[ganesh-dagadi]

Greetings! I would like to work on this issue. After reading about the architecture and going through some code, this is what I understood

1. Slips uses zeek or other formats to capture the packets.
2. This data is then converted to a common format and detection is performed using a module.

Here for this issue, Threat Intelligence Module is applied as it deals with Domainsthat include DNS requests, DNS replies, HTTP hostnames, and TLS SNI. IPs include source and destination IPs, both IPv4 and IPv6.

After reading through the Matching of Domains section of Threat Intelligence module, I find that the blacklisted domains are downloaded from sources in the config/TI_feeds.csv. As this file contains sources for blacklisted domains and not the actual domains, there is no way to change anything here so as to prevent 0.0.0.0 and 127.0.0.1 from being identified as malicious.

Also i looked at /modules/threat_intelligence/threat_intelligence.py and found the function spamhaus could have some relevance but could not get any conclusive inference.

Can you please guide me from here so that I can work on this issue. Thanks!

[AlyaGomaa]

hello @ganesh-dagadi you are right, we can't do anything if any of our TI feeds have a FP. and I don't think spamhaus has anything to do with this my approach would be to add a function in the threat_intelligence module, to check for each DNS answer for the IP 0.0.0.0 if found as a resolution to any domain that isn't 'localhost', we can set evidence with threrat_level = 'info'

[eldraco]

What about adding 0.0.0.0 and 127.0.0.1 to the whitelist file @AlyaGomaa ? That should prevent it from being used in alerts. I don't like the idea of hardcoding IPs in the code so much.

[AlyaGomaa]

you said "we need to detect these as non-malicious evidence" if we whitelist them we won't be able to detect them so we either whitelist or detect them, what do you think?

[eldraco]

Ok, like this:

• if the IPs 0.0.0.0 and 127.0.0.1 appear in the traffic (IPs, DNS, URL, etc) then yes we need to detect this somehow. Non maliciuos evidence is ok.
• if these IPs appear in a TI file because of some FP error from the feed, we need to ignore.

which would be a good place for this? Do we need a third option in the whitelist file to ignore not only alerts and traffic but also TI feeds?

[AlyaGomaa]

ahh got it, i like the whitelisting of IPs/domains from TI feeds once an IP is whitelisted from all TI feeds we whitelist all evidence to/from it right?

[eldraco]

if the ip is removed from the TI feed by the 'new' whitelisting of TIs, then we dont have the TI problem. But we still need to deal with how to report them if we see them in the traffic. Hardcode them??? a new list???

[AlyaGomaa]

i'd always choose hardcoding until i'm sure that we have enough IPs to move them to a new list

[ganesh-dagadi]

what is FP?

[AlyaGomaa]

False positive, which means alerts/IPs that shouldn't be there but are there by mistake

[ganesh-dagadi]

ok. got it

[eldraco]

In case you need it @ganesh-dagadi https://en.wikipedia.org/wiki/False_positives_and_false_negatives. Ufffffffffff ok, we can hardcode, but with a deadline to review it, with good documentation about it, and asking forgiveness from the god of programming, that is, of course, Ada Lovelace.

[ganesh-dagadi]

thx @eldraco. Here is the approach:

In the is_malicious_ip function, if the ip is a False Positive (which will be checked against hardcoded ip list using a new function within the same file), we will set evidence as non malicious. Is this ok? I have a question : How do I set the evidence as non malicious? The function set_evidence_malicious_ip (used after detection of malicious IP in is_malicious_ip) appears to be used to create evidence of an actual blacklisted IP. Is it ok to use the same function as we are just reporting FP and not reporting an actual blacklisted IP?

[ganesh-dagadi]

@AlyaGomaa @eldraco can i follow this approach? Also please answer my question regarding setting evidence so that i can begin working on this asap. 😀

[eldraco]

Hi. Re reading the original problem, this description of the solution is not good for this. Evidently I explain myself wrong in the first description.

The threat intelligence modules has nothing to do with this. There is no TI, and nothing with the feeds.

• The problem is in the DNS answer. Some DNS resolvers answer the DNS query with 0.0.0.0 or 127.0.0.1 as the ip of the domain.

• This is not probably the real ip of the domain, but maybe it is only what the DNS says.

• I imagine that they may be DNS services like pihole that try to stop you from going to that domain. And in the example i found, the domain was an adtracker, so it fits.

• The place where we need to solve this is in the flowalerts module. A new function needs to be created next to and similar to check_suspicious_dns_answers()

• The idea is to check the answers coming from DNS and check that they are 0.0.0.0 or 127.0.0.1. And if they are set an INFO alert (since it is not infection)

• AND also very important, when they are found, this DNS answer should be deleted from the redis DNS cache. Because later on, all the DNS answers in the cache are checked in the check_dns_without_connection() function. And we want to avoid reporting a check_dns_without_connection in these answers, since there will be no answer.

Tell us @ganesh-dagadi if it is more clear now. Sorry for me answering about TI before, i got confused.

[ganesh-dagadi]

Yes. Thank you for the explanation. I will begin working on this now.

[ganesh-dagadi]

Pull request has been submitted #349