samedi 29 janvier 2011

Sourceforge.net passwords reset - maintenant, vous pouvez vraiment hurler

Après Fedora qui a connu un problème de sécurité dû à la compromission d'un mot de passe d'un administrateur mineur, Sourceforge fait parler de lui.

Sourceforge est une plateforme d'édition de source et de dépôt pour celles-ci. Cette plateforme s'est faite attaquer avec succès si l'on en croit les communiqués officiels:
Et l'équipe de sourceforge mentionne que leurs admins continuent de travailler sur l'incident et qu'ils communiqueront plus tard sur les impacts et causes de cette attaque. D'ailleurs, j'ai reçu un email ce matin m'enjoignant à changer mon mot de passe sourceforge "and so we are resetting all passwords in the sf.net database -- just in case"

Je ne suis pas très rassuré sur cette histoire. J'ai téléchargé quantité de logiciels sur sourceforge et une compromission de cette plateforme aurait un impact énorme. Et je suis inquiet lorsque je vois cette timeline:
On peut lire cette timeline comme on le souhaite, mais à mon avis il faut considérer tout logiciel téléchargé chez sourceforge depuis mai 2010 comme potentiellement trojanisé et ça, ce n'est vraiment pas une bonne nouvelle :(

Le mail de ce matin ne fait que confirmer cette sensation désagréable.. On resette tous les mots de passe, il y a eu des "evidence of password sniffing attempts".
J'attends le prochain update de sourceforge pour voir jusqu'à quel point ils ont été touchés. J'ai envoyé quelques mails à certains projets pour demander des avis sur l'état des sources. Wait end See.

vendredi 21 janvier 2011

USB m'a tuer

L'USB est une prise et un protocole de communication largement répandue qui se fait attaquer. Cette prise permet de connecter à peu près n'importe quel équipement à n'importe quel système (OS grands publics, ou smartphones).

La conférence blackhat propose deux conférences intéressantes ou l'USB permet de prendre le contrôle de machines. La première, de Jon Larimer intitulée "Beyond AutoRun: Exploiting software vulnerabilities with removable storage". Cela parle de Stuxnet (encore une fois), mais présente un moyen de délocker un poste linux verrouillé. Morceau choisi: "There’s a lot of code that runs between the USB drivers themselves and the desktop software that renders icons and thumbnails for documents, providing security researchers and hackers with a rich set of targets to exploit.". A suivre, donc.
Une seconde conférence propose un moyen original de prendre le contrôle de votre machine via l'USB et un smartphone piégé. Conférence de "Angelos Stavrou, Zhaohui Wang", "Exploiting Smart-Phone USB Connectivity For Fun And Profit". L'idée est originale et assez efficace. Il faut savoir que lors de la connexion à la prise USB, les périphériques se font reconnaître, comme support de stockage, hub USB, clavier, etc... Rien n'empêche un périphérique de se faire passer pour une souris et un clavier afin de pouvoir agir directement sur la session de l'attaqué! Sous windows, il y a une courte infobulle informant de l'ajout de ces périphériques, sous Mac un pop-up apparaît, mais il est possible pour l'attaquant de le fermer, et sous linux, il n'y a aucun warning[1]. Owned!

On constate de plus que le laboratoire SOGETI/ESEC recrute (entre autre) un stagiaire pour : "Malicious hardware and USB: the purpose is to study the USB protocol and use it on a device (e.g. FPGA) to compromise a target host (Windows, MacOS X, Linux, iOS, Android)". On imagine facilement l'idée derrière, obtenir un périphérique capable de fournir des réponses choisies (malicieuses) lors de la discussion USB qui s'instaure à la connexion de ce périphérique.

L'USB est déjà un vecteur d'insécurité largement généralisé du fait des infections par clés USB qui permettent de transporter les virus. Mais une nouvelle famille de failles est peut-être encore à découvrir, attaquant directement le protocole USB lui-même.


[1] Ceci dit, le magazine MISC n°50 proposait un article implémentant un pare-feu USB sous linux.

mercredi 19 janvier 2011

Les posts auxquels vous avez échappé

Bloguer demande une rigueur d'écriture et certains billets ne sont donc pas publiés.
Les raisons en sont multiples. La principale est souvent liée au temps nécessaire à son écriture. Une bonne idée n'est pas forcément un bon article s'il n'est pas étayé par des références fiables et s'il n'a pas eu plusieurs relectures. Mais ces idées ne gagnent rien non plus à rester dans ce statut.
Voici donc une liste des posts auxquels vous avez échappés, cela videra une partie de mon stock de brouillons :)

Le plus ancien date de juin 2009, la parution de zf05 a permis de se rendre compte que l'hébergement mutualisé est un gros FAIL en terme de sécurité. En lisant ce zf05.txt on se rend compte que les personnes visés utilisaient leur hébergeur mutualisé pour héberger aussi des données privées. Un mutualisé ne devrait servir qu'a placer des données publiques comme un blog. Donc FAIL de l'hébergeur, ou FAIL de celui qui y place ses données privées?

Un autre post qui a été repris plusieurs fois concerne les tunnels DNS. On sait comment ça fonctionne, et comme tout à été à peu près dit dessus, à quoi bon revenir une fois de plus. De plus, j'ai lu http://www.daemon.be/maarten/dnstunnel.html (la page semble down en ce moment). Que dire de plus sinon paraphraser cet article? Donc brouillon, avec quantité de liens comme des tunnel DNS brokers, et autres analyses de débits de ces tunnels, etc etc..

Une analyse réseau d'une capture d'une centaine de Mo avait commencée de manière amusante car dans les premiers paquets apparaissait une recherche google sur les mots clés "on peut être féminine et poutrer du zombie" (mais qui cherche ça?).
Analyser des .pcap de cette taille, c'est long et ennuyeux, surtout que le reste de la capture était vide d'intérêt; pas de virus, pas de troyens, pas de données curieuses, rien. tshark permet facilement de réduire les données d'entrées. Je devais réordonner les one-liner tshark et les diffuser quelque part. La seule option manquante est l'extraction complète des fichiers échangés en HTTP en une passe. Wireshark permet de le faire fichier par fichier, mais apparemment rien n'existe de manière globale. Je pensais bloguer sur cette analyse, mais mis à part pour dire que la majorité des utilisateurs surfent en HTTP et que de fait firesheep a encore de beaux jours devant lui, il n'y avait hélas pas grand chose.. (et puis la sécurité réseau est ennuyeuse, alors..)

Certains messages de bluetouff m'avaient amené à creuser les questions sur le DPI en cœur de réseau opérateur. En regardant chez Orange, on apprend que ce genre d'équipement existe déjà et sert à protéger des clients de DDoS (mais ne donnait pas d'ordres de grandeur). Le dernier DDoS chiffré à l'époque de l'article était celui de wikileaks, 10Gb/s. J'en conclus donc que les équipements de DPI existent déjà, et filtrent au minimum à cette vitesse (les équipements sérieux s'entend, je ne sais pas si l7filter arrive à ce débit :) ).
Le DPI semble une notion assez mal définie ceci dit. Les firewalls ne filtraient à l'origine que des IP/port, puis sont devenus statefulls. Aujourd'hui l'analyse remonte d'un cran pour être applicative. Jusqu'où peut remonter cette analyse? Un firewall bloquant un port nuit il à la liberté d'expression plus ou moins qu'un firewall qui bloque une URL terminant en .exe? Et un firewall DPI protocolaire peut il continuer à remonter, i.e. étudier les fichiers utilisant ce protocole? Intéressant, mais il me faudrait du temps pour rassembler mes notes encore une fois.
Cet article finissait aussi sur la mort du firewall. La sécurité réseau n'intéresse personne, on pose des firewalls de la même manière qu'on pose des antivirus sur des machines windows: "Il en faut". Mais on sait très bien que ça ne bloque pas un seul instant le pirate déterminé. Alors pourquoi en mettre? Il s'agit sans doute de deux idées trop différentes pour en faire un unique post, je reviendrai peut-être la dessus.

Wikileaks devait aussi faire l'objet d'un article. Il s'agit d'un phénomène intéressant de résilience de l'information. Je voulais faire le distinguo entre la résilience d'une information et la résilience d'un service. Une information sur internet est facilement résiliente, sa duplication peut se faire à coût nul (ou négligeable) et sa diffusion peut être faite par tout un chacun, ce qui a été le cas pour wikileaks. La résilience d'un service (imaginons twitter ou facebook) est autrement plus compliquée à obtenir.
Un deuxième axe de réflexion sur wikileaks concerne bien évidemment les Denials of Service qui sont complètement sortis de la sphère "cyber" pour se propager dans le monde réel.

Voilà quelques posts qui n'ont jamais été terminé. J'aurais également souhaité rencontrer un juriste pour parler de LOPPSI2 et des intrusions informatiques "légales", mais l'emploi du temps ne me l'a pas permis.

Certains autres brouillons devraient eux se retrouver bientôt en message de blog.