Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Je lisais sur une mailing list qu'un gros problème en crypto, c'est qu'en cas de problème, cela fonctionne tout de même C'est juste non sécurisé, mais personne ne s'en rend compte... 1 une petite démo d'insécurité Étudiant en ce moment le chiffrement de disque sous linux, je propose un petit exercice pour s'en rendre compte. Sous linux, on utilise le frontend cryptsetup pour gérer la couche crypto cryptsetup luksOpen dev sdb1 ciphered_sdb1et la commande demande un mot de passe. S'il est correct, alors la clé maître de chiffrement du volume est libérée, permettant la lecture des données. La documentation précise que l'on peut passer ce mot de passe via un pipe unix, comme par exemple echo MDP cryptsetup luksOpen dev sdb1 ciphered_sdb1ou bien cat randomfile cryptsetup luksOpen dev sdb1 ciphered_sdb1 Imaginons donc un setup qui va extraire un certain nombre d'octets depuis dev random et qui va s'en servir comme clé de chiffrement. Ce setup n'offre qu'une faible garantie contre une attaque bruteforce La raison en est simple et est précisée dans la fin du man cryptsetup. En effet, le passage de données via un pipe s'arrête dès le premier n rencontré. Ce qui signifie que si dans les premiers caractères du fichier un n est présent, alors la force de la clé est simplement équivalente au nombre de caractères précédent le n Démonstration Tout d'abord génération d'un fichier aléatoire tiré depuis dev random et utilisation de celui-ci pour formater une partition luks root slack dd if dev random of rnd bs 16 count 1 0 1 enregistrements lus 0 1 enregistrements écrits 16 octets 16 B copiés, 0,00016936 s, 94,5 kB s root slack cat rnd cryptsetup luksFormat dev loop0 root slack cat rnd cryptsetup luksOpen dev loop0 ciphered root slack cryptsetup luksClose dev mapper ciphered A première vue, le setup semble correct la clé est tirée depuis un générateur de hasard correct, et j'ai pu ouvrir le volume sans erreur. Mais il se trouve que la force de la clé est beaucoup plus faible que 16 octets et dû également à un certain nombre d'essai successifs de ma part pour obtenir un rnd voulu root slack hexdump rnd 00000000 ca 41 71 0a 51 ba 56 55 f7 13 fb d9 94 0e 5c 2f 00000010root slack printf ' xca x41 x71' loose root slack cat loose cryptsetup luksOpen dev loop0 ciphered root slack ls -l dev mapper ciphered lrwxrwxrwx 1 root root 7 août 23 21 19 dev mapper ciphered - .. dm-0 root slack On constate que le fichier contient un 0a en 4e position, et que le volume s'ouvre uniquement avec la connaissance des trois précédents. Le système n'est donc absolument pas sécurisé malgré ce qu'il laissait imaginer puisqu'il est vulnérable à une attaque bruteforce. Pour éviter ce problème il faudrait s'assurer de ne jamais avoir de n dans son fichier ou d'utiliser l'option --key-file qui n'a pas ce problème, se référer à la page man partie NOTES ON PASSWORD PROCESSING . Comme indiqué en introduction il ne s'agit pas d'une attaque ou d'un scoop particulier, le but de cet article est simplement de montrer qu'un setup crypto qui fonctionne et qui paraît fiable ne l'est pas du tout. 2 And go beyond A titre d'exemple, quelle est la valeur des master key de cryptsetup La doc indique que la master key est générée à l'aide de dev random ou dev urandom. Sur ma machine, je vois par exemple root slack cryptsetup --help snip... Paramètres de chiffrement compilés par défaut plain aes-cbc-essiv sha256, clef 256 bits, fonction de hachage ripemd160 LUKS1 aes-cbc-essiv sha256, clef 256 bits, hachage entête LUKS sha1, RNG gén. aléa. dev urandom Le choix de chiffrer un disque se fait généralement à l'installation de la distribution. Et lors du boot d'une machine, à l'installation, suffisamment de random est il récupéré Le man urandom précise que ce n'est pas un aléa de qualité, bien qu'il ne fournisse aucune attaque. Il faudrait que je prenne un peu de temps pour étudier tout cela. Pour ceux que cela intéresse, sachez que dans la dernière version de cryptsetup il existe une option permettant de modifier la MasterKey sans devoir regénérer le mapping et ainsi s'éviter un backup restore des données crypsetup-reencrypt .






Les derniers articles du site "Exploitability" :

- Street fighter -- Assassin's Fist
- SSTIC 2014
- L'antivirus est mort air connu
- 400 Gigabits par seconde, c'est beaucoup pour un DDOS
- Bluetouff et gogleuh
- Haka est sorti TCP IP security is not boring anymore
- NSA Catalog petit papa Snowden
- Grehack 2013 writeup - 1337
- Gre at Hack 2013
- RIP.

---

S'abonner au fil RSS global de la revue de presse

---