Thursday, August 18, 2005 5:17 AM bart

Why preparing security demos can hurt ... I killed lsass.exe by mistake :o

Tonight I was doing a little demo prep for security-related stuff in Windows Server 2003. One of the things I was preparing is the "service account credentials" problem. As you probably know, Windows services run in the context of a user (just like any other process does). Typically such a user is SYSTEM or Network Service or Local Service but it can also be a custom account specified by the user during installation of the service or via the services.msc MMC. The use of a custom account allows you to have better control over what the service is allowed to do (privileges, ACLs) and therefore can lead to better security (assuming you're not adding that account to the administrators or power users group of course, e.g. "for simplicity of configuration", oooh). Now, when you do specify such a custom service account, you also need to specify the password for that account. Windows needs to store that password somewhere locally on your machine, being the registry key HKLM\SECURITY.

Now your natural reaction should be: WinKey-R, regedit, My Computer, HKEY_LOCAL_MACHINE, SECURITY. You'll be disappointed I guess, nothing visible in there. Check the permissions of the key and you'll see that only the SYSTEM account has access to this key. Okay, you could go to the Permissions dialog window and grant the Administrators temporarily access to the key in order to look at the contents, but instead of doing this, I'd like to show another trick. Also notice that this sentence contains a very bad assumption because it implies that you are running as Administrator on the machine. However, for the sake of this demo I'm breaking the rules. Now the trick. Go to the command prompt and type the following commands:

C:\Documents and Settings\Administrator>net start Schedule
The requested service has already been started.

More help is available by typing NET HELPMSG 2182.


C:\Documents and Settings\Administrator>time /T
04:13 AM

C:\Documents and Settings\Administrator>at 04:14 /INTERACTIVE cmd.exe
Added a new job with job ID = 1

After (less than) a minute you should see a new Command Prompt window appearing in your interactive session. In fact, it won't have C:\Windows\System32\cmd.exe in its title bar, but you'll see C:\Windows\System32\svchost.exe instead. What's so special about this Command Prompt is that it's running in the context of the Task Scheduler service's account, being SYSTEM:

C:\WINDOWS\system32>whoami
nt authority\system

When you now start regedit through this prompt, it will inherit the security context of the parent process, being the cmd.exe shell hosted by svchost.exe running as SYSTEM. You can check this as follows:

C:\WINDOWS\system32>tasklist /FI "USERNAME eq NT AUTHORITY\SYSTEM" /FI "IMAGENAME eq regedit.exe"

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
regedit.exe                   4680 Console                    0      3,360 K

That should convince you, right? Now back to the Registry Editor where you can now open the HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets key because SYSTEM has access to this key.

In this very key Windows stores a lot of secrets that need to be kept in plaintext for further usage, including service account passwords. The store includes the machine's computer key in a domain (HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC), security information of various services (HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\_SC_*), Terminal Services Licensing keys (HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\L$TermServ*), ASP.NET auto-generated machine keys (HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\L$ASP.NETAutoGenKeys*), RAS dial parameters (HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\RasDialParams!S-1-5-21-99659525-1695905762-1439541511-500#0, the -500 suffix of the SID stands for the local Adminstrator accounts), cached password hashes for the last logons, web user passwords, FTP passwords.

Take a look in here carefully. From the list mentioned above, the _SC_* keys are the most interesting ones to us. For example, I have MIIS installed on my machine which runs as a service called "miiserver" with a custom service account. In the registry I can find the following key - HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\_SC_miiserver - containing security information for the service. Originally, Paul Ashton reported the LSA secrets problem on the Windows NT BuqTraq mailing list in August 1997 (link) with a basic exploit. A first thing I wanted to show is the fact that this code doesn't work anymore. However, the SYSTEM account still has access to the (obfuscated) data in some way, as the SCM needs the information in order to run the service correctly.

The moral of the story is pretty straightforward: a compromised local administrator can lead to a domain-wide attack by extracting the service account passwords that possible are domain accounts. Having such a domain account can be enough to launch a successful attack against the domain and other systems (servers, workstations) in that domain.

One tool that can be used nowadays to extract this information from the LSA Secret is the lsadump2 tool from Bindview. The code is included with the tool and gives you better insight in how this tool works (lsadump2.c). In big lines, the tool tries to find the lsass.exe (the local security authority subsystem) process, tries to enable debugging privileges (needed to run the tool), injects a dll into the process (dumplsa.dll compiled from dumplsa.c) and uses named pipes to communicate with the dll's functionality in order to print output to the screen. So basically, the tool hooks itself into the LSA in order to retrieve information directly from the source. The dumplsa.c file contains the source of the LSA dumping functionality (refer to the DumpLsa function which iterates through the HKLM\SECURITY\Policy\Secrets key and calls the LsarOpenSecret and LsarQuerySecret functions through direct function pointers obtained by GetProcAddress on the lsasrv.dll library). Try to run the tool yourself and be convinced of its power!

However, some things went wrong earlier this night. The tool - running on W2K3 SP1 - brough the lsass.exe process down, causing some weird system behavior. First of all, I got the well-known shutdown countdown dialog that says "This system is shutting down. Please save all work in progress and log off. Any unsaved changes will be lost. This shutdown was initiated by NT AUTHORITY\SYSTEM (...) Time before shutdown: 00:00:60" with the additional message: "The system process 'C:\WINDOWS\system32\lsass.exe' terminated unexpectedly with status code .... The system will now shut down and restart.". When you see this dialog, Start, Run, cmd, OK, shutdown /a, ENTER as fast as you can to cancel the system shutdown.

Also check out Mark Russinovich's article on "Running Windows With No Services" that was published in July this year. It has a screenshot of this "System Shutdown" countdown dialog.

The death of lsass.exe is just the beginning of a series of troubles in fact. After I saved my work, I tried to reboot the computer through Start, Shut Down, Restart, OK resulting in the following error message:

Right, lsass.exe is responsible for user privileges indeed and the privilege to shutdown the system can't be evaluated anymore for the current user. Damn. What about shutdown /s at the command prompt? Doesn't work either as you can see in the following screenshot:

Just in a little panic, I tried to play the at.exe trick to try the shutdown.exe stuff as LOCAL SYSTEM. However, at.exe doesn't work anymore either:

The Task Manager can't find out about the process owners anymore as you can see below:

And whoami is out of order too:

So I tried to logoff which worked well. However, pressing CTRL-ALT-DEL results in a screen with only the mouse pointer left. No chance to login again. Powering off the system seemed to be the only solution left. Upon reboot, the system told me what I already knew: I killed "LSA Shell" :o:

My conclusion: Security demos are fun, but don't prepare these on a production machine (you laptop for day-to-day usage for example) in order to reduce scary moments. And never ever trust 3rd party (only 3rd party?) tools to work smoothly. Oh, did I tell you that I was running all this stuff in a VPC? :-)

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under:

Comments

# Reg key HKEY_LOCAL_MACHINE\SECURITY is empty | keyongtech

Wednesday, January 21, 2009 7:57 PM by Reg key HKEY_LOCAL_MACHINE\SECURITY is empty | keyongtech

Pingback from  Reg key HKEY_LOCAL_MACHINE\SECURITY is empty | keyongtech