The scenario
A friend of mine worked at the IT department of a school and we had a talk about what consequences it may have if a laptop without disk encryption got into the wrong hands. He could not see what the big deal was if a student computer got lost so I suggested that if he would borrow me a computer from the school I would try to see what potential risks could come out of it. The laptop I got was old, worn down and scheduled for recycling. Perfect for this scenario!
Booting up
Starting the machine I’m eventually presented with the Windows XP login screen. I immediately notice that the username field does not contain anything filled out from before which puzzles me. I figure this must’ve been done by some policy setting. A quick Google search takes me to HowToGeek’s nice article explaining how to prevent this.
First thing I do after booting up is testing to log on as Administrator with blank password and other typical default passwords like ‘adminadmin’, ‘admin’, ‘qwerty’ and so on. You’d be surprised in how many administrators that do not change their default login credentials.In fact these types of security mis-configurations are featured on OWASP’s top ten quite often.
I have no luck with the password guessing attempt, albeit I did discover a guest account, however it was locked. This could have potentially been a way in.
My next step is to boot up the machine with a bootable device. My choice of weapon is to boot the machine with Backtrack . Backtrack is a Unix distribution with a large collection of different security tools. I chose this system because I know that I can easily mount the filesystem from disk and get full access to interesting files. For this Windows XP box I would say that the SAM file is the most interesting file. This file contains security account information. If I can modify it the proper way I am sure I can get access to the operative system.
Removing BIOS password
In order to be able to boot the machine from Backtrack live CD I had to change the boot up sequence. The machine had been configured to boot from HD and not offer any alternative boot options. The boot up sequence is changed via the BIOS which was protected with a password.
The BIOS password is easily bypassed by removing all power sources to the laptop. On some motherboards it can also be cleared by jumping a jumper between two pins. Removing all the power sources usually involves removing the following items:
* power cord
* battery pack
* motherboard battery
A special thing to notice on this Fujitsu laptop was that the battery was actually fitted beneath the keyboard instead of under the laptop beneath the panels for memory.
This should clear the CMOS which holds the BIOS password. You can read more about BIOS and CMOS, and especially the difference between the two, here: http://www.computerhope.com/issues/ch000707.htm .
Putting everything back together, I boot up the computer and I immediately notice that the BIOS password has been removed, I can now finally enter the BIOS to change the boot up sequence.
Mounting the filesystem and hijacking the SAM file
Since I now can change the boot sequence from the BIOS menu I now want to boot up the machine with my Backtrack live CD. This is so I can dump the SAM (Security Accounts Manager) file. This file is normally locked when the OS is running, but when I boot up with a different OS I can easily read and copy the file.
With Backtrack ready to go I run the command ‘mount -t ntfs-3g /dev/sda1 /mnt/winxp‘. This results in an error message claiming that the file-system is in use and also indicates an unclean shutdown. Not caring too much about this I force the mount through with the ‘-o force’ option .
With the OS fully readable and writable I can now go hunting for the prize, the SAM file. This key to truly unlock this PC.
The file is stored in Windows/System32/config/ folder. Using a program called ‘chntpw‘ made by Peter Nordahl I can easily modify the SAM file to meet my needs, but first I need to dump the hashes to a different file using ‘samdump2’ tool: ‘samdump2 system /mnt/win/Windows/System32/config/SAM > hashes.txt’
The hashes I stored in my working directory. They looked like this (modified for this example):
alsadmin:4F39B1117F8E17F5FAD2B435B51404EE:311BCD7805861C316FF74C13B467B7C5:::
guest:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:::
helpassistant:973997D93F2281620A4AAFF466D07871:3971C3C5C28DB4F37A2D289C56CAAAEF:::
SUPPORT_395345A0:AAD3B435B51404EEAAD3B435B51404EE:61E57472C5A2365EF67B07C61AFAC15E:::
I want the hashes for later just in case. The admin password might prove useful for me!
To fix access to the laptop I load up the SAM file with chntpw and choose the menu option ‘Edit user data and passwords’. I then choose to edit the user alsadmin. I am now presented with several different options I can perform on this user, but my choice of option is the ‘Clear password’ option. I already have the hashes in my Samdump2 file so the admin password can be cracked later.
With the BT CD removed the laptop now boots back up into windows. So I am now almost back to where I started, however this time I have a hidden ace up my sleeve. I diligently type inn alsadmin as the username and keep the password blank, press OK and voilà, I’m successfully logged into the computer. I don’t notice any start up scripts at log in, however I am presented with a message from the domain admin with a message about their network disc storage is full and their users need to clear free space. This message have probably been pushed out through a global policy update the last time it was connected to the domain it belongs too.
Next steps…
In the next part of this story one could explore topics such as:
- Recovering deleted files
- Cracking the administrator password
- Wardriving their WLAN’s
- Attacking the domain controller
Conclusion
- Use drive encryption
- Wipe computers when you are done with them (secure wipe!)