Xipology (⅓) — Exploiting DNS caching as a carrier
This is our story of exploiting caching Domain Name System (DNS) servers to break network segregation. We’ll call it Xipology and introduce it to you in three parts. First we will go through a bit of background and theory, then introduce a library to build on, and finally show you an application for a peer discovery over DNS.
Breakout
Segregation, segmentation, separation and containment are synonyms for the same goal. Hypervisors, containers, virtual machines for programming languages, MMUs, processes, contexts, sandboxes, namespaces, VLANs, MPLS, firewalls, software defined networks (SDNs) and alike are used to build walls to tear us apart. They provide a sense of security and an attempt to reduce complexity by neatly separating things from each other. Personal data protection, payment safety, or just your own sanity require you to segregate your data and networks.
Surprising things can pull the rug from under your segregation setup. Sharing is caring and caches are a must to improve the efficiency, but Last-Level Cache Side-Channel Attacks are Practical and Cache Missing has been exploited for Fun and Profit. Most of the public work on this front exploit the CPU level shared caches for covert channels and attacking crypto, but we are interested in the networks.
Here DNS enters the network play. DNS vulnerabilities, cache poisoning and DNS tunneling are old news. Your typical DNS tunneling tool is made for data exfiltration and requires a external name server controlled by the attacker. However we were looking for a true peer-to-peer approach that would work even in more challenging environments.
We have seen many segregated networks sharing a DNS resolver and knew a bit about DNS protocol and caching. A couple of quick experiments and a joy of discovery, we had means to make the DNS leak! Alas, a bit of googling revealed that this was news about ten years ago. DNS Covert Channels and Bouncing Techniques — a Phrack article by Anonymous from 2005 explains the theory of “our attack”, gives practical hints and proposes Worm communications application. It was followed in 2008 by a paywalled study called Domain Name System as a Memory and Communication Medium by Dušan Bernát. This study examines the channel error rate but goes no further in practical applications. Unfortunately all this seems forgotten, but fortunately for us the prior art leaves room for improvements in the theory, tooling, applications and popularization.
Leaky bits
Why caching DNS acts as a carrier for messages and leads to a leaky segregation? Caching status of any DNS name at your DNS resolver can be interpreted as one bit of information to transmitted. This bit has a limited time to live (TTL). You can set a bit by querying for a name, it will cause it to be cached, and you can signal zero by not querying. Thus these bits will self-destruct when you read them. We thought that this observer effect straight from the quantum mechanics is sexy as hell. Turns out that we just didn’t read the Phrack article well enough to notice the non-recursive query trick to work around the read only semantics. Our failure turned to our advantage and by taking the hard road we ended up pushing the envelope to enable new forms of exploitation, check out the last post in this series to find out how.
Since the cache for a single name conveys one bit of information, a sequence of names can be used to post a longer message. When posting the message only true bits (1) are written at corresponding names from the sequence. This gives an observer of the DNS traffic, who can’t predict the names in the sequence, a lower hand. An outsider can only count the number of true bits in the message but has no means to reveal the message or destroy the message. In other words, if you can see only the truth you are confined to repeat it.
Naughty bits
There are two strategies to store bits in the DNS cache.
Number one: Naughty bits can be stored in the positive cache by querying existing names. Using existing names is prone pollution from the environmental noise of the other users of the resolver co-incidentally querying the same names. The Phrack article gives pointers to work around the pollution by using the most unpopular websites on the Internet, wildcard DNS (see http://xip.io, wonder what inspired name Xipology?) or .in-addr.arpa domains. However positive caching with Internet names doesn’t work if the resolver is in a high security zone and isolated from the Internet.
Number two: Naughty bits can also be stashed in Negative Caching of DNS Queries (DNS NCACHE) by querying non-existing names. On the downside there may be resolvers that do not do negative caching and poorly chosen non-existing names may be a dead giveaway about something fishy going on. However negative caching works also in the truly isolated networks.
There are two ways to observe the naughty bits. You could either rely on the remaining time to live (TTL) returned by the DNS server or measure the variation in the query times. With positive caching the TTL signals the lifetime of the cache entry, but in the negative caching it might not be available from the NXDOMAIN error. While testing this we found some DNS quirks and the record (SOA) supposed to inform about the negative TTL was not present with all the resolvers and some resolvers returned stuck TTL values. Query times turned out to be more generic way to observe the caching state. We observed query times of 1 — 10 ms for cache hits and 10 — 1000 ms for cache misses. However in isolated setups the resolver might not recurse to greater distances and difference in the query times might be much harder to interpret. With the query times you can train your bit decision making by measuring several cache hits and misses and averaging them.
For fun and study credits
The Phrack article proposes that worms could use this scheme to communicate and coordinate. We didn’t want to write worms. Applying this to steganographic communications for privacy or data exfiltration would be hard to get right. We steered clear of that since we are not crypto experts. Any novel implementation for this scheme would be a perfect tool to test DNS-data exfiltration detection and prevention tools, see Detecting DNS Tunneling by Greg Farnham for a comprehensive list of the DNS tunneling tools and detection strategies. We didn’t have any detection tools to torture at our disposal, but we encourage you try this against your detection tech. You can check out our code from the next part. On top of coding a library we decided to apply this to peer discovery over DNS. In other words, we went for peers discovering each other and communicating, potentially over network barriers, by abusing shared resolvers as carriers. Having a tool for the discovery will help you to understand your network setup and co-dependencies and support security audits. You will find out if the DNS is the weak link in your network segregation setup.
No DNS servers were harmed in making this study. When you try this out please beware of excessive DNS load or your queries hitting innocent victims, choose your domains wisely and don’t use this to stream cat videos.
This series of blog posts was written by Ossi Herrala of SensorFu and Marko Laakso of Synopsys for the 521155S Computer Security (practical security) course lab taught by Teemu Tokola of OUSPG. DNS might be an obsession for Ossi and Marko just keeps breaking stuff in general. Please check out the next part for the library and “Hello World”, or skip to part three to see a mob of bots trashing around in the DNS space.
