3 ms·

> spoof sensitive DNS records, resulting in varying consequences from credential theft to full Active Directory domain compromise It sounds insane to me that t

> 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.
- sonicanatidae 3y ago
  >I would think in a typical AD domain that was built using reasonably good practices One would think that, but I literally cannot enumerate the number of Domains that were setup by...let's just say, people that had no business setting up domains. Default settings are partially defined during the install.
- jiggawatts 3y ago
  Unfortunately the security defaults haven’t meaningfully changed since 2003! The more advanced protections introduced over the last two decades are mostly off by default. As a random example, a trust established between two AD forests using only Windows Server 2022 domain controllers will default to RC4 encryption instead of AES! It takes a lot of thankless work to properly secure an AD domain, and often it’s a impossible task because of incompatibilities with - checks list - Microsoft software released as recently as 2020.
  - sonicanatidae 3y ago
    This man/woman/smallanimal SysAdmins!
uxp8u61q 3y ago
Are you aware of how letsencrypt operates, for example? With a single spoofed dns record, you can get an https certificate. A whole lot of infrastructure relies on DNS for security.
- morelisp 3y ago
  You need to spoof at least three records (for the same domain) to get a certificate.
  - deathanatos 3y ago
    …no? Or what are the other two records? If I can control example.com, I can use an http-01 challenge to obtain a cert for example.com. I can't do a dns-01 challenge (that would require _acme-challenge records, although even then, I'm still up to 2, not 3, records), but I don't have to do a necessarily have to do a dns-01 just to get a cert…
    - Arnavion 3y ago
      Even in the dns-01 case you only need the one _acme-challenge record to *get* the cert. You only need more records to be able to do something meaningful with your cert, eg A/AAAA records that point to your malicious server and serve that cert.
      - EAtmULFO 3y ago
        Best practice is to use CAA records, which would help reduce the impact unless the CAA specifies letsencrypt.
        jiggawatts 3y ago
        It’s a terrible practice designed to build a moat for billion-dollar corporations feeling scared of free Let’s Encrypt certificates turning off the money printer.
MPSimmons 3y ago
>It sounds insane to me that the security of anything would depend on the validity of a DNS record Ahem. "The /etc/exports Configuration File" - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports https://access.redhat.com/documentation/en-us/red_hat_enterp...

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.

sonicanatidae 3y ago
>I would think in a typical AD domain that was built using reasonably good practices One would think that, but I literally cannot enumerate the number of Domains that were setup by...let's just say, people that had no business setting up domains. Default settings are partially defined during the install.
jiggawatts 3y ago
Unfortunately the security defaults haven’t meaningfully changed since 2003! The more advanced protections introduced over the last two decades are mostly off by default. As a random example, a trust established between two AD forests using only Windows Server 2022 domain controllers will default to RC4 encryption instead of AES! It takes a lot of thankless work to properly secure an AD domain, and often it’s a impossible task because of incompatibilities with - checks list - Microsoft software released as recently as 2020.
- sonicanatidae 3y ago
  This man/woman/smallanimal SysAdmins!

uxp8u61q 3y ago

Are you aware of how letsencrypt operates, for example? With a single spoofed dns record, you can get an https certificate. A whole lot of infrastructure relies on DNS for security.

morelisp 3y ago
You need to spoof at least three records (for the same domain) to get a certificate.
- deathanatos 3y ago
  …no? Or what are the other two records? If I can control example.com, I can use an http-01 challenge to obtain a cert for example.com. I can't do a dns-01 challenge (that would require _acme-challenge records, although even then, I'm still up to 2, not 3, records), but I don't have to do a necessarily have to do a dns-01 just to get a cert…
  - Arnavion 3y ago
    Even in the dns-01 case you only need the one _acme-challenge record to *get* the cert. You only need more records to be able to do something meaningful with your cert, eg A/AAAA records that point to your malicious server and serve that cert.
    - EAtmULFO 3y ago
      Best practice is to use CAA records, which would help reduce the impact unless the CAA specifies letsencrypt.
      - jiggawatts 3y ago
        It’s a terrible practice designed to build a moat for billion-dollar corporations feeling scared of free Let’s Encrypt certificates turning off the money printer.

MPSimmons 3y ago

>It sounds insane to me that the security of anything would depend on the validity of a DNS record Ahem. "The /etc/exports Configuration File" - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports https://access.redhat.com/documentation/en-us/red_hat_enterp...