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