Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Use DNS TXT to share information

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: Show HN: Use DNS TXT to share information

#51

Post by _8j50 »

ngc6677 wrote: post #45
_8j50 wrote: post #30

OP, this is trivial to detect. DNS command and control is a thing malware/attackers use which among other things include TXT records,DoH, long A or AAAA records and many other creative ways, my fav right now being using a CNAME chain to encode information (no single request is too large or suspicious. In my experience, bypassing censorship does not mean doing unusual things like this but things like browser extenstio…

what do you mean by CNAME chain? sounds interesting

Lookup .site.com gets you A.com -> B.com -> C.com -> IP. ABC is the response message and the subdomain is the request.

Re: Show HN: Use DNS TXT to share information

#52

Post by mrweasel »

toast0 wrote: post #37
mrweasel wrote: post #35

Earlier quoted context omitted.

Won't DNSSEC prevent MITM attacks in this case? From https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... - "DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX)"

clamav.net, like most domains, doesn't enable DNSSEC. Further, as designed, local resolvers don't validate DNSSEC, they just ask the recursive resolver to; a MITM between the local and the recursive can lie. So when wikipedia says DNSSEC can protect, that's the permissive can. Like things can happen. But don't rely on it.

Silly me for expecting an anti-virus company to care about security. The point remains: DNSSEC COULD make this safe to do.

Re: Show HN: Use DNS TXT to share information

#53

Post by orangepurple »

egberts1 wrote: post #43
hannob wrote: post #27

Earlier quoted context omitted.

That is... interesting that they do not even use HTTPS or any type of signature for that info. So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?

well, that would be the fault of clamav if they did not do the proper DNSSEC verification and validation of their ‘current.cvd.clamav.net’ hostname. Digging into the code of freshclam, source of libfreshclam.c, dnsquery() function call, it is painfully evident that freshclam daemon does not do basic DNSSEC when performing res_query(). Instead, freshclam should be calling `val_res_query()`. They are currently using ‘r…

Yep, it's another "security" solution that is dead on arrival

Re: Show HN: Use DNS TXT to share information

#54

Post by philipwhiuk »

RajT88 wrote: post #31

Timely. I've been noticing on flights that the in-flight wifi uses a squid proxy to block you until you pay - but most of the time, you'll get whatever data from the DNS Forwarder even if you haven't paid yet. I've been noodling on how to build a simple proxy off DNS to test on my next flight.

This sort of escape is how Kaminsky ended up as the guy who broke DNS.

(From the opener to https://www.wired.com/2008/11/ff-kaminsky/ )

Re: Show HN: Use DNS TXT to share information

#55

Post by hashstring »

fanf2 wrote: post #5

There are a bunch of awkward limitations, tho: The order of records associated with a name is undefined, so if you spread your data across multiple records, you need to add ordering metadata. The total size of the records must be less than 64 KiB - they have to fit within a DNS message, which has a limited size. You can put all your 64K ish data into one TXT record, but it has to be split into strings of up to 255 by…

I think that a lot of offensive tools to tunnel IP over DNS actually overcame these limitations in real time, at the expensive of throughput [1]. It obviously does require agreeing on some sort of protocol on both sides though.

[1] https://github.com/yarrick/iodine

Re: Show HN: Use DNS TXT to share information

#57

Post by omoikane »

toast0 wrote: post #37
mrweasel wrote: post #35

Earlier quoted context omitted.

Won't DNSSEC prevent MITM attacks in this case? From https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... - "DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX)"

clamav.net, like most domains, doesn't enable DNSSEC. Further, as designed, local resolvers don't validate DNSSEC, they just ask the recursive resolver to; a MITM between the local and the recursive can lie. So when wikipedia says DNSSEC can protect, that's the permissive can. Like things can happen. But don't rely on it.

Related:

https://news.ycombinator.com/item?id=36171696 - "Calling time on DNSSEC: The costs exceed the benefits"

Re: Show HN: Use DNS TXT to share information

#58

Post by donselaar »

AtNightWeCode wrote: post #56

If TXT-records are proof enough when ownership is to be provided for TLS certs. Then, why not just put the TLS-data into the "trusted" TXT-records and skip the multi-billion-dollar-BS-CA-biz all together?

Makes sense indeed. It exists and it's called DANE. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Re: Show HN: Use DNS TXT to share information

#59

Post by hashstring »

donselaar wrote: post #58
AtNightWeCode wrote: post #56

If TXT-records are proof enough when ownership is to be provided for TLS certs. Then, why not just put the TLS-data into the "trusted" TXT-records and skip the multi-billion-dollar-BS-CA-biz all together?

Makes sense indeed. It exists and it's called DANE. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Yes and then your government controls your “trusted” connection.

Re: Show HN: Use DNS TXT to share information

#60

Post by thewataccount »

AtNightWeCode wrote: post #56

If TXT-records are proof enough when ownership is to be provided for TLS certs. Then, why not just put the TLS-data into the "trusted" TXT-records and skip the multi-billion-dollar-BS-CA-biz all together?

I'm not sure I 100% understand your question.

If you're asking "Why do we need CA's when they already control the DNS record for that domain" then the answer is that DNS doesn't natively even have any cryptography involved, your DNS server can serve any information it wants, and this is common practice in IT environments.

Effectively speaking MITM'ing dns is relatively easy and common as it's the equivalent to HTTP.

So you don't know that the answer you are receiving it actually from the owner of that domain. If they sent you a certificate you don't know if that's an attackers certificate or the owner's certificate.

The CA system is a (very imperfect) method of verifying ownership by having a trusted third party do the ownership verification. This way the certificate the owner gives you is effectively "notarized" so to speak.

tl;dr - DNS has no built-in signing or encryption, and is "MiTM'd" by design. It's common practice for your DNS server to be set to your company's DNS server, your ISP, etc. And those can send any response they want, and you have no way to authenticate if it's been modified or not.

Post reply on HN