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