Affaiblissement et les faiblesses du "Protected storage"

Francois Grieu wrote:

http://support.microsoft.com/kb/955417

"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/encryption-busted-on-nist-certified-kingston-sandisk-and-verbatim-usb-flash-drives/6655

Par ailleurs, je lis que "tous les services étrangers savaient
briser le Secure Storage de Windows Nt4-2k-Xp-2k3"

http://www.symantec.com/connect/articles/password-management-concerns-ie-and-firefox-part-one
"PStore data is encrypted with TripleDES [...] However, data
security and access are logically tied to a user's Windows
login credentials" ?

AC

On 4 oct, 14:27, Francois Grieu <fgr...@gmail.com> wrote:

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.

Tu connais Elcomsoft?

http://www.elcomsoft.com/WP/advantages_and_disadvantages_of_efs_and_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=14&issue=49

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.

Le 05/10/2010 04:26, Pierre Vandevenne a écrit l'intéressant message
news:293953ef-8804-4693-a387-f8c7d9031bdd@j18g2000yqd.googlegroups.com
<http://groups.google.fr/group/fr.misc.cryptologie/msg/90f4eddd16598ee6>
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
<http://www.elcomsoft.com/aefsdr.html>
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

On Oct 5, 7:19 am, Francois Grieu <fgr...@gmail.com> wrote:

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é.

En gros, stockage de la clé du recovery agent sur la machine elle
même.

http://answers.yahoo.com/question/index?qid=20080405045935AAzeM5p

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-resources/malwarefaq/pptp-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.

According to Pierre Vandevenne <pierre.vandevenne@gmail.com>:

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.

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

Thomas Pornin wrote:

Notons que 7 octets = 56 bits = beaucoup

Beaucoup est un peu vague, en gros c'est suffisamment cher pour que cela
ne vaille très probablement pas le coup (et le coût) de s'en prendre à
votre compte en banque comme cela.

Enfin au premier abord, car si on tente de mettre des chiffres un peu
plus précis :
- On calcule autour de 300 millions de MD5 par seconde sur une PS3 ou un
PC multicore récent (*), prenons ce chiffre comme difficulté de
l'attaque à réaliser
- 2^56 représente alors 66 000 heures de calcul
- L'attaque est donc réalisée en 3 jours avec 1000 PS3 (budget de
300k€), en 15 jours gratuitement si l'EPFL de Lausanne vous donne accès
à son cluster de 200 PS3.

Mais si l'attaquant est un pirate qui contrôle un botnet de plusieurs
centaine de milliers ou même millions de machines, et qu'il a identifié
qu'il y a plusieurs milliers d'euro à récupérer, on peut se poser la
question si ça ne deviendrait pas très concrètement rentable pour lui.

(*) Résultat corrigé de Nick Breese de 80 million en 2007, amélioré à
300 millions ici :
http://blog.distracted.nl/2009/06/psebr-is-almos-done.html. Le même blog
point vers un autre programme destiné à attaquer du NTLM sur un CPU
standard qui semble bien avoir des performances comparables. Vu la
facilité que j'ai eu à trouver ce blog, un attaquant avec la compétence
et les moyens nécessaires pour réaliser cela doit certainement connaître
cela depuis longtemps.

According to Jean-Marc Desperrier <jmdesp@gmail.com>:

- On calcule autour de 300 millions de MD5 par seconde sur une PS3 ou un
PC multicore récent (*), prenons ce chiffre comme difficulté de
l'attaque à réaliser

En fait sur un PC multicore, même récent, c'est moins que ça (à la
louche, dans les 20 millions de MD5 par seconde et par core si on fait
du SSE2 pour en calculer quatre en parallèle). Mais un PC moderne
pourrait aussi avoir une carte graphique moderne. Avec ma NVidia 9800
GTX+, je fais dans les 160 millions de SHA-1 par seconde. Sur du MD5, on
devrait approcher les 200 millions. Avec une carte plus grosse (genre
une GTX 470 ou plus), on devrait faire dans les 400 millions de MD5 par
seconde.

Pour les PS3, ça ne marche plus : depuis le printemps dernier, Sony a
abandonné "OtherOS" et mis à jour les firmwares : on ne peut plus
installer Linux sur une PS3 nouvellement achetée, ni sur une PS3 mise à
jour (et une PS3 non mise à jour ne peut plus se connecter aux serveurs
de jeux).

Donc celui qui voudrait faire du cassage de mot de passe brutal devrait
acheter des cartes graphiques, pas des PS3.


Il convient de noter que beaucoup d'usages de MD5 ou SHA-1 pour des
mots de passe utilisent des invocations multiples ; par exemple, pour
un /etc/passwd linuxien, le coût du hachage est similaire à celui
de 1700 MD5 "simples". Donc diviser par 1700...

Dans le cas de NTLM, c'est une variante de DES. Les timings pourraient
être assez différents de ceux de MD5.

Mais si l'attaquant est un pirate qui contrôle un botnet de plusieurs
centaine de milliers ou même millions de machines, et qu'il a identifié
qu'il y a plusieurs milliers d'euro à récupérer, on peut se poser la
question si ça ne deviendrait pas très concrètement rentable pour lui.

Mouais, enfin on parlait ici d'un mot de passe NTLM sur un Windows 2000.
Un Windows de ce genre a suffisamment de trous en lui-même pour qu'une
quelconque attaque cryptographique soit, comparativement, hors de prix.


--Thomas Pornin

Thomas Pornin wrote in message <4cbf47ab$0$9907$426a74cc@news.free.fr>:

Pour les PS3, ça ne marche plus : depuis le printemps dernier, Sony a
abandonné "OtherOS" et mis à jour les firmwares : on ne peut plus
installer Linux sur une PS3 nouvellement achetée, ni sur une PS3 mise à
jour (et une PS3 non mise à jour ne peut plus se connecter aux serveurs
de jeux).

Il y a du nouveau tout frais de ce côté.

http://marcansoft.com/blog/2010/10/asbestos-running-linux-as-gameos/

C'est encore assez artisanal, mais c'est déjà ça.

On Oct 20, 9:48 pm, Thomas Pornin <por...@bolet.org> wrote:

Mouais, enfin on parlait ici d'un mot de passe NTLM sur un Windows 2000.
Un Windows de ce genre a suffisamment de trous en lui-m me pour qu'une
quelconque attaque cryptographique soit, comparativement, hors de prix.

Ma réponse précédente n'est apparemment pas passée. J'avais en effe t
été un peu approximatif dans l'expression de ma réponse (j'ignorais
que TP lisait encore ce groupe). Il y a plein de restrictions sur les
caractères utilisables, et plein d'autres faiblesses. En pratique,
tout craquait assez vite avec lophtcrack sur du hard de 2002, même les
mdp de longueur "idéale" - 7 caractères - . Une recherche sur
lophtcrack/scambray/mcclure donne toute l'info même si elle est un peu
fragmentée. Un problème connexe étant le stockage de données
d'authentification faibles au côté de plus forte pour des raisons de
compatibilité. Et accessoirement, toujours vu sous l'angle pratique
des choses, les réduction volontaires du niveau de sécurité de ces
mécanismes d'authentification pour permettre d'accéder à des systèm es
basé sur linux qui ne supportaient pas les mécanismes ultérieurs.