4 ms·

After reading the article again, I think this might be an actual interesting Windows vulnerability - rather than a platform issue with MOR, I think this might b

by bri3d 2y ago

After reading the article again, I think this might be an actual interesting Windows vulnerability - rather than a platform issue with MOR, I think this might be bad Windows code where the key is left over in places that aren't protected by MOR. It's quite unclear the more I think about it what's going on here, and the article lacks detail. It's very suspicious to me that the key has disappeared from the `ksecdd` pool but remains in the `dumpfve` pool, and this has my bug spidey-sense tingling. I'm surprised given that the article mentions stepping into the boot process and `SymCryptSessionDestroy` that they didn't look more deeply into this; it's not how I really intended to spend my new years but I might have a new debugging project now...

NoInitRD 2y ago
Hello! I'm the author of the article and I actually did look into that. I used windbg and stepped through the process of windows booting up to the point of expecting a password. I also looked at what happens when you trigger bitlocker in a way where it requests a recovery key. I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets. Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...
- bri3d 2y ago
  Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.
mjg59 2y ago
MOR should be wiping everything, especially since after a cold boot the firmware has no idea what the previous memory map was. But I can imagine a universe where it doesn't wipe the boot services heap space (because some of that is obviously in use) and maybe a copy is hanging out there in a predictable way?
- NoInitRD 2y ago
  This is my understanding of whats going on.

by bri3d 2y ago

NoInitRD 2y ago

Hello! I'm the author of the article and I actually did look into that. I used windbg and stepped through the process of windows booting up to the point of expecting a password. I also looked at what happens when you trigger bitlocker in a way where it requests a recovery key. I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets. Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...

bri3d 2y ago
Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.

mjg59 2y ago

MOR should be wiping everything, especially since after a cold boot the firmware has no idea what the previous memory map was. But I can imagine a universe where it doesn't wipe the boot services heap space (because some of that is obviously in use) and maybe a copy is hanging out there in a predictable way?

NoInitRD 2y ago
This is my understanding of whats going on.