5 ms·

Microsoft seems to either ignore the security repercussions of their design decisions, or more cynically, they deliberately introduce attack vectors. Without d

Microsoft seems to either ignore the security repercussions of their design decisions, or more cynically, they deliberately introduce attack vectors. Without details (because the article has withheld them), but given the title and overview, this attack makes use of Microsoft's "extensions" to the DHCP protocol that allow updates to DNS records from hosts with dynamically assigned IP addresses. This began as a Windows only thing, but it's now supported by some other DHCP servers as well. It always seemed odd and wrong to me that DNS could be updated as a result of a DHCP assignment. IMHO the correct way to do this (assuming dynamic address assignment is desired), is via DHCP reservation. The admin would (manually) choose an IP address for a particular host's MAC address, and also (manually) add a permanent DNS record for the chosen IP address. Given the vast number of authentication features (such as SPF) that use domain as a key, it's a really bad idea to allow automated updates to domain records by unrelated services. As usual, the mitigation for this issue is to turn off the Microsoft "extension" that is enabled by default -- in this case it is DHCP DNS Dynamic Updates.

hsbauauvhabzb 3y ago
I too find it odd that TLS implicitly relies on DNS (ACME from letsencrypt). If someone controls your DNS they can get signed certificates. I’m optimistic letsencrypt validate dns via multiple streams (to prevent BGP hijacking) but I’ve got no evidence or proof. But that also doesn’t solve a breach of your nameservers (Godaddy has been breached) among other things. And before anyone mentions it, dnssec is dead, at least as far as I can tell.
- alwillis 3y ago
  DNSSEC isn’t dead; the graph of its deployment is what you’d want for any emerging technology: high and to the right [1]. The problem is DNSSEC is complicated to deploy for large organizations like Microsoft with hundreds of domains (and subdomains). Meanwhile, many domain registrars make it close to trivial to deploy DNSSEC for small and medium sized companies. [1]: https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0 https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0
- midasuni 3y ago
  Letsencrypt might but zerossl have suffered from BGP hacks before https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack https://therecord.media/klayswap-crypto-users-lose-funds-aft...
- btown 3y ago
  Let's Encrypt does validate via multiple streams: https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat... But even this is vulnerable if a strong adversary can make it seem like their compromised nameserver is the only reliable nameserver reachable over the network: https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Shulman-Lets-Attack-Lets_Encrypt.pdf https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Shulma... An analysis from early 2023 indicates LE's default setup was suboptimal compared to a multi-cloud quorum policy, which seems like a no-brainer at their scale IMHO: https://arxiv.org/abs/2302.08000 https://arxiv.org/abs/2302.08000
deleted 3y ago
[deleted]
autoexec 3y ago
I can't imagine how Microsoft would profit from making their DNS server vulnerable, but I also can't imagine how something like this could happen given how many people and stages of development it must have gone through. I'm sure they have security people reviewing this stuff, but things that readily appear to be terrible for security slip right on by.
- userbinator 3y ago
  given how many people and stages of development it must have gone through That's exactly the problem. The bigger the team, the less motivation there is for each individual to care about the big picture. This phenomenon can be witnessed whereever bureaucracy exists. More bluntly phrased, "shared responsibility is no responsibility". That said, I think in this case it's just a matter of these protocols being designed for and intended to be used in a network with high trust.
justsomehnguy 3y ago
> IMHO the correct way to do this (assuming dynamic address assignment is desired), is via DHCP reservation And how many end-user/dynamic hosts did you ever manage? And more importantly, why a l33t hax0r, who is already in the internal network, as he can send DHCP requests, can't impersonate a MAC address?
- anonymousiam 3y ago
  I've managed quite a few, but typically you would want your "trusted" hosts on a separate VLAN or subnet from untrusted ones. It's probably fine to leave DHCP DNS Dynamic Updates turned on as long as it's not updating a DNS server with control over any trusted domains. As you say, a host could spoof a MAC and get a reserved assignment, but only if the real host with that MAC is down. Again, isolating the security perimeters is the answer.

hsbauauvhabzb 3y ago

I too find it odd that TLS implicitly relies on DNS (ACME from letsencrypt). If someone controls your DNS they can get signed certificates. I’m optimistic letsencrypt validate dns via multiple streams (to prevent BGP hijacking) but I’ve got no evidence or proof. But that also doesn’t solve a breach of your nameservers (Godaddy has been breached) among other things. And before anyone mentions it, dnssec is dead, at least as far as I can tell.

alwillis 3y ago
DNSSEC isn’t dead; the graph of its deployment is what you’d want for any emerging technology: high and to the right [1]. The problem is DNSSEC is complicated to deploy for large organizations like Microsoft with hundreds of domains (and subdomains). Meanwhile, many domain registrars make it close to trivial to deploy DNSSEC for small and medium sized companies. [1]: https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0 https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0
midasuni 3y ago
Letsencrypt might but zerossl have suffered from BGP hacks before https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack https://therecord.media/klayswap-crypto-users-lose-funds-aft...
btown 3y ago
Let's Encrypt does validate via multiple streams: https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat... But even this is vulnerable if a strong adversary can make it seem like their compromised nameserver is the only reliable nameserver reachable over the network: https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Shulman-Lets-Attack-Lets_Encrypt.pdf https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Shulma... An analysis from early 2023 indicates LE's default setup was suboptimal compared to a multi-cloud quorum policy, which seems like a no-brainer at their scale IMHO: https://arxiv.org/abs/2302.08000 https://arxiv.org/abs/2302.08000

deleted 3y ago

[deleted]

autoexec 3y ago

I can't imagine how Microsoft would profit from making their DNS server vulnerable, but I also can't imagine how something like this could happen given how many people and stages of development it must have gone through. I'm sure they have security people reviewing this stuff, but things that readily appear to be terrible for security slip right on by.

userbinator 3y ago
given how many people and stages of development it must have gone through That's exactly the problem. The bigger the team, the less motivation there is for each individual to care about the big picture. This phenomenon can be witnessed whereever bureaucracy exists. More bluntly phrased, "shared responsibility is no responsibility". That said, I think in this case it's just a matter of these protocols being designed for and intended to be used in a network with high trust.

justsomehnguy 3y ago

> IMHO the correct way to do this (assuming dynamic address assignment is desired), is via DHCP reservation And how many end-user/dynamic hosts did you ever manage? And more importantly, why a l33t hax0r, who is already in the internal network, as he can send DHCP requests, can't impersonate a MAC address?

anonymousiam 3y ago
I've managed quite a few, but typically you would want your "trusted" hosts on a separate VLAN or subnet from untrusted ones. It's probably fine to leave DHCP DNS Dynamic Updates turned on as long as it's not updating a DNS server with control over any trusted domains. As you say, a host could spoof a MAC and get a reserved assignment, but only if the real host with that MAC is down. Again, isolating the security perimeters is the answer.