Hacker News Reader

I monitor DNS queries made by some of my servers by setting a DoH server to systemd-resolve, some of the top queries are:

- OCSP servers to query TLS certificate validity. This is necessary because I have configured my web server to staple OCSP responses. (`e1.o.lencr.org`)

- Software repos (apt, dnf, etc). `livepatch.canonical.com` being the top contender.

- GitHub

The only place that TXT records are used in the very popular use cases would be an email server. SPF, DMARC, and DKIM all piggy back in TXT records. I would also imagine a lot of Microsoft stuff like AD use DNS .

In a corporate environment you need to block all the DNS traffic to external resolvers, except the company monitored DNS resolvers. If you have a SIEM that monitor the queries, it will be easy to identify the majority of attacks.

It's amazing how enterprises are only now doing this. Stub resolvers should not be sending queries anywhere but designated recursive resolvers for the network. It's easy to block outbound ports.

Oh, yes you should absolutely do that. What I meant is that in the case of prod you can stop all recursive DNS beyond the resolvers you own. But absolutely, all DNS should have to go through resolvers that you own.

I have done traffic analysis (e.g. netflow) and some basic base-lining/anomaly detection/cross referencing to spot this. Things like "Why do 9,999 workstations send an average of X bytes of DNS traffic a day, but yesterday Bob sent 1024 * X bytes" and "99% of DNS traffic is to a set of X DNS servers (root servers, DHCP assigned ones), but Jane almost always sends it to this one rando DNS server" get pretty easy to spot. Not perfect by any stretch, but you spot a lot of egregious stuff.

For production environments it's really unnecessary to allow most egress traffic, but it's especially unnecessary to allow DNS.

Yeah...this is really the low hanging fruit for this issue.

Filtering TXT doesn't help. Think about it. To exfiltrate data means to send data out, so you can just encode it in the query names and forget about RR types and RDATA.

Now if you were trying to infiltrate contraband, then RR types matter, but you could use A/AAAA and use as many as needed.

The way you deal with this sort of thing is by throttling query rates for domains you don't have on a list of domains known not to do this. An attacker could set up lots of domains to get around such throttling, but that's fairly expensive, and still should be noticeable. You really have to check DNS queries for odd behavior.

> Filtering TXT doesn't help. Think about it. To exfiltrate data means to send data out, so you can just encode it in the query names and forget about RR types and RDATA.

Well it definitely helps in that it would completely break this tool - as far as I know, TXT exfil is the most efficient since it allows the most data transferred per query, whereas all other forms are 1/2 as efficient or worse. But I agree there are ways around it - could you tell me more about the position that the attacker is in and how that attack works? Conceptually I can think of ways for an attacker to continue to exfil, but I'm wondering if you have something specific in mind. I'm assuming you just put the data into the subdomain, or something like that, which is much slower but still viable for C2 traffic.

Yes, it's putting the data into the name you're querying (the "qname" in DNS parlance). Say you have a message M of some length to exfiltrate, so first encode it as base64 or whatever, then break up the encoded message into chunks of 63 bytes (ASCII characters, since you encoded in base64), then send DNS lookups for ${n}.${chunk}.${some_label_identifying_exfiltration_instance}.${attacker_domain}. It doesn't matter what the replies are (NXDOMAIN is fine), or maybe you want a receipt confirmation encoded as an A or AAAA RR, whatever. You don't even need a tool because you can just script this from scratch every time you need this. The server could just log all the queries -- all you have to do is reassemble them.

One could send junk queries to these domains to try to muck with such attacks, so maybe the attacker could add a label with a MAC to every query name.

Really, this is unstoppable except via a) throttling, b) detecting this sort of thing, c) investigating detected attempts. (Or you can disallow direct DNS access to the Internet, forcing everything to go through proxies.)

Yep, makes sense.

The GitHub README page doesn't give many details, but for what I've seen in the (slightly blurry) screenshot, what this software does is spin up a DNS server on a given host, and then allow transferring a file to it by sending multiple DNS A requests for names containing parts of the Base64 representation of the file to that DNS server.

> Is there even a legitimate use for a public TXT record for corporate devices?

Assuming there isn't and blocking them will break applications. I realized my local resolver validates DNSSEC when I went to a place that did not forward RRSIGs, making me unable to access the Internet over there.

the problem is that most people do not monitor heavy use of TXT records; it's rather A/AAAA resolves in my experience.

but most production system i've seen allow all outgoing traffic (if poorly managed) or restrict it to port 443 (for some APIs) which is kind of all.

so if you're not in a very very restricted system (and then DNS should be restricted as well!) you'll most likely find an easy way to copy stuff over HTTPS.

You could also use AAAA records to exfil data. Whole 128 bits at a time.

Of course there are far more practical ways of going about it.

CNAME too. I dont know what the max field length for CNAME is though.

between 1 and 63 characters I think is the min/max

63 bytes per label, but the name can be longer than that.