[STANDARD] OWASP - Episode 3

Nous continuons les tests actifs avec cette deuxième phase. Elle traite des tests sur le système d'authentification. Ce point est très important puisqu'il permet d'obtenir des escalades de privilèges et/ou des accès illégitimes s'il est mal configuré.

1 - Avant-propos

Pour rappel, la méthodologie d'OWASP décompose les tests d'intrusion en :

• une phase de tests dits passifs (collecte d'informations) ;
• neuf phases de tests actifs.

C'est la deuxième des 9 phases de tests actifs que nous étudions ici, appelé Authentification Testing (AT).

2 - Phase de tests actifs 2 : tests sur le système d'authentification


2.1 - AT-001 : Transport des credentials un tunnel chiffré

Lorsque l'authentification a lieu via Internet (e. g. portail WEB), alors il faut nous assurer que les données sensibles que sont le login et le mot de passe sont transmises de manière sécurisée entre le client et le serveur. Puis nous pouvons lancer le test suivant :
1/ Lancer un proxy local ;
2/ Effectuer une authentification via le formulaire WEB ;
3/ Est-ce que la méthode "GET" ou "POST" qui est utilisé ? (GET ne devrait pas être utilisé !) ;
4/ Est-ce que l'authentification se fait bien via HTTPS ?


2.2 - AT-002 : Énumération d'utilisateurs

Avant de chercher le mot de passe, nous avons besoin de connaître le login. A travers un page d'authentification, nous pouvons lancer plusieurs tests pour trouver cette information.

1/ Analyser les messages et codes d'erreur issus des réponses HTTP en essayant plusieurs scénarios (login valide + mot de passe valide / login valide + mot de passe faux / login et mot de passe faux). Le message doit être le même que ce soit le login et/ou le mot de passe qui est(sont) faux.

Par exemple, le site suivant renvoie cette fenêtre quand le login est faux :

Alors que si seul le mot de passe est faux, nous avons cette autre fenêtre :

Nous venons de trouver un login !

2/ Obtient-on l'erreur 403 à la place de l'erreur 404 ? (Alors la page existe pour cet utilisateur mais n'est pas accessible).

3/ Le titre de la page WEB est-il modifié selon que l'authentification a réussi ou non ?

4/ Etudier les pages et formulaires proposés pour le recouvrement de mots de passe.

5/ Obtient-on une erreur 404 (éventuellement verbeuse) au lieu d'une erreur 200 générique ?

6/ Peut-on deviner les logins ? (à partir des logins de tests, des logins déjà trouvés, selon un schéma particulier ? etc.).

2.3 - AT-003 : Compte utilisateur par défaut ou pouvant être devinés

Que ce soit sur un serveur ou un équipement réseau, un mot de passe par défaut peut être présent si l'administrateur a omis de le modifier ou s'il s'agit d'un compte non utilisé et toujours avec son mot de passe par défaut. Nous pouvons aussi trouver des logins simples qui ont servi de test la plupart du temps et n'ont pas été supprimés.

1/ Tester les logins communs (ex : "admin" / "test" / ...)

2/ Tenter de trouver un login grâce au nom de l'application ou de la société cible (ex : C0mpanie123).

3/ Utiliser le nom des contacts de la mission de tests d'intrusion pour en trouver les logins (ex : pmartin / pmartin1 / martin / ... pour Paul MARTIN).

4/ Utiliser la page d'inscription pour obtenir des informations sur le format du login (ex : adresse mail / initiales / prénom + chiffre /...).

5/ Essayer un mot de passe blanc. Hé oui, ça marche parfois !

6/ Regarder le code javascript et le code source pour obtenir des informations sur le login.

7/ Trouver des informations laissées inintentionnellement en clair dans un fichier de sauvegarde ou un commentaire de code.

8/ Trouver le schéma de login (ex : nom + 1 caractère + 2 chiffres). Pour trouver ce schéma, créer un maximum de compte.


2.4 - AT-004 : Attaque de type brute-force

Si aucun seuil n'est appliqué au compte, alors il est possible d'utiliser une attaque de type brute-force qui consistera à essayer tous les mots d'une liste (e. g. dictionnaire) ou des combinaison de caractères.

1/ Tout d'abord, quel est le mode d'authentification ? (Basic ? Digest ? HTTP-Form ?)

2/ Tenter de cracker le mot de passe à l'aide des outils JTR, Hydra, Brutus, Base64 decoder, ...
Un exemple est disponible sur un post précédent.


3/ En boîte grise ou si vous arriver à obtenir les hashes des mots de passe, vous devrez auditer la force du secret grâce aux rainbow tables et l'outil rcrack.

2.5 - AT-005 : Contourner l'authentification

1/ La page est parfois directement accessible si nous connaissons la bonne URL... Pour la trouver, il nous faudra manuellement modifier l'URL ou la trouver grâce à un scanner de site WEB.

2/ Les ressources protégées peuvent être accessible si nous modifions les paramètres contenus dans l'URL. (ex : remplacer access=no par access=yes).

3/ L'ID de session peut être trouvé. Ce cas devrait être testé en générant un grand nombre de session. Peut-on trouver une logique entre chaque ID ?

4/ Les champs d'authentification acceptent-ils une injection SQL ?


2.6 - AT-006 : Mot de passe mémorisé et fonction de reset

Il existe toujours une solution de secours au cas où l'utilisateur aurait perdu son mot de passe. Certaines solutions sont plus vulnérables que d'autres. En voici plusieurs scénarios.

1/ Peut-on directement deviner la réponse ? Imaginons que plusieurs questions sont proposées (parmi plusieurs questions secrètes auxquelles un utilisateur a répondu lors de son inscription). Dans ce cas, il faut choisir la question la plus facile :

• celle dont la réponse peut se trouver à l'aide d'un moteur de recherche ;
• ou celle qui peut reposer sur des statistiques ;
• ou celle dont la réponse fait partie d'un ensemble limité (ex : marque d'une voiture) ;
• ...

2/ Quelles sont les moyens qui sont à notre dispositions ?

• Un nombre d'erreur limité est-il configuré pour nos réponses ?
• Comment est réinitialisé le mot de passe ? (via l'envoi d'un email ? via des réponses sur le profil de l'utilisateur ? via des questions secrètes ?).

3/Existe-t-il un autre moyen de trouver le mot de passe ?

• Est-il enregistré dans le cache du navigateur ?
• Est-il transmis via un cookie persistant ?

2.7 - AT-007 : Déconnexion et gestion du cache utilisé par le navigateur

Si une session est mal configurée, elle ne se terminera pas correctement. Alors, les informations sensibles peuvent transiter ou être stockées de manière non sécurisée car non effacées grâce à une déconnexion "propre".

1/ La fonction de déconnexion est-elle correctement implémentée ?

• Existe-t-il un bouton de déconnexion ? Bien visible ?
• Les cookies de session sont-ils correctement effacés ?
• L'utilisation d'un navigateur différent permet-il de dévoiler certaines informations ?
• Le bouton "retour" du navigateur permet-il de revenir sur la page sensible ?
• Que se passe-t-il quand on empêche l'exécution de script ? (javascript)?
• Est-il possible de configurer manuellement des cookies qui fonctionnent ?

2/ Comment est configuré la fonction de timeout ?

• Existe-t-il une fonction de timeout ?
• Les tokens sont-ils détruits une fois cette limite de temps passée ?
• Les tokens générés sont-ils réutilisables ? (rejouer un token ...).

3/ Pages en cache
A travers un proxy, regarder les requêtes HTTP qui sont lancées :

pragma: no-cache

Regarder aussi au niveau HTML :



2.8 - AT-008 : CAPTCHA

CAPTCHA (pour Completely Automated Public Turing test to tell Computers and Humans Apart) est un système d'authentification basé sur le challenge-réponse. S'il est normalement solide, il peut être déjoué grâce à des défauts d'implémentation.

1/ Phase de reconnaissance du CAPTCHA :

• Quels sont les paramètres utilisés ?
• Peut-on effectuer des attaques de rejeu ? (en utilisant une ancienne valeur d'un CAPTCHA décodé couplé à un ancien ID d'une session ou en le couplant à un ancien ID d'un CAPTCHA décodé).

2/ Un CAPTCHA similaire a-t-il déjà été cassé ?

3/ Le nombre de réponse est-il limité ? La réponse elle-même peut-elle être devinée ?

4/En boîte grise, des tests supplémentaires peuvent être effectués :

• Des vulnérabilités connues existent-elles ?
• Les algorithmes de chiffrement et de hashages sont-ils suffisamment robustes ?

2.9 - AT-009 : MFAS

MFAS (pour Multiple Factors Authentication System) est aussi appelé authentification forte. Le pentester confronté à ce genre de situation aura certainement plus de difficulté à le contourner. Cependant, certains sont plus robustes que d'autres et la plupart du temps, ils ne protègent pas contre tous les types d'attaques.

1/ Dans cette section, le but est de s'assurer que le MFAS permet bien de protéger les ressources contre les menaces suivantes :

• Vols des credentials ;
• Mots de passe faibles ;
• Attaques basées sur la session (rejeu / fixation d'une session) ;
• Chevaux de troie et logiciels malicieux ;
• Réutilisation des mots de passe.

2/ Mener les tests en fonction des méthodes d'authentification rencontrés :

• OTP ;
• Carte virtuelle ;
• Clé USB ou carte à puce avec certificat ;
• OTP généré aléatoirement et transmis via SMS.

2.10 - AT-010 : Race Conditions

Les races conditions consistent à croiser plusieurs actions simultanément pour provoquer un comportement inattendu. Par exemple, effectuer deux retraits d'argent simultanément entre deux même comptes.

1/Pour toutes les actions permises pour l'application testée, essayer de lancer des actions simultanées.

2/ Le résultat obtenu est-il conforme au comportement attendu ?


La suite au prochain épisode ...

[STANDARD] OWASP - Episode 2

Suite du premier épisode qui traitait de la collecte d'information. Ici, nous abordons le premier chapitre des tests actifs. Plus précisément, ils concernent les tests sur l'infrastructure environnante et l'application auditée elle-même.

1 - Avant-propos

Pour rappel, la méthodologie d'OWASP décompose les tests d'intrusion en :

• une phase de tests dits passifs (collecte d'informations) ;
• neuf phases de tests actifs.

C'est la première des 9 phases de tests actifs que nous étudions ici, appelé Configuration Management (CM).

2 - Phase de tests actifs 1 : tests sur la configuration de l'infrastructure et de l'application

2.1 - CM-001 : Tests sur les certificats, SSL/TLS

Les certificats peuvent donner un sentiment de "fausse sécurité". Il est important alors de vérifier que les données sont transmises de manière sécurisée sans quoi un attaquant sera en mesure de récupérer les informations sensibles qui transitent. La démarche du test se déroule en trois axes :

1/ Quelle est la robustesse du chiffrement par défaut (taille de la clé suffisante ? Algorithme de chiffrement satisfaisant ? Algorithme de hashage existant et suffisant ?)


2/ En parallèle, d'autres chiffrements, dits faibles, sont-ils autorisés ? SSLv2, connu pour être vulnérable aux attaques de type Man-in-the-Middle, est-il permis ?

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

3/ Le certificat utilisé est-il valide ?

• Est-il auto-signé (non recommandé) ?
• Est-il bien signé par une autorité reconnue (recommandé) ?
• Est-il à jour (i.e. non expiré) ?
• L'URL trouvé sur le certificat correspond-elle au site WEB ?

A noter : la sécurité des certificats a déjà été abordé dans un post précédent [plus d'info, partie 2].

2.2 - CM-002 : Tests sur le Listener d'Oracle

Via le Listener d'Oracle, il est possible d'exécuter des commandes, voire de prendre la main sur le serveur. C'est pourquoi cette section a pour objectif de trouver une vulnérabilité sur ce serveur de base de données.

1/ Identifier le service à l'aide de NMAP par exemple (par défaut, il s'agit des ports 1521, 2483 ou 2484).

2/ Auditer le serveur Oracle avec l'outil de INTEGRIGY [info] [télécharger].

3/ Tester avec le client Oracle pour obtenir :

• des informations supplémentaires ;
• la liste des comptes ;
• trouver des procédures capables d'exécuter des commandes arbitraires.

4/ En boîte grise, vérifier la bonne configuration du fichier Listener.ora.

A noter : de nombreuses références et outils pour auditer un serveur Oracle sont disponibles [ici].

2.3 - CM-003 : Audit de l'infrastructure

Ce troisième point nous apportera une meilleure connaissance de l'architecture. Principalement, nous devrions avoir une meilleure vue sur les protections réseau employées.

1/ Revue de l'architecture de l'application :

• Avons-nous un pare-feu ? Si oui, l'isolation des éléments de l'architecture est-elle correctement configurée ?
• Un reverse-proxy ?
• Un répartiteur de charge ?
• Une base de données ?
• Un serveur d'authentification ?
• Etc ...

2/ Existe-t-il des vulnérabilités connues sur les éléments de l'infrastructure identifiés ? (NESSUS + securityfocus.com + tests manuels + ...)

3/ Des outils d'administration sont-ils présents ? Accessibles ?

A noter : Pour la recherche de vulnérabilités connues, voir deux précédents posts sur NESSUS et son utilisation [ici] et [là].

2.4 - CM-004 : Configuration de l'application

La présente section a pour but d'identifier les problèmes de configuration globaux de l'application et la gestion des logs.

1/ Des fichiers d'installation / connus sont-ils présents sur le serveur ? (ex : les fichiers d'installation par défaut d'Apache).


2/ Passer en revue les commentaires contenus dans le code source des pages de l'application.

En boîte grise,

3/ Auditer les fichiers de configuration du serveur WEB. Le niveau de sécurité est-il suffisant ?

4/ La gestion des logs est-elle satisfaisante ?

• Comment sont traitées les informations sensibles ?
• Où sont stockés les logs ?
• De quel manière sont-il stockés ? (espace disque suffisant ? partitionnés par application ? supervisés ?)
• Comment est appliquée la gestion des logs ? (période ? compression des archives ? permissions attribuées sur les archives suffisamment restrictives ?)
• Les logs importants sont-ils bien audités ? (ex : erreurs 40x et 50x).

2.5 - CM-005 : Contrôle des extensions de fichiers

Les extensions de fichiers peuvent d'une part révéler de nouvelles informations. D'autre part, elles peuvent prouver l'existence d'un type de fichier et donc la présence d'informations sensible s et/ou techniques.

1/ Lancer des requêtes HTTP avec des ressources dont l'extension est différente. Quel est le comportement du serveur WEB ?

2/ Trouver les répertoires contenant les scripts (grâce à Nessus, Nikto, Crawler, ...).

2.6 - CM-006 : Fichiers anciens, de sauvegarde et non référencés

Bien souvent, des fichiers sont stockés sur le serveur par oubli ou par mégarde. Malheureusement, ils fournissent souvent des informations précieuses ou des accès illégitimes.

1/ Déduire l'existence de nouveaux fichiers / répertoires. Par exemple,

• s'il existe le fichier removeuser.asp, tenter adduser.asp ;
• s'il existe le répertoire /users, existe-t-il le répertoire /admin ?

2/ Trouver de nouveaux fichiers qui seraient cités :

• dans les commentaires du code source ;
• dans les codes javascript ;
• dans le fichier robots.txt.

Exemple récupéré sur le site www.lemonde.fr/robots.txt :

User-agent: *
Disallow: /web/recherche_resultats/
Disallow: /web/recherche/
Disallow: /web/yahoosearch/resultats/
Disallow: /web/newsletter_exemple/
Disallow: /web/teaser/
Disallow: /web/inscription_newsletter/
Disallow: /qui-sommes-nous/
Disallow: /web/abopapier/
Disallow: /services-aux-internautes/
Disallow: /web/ep/service_clients/
Disallow: /web/siteweb/
Disallow: /web/imprimer_element/
Disallow: /web/imprimer_archive/

3/ Tenter de trouver de nouveaux fichiers en modifiant leur extension ou en ajoutant une nouvelle (ex : .bak, .old, etc ...).

4/ Chercher s'il existe des vulnérabilités connues affectant le serveur WEB permettant par exemple de lister les répertoires et fichiers ou de récupérer des informations techniques.

5/ Chercher des fichiers via :

• les moteurs de recherche ;
• la page cache sauvegardée par Google, Yahoo, ou les sites d'archivage (ex : archive.org) ;
• les liens fournis par les sites tiers.

2.7 - CM-007 : Interfaces d'administration de l'infrastructure ou de l'application

Les interfaces d'administration permettent d'acquérir des droits plus importants ou du moins, d'exécuter des commandes qui ne sont pas permises pour un utilisateur standard. De tels accès peuvent mener à la compromission du serveur lui-même.

1/ Énumérer les répertoires et fichiers pouvant contenir une interface d'administration (ex : /admin).

2/ Trouver les interfaces grâce aux commentaires ou aux liens WEB parcourus par l'application.

3/ Voir la documentation du serveur et de l'application pour en connaître les répertoires d'administration par défaut. Éventuellement, testes les couples login/mot de passe par défaut (ex : site).

4/ Trouver une interface d'administration sur un autre port. Cet exemple a été abordé dans des posts plus anciens avec JonAs et JBoss.


5/ Est-il possible d'accéder à une interface d'administration en modifiant un cookie ?


2.8 - CM-008 : Tester les méthodes HTTP autorisées et test de l'attaque XST

Certaines méthodes HTTP permettent des actions malicieuses. Elles doivent donc être restraintes ou du moins contrôlées correctement pour éviter qu'un pirate en abuse pour exécuter des commandes arbitraires par exemple.

1/Quelles sont les méthodes HTTP autorisées ? Deux manières peuvent nous apporter la réponse :

a) Netcat + la méthode OPTIONS. Cette dernière liste toutes les méthodes actives si elle est elle-même activée.

nc www.cible.fr 80
OPTIONS / HTTP/1.1

b) Utiliser l'outil Metoscan

POST => N/A
GET => 200 (OK) / 400 (BAD REQUEST)
CONNECT => 200 (OK) / 400 (BAD REQUEST)
PUT => 200 (OK) / 400 (BAD REQUEST)
DELETE => 200 (OK) / 400 (BAD REQUEST)
HEAD => 200 (OK) / 400 (BAD REQUEST)
TRACE => 200 (OK) / 400 (BAD REQUEST)
...

Bien sûr, chaque méthode peut être testée manuellement.

2/ Test de l'attaque XST

Possible si la méthode TRACE est active. Il faut aussi qu'une faille de type XSS (côté serveur) ou que l'exécution de code javascript (côté client) nous permette de lancer une attaque.

3/ Tests des commandes arbitraires

Tester si la méthode JEFF est active. Si oui, une attaque pourra être envisagée.

nc www.cible.fr
JEFF / HTTP/1.1

4/ Contournement des contrôles d'accès via la méthode HEAD

nc www.cible.fr
HEAD /admin HTTP/1.1

A suivre : L'épisode 3 de ce post abordera l'authentification.

[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 ;)