Active Directory DNS server security misconfiguration or an acceptable practice?

Question

I work for a large Eastern European bank as a programmer.

Recently, I was setting up a documentation website for my team. We came up with the host name, and now all we needed was to pick the best suitable zone for it and send a request to IT support team to create a new DNS record.

So, I fired up PowerShell and loaded DnsServer module to list available DNS zones (I was unaware at the time, that ordinary users, generally, can not enumerate anything on AD DNS server. Access SHOULD be denied by default).

The Get-DnsServerZone cmdlet promptly listed all available zones. I've picked one, and to make sure there were no similar host names in this zone, ran Get-DnsServerResourceRecord command too. Everything worked fine.

While I was at it, out of curiosity, I decided to explore "Add-*" commands too: Add-DnsServerResourceRecordA, Add-DnsServerResourceRecordCName etc. I did not expect these to work at all, but, to my great surprise, cmdlets did not throw errors - they completed successfully!!!

I've verified created records using Get-DnsServerResourceRecord and nslookup. Also ran same commands using non-privileged technical user account (which belongs only to DOMAIN\Users group and nothing else) and got same result: DNS records were added successfully. Looks like any authenticated user can create DNS records. This does not feel right.

The Question:

Is this an acceptable practice or a security misconfiguration? Should I report it?

(I have not reported it yet, because of lots of beaurocracy involved. Also I dont want to attract unneeded attention. We have quite unhealthy culture and broken communication here - this is a bank, after all).

Answer 1

This should definitely be reported to your CSO and/or his/her team.

Besides you being able to add DNS records, chances are good, that you can execute other commands as well to manipulate the DNS configuration. From my experience it is better to report findings like this fast.

If the network administrators in charge notice the alterations that you have made, they will most likely be able to trace them back to you. If you have not reported this incident to them by then (or even in a timeframe that acceptably small), this will put you in a far worse light than reporting the issue in the first place.

Answer 2

UPDATE: I reported this issue to the Microsoft Security Response Center (Case 91434 on 24/9/2024). They responded on 5/11/2024 as follows (emphasis as in original):

Thank you again for submitting this issue to Microsoft. Although your report is valid, currently, MSRC prioritizes vulnerabilities that are assessed as “Important” or “Critical” severities for immediate servicing. After careful investigation, this case is rated as Moderate severity and does not meet MSRC’s current bar for immediate servicing. This is because the wildcard record in DNS which will cause all unknown domains to go to the attackers machine does not allow targeted spoofing.

However, we have shared the report with the team responsible for maintaining the product or service. They will take appropriate action as needed to help keep customers protected.

Original answer:

All newly-created Active Directory Integrated forward and reverse DNS zones include the following entry by default in their DACL, at least up to Windows Server 2022:

Principal: Authenticated Users (S-1-5-11)
Access: Create all child objects

It has been noted by The Hacker Recipes, NetSPI, and GoSecure that this represents a potential vulnerability - it is possible for any user in the domain/forest to add and control a new DNS record (so long as it doesn't exist already) with an arbitrary name, including a new wildcard record, using a simple LDAP request, or a dynamic DNS update request.

It can be mitigated by removing the above DACL; however, it is not a supported configuration, so you may experience issues. In particular, if you need secure dynamic updates to operate (e.g. for Active Directory Domain Join), you should also probably consider adding the following Allow entries in its place:

Principal: <DOMAINNAME>\Domain Computers
Access: Create all child objects

Principal: <DOMAINNAME>\Read-only Domain Controllers
Access: Create all child objects

Also, if you have configured any Windows DHCP Servers to use dedicated service accounts to update DNS records for clients (not the default), you should also give those service accounts the above permissions. However you will also need to mitigate against another related vulnerability in Windows DHCP servers when the default option allowing dynamic updates of DNS records on behalf of clients is enabled.

Answer 3

Authenticated users by default have the create child object permission. Removing this breaks ddns.

Related Technet post