On Robust Covert Channels Inside DNS Lucas Nussbaum , Pierre Neyron - - PowerPoint PPT Presentation

▶

Sep 16, 2022 585 likes •789 views

On Robust Covert Channels Inside DNS Lucas Nussbaum , Pierre Neyron and Olivier Richard Laboratoire dInformatique de Grenoble / INRIA Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 1 / 18 Introduction

SLIDE 1

On Robust Covert Channels Inside DNS

Lucas Nussbaum, Pierre Neyron and Olivier Richard Laboratoire d’Informatique de Grenoble / INRIA

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 1 / 18

SLIDE 2

Introduction

Many networks with restricted Internet access : Wireless access points in hotels and airports Censored Internet access in some countries Question : How can one get full Internet access ? Idea : Leverage one of the unfiltered protocols

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 2 / 18

SLIDE 3

DNS ?

DNS : perfect protocol ? (Almost) never filtered And cannot reply with wrong results because of cache But was not designed for tunnelling data Need to work around several DNS limitations

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 3 / 18

SLIDE 4

DNS covert channels : principle

Hide data into DNS requests and replies Communicate with a rogue DNS server on the Internet

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 4 / 18

SLIDE 5

Existing implementations of DNS tunnelling

Not a new idea : IP over DNS tunnels : NSTX Iodine TCP over DNS tunnels : OzymanDNS dns2tcp ⇒ Compromises between protocol compliance and efficiency

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 5 / 18

SLIDE 6

DNS record types

Example :

> CNAME ? www.google.com. < q : CNAME ? www.google.com. www.google.com. CNAME www.l.google.com.

Name being queried : only text (A-Z, a-z, 0-9, "-") Record type being queried (implies type of reply) : A : only 4 bytes of data ! CNAME : text with additional requirements (valid DNS name) TXT : any kind of data [NSTX, OzymanDNS, dns2tcp] But not many real-life uses ⇒ often blocked NULL : for experimental purposes [Iodine] No known real-life usage

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 6 / 18

SLIDE 7

DNS extension : EDNS0

Specified in RFC 2671 Allow for larger packets Used by Iodine and OzymanDNS Not many real-life uses ⇒ can easily be blocked by ISPs

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 7 / 18

SLIDE 8

Data encoding in queries and replies

DNS names : A-Z, a-z, 0-9, "-" => 63 characters DNS servers "should" preserve case if possible 2 solutions : Base32 (need 32 characters) Less efficient, but protocol compliant [OzymanDNS] Base64 (need 64 characters) Adding another, invalid character : "_" [NSTX, Iodine] "/" [dns2tcp] Using an escaping system But packet length would vary

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 8 / 18

SLIDE 9

Evaluation of existing solutions

All solutions tested on several networks (academic, home ISP , hotels, airports, etc...) Each of them failed to work in some cases ⇒ Too many compromises with protocol compliance ? ⇒ Build our own solution ?

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 9 / 18

SLIDE 10

TUNS

IP over DNS tunnel Standard-compliance : uses CNAME records and Base32 Handle poor network conditions : Does not split IP packets Lower MTU instead Handle duplicate replies Efficient polling mechanism

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 10 / 18

SLIDE 11

Example packets

Data packet from client to server : dIUAAAVAAABAAAQABJ5K4BKBVAHAKQNICBAAAOS5TD4ASKPSQIJEM7VABAAEASC. MRTGQ2TMNY0.domain.tld: type CNAME, class IN The client sends a short query that the server will use to send a reply : r882.domain.tld: type CNAME, class IN The server acknowledges the data that was sent : Queries dIUAAAVAAABAAAQABJ5K4BKBVAHAKQNICBAAAOS5TD4ASKPSQIJEM7VABAAEASC. MRTGQ2TMNY0.domain.tld: type CNAME, class IN Answers dIUA[..]0.domain.tld: type CNAME, class IN, cname l4.domain.tld The server sends a reply containing data to the client : Queries r882.domain.tld: type CNAME, class IN Answers r882.domain.tld: type CNAME, class IN, cname dIUAAAVCWIUAAAQABH VCY2DMO2HQ7EAQSEIZEEUTCOKBJFIVSYLJOF4YDC.MRTGQ2TMNY0.domain.tld

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 11 / 18

SLIDE 12

Efficiently polling the server

Problem : Server sends data to client using DNS replies To send a DNS reply, the server needs a query Solution : On regular intervals, send a DNS query to the server The server answers with data or indicates that there’s no data Optimization : [NSTX and TUNS, but not Iodine] If there’s no data, wait for a while. Data might arrive in the meantime. From the client POV, the server simply looks busy. ⇒ Improves perceived latency significantly

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 12 / 18

SLIDE 13

Performance evaluation

Compared NSTX, Iodine and TUNS using a network emulator Measured the tunnel’s latency and bandwidth with varying network latency Also when facing degraded network conditions (5% packet loss, variable latency causing packet reordering)

TUNS server TUNS client emulator

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 13 / 18

SLIDE 14

Results : bandwidth

100 200 300 400 500 50 100 150 200 bandwidth (Kbps) emulated RTT (ms) Bandwidth, server to client NSTX Iodine Tuns 100 200 300 400 500 50 100 150 200 bandwidth (Kbps) emulated RTT (ms) Bandwidth, client to server NSTX Iodine Tuns

⇒ TUNS is slower than the other implementations

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 14 / 18

SLIDE 15

Results : bandwidth, with loss / reordering

20 40 60 80 100 50 100 150 200 bandwidth (Kbps) emulated RTT (ms) Bandwidth, server to client NSTX Iodine Tuns 20 40 60 80 100 50 100 150 200 bandwidth (Kbps) emulated RTT (ms) Bandwidth, client to server NSTX Iodine Tuns

... but stays more stable when network conditions are degrated, and outperforms NSTX

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 15 / 18

SLIDE 16

Results : latency

200 400 600 800 1000 1200 1400 50 100 150 200 perceived RTT (ms) emulated RTT (ms) Latency, pings initiated by server NSTX Iodine Tuns 50 100 150 200 250 50 100 150 200 perceived RTT (ms) emulated RTT (ms) Latency, pings initiated by client NSTX Iodine Tuns

⇒ Iodine’s polling mechanism is inefficient

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 16 / 18

SLIDE 17

Conclusion

Exposed the various challenges faced by DNS covert channels Described TUNS, our IP over DNS tunnel Slower that the other implementations in some cases But uses only standard DNS features Harder to block by system administrators Remaining solution : traffic shaping Worked on all networks we could try Except those with broken DNS, of course

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 17 / 18

SLIDE 18

Future Work

Tuning of tunnel parameters from the client-side Packet length, DNS record type, encoding Automatic detection of best parameters Headers compression ⇒ more space for data TCP tuning to better handle packet re-ordering Very frequent over DNS Encryption of data being transmitted

Lucas Nussbaum, Pierre Neyron and Olivier Richard On Robust Covert Channels Inside DNS 18 / 18