4 ms·
The important bit is kind of buried in the middle: It is important to note that as the record is malformed, it should not traverse any sane DNS resolvers. Beca
by rando444 9y ago
The important bit is kind of buried in the middle:
It is important to note that as the record is malformed, it should not traverse any sane DNS resolvers. Because of this, the issue can only be triggered if the victim(s) are accepting DNS responses directly from the attacker-controlled server. Typically, this would require an active Man-in-the-Middle attack.
- deleted 9y ago[deleted]
- tyingq 9y agoTrue, though "man in the middle" can be as simple as serving up free WiFi anywhere people have laptops.
- stephengillie 9y agoA way to protect yourself is to manually specify DNS servers - to your own, or a trusted public one like 4.4.2.2 or 8.8.8.8. It's buried in the network settings, but DNS servers can be specified even if you're getting your IP from DHCP. This attack only works if you're getting DNS info from a malicious/compromised source. So if you're on a coffee shop WiFi, it creates another layer of complexity - the attacker would have to rewrite/spoof the DNS packets instead of simply serving the malformed packets directly.
- jonknee 9y agoWould that make a difference if you're getting MITM?
- stephengillie 9y agoThe coffee shop WiFi would have to rewrite the packets with a new payload. Not too difficult, but a different skillset and scope than the original attack.
- SadWebDeveloper 9y agoNo, unless you configure your IP address statically and use a VPN that doesn't require a DNS lookup to connect so basically, it's hard to avoid these issues on a rouge network.
- Santosh83 9y agoIsn't that 4.4.4.4 or does Google also have a public DNS server on 4.4.2.2?
- stephengillie 9y ago4.4.2.2 is Level3, now owned by CenturyLink.
- deleted 9y ago[deleted]
- jwilk 9y agoGoogle Public DNS IPs are 8.8.8.8 and 8.8.4.4. Source: https://developers.google.com/speed/public-dns/ https://developers.google.com/speed/public-dns/
- mobilio 9y agoAnd why you think that someone can make free WiFi hotspot and can't route that both IPs to it's own DNS server?
- 9y ago
- benkillin 9y agoWould a mitm attack be necessary since DNS is UDP? Couldn't you just forge packets from likely dns hosts that the victims might use and just constantly send responses hoping that the victim makes a request for one of the hosts you are forging responses for, and maybe one of the packets beats the real response and gets parsed? Is there a sequence number or unique request ID that gets used in UDP dns requests that is required in the response to be accepted as a response?
- lambda 9y agoThere is the UDP source port, which is where the reply will be sent, and a 16 bit ID number associated with each request. Randomizing both of these gives you 32 bits of entropy, which would makes spoofing attacks a lot harder. There were a lot of systems vulnerable to such attacks before source port randomization and ID randomization became common to mitigate such attacks. https://en.wikipedia.org/wiki/DNS_spoofing https://en.wikipedia.org/wiki/DNS_spoofing Of course, for this attack, you may only need to get the source port to match, since if it's the DNS resolver that has the bug, it may parse the whole response before noticing that the ID doesn't match. And some NATs may break source port randomizaiton, since they allocate their own source ports to keep a table of their source port to the internal IP and source port; if they do so in a more predictable manner, it may be relatively easy to spam them with packets, or you could just spam the whole 65536 bit range with bad packets.
- cesarb 9y ago> Is there a sequence number or unique request ID that gets used in UDP dns requests that is required in the response to be accepted as a response? Yes, there is, but it's only 16 bits, so it can be guessed, as was shown a decade ago with the "Kaminsky vulnerability" (giving names to vulnerabilities is not a new thing). A workaround is to also randomize the source port, so the attacker has to guess both the query ID and the source port used for the request. The true fix for the "Kaminsky vulnerability" would be to use DNSSEC, since even if the attacker spoofs the DNS response, they can't spoof the DNSSEC signature. Yes, this buffer overflow is in code added precisely to protect against an attacker forging DNS responses. Ironic, isn't it?