DNS Covert Channel Attacks: Anomaly Occurrence

Part 4 of 5

In the prior articles of this series (1, 2, 3), I introduced and expanded on the idea of detection of data being exfiltrated or infiltrated using the DNS protocol. The DNS standard calls for a 64-character set for queries and responses which lends itself to exploitation as a base-64 data encoded channel. The problem for defenders is how to find and block this data channel on busy networks. Automated detection immediately comes to mind, but how to teach machinery to flag plain text as suspicious at line speeds is not obvious.

Previously, I gave you reason to believe that encoding produces anomalies that can be detected with CloudShield’s Deep Packet Processing (DPP) infrastructure, but have not shown that anomaly occurrence is frequent enough to be significant. In this article, we will look at the occurrence of character strings that result from encoding some common file types.

In part 2, I showed how detectable data is if you happened to see it flying past at line speed. In part 3 we discussed the anomalies that can occur in encoded data. Up to now, we have been proceeding with theory and hypotheses. Like good engineers, we want to know if our hypothetically detectable anomalies do, in fact, occur in sufficient density before we spend a lot of time and money designing and building our detector.

Character string anomalies

To this end, I’ve coded a two-way converter that ingests both text and binary files and produces purely base-64 character streams and files as output. To validate the concept and the encoder, I included a function to ingest the base-64 output and decode it to its original form. Many tests validated the application including processing executable files for which the base-64 results were used to rebuild the binaries. The doubly-transformed files did execute just as the originals.

What might we expect to see if a nefarious software agent is exfiltrating our proprietary data using DNS? First, for the results to be meaningful, we need to decide what string lengths constitute anomalies in the various character classes. For concept exploration, I chose a length of 4 for the special characters and 8 for the others.

Figure 1. Base-64 File Conversion Application (Source: Internal CloudShield document)

Figure 1 shows the results of encoding a CloudShield document. Significant in the figure are the fields at the bottom of each column. (The special character column is stacked under the digits column.). There are 9,469 long consonant strings and 18 long digit strings – over 9,000 anomalies without getting to the point of considering label and query lengths.

That is just over one anomaly for every 57 characters in the file – more than enough to trigger a high confidence alert. If we .zip all the data sheets, user guides, and sales slicks in my CS-4000 product folder and run it through the base-64 converter, we get 308,124 consonant strings, 11 vowel strings, 47 digit strings, and 4 special character strings. Similar results are obtained for the CloudShield IDE ISO image and various executable files.

Now we know there are sufficient anomalies in character strings alone to build a high-confidence detector. However, even though Leonardo De Vinci had a concept for a helicopter, he lacked the engine, structure, and control technologies to build it. So, do we have the technologies and infrastructure for instantiating a DNS exfiltration detector and/or blocker? Let’s look at the individual capabilities we need.

Capabilities needed to automate detection and blocking

Broadly, we need to examine packets and search for sub-strings in the various character classes and watch for lengths of sub-strings. More specifically, we need:

• A platform to ingest packets and examine them for packet type
• Ability to sort and pass on non-DNS packets and scrutinize the rest for anomalies
• String length searches – regular expression (regex) processing
• Packet data examination for total DNS query length
• Byte-by-byte packet inspection for label length tests
• Line-speed traffic processing for current-packet blocking decisions
• Management-side data harvesting and data field set capability for application control

The missing capability

We need one more significant capability, alluded to in part 3. We need to be able to replace the dots (length bytes) with characters that can be ignored in string searches. Why do we need to replace the length bytes? For regex processing, the length bytes look like character codes in the range of values from 2 to 63 making it difficult to code regex to ignore them.

For convenience, it would be nice to find a replacement character that is not used as one of the regex special characters and is not part of the DNS character set. The semi-colon, “;”, fits the need. If the search application walks through the length bytes, accessing each one directly from the information provided by those prior, the semi-colons can be inserted very efficiently and the lengths stored separately and restored later – depending on implantation specifics. The capability we need is packet data replacement, so we add another bullet to the list above, as:

• Selective packet data replacement

Does anyone make a platform that will provide all of these capabilities? If this sounds to you like a job for a CloudShield CS-2000 or a fraction of the capacity of a CloudShield CS-4000, you have been doing your research.

Putting it all together

We now have a good idea of what we need to look for to find anomalies and are confident we can find them. We also know the capabilities we need in a platform and we know where we can find that. All we need now is an analysis of design considerations and we will be ready to draft a design and implement the solution. We will examine some of the significant design considerations in the next article in this series.