7 ms·

Spoofing DNS records by abusing DHCP DNS dynamic updates

191 points by Terretta 3y ago

andridk 3y ago
I never would have guessed that so many data centers ran their DHCP off of Microsoft Windows.
- noobface 3y ago
  Active Directory and DHCP go hand-in-hand. Your Domain Controllers aren't always your DHCP servers, but under a certain scale, they very likely are.
  - forgotusername6 3y ago
    If you create a brand new domain, it will automatically configure it to be the DHCP server by default.
    - blakes 3y ago
      That's true of DNS, not DHCP. One has to specifically install the DHCP role in a new AD domain.
  - EvanAnderson 3y ago
    I'm a 20+ year Windows sysadmin and I don't buy it. If you'd said "Active Directory and DNS go hand-in-hand" I'd agree-- the coupling there is pretty tight (and it's a pain-in-the-ass to run Active Directory with non-Microsoft DNS servers being authoritative for the AD domain name). DHCP is a lot less tightly coupled.
- nfeutry 3y ago
  I find this number also very surprinsing but it's not really 40% of datacenter, it's 40% of the networks monitored by Akama
  - 9dev 3y ago
    Yeah, I thought that too. Akamai seems to be popular with corporations.
- krylon 3y ago
  Microsoft's Active Directory, DHCP server, and DNS server integrate very closely. When a domain member gets a dynamic IP address, the DHCP server will inform the DNS server to update its record for that host. Many companies are, let's say a bit lazy - when use an Active Directory domain anyway, you might as well use the DHCP and DNS servers, too, they handle replication and failover very smoothly. (I am not a big fan of Windows, but that part has worked pretty well in my experience.) You can get a similar mechanism to work between BIND and ISC DHCPD; it's not a lot of work, but with Zeroconf/mDNS it is less useful than it used to be.
- Terretta 3y ago
  Not the colo themselves running it, "in" datacenters. And more accurately, in networks in datacenters. Colocation means many clients, and in any given colo there's almost certainly someone running a Windows AD + Microsoft DHCP box, meaning it's "in" that datacenter. I'm surprised as many as 40% of networks still have that tech, but that's enterprise for you. Point being, though, it's likely in well more than 40% of datacenters.
- irq-1 3y ago
  In the 90s Microsoft tied their dominant Exchange/Outlook to Active Directory which depends on DNS/DHCP.
  - steve1977 3y ago
    Active Directory was officially only released in 2000 though.
- alacode 3y ago
  Microsoft and Google together are trying to control the largest spectrum of computer usage globally.
rafaelturk 3y ago
40% of datacenters? Akamai are you serious about your marketing stunts?
- forbiddenlake 3y ago
  The HN title[1] was editorialized. The actual figure, used twice in the article, specifies it is talking about data center networks monitored by Akamai. [1] As of this comment: "Spoofing DNS records abusing Microsoft DHCP server running in 40% of datacenters"
  - Terretta 3y ago
    I'd argue it's more likely to be in a datacenter than in 40% of data center networks, since if even one network in the colo ran it, that would mean it was in that datacenter. Remember, this isn't server share, it's share of DCs that have even one Windows Server with AD and Microsoft DHCP. For large commercial colos, you can assume that's effectively 100% of colos. And with 85% of SMB being Microsoft shops, one can extrapolate for small colos, though we'd hope of that majority that are still on AD they either use Azure AD or run AD in the office and Linux in the colo.
- Terretta 3y ago
  If you think Windows Server isn't running in 40% of data centers, have I got news for you.
  - krylon 3y ago
    I don't like it very much, but every single small-to-medium non-IT company I have seen runs on Windows. Sometimes they require Windows specifically because of third-party software (SCADA/industrial automation for example), more often it's just that Windows is the "default" that people know and use, due to network effects.
  - robertlagrant 3y ago
    Indeed - it doesn't take much to be in a datacentre. One server in thousands could be running it and it's "in the datacentre".
0xbadcafebee 3y ago
> spoof sensitive DNS records, resulting in varying consequences from credential theft to full Active Directory domain compromise It sounds insane to me that the security of anything would depend on the validity of a DNS record, but I vaguely remember that AD is extremely dependent on DNS configuration
- blincoln 3y ago
  I would think in a typical AD domain that was built using reasonably good practices (maybe even the default settings) in the last 5 (maybe even 10) years, DNS changes alone wouldn't be able to directly result in the compromise of any Microsoft products, or third-party products that authenticate against AD. One or more cryptographic mechanisms (TLS certificate verification, SMB signing, etc.) should prevent other devices from trusting the system with the spoofed name. That having been said, if the domain has relaxed security to support legacy systems, or was built 20 years ago and incrementally upgraded to newer Windows versions ever since, this technique seems like it could be used to compromise the domain. For example, if NTLM auth is enabled, but signing is not required, it seems like this would allow a network-wide version of NTLM relaying attacks. Those are usually done using subnet-specific name spoofing, so it would be a big increase in scope. Additionally, in most large enterprise environments, there will be at least a few third-party products that are set up (deliberately or by default) to operate in a way that could be exploited using this technique. Web applications that authenticate using cleartext HTTP, network appliances with telnet or other unencrypted sevices, email that's exchanged over cleartext SMTP, etc., on the assumption that an attacker would have to already have privileged access to something to capture the information sent over that channel. I suspect there would usually be a way to exploit one of those things in a way that would eventually lead to compromise of the AD domain. e.g. the organization uses Cisco network hardware configured to back up their configurations to a TFTP server every night. The attacker exploits the DHCP DNS vulnerability to pretend to be the TFTP server and captures the device configurations. They decrypt reversibly-encrypted network appliance administrator passwords, or crack the hashes if they're stored in a non-reversible format. Then they use those credentials to alter the TACACS configuration on one or more network devices to send credentials to their own system when someone tries to log on. TACACS is set up to authenticate to AD, so now the attacker has a bunch of AD credentials that belong to network administrators.
tsujamin 3y ago
Adding the ‘*’ record to ADIDNS during a penetration test and watching auth attempts for mistyped domains roll in is always good fun
candiddevmike 3y ago
How are folks managing AD users and computers with so many remote employees? Does AD still have value vs a more decentralized "BYOD" approach, especially with heterogenous OSs? AD used to be the lynchpin for policies and SSO via GP, NTLM and file shares, but these days those are all web apps or cloud drives and AD has little control over them.
- tenebrisalietum 3y ago
  SAML extends AD-based authentication to any external app/service that can use it.
  - candiddevmike 3y ago
    Sure, ADFS has been a thing for forever, but I don't think that is a good value prop for AD. Most online office suites and SSO platforms can provide SAML, and with a nicer way of managing users and groups.
    - robertlagrant 3y ago
      AD is like Jira: it's not great, but loads of things integrate with it. You can do SAML or OIDC for more modern logins, and you can speak LDAP/AD for other systems, and all your Windows logins will just work. Also, your skills acquired 20 years ago on AD are still relevant, which is why as an IT head you'll probably stick with AD.
      - steve1977 3y ago
        Not that SAML or OIDC are actually any better. They’re a bit like YAML or JSON vs XML in my experience.
- Unfrozen0688 3y ago
  Office 365 + Azure AD/Entra + onprem sync + Intune
kramerger 3y ago
> We reported our findings to Microsoft, but a fix is not planned. The old Microsoft is back then?
- stackskipton 3y ago
  As former Windows Sysadmin, any fix is likely to break environments and Microsoft doesn't want to deal with it. DHCP feature was legacy thing for NT4 migrations but Microsoft never turned it off because almost no sysadmins know what they are actually doing. Fix seems to be just disable DHCP DNS registration. Also, Microsoft is over Windows Server environments. They have gone full cloud and could care less about Windows OSes. They continue to develop them but it's clear it's switched from critical business unit to a side business for them.
  - jahsome 3y ago
    As they should. I wish Windows Server a swift and excruciating death. That's unfair. I actually don't hate Windows Server in and of itself, but I loathe the way people use it, and I dare say they're encouraged to do so. I think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration. Why bother expanding your skills, when everything you need is just an RDP and EXE away! Windows Server is to system administration as WordPress is to software engineering. It's extremely powerful for beginners and it'll _probably_ work for a good chunk of what people want. Both are often driven by incessant manual tweaking, until one day it finally works, and then hoping no one makes a sudden movement. And good luck consistently replicating any effort from one environment to another in either case. However easy it might _seem_ easy at first, it's very quickly going to start hurting. And of course there are "correct" ways of doing them both, but: why on Earth would you bother when it's so damn easy to do it the naughty way?
    - steve1977 3y ago
      > think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration. I have been out of Windows systems engineering for a while, but this was certainly not the case say 20 years ago. The operating systems and best practices were well documented (via official Microsoft Press books) and back then MCSE certification actually let you learn some in depth stuff (if you wanted to).
ksjskskskkk 3y ago
if you know all you can do with a default AD install, you won't even bother with dns poisoning.
arcza 3y ago
Pretty much a non story and hence MS didn't bother entertaining Akamai's rage bait post here. A lot more things can go wrong with a default AD install as others said. Yawn.
- spookie 3y ago
  Ever the more reason to fix it? It sounds as if nothing is fixed if it is _that_ bad.
- overstay8930 3y ago
  Akamai acting like they wouldn't go immediately bankrupt if they didn't have those sweet government contracts, I do not miss working with them
pbhjpbhj 3y ago
Actual title for me: "Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates". A "by" in the title is necessary IMO.
- Terretta 3y ago
  Narrowing to Microsoft AD DHCP seemed MUCH more important.
  - dang 3y ago
    If you want to say what you think is important about an article, that's fine, but please do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so... "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - Terretta 3y ago
      I was thinking specifically of this rule. Their original title was misleading, implying broader scope, all dynamic DHCP. Narrowing to saying Microsoft DHCP seemed less misleading and less click-bait. I could picture a pile of conversation saying "oh, this is just X" so tried to narrow it to just X. From your comment, I take it I saw it wrong. Just saying that rule was my specific reason for the edit, to make less click-bait and less misleading.
      - dang 3y ago
        If you were thinking of the rule and trying to abide by it, that's more than enough! This domain (titles etc.) is complex enough that it's totally normal for people to interpret the rule differently.
  - nullindividual 3y ago
H8crilA 3y ago
Another fun exercise is to announce IPv6 in a network that's designed to be IPv4 only (IPv6 is announced via its own protocol rather than via DHCP, though you can also use DHCPv6 if you want to). High chances that the switches will not drop the announcement and that hosts will configure IPv6, then try to use it without the user knowing.
- CaliforniaKarl 3y ago
  Your post is incomplete. Instead of saying "announce IPv6", it might be better to say "announce IPv6 with SLAAC" or "announce SLAAC-supporting IPv6". If, in the Route Announcements, you enable the M flag, then that disables SLAAC on your subnet, forcing folks to use DHCPv6 for an IP allocation (or use a static IPv6 address). Besides, that "fun exercise" is what ISPs often do: For example, Comcast turned on IPv6 without any warning (at least, no warning pushed to customers). In my case, I (the user) didn't notice it was in use until I checked, which I think is exactly how it is supposed to work for the end-user.
- kokx 3y ago
  As a pentester that did exactly this in many corporate networks: this is extremely effective. Just announce with a router advertisement that there is a DHCPv6 server and start handing out link-local IPv6 addresses while you specify your own system as DNS-server. Clients (both Windows and Linux) will prefer the DNS-server specified through IPv6 over the one from IPv4. Then you can spoof any DNS record and capture juicy NTLM hashes flying through the network or relay their authentication and get a free authenticated connection. This is most effective in networks that were designed for only IPv4 and didn't consider IPv6 at all. But it is also effective in some networks that do use IPv6. Mitigations? Either disable the IPv6-stack on all systems, or configure your switches to block the router advertisements and do not allow DHCPv6 traffic to the wrong systems.
mise_en_place 3y ago
NetBIOS needs to go away. It made sense when computers were linked up in a token ring setup. There are way better and more modern/secure methods of service discovery.
anonymousiam 3y ago
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
efitz 3y ago
How is this less secure than MDNS? Asking for a friend.
efitz 3y ago
I worked in Microsoft support for domains and security from the mid 90s through the launch of Windows 2000. I haven't worked for Microsoft in more than a decade and I don't speak for them; I'm just recollecting. Many of you may be too young to remember, but TCP/IP did not really come to dominate corporate networking until the mid-late 90s. Before that, Novell had the IPX/SPX protocol suite and Microsoft had NetBEUI. These protocols solved name resolution via broadcast (although NetBEUI morphed into NetBIOS over TCP/IP [NBT] and gained a server-based name resolver, WINS, which people have the same complaints about). For early adopters of Active Directory, one of the biggest problems they had was that TCP/IP was new to them, and as often happens in corporations, the people who had Windows AD expertise had no authority over their enterprise DNS, and the people who controlled enterprise DNS had no Windows expertise. Support calls due to inability to locate a Windows resource in DNS were some of the most common, and were therefore one of the bigger identifiable costs of supporting Windows. The Windows team had predicted all this (and also predicted that Windows 2000 would be the first introduction of TCP/IP into many smaller corporate networks and therefore they couldn't count on having DNS and DHCP already present), and they built AD-integrated DNS and DHCP and included it with Active Directory. Microsoft didn't invent DNS or DHCP obviously, and of course at the protocol level both of them are insecure. But so was everything else on corporate LANs at the dawn of the internet and for years after. Having AD-integrated DNS and DHCP meant that literally you could boot a server with the Windows 2000 CD and install Windows and during the creation of Active Directory, you could select to have Windows install DNS and DHCP for you, giving you a turnkey TCP/IP network. Windows DHCP could be configured to issue addresses and then take the broadcast name (remember NBT?) and populate DNS with it, making it easy for DNS name resolution to work and solving the other frequent support issue of not being able to resolve names via broadcast on segmented/routed networks. Of course now all this looks hopelessly archaic, but all of the decisions were rational at the time they were made. The problem now is that many Microsoft customers still use the really old features, they can't migrate off them for one reason or other, usually due to compatibility of some obscure app or other, or just due to costs. Of course the "secure" solution to DNS is for an admin to manually create all the records, and use DHCP reservations. Most companies don't want to expend that effort, except for security sensitive machines. In AD, the really critical records (SRV records) have ACLs that protect them from abuse. So mostly client machines get the dynamic DHCP treatment.
cryptonector 3y ago
NTLM has to die. And yes, I'm aware that MSFT is working on it.

191 points by Terretta 3y ago

andridk 3y ago

I never would have guessed that so many data centers ran their DHCP off of Microsoft Windows.

noobface 3y ago
Active Directory and DHCP go hand-in-hand. Your Domain Controllers aren't always your DHCP servers, but under a certain scale, they very likely are.
- forgotusername6 3y ago
  If you create a brand new domain, it will automatically configure it to be the DHCP server by default.
  - blakes 3y ago
    That's true of DNS, not DHCP. One has to specifically install the DHCP role in a new AD domain.
- EvanAnderson 3y ago
  I'm a 20+ year Windows sysadmin and I don't buy it. If you'd said "Active Directory and DNS go hand-in-hand" I'd agree-- the coupling there is pretty tight (and it's a pain-in-the-ass to run Active Directory with non-Microsoft DNS servers being authoritative for the AD domain name). DHCP is a lot less tightly coupled.
nfeutry 3y ago
I find this number also very surprinsing but it's not really 40% of datacenter, it's 40% of the networks monitored by Akama
- 9dev 3y ago
  Yeah, I thought that too. Akamai seems to be popular with corporations.
krylon 3y ago
Microsoft's Active Directory, DHCP server, and DNS server integrate very closely. When a domain member gets a dynamic IP address, the DHCP server will inform the DNS server to update its record for that host. Many companies are, let's say a bit lazy - when use an Active Directory domain anyway, you might as well use the DHCP and DNS servers, too, they handle replication and failover very smoothly. (I am not a big fan of Windows, but that part has worked pretty well in my experience.) You can get a similar mechanism to work between BIND and ISC DHCPD; it's not a lot of work, but with Zeroconf/mDNS it is less useful than it used to be.
Terretta 3y ago
Not the colo themselves running it, "in" datacenters. And more accurately, in networks in datacenters. Colocation means many clients, and in any given colo there's almost certainly someone running a Windows AD + Microsoft DHCP box, meaning it's "in" that datacenter. I'm surprised as many as 40% of networks still have that tech, but that's enterprise for you. Point being, though, it's likely in well more than 40% of datacenters.
irq-1 3y ago
In the 90s Microsoft tied their dominant Exchange/Outlook to Active Directory which depends on DNS/DHCP.
- steve1977 3y ago
  Active Directory was officially only released in 2000 though.
alacode 3y ago
Microsoft and Google together are trying to control the largest spectrum of computer usage globally.

rafaelturk 3y ago

40% of datacenters? Akamai are you serious about your marketing stunts?

forbiddenlake 3y ago
The HN title[1] was editorialized. The actual figure, used twice in the article, specifies it is talking about data center networks monitored by Akamai. [1] As of this comment: "Spoofing DNS records abusing Microsoft DHCP server running in 40% of datacenters"
- Terretta 3y ago
  I'd argue it's more likely to be in a datacenter than in 40% of data center networks, since if even one network in the colo ran it, that would mean it was in that datacenter. Remember, this isn't server share, it's share of DCs that have even one Windows Server with AD and Microsoft DHCP. For large commercial colos, you can assume that's effectively 100% of colos. And with 85% of SMB being Microsoft shops, one can extrapolate for small colos, though we'd hope of that majority that are still on AD they either use Azure AD or run AD in the office and Linux in the colo.
Terretta 3y ago
If you think Windows Server isn't running in 40% of data centers, have I got news for you.
- krylon 3y ago
  I don't like it very much, but every single small-to-medium non-IT company I have seen runs on Windows. Sometimes they require Windows specifically because of third-party software (SCADA/industrial automation for example), more often it's just that Windows is the "default" that people know and use, due to network effects.
- robertlagrant 3y ago
  Indeed - it doesn't take much to be in a datacentre. One server in thousands could be running it and it's "in the datacentre".

0xbadcafebee 3y ago

> spoof sensitive DNS records, resulting in varying consequences from credential theft to full Active Directory domain compromise It sounds insane to me that the security of anything would depend on the validity of a DNS record, but I vaguely remember that AD is extremely dependent on DNS configuration

blincoln 3y ago
I would think in a typical AD domain that was built using reasonably good practices (maybe even the default settings) in the last 5 (maybe even 10) years, DNS changes alone wouldn't be able to directly result in the compromise of any Microsoft products, or third-party products that authenticate against AD. One or more cryptographic mechanisms (TLS certificate verification, SMB signing, etc.) should prevent other devices from trusting the system with the spoofed name. That having been said, if the domain has relaxed security to support legacy systems, or was built 20 years ago and incrementally upgraded to newer Windows versions ever since, this technique seems like it could be used to compromise the domain. For example, if NTLM auth is enabled, but signing is not required, it seems like this would allow a network-wide version of NTLM relaying attacks. Those are usually done using subnet-specific name spoofing, so it would be a big increase in scope. Additionally, in most large enterprise environments, there will be at least a few third-party products that are set up (deliberately or by default) to operate in a way that could be exploited using this technique. Web applications that authenticate using cleartext HTTP, network appliances with telnet or other unencrypted sevices, email that's exchanged over cleartext SMTP, etc., on the assumption that an attacker would have to already have privileged access to something to capture the information sent over that channel. I suspect there would usually be a way to exploit one of those things in a way that would eventually lead to compromise of the AD domain. e.g. the organization uses Cisco network hardware configured to back up their configurations to a TFTP server every night. The attacker exploits the DHCP DNS vulnerability to pretend to be the TFTP server and captures the device configurations. They decrypt reversibly-encrypted network appliance administrator passwords, or crack the hashes if they're stored in a non-reversible format. Then they use those credentials to alter the TACACS configuration on one or more network devices to send credentials to their own system when someone tries to log on. TACACS is set up to authenticate to AD, so now the attacker has a bunch of AD credentials that belong to network administrators.

tsujamin 3y ago

Adding the ‘*’ record to ADIDNS during a penetration test and watching auth attempts for mistyped domains roll in is always good fun

candiddevmike 3y ago

How are folks managing AD users and computers with so many remote employees? Does AD still have value vs a more decentralized "BYOD" approach, especially with heterogenous OSs? AD used to be the lynchpin for policies and SSO via GP, NTLM and file shares, but these days those are all web apps or cloud drives and AD has little control over them.

tenebrisalietum 3y ago
SAML extends AD-based authentication to any external app/service that can use it.
- candiddevmike 3y ago
  Sure, ADFS has been a thing for forever, but I don't think that is a good value prop for AD. Most online office suites and SSO platforms can provide SAML, and with a nicer way of managing users and groups.
  - robertlagrant 3y ago
    AD is like Jira: it's not great, but loads of things integrate with it. You can do SAML or OIDC for more modern logins, and you can speak LDAP/AD for other systems, and all your Windows logins will just work. Also, your skills acquired 20 years ago on AD are still relevant, which is why as an IT head you'll probably stick with AD.
    - steve1977 3y ago
      Not that SAML or OIDC are actually any better. They’re a bit like YAML or JSON vs XML in my experience.
Unfrozen0688 3y ago
Office 365 + Azure AD/Entra + onprem sync + Intune

kramerger 3y ago

> We reported our findings to Microsoft, but a fix is not planned. The old Microsoft is back then?

stackskipton 3y ago
As former Windows Sysadmin, any fix is likely to break environments and Microsoft doesn't want to deal with it. DHCP feature was legacy thing for NT4 migrations but Microsoft never turned it off because almost no sysadmins know what they are actually doing. Fix seems to be just disable DHCP DNS registration. Also, Microsoft is over Windows Server environments. They have gone full cloud and could care less about Windows OSes. They continue to develop them but it's clear it's switched from critical business unit to a side business for them.
- jahsome 3y ago
  As they should. I wish Windows Server a swift and excruciating death. That's unfair. I actually don't hate Windows Server in and of itself, but I loathe the way people use it, and I dare say they're encouraged to do so. I think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration. Why bother expanding your skills, when everything you need is just an RDP and EXE away! Windows Server is to system administration as WordPress is to software engineering. It's extremely powerful for beginners and it'll _probably_ work for a good chunk of what people want. Both are often driven by incessant manual tweaking, until one day it finally works, and then hoping no one makes a sudden movement. And good luck consistently replicating any effort from one environment to another in either case. However easy it might _seem_ easy at first, it's very quickly going to start hurting. And of course there are "correct" ways of doing them both, but: why on Earth would you bother when it's so damn easy to do it the naughty way?
  - steve1977 3y ago
    > think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration. I have been out of Windows systems engineering for a while, but this was certainly not the case say 20 years ago. The operating systems and best practices were well documented (via official Microsoft Press books) and back then MCSE certification actually let you learn some in depth stuff (if you wanted to).

ksjskskskkk 3y ago

if you know all you can do with a default AD install, you won't even bother with dns poisoning.

arcza 3y ago

Pretty much a non story and hence MS didn't bother entertaining Akamai's rage bait post here. A lot more things can go wrong with a default AD install as others said. Yawn.

spookie 3y ago
Ever the more reason to fix it? It sounds as if nothing is fixed if it is _that_ bad.
overstay8930 3y ago
Akamai acting like they wouldn't go immediately bankrupt if they didn't have those sweet government contracts, I do not miss working with them

pbhjpbhj 3y ago

Actual title for me: "Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates". A "by" in the title is necessary IMO.

Terretta 3y ago
Narrowing to Microsoft AD DHCP seemed MUCH more important.
- dang 3y ago
  If you want to say what you think is important about an article, that's fine, but please do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so... "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - Terretta 3y ago
    I was thinking specifically of this rule. Their original title was misleading, implying broader scope, all dynamic DHCP. Narrowing to saying Microsoft DHCP seemed less misleading and less click-bait. I could picture a pile of conversation saying "oh, this is just X" so tried to narrow it to just X. From your comment, I take it I saw it wrong. Just saying that rule was my specific reason for the edit, to make less click-bait and less misleading.
    - dang 3y ago
      If you were thinking of the rule and trying to abide by it, that's more than enough! This domain (titles etc.) is complex enough that it's totally normal for people to interpret the rule differently.
- nullindividual 3y ago

H8crilA 3y ago

Another fun exercise is to announce IPv6 in a network that's designed to be IPv4 only (IPv6 is announced via its own protocol rather than via DHCP, though you can also use DHCPv6 if you want to). High chances that the switches will not drop the announcement and that hosts will configure IPv6, then try to use it without the user knowing.

CaliforniaKarl 3y ago
Your post is incomplete. Instead of saying "announce IPv6", it might be better to say "announce IPv6 with SLAAC" or "announce SLAAC-supporting IPv6". If, in the Route Announcements, you enable the M flag, then that disables SLAAC on your subnet, forcing folks to use DHCPv6 for an IP allocation (or use a static IPv6 address). Besides, that "fun exercise" is what ISPs often do: For example, Comcast turned on IPv6 without any warning (at least, no warning pushed to customers). In my case, I (the user) didn't notice it was in use until I checked, which I think is exactly how it is supposed to work for the end-user.
kokx 3y ago
As a pentester that did exactly this in many corporate networks: this is extremely effective. Just announce with a router advertisement that there is a DHCPv6 server and start handing out link-local IPv6 addresses while you specify your own system as DNS-server. Clients (both Windows and Linux) will prefer the DNS-server specified through IPv6 over the one from IPv4. Then you can spoof any DNS record and capture juicy NTLM hashes flying through the network or relay their authentication and get a free authenticated connection. This is most effective in networks that were designed for only IPv4 and didn't consider IPv6 at all. But it is also effective in some networks that do use IPv6. Mitigations? Either disable the IPv6-stack on all systems, or configure your switches to block the router advertisements and do not allow DHCPv6 traffic to the wrong systems.

mise_en_place 3y ago

NetBIOS needs to go away. It made sense when computers were linked up in a token ring setup. There are way better and more modern/secure methods of service discovery.

anonymousiam 3y ago

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

efitz 3y ago

How is this less secure than MDNS? Asking for a friend.

efitz 3y ago

I worked in Microsoft support for domains and security from the mid 90s through the launch of Windows 2000. I haven't worked for Microsoft in more than a decade and I don't speak for them; I'm just recollecting. Many of you may be too young to remember, but TCP/IP did not really come to dominate corporate networking until the mid-late 90s. Before that, Novell had the IPX/SPX protocol suite and Microsoft had NetBEUI. These protocols solved name resolution via broadcast (although NetBEUI morphed into NetBIOS over TCP/IP [NBT] and gained a server-based name resolver, WINS, which people have the same complaints about). For early adopters of Active Directory, one of the biggest problems they had was that TCP/IP was new to them, and as often happens in corporations, the people who had Windows AD expertise had no authority over their enterprise DNS, and the people who controlled enterprise DNS had no Windows expertise. Support calls due to inability to locate a Windows resource in DNS were some of the most common, and were therefore one of the bigger identifiable costs of supporting Windows. The Windows team had predicted all this (and also predicted that Windows 2000 would be the first introduction of TCP/IP into many smaller corporate networks and therefore they couldn't count on having DNS and DHCP already present), and they built AD-integrated DNS and DHCP and included it with Active Directory. Microsoft didn't invent DNS or DHCP obviously, and of course at the protocol level both of them are insecure. But so was everything else on corporate LANs at the dawn of the internet and for years after. Having AD-integrated DNS and DHCP meant that literally you could boot a server with the Windows 2000 CD and install Windows and during the creation of Active Directory, you could select to have Windows install DNS and DHCP for you, giving you a turnkey TCP/IP network. Windows DHCP could be configured to issue addresses and then take the broadcast name (remember NBT?) and populate DNS with it, making it easy for DNS name resolution to work and solving the other frequent support issue of not being able to resolve names via broadcast on segmented/routed networks. Of course now all this looks hopelessly archaic, but all of the decisions were rational at the time they were made. The problem now is that many Microsoft customers still use the really old features, they can't migrate off them for one reason or other, usually due to compatibility of some obscure app or other, or just due to costs. Of course the "secure" solution to DNS is for an admin to manually create all the records, and use DHCP reservations. Most companies don't want to expend that effort, except for security sensitive machines. In AD, the really critical records (SRV records) have ACLs that protect them from abuse. So mostly client machines get the dynamic DHCP treatment.

cryptonector 3y ago

NTLM has to die. And yes, I'm aware that MSFT is working on it.