I’ve been working on https://github.com/bluejekyll/trust-dns for a bit over two years now. About a year ago a new contributor added Windows build support and testing with AppVeyor, which was awesome.
Originally I started this project more for server side stuff, but recently have been very focused on a full resolver which could be used as a replacement for the OS system resolver.
A question for HN, what would you like to see in this context that would make a replacement resolver on Windows something you’d use? To be clear, it’s not something you could use dropin right now, it can only be used as an internal library to Rust at-the-moment, but I’ve been planning to start working on a daemon that could act as a caching system resolver in the next little bit.
I don't know about Windows, but on Linux, I would love to have a replacement for the entirety of NSS (and PAM, and other similar parts of the system) that ran in separate daemons rather than by loading shared objects into my process which could arbitrarily corrupt my process if they were buggy (which I have encountered before before).
To achieve that compatibly with existing systems, it would probably need to be able to act as an NSS module itself in order to be compatible with existing clients, and also be able to load NSS modules (hopefully in sandboxed, lower privileged processes) so it could support existing setups transparently, though it would be great to also have a better asynchronous interface so that you don't have to spawn thread or process pools for things like hostname resolution or fetching groups from LDAP.
On Linux, I'd really love a caching resolver that saves its cache persistently. I don't understand why the machine's power-on state has anything to do with the validity of the DNS cache; if the entries were good at shutdown time they ought to be good enough in a few seconds when I boot again.
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.
Would 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?
A 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.
It's been many, many years since I earned my MCSx certs and, fortunately, I rarely touch a Windows box these days so I am very likely wrong... but it seems to me that the following scenario is possible.
A domain controller also acts as a DNS server. "Forwarders" can be configured, or the DC can "go direct" and perform (recursive) resolution on a client's behalf. A client that could be convinced (should be relatively easy?) to issue a certain DNS request (which would be sent to the DC) would cause a malicious response (assuming a malicious authoritative DNS server) to be sent to the DC. In the case where the DC is an affected (unpatched) Windows 2012 server, this would result in a compromise of the DC.
Sounds feasible, in theory. I don't know enough about this issue to say for certain, though.
[+] [-] bluejekyll|8 years ago|reply
Originally I started this project more for server side stuff, but recently have been very focused on a full resolver which could be used as a replacement for the OS system resolver.
A question for HN, what would you like to see in this context that would make a replacement resolver on Windows something you’d use? To be clear, it’s not something you could use dropin right now, it can only be used as an internal library to Rust at-the-moment, but I’ve been planning to start working on a daemon that could act as a caching system resolver in the next little bit.
[+] [-] lambda|8 years ago|reply
To achieve that compatibly with existing systems, it would probably need to be able to act as an NSS module itself in order to be compatible with existing clients, and also be able to load NSS modules (hopefully in sandboxed, lower privileged processes) so it could support existing setups transparently, though it would be great to also have a better asynchronous interface so that you don't have to spawn thread or process pools for things like hostname resolution or fetching groups from LDAP.
[+] [-] gue5t|8 years ago|reply
[+] [-] rando444|8 years ago|reply
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.
[+] [-] tyingq|8 years ago|reply
[+] [-] benkillin|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] stephengillie|8 years ago|reply
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.
[+] [-] jlgaddis|8 years ago|reply
A domain controller also acts as a DNS server. "Forwarders" can be configured, or the DC can "go direct" and perform (recursive) resolution on a client's behalf. A client that could be convinced (should be relatively easy?) to issue a certain DNS request (which would be sent to the DC) would cause a malicious response (assuming a malicious authoritative DNS server) to be sent to the DC. In the case where the DC is an affected (unpatched) Windows 2012 server, this would result in a compromise of the DC.
Sounds feasible, in theory. I don't know enough about this issue to say for certain, though.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] j_s|8 years ago|reply
Behind the Masq: Yet More DNS and DHCP Vulnerabilities | https://news.ycombinator.com/item?id=15383574 (Oct 2017, 117 comments)
[+] [-] KekDemaga|8 years ago|reply
Programmer one: "It keeps crashing!"
Programmer two: "Just remove the bit that tells the user it crashed and ship it!"
[+] [-] dpark|8 years ago|reply