This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.3.4 Revue des fichiers pour recherche d'informations sensibles (OTG-CONFIG-004)

From OWASP
Jump to: navigation, search 
This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Résumé

Bien que la plupart des fichiers d’un serveur Web soient gérés directement par le serveur lui-même, il n’est pas inhabituel d’y trouver des fichiers non référencés,ou oubliés, qui permettent d’obtenir des informations sensibles sur l’infrastructure ou sur des justificatifs d’accès.

La plupart des scénarios reposent sur la présence d'anciennes versions de fichiers modifiés et renommés, sur des fichiers d'inclusion, qui ont été chargés selon les règles du langage utilisé, et qui peuvent être téléchargés en tant que fichiers sources, ou même des sauvegardes automatiques, ou manuelles, telles que des fichiers d'archives compressées. Des fichiers de sauvegarde peuvent aussi être générés automatiquement par le système de fichiers sur lequel l’application est hébergée, une fonction habituellement appelée "copie instantanée" ou "snapshot".

Tous ces fichiers peuvent permettre au testeur d’accéder au fonctionnement interne, aux portes dérobées, aux interfaces d’administration, ou même aux justificatifs d'accès privilégiés permettant de se connecter à l'interface d'administration et au serveur de bases de données.

Les fichiers n’ayant aucun lien avec l’application et, ayant été générés par l’édition de fichiers d’application, ou issus de copies de sauvegarde instantanées, ou les fichiers obsolètes ou, non référencés laissés dans l’arborescence du serveur Web, sont une source importante de vulnérabilités.

Editer des fichiers sur le serveur de production ou, y faire d’autres actions d'administration, peut y laisser malencontreusement des copies de sauvegarde qu'elles soient générées, automatiquement par l’éditeur lors d'une édition de fichiers, ou directement par l’administrateur lorsqu'il crée un fichier zippé d’un ensemble de fichiers pour faire une sauvegarde.

Il est facile d’oublier de tels fichiers et cela peut présenter de sérieuses menaces de sécurité pour l’application. Cela arrive parce que les copies de sauvegarde peuvent être générées avec des extensions de sauvegarde différentes des fichiers originaux. Une archive .tar, .zip ou .gz que nous générons (et oublions) a, bien sûr, une extension différente, et il arrive la même chose avec les copies générées par beaucoup éditeurs (par exemple, emacs génère une copie de sauvegarde nommée file~ lorsqu’on édite file). Une copie manuelle peut aboutir au même résultat (comme copier file en file.old). Le système de fichier sous-jacent peut faire des «copies instantanées» de vos applications, à différents moments, sans que vous le sachiez, et ils peuvent être accessibles par le Web, ce qui présente une menace de type «fichiers de sauvegarde», différente mais similaire, pour votre application.

Ainsi, ces activités peuvent générer des fichiers non nécessaires à l’application qui peuvent être gérés différemment des fichiers originaux par le serveur web. Par exemple, si nous faisons une copie du fichier login.asp vers login.asp.old, nous permettons aux utilisateurs de télécharger le code source de login.asp. Ceci parce login.asp.old sera habituellement ouvert comme un fichier texte ou brut plutôt qu’exécuté à cause de son extension. En d’autres termes, l’accès au fichier login.asp entraîne l’exécution sur le serveur du code login.asp tandis que l’accès au fichier login.asp.old conduit à renvoyer simplement à l'utilisateur le contenu du fichier login.asp.old (qui est, là aussi, le code du serveur) et à l'afficher sur le navigateur de l’utilisateur. Cela présente des risques de sécurité puisque des informations de sécurité peuvent ainsi être révélées.

Généralement, exposer le code du serveur n’est pas une bonne idée. Non seulement, vous exposez inutilement la logique de l’entreprise mais vous pouvez divulguer sans le savoir des informations relatives à l’application qui peuvent aider l’attaquant (chemin d’accès, structures des données, etc...). Ceci sans mentionner le fait qu’on trouve beaucoup trop de scripts avec des comptes et mots de passe en clair (ce qui est une pratique imprudente et dangereuse).

D’autres causes de fichiers non référencés sont dues aux choix d’architecture et de configuration quand ceux-ci permettent au serveur web d’accéder à toutes sortes de fichiers relatifs à l’application tels que des fichiers de données, de configuration, de logs stockés dans des répertoires du système de fichier.

Ces fichiers n’ont normalement rien à faire dans l’espace du système de fichiers accessible par le web puisqu’ils ne devraient être accessibles qu’au niveau de l’application, par l’application elle-même (et non par un utilisateur occasionnel qui navigue autour).


Menaces

Les fichiers de sauvegardes et, les fichiers anciens ou non référencés, représentent diverses menaces à la sécurité d’une application web :

  • Les fichiers non référencés peuvent dévoiler des informations sensibles qu peuvent faciliter une attaque ciblée d’une application ; par exemple cela comprend les bases de données de justificatifs d’accès, les fichiers de configuration contenant des références à des contenus cachés, chemins d’accès complets, etc...
  • Des pages non référencées peuvent contenir de puissantes fonctionnalités pouvant être utilisées pour attaquer l’application ; par exemple une page d’administration non publiée mais qui peut être accédée par n’importe quel utilisateur qui sait où la trouver.
  • D’anciens fichiers ou des fichiers de sauvegarde peuvent contenir des vulnérabilités qui ont été corrigées dans des versions plus récentes ; par exemple viewdoc.old.jsp peut contenir une vulnérabilité de type «traversée de répertoires» ou "Path Traversal" qui a été corrigée dans viewdoc.jsp mais peut toujours être exploitée par celui qui trouve cette vieille version.
  • Les fichiers de sauvegarde peuvent dévoiler le code source des pages prévues pour être exécutées sur le serveur ; par exemple, ouvrir viewdoc.bak peut renvoyer le code source de viewdoc.jsp, qui peut être analysé pour en rechercher les vulnérabilités qui seraient difficiles à trouver en faisant des requêtes à l’aveugle vers la page exécutable. Alors que cette menace s’applique évidemment au langages de script, tels que Perl, PHP, ASP, shell scripts, JSP, etc., cela ne se limite pas à eux seuls, comme nous le verrons dans l’exemple du prochain paragraphe.
  • Les fichiers de sauvegarde peuvent contenir des copies de tous les fichiers sous la racine (ou même en dehors) du site web. Cela permet à l’attaquant de rapidement énumérer l’application entière, dont les pages non référérencées, le code source, les fichiers inclus, etc... par exemple, si vous avez oublié un fichier nommé myservlets.jar.old qui contient (une copie de sauvegarde de) vos classes de servlet implémentées, vous exposez beaucoup d’informations sensibles pouvant faire l’objet de décompilation ou de rétro-ingénierie.
  • Dans certains cas, éditer ou copier un fichier ne modifie pas l’extension de fichier mais modifie le nom du fichier. Cela arrive, par exemple dans les environnements Windows, où les opérations de copie de fichier génèrent des fichiers suffixés avec «-Copie» ou des versions locales de cette chaîne. Puisque l’extension de fichier reste inchangée, ce n’est pas le cas où le fichier exécutable est renvoyé comme texte en clair par le serveur web, donc pas un cas de divulgation de code source. Malgré tout, ces fichiers aussi sont dangereux car il y a une possibilité qu’ils contiennent une logique incorrecte ou obsolète et peuvent, s'ils sont accédés, déclencher des erreurs d’application, qui donnent de précieuses informations à l’attaquant, si le message d’erreur s’affiche.
  • Les fichiers journaux peuvent contenir des informations sensibles à propos des usages de l’application par les utilisateurs, par exemple les données sensibles passées en paramètre aux URL, les ID de session, les URL visités (qui peuvent divulguer d’autres contenus non référencés), etc... D’autres fichiers journaux (ex. les journaux ftp) peuvent contenir des informations sensibles à propos de la maintenance de l’application par les administrateurs système.
  • Les copies instantanées de système de fichiers peuvent contenir des copies de code ayant des vulnérabilités corrigées dans les versions plus récentes. Par exemple, /.snapshot/monthly.1/view.php peut contenir une vulnérabilité de type « traversée de répertoire » qui a été corrigée dans /view.php mais qui peut toujours être exploitée par celui qui trouve la vieille version du fichier.

Comment Tester

Test en Boite Noire

Le test des fichiers non référencés utilise à la fois des techniques manuelles et automatiques et typiquement combine les suivantes :

Déductions du schéma de nommage du contenu publié

Dénombrer toutes les pages et les fonctionnalités de l’application. Cela peut être fait manuellement avec un navigateur ou en utilisant un outil d’exploration (« spidering ») d’application. La plupart des applications utilisent un schéma de nommage identifiable, et organisent les ressources en pages et répertoires en utilisant des mots décrivant leurs fonctions. A partir du schéma de nommage utilisé pour le contenu publié, il est souvent possible d’en déduire le nom et l’emplacement des fichiers non référencés. Par exemple, si on trouve une page viewuser.asp, alors il faut chercher edituser.asp,adduser.asp et deleteuser.asp. Si on trouve un répertoire /app/user, il faut aussi chercher /app/admin et /app/manager.


Autres indices dans le contenu publié

Beaucoup d’applications web laissent des indices dans leur contenu publié qui peuvent conduire à découvrir des fonctionnalités ou des pages cachées. Ces indices se retrouvent souvent dans le code source HTML et dans les fichiers JavaScript. Le code source de tous les contenus publiés devrait être revu manuellement pour identifier les indices laissés concernant les fonctionnalités et les pages.

Par exemple :

Les commentaires et les sections commentées du code source par les programmeurs peuvent faire référence à du contenu caché : 

<!-- <A HREF="uploadfile.jsp">Upload a document to the server</A> -->
<!-- Link removed while bugs in uploadfile.jsp are fixed          -->

JavaScript peut contenir des liens sur des pages qui sont uniquement émises dans l’interface graphique de l’utilisateur dans certaines circonstances : 

var adminUser=false;
:
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));

Les pages HTML peuvent contenir des FORMs qui ont été cachées en désactivant l’élément SUBMIT : 

<FORM action="forgotPassword.jsp" method="post">
    <INPUT type="hidden" name="userID" value="123">
    <!-- <INPUT type="submit" value="Forgot Password"> -->
</FORM>

Une autre source d’indices concernant les répertoires non référencés est le fichier /robots.txt, fichier utilisé pour donner des instructions aux robots d’indexation du Web : 

User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include

Recherche à l'aveugle

Dans sa forme la plus simple, il s'agit de lancer une recherche de noms de fichiers usuels via un moteur de requêtes dans le but de deviner quels sont les fichiers et les répertoires existant sur le serveur. Ce script qui utilise une commande "netcat" lira une liste de mots à partir de stdin et réalisera une attaque élémentaire par conjecture ou "guessing attack" : 

#!/bin/bash

server=www.targetapp.com
port=80

while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile


Suivant la configuration du serveur, on pourra remplacer la commande GET par une commande HEAD pour avoir des résultats plus rapides. On pourra ensuite faire une commande grep sur le fichier de sortie pour y rechercher des codes de réponse “intéressants”. Le code de réponse "200" (OK) indique habituellement qu'une ressource valide a été trouvée (a priori, un serveur ne renvoit pas une page “not found” avec un code "200").

Rechercher aussi les codes "301" (Déplacé), "302" (Trouvé), "401" (Non autorisé), "403" (Interdit) and 500 (Erreur Interne), qui peuvent aussi référencer des ressources et des répertoires qui méritent plus d'investigation.

L'attaque élémentaire par conjecture doit s'effectuer sur le répertoire racine du serveur, le "webroot", et aussi sur tous les répertoires identifiés par d'autres méthodes d'énumeration. Des attaques par conjecture, plus avancées et efficaces, peuvent être réalisées comme ceci:

  • Identifier les extensions de fichiers utilisées dans les espaces connus de l'application (ex. jsp, aspx, html), et prendre une liste de mots de base ajoutés à ces extensions ou prendre une plus longue liste des extensions communes si les ressources le permettent).
  • Pour chaque fichier identifié par d'autres techniques d'énumeration, créer une liste de mots personnalisés dérivés du nom de fichier.

Prendre une liste des extensions de fichier usuels (incluant les ~, bak, txt, src, dev, old, inc, orig, copy, tmp, etc.) et utiliser chaque extension avant, après, et à la place de l'extension actuelle du fichier.

Note: Les opérations de copie de fichiers Windows génèrent des noms de fichiers postfixés par “-Copie“ ou par des versions localisées de cette chaîne, mais ne changent pas l'extension du fichier. Bien que les fichiers “-Copie“ ne divulguent pas habituellement le source code quand on y accède, ils peuvent néanmoins divulguer des informations sensibles dans le cas où ils génèrent des erreurs quand on y accède.

Informations obtenues grâce aux vulnérabilités et aux mauvaises configurations du serveur

Le cas le plus flagrant où une mauvaise configuration du serveur peut divulguer des pages non référencées est l'énumération des répertoires. Rechercher dans tous les répertoires énumérés pour identifier ceux qui listent des répertoires.

On trouve de nombreuses vulnérabilités sur des serveurs Web personnels qui permettent aux attaquants de lister du contenu non référencé, comme par exemple :

  • Vulnérabilité ?M=D de listage des répertoires sur Apache.
  • Nombreuses vulnérabilités de divulgations de scripts sources sur IIS.
  • Vulnérabilités de listage de répertoires sur WebDAV IIS.


Utilisation de l'information accessible au public

Les pages et les fonctionnalités, des applications web sur Internet, qui ne sont pas référencées par l'application elle-même peuvent être référencées par d'autres sources du domaine public. Il existe plusieurs sources de ces références :

  • Les pages habituellement référencées peuvent toujours apparaître dans les archives des moteurs de recherche Internet. Par exemple, 1998results.asp peut ne plus être lié à un site web d'entreprise, mais cependant rester sur le serveur et dans les bases de données des moteurs de recherche. Ce vieux script peut contenir des vulnérabilités qui peuvent permettre de compromettre le site entier. L'opérateur de recherche Google site: peut être utilisé pour faire une recherche sur un seul domaine choisi, comme dans : site:www.example.com. Utiliser les moteurs de recherche de cette façon a permis un large éventail de techniques que vous pourrez trouver utiles et qui sont décrites dans la section Google Hacking de ce Guide.

Lisez-le pour affûter vos compétences de test via Google.


Les fichiers de sauvegarde ne sont probablement pas référencés par d'autres fichiers et ainsi ne doivent pas avoir été indexés par Google mais s'ils se trouvent dans des répertoires accessibles par votre navigateur,le moteur de recherche peut en avoir connaissance.

  • De plus, Google et Yahoo conservent des versions en cache des pages trouvées par leurs robots. Même si 1998results.asp a été supprimé du serveur cible, une version de ses résultats peut toujours être stockée par ces moteurs de recherche. Ces versions en cache peuvent contenir des références ou, des indices sur un autre contenu additionnel caché, qui existe toujours sur le serveur.
  • Du contenu, non référencé par une application cible, peut être lié à des sites web d'un tiers. Par exemple, une application qui gère les paiements en ligne pour le compte d'un site marchand peut contenir une diversité de fonctionnalités sur mesure qui ne doivent, normallement, être retrouvées qu'en suivant les liens des sites web de leurs clients.


Contournement du filtrage des noms de fichiers

Comme les filtres de liste noire sont basés sur des expressions régulières, on peut parfois profiter de fonctionnalités d'expansions opaques de noms de fichiers qui fonctionnent d'une façon que le éveloppeur n'imagine pas.

Le testeur peut parfois exploiter la différence dans la façon dont les noms de fichiers sont analysés par l'application, le serveur web, et le système d'exploitation sous-jacent et ses conventions de nommage de fichiers.


Exemple: Expansion des noms de fichiers sous Windows 8.3 "c:\program files" devient "C:\PROGRA~1" 

– Supprime les caractères incompatibles
– Convertit les espaces en caractère souligné bas "_"
- Prend les six premiers caractères du nom 
– Ajoute “~<chiffre>” pour différencier les fichiers dont les noms ont les mêmes six premiers caractères 
- Cette convention change après les 3 premières collisions de noms
– Tronque les extensions de fichiers à trois caractères
- Met tous les caractères en lettres majuscules


Test en Boite Grise

Réaliser un test en boite grise sur les vieux fichiers et les fichiers de sauvegarde nécessite l'examen des fichiers contenus dans les répertoires appartenant à l'ensemble des répertoires Web servis par le(s) serveur(s) internet de l'infrastructure de l'application. Théoriquement, l'examen devrait être réalisé manuellement pour être exhaustif.

Quoiqu'il en soit, comme la plupart du temps les copies ou les sauvegardes de fichiers utilisent les mêmes conventions de nommage, la recherche peut être effectuée facilement par script. Par exemple, les éditeurs nomment les copies de sauvegardes avec une extension reconnaissable et les humains tendent à les nommer en .old ou une autre extension similaire prédictible.

Uune bonne stratégie consiste à planifier une tâche de fond périodique à la recherche de fichiers avec des extensions qui les identifient comme de probables copies ou des sauvegardes de fichiers et à faire aussi des vérifications manuelles sur des périodes plus longues.

Outils

  • Les outils d'évaluation de vulnérabilités tendent à inclure des vérifications pour repérer les répertoires web avec des noms standard (tels que “admin”, “test”, “backup”, etc.), et à recenser tout répertoire web qui en autorise l'indexation. Si vous ne pouvez pas lister les répertoires, vous devriez essayer de vérifier les extensions probables des fichiers de sauvegarde. Regarder par exemple Nessus (http://www.nessus.org), Nikto2(http://www.cirt.net/code/nikto.shtml) ou les nouveaux dérivés Wikto (http://www.sensepost.com/research/wikto/), qui supportent les stratégies de base du Google Hacking.

Certains de ces outils sont compris en standard dans les distributions Linux.

  • Les utilitaires de développement Web ont généralement des outils pour identifier les liens cassés et les fichiers non référencés.

Remédiation

Pour garantir une stratégie de protection efficace, les tests doivent être complétés par une politique de sécurité qui interdit clairement des pratiques dangereuses telles que :

  • Editer des fichiers directement sur le serveur web ou sur le système de fichiers de l'application. C'est vraiment une mauvaise habitude car il est prévisible que les éditeurs génèrent des fichiers de backup non souhaités. C'est étonnant de voir comme c'est fréquent, même dans les grandes organisations. Si vous avez absolument besoin d'éditer un fichier sur un serveur de production, assurez-vous de n'y laisser que ce qui est explicitement nécessaire, et considérez que vous le faites à vos propres risques.
  • Vérifier soigneusement toute autre activité réalisée sur le système de fichiers exposé par le serveur Web, telles que les activités d'administration. Par exemple, si vous avez ponctuellement besoin de faire une "copie instantanée" de quelques répertoires (ce que vous devriez pas faire en production), vous pouvez être tenté au préalable d'en faire un fichier zippé.

Faites attention de ne pas laisser l'archive derrière vous.

  • Une politique de gestion de configuration devrait permettre de ne pas laisser traîner des fichiers obsolètes ou non référencés.
  • Les applications devraient être concues pour ne pas créer (ou s'appuyer sur) des fichiers stockés sous l'arborescence de répertoires mis à disposition par le serveur Web. Les fichiers de données, de traces, de configuration, etc..., devraient être stockés dans des répertoires inaccessibles au serveur Web, pour contrer les possibilités de divulgation d'information (pour ne pas mentionner les modifications de données si les permissions sur les répertoires Web autorisent l'écriture).
  • Les "copies instantanées" ou "snapshot" de système de fichiers ne devraient pas être accessibles par le Web si l'emplacement du document est sur un système de fichiers utilisant cette technologie.

Configurer votre serveur Web pour refuser l'accès à de tels répertoires, par exemple, sous Apache une directive <location>, comme indiqué ci-dessous, devrait être mise en place : 

<Location ~ ".snapshot">
    Order deny,allow
    Deny from all
</Location>
Retrieved from "https://wiki.owasp.org/index.php?title=4.3.4_Revue_des_fichiers_pour_recherche_d%27informations_sensibles_(OTG-CONFIG-004)&oldid=202082"