COMMAND
Domain_Create_Alias
SYSTEMS AFFECTED
Win NT 3.51, 4.0
PROBLEM
NT allows any user to create local groups on the domain
controller. This is meant to allow people to set access controls
easily. If not abused, it is a Good Thing. However, if you
create a LOT of groups, you'll fill up the registry, make the SAM
really huge, and crash the server. It will be a real PITA to
clean up the mess, too. The guys over at Infoworld thoughtfully
posted a BASIC script which allows any user (even users without a
brain) to use this feature to down an NT domain controller. Note
that all copies of NT come with a BASIC interpreter.
Example of this feature would be the marketing manager who 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.
Alarming thing 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 would do the trick:
DIM var AS INTEGER
DIM hack1 AS STRING
DIM hack2 AS STRING
DO WHILE var < 10000000
var = var + 1
hack1 = hack1 + LTRIM$(STR$ (var))
hack2 = "net localgroup" +
hack1 + " /add /domain"
SHELL hack2
LOOP
This will also replicate to the BDCs and take them down too.
Groups are SAM objects like anything else and need to be
replicated across BDCs (if you can promote a BDC to PDC then it
needs to contain everything that the PDC does SAM-wise). Once the
SAM grows, it does not automatically compact itself, and there is
no utility to do so. KB article:
http://support.microsoft.com/support/kb/articles/q140/3/80.asp
explains 3 methods that could be used to reduce the size of the
SAM after you have manually deleted all of the unwanted groups,
but none of them are quick or friendly. These extra SAM entries
also consume physical memory, so you don't need to completely fill
the SAM with wanton groups in order to create a problem for DCs
with limited RAM.
SOLUTION
Disabling the Domain_Create_Alias functionality for some users may
be a way to prevent the "vulnerability", but it does so at a loss
of expected functionality (meaning you need to think about just
who/what you are going to deny). Auditing gives you the details of
who did the dirty deed.
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. You
can download CREATALS.EXE from:
http://www.ntbugtraq.com/downloads/creatals.asp
If you have RestrictAnonymous=1 set in your registry and you run
the CREATALS.EXE program the result is that LSASS.EXE goes to
50/100% utilization and you will not be able to establish remote
connections to your PDC (not IIS, not Exchange, not DNS, not
nothing!). You will, however, still be able to operate from the
console. If this has already happened to you then you will need
to do the following;
- invoke regedt32
- goto hkey_local_machine\system\currentcontrolset\control\lsa
- change the value on RestrictAnonymous to 0
- shutdown and restart
LSASS will be back to normal once you've done this, but of course
you will also have disabled your RestrictAnonymous setting!
In the meantime, David LeBlanc wrote a little app to help with
this issue. It attaches to the security logs and watches for
someone adding new groups. If it sees 10 groups out of the same
user within an hour, it then disables the user's account and
tosses them off the server. His app can be had from:
http://www.ntbugtraq.com/downloads/groupmonitor.asp
USE AT YOUR OWN RISK.