dimanche 13 décembre 2009

Le code source Java en libre service!

Si vous pensez que votre code Java est toujours obfusqué (et bien obfusqué) et que de toutes les façons on y trouve jamais d'informations confidentielles, alors cette article n'est pas pour vous.
Sinon, vous trouverez peut être dans cet article quelques informations intéressantes.

Tout d'abord un bref rappel!


Le reverse engineering est une technique permettant de reconstituer le code source d'une application à partir de sa forme compilée telle que livrée à ses clients par un éditeur. La possession du code source permet de connaître le fonctionnement précis d'une application.


Une personne malveillante peut grâce à cette technique connaître les algorithmes utilisés par son concurrent et lui voler ses secrets. Outre les algorithmes, les identifiants de connexion à des ressources (bases de données, annuaires...) sont là aussi accessibles, d'où le risque de vol de mot de passe et d'accès frauduleux à des ressources protégées.


Face aux risques liés au reverse engineering quelles techniques permettent de cacher le code source d'une application ? L'une d'elles est l'obfuscation qui transforme le code source avant compilation de manière à le rendre illisible pour l'être humain.

L'aspect général du code source d'une application peut être obfusqué de la manière suivante:


  • renommage de tous les identifiants

  • suppression des commentaires

  • élagage des déclarations d'API non utilisées

  • suppression des règles de style (comme l'indentation)

  • cryptage des chaînes de caractères pour cacher leur valeur.


Démonstration par l'image au travers d'un exemple... à suivre (plus ou moins)!





Voici quelques obfuscateurs (c'est une liste non exhaustive):




Le décompilateur Mocha peut être téléchargé ICI.


Le décompilateur Java Sothink peut être téléchargé ICI.




A bientôt...

dimanche 6 décembre 2009

Transformer votre clef USB en bureau "mobile"!

L'objectif de cet article est de vous montrer comment transformer votre clef USB en bureau mobile. Mais qu'est-ce qu'un bureau mobile? C'est la possibilité d'installer sur votre clef USB vos applications préférées et ainsi de pouvoir les utiliser sur n'importe quel ordinateur.


Cette approche est dans le même esprit que le "cloud computing" dans la mesure où elle vous permet d'accèder à vos applicatifs préférés à tout moment (je sais la comparaison est cavalière et j'espère que les puristes me pardonneront ce raccourci). Tandis que le "cloud computing" met à votre disposition les applications sur internet (Word, Photoshop,...), votre clef USB, transformée en bureau mobile, vous permet également d'accèder à vos applicatifs préalablement installés sur votre clef.


La premier application qui vient à l'esprit est le Single Sign On, i.e. la possibilité de stocker vos associations dans un applicatif sécurisé par un mot de passe. Vous pouvez ainsi accèder à vos sites web favoris sans avoir à entrer l'URL, le nom de l'utilisateur et le mot de passe à chaque session. Parmi les nombreux applicatifs qui permettent cette fonctionnalité on trouve Roboform et Keypass. Dans notre vidéo nous décrivons l'installation et l'utilisation de Roboform.


Mais il existe de nombreux autres applicatifs disponibles dans des domaines très variés. Certains de ces applicatifs se trouvent sur le site PortableApps. Dans notre vidéo nous installons et configurons PStart et FirefoxPortable. PStart permet de lister les applications installées sur votre clef USB et de choisir celle que vous souhaitez exécuter. Quant à FirefoxPortable, c'est la version "légére" de Firefox qui vous permet d'utiliser votre propre browser pour surfer sur internet avec vos favoris et vos plug-ins.


La cerise sur le gâteau est de pouvoir lancer automatiquement votre application préférée dés l'insertion de votre clef USB. Mais cette fonctionnalité est parfois désactivée en entreprise et disparaît totalement avec l'arrivée de Windows 7 (pour des raisons de sécurité: cf les articles du blog à ce sujet "Plus d'Autorun dans Windows 7...!" et "La clef USB: le maillon faible ? ").


La solution consiste à installer l' "USB Grabber" (outil gratuit proposé par Prox-IA) qui permet de configurer les applicatifs à lancer à l'insertion de la clef USB. "USB Grabber" permet également de créer des raccourcis sur votre bureau. La vidéo nous montre l'installation et la configuration d' "USB Grabber".



On ne peut parler de mobilité et des clefs USB sans parler du format U3.



L'U3 ou Smart Drive est un format de clé USB comprenant une plate-forme logicielle spéciale qui permet aux développeurs d'écrire des applications spécialement conçues pour fonctionner depuis une clé de ce type. Une application U3 est dite portable car elle peut être utilisée sur différents ordinateurs sans nécessiter une installation sur chacun d'entre eux : le programme ainsi que ses données et sa configuration sont stockés sur la clé et non sur les ordinateurs hôtes.

SanDisk et M-Systems ont créé un mini-environnement avec une sorte de menu de démarrage appelé LaunchPad qui ne fonctionne que sous Windows. Celui-ci permet aux utilisateurs de lancer les applications installées sur la clé et de configurer leur « clé intelligente ». Un site web dédié aux clés U3 permet aux propriétaires d'une de ces clés de télécharger de nouvelles applications portables.

Les clés U3 sont compatibles avec Microsoft Windows Vista à partir de la version 1.4 du LaunchPad.





A bientôt...

samedi 14 novembre 2009

Une parade à l'attaque Man In The Middle (ou pas)!

Pour éviter une attaque de type MITM (Man In The Middle) dans une architecture orientée services, une solution possible est le CBT (Chain Binding Token de Microsoft) appelé aussi "Extended Protection for Authentication".

Cette solution, proposée par Microsoft, fait partie de WCF et apparaît avec le .NET Framework 3.5 et Windows 7.

WCF (Windows Communication Foundation) est un sous-système de communication de Windows Vista. Les applications WCF peuvent être développées en utilisant les différents langages de Microsoft .NET. WCF est l'un des composants majeurs du .NET Framework 3.0, qui est inclus dans Windows Vista et Windows Server 2008.


Le modèle de programmation WCF est une couche d'abstraction qui unifie et simplifie la mécanique d'intégration des services Web (entre autres choses).

Si vous souhaitez mieux comprendre en quoi consiste une attaque du type MITM, vous pouvez consulter l'article du blog suivant "L'attaque MITM démystifiée avec Backtrack 3".




Décrivons le scénario d'attaque suivant avec 3 participants: un client, un serveur et un attaquant.




L'attaquant fait croire au client qu'il accède au serveur alors qu'en fait le client accède à l'attaquant. Puis l'attaquant transmet la requète du client au serveur. Le serveur répond à l'attaquant avec une demande d'authentification HTTP sous la forme d'un header contenant un "WWW-Authenticate". L'attaquant ne dispose pas des informations d'authentification, il va alors transmettre le "WWW-Authenticate" au client. Le client envoie alors à l'attaquant (qu'il prend pour le vrai serveur) la réponse au "WWW-Authenticate" avec un header contenant un "Authentication" (qui est la réponse au "WWW-Authenticate" contenant les informations d'authentification). Puis l'attaquant se contente de transmettre le "Authentication" au serveur. L'attaquant a ainsi accès aux ressources sécurisées du client.





Généralement, quand un client s'authentifie auprès d'un serveur avec une authentification Kerberos ou NTLM en utilisant HTTPS, un canal SSL est établi en premier lieu afin de permettre à la phase d'authentification d'avoir lieu dans de bonnes conditions. Cependant il n'existe pas de lien entre la clef de session générée par SSL et la clef de session générée pendant l'authentification.


Ainsi, dans le scénario précédent, il y a deux canaux SSL distincts: un entre le client et l'attaquant et un entre l'attaquant et le serveur. Les "credentials" du client (généralement le nom d'utilisateur et le mot de passe) sont envoyés vers le serveur en premier lieu au travers du canal SSL entre le client et l'attaquant, puis dans un deuxième temps au travers du canal SSL entre l'attaquant et le serveur. Une fois que les "credentials" sont transmis au serveur, le serveur vérifie les "credentials" sans pouvoir détecter que le canal SSL au travers duquel les "credentials" ont été transmis est celui en provenance de l'attaquant et non pas celui en provenance du client.





La solution consiste à utiliser un canal SSL externe et un canal interne (celui du client authentifié) et à passer un CBT au serveur (Channel Binding Token). Le CBT est une propriété du canal SSL externe, et il est utilisé pour lier le canal SSL externe au canal interne (celui du client authentifié).





Dans le scénario précédent, le CBT du canal "client-attaquant" est combiné avec les informations d' "Authentication" transmises par le client au serveur en réponse au "WWW-Authenticate" (via l'attaquant). Un serveur capable de gérer ce CBT qui correspond au canal SSL "client-attaquant" le compare au CBT attaché au canal "attaquant-serveur". Le CBT est lié à la destination du canal, et donc le CBT "client-attaquant" ne correspond pas au CBT "attaquant-serveur". Le serveur peut ainsi détecter l'attaque MITM et refuser la requète d'authentification.



Le client ne nécessite aucune configuration particulière (à partir du moment où le CBT est implémenté). Une fois que la machine cliente à été mise à jour pour passer le CBT, elle le fait toujours. Si le serveur à lui aussi été mise à jour alors il peut être configuré pour vérifier ou ignorer le CBT. S'il n'a pas été mis à jour alors le serveur ignore toujours le CBT.

N'est-ce pas fantastique!

La vidéo ci-dessous va nous permettre au travers d'un exemple de comprendre comment configurer le CBT entre un client et un serveur.









Il nous reste maintenant à vérifier que cette nouvelle solution ne présente pas de failles. Mais ceci est une autre histoire!


Source: Microsoft MSDN http://msdn.microsoft.com/en-us/library/dd767318.aspx

samedi 10 octobre 2009

Cross Site Request Forgery par l'image!

Cross Site Request Forgery est aussi connu sous l'abbréviation CSRF. Le CSRF exploite un site web pour lequel des commandes non autorisées sont transmises par un utilisateur en qui le site web à confiance.



A la différence du XSS (Cross Site Scripting) qui exploite la confiance d'un utilisateur pour un site web particulier, le CSRF exploite la confiance qu'un site web à dans le browser de l'utilisateur.




Prenons un exemple pour nous permettre de mieux comprendre la mécanique du CSRF.

Bertrand se connecte comme tout les matins sur son site bancaire pour effectuer les opérations nécessaires à son activité professionnelle. Il commence par s'authentifier auprès de sa banque et réalise quelques transferts de fonds. Puis il va consulter ses mails personnels sur son web mail favori en oubliant de fermer la session avec son site bancaire. Il est impatient de recevoir la confirmation de la réservation d'un séjour d'une semaine en Guadeloupe. Il aimerait annoncer la bonne nouvelle à sa famille en rentrant ce soir. Bertrand trouve de nombreux mails dans sa boîte aux lettres, mais pas de confirmation de réservation. Déception!Par contre, un de ces mails non attendus lui propose d'obtenir la liste des salaires de son entreprise (un grand groupe international). Intrigué, il ne résiste pas à la tentation et clique sur l'URL proposée. Il obtient effectivement une liste de salaires mais l'information ne lui semble pas très fiable. Tant pis! Bertrand reprend consciencieusement son travail.

Ce que Bertrand ne sait pas encore c'est qu'en cliquant sur l'URL pour accèder à la liste des salaires, il a ouvert la boîte de Pandore: un script malicieux s'est exécuté pour réaliser un transfert de fonds de son compte bancaire vers un compte tiers.


Ce scénario est bien entendu une fiction et la ficelle semble bien grosse. Mais il permet, me semble t'il, de bien comprendre ce qu'est le CSRF.


La vidéo ci-dessous explique plus en détails les arcanes du CSRF à partir d'un exemple similaire.






Quelques conseils pour essayer d'éviter ce type d'attaque:

  • Demander des confirmations à l'utilisateur pour les actions critiques au risque d'alourdir l'enchaînement des formulaires. La demande de confirmation peut être basée sur une ré-authentification de l'utilisateur avec la même méthode d'authentification, ou une méthode d'authentification plus forte si l'action requise est critique.
  • Vérifier l'adresse URL du script appelant (referrer) au risque également d'alourdir le développement des formulaires.
  • Utiliser des jetons de validité dans les formulaires pour faire en sorte qu'un formulaire posté ne soit accepté que s'il a été produit quelques minutes auparavant : le jeton de validité en sera la preuve. Le jeton de validité doit être transmis en paramètre et vérifié côté serveur.

A bientôt...

samedi 3 octobre 2009

Comment détecter les PDFs malveillants?

Avant de vous présenter comment on peut détecter les PDFs (Portable Document Format) malveillants un bref rappel du format PDF me semble nécessaire.


Un document PDF peut être défini comme un ensemble d’objets qui décrivent comment une ou plusieurs pages peuvent être affichées. Ces objets et autres composants additionnels sont gérés par une combinaison d'opérandes (objets) et opérateurs qui constituent un véritable langage dédié à la description de pages PDF.
Cette description de page se fait en 2 étapes:
  • l'application génére une description du document en langage PDF indépendante du matériel
  • un interpréteur assure ensuite le rendu et l'affichage du document à partir de la description précédente.


Tout fichier PDF contient les sections suivantes:

  • Le « Header » contient la version du fichier PDF.


  • L’ « Object » racine contient le catalogue qui décrit le contenu du fichier.


  • Les autres « Object » décrivent le type des données et leur format. Par exemple le type peut être du texte et la police « Helvetica ».


  • La table « Cross References » contient la liste des objets utilisés et les objets supprimés (ce qui signifie que lorsque vous créez un fichier PDF puis en supprimez une partie, cette partie supprimée n’est plus affichée mais elle est toujours présente dans le fichier PDF et peut donc être récupérée; danger!). La table de référence croisée (alias Cross References) permet d'accéder directement aux objets sans avoir à parcourir tout le code.


  • Le « Trailer » contient des informations essentielles à la lecture du fichier dont entre autres choses le nombre d'objets contenus dans le fichier et l'offset de la table de référence croisée (alias Cross References). Cette section bien que située à la fin du fichier est la première lue.


Maintenant que les présentations sont faites, nous allons voir comment détecter un PDF contenant un script malveillant.



Une fois de plus nous utilisons le framework «Origami 1.0.0. Beta 0» non pas cette fois pour créer un PDF malveillant mais pour détecter les PDFs malveillants.
Pour cela nous lançons le script Ruby appelé pdfscan.rb situé dans le répertoire «scripts/scan» en ligne de commande et nous obtenons le résultat suivant :






La première chose à remarquer est qu’il y a plusieurs sections dans le résultat de l’analyse:



File ID : permet de se souvenir du fichier analysé



Structure : permet d’avoir une vue rapide sur la structure du PDF (la version, les «object»,…). Chacun de ces éléments permet d'obtenir des indices pour mieux comprendre le résultat



Properties : permet de savoir si le fichier est encrypté (afin de cacher un code malveillant) ou s’il contient des fichiers embarqués (qui peuvent contenir un «malware»)



Triggers : un contenu malicieux est inutile s’il n’est pas utilisé, c’est pourquoi il est intéressant de connaître les moyens de générer des événements.



Actions : même si les actions ne sont pas nécessaires pour exploiter une faille, elles sont à suspecter car la plupart du temps un fichier PDF ne contient pas d’actions dynamiques.



Revenons aux résultats de l’analyse de notre fichier suspicieux! Si le résultat de l’analyse est suspect il apparaît en rouge. Cela signifie que vous devez vous méfier de ce PDF et l’analyser plus en détails.



A bon entendeur...



Sources: « Origami in PDF » (http://www.security-labs.org/origami/), “Blog de l’équipe R&D Essec” (http://esec.fr.sogeti.com/blog) et MISC n°38 (je ne saurais que trop vous recommander de vous y abonner) avec l'article "Les nouveaux malwares de document" d'Alexandre Blonce, Eric Filiol et Laurent Frayssignes.

samedi 19 septembre 2009

Patcher vos applicatifs avec Secunia

Secunia est un fournisseur de services pour la sécurité des ordinateurs permettant de traquer les vulnérabilités de plus de 12.400 logiciels applicatifs et systèmes d'exploitations.


De nombreux ordinateurs possèdent des versions non-patchées des applications les plus populaires. Et les utilisateurs oublient souvent de les mettre à jour. Secunia se charge pour vous de vérifier les versions de vos applications et vous propose les patchs de sécurité lorsqu'ils existent.

Secunia permet de scanner votre ordinateur à partir de leur site web. Mais il propose également un petit logiciel gratuit appelé Secunia PSI à installer sur votre poste client qui fonctionne en tâche de fond et qui scanne periodiquement vos applications vous permettant ainsi d'avoir un statut clair de la sécurité de votre ordinateur. Secunia permet via Secunia PSI de mettre à jour vos applicatifs.

Secunia s'est fait connaître en découvrant des vulnérabilités '"0-day" majeures dans Internet Explorer et de nombreux autres applicatifs.


Source: http://secunia.com/

samedi 12 septembre 2009

Du rififi dans le Wifi! Le WPA malmené!

Depuis le récent article des scientifiques japonais concernant la possibilité de craquer WPA (Wifi Protected Access) en 1 minute (http://blogs.zdnet.com/BTL/?p=23384), je ne sais pas pour vous, mais pour moi, quelques éclaircissements s'imposent!


Un peu d'histoire...

En 2003, Moskowitz a montré une faiblesse de WPA devant une attaque par dictionnaire. Mais cette faiblesse peut être facilement évitée en générant la clef maître à partir d'une chaîne de caractères longue et aléaoire.

En 2008, Beck et Tews ont proposé une attaque pratique sur les implémentations de WPA qui supportent IEEE802.11e QoS (Quality of Services). Cette attaque appelée l'attaque Beck-Tews (c'est original!) permet de récupérer la clef MIC et un texte en clair à partir d'un paquet encrypté court tel qu'un paquet ARP ou DNS. Ces paquets courts de type ARP ou DNS sont intéressants car ils ne nécessitent pas de fragmentation en plusieurs messages et réduisent le temps de calcul. L'objectif de l'attaque Beck-Tews n'est pas d'obtenir le texte en clair mais de retrouver la clef MIC et de l'utiliser pour falsifier un paquet.

En 2009, Ohogashi et Morii (de l'université d'Hiroshima) généralisent l'attaque Beck-Tews à toutes les implémentations de WPA. En appliquant l'attaque Beck-Tews à une attaque MITM (Man In The Middle), ils réduisent le temps d'exécution de l'attaque à 1minute. Pour plus de détails vous pouvez jeter un oeil à l'article de Ohogashi et Morii.


Détaillons un peu le scénario de l'attaque Ohogashi-Morii

Ohogashi et Morii affirment que leur attaque s'applique à toutes les implémentations WPA. La pré-condition pour exécuter l'attaque Beck-tews sur WPA est d'obtenir une trame encryptée dont la valeur de l'IV (Initialization Vector) est plus grande que la valeur courante du compteur TSC (TKIP Sequence Counter). Beck-Tews satisfont cette condition en utilisant les caractéristiques de IEEE802.11e QoS.
Les caractéristiques de IEEE802.11e QoS autorisent 8 canaux différents pour des flots de données différents, et dans ce cas chaque canal à un compteur TSC indépendant. Supposons qu'un attaquant à récupéré un paquet encrypté avec un IV = 15 pour le canal 0. Alors l'attaquant ne peut pas réaliser son attaque sur le canal 0 car le compteur TSC a été mis à jour avec la valeur 15. Cependant ce même attaquant peut exécuter son attaque sur un autre canal, si le compteur TSC de ce canal est inférieur à 15.
Dans l'attaque Ohogashi-Morii, les auteurs utilisent l'attaque MITM pour d'obtenir une trame encryptée dont la valeur de l'IV est plus grande que la valeur courante du compteur TSC. L'attaquant intercepte les trames encryptées du destinataire (Access Point /client). Ainsi une trame encryptée dont la valeur de l'IV est plus grande que la valeur courante du compteur TSC peut être obtenue puisque le paquet capturé n'a pas atteint le destinataire.

L'attaquant se place entre le client et l'AP en utilisant une antenne directionnelle ou une plus forte puissance de transmission. Pour établir le MITM entre le client et l'AP (Access point), l'attaquant transmet des "Beacons" et des "Probe Responses" sur un canal différent et utilisant le même SSID que l'AP légitime.

L'attaquant doit ensuite obtenir la clef MIC pour générer et injecter des trames modifiées.


Quelques détails techniques...

WPA s'appuie sur des mécanismes de confidentialité basés sur TKIP ou CCMP, et sur deux mécanismes d'authentification: EAP pour le marché entreprise et hotspot, et PSK (Pre-Shared Key) pour le marché résidentiel (clef partagée entre tous les utilisateurs et les APs).
Le standard 802.1x est une solution de sécurisation, mise au point par l'IEEE, permettant d'authentifier un utilisateur souhaitant accéder à un réseau (filaire ou non) grâce à un serveur d'authentification. Le standard 802.1x repose sur le protocole EAP (Extensible Authentication Protocol), défini par l'IETF, dont le rôle est de transporter les informations d'authentification des utilisateurs.
Le tableau ci-dessous résume les différentes méthodes EAP (Extensible Authentication Protocol):



Le tableau ci-dessous décrit les méthodes d'encryption utilisées par les WLAN en 802.11:





TKIP signifie Temporary Key Integrity Protocol. Il utilise un message de vérification d'intégrité appelé "Michael" alias "Mike". Comme WEP, TKIP utilise l'algorithme d'encryption RC4.

Avec un mécanisme de confidentialité basé sur TKIP, un clef maître (PMK) est partagée entre le point d'accès (AP) et le client. Soit la clef maître est partagée en suivant le modèle du WEP comme dans le modèle WPA-Personal du tableau ci-dessus, soit la clef maître est dérivée dans le contexte de l'authentification EAP (avec un serveur d'authentification 802.1x) comme dans le modèle WPA-Entreprise du tableau ci-dessus.

En d'autres termes, le standard fournit 2 méthodes de distributions des PMKs. Quand un serveur d'authentification 802.1x est utilisé, la PMK est dérivée lorsqu'un client s'authentifie sur le serveur. Pour les réseaux qui ne supportent pas 802.1x, une clef partagée appelée PSK (Pre-Shared Key) est "distribuée" à tous les clients et les APs. Cette PSK est la PMK.
La PMK permet de générer la clef MIC (64 bits) et une clef d'encryption (128 bits). Un MIC (Message Integrity Check) est généré à partir de la clef MIC et d'une donnée; ce MIC est utilisé pour détecter la falsification du message (i.e. son intégrité). La clef d'encryption permet d'encrypter et de décrypter les paquets.


CCMP signifie CTR (Counter mode) with CBC-MAC (Cipher Block Chaining Message Authentication Code) Protocol. CTR est un attribut de la méthode d'encryption. CBC-MAC est utilisé pour l'intégrité des messages et l'authentification. CCMP utilise l'algorithme d'encryption AES (Advanced Encryption Standard).


TKIP et CCMP utilisent une clef maître séparée appelée PMK (Pair-wise Master Key) pour chaque couple de noeuds e.g. un client et un AP ou deux clients. La clef maître est utilisée pour dériver d'autres clefs qui sont utilisées pour encrypter/décrypter le trafic entre le couple de noeuds. Cette approche permet de moins exposer la clef maître.
L'association entre 2 noeuds du réseau est créée par l'échange de 4 paquets appelés "4 way handshake". Pendant cette transaction les noeuds dérivent la PTK (Pair-wise Transient Key) qui est ensuite partitionnée pour produire les autres clefs qui seront utilisés pour l'encryption et l'intégrité. La PTK est dérivée à partir de la PMK et de valeurs aléatoires fournit par le client (SNonce) et l'AP (ANonce).
Quand TKIP ou CCMP sont utilisés, le traffic "broadcast" et "multicast" est encrypté en utilisant une clef de groupe. La clef de groupe appelé GTK (Group Temporal Key) est distribuée pendant le "4 way handshake".

Le tableau ci-dessous compare WEP, TKIP et CCMP:





Si nous devions conclure...

Les attaques Beck-Tews et Ohogashi-Morii se basent sur le mécanisme de confidentialité TKIP. Pour plus de sécurité il est donc conseillé d'utiliser le mécanisme de confidentialité CCMP. Mais pour cela le matériel doit implémenter AES.

On remarque cependant qu'un IDS (Intrusion Detection System) convenablement configuré peut détecter la tentative de MITM nécessaire à la réalisation de l'attaque.

A bientôt...

Source: "Analysis of MITM based TKIP attack described in paper titled - "A Practical Message Falsification Attack on WPA" by Robbie Gill et le cours de Laurent Butti sur la sécurité des réseaux (France Telecom).

samedi 5 septembre 2009

Forger des PDFs malveillants avec Origami

Dans cet article nous allons voir comment créer des PDFs malveillants en utilisant Origami. Origami est un ensemble d'outils en Ruby permettant d'analyser et de forger des documents PDF.

La vidéo ci-dessous décrit succintement comment utiliser Origami pour forger un PDF malveillant.


Vous pouvez télécharger ci-après 2 exemples de PDFs malveillants:


PDF contenant l'exécution de code Javascript et lancement du browser



PDF contenant le lancement de l'application "calc.exe"



D'une manière générale pour éviter d'avoir des applicatifs présentant des failles de sécurité, vous devez posséder un outil comme Secunia permettant de détecter les mises à jour de sécurité disponibles pour les applicatifs installés sur votre machine.

Dans un prochain article nous verrons comment, avec Origami, il est possible d'analyser les fichiers PDF afin d'y découvrir d'éventuels dangers. Mais c'est une autre histoire...!


Source: http://security-labs.org/origami/ de Guillaume Delugré & Fred Raynal. Merci également à Laurent Butti.

dimanche 19 juillet 2009

Comment gérer les applications des clefs USB sur votre bureau?


English version


Cet article vous présente un petit outil gratuit appelé "USB Grabber" développé par Prox-IA.


Cet outil permet de faire apparaître sur le bureau de votre ordinateur les raccourcis de vos applications préférées se trouvant sur vos clefs USB. Lors de l'insertion d'une clef USB, "USB Grabber" crée un raccourci sur le bureau pour les applications que vous aurez configurées. "USB Grabber" permet également d'exécuter automatiquement cette application si vous le souhaitez. Il permet aussi de créer un raccourci vers n'importe quel autre type de fichier (.ppt, .pdf, .doc,...).

Lors du retrait de la clef USB, "USB Grabber" se charge d'enlever du bureau les raccourcis des applications se trouvant sur la clef USB retirée.

Cette outil a été developpé afin de faciliter l'accès aux applications "portables" des clefs USB dans des environnements où les "autorun" sont désactivés ou avec Windows 7 qui fait disparaître la fonctionnalité d' "autorun" (cf l'article du blog sur le sujet "Plus d'Autorun dans Windows 7...!").

"USB Grabber" a actuellement été testé sur Windows XP SP2, SP3 et Windows 7. Vos commentaires, remarques, suggestions pour améliorer cet outil sont les bienvenus. "USB Grabber" est actuellement en version anglaise. Si vous souhaitez une version dans une autre langue vous pouvez nous en faire part.

Pour installer "USB Grabber" vous pouvez télécharger le programme ICI. Puis vous pouvez extraire le contenu du fichier "rar" dans le répertoire de votre choix. Et enfin si vous le souhaitez vous pouvez créer un raccourci sur votre bureau pour "USB Grabber.exe" et configurer votre ordinateur pour lancer "USB Grabber" lors du "boot".

La première étape de l'utilisation de "USB Grabber" consiste à saisir un mot de passe de 8 caractères qui permet de protéger "USB Grabber" et ses données.




Pour des raisons de sécurité, le mot de passe est demandé au lancement de "USB Grabber" et lors de l'ajout, la suppression et la modification d'une application dans "USB Grabber".



Vous trouverez plus d'informations sur les applications que l'on peut installer sur une clef USB sur le site http://portableapps.com/

mardi 14 juillet 2009

PDF: attention danger!

Régulièrement nous recevons des "PDF" par mails ou nous les téléchargeons sur internet. Puis nous les ouvrons en toute confiance sans penser que la menace peut venir d'un tel fichier.

Et bien nous avons tort. La menace est aussi présente dans les "PDF". Adobe Reader et Adobe Acrobat sont actuellement sous les feux de la rampe mais bien entendu ce ne sont pas les seules applications à présenter des vulnérabilités.

Nous allons cependant nous intéresser aux "PDF" dans le cadre de cet article.

Le scénario est le suivant. Notre cible télécharge un "PDF" sur internet et l'ouvre. En l'ouvrant un canal est établi entre la cible et le pirate. Et le pirate dispose alors d'un accès à la cible grâce auquel il peut réaliser ce qu'il souhaite.

La vulnérabilité utilisée dans cette session a été découverte en Avril 2008 par Secunia Research (Référence CVE: CVE-2008-2992). Elle est causée par une mauvause gestion des limites dans la vérification des chaînes de caractères de la fonction javascript "util.printf()". Cette vulnérabilité peut être exploitée pour causer un débordement de la pile via un PDF spécialement conçu.

C'est ce que nous allons voir dans la vidéo ci-dessous:



C'est pour toutes ces raisons que je ne saurais trop vous conseiller de mettre à jour, non seulement votre OS avec les patchs fournis, mais également vos applicatifs comme Adobe Reader et les autres. Mettre à jour vos applicatifs, c'est intégrer les corrections des dernières failles de sécurité.

Vous trouverez un outil intéressant sur le site http://secunia.com/ pour vous tenir au courant des patchs de vos applicatifs (Secunia propose un outil à installer sur votre ordinateur pour scanner les applications installées et vous prévenir des mises à jour éventuelles).

A bon entendeur...!

dimanche 5 juillet 2009

Quand Metasploit joue au Keylogger!

Au travers de cet article nous allons découvrir que Metasploit permet aussi de faire du keylogging à distance.

L'attaque se passe en trois temps. La première étape consiste à exploiter une faille présente sur la machine cible (dans notre cas un Windows XP SP2). La faille choisit est la faille MS08-067.
La deuxième étape consiste à injecter la dll qui nous permettra de faire du keylogging sur le poste cible. La dernière étape consiste à exploiter cette faille en associant le keylooging aux processus qui fonctionnent sur la machine cible et que l'on veut surveiller. Dans le cadre de la vidéo nous associons notre keylogger aux processus "explorer.exe" et "winlogon.exe".


Afin de décrire en quoi consiste la faille MS08-067, vous trouverez ci-après un extrait du bulletin de sécurité Microsoft MS08-067 paru le 23 octobre 2008:

"Cette mise à jour de sécurité corrige une vulnérabilité signalée confidentiellement dans le service Serveur. La vulnérabilité pourrait permettre l'exécution de code à distance si un système affecté recevait une requête RPC spécialement conçue. Sur les systèmes Windows 2000, Windows XP et Windows Server 2003, un attaquant pourrait exploiter cette vulnérabilité pour exécuter du code arbitraire sans nécessiter d'authentification. Il serait possible d'utiliser cette vulnérabilité dans la création d'un ver. Les meilleures pratiques en matière de pare-feu, ainsi que les configurations par défaut des pare-feu, contribuent à protéger les ressources réseau contre les attaques lancées depuis l’extérieur de l’entreprise.

Il s'agit d'une mise à jour de sécurité de niveau « critique » pour toutes les éditions prises en charge de Windows 2000, Windows XP, Windows Server 2003 et de niveau « important » pour toutes les éditions prises en charge de Windows Vista et Windows Server 2008."

Pour information les bulletins de sécurité de Microsoft peuvent être consultés à l'adresse suivante: http://www.microsoft.com/france/technet/security/bulletin/default.mspx

Sur ce site vous avez la possibilité de vous abonner aux newsletters et alertes Sécurité Microsoft.

Pour ceux qui ne sont pas familier avec les processus de Windows, l'explorateur Windows ("explorer.exe") est l'application utilisée dans le système d'exploitation Windows pour l'affichage, l'exploration et l'utilisation des fichiers et répertoires.

Quant à "winlogon.exe", c'est un composant de Windows qui gère l'ouverture et la fermeture de session, et le "Ctrl-Alt-Delete".
En particulier, il charge le profil d'un utilisateur après qu'il se soit authentifié, et il gère l'écran de veille.

Vous trouverez ci-dessous la vidéo de l'exploit:


D'une manière générale pour éviter d'être la cible de ce type d'attaque vous devez avoir un pare-feu personnel mis à jour.

Bien entendu votre pare-feu peut lui même être la cible d'attaque afin de vous laisser croire qu'il contrôle la situation alors qu'il a été désactivé. Mais ceci est une autre histoire...!

lundi 29 juin 2009

Keyloggers et screenloggers

On nous parle souvent des keyloggers et des screenloggers qui permettent pour les premiers, de récupérer les informations saisies par l'utilisateur au travers de son clavier ou pour les seconds, de faire des copies de l'écran de l'utilisateur à intervalles de temps réguliers.


L'objectif de cette article est de se faire une idée concrète de cette menace pour mieux la comprendre et adopter les bonnes contre-mesures.

Bien entendu il existe de nombreux outils de ce type, mais il a fallu faire un choix et comme vous le savez "Choisir c'est renoncer...!".

Nous avons testé pour vous Ghost Keylogger 3.40 et Spector Pro 5. Parmi ces deux outils, seul Spector semble être un vrai produit avec une existence légale au travers de la société SpectorSoft (http://www.spectorsoft.com/)

Vous trouverez ci-dessous la vidéo des tests.


Dans un prochain article nous verrons comment, avec Metasploit, il est possible de récupérer "à distance" les informations saisies par l'utilisateur sur son clavier. Mais c'est une autre histoire...!

Source : SpectorSoft (http://www.spectorsoft.com/) & Matthias que je remercie

vendredi 5 juin 2009

"USB Dumper", l'aspirateur des clefs USB...!

On pourrait croire que l'arrivée de Windows 7 faît définitivement disparaître la menace des clefs USB. Mais ce n'est malheureusement pas le cas! Windows 7 protége l'ordinateur d'une clef USB malveillante mais qui protège une clef USB d'un ordinateur malveillant?

C'est pourquoi nous avons ressorti des placards le vieil "USB Dumper" dont l'efficacité légendaire reste la même. L'USB Dumper lancé sur un ordinateur permet d'aspirer toutes les données d'une clef USB qui se connecte à cet ordinateur à l 'insu du propriétaire de la clef USB.


La plupart des outils (malware) permettant de simuler des attaques sun un poste client sont aujourd'hui reconnues par les bons anti-virus.

Mais si vous disposez du code source vous pouvez alors recompiler le malware en le modifiant légérement et la nouvelle signature de votre malware ne sera plus reconnue par la plupart des antivirus.

C'est le cas de l'USB Dumper pour lequel vous pouvez télécharger le code et l'exécutable ICI.

La vidéo ci-dessous vous montre la marche à suivre.



Source: Bruce Schneier & Eric Detoisien

jeudi 4 juin 2009

Quelques statistiques pour mieux comprendre le contexte de la sécurité !

Vous trouverez ci-dessous quelques statistiques qui donnent un éclairage édifiant sur des failles que l'on considère souvent à tort comme obsolètes.


Dans le graphe ci-dessous on observe la part des vulnérabilités qui affectent les applications web comparé au volume globale des vulnérabilités. On constate que la part prise par les vulnérabilités des applications web est en augmentation.





Parmi ces vulnérabilités des applications web on trouve l'injection SQL dont le but est d'injecter un contenu malicieux dans le site web pour attaquer les visiteurs.

On trouve également le XSS parmi ces vulnérabilités. Le nombre de vulnérabilités de type XSS reporté en 2008 est de 12.885 (en 2007 on avait reporté 17.697 vulnérabilités). La raison de cette baisse est que de nombreuses vulnérabilités de type XSS ont été corrigées en 2007. Malgré tout les failles XSS reste une des préoccupations majeures des administrateurs de site web.





Les failles sont également très présentes sur les postes des utilisateurs (au travers des browsers par exemple).

En 2008, 99 vulnérabilités ont affectés Mozilla (40 sont considérés comme peu sévère et 59 comme étant moyennement sévère). En 2007, 122 vulnérabilités avaient été documentées pour Mozilla.
En 2008, 47 vulnérabilités ont affectés Internet Explorer (16 sont considérés comme peu sévère et 31 comme étant moyennement sévère). En 2007, 57 vulnérabilités avaient été documentées pour Internet Explorer.

On constate que les browsers restent une cible attractive pour les attaquants (ainsi que les plug-ins des browsers). On observe une augmentation en 2008 du nombre de vulnérabilités autour des plug-ins Java (on passe de 4% en 2007 à 11% en 2008), et Adobe (on passe de 1% en 2007 à 4% en 2008)



On observe une confirmation de la tendance qui consiste à privilégier l'attaque du côté du poste du client.
En 2008, 7% des attaques utilisaient des vulnérabilités du côté du serveur. En 2007, 5% des attaques se basent sur des vulnérabilités côté serveur.




Il faut noter que le volume correspondant au "Top 50" des malwares en 2008 est plus du double du volume de 2007.
Il faut également noter qu'une diminution du pourcentage d'un malware d'une année sur l'autre n'indique pas forcément un déclin de ce malware.



Il est bon de redonner quelques définitions:
  • Trojan ou cheval de troie: un cheval de Troie est un malware qui permet de réaliser une fonction non souhaitée par l'utilisateur comme par exemple faciliter un accès non autorisé à l'ordinateur de l'utilisateur. A la différence des ver et des virus il ne se réplique généralement pas. Habituellement il requière une intervention du hacker pour réaliser leur fonction.
  • Worm ou ver: un ver est un programme qui peut se copier lui-même et infecter un ordinateur. Le ver peut se répandre d'un ordinateur vers un autre. A la différence du virus qui est nécessite un support, le ver est totalement autonome.
  • Virus: un virus est un programme qui peut se copier lui-même et infecter un ordinateur. Le virus peut se répandre d'un ordinateur vers un autre. A la différence du ver qui est totalement autonome le virus a besoin d'un support (un fichier, une application,..) pour se propager.
  • Back-door ou porte dérobée: une porte dérobée est un malware qui permet de contourner l'authentification normale qui sécurise l'accès "remote" à un ordinateur. La porte dérobée peut être un programme à part entière ou une modification d'un programme existant.

Source: Symantec (Avril 2009)

mercredi 13 mai 2009

Et pourtant ce n'est pas nouveau le Google Hacking !

Connaissez-vous Johnny? Pas le chanteur mais celui de IHS (I HACK STUFF). Eh bien ce Johnny là, depuis maintenant plusieurs années, recense les "googledorks"; vous savez ces personnes qui laissent sur internet des informations qui ne devraient pas s'y trouver.

Grâce à lui vous êtes au centre de l'univers du Google Hacking i.e. comment utiliser la syntaxe avancée de Google pour retrouver des informations confidentielles.



Pour le plaisir nous allons de nos propres yeux voir quel type d'informations on peut récupérer encore aujourd'hui sur internet grâce au Google Hacking.
Plus précisément nous allons rechercher les URLs contenant les paramètres "passwd" et "login" en espèrant y trouver également les valeurs associées.

Vous trouverez ICI la vidéo de notre petite ballade dans le monde du Google Hacking.

Vous trouverez la liste des "googledorks" à l'adresse suivante: http://johnny.ihackstuff.com/ghdb/

Je vous laisse conclure...

Plus d'AutoRun dans Windows 7...!

Devant l'augmentation des menaces liées à la fonctionnalité AutoRun, Microsoft a décidé de réagir par la suppression de la fonctionnalité AutoRun à partir de Windows 7 disponible en fin d'année.

Avant de détailler les changements de Windows 7 il est important de comprendre la différence entre l'AutoRun et l'AutoPlay:

L'AutoRun est une technologie utilisée pour démarrer des programmes automatiquement quand un CD ou un autre média est inséré dans l'ordinateur. L'objectif principal de l'AutoRun est de fournir une réponse logicielle à une action matérielle qu'un utilisateur déclenche sur un ordinateur.

L'AutoPlay est une fonctionnalité Windows qui permet à l'utilisateur de séléctionner quel programme démarrer quand un type spécifique de média est inséré e.g. CD ou DVD. Pendant l'AutoPlay le fichier Autorun.inf est aussi parcouru. Ce fichier (s'il est disponible) spécifie quelles commandes additionnelles seront affichées dans le menu de l'AutoPlay. De nombreux fournisseurs de logiciels utilisent cette fonctionnalité pour démarrer l'installation de leur logiciel.


Ceci étant dit, quels sont les changements apportés dans Windows 7?

Premier changement: l'AutoPlay ne supporte plus la fonctionnalité AutoRun. En d'autres termes, l'AutoPlay continuera à fonctionner pour les CD/DVDs mais il ne fonctionnera plus pour les clefs USB. Les images ci-dessous montre le changement: avec Windows 7, l'AutoPlay est sécurisé.

Avant le changement:

Après le changement:


Deuxième changement: la boîte de dialogue fait apparaître explicitement que le programme que l'on souhaite exécuter se trouve sur la clef USB.

Avant le changement:

Après le changement:




Ce changement devrait aussi être disponible sous Windows Vista et Windows XP.

Source: Microsoft

lundi 4 mai 2009

Bien qu'ancienne la faille de l'AutoRun reste d'actualité...!

On me fait parfois la remarque suivante: "L'utilisation de l'AutoRun sur une clef USB n'est pas nouveau, regardez Conficker!". Cette remarque est juste mais l'utilisation de cette faille fait toujours de nombreux ravages.
Vous trouverez ci-dessous quelques statistiques confirmant l'actualité de la menace.

La WLO (WildList Organization) produit chaque mois la liste des virus confirmés se répandant parmi les utilisateurs. Leur compte des virus identifiés comme étant des Worm:Win32/AutoRun montre une augmentation significative.


Le tableau ci-dessous montre le nombre de virus identifiés comme étant également des Worm:Win32/AutoRun dans les laboratoires de Microsoft. On constate un nombre considérable de virus de ce type à partir de 2008.



Le graphe ci-dessous nous montre l'augmentation de la détection par Microsoft des infections répandues via l'AutoRun.



On constate une augmentation très sensible en 2008 et une présence toujours très importante début 2009.

Source: Microsoft

samedi 2 mai 2009

Cracker un mot de passe avec Cain & Abel

Pour faire suite à l'article sur les clefs USB, imaginons que nous avons récupéré en suivant la méthode décrite dans l'article "La clef USB: le maillon faible?" du 02/04/2009 les fichiers suivants sur la machine de la victime
  • C:\WINDOWS\repair\system
  • C:\WINDOWS\repair\sam


A quoi servent ces fichiers?

Eh bien le fichier "sam" contient les noms d'utilisateurs et les mots de passe utilisés sur la machine (utilisateurs locaux). Mais le fichier "sam" est encrypté en utilisant une clef appelé SYSKEY que l'on retrouve par l'intermédiaire du fichier "system". Avec ces deux fichiers et l'outil approprié nous avons la possibilité de retrouver le nom et le mot de passe de la machine "cible".

Vous trouverez plus d'informations sur le rôle de ces fichiers à l'adresse suivante: http://en.wikipedia.org/wiki/Security_Accounts_Manager.


Cain & Abel: une autre vision de l'ancien testament!

L'objectif de cet article est de décrire l'utilisation de Cain & Abel pour retrouver le nom et le mot de passe de l'utilisateur.
L'outil peut être téléchargé à l'adresse suivante: http://www.oxid.it/cain.html.


L'utilisation de Cain & Abel permet de réaliser une attaque "brute-force" pour trouver le mot de passe. On note immédiatement que plus le mot de passe est complexe et plus le temps nécessaire à Cain & Abel pour retrouver le mot de passe sera important.



Action


Afin de limiter dans le temps la recherche du mot de passe, nous avons réduit l'ensemble des caractères utilisés pour l'attaque "brute force" aux minuscules et non avons fixé la longueur du mot de passe à 7 (ce qui correspond à la longueur du mot de passe que nous recherchons). Bien entendu ces contraintes permettent uniquement de limiter le temps de recherche qui peut être très (voir trop) élévé pour des mots de passe complexes.


Comme toujours vous trouverez la vidéo décrivant l'utilisation de Cain & Abel ICI.


En conclusion

On comprend alors mieux l'intérêt d'avoir des mots de passe qui suivent les règles de base suivantes:

  • supérieur ou égal à 8 caractères
  • incluant des chiffres
  • incluant des lettres minuscules et majuscules
  • incluant des caractères spéciaux


A bon entendeur...

vendredi 1 mai 2009

Challenge Webgoat 5.2: la solution en vidéo

Vous connaissez tous Webgoat, le site web permettant de faire des tests de pénétration fournit par l'OWASP.

Et vous savez également tous que les solutions des exercices de pénétration proposés par Webgoat se trouvent à l'adresse suivante: http://yehg.net/lab/pr0js/training/webgoat.php

Et comme moi, il ne vous a pas échappé que certains exercices n'étaient pas corrigés. C'est en particulier le cas du challenge proposé par Webgoat 5.2.

C'est pourquoi je vous propose de vous donner la solution du challenge avec l'aide d'une vidéo (que vous pouvez visualiser ICI).

La solution est composée de 3 étapes:

- la découverte d'une fonctionnalité de visualisation du code Java n'apparaissant pas dans la barre de menu mais malgré tout disponible
- une injection SQL classique
- et enfin une injection de commande DOS

Bien entendu, nous utilisons Webscarab pour observer et modifier les requêtes HTTP.

Bon film!

samedi 18 avril 2009

Metasploit exploite l’absence de DEP

Dans cet article nous allons réaliser un exploit dont l’objectif est de prendre la main sur la machine « cible » en envoyant un mail « corrompu » à la cible. Cet exploit s’appuie sur la désactivation du DEP sur la machine « cible ».

DEP signifie Data Execution Protection. En d’autres termes le DEP existe pour empêcher l’exécution de code malveillant dans des zones mémoires qui ne sont pas faites pour cela. Cette technique empêche l’exécution de code rendu exploitable en réalisant un « buffer overflow » (débordement de buffer) par exemple.

DEP peut être « hardware » ou « software ».

Hardware

Le bit NX qui signifie No eXecute, est une technologie utilisée par les CPUs pour restreindre l’usage des zones mémoires soit au stockage des instructions ou du code du processeur, soit au stockage de données.

Si le processeur x86 supporte cette fonctionnalité, et si le BIOS supporte également cette fonctionnalité, et que le fonctionnalité est activée soit par le fabricant, soit par l’utilisateur, alors la fonctionnalité NX est opérationnelle sous Windows sur une base limitée (appelé « OptIn »). Cette configuration fournit uniquement une protection pour un ensemble limité du système Windows et des fichiers binaires. Pour se protéger entièrement, l’utilisateur doit choisir soit le mode “OptOut” couvrant tout les programmes et processus non spécifiquement exemptés, ou le mode “AlwaysOn” couvrant tout sans exception. Ces paramètres sont configurables au travers de l’interface “System Properties”. Si le processeur x86 ne supporte pas cette fonctionnalité, alors il n’y a aucune protection. En dehors de l’architecture x86, une version de NX existe également pour l’architecture IA-64 d’Intel (supportée par Windows).


Software

Le DEP logiciel , bien qu’il n’ait rien à voir avec le bit NX, est ce que Microsoft appelle le renforcement du “Safe Structured Exception Handling” (la gestion structurée et sécurisée des exceptions). Le DEP logiciel (aussi appelé SafeSSH) vérifie simplement quand une exception est levée pour être sur que l’exception est enregistrée dans la table des fonctions d’une application, et que l’application en a réellement besoin. Cependant bien que l’on ait l’impression que le DEP logiciel soit lié à la prévention de l’exécution de code dans les pages de données, c’est en fait une forme de protection différente.

DEP est apparu dans Windows XP Service Pack 2 et est inclus dans Windows XP Tablet PC Edition 2005, Windows Server 2003 Service Pack 1 et plus tard, Windows Vista, and Windows Server 2008, et toutes les dernières versions de Windows.


Vous allez me dire alors, je le vois bien : « Cet exploit ne peut plus être réalisé ? ». La réponse est à la fois oui et non. Oui car la plupart des postes ont les dernières versions des SP, et non car malgré tout certains ne sont toujours pas à jour et il existe, paraît-il, des possibilités de contourner le DEP. Mais ce sujet devrait être traité dans un autre article.

Quoiqu’il en soit, l’intérêt de cet article est de présenter ce type de faille, et le mode opératoire (réalisé par l’envoi d’un mail à la victime). Au travers de cet exploit on se rend également compte de la puissance de Metasploit (dans le contexte de cet article nous utilisons le Metasploit installé sur Backtrack 3).

Pour information, Backtrack n’est pas le « graal » des outils des auditeurs en sécurité. Généralement ces derniers préfèrent se créer leur propre boîte à outils. Cependant Backtrack permet de rassembler dans une VM les principaux outils nécessaires à la réalisation de la plupart des exploits (Backtrack peut aussi être installé sur une vraie machine ou sur une clef USB).

Dans la vidéo présentée en fin d’article, nous vous expliquons comment activer et désactiver le DEP sur votre machine. Ce sera l’occasion de vérifier qu’il est bien activé ;-).

La machine « cible » est un Windows XP SP2 avec le DEP désactivé (la désactivation du DEP nécessite d’avoir les droits « administrateurs » sur la machine).

Le mail envoyé à la victime contient un fichier ANI forgé pour exécuter un « buffer overflow » lors de son chargement. Les fichiers ANI gèrent les curseurs animés pour Win95 et WinNT.

La vidéo de l’exploit est visible ICI. Bon film… !

samedi 4 avril 2009

L'attaque MITM démystifiée avec Backtrack 3

L’objectif de cet article est de décrire une des nombreuses possibilités de réaliser une attaque « MITM » i.e. Man In The Middle.

Cette attaque se base sur l’ARP poisoning.

Il y a plusieurs types d'attaques pour devenir "man in the middle", nous allons voir dans cet article des attaques basées sur le protocole ARP. Le protocole ARP est un protocole de niveau 3 utilisé pour traduire des adresses IP en adresses physiques de carte réseau ou adresse MAC. Quand un équipement essaie d'accéder à une ressource réseau, il va d'abord envoyer des requêtes vers les autres équipements pour connaître l'adresse MAC associée avec l'adresse IP qu'il veut atteindre. Cette équipement va garder l'association IP - MAC adresse dans son cache, le cache ARP, pour accélérer de nouvelles connections vers cette même adresse IP. L'attaque survient quand une machine demande aux autres de trouver l'adresse MAC associée à une adresse IP. Le pirate va répondre au demandeur avec des paquets indiquant que l'adresse IP est associée à sa propre MAC adresse. Par ce biais, il va court-circuiter la vraie réponse d'association IP - MAC venant d'autre hôte. Cette attaque est référencée en tant qu'usurpation ARP (ARP poisoning ou ARP spoofing). Elle n'est possible que si le pirate et les victimes sont à l'intérieur du même domaine de broadcast qui est défini au niveau d'un hôte par une adresse IP et un masque de sous-réseau, par exemple: 192.168.1.1 255.255.255.0

Dans le cas présent une machine (le pirate) usurpe l’adresse MAC d’une autre machine (la cible). Pour réaliser cette attaque nous allons utiliser la distribution « Bactrack 3 ».


Prenons le cas d’une attaque en entreprise. Le pirate (l’employé malveillant) lance sa machine Backtrack et la connecte à son réseau d’entreprise. Il ne lui reste alors plus qu’a s’immiscer entre le routeur et la machine « cible » en utilisant Ettercap.

Lorsque cette opération est terminée le trafic de la machine « cible » transite par la machine « pirate ».

Intéressons nous au trafic HTTPS. Dans ce cas le trafic transite également par la machine « pirate ».

Si la cible se connecte sur son site mail de Google en HTTPS, elle est prévenue par un message d’erreur que le certificat n’est pas entièrement fiable. Mais pour la plupart des utilisateurs non avertis, ce message d’erreur n’est pas pris en compte et pour la plupart des utilisateurs avertis mais pressés, le message n’est pas traité avec l’importance qui devrait lui être accordé.
La machine « pirate » peut donc ainsi obtenir le nom d’utilisateur et le mot de passe du mail Google de la « cible ».

Les applications ne se limitent pas aux comptes mail malheureusement.
Vous pouvez voir la video de cette attaque ICI.

Partager avec...