Ma grand mère avait hérité d'une recette de tripoux particulièrement savoureuse, ce qui m'amène à mon sujet d'aujourd'hui lié à cette fameuse cyberguerre dont tout le monde parle.
Au début d'internet il était admis que la sécurité informatique ne reposait que sur un socle défensif: antivirus, firewall, log, etc..
A lire différents blogs et communiqués aujourd'hui, on entend parler de plus en plus ouvertement de cyberguerre, de lutte offensive et du cyberespace comme nouveau champ de bataille. La transition s'est faite approximativement avec Stuxnet, lorsque le monde s'est rendu compte que l'informatique impalpable avait finalement les pieds très ancrés dans le monde physique. On est passé d'un discours purement défensif à un discours ouvertement offensif. Le défensif a montré ses limites, un général US disait à ce sujet que le temps de réponse est beaucoup trop court: "A piece of information can circumnavigate
the globe in about 133-134 milliseconds, your decision space
in cyber [is] half that". La fin de son discours est clairement tourné vers l'offensif: "Today, the offense clearly has the
advantage, Get cyber legislation in there, bring industry and
government together, and now we have the capability to say 'You don't
want to attack us. We can stop it and there are other things that we can
do to really make this hurt.".
On a pu voir dernièrement l'OTAN diffuser un draft qui souhaite légaliser la cyberguerre. Le but de ce document est d'appliquer/d'adapter au mieux les lois régissant la guerre conventionnelle au "cybermonde". Par exemple, qu'est ce qui peut être pris comme une intention belliqueuse, quelles répliques sont admises, etc..
Il reste toutefois un dernier point, communément partagé: A la différence du monde physique ou l'ennemi est visible et identifiable, contre qui tourner ses armées lorsque l'attaque vient d'Internet? The
department has made significant advances in solving a problem that makes
deterring cyber adversaries more complex: the difficulty of identifying
the origins of that attack. Over the last two years, DoD has made significant
investments in forensics to address this problem of attribution and
we're seeing the returns on that investment. Potential aggressors should be aware that the United States
has the capacity to locate them and to hold them accountable for their
actions that may try to harm America. ". Ce point est vraiment nouveau dans le discours "cyberguerrier", il indique clairement que l'anonymat est en train de disparaître, ce qui implique entre autre qu'un APT ne pourra plus prospérer car on est capable d'en identifier l'auteur.
Mais allons un peu plus loin dans la réflexion. Les états sont donc de plus en plus sensibilisés aux questions d'attaques informatiques aussi bien destructives que disruptives ou aux intrusions. Les discours politiques visent à protéger les infrastructures publiques. On ne peut qu'anticiper que cette protection va s'étendre aux OIV (Organismes d’Intérêt Vitaux).
Ma grand-mère m'a légué la recette du tripoux que le monde entier envie. Devant la qualité de ce plat, j'ai décidé de monter une entreprise pour promouvoir ces saveurs inimitables. J'ai misé sur la vente par internet. Et un problème se pose avec mon usine de tripoux en conserve. Qui me protégera d'un acte de piratage ou d'une copie infâme? Un tripoux à bas prix pourrait voir le jour si on vole la propriété intellectuelle de ma recette. Un concurrent malveillant pourrait infecter mon usine pilotée par système scada afin d'accélérer la cadence de mes salières pour rendre mon tripoux impropre à la consommation (ma grand-mère me disait toujours: sans trop de sel et à feu doux!). Plusieurs attaques peuvent empêcher mon site web de vendre, depuis le (D)Dos en passant par la modification des commandes en ligne. Contre toutes ces attaques, je n'ai pas d'autre choix que de mettre de la sécurité classique (AV, firewall, patching policy, IDS, SIEM, etc..) qui bloquera les 80% des attaques basiques, mais qui n'empêcheront pas les drames décrits ci-dessus. L’État est capable de prendre des mesures pour protéger ses infrastructures, mais pour les miennes?
Jusqu'où la protection publique qui dispose d'une force de frappe conséquente ira pour protéger les acteurs privés qui sont en droit d'attendre cette protection? Cette question en recouvre d'autres:
-Dans quelle mesure les cyberattaques vont-elles modifier les pouvoirs de la police étatique vis à vis de l'Internet et par là même rogner sur les libertés d'Internet?
-La "police du net" restera t'elle longtemps l'apanage des sociétés privées alors que l'État est de plus en plus impliqué dans la protection de son cyberterritoire et de ses intérêts
-Est-ce la fin d'un Internet anonyme et sans frontières?
mercredi 24 octobre 2012
jeudi 4 octobre 2012
Etes vous les 20% ?
J'ai lu deux papiers dernièrement qui traitent un thème commun. Le premier est l'édito de MISC septembre-octobre dans lequel un paragraphe a retenu mon attention: "Un peu de réflexion et de bon sens permettrait déjà de régler nombre de problèmes. Par exemple, au lieu de déployer des anti-virus, IDS/IPS, WAF et autres outils de filtrage qui n'arrêtent que le bruit ambiant d'Internet, peut-être qu'analyser et comprendre les 20-30 failles critiques qui sortent par an suffirait à déployer une défense ciblée, adaptée à ces risques ? Encore faut-il être capable d'identifier ces 20-30 failles ...". Le second est un article de blog de Carnal Ownage qui donne une piste de réflexion "We should stop trying so hard to stop the 80% of low sophistication attackers and focus on the 20% of attackers we really care about and who can really hurt us".
Le blog de Carnal0wnage est un peu plus disert que l'edito de MISC et donne des détails sur le contenu de ces pourcentages. Les 80% ont pour but des vols de numéros de sécu ou CB, de l'envoi de mail, de l'ajout de bandeaux publicitaires ou de defacer du site web. Leurs techniques sont des techniques massives, du scan au malware en utilisant des failles anciennes (appelées 1day). Le but des 20% est de voler de la propriété intellectuelle, d'obtenir des informations confidentielles afin de bénéficier d'une avance (législative, négociation, paris, etc..), pouvoir endommager des architectures physiques dans une optique de perte financière, décrédibiliser une entreprise et même de voler des codes sources afin de trouver des 0day ou de les modifier. Leurs techniques sont plus pointues et regroupent des 0day, du spear phishing, des APT, des AET (combo buzzword!), utilisent des certificats volées, implantent du malware dès la chaîne de construction et réussissent à exploiter les relations de confiance.
On observe effectivement une bonne dichotomie entre d'un côté des attaques de "masse" et de l'autre des attaques "ciblées". Apparemment, une bonne expérience[1] de la sécurité informatique permet d'éviter les scans massives et les 1days (finalement le trio infernal firewall/antivirus/IDS fonctionne un peu :) ) Attaques de masse => réponse standardisée. Pour ces 80%, normalement, pas de soucis, l'ANSSI vient même de créer un checkup à réaliser (ou pas).
Bien évidemment le problème est posé par les attaques ciblées. On sait très bien qu'un firewall ne bloque ni n'analyse un flux https sortant ou qu'un antivirus est aveugle devant un exploit préparé pour, qu'un social engineering efficace contourne beaucoup de protections. Alors, quelles solutions avons nous pour ces 20%? MISC conseille l'étude de ces failles pour en déduire une défense ciblée. Certes, mais laquelle, et en regard de quelle faille? CarnalOwnage propose une option offensive (?) ou une option d'augmentation des coûts pour l'attaquant (par des méthodes de SIEM semble t'il). Je reste dubitatif vis à vis de ces lignes de défense. L'offensif pourquoi pas, le mot cyberguerre commence à être employé de plus en plus souvent, mais contre quel ennemi? A l'opposé du champ de bataille ou l'ennemi est connu puisqu'en en face, qui attaquer lorsque l'ennemi est invisible? Tabler sur la peur? Je n'y crois pas. Les SIEM (ou assimilé) pour faire augmenter le coût de la réussite de l'attaque? Est-ce possible d'estimer le coût qu'espère tirer l'attaquant de son action?
L'informatique et le réseau permet de relier des systèmes et des personnes afin qu'ils communiquent entre eux. Les attaquants tirent partie de ces personnes et communications. La sécurité veut empêcher tout ou partie de ces communications. Equation impossible?
[1] ou hygiène? :)
Le blog de Carnal0wnage est un peu plus disert que l'edito de MISC et donne des détails sur le contenu de ces pourcentages. Les 80% ont pour but des vols de numéros de sécu ou CB, de l'envoi de mail, de l'ajout de bandeaux publicitaires ou de defacer du site web. Leurs techniques sont des techniques massives, du scan au malware en utilisant des failles anciennes (appelées 1day). Le but des 20% est de voler de la propriété intellectuelle, d'obtenir des informations confidentielles afin de bénéficier d'une avance (législative, négociation, paris, etc..), pouvoir endommager des architectures physiques dans une optique de perte financière, décrédibiliser une entreprise et même de voler des codes sources afin de trouver des 0day ou de les modifier. Leurs techniques sont plus pointues et regroupent des 0day, du spear phishing, des APT, des AET (combo buzzword!), utilisent des certificats volées, implantent du malware dès la chaîne de construction et réussissent à exploiter les relations de confiance.
On observe effectivement une bonne dichotomie entre d'un côté des attaques de "masse" et de l'autre des attaques "ciblées". Apparemment, une bonne expérience[1] de la sécurité informatique permet d'éviter les scans massives et les 1days (finalement le trio infernal firewall/antivirus/IDS fonctionne un peu :) ) Attaques de masse => réponse standardisée. Pour ces 80%, normalement, pas de soucis, l'ANSSI vient même de créer un checkup à réaliser (ou pas).
Bien évidemment le problème est posé par les attaques ciblées. On sait très bien qu'un firewall ne bloque ni n'analyse un flux https sortant ou qu'un antivirus est aveugle devant un exploit préparé pour, qu'un social engineering efficace contourne beaucoup de protections. Alors, quelles solutions avons nous pour ces 20%? MISC conseille l'étude de ces failles pour en déduire une défense ciblée. Certes, mais laquelle, et en regard de quelle faille? CarnalOwnage propose une option offensive (?) ou une option d'augmentation des coûts pour l'attaquant (par des méthodes de SIEM semble t'il). Je reste dubitatif vis à vis de ces lignes de défense. L'offensif pourquoi pas, le mot cyberguerre commence à être employé de plus en plus souvent, mais contre quel ennemi? A l'opposé du champ de bataille ou l'ennemi est connu puisqu'en en face, qui attaquer lorsque l'ennemi est invisible? Tabler sur la peur? Je n'y crois pas. Les SIEM (ou assimilé) pour faire augmenter le coût de la réussite de l'attaque? Est-ce possible d'estimer le coût qu'espère tirer l'attaquant de son action?
L'informatique et le réseau permet de relier des systèmes et des personnes afin qu'ils communiquent entre eux. Les attaquants tirent partie de ces personnes et communications. La sécurité veut empêcher tout ou partie de ces communications. Equation impossible?
[1] ou hygiène? :)
mardi 11 septembre 2012
Le chiffrement de disque sous linux: Second strike
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.
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.
Inscription à :
Articles (Atom)