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 :

1. lsasrv!LsaProtectMemory
2. crypt32!CryptProtectMemory
3. dispatch ksecdd
4. dispatch cng
5. 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…