|
HACK REPORT
DOMAIN_CREATE_ALIAS vulnerability
SUMMARY: The default protection on the Windows NT Domain allows Everyone the right to create Local Groups (known as aliases) on the Domain Controller. The access right on the Domain object is known as the DOMAIN_CREATE_ALIAS.
TARGET: Windows NT 3.51/4.0 server (Primary Domain Controller)
TYPE: Denial of Service
DATE: Documented since Windows NT 3.1
CODE: QBasic script was used but any language with looping structure will work
SOURCE: "net localgroup [groupname] /add /domain"
ATTACKER: Windows NT 3.1 to 4.0 Workstation or Server
FIX: CREATALS.EXE available from Microsoft
|
Like this year's Oscar-blowout Titanic, the hack we're unveiling this week is an old Windows NT vulnerability resurrected and remastered by the InfoWorld Test Center's security team. And now it's bigger and badder than before. The hack was originally brought to our attention by an InfoWorld reader who administers a large NT site.
The DOMAIN_CREATE_ALIAS vulnerability allows users with an account on an NT domain to freely create Local Groups on the domain. Although the reader who reported this hole received a different explanation from Microsoft support personnel than we did, Microsoft indicated to us that the purpose of this capability was to simplify security management. A user can put other users into a group and assign access to resources based on membership in that group. For example, the marketing manager can create a marketing group, put all the marketing staff in the group, and then give access to a sensitive marketing document only to this group. Access Control Lists need only be set for assigning resources to the group and not to each individual user. The command syntax is simple: net localgroup [groupname] /add /domain.
Microsoft confirmed this has been a documented NT feature since Version 3.1 and the company wrote a utility called CREATALS.EXE to restrict this ability to administrator-defined accounts. But CREATALS.EXE has not been made available to the public: Users must request it directly from Microsoft.
Microsoft also recommends considering obvious security steps, such as implementing a sound personnel policy for effective control of internal threats, keeping the Domain Controller (DC) physically secure, and turning on auditing for objects/events on the DC.
Administrators of high-security sites can consider limiting DC access from the network altogether by disabling "Access this computer from the network" for the Everyone group in User Manager. (But this drastic step should only be considered when the DC is used solely for authentication functions, as it will obviously restrict access to application and file and print services on the DC.)
How can this seemingly insignificant capability lead to problems? We discovered that if you create enough Local Groups on a DC, the Security Accounts Manger (SAM) database simply runs out of space and the whole system grinds to a halt. Registry size can be increased in the System Control Panel, but that's little consolation when you find thousands of used and unused groups on your server to get rid of.
Needless to say, performance and management was severely hampered in our tests of this problem (thus we're classifying this hack as a Denial of Service attack). Your first warning sign is the Event Log error message 12288, meaning your registry and SAM is running out of resources.
What's even more alarming is the ease with which an inexperienced user could automate this process to silently create millions of Local Groups in the space of a few hours. For example, this simple Quick Basic program we wrote would do the trick:
DIM var AS INTEGER
DIM hack1 AS STRING
DIM hack2 AS STRING
DO WHILE var < 10000000
var = var + 1
hack1 = "hack" + LTRIM$(STR$ (var))
hack2 = "net localgroup " + hack1 + " /add /domain"
SHELL hack2
LOOP
For further reading on NT security in general, we recommend a recently released step-by-step prescription for hardening security at NT sites compiled by SANS (System Administration, Networking, and Security), a cooperative research and education organization. The DOMAIN_CREATE_ALIAS isn't covered in the guide, but it is an otherwise solid outline of the details to consider when securing NT installations.
|
![[Security Watch]](/pageone/hedrgifs/clsecurity.gif)
