4

Are there any tools (or at least methods that would work, if no free tools currently exist) which one could use to detect false DNS results?

It would be very simply to detect an attack along the lines of DNSChanger (just alert the user if the DNS server ip has been changed) but suppose a system like DNSChanger had worked by proxying your DNS queries and editing them on the fly.. how could you detect this?

|improve this question
  • 1
    If you want to verify dns query results on a client machine, then you can simply make script to statically use one of the trusted dns servers and second to use dns on the int conf and compare the both responses from both requests. – Kapish M Jul 29 '12 at 7:29
  • 1
    Well there are many tools for netflow, libpcap, DNS, but if you want to check if the UDP packet was not modified, you cant because it's not signed, so you need to guess with signal analysis – Andrew Smith Jul 29 '12 at 17:03
  • If you're looking for a broad set of free DNS analysis tools, you might check out SolarWinds' DNSstuff at www.dnsstuff.com. – user116343 Dec 19 '12 at 13:54
  • The best results you might get by using the new DNS ToolBox which draws a DNS Chart with the PTR, MX and TXT Records included in one DNS Chart - so you find the problem at a glance. – user27109 Jun 13 '13 at 8:34
2

I'm not aware of any tools, and I'm not sure how effective they would be. If you got enough privileges to change the DNS servers of a system, you can probably also disable any anti-malware programs.

If you still want to, you could easily write a script that does the following:

  1. Query for the domain you want to be sure is correct, using the system's DNS servers
  2. Query a trusted DNS server for the same domain
  3. Query a second trusted DNS server for the same domain

From which you can conclude:

  • If they all give the same IP, it's probably legit.
  • If the trusted DNS servers give the same IP but yours doesn't, something is wrong
  • If they all give different IPs, the nameserver of the target domain uses round-robin or split horizon

This is, like with almost everything, not entirely safe. Like I said, malware needs a lot of privileges to do this, it's not unthinkable that it spoofs the IP for trusted servers like OpenDNS or Google's public DNS, making them appear to return the same answer as the malware server.

Probably the only way to ensure you are talking to trusted DNS servers, is by using DNSSEC.

|improve this answer
0

Select a site whose IP never changes (Do not select a site that uses Akamai or any other multiple IP hosting, but more likely, a small company site), and simply run a script on the machine, constantly querying that site. If the IP returned changes - then you know you have malware.

|improve this answer
  • IPs are made to change, no matter what. Relying on some small company to keep their IP the same forever is going to give trouble sooner or later. Also if your DNS server is a fraud, it may still return the correct result for all but a few domains. – Luc Jul 29 '12 at 13:32
  • 1
    What you are saying is almost impossible to catch. I might be infected and even not go to those sites. The fraud can be at any level - network level? drivers level? configuration level? each of these issues should be handled totally differently. i.e. if it's a change in the system's drivers - even trying to reach a so called "trusted DNS" won't work. – Roy Reznik Jul 29 '12 at 13:45
0

You can run TSIG DNS checks (private key shared between host and requester), then run a CRON that listens for error responses and prompts action. It's used for verifying Dynamic DNS updates, but it could easily be used for security if you setup the secret key transfer correctly (eg. rsync over SSH).

This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.

No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available.

In regard to stale records and replay attacks:

3.3. Time values used in TSIG calculations

The data digested includes the two timer values in the TSIG header in order to defend against replay attacks. If this were not done, an attacker could replay old messages but update the "Time Signed" and "Fudge" fields to make the message look new.

There's an excellent read on DNS security in O'Reilly DNS and Bind.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy