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

[Pentesting] [Discovery phase] When relevant information is available ... on the Internet!

Lorsque nous commençons nos tests d'intrusion, il est important d'engranger un grand nombre d'information. Cela constitue autant de piste d'attaque par la suite. En l'occurrence, les identifiants et mots de passe sont des données privilégiées, ainsi que les documents sensibles. Pour faciliter et automatiser une telle recherche, nous allons voir deux outils de la société Edge-Security. Cette dernière vient de sortir une nouvelle version de son outil Metagoofil et il vaut le détour ! Nous allons le voir tout de suite.

Préparation de l'attaque

1/ Commençons par télécharger l'outil à l'adresse suivante : http://www.edge-security.com/soft/metagoofil-1.4.tar.

2/ Dans votre console, décompressez-le :

tar -xvf metagoofil-1.4.tar

3/Installer extract qui est nécessaire pour l'extraction des méta-données des documents.

apt-get install extract

4/ Vérifier que dans le code de metagoofil, le chemin donné pour extract est le bon (fichier metagoofil.py). Sinon, changez-le pour avec le bon path : extcommand='<chemin>'.

C'est tout, vous êtes déjà prêts !


A l'exploration !

L'outil s'utilise de la manière suivante (ex : microsoft.com) :

./metagoofil -d microsoft.com -f xls -l 100 -o microsoft-test.html -t /home/jer/metagoofil/microsoft-test/

Avec :

• -d ;
• -f (peut être doc, xls, pdf, ... ou all) ;
• -l (par défaut 100) ;
• -t (où seront stockés les documents récupérés).

Ici, nous avons utilisé les formats doc car sinon, avec le paramètre all, l'outil récupérera plus de .pdf qui sont des documents légitimement accessibles sur le WEB ce qui devrait être moins le cas pour les .xls (même si c'est moins vrai dans l'exemple que nous prenons). Puisqu'il s'agit d'une grande entreprise, nous devrions récupérer un maximum d'information. Cela nous demanderait alors par conséquent plus de temps et d'espace disque.

Une fois terminé, nous voyons apparaître les chemins de documents et les noms d'utilisateurs trouvés ainsi que les noms de services de l'entreprise !

Evidemment, nous devons éliminer les informations non pertinentes à ce niveau. Les données ont été récupérées grâce aux champs "auteurs" et "chemin" des documents, eux-mêmes localisés avec des requêtes Google. Cela nous donnes une bonne base et même des formats (de mail ? d'identifiant ?) comme emma.pXXXXXXX. N'oublions pas qu'il peut aussi s'agir de partenaires ou de client de la cible est qu'il est important de trier les résultats. Quoiqu'il en soit, ces données devraient être intéressantes par la suite du test d'intrusion ;)

Les ressources fournies par Metagoofil

Outre l'output sur le terminal, Metagoofil fournit les stocke les documents récupérés dans le répertoire désigné par l'option -t. Vous devriez y trouver des informations très intéressantes sur votre cible ... Dans notre exemple, un tableau contenant le nom de commerciaux et leur numéro interne a été trouvé. Sur une autre requête exécutée sur les .doc, un CV d'un consultant de l'éditeur a été retrouvé.
Aussi, Metagoofil founit un fichier HTLM constituant le reporting de ses recherches. En résumé, nous y trouvons pour chaque fichier (au mieux) :

• Le titre et descriptif du document ;
• Le nom de l'auteur ;
• Le suivi des révision ;
• Le nom de la dernière personne ayant sauvegardé le fichier pour la dernière fois ;
• La date de création du fichier et de modification ;
• L'outil qui a servi a créer le fichier (ex : Acrobat Distiller) voire la version (5.0.2) et même l'OS (ex : Machintosh) ;
• L'adresse MAC de la machine ;
• Le chemin où est enregistré physiquement le fichier (et donc certainement un partage ouvert puisque le fichier a été récupéré depuis Internet ...) ;
• Et souvent des données additionnelles sur les outils utilisés par la cible.

Entre fuite d'information et données importantes pour la suite du pentest, vous avez déjà ici de quoi faire ;) Voici deux examples :

Pour aller plus loin

Pour voir un autre exemple de l'utilisation de cet outil, une vidéo est disponible sur le site d'irongeek.
Pour approfondir vos recherches, il existe un certains nombre de requêtes Google qui peuvent être très utiles. Le site de Johnny LONG (auteur de "Google Hacking") devrait être une bonne source d'information. Son site se trouve ici.
Enfin, Edge-Security propose un autre outil - dans le même ordre d'idée - qui lui est plus focalisé sur la recherche d'adresses emails. Il se base aussi sur le moteur de recherche Google mais aussi le moteur de MSN, le serveur de PGP et le site linkedin. L'outil en question est appelé theHarvester et peut être téléchargé ici. Rapidement, en voici un exemple :

./theHarvester.py -d microsoft.com -l 100 -b google

Avec les options :

• -d : ici, nous gardons le même exemple ;
• -l : nombre de résultats limite ;
• -b : source de l'information parmi Google, MSN, PGP et Linkedin.

Et vous, êtes vous sûrs qu'aucune de vos informations personnelles n'est accessible sur Internet ?

[Social Engineering] Is your money safe?

Tout a commencé par un SMS ... Une nouvelle mission ? Non ! Mais finalement, ça aurait pu le devenir ... Un matin, je reçois un SMS d'une certaine banque que nous appellerons X autre que la mienne. Le texto m'indique que "je" suis à découvert de 51,29€ avec un découvert autorisé de 200€. De plus, il est écrit pour le compte "CC 12345678" (les chiffres et caractères ont volontairement été changés bien sûr). A votre avis, jusqu'où peut nous mener une simple erreur de numéro de téléphone ? Bien plus loin que l'on pourrait le penser ... L'aventure commence !

Avant-propos

Ce post a pour unique but de sensibiliser les personnes et en l'occurrence, beaucoup de gens puisque toute personne ayant un compte bancaire consultable en ligne est concernée... C'est pour cela que les informations sont transformées de sorte à ne pas enfreindre ni la loi, ni la vie privée de la personne incriminée à son insu.

Etape 1 : Récupération de l'identifiant

Je commence par me balader sur le site de la banque comme un simple utilisateur pour signaler l'incident. Dans la partie "contact", outre l'appel surtaxé, je peux remplir un formulaire pour envoyer un mail. Entre autres, je remplis le champs avec le numéro de compte. Aussi, on me propose trois types de compte : "compte chèque, compte titre ou compte épargne". Le CC dans le SMS me fait opter pour un compte chèque (ce dont nous aurions pu nous douter puisqu'il n'existe pas de découvert sur les compte titre et d'épargne). Suite à une erreur dans le formulaire, je suis renvoyé sur la même page et je remarque que le numéro de compte a été modifié : le vrai numéro de compte est en réalité précédé de trois "0". Ok, donc le vrai numéro de compte est 00012345678 (pour reprendre notre exemple factice). J'ai donc à ma disposition le premier élément pour m'authentifier, l'identifiant. La deuxième information à obtenir est le mot de passe...


Etape 2 : Récupération du mot de passe

Je découvre rapidement que le mot de passe est constitué d'un certain nombre de chiffres puisque l'on me propose un clavier numérique. Bon, ça se corse car difficile de contrer ce genre de clavier (quoiqu'il paraît que des programmes malicieux - ou malwares - font des captures d'écran ...). Il y a un bouton "valider" sous le clavier numérique mais je remarque qu'il devient "cliquable" qu'une fois avoir sélectionné 6 chiffres (au hasard, ne connaissant pas le mot de passe). Ok, il y a donc exactement 6 chiffres dans le mot de passe. Reste l'obstacle du clavier mais celui-ci sera très vite déjoué puisque un lien sur la même page du site permet une authentification "autre" en cas de problème. Je clique et hop, je me retrouve sur une page où l'on peut s'authentifier sans clavier numérique mais seulement à l'aide de deux champs de formulaire classique. Sinon, il était joli le clavier :). Pour la petite histoire, au début des claviers numériques, ils ne fonctionnaient que sous IE pour la caisse d'épargne pendant une certain temps. Il suffisait alors d'utiliser un navigateur alternatif comme Firefox.
Quoiqu'il en soit, voilà qui nous simplifie la tâche puisque nous sommes alors en face d'un mot de passe faible voire très faible puisque composé d'exactement (et seulement 6 chiffres). Je pense que vous avez déjà connu plus difficile ;) Nous avons à ce stade suffisamment d'information pour lancer une attaque :

• L'identifiant ;
• La forme et la longueur du mot de passe ;
• Des champs HTML pour tenter une attaque de type brute force.

Etape 3 : Récupération du mot de passe

Malheureusement ici, nous allons tout de suite devoir calmer nos ardeurs car nous entrerions dans un cadre non légal. Cependant, la technique est très simple et expliquée ici car elle peut servir dans de nombreux cas. C'est aussi l'occasion de voir un outil comme Brutus qui nous permet d'appliquer toutes les données récupérées. Normalement, ce logiciel est téléchargeable ici. Il se peut que vous rencontriez des problèmes mais Google est votre ami ;)

Tout d'abord, le panneau principal. Vous devez y choisir :

• target = la page du site contenant le formulaire ;
• type = HTTP (form) ;
• port = 443 ;
• Authentification options = checker "single user" et entrer le numéro de compte dans le champs User ID ;
• Pass mode = Brute Force.

Ensuite, cliquer sur le bouton "Range" et le configurer de telle sorte que seuls les mots de passe de 6 chiffres seront tentés comme le montre l'image suivante :

Dernière étape du paramétrage, définir les champs de la page HTML. Brutus peut vous aider. Pour cela, cliquer sur le bouton "Modify Sequence" du panneau général. Une nouvelle fenêtre s'ouvre. Entrez l'adresse de la cible est la page et l'identifiant dans les champs correspondants puis cliquez sur le bouton "Learn Form Settings" :

Une fois trouvé, Brutus montre le fruit de ses recherches . Sélectionner alors le champ correspondant à l'identifiant et cliquer sur "Username". De même avec "Password".

Cliquez sur "Accept" et "OK" des fenêtres ouvertes pour revenir au panneau principal. Il ne vous reste plus qu'à cliquer sur le bouton "start" et l'attaque commence. Pour le post, nous nous arrêterons ici mais je pense que vous avez l'essentiel appris l'essentiel ;)