lundi 27 juillet 2009

La preuve que la sécurité est un échec

Pour ceux qui ne lisent pas (ou plus) la liste de diffusion Full Disclosure, voici la version courte de l’histoire : un « groupe » se faisant appeler « anti-sec » lance une guerre totale contre les « white hats » (les gentils hackers, si toutefois cela a un sens) et le « full disclosure ». Une telle initiative refait surface de manière périodique, la dernière en date étant le « pr0j3kt m4yh3m » (tout un programme).

Comme preuve de leur motivation, ils ont saccagés quelques sites à forte visibilité : Astalavista, ImageShack … le dernier en date étant la crème du consulting américain en sécurité informatique : la société Matasano.

Cette histoire est emblématique à plusieurs titres.

Tout d’abord la réponse à « pourquoi la sécurité est un échec » se voit une n-ième fois confortée : toutes ces attaques sont basées sur la découverte d’un mot de passe faible par brute-force SSH, n’en déplaise à ceux qui pensaient avoir trouvé un « 0day » exploitable en préauth dans SSH sur un Linux 64 bits avec le patch GrSecurity appliqué …

N’oublions pas le cas de Twitter, qui aurait pu simplement « disparaitre » du Web à la suite de la compromission d’un mot de passe (heureusement que cette attaque était le fruit d’un individu isolé plutôt bien intentionné).

Ensuite le cas de Matasano laisse songeur, surtout lorsqu’on voit que le même système est utilisé pour de l’hébergement Web, de la messagerie … et le stockage de données d’audit client (ex. « ISA Pen Test Availability_13_Feb.xls »).

La sécurité est un échec car personne, quel que soit son niveau de compétences et l’énergie investie dans l’administration de ses systèmes, ne peut prétendre être invulnérable. D’ailleurs vous ne m’entendrez jamais dire « fu^H^Hhack me I’m famous », car je sais trop bien que vous y arriveriez :)

Des exemples ?

On lit dans la presse que divers réseaux de sensibilité extrême sont piratés (DoD, FAA, système de paiement, …). C’est bien sûr totalement invérifiable, mais crédible. Ayant eu l'occasion de m'intéresser à quelques réseaux sensibles vaguement connectés à Internet (SITA, réseaux satellitaires, etc.), il s’avère qu’ils sont tous de même niveau de sécurité que le réseau bureautique moyen … l’expérience des attaques en moins !

Prenons quelques exemples publics et vérifiables :

  • Le site « j’aime les artistes ». Un(e) ministre ayant commis l’erreur de prétendre ce site inviolable, il a été immédiatement mis hors d’usage.
  • La société « Extelia ». Après avoir gagné l’appel d’offres HADOPI, cette société et tous ses sites clients ont immédiatement été piratés.
  • Le (défunt) Challenge Securitech. Bien sûr faire converger tous les « experts en sécurité » français (soyons clair, Securitech était devenu très « corporate » sur la fin :) sur un site où ils peuvent gagner un iPod en piratant était dangereux. Mais se faire avoir parce que l’hébergeur a désactivé l’option « magic quotes » est un peu humiliant quand même :)
  • Le blog d’Ivanlef0u. En même temps, je ne vois pas qui peut assurer la sécurité d’un hébergement mutualisé en PHP. Ils serait plus facile de compiler OpenOffice sous OpenBSD.
  • Edit: n'oublions pas la fameuse démo du projet SPAClik au SSTIC'09. "Aucune faille n'a été trouvée dans mon système jusqu'à présent". On connait la suite, avec l'humiliation en direct sur scène.
Quel est le point commun entre tous ces cas ? La dépendance du niveau de sécurité global à celui des tierces parties impliquées.

Ainsi dans mon cas, je suis dépendant de :

  • La sécurité de ma Freebox (autant dire pas grand-chose, puisqu’elle est administrable à distance par au moins tout le personnel de Free).
  • La sécurité de mes fournisseurs de messagerie (Free, Gmail, etc.). Autant dire pas grand-chose non plus, même si j’utilise de fausses réponses aux questions secrètes, que je ne lis jamais mon mail via l’interface Web, et que j’utilise un mot de passe différent sur chaque site. Car réaliser un Webmail sécurisé relève de la mission impossible.
  • La sécurité de mes machines à la maison. Ainsi « on » m’a fait remarquer que dans la configuration Debian par défaut du serveur ProFTDd, l’utilisateur anonyme peut accéder à tout le disque par un simple « ../ ». Mais qui fait encore confiance à Debian pour assurer sa sécurité ? :)

Alors que peut-on faire ? Rien du tout, car en général il suffit que l’un de ces maillons soit brisé pour que le château de cartes s’écroule par le jeu des relations de confiance. La meilleure défense consiste à ne rien stocker de sensible qui ne soit accessible en ligne, car tout ce qui est connecté à Internet est ou peut être compromis.

Pour tenter une analogie (avec tous les risques que cela comporte), les digicodes ne servent à rien quelle que soit la longueur du code - à partir du moment où au moins un résident de l'immeuble a déjà commandé une pizza par téléphone (disclaimer: je n'ai jamais audité le réseau Pizza Hut, je suppose juste que tous les digicodes sont stockés en clair dans leur base de données :).

Alors quand on voit le nombre d'intermédiaires impliqués dans la gestion du réseau Internet en France, on peut se poser des questions sur la sécurité même de nos infrastructures critiques ...

(Que serait un billet polémique qui ne se termine pas sur impots.gouv.fr ? ;)

Edit: je n'avais pas vu que le magazine Capital était arrivé exactement à la même conclusion ! Promis je n'étais pas au courant ...

vendredi 24 juillet 2009

Psychose

Pour commencer, il vous faut écouter cette séquence avec attention (il s'agit d'un distributeur de billets de marque Diebold situé à Paris, strictement identique à tous les distributeurs déployés par la Société Générale en France):



Si vous êtes utilisateur Windows, vous aurez reconnu sans peine le son "chimes" (C:\Windows\Media\chimes.wav) émis par ce distributeur (par dessus le bruit ambiant, désolé pour la piètre qualité de l'enregistrement).

Que viennent faire ici ces sons assez saugrenus, à part nous signaler que le distributeur tourne probablement sous une version quelconque de Windows Embedded (ou que la licence Microsoft a été violée) ?

A la lecture de l'article "organiser la fuite d'information d'un poste isolé: méthodes logicielles" - et particulièrement du chapitre "attaque via le jingle Windows" (MISC n°44, entièrement lisible en ligne à cette adresse), un doute horrible me saisit: et si ces sons servaient de stégo-medium à mon code PIN ?

Depuis, je ne vais plus retirer de l'argent sans chanter à tue-tête quelque musique nordique conseillée par Ivanlef0u. En l'état actuel des connaissances, aucun algorithme de traitement du signal ne peut extraire d'information utile dans ce bruit blanc.

vendredi 3 juillet 2009

L'échec de la sécurité française

Ou pourquoi il faut arrêter de me saouler avec les "0day" ...

Les français ne manquent pas de talent dans le domaine de la sécurité informatique. Malheureusement ils ne s'épanouissent pas forcément dans leur pays d'origine. Parmi les gens que j'ai connu personnellement et qui sont partis, on peut citer:
  • Kostya Kortchinsky
D'abord CERT Renater, puis EADS, et maintenant Immunity (à Miami). Il s'est illustré par l'exploitation de la faille MS08-001 (qualifiée d'impossible par Microsoft) et l'évasion de VMWare (attaque CloudBurst).
  • Nicolas Pouvesle
Anciennement Tenable Network Security (n'oublions pas que Nessus est un produit français à l'origine), cité par H.D. Moore comme "Top Influencer", contributeur du projet Metasploit, auteur du plugin PatchDiff2 pour IDA Pro ... et maintenant chez Immunity également.
  • Thomas Garnier
Anciennement SkyRecon (un autre produit français), auteur de failles innombrables dans le composant GDI de Windows, il est parti chez Microsoft Corp. lors de la reprise en main de SkyRecon.
  • Julien Tinnès
Anciennement FT R&D, il est parti (comme beaucoup d'autres) chez Google lorsque cette entité a été rattachée au marketing sous le nom d'Orange Labs. Il s'est illustré récemment sur la faille Java util.calendar(), mais tourne en fait dans le milieu depuis longtemps.
  • Julien Vanègue
Chef de file du projet ERESI, il a fini par virer sa cuti et rejoindre l'équipe MSEC de Microsoft.


Bien sûr, il existe encore probablement beaucoup de gens de qualité dans l'underground et l'upperground français. Mais quand je lis que la mise en oeuvre de la LOPPSI va peut-être nécessiter des "0day" pour installer les mouchards à distance, je manque de m'étouffer.

Non seulement la plupart des gens ayant démontré publiquement une certaine capacité dans le domaine sont partis, mais de plus tous les programmes publics d'acquisition de "0day" sont étrangers (américains en fait, sauf feu-WabiSabiLabi).

Si c'est pour faire appel à des projets universitaires, et sans mauvais esprit aucun (je ne suis pas connu pour ça :), on aura peut-être un fuzzer pour les syscalls NT4 dans 3 ans après avoir usé 5 thésards ...

Si c'est pour mettre le flingue sur la table ou la tête dans le caniveau, ça ne marche pas: il est impossible pour un magicien de créer un objet magique sous la contrainte.


Alors bien sûr, quelques initiatives sortent du lot, comme la conférence iAWACS: international Alternative Workshop on Aggressive Computing and Security - The No Limit Workshop, selon leurs termes.

On pourrait imaginer un programme particulièrement alléchant, comme:
Mais j'ai vaguement l'impression que le résultat final sera un peu moins sexy ... Espérons que les meilleures soumissions se verront exploitées sans passer par la case "publication" !


Pour finir, je campe sur ma position qui a toujours été claire depuis le début: les "0day" ne servent à rien (dans 99,9% des cas, je mets de côté le cas des systèmes vraiment protégés).

Ainsi le dernier numéro (n° 4/2009) du magazine Hakin9 m'est arrivé en anglais. Erreur de routage ou disparition de la version française ? Peu importe, la version anglaise est finalement comparable à la version française: les articles sont extrêmement inégaux en qualité (sur le fond et sur la forme).

Et là, un certain Carsten Köhler (visiblement très actif par ailleurs) nous délivre ses tricks de pentesteur, et explique par exemple qu'il est possible de créer des fichiers arbitraires sur n'importe quel système Windows qui partage au moins une imprimante.

Je reviendrai plus tard sur les détails techniques, mais voilà exactement le genre d'astuce qui marche "pour de vrai": une faille de conception (donc très difficile à corriger), multi-versions, multi-langues, ne risquant pas de planter le système distant, exploitable via les API Windows. Rien à voir avec un "0day" au sens où on l'entend d'habitude !