The Technical Aspect Spoofing Cache Poisoning And Other Attacks

You've seen, more or less, the social aspects that affect security related to the DNS infrastructure. Now we'll discuss the technical side.

As you've seen, usually at least two packets are exchanged in a DNS transaction. The piece of information that "glues" the reply to the original query is the identification field. This field has a 16-bit value and should be picked randomly every time. During recent years, several implementations have not picked the value randomly enough, allowing the possibility of session hijacking by spoofing.

An attacker can guess the correct ID by sending a series of packets with different IDs to the victim's client, hoping that one of them will match the ID in the client's query. Of course, guessing the ID is only part of the process, since an attacker would still need to guess the matching port numbers and carefully inject the spoofed reply at the right time.

The latest DNS implementations are not easily affected by predictable ID numbers issues, but spoofing is always theoretically possible if conditions are favorable. Of course, on a local LAN where Layer 2 hijacking is possible, DNS spoofing is trivial.

In this context the spoofed reply doesn't necessarily need to be directed to the client itself. An attacker can also spoof a reply for a query made by a victim's DNS server, thus poisoning its cache. The advantage of this is that if the DNS server is an open resolver, the attacker can increase the chances of success by asking it to resolve a name on his or her behalf and then spoof the replies for that same query. If successful, this attack "poisons" the cache of the victim's DNS server, aiding the malicious intent.

Another type of known cache-poisoning attack consists of injecting additional authoritative information into a legitimate DNS reply. The attacker would ask the victim's DNS server for the resolution of its (the attacker's) own zone. The DNS server would then request this information from the attacking domain's authoritative server, which is controlled by the attacker.

The zone file of the requested domain would have an additional section with an entry completely unrelated to the requested domain (i.e., a bogus IP address for www .google.com), so that the requesting DNS server would cache that information for performance purposes even if the entry is not what was requested. Currently, most DNS server implementations are configured to reject additional zones that are not compliant with the original query, but older systems are still vulnerable to this kind of attack.

Rather than relying solely on DNS, some protocols provide an additional layer of authentication. The most notable example is TLS- or SSL-encrypted connections (like

HTTPS), which are used for authenticating your endpoint with a certificate signed by a trusted certification authority. Even with DNS hijacking, an attacker would not be able to present a valid certificate easily. Unfortunately, many users tend to ignore SSL-related warnings presented by browsers and most SSL connections between applications don't enforce certificate validation as they should.

Some protocols, like SSH, cache a unique ID associated with the host, so that any DNS hijack attempt would raise an error due to mismatched ID:

[keymaker]:/home/epablo:\>ssh 192.168.1.22

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is ff:87:b7:69:dc:f5:ef:8c:39:df:30:22:44:d2:68:60. Please contact your system administrator.

Add correct host key in /home/epablo/.ssh/known hosts to get rid of this message.

Offending key in /home/epablo/.ssh/known hosts:25

RSA host key for 192.168.1.22 has changed and you have requested strict checking.

Host key verification failed. [/example of ssh hostid mismatch]

It's always good practice to rely on something other than DNS for any authentication purpose and to use IP addresses if possible in your configurations.

Finally, the DNS cache can also be used to check if clients using your DNS server have been querying for a specific domain. This technique is called cache snooping. If your DNS server accepts queries from arbitrary addresses, it will immediately provide cached information about already-resolved domains, instead of referring the client to the toplevel DNS server (if it allows non-recursive queries), or it won't reply to the query at all. Successful cache snooping allows an attacker to easily probe if your network has been browsing a specific domain lately, and it can greatly help with social engineering attacks.

This example shows how a simple timing analysis tells you that users of the DNS server you are querying have been using Google lately and not Excite. Apart from the timing, you can also gather that information from the cache Time to Live (TTL) times: A round value of 14400 in the first case is evidence of a freshly cached record, whereas Google's TTL of 138738 shows that it has been cached for quite some time (a simple cross check with a clean DNS cache shows that www.google.com's default TTL time is

604800).

$ time dig www.excite.com

<< DiG 9.3.0 << @140.105.134.1 www.excite.com global options: printcmd Got answer:

-HEADER«- opcode: QUERY, status: NOERROR, id: 7685

flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2

; ; QUESTION SECTION ;www.excite.com.

;; ANSWER SECTION: www.excite.com.

14400

208.45.133.23

;; AUTHORITY SECTION: excite.com. 17 27 9

excite.com. 17 27 9

excite.com. 17279

excite.com. 17279

IN NS ns1-156.akam.net.

IN NS dns4.imgfarm.com.

IN NS dns5.imgfarm.com.

IN NS use1.akam.net.

;; ADDITIONAL SECTION: use1.akam.net. 4180 IN A ns1-156.akam.net. 17866 IN A

63.209.170.136 193.108.91.156

Query time: 660 msec

SERVER: 140.105.134.1#53(140.105.134.1) WHEN: Sat Nov 4 17:23:34 2006 MSG SIZE rcvd: 175

real 0m0.672s user 0m0.012s sys 0m0.000s

$ time dig www.google.com

; << DiG 9.3.0 << @140.105.134.1 www.google.com ;; global options: printcmd ;; Got answer:

;; -HEADER«- opcode: QUERY, status: NOERROR, id: 37034

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: C

,•www.google.com. IN A

;; ANSWER SECTION:

www.google.com. 138738 IN CNAME www.l.google.com.

www.l.google.com. 300 IN A 66.249.85.99

www.l.google.com. 300 IN A 6 6.249.85.104

;; AUTHORITY SECTION:

l.

.google.

. com.

77277

IN

NS

a.

l.

.google.

com

l.

.google.

. com.

77277

IN

NS

b.

l.

.google.

com

l.

.google.

. com.

77277

IN

NS

c.

l.

.google.

com

l.

.google.

. com.

77277

IN

NS

d.

l.

.google.

com

l.

.google.

. com.

77277

IN

NS

e.

l.

.google.

com

l.

.google.

. com.

77277

IN

NS

g.

l.

.google.

com

Query time: 129 msec

SERVER: 140.105.134.1#53(140.105.134.1) WHEN: Sat Nov 4 17:23:42 2006 MSG SIZE rcvd: 180

real 0m0.142s user 0m0.008s sys 0m0.004s

We discuss how to prevent this behavior in the next section.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Post a comment