Affaiblissement et les faiblesses du "Protected storage"
Le
Francois Grieu
Bonjour,
je découvre que Microsoft a affaibli le "Protected storage"
de Windows, y compris XP SP3, pour la localisation France.
<http://support.microsoft.com/kb/955417>
Je cherche un bonne explication sur les implications que cela
avait, et a encore pour les utilisateurs de XP, au moins sans
le patch; lequel (sauf erreur de ma part) ne s'installe pas
par défaut, et est j'imagine donc peu déployé.
Par ailleurs, je lis que "tous les services étrangers savaient
briser le Secure Storage de Windows Nt4-2k-Xp-2k3" sans
l'affaiblissement Français, et cherche aussi de l'info sur
cela.
Francois Grieu
je découvre que Microsoft a affaibli le "Protected storage"
de Windows, y compris XP SP3, pour la localisation France.
<http://support.microsoft.com/kb/955417>
Je cherche un bonne explication sur les implications que cela
avait, et a encore pour les utilisateurs de XP, au moins sans
le patch; lequel (sauf erreur de ma part) ne s'installe pas
par défaut, et est j'imagine donc peu déployé.
Par ailleurs, je lis que "tous les services étrangers savaient
briser le Secure Storage de Windows Nt4-2k-Xp-2k3" sans
l'affaiblissement Français, et cherche aussi de l'info sur
cela.
Francois Grieu
Poser une question
"Microsoft chose to disable the encryption of Protected Storage
by using a single, fixed encryption key for the French locale."
Ouch. Même pas besoin d'extraire cette clé, il doit suffire de
transférer les données chiffrées sur un autre XP dont on a le
mot de passe, non ?
Je pensais que les vendeurs de logiciels bridaient les clés
à 40 bits pour respecter les lois françaises avant 1999.
Mais une clé unique, c'est un peu fort.
Enfin bon, début 2010 on voyait encore des disques USB certifiés
FIPS et chiffrés en AES256... mais tous avec la même clé:
http://www.zdnet.com/blog/hardware/...rives/6655
http://www.symantec.com/connect/art...x-part-one
"PStore data is encrypted with TripleDES [...] However, data
security and access are logically tied to a user's Windows
login credentials" ?
AC
Tu connais Elcomsoft?
http://www.elcomsoft.com/WP/advanta...nd_effecti ve_recovery_of_encrypted_data_en.pdf
http://www.elcomsoft.com/aefsdr.html
A l'epoque ou je m'occupais encore d'IDA, il y avait au moins une
bonne dizaines de prives independents qui savaient faire ce genre de
chose: pour un systeme de chiffrement avec du multi-utilisateur ou un
compte de recovery crackable, l'algo utilise pour le chiffrement
proprement dit n'a que peu d'importance. En outre, il etait assez
facile de hot patcher un systeme pour s'amuser.
En ce qui concerne les "gouvernementaux", mon avis qui vaut ce qu'il
vaut...
D'un point de vue purement theorique, avant 2000, ils etaient
nettement plus forts que le monde academique. Il y a des indices ici
et la, comme l'histoire des s-box du DES optimisees contre la
cryptanalyse differentielle avant que celle-ci soit redecouverte par
le monde academique. Pas etonnant au vu de leurs effectifs, de la
qualite de ceux-ci et de leurs budgets. Cela continue probablement,
mais cela a perdu de son interet.
Par contre, au niveau pratique, donc essentiellement exploitation de
vulnerabilites et RE de systemes dans leur ensemble a la recherche de
problemes d'implementation, j'ai l'impression qu'ils n'etaient pas
tres avances. Plusieurs indices: ils sous-traitaient regulierement,
avaient tres peu de gens competents et pas de programmes structures.
Je ne peux pas trop entrer dans les details, mais disons que j'ai vu
des trucs concus par des gouvernementaux cent fois plus competents que
moi au niveau math/crypto qui ne tenaient pas trois jours face a une
attaque pratique. Un jour, j'avais meme decroche une mission d'analyse
d'une certaine duree, sur un truc cense etre solide. J'ai fini en 2-3
jours mais on m'a demande de continuer la mission a son terme pour des
raisons de politique interne. On preferait me payer plus longtemps
plutot que de remonter l'info d'extreme faiblesse de ce qui avait ete
develope. On preferait aussi me coller l'etiquette de "petit genie de
l'informatique" que de m'entendre dire que n'importe quel etudiant
russe avec un vieux PC aurait fait pareil, probablement plus vite.
Plusieurs anecdotes dans le genre, avec divers pays, donc je pense
qu'a ce niveau, ils n'etaient pas dans le coup.
Les germes du changement, c'est par exemple ceci en 96
http://www.phrack.org/issues.html?id&issueI
qui fait prendre conscience a beaucoup de monde qu'on n'est pas au
bout de nos peines en securite informatique et que l'attaque indirecte
contre des systemes de securite est vraiment realisable en pratique.
et en 2001
http://en.wikipedia.org/wiki/Code_Red_worm
qui provoque un tel choc que les budgets se liberent partout, les
services se creent ou se developent, parfois d'un facteur 100 si l'on
se base sur les achats d'outils software.
A vue de nez, a partir de 2003, les gouvernementaux deviennent plus
forts que les commerciaux, dans les aspects pratiques qui les
interessent en tout cas.
Pour resumer, par etapes successives
focalisation sur le chiffre (cryptanalyse pure et dure)
focalisation sur l'implementation de la methode de chiffrement. (RE de
l'implementation - faiblesses - par exemple DeCSS)
focalisation sur le systeme dans son ensemble (RE de l'implementation
dans son ecosysteme local - par exemple crack EFS)
focalisation sur les systemes dans leur ecosysteme (par exemple, et
jusqu'a preuve du contraire - une fuite etant toujours possible - le
"crack" HDCP recent)
Au passage, pas directement lie a la crypto, le truc hyper chaud du
moment c'est cela
http://en.wikipedia.org/wiki/Stuxnet
qui aura pour consequence de booster encore plus significativement les
efforts gouvernementaux dans le domaine.
news:
où il donne sa vision de l'historique des capacités des services
gouvernementaux en matière de cryptanalyse pratique. Le meilleur
article de ce groupe depuis des mois ! Merci !
Si je comprends bien l'offre de Elcomsoft
EFS est vulnérable
- bien sur, si on connais ou peut trouver par énumération le mot de
passe d'un utilisateur qui a (? eu ?) accès au document;
- plus généralement si on exploite une faiblesse (? accidentelle ?
délibérée ?) non spécifiée du système, dont (j'imagine)
l'affaiblissement Français est le paroxysme.
"The [aefsdr] product is well aware of the EFS encryption weakness
present in Windows 2000, allowing quickest recovery of the encrypted
files."
Je suis preneur d'infos plus précises sur la nature de cette faiblesse,
quels OS elle affecte, et si elle est délibérée ou pas. Par pure
curiosité.
Francois Grieu
En gros, stockage de la clé du recovery agent sur la machine elle
même.
http://answers.yahoo.com/question/index?qid 080405045935AAzeM5p
Possibilité d'effacer le mdp admin, et de ré-attribuer des mdp de ton
choix, même si l'admin n'est pas le recovery agent.
Sur disques crashés, possibilité aussi de récupérer les infos de
comptes, de les craquer et donc de récupérer les clés individuelles
utilisées.
Si mes souvenirs sont bons, les LM hashes, dont dépend la sécurité
des clés sous Windows 2000, sont de toute façon crackables par
recherche exhaustive sur 7 octets.
Description de la génération des hashes ici par exemple
http://www.sans.org/security-resour...tp-vpn.php
Techniquement, je ne me souviens plus du raccourci qui fait que seuls
sept octets sont importants. Cela va sans doute me revenir, mais la
dernière fois que j'ai regardé, c'était en 2002 ou 2003
Faiblesse délibérée? Oui, par design, et Microsoft n'a jamais préte ndu
autre chose dans ses docs techniques EFS, le marketing étant
évidemment autre chose. Au niveau de l'authentification LM, c'est
juste l'héritage d'une autre époque (OS/2) je pense.
Notons que 7 octets = 56 bits = beaucoup. Le NTLM est craquable parce
que ce n'est pas 7 octets, mais 7 _caractères_, de surcroît après
normalisation de la casse (lettres majuscules et minuscules sont
équivalentes). De plus, le mot de passe (jusqu'à 14 caractères) est
coupé en deux blocs de 7, qui sont traités séparément (ce qui est une
grosse boulette).
Le traitement consiste à utiliser le bloc de 7 (après normalisation de
la casse) comme clé DES pour chiffrement d'un mot de 8 octets fixe (pas
le même pour les deux blocs). Si le mot de passe ne comporte que des
lettres (sans accent) et des chiffres, alors on arrive à un coût moyen
de recherche exhaustive d'un peu moins de 2^37 essais en tout. Et ça,
c'est vraiment peu. Ça se compte en heures, voire minutes, sur un PC
banal. C'est suffisamment peu pour pouvoir s'optimiser avec des
précalculs. Une bête table précalculée avec _tous_ les blocs de 7
caractères possibles, chiffrés pour la moitié gauche et la moitié
droite, prendrait un misérable téra-octet, et permettrait une attaque
immédiate (un lookup sur disque, mettons deux puisque c'est quand même
une grosse table et qu'il faudrait un peu d'index, c'est une petite
fraction de seconde).
--Thomas Pornin