Malware Authors Turn to DNS Protocol as a Covert Channel

https://www.infosecurity-magazine.com/news/malware-dns-protocol-covert-channel/

 

A DNS firewall rule should prevent that.

 

Can you explain a bit more? I still don't understand how malware can use DNS to bypass firewalls.

 

Well, unless I misunderstood the threat, I think it means if an adversary set up a server to communicate on port 53 with malware on the victims computer, it is using the same port as a DNS server so the communications are assumed to be DNS requests.
Mitigate that by a firewall rule to allow communication to remote server port 53 ONLY to the IP address of your legitimate DNS server(s)
We used to allow only UDP, so TCP was blocked, but I remember reading something about DNS requests over 512 bytes need TCP and that IPv6 does make requests bigger than 512bytes.
I would experiment, allow only UDP and if DNS lookups start failing, allow TCP too.

 

This is basically a man-in-the-middle attack. The attacker is impersonating as your legit DNS provider or as posted above, capture the data before it is received by the legit DNS provider.

 

The attacker could use several methods, one of which is to setup a fake DNS server, then the firewall rule would work, but not in the other case.

I guess, that is, where encrypting dns requests would help, then he can not sniff anything.

 

Ah...
So if I have a bad trojan on my comp and it phones to home it could send small amounts of my data like:
myemailpassword.bad.com

That's quite sneaky !

 

Looking at Shamoon will fill in a lot of "the blanks" on this issue:

https://www.symantec.com/connect/bl...-destructive-attacks-limited-specific-targets

 

I wonder how well Heimdal would do against this. After all, I believe it was specifically design to prevent this sort of things from happening.

 

Actually the source Fidelissecurity article explains this attack the best: https://www.fidelissecurity.com/threatgeek/2018/03/your-networks-dns-plumbing-leaky

As far as recommended detections for the average end user, the one I underlined appears to be the only one feasible:

 

@itman it seems most of the vulnerability is tied to the fact that using domain names is insecure to start with, as the article said, attackers can register a sub domain, so if you specify the dns servers to be used explicitly by ip address in a firewall rule that blocks all others, it should prevent at least some of those attacks no?
Then if you add to that, using dns crypt https://dnscrypt.info/ should prevent attackers sniffing dns packets. Together that should tighten up dns security a lot.

 

This article is directed to corps. that use their own standalone DNS server or to ISP's and public DNS resolvers:

The average end user has a router. The router contains a DNS server; well not really. It is really just a cache containing resolved domain IP addresses used to speed up the resolution process. The actual DNS server is located at his ISP or in the case where a third party DNS provider is used, their server.

 

The article mentions several methods which seems to have caused confusion. One can be prevented just by firewall, another can be prevented by adding DNSCrypt or DNS over TLS (now you can block port53 entirely), but yet another can't by either, tho in this case DNS server have to be compromised or tricked.

While Heimdal essentially replaces the role of your stub resolver and apply DNS filtering, there's no direct prevention against these kinds of attacks except blacklist so you have to rely on its heuristic decision which I don't expect too much. There's discussion about Heimdal in Malwaretips, but I don't have interest in their efficiency on blacklist. What should matter is if their heuristic is efficient.

 

As far as home users go, they should be worried about attacks against the DNS server within their router. I am posting a few of those below.

Your best protection against these is to use a strong user id and password for router access. However, it is possible malware could change your Windows IPv4 or 6 DNS server settings for your network adapter if so employed. So your best protection is to create firewall rules to only allow inbound/outbound traffic to/from port 53 to your ISP or third party DNS provider IP address/es and block any other traffic to/from port 53. The important point to note is the malware installed on your PC and the malware then accessed your router's admin settings to make DNS server IP address changes. So if you block the malware in the first place, no further malicious activity can take place.

Anatomy of a modern DNS Changer malware attack

https://www.comparitech.com/blog/in...alware-how-to-detect-it-and-protect-yourself/

Switcher hacks Wi-Fi routers, switches DNS

https://www.kaspersky.com/blog/switcher-trojan-attacks-routers/13771/

 

The domain name system was a security train wreck from the start, the interesting thing to note is, if you manually enter the web site IP addresses for important websites into the hosts file, the DNS server lookup is not required. This mitigates all kinds of threats including most mitm attacks.
But how often is that ever mentioned in mainstream articles about MITM attacks and other DNS based attacks?

 

Thanks, will do a bit of more reading. SpyShelter does have an option to monitor requests to the DNS Resolver Service, but every app that needs to make an outbound connection will trigger an alert, so it's pretty pointless.

 

Use a firewall to block all connections to remote port 53 except for the the IP address(s) of your DNS server. For better than that, use dns crypt too and firewall it.

 

Here's a good article for corps running their own DNS server.

DNS Poisoning and How To Prevent It

https://www.alienvault.com/blogs/security-essentials/dns-poisoning

 

Yesterday, Eset's network protection detected a DNS poisoning attack on my PC:



Of note is the source IP is for Verisign's public DNS server which is had set up as my third party DNS provider.

Bottom line - you can be hacked regardless of what firewall rules you have enabled to only ensure you only connect via port 53 to your designated DNS provider. You really need to use a security solution that detect DNS poisoning/spoofing.

 

@itman how does that work are you running a dns server?

 

Eset's IDS has a number of network protections; DNS poisoning/spoofing is one of them.

 

Is it an issue in Linux as well?

 

Yes but what I meant was how does a DNS poisoning attack take place on your PC?
I thought those attacks were only against DNS servers.

 

I doubt that is poisoning on Verisign, maybe you can examine the detection including possibility of FP? These days experts seem to agree cache poisoning can be well mitigated w/out DNSSEC, through source port randomizing etc., essentially renders DNSSEC not much for poisoning prevention but more for added features such as dns-01 auth. But poisoning can be and have been done on router, endpoint, or the "last mile" of traffic with them and yes firewall don't protect you from poisoning.

 

Maybe UDP packet was just malformed, because some bit flipped in transit. TCP has some protection aginst it, UDP does not.

And that's why it is better to use encrypted and signed DNS queries by the means of DNS over TLS or DNSCrypt (which is faster thant DNS over TLS).