vendredi 28 août 2009

Compromission d'apache.org

Le site apache.org vient d'être attaqué.
Ils indiquent:
The Infrastructure Team of The Apache Software
Foundation is currently investigating a
potential compromise of one of our servers.
For security reasons most apache.org
services are therefore offline, but will be
restored shortly. We apologies for any
inconvenience this may cause.

Il ne s'agit pas d'une faille d'apache, mais d'une clé ssh compromise, comme ils indiquent sur leur site.
10:42am UTC: Compromise was due to a
compromised SSH Key, not due to any software
exploits in Apache itself.
More details soon.
Nous attendons des détails, donc. Ce genre d'attaque serait effectivement très intéressante à décortiquer pour comprendre comment elle a pu être possible.
Il y a quelque temps, RedHat s'était également fait compromettre via une clé SSH. Le pirate aurait pu signer des paquets (le conditionnel est de mise). cf http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/.
RedHat avait promis fournir toutes les informations relatives à cette attaque, ce que nous attendons toujours.

J'espère qu'Apache aura plus de transparence et indiquera comment la clé a pu être compromise, ce qui a un interêt relatif, et surtout comment la détection et la circonscription de l'attaque s'est faite.

1/ La compromission de la clé peut arriver de multiples manières. On peut imaginer un utilisateur malveillant. On peut imaginer un utilisateur protégeant mal sa clé. On peut imaginer une première compromission d'infrastructures (zf05 nous rappelle bien que les infrastructures mutualisées ne sont pas de confiance)

2/ La détection de l'attaque est donc bien plus intéressante. Quelles sont les méthodes qui ont permis de détecter des manipulations malicieuses? Quelles ont été les actions prises pour circonscrire l'attaquant? Comment revenir à un fonctionnement normal et sain par la suite?

Donc, Wait and See.

samedi 8 août 2009

Résilience

Le site twitter est de nouveau sous le feu de l'actualité.

Il a été victime d'un DDOS, interdisant de fait son accès. On voit fleurir des questions (naïves) de journalistes s'interrogeant sur les causes ayant rendues une attaque de ce type possible.

Ceci dit, cette attaque, tout comme plusieurs autres avant celles-ci me font interroger sur le phénomène de résilience des réseaux. Qu'est ce que la résilience, tout d'abord? Wiktionary m'indique plusieurs définitions dont celles-ci:
-Aptitude à s’adapter, à réussir à vivre et à se développer positivement en dépit de circonstances défavorables et de stress.
-propriété physique d'un matériau de retrouver sa forme après avoir été comprimé ou déformé ; élasticité.
La résilience informatique serait donc double. Tout d'abord la résistance de celui-ci face à tout type de sollicitations (légitimes ou malveillantes), et ensuite la possibilité qu'a celui-ci de retrouver son fonctionnement initial et optimal même après une phase de fonctionnement dégradé.
L'information possède une bonne résilience également tant qu'on la duplique.
Informatiquement, la duplication de l'information se fait à coût nul (j'approxime bien entendu) de ce fait la résilience de l'information au sens large est acquise (ce qui pose bien entendu d'autres problèmes concernant la dualité de protection de l'information. Soit on la duplique à l'infini et son accès sera toujours possible; soit on restreint de manière confidentielle son accès à un emplacement unique et cette information peut être perdue).

On peut de plus parler de résilience à différents niveaux:
-résilience du réseau
-résilience du service
-résilience d'infrastructure

Quelques exemples viennent immédiatement à l'esprit suite à cette définition. Un réseau IP possède une bonne résilience: en effet, il a été conçu à la base pour ce but. La disparition de plusieurs de ses noeuds ne doit pas empêcher la circulation de l'information. Les protocoles de routage adaptatifs ont été conçus dans ce but.
Le service DNS possède une bonne résilience. En effet, il est décentralisé (via l'utilisation d'Anycast, RFC3258) et permet de mettre en oeuvre des mécanismes de serveurs secondaires.
La résilience d'infrastructure va concerner tout ce qui est connexe (matériel comme logiciel), comme l'accès en énergie, les mécanismes de haute disponibilité (hard par le doublement des équipements et soft par les programmes permettant de basculer en cas de problèmes), et les mécanismes de sauvegardes de données.

Ces mécanismes de résilences sont interdépendants, et doivent chacun s'appuyer les uns sur les autres pour offrir une bonne résilience globale.

Pour ce message, je propose quelques réflexions sur certains réseaux dit résilients:

1/ Le P2P
Par P2P j'entends les réseaux de partage Peer-to-peer et les botnets basés sur une technologie de peer-to-peer. C'est le réseau résilient par excellence. Entièrement décentralisé, il peut renaître tant qu'un second hôte est présent. Il est très efficace pour partager de l'information. Toutefois, l'information en elle-même n'est pas résiliente. Une information peut partagée peut progressivement disparaître. De plus, le point crucial de ses réseaux concerne l'accès aux service DNS. En effet, la connaissance des voisins du réseau impose une première requête donnant quelques noeuds qui pourront par la suite donner les noeuds suivant, etc..
La recherche dans le domaine des botnets est à ce sujet intéressante. Les premiers botnets disposait d'un serveur de contrôle et de commande unique (par exemple un canal IRC). Ce dispositif offre une résilience très faible. Le C&C disparaît, le botnet avec. Les auteurs de botnets (comme les auteurs de softs P2P) ont donc migrés progressivement vers des solutions décentralisées.
Toutefois, ces réseaux ne sont malgré tout pas d'une résilience absolue. A ce sujet, l'analyse de certaines analyses sur des botnets précisent qu'en jouant sur les DNS il serait possible de prendre la main et de contrôler ces réseaux.

2/ NNTP et SMTP
Les services NNTP et SMTP possèdent également une bonne résilience intrinsèque. La résilience de NNTP s'appuye uniquement sur la duplication permanente et asynchrone des informations via un système distribué de serveur NNTP. SMTP fonctionne sur le principe asynchrone et sur le routage successif des informations. De plus SMTP peut tout à fait résister à un problème temporaire. Les mails sont conservés, pour être réémis plus tard.

Résilience d'infrastructures
-C'est un point qui me semble très intéressant et à creuser. En effet, la majorité des services sur internet repose des près ou de loin sur DNS. Est-il possible d'imaginer internet sans DNS?
-Résilience d'accès au réseau. Une ville s'est faite couper du réseau internet. Les conséquences en ont été graves.


Le DNS me paraît une bonne piste de réflexion. Nous avons là un service essentiel au bon fonctionnement de tous les réseaux. Par qui transite les requêtes et réponses DNS? Qui peut influer sur ces requêtes et réponses? Si on est attaquant ou utilisateur, quelles conséquences?
Une autre piste concerne BGP et les mécanismes de routage entre les AS. En effet, si plusieurs AS se mettent d'accord, il est possible de faire disparaître du paysage d'internet un de ses acteurs. Voir les liens expliquant cela sur la page wikipedia de mcColo. La question qui suit est double: Comment éviter de se faire déconnecter d'internet? Comment déconnecter une partie d'internet du reste d'internet?

dimanche 2 août 2009

Chiffrement de disques.

Le chiffrement de disques durs, appelé aussi le chiffrement de surface, est une mesure intéressante pour éviter la fuite d'information en cas de perte ou vol de matériels.

J'ai à ce sujet écrit un article dans linux Magazine il y a un an et demi, présentant diverses méthodes pour mettre en oeuvre le chiffrement de partitions sous linux en janvier 2008.
L'article devrait être disponible un jour ou l'autre sur http://www.unixgarden.com . L'article fournissait une méthode offrant de la plausible deniability et une méthode graphique permettant de visualiser le chiffrement (ces deux points ne sont pas considérés dans l'article du blog présent).

Les conclusions de l'article sont les suivantes:
-le chiffrement ne protège les données que lorsque la machine est éteinte
-il reste toujours un angle d'attaque sur la machine chiffrée, correspondant à la partition en clair supportant le noyau et son initrd.

Appliquons ces deux points à l'actualité récente, MISC 45 et la blackhat 2009.

1/ MISC 45
Tout d'abord, j'ai lu dans MISC 45 l'article sur dokuwiki. L'article est intéressant, agréable à lire et j'aime bien cette idée de donner des détails pratiques sur la mise en oeuvre d'un outil.
Ceci dit l'auteur conclut en indiquant (entre autre bons conseils) qu'il est conseillé de chiffrer le disque dur du serveur et du client pour des raisons de confidentialité.

Cette raison me paraît totalement inutile. Pour le serveur tout d'abord. Un serveur, ça sert des pages, donc c'est allumé. Tant que la machine est allumée, le disque est ouvert, la clé de chiffrement présente, l'accès aux fichiers possibles. Donc pour limiter la fuite d'informations de ce serveur, le chiffrement est tout simplement superfétatoire.
Pour la même raison (la confidentialité), l'auteur conseille de chiffrer le disque de la machine cliente qui va éditer un fichier wiki afin de l'uploader sur le serveur dokuwiki; la raison en est simple, en cours d'édition, le contenu du fichier est contenu dans un javascript enregistré localement. Et pour la même raison j'indique que cela est tout autant inutile. Un attaquant sur la machine -allumée bien sûr- aura accès à ce fichier, chiffrement de disque ou pas.

Le chiffrement de disque est utile, mais attention aux raisons qui vous poussent à le mettre en oeuvre...

2/ Fuite de la clé de chiffrement
Une conférence à la blackhat 2009 fournit une méthode pour lire la clé TrueCrypt. Le principe en est simple. Il suffit de s'intercaler entre le disque et le système pour lire la clé alors qu'elle lui est transmise. Je salue l'exploit (l'auteur a ajouté pas mal de petites options intéressantes, citée dans l'article). Ceci dit, je note que l'attaque reste locale puisque elle repose sur l'infection du MBR.
Et cette attaque peut être exactement portée sous linux (l'essence de cette attaque, pas le code du bootkit). Le déchiffrement du disque sous linux est réalisé dans l'initrd (ou initramfs) lors du boot. Et cet initrd/ramfs est situé sur une partition non chiffrée.
Ainsi, un attaquant qui aurait en sa possession un portable chiffré pourrait sans aucun problème modifier cet initrd afin qu'il lise la clé fournie par l'utilisateur, et la dupliquer quelque part sur le disque ou l'envoyer sur le réseau une fois la machine bootée. Cette attaque est tellement simple à mettre en oeuvre que son évocation est un PoC à lui seul.

Pour éviter ceci, dans mon article linux magazine, je préconisais deux méthodes:
-Camoufler le noyau et l'initrd dans les premiers Mo de la partition swap. Après le boot, le swap n'utilise pas ces quelques Mo. Le tout début de la partition swap est à son tour chiffré, empêchant ainsi un attaquant d'analyser les partitions en clair. Méthode relativement lourde à mettre en oeuvre, et qui ne résiste pas à une analyse poussée.
-Mettre le noyau et l'initrd sur une clé USB, qui peut également contenir des clés de chiffrements des disques [2]. Sans cette clé, la machine est inerte. Un attaquant pourra infecter le MBR sans risques pour la confidentialité, puisque ce sera la clé USB qui sera démarrée au boot. Il ne reste qu'a sensibiliser l'utilisateur à cette clé USB pour qu'il ne la laisse pas trainer avec le portable.
La perte de la clé USB en elle même n'est pas forcément grave, il suffit de supprimer la clé de chiffrement du disque contenue dans cette clé USB, puis d'en fournir une nouvelle à l'utilisateur.

Bien entendu, cette attaque peut être portée sous n'importe quel type de chiffrement logiciel. Au boot, windows aura forcément besoin d'un bout de code en clair quelquepart. Et ce code pourra donc être modifié par autre chose. La signature de ce bout de code pourrait être une solution, mais la complexité de mise en oeuvre augmente d'autant.

CONCLUSION/
Le chiffrement de surface doit rester confiné à son utilisation première: protéger les disques éteints (donc plutôt dédiée aux périphériques mobiles ayant des phases d'extinction. Un ordinateur portable semble une bonne idée, un téléphone portable moins, étant la majeure partie du temps allumé). Si elle est étendue à d'autres services (ex chiffrement de disque d'un serveur) la raison doit en être clairement identifiée sous raison de perdre du temps, de la puissance CPU et une augmentation de la complexité lors de la résolution de problèmes (ex: clusters défectueux). Pour finir sur une note humoristique, je conseille la lecture de ce post d'XKCD concernant le chiffrement de disques :)

[1]Pour préciser, j'indiquerai que la phrase "le chiffrement de surface ne protège que les machines éteintes" doit être légerement modifiée. En effet des chercheurs ont mis en oeuvre une attaque appelée cold-boot attack. La RAM conservant un certain temps des informations (dont la clé de chiffrement du disque) après extinction de la machine, il faut modifier la règle en: "Le chiffrement de surface ne protège que les machines éteintes depuis quelques minutes". Ceci dit, tout les limitations concernant le chiffrement de surface restent identiques.
[2]Ce qui a le double avantage de faciliter la vie de l'utilisateur: il veut allumer sa machine, il met sa clé USB, elle démarre. Il n'a qu'a ranger la clé USB de manière sécurisée par la suite. Pas de mot de passe compliqué qui finira écrit sur un post-it, pas de complications et c'est simple à comprendre pour n'importe quel utilisateur. Cerise sur le gâteau la clé peut être perdue sans aucun risque de fuite d'information...