18 ms·

How would this even be exploited? What software would try and use such an invalid domain? It would always fail, so such a thing would never be shipped to end us

How would this even be exploited? What software would try and use such an invalid domain? It would always fail, so such a thing would never be shipped to end users. The only thing I can think of is some kind of social engineering attack, but at that point I feel like you can just use a normal attacker controlled domain instead of trying to do something special.

kj4ips 1y ago
I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd. Imagine that: * I have an evil system at 192.0.2.1 * target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq. * foobar.com has a nameserver that silently drops any request with a ! in the first label I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com" 192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped. While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months. If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.
- charcircuit 1y ago
  That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.
  - ectospheno 1y ago
    RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.

kj4ips 1y ago

I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd. Imagine that: * I have an evil system at 192.0.2.1 * target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq. * foobar.com has a nameserver that silently drops any request with a ! in the first label I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com" 192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped. While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months. If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.

charcircuit 1y ago
That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.
- ectospheno 1y ago
  RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.