|
Le chiffrement de disque sous linux Second strike |
Si vous voulez bloquer ce service sur vos fils RSS
Si vous voulez nous contacter ou nous proposer un fil RSS
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]
Le chiffrement de disque sous linux Second strike Par ExploitabilityLe [2012-09-11] à 18:01:43
Présentation : 1 Introduction la théorie Toutes les distributions linux permettent depuis longtemps de chiffrer la racine du système afin d'améliorer la sécurité du système. Ce chiffrement se fait à l'aide de cryptsetup et dm-crypt, la documentation est abondante sur le sujet. Cet article propose une étude des limites du chiffrement -L'humain l'implémentation et l'utilisation -Ecrasement de données -Evil Maid -Cold boot attack 2 L'humain Le plus gros problème de la crypto c'est qu'il est possible de se tromper mais que cela fonctionne tout de même c'est juste non sécurisé. 2 A L'implémentation le meilleur chiffrement du monde peut être anéanti si le programmeur l'a mal codé. Si le programmeur a bien travaillé, alors l'intégrateur peut se tromper également n'est ce pas debian . Les algos par défaut peuvent également être mal choisis ce n'est pas le cas avec cryptsetup . Comme je l'ai montré dans un précédent article, un simple cat peut aussi réduire toute la sécurité à zéro. Une lecture des init de debian et slackware montrent que des choix efficaces ont été fait. 2 B L'utilisateur Toute solution de chiffrement est vulnérable à au mauvais mot de passe. Il faut donc forcer l'utilisation de bon mots de passe. On peut imaginer des solutions hardwares ou des politiques strictes. Il faut aussi se méfier de l'utilisateur malveillant qui peut dumper la clé maître de chiffrement du disque dmsetup --showkeys , rendant caduque le remplacement des clés de slots par l'administrateur qui veut lui couper l'accès. Heureusement, cryptsetup propose depuis la version 1.5.0 en expérimental un système de changement de clé maitre http code.google.com p cryptsetup wiki Cryptsetup150 chercher cryptsetup-reencrypt dans la page 3 Protection anti-écrasement Un autre de mes articles expliquait comment écraser des données choisies afin d'éviter le lancement au démarrage de contre mesures de protection. Il n'existe pas encore au niveau de dm-crypt un mécanisme de vérification d'intégrité. Toutefois, deux solutions sont envisageables 3 A Le filesystem Ext4 depuis la version 3.5 permet de calculer un CRC32 des données. Si un écrasement à eu lieu, alors le fs est remonté en ro. Il devient donc possible de détecter si un écrasement volontaire ou non a eu lieu en testant en fin de boot si est en rw. 3 B dm-verity Une nouvelle couche device mapper a fait son apparition avec le noyau 3.4. Elle maintient un hash de tous les blocs et permet de les vérifier de manière fiable à l'aide d'un TPM. 4 Protection anti Evil Maid On le sait, même si l'intégralité du disque est chiffré, il reste toujours une petite partie en clair, servant à gérer le démarrage et demander la clé de déchiffrement. Un pirate pourrait modifier ce code en clair afin de logger le mot de passe quelque part. 4 A TPM le noyau peut utiliser un TPM. Ce TPM permet de vérifier que le code en clair MBR noyau initramfs est bien celui d'origine et n'a pas été modifié. La conférence que j'ai donné aux RMLL 2010 explique comment utiliser le TPM sous linux. 4 B If it walk like a duck, is it a duck Ma conférence était un poil incomplète. En effet, le setup laisse un léger trou qui peut se combler facilement. Lors du démarrage, les métriques du boot MBR, noyau, initramfs sont chargées dans le TPM. Ensuite, la racine est déchiffrée via la clé scellée dans la partition boot. Mais si je suis un pirate, je peux déplacer cette clé, changer l'intégralité du système linux et rebooter. Ainsi, je deviens root sur mon système et les métriques TPM sont correctement positionnées Je peux donc désceller aisément la clé scellée et lire modifier les données du système initial. Cela se corrige simplement en brûlant les métriques TPM en fin de boot en ajoutant de l'alea afin de les dévalider. 5 Protection cold boot Une autre attaque consiste à aller chercher les clés directement dans la mémoire vive. Ciblant plus linux, un travail d'étude intéressant peut se lire ici http events.ccc.de camp 2007 Fahrplan attachments 1300-Cryptokey_forensics_A.pdf Je cite une partie The obvious conclusion that can be drawn is that key recovery is surprisingly easy. Once an attacker, in our case a forensic investigator, has gained access to an image of the memory the keys can be easily found, extracted and reused to gain access to the encrypted material. La solution consiste donc à éviter que les clés soient présentes en mémoire vive. Deux projets me semblent intéressant. 5 1 Frozencache Le projet semble relativement mort. L'idée de base est de placer les clés dans le cache CPU. Lorsque la clé est dans le cache, les performances sont calamiteuses, mais comme le dit l'auteur, la clé n'a besoin d'y être que lors de la phase d'hibernation ou lorsque la machine a son screensaver de lancé. 5 2 Tresor Ce projet n'est pas inclus dans les sources officielles du kernel mais semble plus intéressant. Our solution takes advantage of Intel s new AES-NI instruction set and exploits the x86 debug registers in a non-standard way, namely as cryptographic key storage. TRESOR is compatible with all modern Linux distributions, and its performance is on a par with that of standard AES implementations. 5 3 Les clés OK, mais quid des données Il reste encore un léger problème avec ces implémentations. Les clés sont sauves d'une attaque coldboot, mais les données, elles, ne le sont pas. C'et mineur, mais il faudrait prévoir un mécanisme permettant de dropper tous les caches afin d'éviter qu'un attaquant lise le contenu de la RAM le proc vm_drop_cache . On sait plutôt bien reconstruire le contenu d'une RAM linux, ainsi que les fichiers présents volatilitux . 6 Conclusion Il s'agit actuellement d'un WIP Work In Progress . Il me reste plusieurs setups à tester et des attaques à vérifier. J'espère avoir fait le tour des risques liés au chiffrement de disque et des moyens pour les limiter.
Les mots clés de la revue de presse pour cet article : linux Les videos sur SecuObs pour les mots clés : linux Les mots clés pour les articles publiés sur SecuObs : linux Les éléments de la revue Twitter pour les mots clé : linux
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.
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]
Si vous voulez bloquer ce service sur vos fils RSS :
- avec iptables "iptables -A INPUT -s 88.190.17.190 --dport 80 -j DROP"
- avec ipfw et wipfw "ipfw add deny from 88.190.17.190 to any 80"
- Nous contacter par mail
Mini-Tagwall des articles publiés sur SecuObs : | | | | sécurité, exploit, windows, attaque, outil, microsoft, réseau, audit, metasploit, vulnérabilité, système, virus, internet, usbsploit, données, source, linux, protocol, présentation, scanne, réseaux, scanner, bluetooth, conférence, reverse, shell, meterpreter, vista, rootkit, détection, mobile, security, malicieux, engineering, téléphone, paquet, trames, https, noyau, utilisant, intel, wishmaster, google, sysun, libre |
Mini-Tagwall de l'annuaire video : | | | | curit, security, biomet, metasploit, biometric, cking, password, windows, botnet, defcon, tutorial, crypt, xploit, exploit, lockpicking, linux, attack, wireshark, vmware, rootkit, conference, network, shmoocon, backtrack, virus, conficker, elcom, etter, elcomsoft, server, meterpreter, openvpn, ettercap, openbs, iphone, shell, openbsd, iptables, securitytube, deepsec, source, office, systm, openssh, radio |
Mini-Tagwall des articles de la revue de presse : | | | | security, microsoft, windows, hacker, attack, network, vulnerability, google, exploit, malware, internet, remote, iphone, server, inject, patch, apple, twitter, mobile, virus, ebook, facebook, vulnérabilité, crypt, source, linux, password, intel, research, virtual, phish, access, tutorial, trojan, social, privacy, firefox, adobe, overflow, office, cisco, conficker, botnet, pirate, sécurité |
Mini-Tagwall des Tweets de la revue Twitter : | | | | security, linux, botnet, attack, metasploit, cisco, defcon, phish, exploit, google, inject, server, firewall, network, twitter, vmware, windows, microsoft, compliance, vulnerability, python, engineering, source, kernel, crypt, social, overflow, nessus, crack, hacker, virus, iphone, patch, virtual, javascript, malware, conficker, pentest, research, email, password, adobe, apache, proxy, backtrack |
|
|
|
|
|