4

As outlined in Security Bulletin MS14-025, Microsoft acknowledges the way credentials had been stored in the group policy field "CPassword" is insecure and is not to be trusted any more.

However according to their own Developer Documentation, they themselves had published the 32-byte AES encryption key well before 2014, allowing anyone chancing upon an encrypted ADGP password to decrypt it. I've seen articles speculate this had been published on MSDN sometime pre-2012, the earliest source I can find is 2013

I can't think of any good reason to publish this key, was this intentional or a mistake on Microsoft's part? Is this an example of an accepted public-secret where anyone operating a Windows server is allowed to reverse engineer this value from memory?

Al Longley
  • 143
  • 4
  • According to this [blog post](https://adsecurity.org/?p=2288) it seems to have started already in 2012 (it contains a section about the history of this problem). – Robert Jun 23 '22 at 12:10
  • I see plenty of retrospective exploit writeups from redteamers aware of the Group Policy fun and games, and of course there's a multi-year gap from MS until remediation is offered. I'm specifically curious about what they have to gain by publishing AES keys. It could have something to do with Desktop Standards "PolicyMaker" already doing so, thank you for linking – Al Longley Jun 23 '22 at 13:38

1 Answers1

2

Given the Group Policy implementation stores the password using encryption (instead of hashes), any code applying the Policy must have the key to decrypt the password.

Once someone has realised this, it wouldn't be very hard to debug any copy of Windows to get the key. In other words, the key is already shipped with every release of Windows way before 2012.

The whole scheme is security by obscurity and has no real strength. Publishing the key is just good documentation.

TBH, it wouldn't be very difficult to deduce this. People with reasonable knowledge of Windows security mechanisms will know that each password is hashed in multiple ways for backwards compatibility (LM, NTLMv1/2, etc.). M$ has never requested the password-containing Group Policy to be re-created as the new hashes are introduced, which means the password is stored in a reversible format. The Base64 in the Policy XML also doesn't look long enough to hold multiple hashes anyway.

billc.cn
  • 3,852
  • 1
  • 16
  • 24