Difference between revisions of "4.3.4 Revue des fichiers obsolètes, de sauvegarde, non référencés pour recherche d'informations sensibles (OTG-CONFIG-004)"

Revision as of 11:33, 19 October 2015

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 métier 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 de conception et de configuration qui permettent à toutes sortes de fichiers relatifs à l’application, comme des fichiers de données, de configuration, ou de traces, d'être stockés dans des répertoires du système de fichiers accessibles par le serveur Web.

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 qui peuvent faciliter une attaque ciblée de l'application ; par exemple, des fichiers d'inclusion (cf "include") qui contiennent les justificatifs d’accès aux bases de données, les fichiers de configuration qui contiennent des références à d'autres contenus cachés, ou des chemins d’accès absolus, 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 référencée dans le contenu publié 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» (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 du site Web et même ceux extérieurs au site. 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 d'inclusion, etc... Par exemple, si vous avez oublié un fichier nommé myservlets.jar.old qui contient une copie de sauvegarde des classes implémentant votre servlet, 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 adaptées aux différentes langues de cette chaîne. Comme l’extension de fichier reste inchangée, ce n’est pas un cas où le fichier exécutable sera 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 que, lorsqu'ils sont appelés, ils déclenchent des erreurs d’application qui, si le message d'erreur s'affiche, donnent de précieuses informations à l’attaquant.

• Les fichiers journaux peuvent contenir des informations sensibles de pratiques des utilisateurs de l’application, par exemple des 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 des conventions de nommage du contenu publié

Enumérer 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 d’application («spidering»). La plupart des applications utilisent une convention de nommage repérable, et organisent les ressources en pages et répertoires en utilisant des mots décrivant leurs fonctions. A partir de la convention de nommage utilisée 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 sur d'autres fonctionnalités et d'autres pages.

Par exemple :

Les commentaires des programmeurs et, les sections du code source mises en commentaire 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 affichées 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 formulaires FORM qui ont été cachés 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, sur 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 soumettre une liste de noms de fichiers usuels, à un moteur de requêtes, pour tenter de deviner quels sont les fichiers et les répertoires présents sur le serveur. Le script suivant, qui utilise une commande "netcat", lira une liste de mots à partir de l'entrée 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 

En fonction de 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 (en supposant que le serveur ne renvoie pas une page d'erreur personnalisée “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 méritant un examen plus approfondi.

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'énumération. Des attaques par conjecture, plus avancées et plus 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 utiliser une liste de mots basiques complétés par chacune de ces extensions ou, utiliser une liste des extensions usuelles plus longue si les ressources le permettent).

• Pour chaque fichier identifié par d'autres techniques d'énumération, créer une liste de mots personnalisés dérivés du nom de fichier.

Préparer 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 le source code quand on y accède, ils peuvent néanmoins divulguer des informations sensibles s'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, qui ont été référencées, peuvent encore 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. Cet ancien script peut contenir des vulnérabilités qui peuvent être utilisées pour 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 des pages HTML générées 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 accès par 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 plusieurs fonctionnalités personnalisées qui ne doivent, normalement, être accessibles 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 des noms de fichiers que le développeur n'a pas imaginé.

Le testeur peut parfois exploiter les différences de conventions de nommage et d'analyse des noms de fichiers utilisées par l'application, le serveur Web, et le système d'exploitation sous-jacent.

Exemple: Sous Windows, le nom de fichier long "c:\program files" devient "C:\PROGRA~1" en format court(format 8.3), après les transformations suivantes :

– 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 fichiers obsolètes ou 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'application. Théoriquement, l'examen devrait être réalisé manuellement pour être exhaustif.

Mais la plupart du temps, les copies ou les sauvegardes de fichiers sont créés avec les mêmes conventions de nommage, aussi la recherche peut être facilement effectuée avec un script. Par exemple, les éditeurs nomment les copies de sauvegardes avec une extension reconnaissable et les humains ont tendance à les nommer avec une extension .old ou une autre extension similaire prédictible.

Une 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 aussi à faire des vérifications manuelles sur des périodes prolongées.

Outils

• Les outils d'évaluation de vulnérabilités ont tendance à 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 son nouveau dérivé Wikto (http://www.sensepost.com/research/wikto/), qui intègre aussi les stratégies de base du Google Hacking.

• Robots d'exploration du Web "spider tools":
  • wget (http://www.gnu.org/software/wget/, http://www.interlog.com/~tcharron/wgetwin.html);
  • Sam Spade (http://www.samspade.org);
  • Le proxy Spike comprend une fonction d'exploration de site Web (http://www.immunitysec.com/spikeproxy.html);
  • Xenu (http://home.snafu.de/tilman/xenulink.html);
  • curl (http://curl.haxx.se).

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

• Les utilitaires de développement Web intègrent habituellement des outils pour identifier les liens cassés et les fichiers non référencés.

Mesures correctives

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

• Editer des fichiers directement sur le système de fichiers du serveur Web et du serveur d'applications. C'est vraiment une mauvaise habitude car on sait que les éditeurs génèrent des fichiers de sauvegarde non désirés. Il 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 appropriée devrait aider à 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 exposés par le serveur Web. Les fichiers de données, de journalisation, 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" du 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>