[PENTEST WINDOWS] Find credentials using TaskManager!

En tant qu'agent confirmé, vous savez que lors d'un pentest sur Windows, vous passerez forcément par l'étape Dump de hashes et crackages. Fastidieux ? Alors voici une nouvelle méthode : passer par le TaskManager !

1 - Contexte

Ce post a pu être réalisé grâce à l'article très bien fait d'Ivanlef0u. Vous y trouverez toutes les explications. Dans le cadre d'un pentest, il faudrait que la machine auditée soit sous Windows donc et qu'une tâche planifiée au moins soit créée. Sachant que les droits administrateurs sont requis pour créer une telle action, nous devrions obtenir des credentials intéressants ;)

Dans la suite de ce post, nous reprenons le scénario depuis le début à des fins pédagogiques. Votre mission est de reproduire les étapes. Attention, vous pourriez être surpris !

2 - Mise en condition

Nous commençons par créer un tâche. Pour exemple, nous décidons de lancer le programme Paint. Mais nous aurions pu choisir n'importe quel autre programme. Deux méthodes :

• en ligne de commande :
  

at 18:05 paint.exe

• avec l'interface graphique :

Aller dans Démarrer > Paramètres > Panneau de configuration > Tâches planifiées. Dans la nouvelle fenêtre, cliquer sur "Création d'une nouvelle tâche" et suivez les instructions du wizard (ex : Paint, toutes les semaines, les jeudis à 22h45). Vous devrez renseigner les credentials ... ce qu'aura fait aussi l'administrateur de la machine auditée lors d'un test d'intrusion !

La figure suivante montre la liste des tâches créées : la première en ligne de commande (At1) et la seconde via la GUI (Paint).

3 - L'attaque

Grâce au programme d'Ivanlef0u, le travail va être très simple mais pas moins impressionnant ! Commencez par télécharger le programme que vous trouverez ici. Décompresser et via l'interpréteur de commande, rendez-vous dans le répertoire d'execution nommé exe\Release.

Il ne vous reste plus qu'à exécuter le programme ...

TaskPwdDmp.exe

... et à admirer le résultat !

Have fun ;)

[INTERNAL PENTEST] Caïn - attack local application

Que le test soit initialement interne ou que vous ayez réussi à obtenir un accès en passant par un accès externe (ex : Internet), il arrivera un moment où vous vous trouverez sur le LAN de la cible. Alors, vous aurez besoin de Caïn qui représentera un réel couteau suisse dans votre aventure ! Nous ne verrons qu'une toute petite partie de ses capacités dans ce billet mais de quoi déjà faire des ravages !

1 - Contexte

Voici le contexte qui représente dans le même temps les conditions nécessaires pour réussir les opérations qui vont suivre :

• nous avons {obtenu} un compte sur une machine du réseau locale de la cible ;
• ce compte a les droits "administrateur local" ;
• l'antivirus sur la machine de travail est inefficace ou vous avez réussi à le désactiver.

Il existe des méthodes de contournement pour la première condition. La deuxième est soit fournie par le client, soit obtenue grâce à une escalade de privilège. Quant à la troisième, nous supposons que la cible est assez sérieuse pour avoir installé un antivirus sur chaque machine. Cependant, pour le désactiver, il faudrait en théorie avoir des droits suffisants sur le domaine, sans quoi, un utilisateur pourrait le désactiver facilement.

2 - Redirection du trafic

Ici, nous souhaitons récupérer les informations sensibles que nous pouvons intercepter sur le réseau interne, en l'occurrence logins et mots de passe. Souvent, se croyant protéger sur son propre réseau, les communications sont en clair sur le réseau en question. Nous verrons que c'est souvent réellement le cas.

Alors, par une attaque appelée ARP Cache Poisoning, nous allons faire en sorte que les associations adresses MAC - Adresses IP soient modifiées dans le but de faire croire que d'autres adresses IP correspondent à notre adresse MAC. Cette attaque bien connue est bien expliquée sur Wikipédia. En plus de récupérer le trafic d'autres utilisateurs, vous le redirigez de sorte que l'opération reste transparente pour les victimes.

C'est ici qu'intervient Caïn ! Vous devriez commencer par le télécharger ici et l'installer si vous ne l'avez pas déjà fait auparavant.

2.1 - Configuration de Caïn

Dans le menu, cliquer sur Configure. par défaut, vous arrivez sur l'onglet Sniffer. Ici, vérifier que la bonne carte réseau est sélectionnée et que l'option "Don't use Promiscuous mode" n'est pas cochée.

Ensuite, rendez-vous dans l'onglet APR. Si vous avez pour but d'être discret, sélectionnez "Use Spoofed IP and MAC address" et modifier l'adresse IP et l'adresse MAC en choisissant des valeurs cohérentes. Les autres paramètres peuvent être laissés par défaut :

2.2 - Lancer la redirection de trafic

Voici la démarche à suivre :

• cliquer sur les boutons "sniffer" et "APR" dans la barre de menu en haut à gauche ;
• cliquer sur l'onglet "sniffer" (en haut) ;
• cliquer sur le sous-onglet "APR" (en bas) ;
• cliquer sur le "+" pour paramétrer l'attaque ARP Cachee Poisoning où vous choisirez la ou les machine(s) cible(s) :
  
  

• c'est bon, le sniffing est en cours !

3 - Interception des mots de passe

Il vous suffit de vous rendre dans le sous-onglet "Hosts" pour obtenir des informations intéressantes.

Encore mieux, allez dans le sous-onglet "Passwords" et là, trouvez tous les mots de passe interceptés, ainsi que les logins associés de tous les credentials qui circulent sur le réseau à travers de nombreux protocoles : HTTP, SMB, LDAP, etc.).

Have fun ;)

[PENTESTING] Get access through HTTP form using Hydra

Lors du dernier post, nous avons rencontré une interface WEB contenant une méthode d'authentification basée sur un mode dit "HTTP-Form". Puisqu'il existe de très nombreuses applications WEB utilisant cette méthode, il y a de grande chance que vous soyez amenés à tester la force du mot de passe. Nous partons du principe ici que l'attaque ne peut se faire qu'online.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

0 - Contexte

Dans ce billet, nous reprenons le cas d'une application Jonas. Nous supposons que nous avons trouver l'interface admin grâce à des scanners comme NMAP (ici, il s'agirait d'une application WEB sur le port 9000, port utilisé par défaut par Jonas) ou des scanners WEB comme Nikto ou Wikto qui sont capables de trouver les pages de ce type. Notre cible est donc http://123.123.123.123:9000/jonasAdmin, sachant que c'est ici que se trouve par défaut la page d'administration de l'appli J2EE en question. Aussi, nous savons - ou avons appris suite à nos recherches - qu'il existe un nom d'utilisateur par défaut : jonas. Pour terminer, nous supposons que le mot de passe a été changé et n'est plus celui par défaut (qui serait ici jonas).

1 - A la recherche des informations clés !

Pour réussir notre attaque, nous utiliserons Hydra de THC. Ensuite, nous avons besoin d'un certain nombre d'éléments, à savoir :

• le nom du champ contenant le login dans la page WEB ;
• le nom du champ contenant le mot de passe dans la page WEB ;
• le nom de la page / du script vérifiant la validité ou non du couple login/mot de passe fourni par l'utilisateur ;
• un mot spécifique retourné par la page d'erreur en cas d'échec de l'authentification.
  

Il existe plusieurs méthodes pour obtenir ces informations. Mais la méthode la plus fiable qui nous assurera de toutes les avoir est d'utiliser un proxy local. S'il en existe bien d'autres, nous utiliserons ici Paros.

Une fois Paros lancé, nous configurons notre navigateur de sorte qu'il utilise ce proxy local (par défaut sur le port 8080). Cette opération peut se faire manuellement dans les options de votre navigateur (Outils > Options > Avancé > Réseau > Paramètres) ou via une extension après configuration (ex : l'extension Switch proxy de firefox).


Nous allons maintenant sur la page http://123.123.123.123:9000/jonasAdmin et tapez jonas en tant que login et un mot de passe aléatoire, exemple jonas pour être sûr que le mot de passe par défaut n'a pas été laissé tout simplement.


Effectivement, le mot de passe a été changé. Cependant, nous obtenons la dernière information clé et nous utiliserons le mot Invalid.

Nous retournons maintenant dans Paros :


La première requête POST contient toutes les infos dont nous avons besoin :

• le champ login à utiliser est j_username ;
• le champ mot de passe à utiliser est j_password ;
• la page à utiliser est j_security_check.

Nous sommes parés ! Il est donc temps de passer à l'étape suivante.


2 - Crackage du mot de passe

Pour casser le mot de passe, nous avons deux solutions : soit par brute-force, soit une attaque par dictionnaire. En tant que bon agent de Mission-Security, vous n'aurez pas négligé la phase de prise d'information et vous aurez certainement une bonne idée de ce que pourrez être le mot de passe. Alors, commençons par une attaque par dictionnaire et seulement ensuite, tenter une attaque par brute-force en cas d'échec.
Donc, une fois écrit votre fichier de mots de passe personnalisé pour la cible (appelé ici passwords.txt), nous pouvons lancer Hydra avec la commande suivante (ATTENTION : votre antivirus peut empêcher l'exécution du cracker) :

hydra -l jonas -P password.txt -s 9000 -o results.txt 123.123.123.123 http-post-form "/jonasAdmin/j_security_check:j_username=^USER^&
j_password=^PASS^&submit=Login:Invalid"

NB : avec -s, le numéro du port.

Le résultat ne se fait pas attendre :

Have fun ;)

[WEB PENTESTING] Hack a JOnAS Web Application

Avec le WEB 2.0, les applications WEB se sont largement multipliées, augmentant dans le même temps les failles de sécurité. Parmi ces applis, nous trouvons JOnAS. Le post suivant propose un scénario d'attaque dans le cas où vous trouveriez cette solution.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

1 - Avoir accès à la page d'administration

Supposons que nous avons repéré JOnAS - une application WEB téléchargeable sur *NIX et WIN* - sur un serveur cible, tournant par défaut sur le port 9000. Il suffit d'utiliser notre navigateur pour nous retrouver sur la page de la cible (ici, à l'adresse 192.168.123.123 pour notre démonstration, reposant sur une plateforme Windows mais les tests peuvent aussi être lancer sous *NIX) : http://192.168.123.123:9000/jonasAdmin. Vous arrivez sur la page suivante :


Par défaut, les credentials sont jonas/jonas, tentez votre chance ! Sinon, il existe de nombreuses méthodes pour trouver le mot de passe s'il a été changé :

• Avec Brutus (cf. la fin du post "Is your money safe?") ;
• Avec Hydra. Ce deuxième cas fera l'objet du prochain post.

2 - Ajouter le module malicieux

Une fois loggé, nous pouvons déployer un nouveau module sur le serveur. Celui-ci, nommé mission-security.war, contiendra les pages malicieuses ... Pour cela, sur la page d'admin de JOnAS :

• Etendez "Deployment" (colonne de gauche) ;
• Cliquez sur "Web Modules (WAR)" ;
• Cliquez sur le deuxième onglet "Upload" (page principale) ;
• Cliquez sur "Parcourir" pour sélectionner le module ;
• Retrouvez le module sur votre machine ;
  
• Il ne vous restera plus qu'à cliquer sur le bouton "Upload".
  

Vous arrivez sur la page suivante :


Une fois cette opération réussie, il faut :

• Revenir sur le premier onglet, nommé "Deployment" ;
• Le module uploadé devrait apparaître dans la colonne de gauche de la page principale. Cliquez dessus pour le sélectionné ;
• Cliquez sur le bouton ">>>" pour le déployer (partie droite) ;
• Cliquez sur le bouton "Apply" pour finaliser cette étape.

Sur la page suivante, cliquez sur "Confirm" :



3 - Exécuter des commandes arbitraires

Dans votre navigateur, entrer l'URL : http://192.168.123.123:9000/mission-security/

Maintenant, c'est à votre imagination de jouer mais voici certainement l'exemple le plus convaincant :

• Cliquer sur le répertoire "win32/" (toujours en admettant que la cible est sous WIN*) ;
• puis sur la page "cmd_win32.jsp" (ou accessible directement en tapant l'URL http://192.168.123.123:9000/mission-security/win32/cmd_win32.jsp) ;
• Tapez la commande de votre choix. Ici, la commande dir en tant qu'exemple.
  

Plus exactement, le code de cette page est le suivant :


Et maintenant, Have fun !

[SECURITY TOOL] SSL power with SslNetcat!

Le protocole SSL est largement utilisé et il n'est plus besoin aujourd'hui de le présenter. Mais dans la pratique, il nous est indispensable pour sécuriser les communications par exemple. Aussi, lors de l'audit comme celui d'un site WEB en HTTPS, il nous sera très utile de communiquer via ce protocole pour effectuer nos tests. Un outil va nous servir de couteau-suisse ici, il s'agit de SslNetCat.

0 - Préparation et contexte

Pour la suite de nos travaux pratiques, nous commençons par télécharger le script SslNetCat disponible ici. Puisqu'il s'agit d'un script perl, soyons explicite et il sera enregistré ici en tant que scnc.pl. Il faut le télécharger sur une machine cliente ET une machine serveur.

Pour exécuter le script perl, nous aurons besoin de modules perl. Attention, la liste peut être différente pour votre machine :

# perl -MCPAN -e 'install "Net::SSLeay"'
# perl -MCPAN -e 'install "IO::Socket::SSL"'
# perl -MCPAN -e 'install "Net::Telnet"'
# perl -MCPAN -e 'install "IO::Socket::INET6"'

Concernant le contexte, nous avons donc besoin de deux machines. L'OS est indépendant, le tout est que vous puissiez exécuter le script perl téléchargé. Dans notre cas, nous aurons :

• Une machine serveur sous Linux, 192.168.0.10 (valeur modifiée) ;
• Une machine cliente sous Linux, 192.168.0.20 (valeur modifiée) ;

Dans la suite de ce post, nous allons reprendre les exemples de l'auteur mais en expliquant de bout en bout les cas pratiques afin que vous puissiez facilement utiliser l'outil. C'est ainsi que nous débuterons dès la génération du certificat par exemple. A noter cependant que si le but est seulement de s'exercer, l'auteur de l'outil propose des certificats et des clés de test.


1 - Créer un tunnel SSL pour sécuriser ses communications

NB : Aller directement à la partie 1.2 si vous utilisez les certificats proposés par GomoR.

1.1 - Création des certificats

1.1.1 - Etablissement de la CA

Nous utilisons openssl (que vous devez avoir mis à jour si vous êtes sous Debian !!! cf. vulnérabilité critique). Aussi, nous devons déterminer une autorité de certification (dénommée ensuite CA) pour signer le certificat mais ici, il s'agira d'un certificat auto-signé, quand bien même cela n'a aucune valeur d'un point de vue sécurité, le principe reste identique.

# openssl req -new -x509 -keyout ca-msblog.key -out ca-msblog.crt

Nous obtenons deux fichiers : ca-msblog.crt (certificat) et ca-msblog.key (clé privée) de la CA.

1.1.2 - Génération du certificat côté serveur

# openssl req -new -keyout server-msblog.key -out server-msblog.csr

Puisque le certificat sera signé localement par la CA, nous n'utilisons pas les attributs supplémentaires ("extra"). Deux nouveaux fichiers sont générés : server-msblog.key et server-msblog.csr. Envoyer ce dernier au CA s'il ne s'agit pas de la même machine.

Commençons par préparer le magasin de certificats pour la CA :

# vi /usr/lib/ssl/openssl.conf

Trouvez la ligne commençant par dir et modifiez ./demoCA par ./msblogCA.

# mkdir ./msblogCA
# cd msblogCA
# touch index.txt
# mkdir newcerts
# echo "01" > serial

Puis créons le certificat serveur lui-même :

# cd ..

# openssl ca -cert ca-msblog.crt -keyfile ca-msblog.key -out server-msblog.crt -in server-msblog.csr

Acceptez le certificat en tapant 'y' quand cela est demandé (deux fois) :

Nous venons de créer le certificat server-msblog.crt. Nous avons tous les fichiers nécessaires ;)

1.2 - Créer un tunnel de communication chiffré

1.2.1 Mettre le serveur en écoute sur le port 12345 et rediriger le trafic sur le port 80

# perl scnc.pl -vc -a ca-msblog.crt -f server-msblog.crt -k server-msblog.key -p 12345 -r localhost:80

12.2 Lancer la connexion du client vers le serveur

# perl scnc.pl -v -s localhost -p 6789 -r server:12345::ssl

2 - Audit d'un serveur Web en HTTPS

Il s'agit ici de faire de notre client un proxy SSL qui nous servira à auditer le serveur Web.

2.1 - Préparation

Nous avons besoin d'un certificat et d'une clé privée pour ce client. Ces deux éléments seront générés de la même manière que nous l'avons fait pour le serveur précédemment (cf. 1.1.2). Ainsi, nous obtenons client-msblog.crt et client-msblog.key.

2.2 - Tests pour l'audit

Pour commencer l'audit, il suffit de se connecter (sur le client avec serveur audité, 192.168.0.10) :

# perl scnc.pl -v -r 192.168.0.10:443::ssl -a ca2-msblog.crt -f client-msblog.crt -k client-msblog.key -s localhost -p 1234

NB : il faudra retourner sur la "machine-proxy", entrer éventuellement la passphrase.

Puis de lancer nos commandes (sur le client toujours - exemple) :

# perl scnc.pl -v localhost 1234
# GET / HTTP/1.0

De même, utiliser l'adresse loopback dans les outils utilisés pour l'audit du serveur HTTPS.

[SSTIC2008] Feedbacks

Lors de l'édition 2008 du SSTIC, plusieurs conférences ont porté sur les tests d'intrusion avec différents points de vue :

- point de vue théorique: le danger des outils d'intrusion automatisés ;

- point de vue pratique avec l'outil SinFP, un scanner semi-actif/semi passif pour la phase de découverte d'un test d'intrusion ;

- point de vue juridique.

1 - Outils d'intrusion automatisés (par Mathieu BLANC)

1.1 - Les menaces portés par les outils de pentest automatisés

Par outils de tests d'intrusion, on parle ici de Metasploit, Core Impact et CANVAS. Personnellement, je ne retiendrai que les deux derniers, le premier n'ayant pas pour objectif de reconstituer l'ensemble de la démarche d'un Pentest. Ensuite, la particularité de cet exposé était de montrer ces outils d'un point de vue "original", et plus précisément d'en montrer les dangers.

Les outils étudiés ont la faculté de reproduire le déroulement d'un test d'intrusion (phase de découverte, d'identification, tentative d'exploitation (à l'aide de 0day en plus d'exploits corrigés), découverte des ressources locales, élévation de privilège locale, installation d'agent pour rebond et répétition des opérations précédentes). Le but est de compromettre le maximum de machines sans se préoccuper de la furtivité.

Les solutions sont si simples que si elles sont mises à la disposition de personnes malicieuse avec seulement un minimum de compétence, cela peut s'avérer dévastateur. Or, via des réseaux pirates ou P2P, il est possible de se les procurer ...

Lors d'une erreur de la part de Core Impact, l'éditeur de Core Security, la liste des abonnés étaient disponible via la liste de diffusion des mises à jour.

Une version ancienne de Core Impact exploitait une vulnérabilité en déplaçant temporairement le sh. Cela pouvait se conclure par la création d'une backdoor en cas d'incident pendant l'exploitation.

La propagation de l'action des solutions peuvent amener à un débordement du périmètre convenu avec le client. Aussi, cela peut provoquer des attaques de type déni de service sur des applications sensibles.

1.2 - Se protéger des outils de pentest automatisés

Commencer par mettre à jour ses systèmes d'exploitation et ses applications. Ainsi, seuls les 0day, en proportion mineure, pourront affecter nos machines.

Ensuite, les agents utilisent un "multi-stage shellcode". A chaque "étage", une contre-mesure devra être trouvée. Si le second étage n'est pas exécuté, c'est que l'attaque a été bloquée à ce niveau.

Pour bloquer les attaques réseau, un IPS doté de signatures adéquat semble être la solution la plus appropriée. Ensuite, une sandbox permet de rediriger l'action des agents pour les rendre inoffensifs.

Au niveau système, les sondes de type SNORT en mode HIDS peuvent bloquer un certain nombre d'attaques.

Enfin, il est possible de contre-attaquer avec des attaques de type buffer-overflow par exemple.

2 -SinFP, prise d'empreintes active et passive (par Philippe AUFFRET)

2.1 - Les forces de SinFP

J'ai décidé de vous parler de cet outil car il peut nous être très utile lors d'un test d'intrusion. Pourquoi ? Notamment parce qu'il peut représenter une bonne alternative par rapport à nmap lorsque les conditions de tests sont complexes :

• environnement NATé/PATé ;
• présence d'équipements de sécurité (pare-feu (et ports filtrés), I{D|P}S ;
• un ou quelques ports TCP ouverts seulement ;
• implémentation d'IPv6 ;
• ...

Aussi, cet outil de prise d'empreinte dispose d'un mode passif ET actif ! Ce qui fait sa particularité. Ainsi, SinFP peut avoir la force d'un p0f et d'un nmap respectivement.

De plus, il est doté d'un mode d'invisibilité. pour accomplir cela, SinFP utilise des requêtes standards qui ne seront pas bloquées par un IDS car alors, ce dernier risquerait de bloquer des requêtes légitimes.

2.2 - SinFP, comment ça marche ?

En mode actif, 3 tests sont effectués :

• P1 : Une requête TCP SYN sans option ;
• P2 : Une requête TCP SYN avec de nombreuses options ;
• P3 : Une requête TCP SYN + ACK.

Les réponses se basent ensuite sur l'analyse des entêtes IP et TCP et une base de signature (environ 150).

En mode passif, la récupération d'information se fait :

• à l'aide d'un fichier pcap ;
• grâce à l'écoute du réseau.

Ensuite, la méthode d'analyse de la signature récupérée peut être transformée de sorte que l'analyse est assimilée à celle vue pour une signature active (cf. ci-dessus).
Il faut savoir que SinFP peut être lancé en mode mixte (ie, passif et actif).


3 -Les tests d'intrusion d'un point de vue théorique (par Marie BAREL)

3.1 - Le pentest, une problématique complexe

Il nous fallait bien le SSTIC pour aborder enfin les tests d'intrusion d'un point de vue juridique. Et qui dit consultant SSI juridique dit ... Marie Barel ! Ok, c'était écrit dans le titre ;) Pour commencer, Marie nous a fait sourire en classant Nessus dans les outils "passifs" mais nous l'avons bien compris, c'est parce qu'il n'exploite pas de faille. Pour résumer brièvement le contenu de la présentation, il faudrait retenir les phrases suivantes :

• le contrat entre le prestataire et le client, c'est très très très important ! Attendez, je rajoute encore un "très" ! et attention, les contrats type, c'est pas bien !
• il ne faut surtout pas négliger les phases de préparation (délimitation du périmètre, intervention d'un tiers ? (ex : hébergeur), etc ...) ;
• l'expert sécurité, il maîtrise !

3.2 - Se protéger juridiquement

Si le ton est quelque peu ironique, c'est qu'en réalité, les aspects juridiques sont d'une complexité inouïe et certainement plus encore que le plus difficile des pentests que vous ayez pu faire sur le plan technique et là, Marie, pour nous l'expliquer, elle maîtrise ! Ici aussi, il n'y a pas un pentest pareil et puisqu'il y a forcément risque et argent mis en jeu, la prudence est indispensable. Si des lois (notamment le code pénale) essaient de cadrer tous les scénarii, c'est irréaliste dans la pratique. En effet, les mesures de protection juridiques côtés client et prestataire souffrent de failles elles aussi : on ne peut pas être exhaustif et la réalité ne permet souvent pas de mettre en place les propositions d'une loi ou recommandation juridique. Bref, sécurité technique, organisationnelle ou juridique, même combat : il faut limiter le risque au maximum.

***

A noter que j'ai écrit deux autres posts, l'un sur la sécurisation des "green" datacenters et l'autre sur la "dépérimétrisation". Ces deux articles sont disponibles sur le blog de l'ESEC.

[PRIVILEGE ESCALATION]Alert! Your secret is known!

Si vous souhaitez récupérer les mots de passes d'une machine Windows, la solution classique consiste à booter le PC sur un CD. Outre le fait que cela prend pas mal de temps, il est possible d'empêcher le reboot sur le CD en configurant de manière sécurisée le BIOS. Alors comment fait-on ? Il est donc temps de vous présenter fgdump !


Installation

1/ Télécharger la dernière version de fgdump sur : http://swamp.foofus.net/fizzgig/fgdump/downloads.htm

2/ Euh ... c'est tout ! ;)


Utilisation basique

Tout d'abord, nous allons commencer par utiliser fgdump pour récupérer les mots de passe hashés sur la machine locale. Pour cela, nous avons besoin d'un compte ayant les droits d'administrateur sur la machine locale, ce qui est le cas du compte sur lequel nous sommes connectés. Si un antivirus tourne sur la machine (ce que nous osons espérer !), cet utilitaire se chargera de l'arrêter et de le redémarrer pour vous :)

fgdump -O 32 -v

Avec -O (optionnel) pour spécifier que la machine utilise une architecture 32 bits (sinon, 64) et -v pour "verbose". Nous obtenons les résultats suivants :

Nous voyons que l'opération a réussi. En plus d'informations utiles (comme la version exacte de l'OS), fgdump génère plusieurs fichiers dont le fichier 127.0.0.1.pwdump. Nous y trouvons notamment les informations concernant le compte jer001 qui est notre cible :

jer001:1013:B34CE522C3E4C8774A3B108F3FA6CB6D:B9F917853E3DBF6E6831ECCE60725930:::

Si de plus ce compte dispose de plus de droits que nous en avons actuellement, cela nous permettra de réussir une escalade de privilèges.

Encore faut-il cracker ce mot de passe ... John ! L'outil que nous allons utiliser est john-the-ripper, certainement le cracker de mot de passe offline le plus connu (téléchargeable à l'adresse http://www.openwall.com/john/).

john-386.exe --users=jer001 127.0.0.1.pwdump

Ensuite, pour afficher le mot de passe, nous utiliserons en plus un petit script, d'un autre agent que vous connaissez certainement ;) (Agent M.A) que je remercie au passage. Ce dernier permet d'obtenir la casse du mot de passe, ce que le cracker ne nous fournit pas.



Utilisation avancée

Parmi les options proposées par fgdump, voici les commandes qui me paraissent intéressantes :

1/ Fournir un nom pour obtenir le nom des répertoires partagés. Une fois le compte jer001 compromis, nous l'utilisons ainsi :

fgdump -u jer001 -O 32 -v

2/ Si nous auditons un sous-réseau, nous pouvons lancer la commande sur une machine distante avec l'option -h et mieux, une liste de machines distantes avec l'option -f . Nous pouvons faire encore mieux en définissant le nom d'utilisateur et le mot de passe pour chaque machine auditée avec l'option -H . La liste aura alors la forme suivante :

192.168.0.2:jer001:passw0rd
192.168.03:Alice:guess_me
192.168.0.4:Bob:Can_U_Find_Me?
...

Et pour terminer, nous ajoutons la commande -T pour exécuter plusieurs threads simultanément, ce qui permettra de rendre le travail plus rapide. Au final, nous obtenons donc la commande suivante pour tester le réseau :

fgdump -H liste.txt -T 5

Une dernière option intéressante : -s pour retrouver les mots de passe stockés par Outlook et/ou Internet Explorer :

Pour plus d'information, vous devriez lire la documentation des auteurs ici.