When attackers use your DNS to check for the sites you are visiting

Published: 2013-11-04. Last Updated: 2013-11-04 23:09:46 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
1 comment(s)

Nowadays, attackers are definitely interested in checking what sites you are visiting. Depending on that information, they can setup attacks like the following:

  • Phising websites and e-mail scams targeted to specific people so they leave their private information.
  • Network spoofing with tools like dsniff, where attackers can tell computers that the sites they want to visit are located somewhere else, therefore enabling them to interact with victims posing like the original site.

One of the most widely used techniques is DNS snooping, where the attacker checks for the DNS server of the domain what queries have been performed by the internal users and therefore letting see the attacker what sites have been visited.

A normal DNS query has the following information:

DNS query packet

What does mean those fields? Let's check everyone of them:

  • Transaction ID: It's used to match the request and reply packets so the computer is able to identificate which answer belongs to which question.
  • Response: If set to 0 is a query packet. If set to 1 is a response packet.
  • Opcode: We can find the following opcodes:
Opcode

Description

0 Standard Query
1 Inverse Query
2 Server Status Request
3 Unassigned
4 Notify
5 Update
6-15 Unassigned
  • Truncated: This flag indicates if only the first 512 bytes of the response is returned. Since this is a question, it is set to 0.
  • Recursion Desired (RD): Instruct the DNS server whether or not to perform recursion to look for the answer of the query.
  • Z: Used in old DNS implementations. If set to 1, only answers from the primary DNS of the destination zone is accepted (Check RFC5395)
  • Non authenticated Data: Used in response packets. If set in 1, indicates that all data included in the answer and authority sections of the response have been authenticated by the server according to the policies of that server. Since this is a query packet, it is set to 0.
  • Questions: Indicates the number of query structures present in the packet.
  • Answer Resource Record (RR): Indicates the number of entries in the answer resource record list that were returned.
  • Authority RR: Indicates the number of entries in the authority resource record list that were returned.
  • Additional RR: Indicates the number of entries in the additional resource record list that were returned.
  • Queries: List of queries included in the packet.

The answer of the last query is shown in the following figure:

DNS response packet

The response code table for the DNS protocol is the following:

Rcode Description
0 No error. The request completed successfully.
1 Format error. The name server was unable to interpret the query.
2 Server failure. The name server was unable to process this query due to a problem with the name server.
3 Name Error. Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.
4 Not Implemented. The name server does not support the requested kind of query.
5 Refused. The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data.
6 YXDomain. Name Exists when it should not.
7 YXRRSet. RR Set Exists when it should not.
8 NXRRSet. RR Set that should exist does not.
9 NotAuth. Server Not Authoritative for zone.
10 NotZone. Name not contained in zone.
11-15  
16 BADVERS.Bad OPT Version.
BADSIG.TSIG Signature Failure.
17 BADKEY. Key not recognized.
18 BADTIME. Signature out of time window.
19 BADMODE. Bad TKEY Mode.
20 BADNAME. Duplicate key name.
21 BADALG. Algorithm not supported.
22 BADTRUNC. Bad truncation.
23-3840 Reserved
3841-4095 Private use.
4096-65534 Reserved
65535 Reserved

When an attacker performs the DNS cache snooping attack, it queries for specific domains without the RD bit set. If the DNS answers the query, then somebody from the inside requested access to that site and so it is cached in the DNS.

Let's see a DNS cache snooping attack query, which is a packet without the RD bit set:

DNS Snoop Query packet

How can we send several packets to test various domains? We can use a nmap script to perform the query for 100 domains already preconfigured:

Let's check the nmap options for the last figure:

  • -sU: Performs UDP Scan
  • -p 53: Performs the selected scan only to port 53
  • 192.168.0.1: Place here the IP address you want to check.

We can see in the following figure a DNS with many cached registers:

DNS cache snoop with nmap

How can you avoid this attack? In bind 9, there is a new feature called view, where you can limit the actions to ip ranges. Let's see an example:

view "external" {
    match-clients { any; };
    recursion no;
    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

 

This configuration only allows to answer queries for example.com zone. Since the recursion no directive is set, it also defaults the allow-query-cache {none;};, which denies access to the cache server. You can use this with bind 9.4 and newer.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

1 comment(s)

Comments

Thanks for the post. Timely, we were just discussing this internally.
Conflicting info out there but from what I gather if the DNS box is a MS DC/DNS and you set to not allow this you have also broken the ability to forward queries so you couldn’t surf the inet from inside?
This is a PCI Violation?
I would be interested in any real world attack scenarios.

Diary Archives