lundi 13 décembre 2010

CyberWar AfterMath

J'ai reçu un abondant courrier des lecteurs (ou plutôt un téléphone arabe des lecteurs devrais-je dire) autour de mon dernier billet, se résumant en gros à un déluge de critiques fondées sur ma prétendue illégitimité dans le domaine (pour simplifier).

Il est vrai que je n'ai pas eu l'occasion de présenter dans des conférences spécialisées, ou de participer à des "cyber-exercices" (même si je vais me permettre de bloguer là-dessus prochainement).

Mais puisque la première cyberguerre mondiale n'a pas encore eu lieu, il me semblait pourtant que mon opinion sur le sujet était tout aussi recevable que celle de n'importe qui - tout le monde en est réduit à des spéculations dans le domaine.

J'oserais même penser qu'en tant que professionnel de l'informatique, mon opinion est plus qualifiée. Car si tout le monde peut intuiter la dangerosité d'une grenade ou d'une baïonnette sans jamais en avoir utilisé une, il en est autrement dans le domaine informatique où aucune analogie avec le monde physique ne fonctionne. Les théoriciens de la cyberguerre n'ont pour la plupart aucune idée de ce qui se produit lorsqu'ils allument leur téléphone ou lorsqu'ils envoient un email. Ce qui les conduit à des conclusions absurdes, comme HADOPI l'installation d'un bot contrôlé par le gouvernement américain sur le PC de tout bon citoyen, ou le bouton rouge qui permet d'arrêter Internet.

Il en est ainsi des domaines techniques comme l'informatique ou la réparation de télé: personne ne peut avoir d'intuitions sans expérience. Le problème c'est qu'en informatique comme dans beaucoup de domaines de la vie courante (l'économie, la politique, etc.), absolument tout le monde a une solide opinion.

La différence entre un professionnel de l'informatique et un technicien, voire un simple utilisateur, est la même qu'entre un prof de maths qui enseigne en prépa et un prof de collège. Le premier doit faire face constamment à des situations qui le poussent aux limites de ses capacités, tandis que le second rabâche à des ignorants des concepts à apprendre par cœur (ton mot de passe doit être complexe, tu ne dois pas le noter sur un post-it, tu dois utiliser un antivirus, etc.).

Bien sûr, dans l'éducation nationale comme dans l'informatique, il existe de vrais passionnés à tous les niveaux, qui s'attaquent à des problèmes non résolus – le plus souvent sur leur temps libre.

Malheureusement, au bout du compte, l'opinion majoritaire reflétée par les médias et couramment admise (même au plus haut niveau) est bien loin des réalités techniques les plus élémentaires. Si vous avez 30 minutes à perdre, et que vous voulez vous payer une bonne tranche de rigolade, je vous conseille de regarder un récent reportage intitulé "les nouveaux pirates de l'informatique", suivi par "alerte à la cyberguerre". C'est disponible partout sur Internet, mais je ne peux pas vous donner de lien ici – seul Google a le privilège d'être au-dessus des lois.

Revenons à nos moutons

Ce débat sur la cyberguerre est né de mes réflexions sur StuxNet. Tout le monde s'extasie sur la "complexité" d'un tel code. Au gré des conférences ou de mes lectures sur Internet, j'ai pu entendre que StuxNet représentait 9 mois*hommes de travail, ou 10 millions de dollars. Ces chiffres sont bien entendu totalement fantaisistes, puisque le pays d'origine du virus – et donc le salaire moyen des développeurs – reste inconnu :)

On peut noter toutefois que la complexité d'un tel code est largement surestimée par les personnes qui ne sont pas des professionnels de l'informatique – tout comme un collégien va trouver la démonstration du grand théorème de Fermat incroyablement complexe, ce qui n'est pas forcément l'avis d'un professeur de prépa.

Prenons le cas du laboratoire privé Sogeti/ESEC. Malgré les fonds et les effectifs limités dont ils disposent, ils viennent pourtant de réimplémenter une attaque sur des cartes réseau, dont l'implémentation précédente était le fait d'un laboratoire de l'ANSSI. Est-ce à dire que "cinq gus dans un garage" peuvent rivaliser avec les services de l'état ? Je pense que oui (au facteur d'échelle près, les ressources de l'état étant illimitées), car la sécurité informatique est avant tout une affaire de matière grise – une ressource impossible à produire et difficile à capter.

Les techniciens informatiques (et a fortiori le grand public) sous-estiment les capacités des "vrais" hackers de plusieurs ordres de magnitude. Un seul homme (ou femme :) vraiment compétent remplace aisément 10 à 100 informaticiens peu motivés comme on en rencontre presque partout. Les exemples de Google (ou de Free) sont là pour nous le rappeler.

Pourquoi on ne voit rien … et ce qui se passe vraiment

Ce biais de perception provient essentiellement de la structuration du monde de la sécurité (aussi appelé le Security Circus).

Il faut bien comprendre que toutes les publications (dans les magazines ou les conférences) sont intrinsèquement sans valeur: ce ne sont ni des résultats produits pour des clients, ni des attaques dangereuses ou illégales, ni des technologies revendables ou brevetables.

Tout ce qui est réellement dangereux, parfois à la limite de la légalité, passe complètement en dessous du radar et "n'existe pas" pour la presse et le grand public en général. Et pourtant cette "masse manquante" représente l'essentiel des travaux produits par les professionnels de la sécurité dont l'activité présente suffisamment d'intérêt pour être financée (c'est-à-dire ceux qui en vivent d'une manière ou d'une autre).

Vu de l'extérieur, ceci donne l'impression que ce petit monde ronronne gentiment, de sauteries en conférences, sans vraiment empêcher le business de tourner rond. Ce qui est loin d'être représentatif de l'état de la menace aujourd'hui …

En vérité, tous les systèmes connectés à Internet sont sous le feu permanent d'intrus (qu'on va appeler "les chinois" pour simplifier – et c'est probablement d'ailleurs le cas). Suis-je mythomane ? Probablement pas, car j'ai eu l'occasion de les rencontrer "pour de vrai" à plusieurs reprises …

La véritable cyberguerre a déjà commencé, mais elle ne ressemble pas à ce qu'on nous présente d'habitude (pays désorganisé, infrastructures critiques en panne, etc.). Pour cela, quelques centimètres de neige suffisent :)

La véritable cyberguerre, c'est le pillage systématique de toutes les ressources technologiques occidentales par des individus entrainés, opiniâtres, et opérant en dehors de toute juridiction. Toutes les entités, des instances étatiques à la plus petite PME, sont victimes de ce ratissage systématique opéré par des attaquants qui ne connaissent pas le repos ni la compassion.

Là où les cybergénéraux attendent des DDoS massifs, par analogie avec les bombardements bien connus dans le monde physique, le réel danger provient de la cinquième colonne qui a probablement infiltré tous les systèmes connectés à Internet à l'heure où j'écris ces lignes (l'opération Aurora n'étant que la partie émergée de l'iceberg).

Une autre cyberguerre est possible

Ce qui se passe actuellement avec le site WikiLeaks me semble également relever de la cyberguerre, du moins de l'attaque non conventionnelle.

En me gardant bien de me prononcer sur le fond, cet épisode met en évidence la dépendance très forte du "cybermonde" vis-à-vis d'entités commerciales américaines bien réelles (à savoir EasyDNS, Paypal, MasterCard, Visa, … dans le cas présent).

Sans rentrer dans des scénarios trop compliqués, on imagine assez aisément que si demain un secrétaire d'état américain demande à l'ICANN, Microsoft, VeriSign, Cisco, et tous les opérateurs Tier-1 américains de bloquer les infrastructures d'un pays occidental, le résultat risque d'être assez catastrophique … et ce sans utiliser un seul virus !

Tout comme la redirection de l'Internet mondial au travers d'un opérateur chinois pendant une vingtaine de minutes (avril 2010) expose une autre fragilité rarement abordée dans les cyberdoctrines: BGP.

Conclure sur StuxNet

Le sabotage informatique est une activité à peu près aussi ancienne que l'informatique. En 1982 déjà, l'explosion d'un pipeline russe a très probablement été provoquée par le sabotage d'un système SCADA par la CIA. On doit pouvoir trouver des exemples similaires du côté de la fusée Ariane, même s'ils ne sont pas sur Wikipedia.

Aujourd'hui le PC sous Windows XP est effectivement devenu le consommable de base qui permet de contrôler à peu près tout et n'importe quoi. Un sabotage réussi aura toutes les chances d'impliquer de l'informatique à un moment ou un autre. Mais cela n'a rien de "magique" ou d'exceptionnel: c'est un métier !

Il est déjà assez simple (dans la plupart des cas) d'analyser des systèmes "fermés", comme le démontrent toutes les conférences de sécurité ces 15 dernières années, au cours desquelles les sujets les plus divers ont été abordés: logiciels propriétaires bien sûr, mais aussi faiblesses de conception des architecture PC, modems/routeurs, téléphones, consoles de jeu, radiocommunications comme le GSM ou le RDS/TMC, puces RFID, TPM, satellites, etc.

Si un étudiant arrive à pirater l'iPhone et la PlayStation 3 (avec un hyperviseur matériel conçu par IBM), on peut supposer que n'importe qui est capable de pirater un système SCADA avec très peu de moyens.

Mais si j'étais demain à la tête de l'opération "StuxNet 2", je ne m'embarrasserais pas des détails. Avec ses 427,000 collaborateurs, on peut supposer qu'il n'est pas trop difficile de pénétrer le réseau interne de Siemens. Il suffit ensuite d'aller y chercher la documentation et les codes sources nécessaires. Comme 100% des tests d'intrusion internes sont couronnés de succès, il n'est pas trop difficile d'être optimiste.

La présentation donnée par Val Smith lors de BlackHat 2010 sur le dynamisme de la "scène" chinoise permet de se rendre compte à quel point de telles opérations sont monnaie courante ... même si personne n'en parle.

Conclusion

Avant de coller le préfixe "cyber" à toutes les sauces, il est recommandé de passer le test suivant.

Car si une chose telle que la "cyberguerre" existe, elle ne ressemble ni à un DDoS, ni à StuxNet.

lundi 4 octobre 2010

L'échec de la CyberGuerre

Il n'est pas besoin d'introduire le "fameux" ver Stuxnet, tant les médias (y compris généralistes) se sont gargarisés de cette attaque.

Maintenant que les souches sont disponibles sur Internet, ainsi que des analyses techniques très détaillées, il m'est possible d'avancer quelques réflexions étayées sur le sujet.

Ce ver représente l'échec flagrant de la CyberGuerre, autre sujet d'actualité s'il en est.

Tout d'abord, commençons par une assertion totalement invérifiable: ce ver ciblerait une installation nucléaire iranienne. Brillante idée. Soit il s'agit d'endommager une vanne ou une pompe - ce qui se répare en quelques jours. Soit il s'agit de provoquer l'explosion de la centrale: un nouveau Tchernobyl en quelque sorte …

Notons que d'après F-Secure, la plateforme DeepWater Horizon utilisait les mêmes équipements Siemens PLC … Il ne faut pas en tirer de conclusions hâtives, mais sachant que ce ver va tourner pendant quelques années (les clés USB étant le vecteur d'infection numéro un aujourd'hui), on peut facilement imaginer que les dommages à venir risquent d'être importants … et imprévisibles.

Un code malveillant comme Stuxnet s'apparente à une arme bactériologique: même s'il semble verrouillé sur une cible donnée, sa propagation est globalement incontrôlable, et les dommages collatéraux peuvent être largement supérieurs à l'intérêt tactique de l'attaque. Il faut avoir des testicules en titane pour lâcher une telle bombe dans la nature, et espérer que ses propres systèmes – ni ceux de ses alliés – ne seront affectés ni par le ver lui-même, ni par les failles révélées (comme le mot de passe Siemens en dur, qui ne peut toujours pas être changé).

Regardons maintenant les dommages collatéraux de Stuxnet:


Cette faille ayant été corrigée en août 2010, les systèmes Windows XP antérieurs au SP3 (ainsi que les Windows XP Embedded compilés avant cette date) resteront éternellement vulnérables à cette faille d'exécution de code depuis une clé USB.


Celle-là ne compte pas, car elle avait déjà été publiée dans le magazine Hakin9 il y a un an et demi. Il faut croire que personne au MSRC ne lit la presse "pirate" :)

  • Faille(s) d'élévation de privilèges.

Ces failles sont documentées dans les analyses techniques (et même disponibles sur étagère), mais non corrigées par Microsoft à l'heure où j'écris ces lignes. Il n'y a plus qu'à attendre les malwares qui vont les exploiter.

Bilan: les risques pour la sécurité informatique mondiale se sont durablement accrus, et la cible a été manquée. Sauf si le seul objectif de ce ver était d'augmenter les budgets alloués aux SCADA et à la CyberGuerre, bien sûr :) Bienvenue dans le mois du Cyber Awareness !

lundi 30 août 2010

Un compte-rendu à froid de SSTIC 2010 (2ème partie)

Est-ce qu'on est tous foutus ?

La conférence de clôture du SSTIC s'est aventurée sur de nombreux terrains, sans langue de bois (même si certains messages ont été délivrés à mots couverts). Difficile dans ces conditions de résumer, et surtout de produire une exégèse pertinente sur cette intervention, d'autant que je n'ai pas compris si les opinions personnelles de l'intervenant, ou la doctrine officielle de l'Etat français, y étaient exprimées. Je vais toutefois m'y essayer.

*
* *
Jetons un voile pudique sur l'idée que l'attaque est inutile à la défense. Cette idée a déjà été battue en brèche en séance, puis dans les compte-rendus ultérieurs publiés sur Internet. Je concède toutefois qu'il est inutile de chercher de nouvelles failles tant il en existe déjà. La faiblesse des mécanismes d'authentification dans les systèmes Windows est un problème déjà largement insoluble (attaque dite pass the hash, entre autres).
*
* *
Ce qui m'a le plus frappé, c'est d'entendre que face aux échecs flagrants et répétés de la sécurité informatique, l'une des solutions proposées consistait à déployer massivement des IDS.

Les IDS faisant partie des échecs les plus retentissants dans l'industrie de la sécurité, cette assertion a de quoi surprendre. Et pourtant elle est parfaitement justifiée, car son auteur ne cherche pas à protéger les systèmes, mais simplement à faire prendre conscience aux responsables de ces systèmes de l'étendue du désastre.

Je reste malgré tout circonspect. L'échec commercial des IDS, outre les limitations techniques des produits existants, s'explique aussi par la recherche de l'ataraxie. Pour exploiter un IDS, il faut engager des personnes compétentes dédiées au traitement des alertes, mettre en place des procédures, éventuellement impacter la production par du forensics, et toutes sortes de choses désagréables du même acabit. Dans ces conditions, ne rien voir est beaucoup plus confortable ^H^H^H beaucoup moins cher.

Dans le cas contraire, et comme le rappelle Michal Zalewski dans un billet original, quelques astuces permettent de réaliser un IDS du pauvre, pour peu que l'emplacement des "pièges" ne soit pas divulgué. Le plus cher dans la détection d'intrusion reste le traitement de l'incident, pas sa remontée. Déployer des IDS n'est que la première étape, que beaucoup n'ont jamais franchie. Wait and see.
*
* *
L'impasse dans laquelle se trouvent actuellement toutes les personnes en charge de la protection des systèmes s'explique par quelques fondamentaux déjà rappelés sur ce blog.

Le principal problème est que l'informatique grand public (ce qui couvre le matériel - ordinateurs personnels et téléphones mobiles, le logiciel, et les contenus/services disponibles) a complètement échappé à toute forme de contrôle par les clients finaux, y compris l'Etat.

Outre les exemples d'Apple et Google qui n'en font qu'à leur tête dans tous les domaines (ex. interopérabilité pour le premier et contenus numériques pour le deuxième), on peut également rappeler que :
  • La loi est tout simplement bafouée par les CLUF. Toutes les protections basiques du consommateur (ex. vices cachés) ne sont jamais appliquées aux logiciels.
  • Le budget de l'ANSSI est de 90 millions d'euros, alors que les simples revenus publicitaires de Google étaient de l'ordre de 10 milliards de dollars ... en 2006.
  • Comme le déplore l'intervenant, notre dépendance aux technologies étrangères est totale.
Par ailleurs, les technologies de l'information sont devenues une commodité, ce qui entretient dans l'esprit du grand public (j'entends par là toute personne dont l'informatique n'est pas le métier - ce qui s'étend jusqu'au plus haut niveau de l'Etat ...) que "ça marche tout seul" et "les constructeurs font plutôt bien leur boulot".
*
* *
Légiférer est l'un de seuls pouvoirs de l'Etat qui pourrait le distinguer d'un client ordinaire.

Mais force est de constater que le droit ne s'applique pas aux technologies de l'information – ou du moins pas de la même manière. Et que l'inflation des lois applicables aux nouvelles technologies s'effectue souvent en dépit du bon sens (HADOPI, LOPPSI et autres ayant déjà été largement traitées par ailleurs).

Sur Internet, le seul pouvoir est médiatique (effet de buzz). La CNIL avec ses contrôles en use habilement. Mais il me semble que les institutions étrangères restent meilleures que les nôtres dans ce domaine.

Il suffit de comparer les prises de position très claires du BSI allemand sur BlackBerry (un serpent de mer de la sécurité des Etats s'il en est). En France j'ai vaguement l'impression que chacun cherche au contraire à obtenir et à contrôler l'information – pour assurer sa supériorité sur son voisin ? – ce qui ne sert pas l'intérêt général mais alimente au contraire la rumeur, jusqu'à effacer les arguments techniques.

Le même phénomène s'est également produit avec Skype. Je porte d'ailleurs de grands espoirs sur la prochaine conférence CCC, où des révélations sur Skype pourraient avoir lieu, tout comme ce fût le cas pour BlackBerry lors d'une édition antérieure. La vérité vient toujours d'ailleurs ...
*
* *
Au final, culture de l'ambiguïté, contrôle de l'information et évangélisation de niveau zéro auprès des administrations ne font pas rêver les hackers.

Mes seuls rapports avec l'Etat 2.0 se limitent au paiement des impôts et des amendes (en attendant les emails d'avertissement HADOPI). Mais je sens s'éloigner le jour où je surferai sur l'Internet mondial (le vrai, pas celui des sites "autorisés") avec les résultats du projet SECSI. Le projet Qubes aura probablement été industrialisé avant, malgré son inutilité fondamentale.

Ajouté au fait que les carrières proposées sont médiocres (CDD 3 ans), et que les perspectives offertes à long terme sont du réseautage plus ou moins obscur, on peut comprendre les difficultés de recrutement de l'Etat dans le domaine de la SSI. Ainsi que le problème du maintien des compétences en France, comme le déplore régulièrement Fred Raynal dans ses éditos.
*
* *
Afin de ne pas être taxé de nihiliste invétéré, voici deux idées qui peuvent réellement changer la face de la sécurité informatique.

1. Appliquer les règles.

Le problème est qu'en France, on cherche à contourner les règles plutôt qu'à les adapter. Or si une règle est inapplicable, c'est qu'elle ne sert à rien ... Cela va du très ancien "tous les supports amovibles introduits dans la société doivent être scannés par le sas antivirus" jusqu'au très récent "l'usage des réseaux sociaux est interdit".

En ce sens, la lecture des avis du CERTA me procure toujours le même plaisir qu'à Kostya.

Que penser de ces délicieuses méthodes de contournement (workarounds) pour une faille dans Adobe Reader exploitée en "0day" dans la nature :
  • (...)
  • convertir les fichiers suspects au format PS puis de nouveau au format PDF sur une machine sas ;
  • n'ouvrir que des fichiers provenant de sources vérifiées et sûres.
Sachant qu'il existe à tout instant au moins une faille connue et exploitée en "0day" dans Adobe Reader (VUPEN ayant décidé de ne plus informer les éditeurs ;), je vous laisse le soin de trouver un outil de conversion PDF vers PostScript qui ne soit pas lui-même vulnérable ... et de déployer cette préconisation de manière permanente à l'échelle d'une entreprise.

Le seul moyen de produire des règles applicables ... c'est de se les appliquer à soi-même. Car on ne devrait pas être plus exigeant avec les autres qu'on ne l'est avec soi-même. Et là encore, la France est championne de "l'exception VIP" (tout en restant dans le domaine de la sécurité informatique et pas celui de la fraude fiscale).

2. Mettre en place un contrôle sanitaire sur les logiciels.

J'approuve complètement le principe du CSPN. Mais à l'heure où j'écris ces lignes, seule une poignée de logiciels totalement inexistants en entreprise a été certifiée. Certifier 10 logiciels en 3 ans, c'est tenter d'éponger l'océan de l'industrie logicielle avec un coton-tige.

On objectera que les ressources nécessaires seraient titanesques. Mais dans ce cas, pourquoi ne pas mutualiser les travaux réalisés de manière indépendante et en doublon par tous les acteurs du marché ?

Il suffirait pour cela de réglementer la profession d'auditeur en sécurité, et de déposer tous les rapports d'audit dans un "pot commun" accessible à tous. Ainsi un auditeur pourrait faire bénéficier ses clients de l'expertise antérieure de ses pairs. Voilà qui éviterait de refaire auditer cent fois le même produit, avec des résultats très aléatoires selon l'intervenant ... Et au final, profiter de l'effet de buzz pour obliger les éditeurs à s'améliorer.

Bien sûr, on peut aussi suspecter que la quasi-totalité des logiciels commerciaux échoueraient à une certification sécurité, même de "premier niveau". Et c'est bien là le drame.

Dans le registre des idées plus farfelues, après avoir dépensé 1 milliard d'euros pour vacciner contre la grippe A, ne serait-il pas judicieux de mettre en place des centres de vaccination pour clés USB ? Cela permettrait de protéger la population (et les entreprises) contre le vecteur d'infection n°1 aujourd'hui ...

Autre idée: interdire complètement l'utilisation de tout langage de programmation non sûr (qui a dit PHP ? ;), y compris dans les écoles. Vous pensez que je vais trop loin ? C'est pourtant ce que les américains s'apprêtent à voter.
*
* *
Enfin, pour conclure sur une note positive, et contrairement à ce que j'ai pu lire ailleurs, je sais de source sûre que l'Etat recrute d'anciens hackers en dehors des écoles dites "groupe A". Du moins si par "hacker" on entend "personne compétences en informatique qui maitrise tous les aspects de son art, y compris les plus obscurs". C'est toujours ça de pris.

Les commentaires sont ouverts ! :)

jeudi 12 août 2010

Interlude d'actualité

"Un peuple qui a quarante mille lois n'a pas de loi."
– Honoré de Balzac

En attendant la deuxième partie de mon compte-rendu du SSTIC, je ne peux pas m'empêcher de commenter l'actualité récente. Et je ne parle pas de la faillite du site Jiwa (dont Sid s'est très bien fait l'écho), même si mon sujet est connexe : il s'agit du cahier des charges afférent aux Mesures Techniques de Protection, censées protéger l'internaute des foudres d'HADOPI.

Bien que ce document soit marqué "confidentiel - ne pas diffuser" et distribué au compte-gouttes, Numerama s'est néanmoins permis de le publier en accès libre – ce qui permet de le commenter. Espérons que chaque copie ait été "watermakée" :)

Comme prévu, les solutions envisagées sont :

  • soit l'installation d'un logiciel sur le poste de l'utilisateur ;
  • soit l'installation d'un logiciel dans la Box du client.
Et comme cela était malheureusement prévisible, il n'est pas fait mention de la sécurité des processus de développement, ni des méthodes de vérification/certification applicables. On s'oriente donc à nouveau vers des logiciels développés en C (ou en PHP) par des stagiaires, avec tous les risques (démontrés) que cela comporte. Cela promet néanmoins des développements juridiques intéressants.

Mais compte-tenu du fait que les premiers emails seront envoyés bien avant la disponibilité de ces fameux outils de protection, on peut compter sur le fait que l'ensemble des internautes concernés feront profil bas … gratuitement et sans risque !

La mise à disposition d'un logiciel destiné aux postes Windows est de toute façon inutile : il restera possible de regarder du streaming sur son iPad, et Apple refusera de signer et/ou diffuser l'application HADOPI, conformément à sa politique. Il restera donc à légaliser le jailbreaking en France et à diffuser l'application HADOPI sur Cydia :)

L'intégration à la Box du client est une solution plus intéressante. Elle est toutefois trivialement contournable, puisque rien n'oblige le client à utiliser la Box de son FAI. Ni à utiliser le logiciel fourni par son FAI, le logiciel de la NeufBox 4 étant par exemple recompilable presque entièrement à partir des sources. Sauf à placer un TPM dans chaque Box, il sera donc impossible de contrôler l'équipement de connexion utilisé par les clients.

*
* *

Une autre actualité intéressante est la décision de justice obtenue par l'ARJEL, qui impose aux FAI de filtrer le site de paris en ligne www.stanjames.com. Notez que l'ARJEL a invoqué la protection des mineurs et la lutte contre le financement du terrorisme pour arriver à ce résultat. Ça marche à tous les coups (ou presque).

A titre personnel, il me semble extrêmement hasardeux de jouer sur un site qui n'a pas été agréé par l'ARJEL. L'ARJEL compte d'excellents techniciens. Les exigences de sécurité produites sont sérieuses et vérifiées avec soin, ce qui permet d'éviter de nombreuses fraudes.

Néanmoins cette décision relance encore une fois le débat sur la neutralité du Net. Il est évident que si l'ARJEL crée un précédent juridique, toutes les personnes ayant connu des déboires en ligne (éditeurs de contenus, hommes politiques, scientologues, et autres) vont s'abattre sur Internet comme la vérole sur le bas-clergé.

Accessoirement, en fonction des mesures effectivement mises en place par les FAI (ou pas), je vous laisserai vous exprimer dans les commentaires pour suggérer les méthodes de contournement les plus élégantes. Mais le fond du débat n'est pas technique. D'ailleurs il semblerait que cette fois-ci, l'éditeur du site se soit sabordé de lui-même.


*
* *


Ces deux actualités laissent à penser qu'on s'oriente vers la nécessité de disposer d'un équipement de connexion "approuvé" pour pouvoir accéder à un Internet dont le contenu est soigneusement contrôlé. Ça ne vous rappelle rien ? Ça n'est sans doute pas pour rien que le pôle Sytem@tic a donné des sous à Archos pour construire le Minitel 2.0 !

"Corruptissima republica plurimae leges"

Promis j'arrête les citations :)

lundi 28 juin 2010

Un compte-rendu à froid de SSTIC 2010 (1ère partie)

Ça y est, SSTIC 2010 est mort et enterré. Désormais ce sont HITB Amsterdam, BlackHat US et Defcon 18 qui font le buzz. Un clou chasse l'autre.

Quant à SSTIC 2010, les comptes rendus techniques détaillés ne manquent pas, c'est pourquoi je ne vais absolument pas vous décrire les conférences par le menu. Ce qui m'intéresse c'est plutôt de répondre à quelques questions essentielles concernant le SSTIC.

Le SSTIC est-il une conférence élitiste ?

Bien sûr ! N'importe quel participant à SSTIC combine les trois facteurs suivants (hors agences gouvernementales) :

  • Il peut se payer une conférence à 240 euros (ce qui reste malgré tout raisonnable comparé aux conférences anglo-saxonnes) ;
  • Il peut s'absenter 3 jours consécutifs de son poste de travail (parfois sans prendre de congés) pour partir à Rennes, ce qui démontre une grande liberté au sein de son entreprise (par exemple c'est un chercheur) ;
  • Il peut malgré tout payer avec une CB en moins de 36h sur un site ne supportant qu'Internet Explorer, ce qui prouve qu'il s'abstrait du processus d'achat de son entreprise.
Le public du SSTIC est donc trié sur le volet par ces prérequis. Si vous cherchez une conférence pas chère, facile d'accès et hors temps de travail, il faut plutôt vous tourner vers la Nuit du Hack. Vous ne serez pas dépaysés : dans les deux cas, les sponsors sont venus pour recruter.

La DGSE sait-elle casser RSA-1024 ?

Visiblement demander à la DGSE si RSA-1024 est à la portée de ses puissances de calcul considérables (4ème plus gros client mondial de la société Xilinx, de l'aveu de l'intervenant) rend intelligent. Je suis flatté :)

Néanmoins la question reste pertinente, quand on voit que l'ANSSI écrit :

"Depuis 2004, l'ANSSI recommande d'utiliser des tailles de clés RSA d'au moins 1536 bits, soit exactement le double de la taille qui vient d'être factorisée, pour un usage ne dépassant pas l'année 2010. Cette exigence est portée à 2048 bits pour un usage ne dépassant pas 2020. Ces tailles de clés, portées par le référentiel général de sécurité (RGS), permettent de garantir un bon niveau de sécurité au vu de l'état de l'art cryptographique et des puissances de calcul actuels."

Tout le problème (l'intervenant n'a pas manqué de le soulever) consiste à déterminer si une faille est plus utile en attaque ou en défense. C'est aussi le cas des backdoors, qui ne sont que des failles introduites à dessein.

Contrairement à ce qu'on pourrait penser, concevoir une bonne backdoor n'est pas simple. Par exemple les affaiblissements cryptographiques placés dans les versions françaises de Windows sont catastrophiques, car elles permettent à toute personne qui en a connaissance de nous attaquer, alors que les autres n'y sont pas vulnérables.

La récente backdoor dans UnrealIRCd appartient à la catégorie des "mauvaises" backdoors : toute personne qui en a connaissance peut l'exploiter. On peut noter toutefois qu'il s'agit d'un cas d'école de dissimulation de code source, qui remonte au moins à novembre 2009. Je ne ferai pas de commentaire sur la sécurité induite par la disponibilité du code source :)

La backdoor dans (feu) SecurityBox Freeware était mieux faite, car elle n'était utilisable que par celui qui détient la partie privée de la clé de recouvrement … RSA-1024 !

En résumé, laisser croire aux civils que RSA-1024 est sûr en 2010 me semblerait être un jeu dangereux, s'il s'avérait que n'importe quel gouvernement sait le "casser". Mais je ne m'attendais pas à une réponse :)

La conférence sur Facebook était-elle bien ?

De nombreux comptes rendus soulignent l'intérêt et la qualité de la conférence sur les attaques Facebook, d'autant qu'elle a été assurée par des stagiaires n'ayant pas une grande expérience des interventions publiques (si j'ai bien compris).

Je n'ai jamais douté du fait que des stagiaires (bien encadrés) soient capables de produire du travail de qualité :)

Mais il me semble que les gens viennent dans les conférences de sécurité comme au cirque : pour se faire peur. En tout cas c'est ce qui ressort des communications agressives telles que celle de Laurent Oudot avant SyScan ou de l'éternel « Big One » promis chaque année à Black Hat US – sans parler de la conférence iAWACS (International Alternative Workshop on Aggressive Computing and Security) sous-titrée "the no-limit workshop" pour ceux qui n'auraient pas compris.

Dans ces conditions, toute intervention qui vient avec une aura « offensive » bénéficie d'une surprime non négligeable sur une intervention « défensive ». Notez que cela ne me choque pas à titre personnel (je fais partie du spectacle), mais ça fait tâche avec le discours de clôture évoquant la prépondérance de la défense sur l'attaque dans la doctrine gouvernementale et l'intérêt marginal à découvrir de nouvelles failles alors qu'on peine à corriger les failles connues.

La conférence sur OPA était-elle de trop ?

Voilà un sujet polémique comme je les aime :) Il suffit de suivre l'échange de commentaires sur le blog de Cédric Blancher, et le billet entièrement consacré à cette conférence, pour voir que la critique (même constructive) déchaîne les passions.

Pour essayer de m'insérer subtilement dans le débat, il me semblerait faux de dire que SSTIC donne la prime aux vieux cons (comme moi). D'ailleurs n'ai-je point dit le plus grand bien de la conférence sur le hacking Facebook ? :)

Maintenant, il est clair que l'objectif d'une conférence de 30 minutes n'est pas d'apprendre quelque chose à l'auditoire. Je ne pense pas que quelqu'un soit capable d'initialiser la structure VMCS du processeur Intel après avoir vu la présentation sur VirtDbg.

L'objectif est de "montrer ce qui se fait", et in fine d'esbaudir l'auditeur pour lui délivrer un message. D'ailleurs les conférences américaines à spectacle (de type Black Hat) font venir des intervenants récurrents et rémunérés pour assurer le spectacle (Dan Kaminsky, Joanna Rutkowska, H.D. Moore, etc.). En ce sens la conférence d'Eric Barbry était parfaite :)

J'ai regardé l'outil OPA et techniquement il mérite d'être sauvé. Car il tente de réaliser le vieux rêve de l'informatique moderne (dont il a encore été question au Forum Atena aujourd'hui) : repartir de zéro. Faire table rase des erreurs du passé, et proposer un système nativement sûr aux développeurs.

Malheureusement la présentation qui en a été faite était de loin la plus élitiste … car j'ai quand même vaguement eu l'impression d'avoir été pris pour un neuneu ! Et là, le message n'est pas forcément passé.

Est-ce qu’on est tous foutus ?

Désolé, mais mon commentaire sur la conférence de clôture fera l'objet d'un billet à part entière :)

mardi 20 avril 2010

SSL est cassé

(Notez que j'ai soigneusement évité "l'échec de SSL" comme titre, mais je n'en pense pas moins :)

Ce dont je ne vais pas parler

La puissance de calcul mise en œuvre pour cette "prouesse" laisse penser que la NSA sait faire la même chose en une semaine (sans parler de notre machine TERA, bien française).

Accessoirement, il est amusant de constater que des clés 768 bits sont utilisées par les cartes EMV en remplacement de la clé 320 bits qui a été factorisée par Serge Humpich …

… mais RSA-1024 reste aujourd'hui impossible à factoriser par le grand public.
  • Vous avez également entendu parler de SSLStrip, par Moxie Marlinspike.
Une attaque man-in-the-middle "basique" qui réécrit les liens HTTPS en HTTP. Très efficace contre les moldus de l'informatique … mais qui n'affecte pas les outils automatiques (bien configurés) ou les geeks qui ont mis tous les sites critiques en "HTTPS forcé" dans NoScript (ou qui utilisent des add-ons dédiés).
Beau travail … mais la plupart des implémentations ont blacklisté ce certificat.
Désolé … mais là encore c'est patché presque partout.
  • Vous êtes assez vieux pour avoir entendu parler de la faille OpenSSL exploitée par le ver Slapper en 2002 ?
C'est patché partout … ou presque (n'est-ce pas PolyCom ? ;).
Rassurez-vous, ça devrait normalement être patché (presque) partout …
  • Vous utilisez GnuTLS ?
Bon là c'est sans espoir, désolé !

Bref, vous êtes un technicien. Mais saviez-vous que le modèle SSL est fondamentalement cassé ?

La faille dans SSL

SSL, un protocole conçu par Netscape pour le e-commerce, est là pour assurer la confiance.

Pour faire simple, il existe deux modèles de confiance en informatique: le modèle "pair à pair", utilisé par GPG, et le modèle "à site central", utilisé par SSL.

Dans le premier modèle, vous faites confiance à un inconnu parce que vous l'avez rencontré au moins une fois, ou quelqu'un que vous connaissez l'a rencontré au moins une fois. C'est relativement fiable (quoique l'expérience des réseaux sociaux montre qu'on a tendance à faire confiance un peu trop vite), mais ça passe difficilement à l'échelle.

Dans le deuxième modèle, vous faites confiance à un inconnu parce qu'il existe une autorité d'enregistrement mondiale qui a "vérifié" tous les inconnus. Ca passe très bien à l'échelle, mais ça suppose une confiance inébranlable dans l'autorité "racine". Or c'est là que le bât blesse.

Car l'autorité ne gagne pas d'argent (oui, accessoirement, c'est une activité lucrative) à chaque fois que vous désirez vérifier l'identité d'un inconnu. L'autorité gagne de l'argent à chaque fois qu'elle enregistre un nouvel inconnu. Et donc son business model est d'enregistrer un maximum d'inconnus le plus rapidement possible, en minimisant les vérifications.

Ceci étant posé, quelles sont alors les véritables attaques contre SSL ?
  • Les "fusions acquisitions"
Et oui, la vie est dure, et vendre de la confiance ne rapporte pas suffisamment d'argent. Il y a donc des autorités racines qui ont duré moins longtemps que leur certificat (soit 20 ou 30 ans) et qui ont été rachetées.

C'est ainsi qu'on a pu voir sur la liste des développeurs Mozilla une discussion intéressante autour de la question "qui possède la racine RSA Security 1024 V3 ?".

Tout est bien qui finit bien, puisque la racine en question appartenait bien à la société RSA, qui avait simplement arrêté de maintenir les points de contact identifiés dans la CA. Et qui a donné son feu vert pour supprimer purement et simplement cette CA de la liste des autorités racine de confiance.

Aucune autorité "majeure" n'a complètement disparu à ma connaissance, mais je n'exclus pas que le HSM d'une autorité racine puisse se retrouver un jour en vente sur eBay
  • La sous-traitance
Pour vendre partout, il faut passer par des partenaires locaux. Par exemple en France, Gandi revend des certificats signés par "UTN – DATACorp", c'est-à-dire Comodo.

Les partenaires n'adhèrent pas forcément avec zèle à la DPC du fournisseur. C'est ainsi qu'un "vrai-faux" certificat Mozilla a pu être obtenu sans aucune vérification auprès d'un sous-traitant de Comodo.

Pourtant d'un point de vue technique, la "confiance" est binaire: soit le navigateur accepte le certificat, soit il le rejette. Il n'y a pas de score attaché au sous-traitant qui a délivré le certificat …
  • La prolifération des autorités racines
Entendons nous bien: je parle ici des "vraies" autorités, celles qui paient pour être intégrées à Windows ou aux navigateurs.

Le débat a enflammé la liste de discussions des développeurs Mozilla: faut-il intégrer une autorité de certification chinoise par défaut dans le navigateur ?

Sans rentrer dans le débat politique, on notera qu'il existe déjà plein d'autorités nationales. Comme une autorité hongroise, dont la DPC n'a pas été traduite dans d'autres langues que le hongrois. Difficile de construire la confiance la dessus ...
  • L'appât du gain
Je ne parlerai pas de la supercherie qu'est EV-SSL, c'est-à-dire une tentative pour mettre fin à ces dérives sur le principe du "plus les gens paient cher, plus on peut leur faire confiance". Ou, pour le dire autrement, "les gens les plus riches sont forcément les plus honnêtes" …

Non, la dérive dont je veux parler, c'est la délivrance de certificats gratuits, mais à courte durée de vie. C'est évidemment un abus de confiance: s'il est possible d'obtenir chez VeriSign un certificat de signature d'une durée de vie de 60 jours sans présenter aucun justificatif, alors cela permet de compromettre l'iPhone, mais également de signer un exécutable ou une macro Office pour une attaque "one shot".
  • L'interception légale
Last but not least, il faut noter que les équipements d'interception légale pratiquent le spoofing SSL sans problème. Comment ? Tout simplement avec la coopération de quelques autorités racine nationales, qui délivrent les certificats ad-hoc. Vous pourrez lire le papier ici, ou le compte-rendu dans la presse.

Y a-t-il une solution ?

Pour être honnête, je ne pense pas qu'une solution puisse venir du "marché". Car si la confiance a un prix, alors il y aura toujours quelqu'un pour payer. Après tout la mafia russe a bien monté son propre FAI, pourquoi n'aurait-elle pas sa propre autorité de certification ?

La solution technique théorique au problème est la révocation. Mais ça ne marche pas du tout. Par exemple la sécurité du système Symbian 9 est basée sur ce mécanisme, mais les opérateurs de téléphonie mobile ne l'activent pas (pour des raisons essentiellement économiques).

Et quand VeriSign a délivré un "vrai-faux" certificat Microsoft, il a bien fallu pousser une liste de révocation "en dur" par Windows Update, car aucun client ne vérifiait correctement les révocations.

En attendant, les geeks peuvent toujours utiliser des extensions comme "Perspectives" ou "Certificate Patrol". Ca peut toujours servir ;)


Ma conclusion est simple: le modèle de sécurité des autorités de certification ne vous protège que contre les attaques passives (écoute d'une connexion SSL). Mais pas contre les attaques actives (man-in-the-middle SSL, authentification par certificat client, signature de code, etc.). Et ça n'est pas prêt de changer.

samedi 23 janvier 2010

Interlude récréationnel

Petite perle dans ma mailbox ce matin (je vous donne la version Twitter car je ne crois pas que la newsletter soit archivée en ligne).

Et pourtant, il y a 3 ans déjà ...

PS. J'en profite pour signaler que j'ai ouvert il y a quelques temps un Fail Blog personnel ... pour ce genre d'anecdotes qui ne justifient pas un billet complet.

jeudi 21 janvier 2010

Aurora FAIL

Je ne vais pas faire l'insulte à mes lecteurs de revenir sur le déroulement de ce qu'il est convenu d'appeler "l'opération Aurora".

A peu près tous les vendeurs d'antivirus, de HIPS et de NIPS vous ont déjà sensibilisés au fait que leur produit aurait permis de bloquer cette attaque (sauf que les 30+ entreprises concernées - dont Symantec -disposaient déjà probablement de nombreux produits de sécurité actifs sur leur réseau, mais c'est un autre débat).

Au final, toute cette histoire aura été l'occasion d'un FUD considérable sur Internet, et d'une superbe opération de communication de la part de Google qui se pose en champion de la liberté.

FAIL#1 Ce qui me choque le plus, c'est qu'une société aussi innovante que Google soit à la merci d'une faille dans Internet Explorer 6. Moi qui pensait qu'ils utilisaient Chrome ;)

Compte-tenu de l'historique de sécurité d'Internet Explorer 6, et du nombre de failles "annexes" qui peuvent être déclenchées automatiquement par le biais de ce navigateur (tous les ActiveX et les codecs installés localement, ainsi que Acrobat Reader, Flash, ShockWave, QuickTime, RealPlayer ...), la conclusion évidente est que surfer sur Internet avec IE6 sans protection (ex. SandBoxIE ou au minimum DropMyRights) est juste parfait pour attraper le SIDA, la syphilis et la variole de l'informatique.

Toute entreprise dont la sécurité interne dépend directement de la sécurité d'IE6 est condamnée à l'infection. Avec le nombre de gens brillants en charge de la sécurité chez Google, j'aurais cru cette vérité comme évidente pour eux.

Personnellement, je ne sors plus qu'avec FireFox + NoScript, et encore je me méfie de la surface d'attaque offerte par le plugin NoScript lui-même ...

FAIL#2 "Les attaques proviennent de la Chine".

Dans le cas de Google, il est fort probable qu'il s'agisse d'un insider job depuis leur bureau en Chine. Toute personne qui a ouvert un bureau ou une usine en Chine sait que ce scénario est très crédible.

Mais quand on regarde le schéma global de toutes les attaques, très peu d'adresses IP sont effectivement situées en Chine. N'importe qui aurait pu faire l'acquisition de cette faille IE (comme il s'en vend plein sur Internet). Et la "sophistication" des attaques reste à démontrer ... car après tout il s'agit juste de déposer des exécutables sur le système de la victime, utilisant un protocole basé sur le chiffrement "XOR" avec une clé de 1 octet. N'importe quel pare-feu personnel devrait être capable de détecter ce type d'activité anormale.

Si vous êtes paranoïaque, il ne vous coûtera pas grand'chose de bloquer toutes les adresses IP chinoises sur votre réseau. Ainsi que tous les domaines de la forme "[0-9]+.{org|.net}" (par exemple, les domaines chinois 8800.org et 3322.net étant exclusivement connus pour héberger du malware).

FAIL#3 Data Execution Prevention (DEP)

Tous les problèmes de sécurité ont été résolus en même temps qu'ils sont apparus. Mais l'industrie s'est tout de suite confrontée aux problèmes, tandis que les solutions ont été beaucoup plus longues à faire leur chemin.

Ainsi au début des années 2000, le problème de la non-exécution de code dans les zones de données a été parfaitement résolu par PaX, mais ce patch n'a jamais été intégré dans le noyau Linux pour des histoires personnelles entre Linus et la PaX team.

Parmi les conditions de mise en oeuvre de la non-exécutabilité des données (DEP sous Windows), il est évident depuis le début que le positionnement des exécutables en mémoire doit également être aléatoire (ASLR), sinon il est possible d'utiliser une technique connue sous le nom de retour dans la libc.

Bref, tout le monde a spéculé sur l'efficacité de DEP pour protéger Internet Explorer. Outre le fait que les versions 6 et 7 n'utilisent pas DEP par défaut, cette protection est de toute façon inefficace sur Windows XP puisque le placement en mémoire des exécutables est prédictible (sauf à utiliser WehnTrust).

Le plus gênant dans cette affaire, ça n'est pas le fait que DEP puisse être contourné sous certaines conditions. C'est que personne n'a pris la peine de tester avec l'exploit public avant d'écrire tout et n'importe quoi.

FAIL#4 Secure Development Lifecycle (SDL)

Ce qui me semble extrêmement intéressant dans les dernières failles Internet Explorer et Acrobat Reader, c'est que les méthodes de développement sécurisé proposées par Microsoft (SDL) n'auraient pas permis de les éviter.

En effet, le SDL vise (entre autres) à bannir les API "dangereuses" (de type strcat() ou sprintf()) - c'est-à-dire à lutter contre les buffer overflows.

Or les failles dont on parle sont de type use after free. Par exemple dans le cas de la faille IE, celle-ci se résume à:

  1. Ajouter un évènement sur un objet du DOM
  2. Supprimer l'objet en accédant au DOM via JavaScript
  3. Attendre que l'évènement soit invoqué
Trivial, n'est-il pas ? Pourtant ces failles sont extrêmement difficiles à détecter, aussi bien en analyse statique qu'en analyse dynamique (fuzzing) que par une revue de code manuelle, surtout sur du code massivement multi-threadé.

On peut donc suspecter que le use after free va encore faire parler de lui ... et pas seulement dans Internet Explorer 6 !

Conclusion

L'affaire "Aurora" ne change rien à mes conclusions antérieures. Si vous avez des vrais problèmes de sécurité, prenez conseil auprès de vrais spécialistes. 95% de l'information disponible sur Internet est partielle, fausse ou non vérifiée.