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