January 07, 2004
Defeating the BOFH: Compromising A Windows System
Tonight I found myself in the situation where one of my clients has had an administrator go rogue on them, leaving the company and refusing to give them vital information like access to their administrator passwords without first being 'compensated'. This is the EXACT risk I was talking about when I was discussing last month the Rule of Trust, one of the 8 Rules of Information Security. And the sad thing is, this isn't the first company I have seen that has had this issue. So in a 'generic' sort of way, I thought I would blog about how I compromised Windows XP to gain access to the administrator's primary machine, in an effort to recover information that was needed without giving into the blackmail.
First off, I must admit I am a little hesitant to discuss how I accomplished this breach. It is not because this is some sort of black art and I don’t wish to give up trade secrets; I just don’t like being responsible for educating “script-kiddies”. But after much deliberation, I realized that the basis of this technique is NOT new… and most attackers can already piece together this attack vector. Moreover, since most readers of my blog are in or want to be in the information security field anyways, I would rather show you how to COUNTER this attack by explaining how it works... and what could have been done to prevent it.
Anyways, onto the compromise. In this particular case, I needed to get access to the system for a few different reasons as part of a stage of evidence gathering, which I cannot discuss here out of respect for client confidentiality. However, I can say that if I could get onto the system, 90% of the battle would immediately be won. Knowing this… and with written permission from my client to breach the system, I went to work.
In the old Win9x days gaining access was quite trivial. Lets ignore the fact you could basically hit ‘escape’ and bypass the system for a moment and look at what their major security was. It was a screen saver password. I used to love this as I would watch the local computer store salespeople laugh as kids would try to breach their complex screen saver passwords in an effort to check out the latest store offerings. One day I just had to say something and explain how they should realize it’s quite trivial to breach their screen passwords. They wouldn’t accept my explanation until I came in one day, handed them a CD and told them that if they put it into the CD tray, they would never again have to enter in the screensaver password. Less than 30 seconds later, they were staring at the Windows 9x desktop. Why? Well almost every Windows 9x machine has autorun turned on. (I have yet to come across a machine that has it turned off in a production environment that I have had to access) This code execution path means that if you put a CD that has an autorun.inf file into the cdrom drive, it will spin up and execute. In my case, I wrote a small exe in C that would kill the process running the screensaver. The result? Put the CD in, Windows would see the autorun and executes my code that would then search for the appropriate process and kill Windows only defence between you and the desktop.
With the introduction of newer versions of Windows, Microsoft made strides to make this sort of attack vector harder. You can no longer just hit ‘escape’ to get into the system, and process separation makes it difficult (but not impossible) to kill off a screensaver. Yet the way systems like XP work gave me an idea about how the screensaver works during logon.
In Windows XP (well all recent Microsoft OSs actually) on boot up you are presented with a logon screen. After a default timeout (approximately 10 to 15 minutes) if there is no interaction with the mouse or keyboard the kernel executes the logon screensaver. Knowing this… it is possible to use this code execution path to gain elevated privileges if we can trick Windows into executing our code.
The way I did this is actually quite trivial. In my case, I simply booted into an environment that would let me access the filesystem directly (For this I use a slightly modified version of Knoppix-STD with NTFS write support) and simply tamper with the logon screensaver. In Windows XP, this file is located at %SYSTEMROOT%\System32\logon.scr. I replaced it with a copy of cmd.exe, and then synced the disk and unmounted it.
Once my “Trojan” was in place, I ejected my boot CD and rebooted the machine, and waited. XP booted up to its logon screen, waiting for me to enter my credentials. But I didn’t. I just sat there, enjoying a Tim Horton’s Café Mocha, documenting my procedures to this point. About 15 minutes later, with my indulgence in coffee satisfied and documentation completed, Windows XP launched my version of the logon screen saver, giving me a command prompt. But not just ANY command prompt. A command prompt with SYSTEM privileges. For those of you that do not know… consider SYSTEM the $DEITY of the machine… with higher privileges than even the Administrator. I’m in. Now, simply type “explorer” and watch the system come up. The result? See for yourself:
If you cannot make out the image (sorry, I should have gotten a better screen scrape) you will note that the USER is System (not a normal thing) and the background has a command shell... but look at the titlebar. Its actually logon.scr!
Ok, so now you know how to breach Microsoft's latest flavours of operating systems. What could have been done to stop me? There were plenty of failures that happened here, some that could have easily been fixed, and others that could not. Here is a brief rundown:
- System should have had a BIOS password: Although it is possible to bypass the BIOS, its makes it considerably harder. Why would I want access to the BIOS? Simple. To set the boot order of devices.
- Do NOT allow bootup from secondary/removable media: I should NEVER have been able to boot from CD. A combination of a strong BIOS password and only allowing a boot from harddisk would have prevented that.
- Consider using a Syskey bootup password: This is a bit tricky, and not ideal for everyone, but can provide you with an extra level of protection. A system would simply NOT boot until a bootup password was provided. For Linux people, this is like password protecting LILO. NOTE: NOT a good idea for headless servers :)
- Prevent physical access to the machine: This is kind of moot in my case, since I had permission from the company. But it still fits. The first three laws of Immutable Security, are basically that if an attacker can get you to run a program, alter your OS or get access to your computer… it’s not your computer anymore. I broke all three laws to breach the system.
Well there you have it. At this point you now know how to breach the system, and techniques you can use to counter the attack. I have purposely left out what I did once on the machine, as I will leave that exercise up to the user… and quite frankly am not interesting in teaching kiddies how to actually use this attack vector to change administrative passwords or create secret accounts for themselves.
Posted by SilverStr at January 7, 2004 12:37 AM
Huhu Dana, good work.
But a question, in your list of ways to fix the problem you mention "Do NOT allow bootup from secondary/removable media". Surely that is set in the Bios, so once that is comprimised you are screwed.
Now question, isn't is possible to set the logon screen to not every go into screensaver mode ? Surely that would solve the problem ? Maybe make logon.scr a system protected file (I assume you can't just edit any file with Knoppix-STD or else you could just edit the password file couldn't you?) or even point the logon screensaver in the registry to a file in the admin's HOME ?
greetz for this 31337 zero day, I have now 0wnzored 3 box’en with it. (precaution use on file system of type NTfs)
peep’s will see these comand benneficial:
mount -o remount,rw /mnt/
You are right about the BIOS.. which was why the first item was to make sure the bios password was on. Although the BIOS can be defeated even with a password, its much harder, and will relieve a good portion of attack surface. Remember, its about risk mitigation... not risk avoidance. If the attacker has the skills to replace a BIOS chip, or has resources on BIOS backdoors (there are numerous ones) he is going to get in.. face it. Knowing the attacker, and the methods they use can go a long way to determining the threats, and the appropriate countermeasures.
As to your question about turning off screen saver mode, I honestly don't know. I would assume that there is such a setting, but I don't know it off hand. For system protected files, remember that this only works if Windows File Protection (WFP) is properly configured, and the cache (where it gets its files) is not tainted. This can easily be overridden when mounted from a different bootup session (ie: a Linux bootup). Typically WFP works when the kernel determines a change in the file while the system is active, and then checks it against the file signatures in the Protected Files catalog. Altered files can then be copied from the cache. Bootup is a different story :)
To the point about getting the password file using this technique... you are absolutely right (you can). Which is WHY its important to use Syskey. Its quite easy to grab the SAM file and crack the hashes with something like L0phtCrack. The Syskey adds one more dimension to this, making it extremely difficult to crack.
Anyways, my point was to show the breach while showing more on how to counter it. I will refrain from disclosing how you can defeat things like WFP cache, as there is no real GOOD reason to do so unless you have malcious intent. And thats not the purpose of this post, or this blog.
Where can I get Knoppix-STD with NTFS write support? Or how can I mod my Knoppix-STD to have write support? I am somewhat new to linux but I highly enjoy using Knoppix and Red Hat. This woul prove very useful to me.
Funny you should write about this, as I did a proof of concept on pretty much the same thing a little while ago. It was actually a little embarrassing, because the C: drive was world write-able and therefor any local user could change the screen saver to cmd.exe (or rwx any other file), not even requiring a reboot with a floppy/CD/USB keychain gizmo (which boots as 'USB Hard Drive' by the way, and is usually enabled by default on new[er] machines).
To capatilize *again* on the importance of locking down the boot order, there was an article posted on while back on gaining the Windows equivalent of root using a Windows 2000 CD. A quick Google points to the original article (briansbuzz.com), which explains how you can use Recovery Console to "operate as Administrator without a password, even if the Administrator account has a strong password."
Question back to you Dana: Because so many of these [relatively easy] security breaches rely on accessing the hard drive without booting from it, would using filesystem-level encryption plug this hole? I'm curious if it's even possible to do under Windows, but also if the cost-benefit ratio makes it worthwhile (ie if it's too much of a pain in the ass to setup, it might be cheaper to rent an old nuclear bunker than it would be to waste costly man-hours getting it to work).
If you are new to Linux I wouldn't recommend trying to modify the iso. Typically you would mount the iso loopback, make changes as required to the iso and then be done with it.
There are tools out there to make it easier. Knoppix-customize is one such product.
Knoppix-STD already comes with NTFS read support. To get it to do NTFS write support (which is still experimental... but quite stable) though you need to make some changes. If you are really interested in this you should look up a tool called "Captive". The trick I found is that you have to use Windows ntfs.sys file through Wine to get the ability to actually manip files on an NTFS partition (especially in this case, where you need to overwrite files).
The idea of using encryption is a neat one, but leaves you to a few "issues" The biggest one is access to core system files. The idea of using EFS to provide the encryption is not practical, as the running system requires the ability to access the system files, which includes normal users. If you only decrypted it during bootup by using some autonomous task, you would still need to store the key SOMEWHERE... which means that the attacker could also find it.
Some of the code I am currently working on solves the problem of access control in this manner. My mandatory access control driver provides an avenue to guarantee the integrity of system binary files (well actually any files in the system that you have configured) on the host, and will not ALLOW an untrusted binary to be executed if it is configured in this manner. My kernel component immediately detects and prevents unauthorized access to protected resources by limiting the set of files an untrusted process may access. This provides "least privilege" confinement to applications and contains the potential damage of malicious or exploited software that exhibit unexpected behaviour or succumb to a security attack. In the end, it provides a way to know, with certainty, that systems remain uncompromised.
I am rather excited by my work, as it can significantly reduce the attack surface of a Windows host while increasing the overall confidentiality, integrity, and availability of the system. Watch for it later this year as I release public versions of my work.
Neat hack. However, as I'm sure you know, no system is secure if you have physical access to the machine. A BIOS password is easily circumvented - most motherboards have a BIOS reset jumper handy, and if not, it's easy enough to pull the LiOn battery for a second.
Failing that, you can always pull the drive and read it from another machine. There are plenty of migration tools which will actually allow you to copy and modify the user accounts on the box if it is a domain controller (give the guys at Quest Software a call).
No amount of security will save you if the door to your server room isn't locked. :)
The logon screen saver settings are simply stored in the registry under HKEY_USERS\.DEFAULT\Control Panel\Desktop
I've used this information to change the logon screen saver, or of course you could disable it entirely.
Neat idea, I've not seen that as an answer to this problem before...
another way to solve it that might interest you is the offline NT password & Registry editor boot CD http://home.eunet.no/pnordahl/ntpasswd/ which I've used on a Win2K machine to reset the administrator password for a friend who had managed to lock himself out.
Yeah I'll have to second ntpasswd, I've used that to gain access to a few computers here to bypass the clueless IT department. The bios password, boot order, etc. can all be bypassed by taking the CMOS battery out and making a circuit between the two pins.
Have you tried running ntpasswd against an XP system with Syskey installed? Its considerable more difficult... especially offline.
Would be interesting to see how it works. I know its quite easy with W2K... haven't tried it on XP though.
You don't even need to mess with the Linux stuff. BartPE will let you boot a minimal version of Windows XP off a CD. http://www.nu2.nu/pebuilder/
That really worked, but when I changed a few stuff and come back latter to change another thing, the system freezes.. well He dont freeze I just cant open things.. i click them but they dont open.. but if i enter as a normal user the computer is normal.. but as system no way.. :( and i still need a thing..
ok, seems to me that you went a bit far out of your way, there's an inherant flaw in the security of most newer OS's that allow a user to use the windows 2000 CD or boot disks to boot into " Recovery Console" once there all restrictions are pretty much gone. one thing that i would advise companies, and individuals to do, is use PGP to encode the first segment of the system folder, and use a smart card or similar to decrypt at during boot, not a very efficient way, but much more secure than anything i've seen come from microsoft..
got a floppy version (no CD drive :( )