First off, for those of you who asked, I did leave 1E last week, off to try new things. Thought I’d take some time off during May, and then look for new opportunities. The future is wide open :^)
In the mean time, I did come across this post today about decrypting passwords with the BIOSConfigUtility64.exe utility.
https://www.serializing.me/2016/10/15/hpqpswd-encrypted-passwords-decryption/
And reminded me of some work I did recently at 1E on their BIOS 2 UEFI toolset. The HP tool did set off some red flags for me, the tool was able to take a plaintext password and put the encrypted value in a *.bin file without asking for an encryption key!?!? How did it do that? I figured it was because the tool stored the encryption key for the password within the executable itself. That’s not optimal (it’s unsecure), but not uncommon.
So I spent some time trying to reverse engineer the process, “link -dump /imports” revealed several cryptographic calls like CryptImportKey(), and with some time using trusty WinDBG.exe, I was able to locate the key. I wondered if HP would try to hide the key, but it was there in plain sight. I wrote a test program, but in my case I didn’t write a tool to decrypt the password, I wrote a tool to perform the encryption. My thoughts were to provide a centralized password storage mechanism for HP, Dell and Lenovo, and I wondered if the HP toolset was a good starting point. 1E didn’t go down that route but the reverse engineering the HP tool was interesting.
It does bring up an interesting ethical dilemma for Engineers like myself. Something that you see on the news whenever someone discovers a new vulnerability in an OS, or Web Browser: Do you keep the vulnerability secret, or do you tell the public, knowing that some Black Hat could use the vulnerability to write an exploit and expose sensitive data? In my case, I decided not to reveal the exploit, but Duarte chose to reveal it. Who is right?
I guess the only thing I can say is this is a good learning opportunity to discuss security/encryption of secrets like passwords. If you are an IT administrator, be weary of tools that can encrypt data magically without an encryption key, it’s not magic, they are encrypting the data with *something* and it’s possible the key is stored locally in an unsecure fashion. Better to store the passwords in a more secure location, with a more secure encryption, and then convert to the HP Password at the “Last-Minute” when preforming the actual task sequence.
This is a similar problem with other tools that “appear” to encrypt data, but store the data in a manner that *can* be easily extracted. Like the AdministratorPassword field in the unattend.xml file, and the Password in the SysInternals AutoLogon.exe tool. Both tools store passwords in an easily recoverable fashion. I’ve seen too many administrators fall for the illusion that these are secure, they are not.
-k
Hope to see many of you at MMS MOA in May 2017!!! I’ll be there.
Keith's Consulting Blog 