Creating ConfigMgr boot media without a password? Maybe that’s a bad idea.

Sometimes going off on a tangent leads you to yet another tangent. Or maybe it’s just an attention span issue. Regardless, it resulted in a question: How is the stuff that ConfigMgr embeds into boot media (e.g. the PKI certificate that you specify that enables the boot image to actually talk to ConfigMgr) protected? I knew that it was stored in the SMSdataVariables.dat file and that the file was encrypted, but since this is symmetric encryption (since it has to be decrypted locally before talking to ConfigMgr) that means there needs to be a key to decrypt it. So what key does it use?

It turns out that someone has already answered that question, likely by disassembling the ConfigMgr code. You can find the resulting code on GitHub, which shows that the hard-coded key is a GUID string, “{BAC6E688-DE21-4ABE-B7FB-C9F54E6DB664}”. If you compile that code, you can use it to decrypt the Variables.dat pretty easily:

And to make that a little easier, you can get PowerShell to convert it to XML:

Most of that stuff is no big deal. But one of the items, _SMSTSMediaPFX, contains a public and private key for a PKI-issued cert that enables communication with the site server, so if you have that cert, you can “chat” with the MP, DP, etc. And you can specify additional task sequence variables when you create the media, which would be added to this list.

So how do you protect this data so that it isn’t using the default decryption key? It’s pretty simple: You specify a password for the media. While you might think that password is just to make sure that someone can’t accidentally reimage a machine using the media (which it does do), but in addition to that the password that you specify replaces the default decryption key. Still, if you know what password was specified, you can still use the CMvarDecrypt.exe tool to decrypt the Variables.dat by specifying the password.

If you had PowerShell format that XML, it would look exactly the same as above (which makes sense — it doesn’t change anything in the file, it just changes the encryption key).

So it’s a good idea to specify a password, if nothing else to protect that one PKI key.

What I find a little more concerning is the “PXEThief” project that the CMvarDecrypt tool links to, and the blog post that describes what it does, defintely worth a read. If you weren’t paranoid about network access account passwords and secrets embedded inside task sequences before, you will be after reading that blog.