De nos jours, les applications Web utilisent souvent de l'open source populaire ou un logiciel commercial qui peut être installé sur les serveurs avec une configuration minimale ou personnalisée par l'administrateur du serveur. En outre, un grand nombre de dispositifs matériels (routeurs et serveurs de bases de données), offrent configurations Web ou des interfaces d'administration. Souvent, ces applications, une fois installées, ne sont pas correctement configurés et les informations d'identification fournies par défaut pour l'authentification et la configuration initiales ne sont jamais modifiées. Ces informations d'identification par défaut sont bien connus par les testeurs de pénétration et, malheureusement, aussi par des attaquants malveillants, qui peuvent les utiliser pour accéder à différents types d'applications. En outre, dans de nombreuses situations, lorsqu'un nouveau compte est créé sur une application, un mot de passe par défaut (avec quelques caractéristiques standard) est généré. Si ce mot de passe est prévisible et que l'utilisateur ne la modifie pas lors du premier accès, cela peut permettre à un attaquant d'obtenir un accès non autorisé à l'application.

La cause profonde de ce problème peut être identifié en tant que:

• Un personnel des structures inexpérimenté, qui ne connait pas l'importance de changer les mots de passe par défaut sur les composants d'infrastructure installés;
• Les programmeurs qui laissent des portes dérobées pour accéder facilement et tester leur application et, plus tard oublient de les enlever.
• Les applications avec des comptes privilégiés par défaut, non amovibles et avec un nom d'utilisateur et mot de passe prédéfinis.
• Les applications qui ne forcent pas l'utilisateur à modifier les informations d'identification par défaut lors de la première connexion.

Lors d'un test boîte noire le testeur ne sait rien à propos de l'application et de l'infrastructure sous-jacente et donc des informations d'identification par défaut des applications. En réalité, ce n'est souvent pas le cas, et quelques informations sur l'application sont connues. Nous supposons que vous avez identifié, grâce à l'utilisation des techniques décrites dans ce guide des contrôles effectués sous le chapitre Collecte de l'information, au moins une ou plusieurs applications communes qui peuvent contenir des interfaces d'administration accessibles . Lorsque vous avez identifié une interface d'application, par exemple une interface Web d'un routeur Cisco ou un portail administrateur Weblogic, vérifiez que les noms d'utilisateur et mots de passe connus pour ces dispositifs ne donnent pas lieu à une authentification réussie. Pour ce faire, vous pouvez consulter la documentation du fabricant ou, d'une manière beaucoup plus simple, vous pouvez trouver des informations d'identification courantes en utilisant un moteur de recherche ou en utilisant l'un des sites ou des outils répertoriés dans la section références. Quant aux applications pour lesquelles nous n'avons pas une liste de comptes d'utilisateur par défaut et communs (en raison du fait par exemple que l'application n'est pas largement répandue), on peut tenter de deviner les informations d'identification par défaut valides. Notez que l'application en cours de test peut avoir une stratégie de verrouillage du compte, et de multiples tentatives de découverte avec de multiples noms d'utilisateur et mot de passe peuvent provoquer le compte à verrouiller. S'il est possible de verrouiller le compte administrateur, cela peut être gênant pour l'administrateur du système pour le réinitialiser. De nombreuses applications ont messages d'erreur verbeux qui informent les utilisateurs du site quant à la validité des noms d'utilisateurs inscrits. Cette information sera utile lors du test des comptes par défaut ou pour deviner les comptes d'utilisateur. Une telle fonctionnalité peut être trouvée, par exemple, sur la page de connexion, la page Mot de passe oublié, et lapage inscrivez-vous. Une fois que vous avez trouvé un nom d'utilisateur par défaut, vous pouvez aussi tenter de deviner le mot de passe de ce compte. Plus d'informations sur cette procédure peut être trouvé dans la section Test pour la numération utilisateur et l'utilisateur deviner Testing for User Enumeration and Guessable User et dans la section politique Testing for Weak password policy. . Étant donné que ces types d'informations d'identification par défaut sont souvent liés à des comptes administrataurs, vous pouvez procéder de cette manière:

• Essayez les noms d'utilisateur suivants - “admin”, “administratorr”, “root”, “system”, “guest”, “operator”, ou “super”. Ceux-ci sont très populaires parmi les administrateurs système et sont souvent utilisés. En outre, vous pouvez essayer “qa”, “test”, “test1”, “testing” et des noms similaires. Les différentes tentatives peuvent essayer toute combinaison de ce qui précède à la fois pour le nom d'utilisateur et les mot de passe. Si l'application est vulnérable à l'énumération des noms d'utilisateur, et que vous réussissiez à vous identifier avec l'un des noms d'utilisateur ci-dessus, les mots de passe peuvent être testés de la même manière. De plus, essayez un mot de passe vide ou l'un des suivants “password”, “pass123”, “password123”, “admin”, ou “guest” avec les comptes ci-dessus ou tout autre compte énuméré. D'autres permutations que ce qui précède peuvent aussi être tentées. Si ces mots de passe échouent, il peut être intéressant d'utiliser un nom d'utilisateur et une liste commune de mots de passe et d'essayer de multiples requêtes contre l'application. Cela peut, bien sûr, être scripté pour gagner du temps.
• Les utilisateurs de l'application d'administration sont souvent nommés d'après l'application ou l'organisation. Cela signifie que si vous testez une application nommée “Obscurity”, essayez d'utiliser obscurity / obscurity comme nom d'utilisateur et mot de passeo u toute autre combinaison similaire.
• Lorsque vous effectuez un test pour un client, essayez d'utiliser des noms de contacts que vous avez reçu dans les noms d'utilisateur avec des mots de passe communs.
• Essayez d'utiliser tous les noms d'utilisateur ci-dessus avec des mots de passe vides.
• Etudiez la source de la page et javascript récupérée par un mandataire ou en affichant la source.
• Recherchez les références à des utilisateurs et des mots de passe dans la source. Par exemple: «Si username = 'admin', puis starturl = / admin.asp else / index.asp“ (pour une connexion réussie et un échec de connexion). Si vous avez un compte valide, alors se connecter et comparer chaque éléments des demandes et réponses d'une connexion valide et ceux d'une connexion non valide, comme les paramètres cachés, les paramètres dans la requête GET (login=yes), etc
• Recherchez les noms de compte et mots de passe écrits en commentaires dans le code source. Voir aussi dans les répertoires de sauvegarde, etc le code source qui peut contenir des commentaires d'intérêt.

Comme mentionné précédemment, dans d'autres situations, lorsqu'un nouveau compte est créé sur une application, un mot de passe par défaut est généré. Ce mot de passe pourrait avoir des caractéristiques standard qui le rendent prédictible et si l'utilisateur ne l'a pas changer lors du premier accès (ce qui arrive souvent, si l'utilisateur n'est pas obligé de le changer), cela peut permettre à un attaquant d'obtenir un accès non autorisé à l'application. Les conseils donnés pour les tests des comptes par défaut dans les applications communes (à propos de la stratégie de verrouillage et des messages d'erreur verbeux) restent valables également pour ces tests. Les étapes suivantes peuvent être appliquées pour tester ces différents types d'informations d'identification par défaut:

• Etudiez la page d'enregistrement utilisateur peut aider à déterminer le format attendu et la longueur des noms d'utilisateur et mots de passe d'application. Si une page d'enregistrement utilisateur n'existe pas, déterminer si l'organisation utilise une convention de nommage pour les noms d'utilisateurs tels que leur adresse e-mail ou le nom avant le ”@“ dans l'adresse e-mail.
• Essayez d'extrapoler à partir de l'application comment les noms d'utilisateur sont générés. Par exemple, un utilisateur peut créer son propre nom d'utilisateur ou le système crée un compte pour l'utilisateur en fonction des informations personnelles ou d'une séquence prévisible? Si l'application créer ses propres comptes dans une séquence prévisible, comme user7811, essayez de fuzzer tous les comptes possibles de manière récursive. Si vous pouvez identifier une réponse différente de l'application lorsque vous utilisez un nom d'utilisateur valide et un mot de passe erroné, alors vous pouvez essayer une attaque en brute forece sur le nom d'utilisateur valide (ou essayer l'un des mots de passe communs identifiés ci-dessus ou dans la section de référence).
• Essayez de déterminer si le mot de passe est prévisible en créant de nouveaux comptes en succession rapide pour comparer et déterminer si les mots de passe sont prévisibles. *S'ils sont prévisibles, essayez de les corréler avec les noms d'utilisateur, ou tous les comptes énumérés, et utilisez les comme base pour une attaque en brute force.
• Si vous avez identifié la convention de dénomination correcte pour le nom d'utilisateur, essayez le “force brute” des mots de passe avec une certaine séquence commune prévisibles comme par exemple les dates de naissance.
• Essayez d'utiliser tous les noms d'utilisateur ci-dessus avec mots de passe vides ou en utilisant le nom d'utilisateur comme mot de passe.

Les étapes ci-après reposent sur une approche entièrement encadrée. Si seulement une partie de ces informations est disponible , reportez-vous aux tests de boîte noire pour combler les lacunes.

• Obtenez du personnel informatique les mots de passe qu'ils utilisent pour l'accès administrateur et comment l'administration de l'application est gérée.
• Examinez la base de données utilisateur pour récupérer les informations d'identification par défaut comme décrit dans la section test boîte noire. Vérifiez également les mots de passe vides.
• Examinez le code pour récupérer les noms d'utilisateur et mots de passe codés en durs.
• Vérifiez les fichiers de configuration qui contiennent des noms d'utilisateur et mots de passe.
• Examinez la politique de mot de passe et, si l'application crée ses propres mots de passe pour les nouveaux utilisateurs, vérifier la politique de l'utilisation de cette procédure.

• CIRT http://www.cirt.net/passwords

  • Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
  • Virus.org http://www.virus.org/default-password/

• Burp Intruder: http://portswigger.net/intruder/

  • THC Hydra: http://www.thc.org/thc-hydra/
  • Brutus: http://www.hoobie.net/brutus/
  • Nikto 2: http://www.cirt.net/nikto2