MaginotDNS:
Attacking the Boundary of
DNS Caching Protection
Speaker(s): Zhou LiContributor(s): Xiang Li and Qifan Zhang
August 2023
#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSAbout Us
Zhou Li
Assistant Professor at UC Irvine
Research interests: DNS, Graph Security analytics (GSA), …

Xiang LiPhD at Tsinghua University

2

Qifan Zhang
PhD at UC Irvine#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Attack Impact

Our MaginotDNS attack could poison
a whole TLD, e.g., .com, at one round.
All domains under that TLD can be hijacked.
3#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
4#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Domain Name System (DNS) DNS Overview
 Translating domain names to IP addresses
 Entry point of many Internet activities
 Domain names are widely registeredWebCDN

DNS

EmailCertificate
example.com

93.184.216.34

5

Cited from verisign.com/dnib#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDNS Resolution
 Resolution Process Primarily over UDP
 Iterative and recursive
 Record caching

DNSclient

DNS namespace

3 Query

QueryQuery

1

2

10Forwarder
Response

9Root.

example.com
Referral to TLD NS 4Delegate

5 Query

example.com

com

net

TLD

6Recursive Referral to SLD NS
Authoritative
resolverservers
7 Query

example.com
Authoritative answer 8

7Delegate
exampleSLD#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
8#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDNS Cache Poisoning Target
 Injecting forged answers into resolvers’ cache Taxonomy
 On-path, off-path Technique Cat-and-mouse game

KaminskyAttackKashpureff
Attack2013

20021997

Attack onForwarders

2008

BirthdayAttackFragmentation
Attack1120202020

Attack via
Attack via
EscapedEscapedChars v2
Chars
2021
2022
2021
SADDNS v2
AttackSADDNS
Attack#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS

12#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
On-path DNS Cache Poisoning
 Kashpureff Attack (on-path, 1997)
 Method: returning forged responses from the authoritative Result: resolver accepting all records in the response Cause: lacking data verification (bailiwick rules)
Step1: Recursive query for
www.alternic.net/ACache

Step 2: Iterative query for
www.alternic.net/A

Evil client

ISP resolver
Step 4:
Recursive query for
www.internic.net/A“alternic.net”
Authoritative
Server

Step 3: Response including bogus
www.internic.net/NS RR13

Step 5:
Bogus
Response

Unsuspecting
server#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDNS Bailiwick Rules Mitigating the Kashpureff Attack
 Record validation when storing cache entries
 Checking for “in bailiwick” in response data: answer records must be from thesame domain as the requested name$ dig example.com

Bailiwick;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34

In-bailiwick
Can be trusted;; AUTHORITY SECTION:
mybank.com. 86400 IN NS ns.mybank.com.

Out-of-bailiwick
Should be removed;; ADDITIONAL SECTION:
ns.mybank.com. 86400 IN A 1.2.3.4
14#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSTakeaway
After the Kashpureff attack, bailiwick checking isintegrated into the resolver’s implementation,
DNS cache poisoning on recursives from the on-path
seems impossible to conduct from 1997.
15#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Off-path DNS Cache Poisoning Kaminsky Attack (Off-path, 2008)
 Method: injecting forged responses with the birthday attack
 Result: resolver accepting glue records in the response Cause: lacking source port randomization (TXID only 16 bits)
Step 1: Recursive query for
www123.mybank.com/A“mybank.com”
AuthoritativeServer

Step 3: Response
TXID=XXXX
www123.mybank.com A?
(empty)mybank.com NS ns.mybank.com
ns.mybank.com A 6.6.6.6

AR AU AN QDTXID=1001
www123.mybank.com A?
(empty)mybank.com NS ns.mybank.com
ns.mybank.com A 1.1.1.1
16

AR AU AN QD

If TXID not matching,start the attack again
with anotherwww456.mybank.com

TXID=1002

Step 4: Response

ISP resolver
TXID=1001

Step 2: TXID=1001: Iterative query for
www123.mybank.com/A

TXQID=1000

Evil client

If TXID matching,success!

Cache

Unsuspecting
server#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDNS Source Port/TXID Randomization Mitigating the Kaminsky Attack
 Increasing the query guessing entropy
 16-bit source port x 16-bit TXID = 32-bit space Hard to brute force

6 5 5 3 6

6 5 5 3 6

Source port

TXID

17

#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSTakeaway
After the Kaminsky attack, source port randomization
is integrated into the resolver’s implementation,
DNS cache poisoning on resolvers from the off-path
became difficult to conduct from 2008.
18#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
19#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSQuestion
Are bailiwick checking and port randomization
good enough?
No. MaginotDNS breaks this guarantee with a new
powerful cache poisoning vulnerability.
20#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
MaginotDNS Attack What is the MaginotDNS attack A new powerful DNS cache poisoning attack against CDNS resolvers
 Can be launched from either on-path or off-path Can poison arbitrary domains including TLDs, such as .com and .net

 Name Exploiting vulnerabilities of bailiwick checking to bypass itself
 Working like breaking the Maginot Line  MaginotDNS21#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSQuestion
What is the CDNS resolver?

A conditional DNS resolver with bothrecursive and forwarding query modes.
22#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDNS Resolvers
 Worldwide

Client-side

 Multiple Roles

ODNS Recursive, forwarder

RDNS Hidden DNS (HDNS)
FDNS Complex Interaction
 CDNS𝐑𝐑𝐑𝐑𝐑𝐑𝐑𝐑𝐝𝐝

ADNS

𝐑𝐑𝐑𝐑𝐑𝐑𝐑𝐑𝐢𝐢

FDNS One of HDNSes
 Never been studied

Server-side

FDNS
Client23HDNS

ODNS:

open resolver

FDNS:

forwarder

RDNS:

recursive resolver

HDNS:hidden resolver

ADNS:

authoritative server#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Attack Target: CDNS
 Conditional DNS Resolver (CDNS)
 Forwarder + recursive resolver (shared cache) 2 query zones used for different resolutiono 𝑍𝑍𝐹𝐹 : domains for forwarding queries

Internal Networko 𝑍𝑍𝑅𝑅 : domains for recursive queries

CDNS Usage Scenarios

Public queries(google.com, etc.)

Query Enterprise: splitting networks

Local queries(mail.local, etc.)

 ISP: reducing heavy traffic cost
Clients
24LocalResolverInternetGoogle’s
8.8.8.8

PublicForwarding
Local
Recursive#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSAttack Overview of MaginotDNS Threat Model Assuming we discovered a CDNS and inferred its 𝑍𝑍𝐹𝐹 & 𝑍𝑍𝑅𝑅
 Attacking the forwarding mode

 Why forwarding mode?

 Bailiwick checking of the recursive mode is well enforced
 But the forwarder mode is not Since they share the same global DNS cache We can exploit the weak forwarder mode to attack the well-protected recursive modeo  Breaking the boundary of DNS cache protection
25#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Software Analysis
 Finding Vulnerable Software In depth bailiwick checking implementation analysis
 Via source code review, debugging, and testing 8 mainstream DNS software, e.g., BIND and Microsoft DNS

Inconsistentbailiwick checking
implementations

BIND

Knot

PowerDNS
26

Unbound#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Root Cause & Vulnerable Software General Bailiwick Checking Logic
 Summarized by us Root Cause In the InitQuery function:o Qry.zone is set to root  all records is in-bailiwick (root’s subdomains) Vulnerable Software
DNS Software

Forwarding

Recursive

Vulnerable

BIND9Enabled

EnabledYes

Knot Resolver

EnabledEnabledYes

Microsoft DNS

EnabledEnabledYes

Technitium

EnabledEnabledYes
27#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Bailiwick Checking (Done Right)
example.com

Clientexample.com
Recursive
ResolverNS
google.com
whitehouse.gov

Cache

Query zone: example.com
Records under example.com

29#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Bailiwick Checking (Done Wrong)
Forwarding zone: example.com

Recursive zone: {domains}-example.com

example.com

example.com

Forwarding zone
ClientUpstream servers

Forwarder
CDNSCache
Query zone*: .root
google.com

Recursive zone

Records under example.com
google.com, whitehouse.gov
Shared Cache
Query zone*: .root
Records under example.com
google.com, whitehouse.gov

30

Resolver Cache#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Attack Steps of MaginotDNS (On-path) Returning fake responses directly
 BIND, Microsoft DNS, Knot, and Technitium

Attacker
1Onpath

𝑸𝑸: attacker.com

2

Upstream
DNS Server

Conditional
DNS Server

Authoritative Server(attacker.com)

FwdingMatch fwd zone

3attacker.com
4𝑹𝑹

Return 𝑹𝑹

com. NS
ns1.rogue-tld-ns.org.

Cached31#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Attack Steps of MaginotDNS (Off-path) Guessing source
port & TXID
 Microsoft: new
port vulnerability

Attacker

 BIND9: using theSADDNS attack

1

𝑸𝑸: attacker.com
2

Offpath4

Upstream
DNS Server

Conditional
DNS Server

Authoritative Server(attacker.com)

Fwding : sport=x, txid=yMatch fwd zone

Guess dport & txid for 𝑹𝑹

attacker.com

Recursive

𝑸𝑸: attacker.com

Cacheddport=x, txid=y……
com. NSns1.rogue-tld-ns.org.

32

3𝑹𝑹

Control thereply time
𝑹𝑹𝑹𝑹
#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Off-path Attack on BIND9
 Guessing Source Port We use SADDNS to infer the source port
 ICMP rate-limit side-channel (check the SADDNS paper for details)

 Brute-forcing TXID
 Attack analysis
 Source port range: 32,768 - 60,999 (28,232)
 Query timeout: 1.2s, guessing 50 ports each round Success rate after 3,600 rounds:o 1 − [(28,232 − 50)/28,232]3,600 = 99.8%

SADDNS
33

https://www.saddns.net/#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Off-path Attack on Microsoft DNS
 Guessing Source Port We found MS DNS only uses ~2,500 source ports for resolution
 2,500 ports are all in the open state (SADDNS not working) Brute-forcing all 2,500 ports

 Brute-forcing TXID
 Attack analysis
 Source port range: probing in advance (2,500)
 Query timeout: 5s, guessing 20 ports each roundSource Port Range Examples of Microsoft DNS

 Success rate after 720 rounds:o 1 − [(2,500 − 20)/2,500]720 = 99.7%

34#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
35#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
MaginotDNS Attack Demos On-path Attack
 The result is determinative Off-path Attack
 Microsoft: avg. 802s

Log of Attacking Microsoft

 BIND9: avg. 790s

Log of Attacking BIND9Watch videos here.
36#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
MaginotDNS Attack Demos Off-path Attacks on BIND9 & Microsoft DNSBIND9Microsoft DNS

37#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
38#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Finding Vulnerable CDNSes
 Differentiating Forwarder & Recursive
 Based on the DNS resolution mechanism
 Forwarders do not cache intermediate NS records

Upstream
server

DNS query
Forward2

1

example.com? A

1

DNS query2

example.com? A

3 New methodology

Queryauthoritative oranswer fromlocal zones

4 Response1. Targeting one resolver
3. For some domains, no NS responses (forwarding)
4. For others, we get NS responses (recursive)

6
8Response

93.184.216.34

93.184.216.34
SLD A Cached

Cache probe 6

9example.com?
NS +norecurse

example.com?
NS +norecurse

Response(Empty)

5

example.com NS
a.iana-servers.net

SLD NS cachedby resolver

Response

7

Query TLD NS
Referral to SLD NS

SLD A Cached5

2. Testing a group of domains, sending NS&NR queries

4

SLD NSnot cachedby forwarder

3com. NSa.gtld-servers.net

TLD NS Cachedexample.com A93.184.216.34

Query root server
Referral to TLD NS

example.com? A Finding CDNSes

Authoritative
servers

Recursiveresolver

DNS ClientForwarder

Query SLD NS

Authoritative answer 7
example.com A
93.184.216.34

Cache probe

Response 10
a.iana-servers.net

5. The resolver does both forwarding & recursive resolution
6.  CDNS identified
39#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Vulnerable CDNS Population
 Measurement
 We collected 1.2M resolvers
 Removing not-applicable ones, such as violating NR or multiple caches
 Applying our method to identify 154,955 CDNSes
 Using software fingerprints to locate 54,949 vulnerable CDNSeso Resolvers with DNSSEC or 0x20 are filtered out

40#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSOutline
DNS overview
DNS cache poisoning
MaginotDNS workflow
Attack demoLarge-scale scanning
Discussion & conclusion
41#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSDiscussion & Mitigation
 Vulnerability Disclosure Confirmed and fixed by all affected software: BIND9, Knot, Microsoft, & Technitium 4 CVE-ids published & Bounty awarded by Microsoft

 Root Cause Problematic forwarding bailiwick checking implementations (Qry.zone <- root)o Why? Forwarder needs flexibility

 Mitigation Solution

 Qry.zone should be set to the forwarded domain in 𝑍𝑍𝐹𝐹 (query zone restriction) Then only records under forwarded domain are acceptable (cache split)
 Have been adopted by affected software

42#BHUSA #THU #UCI @BlackHatEvents

MaginotDNSBlack Hat Sound Bytes
 Bailiwick checking is not bullet-proof!
 We thought it’s perfect after 26 years since it’s born.

 Inconsistent DNS implementations are common…
 Forwarder vs. resolver
 BIND, Knot, Microsoft, ….
 Partially caused by the vague RFCs

 There might be more vulnerabilities we don’t even know …
 We need automated tools (e.g., fuzzers) customized to analyze DNS software My group is working on that 
44#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS

46#BHUSA #THU #UCI @BlackHatEvents

MaginotDNS
Wrap-upPaper

Thanks for listening!
Any questions?
Zhou Li, zhou.li@uci.edu
Xiang Li, x-l19@mails.tsinghua.edu.cn
Qifan Zhang, qifan.zhang@uci.edu

47

Tool

#BHUSA #THU #UCI @BlackHatEvents