Imaginons un RSSI consciencieux qui décide de chiffrer sa flotte d'ordinateurs portables afin d'éviter la fuite d'information en cas de perte ou de vol, ou de malveillance interne.
Il décide de renforcer la sécurité des machines:
Il décide de renforcer la sécurité des machines:
- Le système installé est linux, dupliqué sur tous les portables.
- Un firewall est configuré à l'aide d'iptables et ce firewall est indispensable à la sécurité de la machine.
- Il a lu mon article concernant le faux sentiment de sécurité lié au chiffrement de disque et utilise une puce TPM pour garantir l'intégrité de la chaîne de démarrage.
Et pourtant, il est possible de casser ce schéma de sécurité. Vous êtes un pentesteur (par exemple), et vous voulez accéder à la machine d'un tiers. Vous avez temporairement un accès à cette machine, comment faire?
1/ Tout d'abord, inutile d'essayer de casser le code de déchiffrement par force brute. On considère que les utilisateurs ont eu une bonne formation et que le mot de passe de déchiffrement est solide.
2/ Inutile de vouloir casser le chiffrement lui même. C'est de l'AES, et vous n'êtes pas Mr Filiol.
3/ L'utilisateur éteint toujours son portable lorsqu'il le quitte. Impossible de lancer une attaque cold-boot.
4/ Essayer de modifier le noyau ou l'initrd du démarrage afin qu'il enregistre le mot de passe entré ne mène à rien: la puce TPM permet de vérifier les métriques du boot et le déchiffrement de la racine n'aboutira pas, provoquant immédiatement une réaction de l'utilisateur.
5/ Changer le portable complet (le chassis) par un autre dont le rôle est de ressembler au portable dans la phase de demande de clé de déchiffrement pour l'envoyer immédiatement par le réseau ne fonctionne pas non plus, le RSSI à pensé à les marquer afin d'éviter les échanges malheureux. Ceci dit, il est toujours possible de changer le disque et de jouer cette méthode, mais le possesseur du portable comprendra immédiatement qu'il y a un problème et pourra prendre des actions correctives. Vous souhaitez accéder à de l'information, vous ne voulez pas que cet accès soit découvert.
6/ Une attaque réseau n'aboutit pas non plus. Le firewall iptables est trop bien configuré pour cela.
Solution après le saut.
Le chiffrement protège la confidentialité des données, mais pas leur intégrité.
Les portables descendent tous du même master.
L'attaquant possède un portable dont les fichiers systèmes sont situés au même endroit sur le disque que sur le disque de la victime.
L'attaque consiste donc a repérer géographiquement où est situé le programme iptables. Sur le portable de la victime, booter depuis un liveCD, et écrire quelques dizaines d'octets à l'emplacement d'iptables.
Attendre que la victime démarre son portable. La lecture du fichier iptables va se faire, sauf qu'il ne s'agira clairement pas d'un binaire ELF. Le firewall ne sera donc pas actif.
Pour l'attaquant, il devient donc possible de lancer des attaques par le réseau: le schéma de sécurité mis en place par le RSSI est donc cassé. Win.
Je pense que cela doit être généralisable sur à peu près n'importe quel système ou il est possible de savoir précisément ou sont les données à écraser (par exemple une base de données antivirales avant de lancer une attaque).
Je n'ai pas vérifié s'il existe des systèmes de chiffrement de disque proposant l'intégrité des données chiffrées, mais cela me semble une option intéressante à mettre en regard de la chute en performance du disque.
Clairement, le problème vient du master, qui créer des clones identiques. La solution ne serait-elle pas de changer le salage pour chaque machine ?
RépondreSupprimerHello,
RépondreSupprimerQuelques questions:
-Dans le cas d'un AES-CBC, est-ce que la modification du disque chiffré ne va pas planter le déchiffrement à cause du chainage ?
-Dans le cas d'un disque chiffré avec diffuseur avec une clé, cette attaque deviendrait caduque ?
Étienne, effectivement, dans le cas de CBC toute la suite sera corrompue. Cependant, je ne pense pas que les programmes de chiffrement de disque utilisent CBC (ou en tout cas pas sur tout le disque), cela nécessiterait, pour lire une donnée arbitraire, de déchiffrer tout ce qui précède ! Ils utilisent plus probablement CTR, ou bien un système où le disque est découpé en petites parties qui disposent chacune de sa clé (ou au moins, de son IV).
RépondreSupprimerCela dit, je pense que le système d'init d'un tel portable sécurisé devrait tout simplement refuser le login si un des programmes critiques comme le pare-feu n'a pas réussi à se lancer.
La configuration en elle-même de ces programmes pourrait être scellée avec un programme comme Samhain, Tripwire ou AIDE.
Bitlocker utilise AES-CBC avec un diffuseur éléphant propriétaire microsoft. Après effectivement, je pense que Bitlocker sépare le disque en parcelles pour des questions de perf mais can rend dans tous les cas l'attaque infaisable.
RépondreSupprimerPar rapport au lancement du système en cas d'erreur avec un composant système, est-ce que ce type de composant existe sous Linux ?
C'est le système communément appelé "init" qui réalise toutes les tâches de lancement d'une distribution linux. Il est lancé par le noyau une fois celui-ci chargé, et fait ensuite, classiquement, le montage des partitions, la configuration du réseau, le lancement des programmes de boot, etc. Il se termine par le programme de login.
RépondreSupprimerIl existe de nombreux systèmes d'init, presque chaque distribution en a un différent.
Mais que ce soit quelques scripts très simples (Archlinux...) ou des programmes un peu plus complexes (upstart sur Ubuntu...), ils sont tous très configurables. Il devrait être relativement simple par exemple de désactiver les interfaces réseau si le firewall ne s'est pas lancé, d'en avertir l'utilisateur, et de l'empêcher d'utiliser l'ordinateur.
@Alserweiss: le changement de sel ne modifie pas la position géographique des fichiers. Si je sais qu'au 256325e octet du disque, je suis sur /sbin/iptables, alors il sera écrasé quel que soit le sel ayant servi à chiffrer. Le cas du sel identique pose un autre problème :-)
RépondreSupprimer@Etienne: S'il y a un chainage, cela signifie que pour lire juste un octet sur le disque, il faut lire l'intégralité des précédents. Inapplicable en pratique. Chaque bloc peut être lu indépendamment des autres.
Pour le système avec diffuseur de clé, je ne suis pas sûr de comprendre.
@Hugo: Je suis d'accord, un système de monitor devrait être mis en place pour éviter ces soucis. Mais dans ce cas il reste possible d'écraser également ce système de monitor (moyennant adaptation bien sûr).
@Etienne: L'attaque reste toujours faisable. Une autre manière de voir les choses consiste à imaginer un défaut de lecture d'un disque (en clair ou chiffré, peu importe). Le système lit un fichier, corrompu. Comment réagit le système?
De la réponse à cette question découlera la réalité de l'attaque.
Le moyen de détecter la corruption sur un système chiffré serait d'utiliser de l'intégrité lors du déchiffrement, mais à ma connaissance ça n'existe pas. De mémoire, sur la ML de cryptsetup ça avait été écarté pour des raisons de perfs.
Il est possible d'utiliser n'importe quel système de détection d'intégrité sous linux, par exemple une vérification des sommes SHA1 de divers fichiers dès le boot par un script, ou d'autres systèmes, indiqués par Hugo.
@Hugo: Yup. Ceci dit l'article est plus là pour poser le problème de la non vérification de l'intégrité des fichiers chiffrés par un exemple hypothétique mais concret, que de vouloir protéger le portable :)
Pour la perf, quid de http://en.wikipedia.org/wiki/Galois/Counter_Mode ?
RépondreSupprimer(Je m'avance sur un terrain inconnu, mais d'après l'article c'est justement le point fort de ce mode de chiffrement authentifié)
Effectivement ce type d'attaque est possible sur Bitlocker mais avec plusieurs contraintes.
RépondreSupprimerBitlocker utilise AES-CBC et un diffuseur appelé Elephant:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13866
En fait il fait du chiffrement AES-CBC des secteurs du disque (entre 512 et 8192 octets). Le diffuseur lui, mélange les octets dans le secteur avant de chiffrer en AES-CBC.
Il devient donc impossible de modifier uniquement une partie du secteur déchiffré.
Cependant, il est possible qu'un secteur de 512 octet ne contienne une partie d'un seul exécutable, et donc de corrompre uniquement cet exe. Mais cela devient de moins en moins probable si la taille des secteurs augmente.
Si on ajoute le fait qu'il faille connaitre la place des fichiers avant l'attaque, ca devient de moins en moins probable.
@Hugo: Ca a l'air intéressant mais le problème reste toujours le stockage du auth tag sur le disque.
La réponse à ta question se nomme IMA/EVM. Elle permet d'ajouter aux attributs étendus des fichiers une signature faite par TPM à partir d'une Master Key.
RépondreSupprimerQuand aux attaques sur TPM, il existe malheureusement celle-ci. ;)
http://testlab.sit.fraunhofer.de/content/output/project_results/bitlocker_skimming/ (le site semble down)
@Alserweiss: Je reviens sur ton commentaire. Il n'est je pense pas question de sel, mais de clé de chiffrement.
RépondreSupprimerSous linux, (dm-crypt et cryptsetup), nous avons une clé de chiffrement générée aléatoirement appelée master key et protégée par une passphrases (ou plusieurs, pour un max de 8).
Si on duplique l'intégralité des disques, alors la même master-key est utilisée. Comme la master-key est la même, l'attaquant peut la lire sur sa machine (dmsetup --showkeys) et s'en servir pour lire/modifier des données d'un autre disque.
Il faut donc régénérer pour chacun des portables la master-key, ce qui se fait à la création, donc à l'installation du système.La précision s'impose, effectivement.
@Serianox: Si je lis la page du testlab.sit.fraunhofer.de cela implique deux boots successifs, le premier échouant. C'est tout à fait vrai mais charge à l'utilisateur de prendre les actions qui s'imposent s'il détecte un boot en échec. Le TPM n'est pas une solution magique à tous les problèmes. Ceci dit la partie "Current implementations of Trusted Computing in personal computers do not include the keyboard in their measurements and also do not establish a secure channel to the keyboard" semble plus intéressante, mais non explorée? Et le clavier semble le bon endroit pour planter un keylogger :-)
Pour récupérer des données chiffrées, il sera toujours possible de remplacer le contenu du portable de la victime par une distribution qui logge le mot de passe TPM et l'envoie via SMS par exemple puisqu'on peut mettre des puces 3G dans les portables p.ex.
J'ai lu sur une mailing liste : "Le chiffrement ne protège vos données que si vous savez si l'attaquant y a eu accès". C'est on ne peut plus vrai, mais cela réduit énormément l'usage de celui-ci. Le TPM élève le niveau de sécurité mais ne résoud pas tout.
" Le chiffrement protège la confidentialité des données, mais pas leur intégrité. "
RépondreSupprimermalheureusement ...