Abusing DNS
Source: http://xkcd.com/1361/
ron@skullsecurity.net @iagox86
Wow!
Such BSides
Wow!
Much SkullSpace
Many Google
Wow! DC204!
Yes, I know doge isn't cool anymore. It was when I made this slide. Now I'm taking it back!
You know the drill...
...but I have to say it.
The stuff I talk about here does not reflect the views of my employer, nor do does my employer necessarily condone anything I've done.
Information is provided without warranty, obligation, or consent. All sales final. See your pentester if symptoms continue for more than 3 days.
Things I'm gonna talk about
Things I'm not gonna talk about
RFC 1035
How DNS works
...in 5 minutes, or your money back (but not actually)
DNS requests (recursive)
Is it cached?
Yes: respond
No: send to 8.8.8.8
Is it cached?
Yes: respond
No: send to�X.root-servers.net
Is it cached?
Yes: respond
No: send to authoritative server
dig @192.168.0.1 test.skullseclabs.org
Return anything we want
X.root-servers.net
8.8.8.8
192.168.0.1
skullseclabs.org
Notice…
The endpoint never directly sent me a packet!
In fact, it didn't send a �single packet that left their �network!��(the router did)
Fun and games with Recursive DNS
The scenario…
I own skullseclabs.org. All requests to �*.skullseclabs.org go to my DNS server
Simple case: is somebody pinging me?
$ ping ab12.skullseclabs.org
Ping request could not find host ab12.skullseclabs.org. Please check the name and try again.
# ruby ./dnslogger.rb
dnslogger v1.0.0 is starting!
Starting dnslogger DNS server on 0.0.0.0:53
...
...
Got a request for ab12.skullseclabs.org [type = A], responding with NXDomain
DNS tunneling
Starring: dnscat2
Photo credit: me!
Some history
There were various DNS tunnels in the past, including one called 'dnscat' (it was Java - hasn't been updated since 2005), based on 'NSTX': http://tadek.pietraszek.org/projects/DNScat/
I wrote my own 'dnscat' as part of 'nbtool' a few years ago, roughly 2009: https://github.com/iagox86/nbtool
Re-wrote from scratch as 'dnscat2' a couple years ago. Still actively developing it!
The theory
You've compromised a machine already, and you need a way to communicate
Social engineering, an exploit, shell injection, etc. etc.
Dnscat2 implements DNS-based C&C
How is this different from…?
Most tunnels were written to get around paywalls, and only tunnel TCP
I explicitly de-scoped general-purpose tunnelling, and focused on command & control
Raw data / shell (not TCP) over DNS is uncommon, possibly unprecedented (at least in the open source world)
Features
Multiple simultaneous sessions
"Command" session (like meterpreter) - can execute commands, upload/download files, etc.
"Proxy" mode - tunnel TCP connections over DNS (like ssh -L)
[Newish!] Encrypted by default
Challenges with DNS
DNS is a really, really frustrating protocol to work with
Let's look at some of the more interesting challenges!
Challenge: DNS is stateless
This may be the most annoying problem
All requests come on the same port, from random upstream servers
It's impossible to know who sent which packet
Solution: session_id field
A field in the dnscat2 header that uniquely identifies a "connection"
Always sent in cleartext at the start of a packet, even encrypted packets (unfortunately, there's no alternative; believe me, I tried!)
Challenge: DNS is one way
The client can ask the server a question
But the server can't ask the client anything
In fact, the server doesn't know who the client is!
Solution: two-way communication
Solution: The client polls the server occasionally
What's the TXT record of "42494e474f0a.skullseclabs.org"?
It's "57617320686973206e616d652d6f0a"
The client even sends blank messages when it has no data
It's "77686f2773207468657265"
TXT for "656666"?
It's "6566662077686f3f"
TXT for "65666620796f7521"?
It's ""
TXT for ""?
It's "474554204954213f"
TXT for ""?
It's ""
TXT for ""?
It's ""
TXT for "6b6e6f636b206b6e6f636b.skullseclabs.org"?
Simple, right?
In reality, it works a little more like:
TXT for "6b6e6f636b206b6e6f636b.skullseclabs.org"?
It's "6566662077686f3f"
TXT for "6b6e6f636b206b6e6f636b.skullseclabs.org"?
It's "6566662077686f3f"
It's "6566662077686f3f"
Screw it. I'm getting a beer.
TXT for "6b6e6f636b206b6e6f636b.skullseclabs.org"?
TXT for "6b6e6f636b206b6e6f636b.skullseclabs.org"?
Challenge: DNS is incredibly unreliable
Retransmissions and drops are common
In fact, many DNS clients / relays will gratuitously retransmit, like it's a game or something!
Solution: A custom protocol
Uses a simple TCP-like protocol, designed with one-way communication mind
Has SYN/FIN packets to start/end sessions like TCP, and has MSG packets in the middle
Also has "ENC" packets, for setting up encryption
New(ish) feature:�Encryption!
Big new feature: Encryption!
All sessions are now encrypted - by default!
They can also be authenticated (to prevent man-in-the-middle attacks) with a pre-shared secret
Note: I'm not a crypto expert!
Technical details
Key exchange: ECDH w/ 256-bit keys (P-256)
Authenticator/signature/SAS: SHA-3 (sometimes truncated)
Encryption: Salsa20
(The choices were more informed by what I could find in Ruby/C than by what I actually wanted to use; however, they're still pretty solid choices)
Way more details: https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md
Traffic forwarding
Newest feature!
On server:
Server will listen on port 1234, forward all connections via the dnscat2 session!
dnscat2> listen 1234 otherhost.com:4321
Traffic forwarding
Metasploit, etc
dnscat2� server
Owned client
Vulnerable server
Listens on port 1234
Connects on port 4321
Future plans
Defense
The ultimate goal of dnscat2…
… is for dnscat2 not to work anywhere.
That's the fun of writing offensive tools.
But really, it's about giving us an easy way to prove that there's a problem!
Detection
… because I have friends who get mad when I only deliver bad news. :)
Tunneled DNS traffic stands out like a sore thumb; it's just a matter of looking for it!
A local friend wrote a thesis on it:�https://www.riebart.ca/hg/thesis/file/70f30181eb5c/Proposal/proposal.pdf
Detection
To summarize:
Some other resources…
Some other research I've run across (if I miss something, please let me know!):
Question?
Ron Bowes <ron@skullsecurity.net>
https://www.skullsecurity.org/
Twitter: @iagox86
Github: iagox86
https://tinyurl.com/dnscat-talk-dc204