Jan 24 2023

Serious Security: How dEliBeRaTe tYpOs might imProVe DNS security

Category: DNS AttacksDISC @ 10:41 am

Over the years, we’ve written and spoken on Naked Security many times about the thorny problem of DNS hijacking.

DNS, as you probably know, is short for domain name system, and you’ll often hear it described as the internet’s “telephone directory” or “gazetteer”.

If you’re not familiar with the word gazeteer, it refers to the index at the back of an atlas where you look up, say, Monrovia, Liberia in a convenient alphabetic list, and it says something like 184 - C4. This tells you to turn straight to page 184, and to follow the grid lines down from the letter C at the top of the map, and across from the number 4 on the left. Where the lines meet, you’ll find Monrovia.

For most users, most DNS lookups go out containing a server name, asking for a reply to come back that includes what’s known as its A-record or its AAAA-record.

(A-records are used for 32-bit IPv4 internet numbers, such as 203.0.113.42; AAAA-records are the equivalent answers for a 128-bit IPv6 addresses, such as 2001:db8:15a:d0c::42 – in this article, we’ll just use A-records and IPv4 numbers, but the same security issues apply to the lookup process in both cases.)

Here’s an example, where we’re looking up the imaginary domain name naksec.test via a DNS server that was specially created to track and teach you about DNS traffic.

We’ve used the old-school Linux tool dig, short for domain internet groper, to generate a simple DNS request (dig defaults to looking up A-records) for the server we want:

$ dig +noedns @127.42.42.254 naksec.test

;; QUESTION SECTION:
;naksec.test.			IN	A

;; ANSWER SECTION:
NAKSEC.TEST.		5	IN	A	203.0.113.42

;; Query time: 1 msec
;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP)
;; WHEN: Mon Jan 23 14:38:42 GMT 2023
;; MSG SIZE  rcvd: 56

Here’s how our DNS server dealt with the request, showing a hex dump of the incoming request, and the successful reply that went back:

---> Request from 127.0.0.1:57708 to 127.42.42.254:53
---> 00000000  62 4e 01 20 00 01 00 00  00 00 00 00 06 6e 61 6b  |bN. .........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01           |sec.test.....   |

DNS lookup: A-record for naksec.test ==> A=203.0.113.42

<--- Reply from 127.42.42.254:53 to 127.0.0.1:57708
<--- 00000000  62 4e 84 b0 00 01 00 01  00 00 00 00 06 6e 61 6b  |bN...........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01 06 4e 41  |sec.test......NA|
     00000020  4b 53 45 43 04 54 45 53  54 00 00 01 00 01 00 00  |KSEC.TEST.......|
     00000030  00 05 00 04 cb 00 71 2a                           |......q*        |

Note that, for performance reasons, most DNS requests use UDP, the user datagram protocol, which works on a send-and-hope basis: you fire off a UDP packet at the server you want to talk to, and then wait to see if a reply comes back.

This makes UDP much simpler and faster than its big cousin TCP, the transmission control protocol, which, as its name suggests, automatically takes care of lots of details that UDP doesn’t.

Notably, TCP deals with detecting data gets lost and asking foir it again; ensuring that any chunks of data arrive in the right order; and providing a single network connection that, once set up, can be used for sending and receiving at the same time.

UDP doesn’t have the concept of a “connection”, so that requests and replies essentially travel independently:

  • A DNS request arrives at the DNS server in a UDP packet of its own.
  • The DNS server keeps a record of which computer sent that particular packet.
  • The server sets about finding an answer to send back, or deciding that there isn’t one.
  • The server sends a reply to the original sender, using a second UDP packet.

From the level of the operating system or the network, those two UDP packets above are independent, standalone transmissions – they aren’t tied together as part of the same digital connection.

It’s up to the server to remember which client to send each reply to; and it’s up to the client to figure out which replies relate to which requests it originally sent out.

How can you be sure?

Learning CoreDNS: Configuring DNS for Cloud Native Environments

InfoSec books | InfoSec tools | InfoSec services

Tags: DNS flaw, DNS Security


May 03 2022

A DNS flaw impacts a library used by millions of IoT devices

Category: DNS AttacksDISC @ 8:29 am

A vulnerability in the domain name system (DNS) component of the uClibc library impacts millions of IoT products.

Nozomi Networks warns of a vulnerability, tracked as CVE-2022-05-02, in the domain name system (DNS) component of the uClibc library which is used by a large number of IoT products. The flaw also affects DNS implementation of all versions of the uClibc-ng library, which is a fork specifically designed for OpenWRT, a common OS for routers used in various critical infrastructure sectors.

An attacker can exploit the vulnerability for DNS poisoning or DNS spoofing and redirect the victim to a malicious website instead of the legitimate one.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.” reads the advisory published by Nozomi Networks.

The uClibc library is used by major vendors, including Linksys, Netgear, and Axis, or Linux distributions such as Embedded Gentoo.

Security experts did not disclose the details of the flaw because the vendor has yet to address it.

The researchers from Nozomi discovered the issue by reviewing the trace of DNS requests performed by an IoT device in their test environment. They were able to determine the pattern of DNS requests performed from the output of Wireshark, the transaction ID is first incremental, then resets to the value 0x2, then is incremental again. The transaction ID of the requests was predictable, a circumstance that could allow an attacker to perform DNS poisoning under certain circumstances.

DNS

“A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.” continues the advisory. “Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”

If the OS uses randomization of the source port, the only way to exploit the issue is to bruteforce the 16-bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate response.

“As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.” concludes Nozomi.

Managing Mission – Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

DNSSEC Mastery

Tags: DNS flaw, IoT devices