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.

jeudi 2 avril 2009

La clef USB: le maillon faible ?

Dans cet article nous allons décrire comment préparer une clef USB pour récupérer des informations sur la machine de notre utilisateur "cible"


Première étape

La première étape consiste à créer le "malware".

Les fichiers qui composent le "malware" sont les suivants:
· autorun.inf
· nircmd.exe
· malware.bat
· folder.ico
· payload.exe

Quelques mots sur l'"autorun.inf". Ce fichier permet de lancer automatiquement une application lors de l'insertion de la clef USB. C'est ce comportement que nous allons utiliser pour exécuter notre "malware".

Cepandant, la fonctionnalité "autorun" peut être désactivé sur la machine "cible" pour des raisons de sécurité que l'on comprend aisément.

Dans ce cas l'"autorun.inf" est malgré tout exécuté lorsque l'utilisateur essaie d'explorer le contenu de la clef avec l'explorateur (double-click sur "My Computer", puis double-click sur la clef USB).




Notre fichier « autorun.inf » est configuré de telle façon que lors de l’insertion de la clef USB, l’utilisateur est averti et on lui demande de confirmer l’ouverture. Le message « Open folder to view files » est affiché et sélectionné par défaut.


Ce message est celui défini dans le fichier « autorun.inf ». L’icône associée est une icône qui représente un répertoire (c’est l’icône « Folder.ico ») définit dans le fichier « autorun.inf ».


Le comportement semble tout à fait normal pour l’utilisateur mais en réalité en choisissant d’ouvrir le contenu de sa clef USB, l’utilisateur choisit d’exécuter le « malware ». La commande exécutée est celle décrite dans le fichier « autorun.inf ».


La ligne de commande utilise un outil appelé « nircmd.exe » disponible à l’URL suivante : http://www.nirsoft.net/utils/nircmd.html . Cet outil permet d’exécuter quelques tâches sans afficher d’interface utilisateur. L’option « execmd » permet d’exécuter une commande Windows. C’est cet outil que nous utilisons pour exécuter notre commande « CALL malware .bat ».


Le fichier « malware.bat » lors de son exécution permet de faire 3 opérations essentielles. La première consiste à cacher les fichiers qui ont été copiés sur la clef USB par le pirate (attrib + H fichier).

La deuxième permet d’ouvrir le contenu de la clef ; c’est le comportement attendu par l’utilisateur (start .).

La troisième et dernière permet d’exécuter la charge utile (CALL payload.exe).

La charge utile correspond au fichier « payload.exe ». Cet exécutable n’est pas présenté dans cet article. Mais il pourrait réaliser les opérations suivantes :
- voler les mots de passe Internet Explorer de l’utilisateur « cible »
- copier des fichiers systèmes
- installer un malware (permettant de prendre le contrôle de la machine)
- transférer des données privées sur la clef USB pour une récupération ultérieure ou sur un serveur « pirate »

Nous allons nous intéresser dans ce qui suit à la récupération de données privées sur la clef USB à l’insu de l’utilisateur.

Deuxième étape

La deuxième étape consiste à infecter la clef USB avec un "malware".

Cette étape peut être facilement réalisée en développant un petit logiciel qui sur détection de l’insertion d’une clef USB copie les fichiers du « malware » sur la clef.

Troisième étape

La troisième étape est l'exécution du malware sur le poste "cible".
Comme nous l’avons vu précédemment lors de l’insertion de la clef sur le poste « cible », l’utilisateur voit apparaître la fenêtre suivante qui correspond au comportement habituel lié à l’insertion de sa clef.



Si l’utilisateur est prudent (et même les plus avertis d’entre eux le sont rarement ; nous l’avons testé pour vous…), il peut remarquer que l’option « Open folder to view files » se trouve à 2 endroits dans la liste. Un utilisateur paranoïaque peut également remarquer que la première option fait référence à un exécutable qui se trouve sur la clef USB (ce qui bien entendu ne devrait pas être le cas).

Quatrième étape

La dernière étape consiste à récupérer les données
Comme pour la corruption de la clef avec le « malware » la récupération des données fonctionne sur le même principe : lors de l’insertion de la clef sur le poste « pirate », le logiciel détecte l’insertion de la clef et la présence éventuelle des données piratées. Si les données sont présentes elles sont alors copiées sur le poste « pirate ».


Prox-IA est à votre entière disposition pour vous fournir des informations complémentaires sur ce thème.
Source: MISC

Partager avec...