Une bonne surprise d’un point de vue sécurité
Il semblerait que Microsoft ait (enfin) compris qu’il valait mieux ne pas conserver au même endroit :
- des données chiffrées
- les clés de déchiffrement
- les routines de déchiffrement
Les mécanismes de protection de LSASS
sous Windows 8.1 preview n’utilisent plus la CNG en mode utilisateur (process), mais en mode noyau :
lsasrv!LsaProtectMemory
crypt32!CryptProtectMemory
- dispatch
ksecdd
- dispatch
cng
cng!CngEncryptMemory
Par ces mécanismes, LSASS peut chiffrer des données en s’assurant que celles-ci ne pourront pas être déchiffrées en dehors de son propre process.
L’API CryptProtectMemory
est utilisée avec le flag CRYPTPROTECTMEMORY_SAME_PROCESS
.
Cette fois, les clés de chiffrement sont générées avec certaines informations disponibles seulement en mode noyau (cookie, salt, heure de création, …).
Conséquence : les données ne peuvent être utilisées que depuis le même processus.
…ce n’est pas trop tôt, ces API étaient disponibles depuis Windows XP/2003 http://msdn.microsoft.com/magazine/cc163883.aspx#S2
Limites
Ces améliorations ont le mérite de protéger des dumps mémoire ou d’attaques sur LSASS
par lecture de données et de clés.
Mais si notre code est exécuté dans le processus LSASS
(injection de DLL ou autre), les mêmes clés sont utilisées, et le déchiffrement reste possible.
Surprise !
Il semblerait que Microsoft se donne du mal pour améliorer des routines sensibles et historiques…. mais ne les utilise pas toujours !
Windows 8.1 preview – provider LiveSSP
oui, le mot de passe est bien en clair en mémoire…
Windows 8 (« c’était mieux avant ») – provider LiveSSP
le mot de passe était bien chiffré précédemment…