Empreinte du framework d'application Web

Résumé

Il ne serait pas exagéré de dire que presque toutes les idées imaginables pour une application web ont déjà été mises en développement. Avec le grand nombre de projets logiciels libres et open-source qui sont activement développés et déployés dans le monde entier, il est très probable qu'un test de sécurité d'application rencontre une cible qui est entièrement ou partiellement dépendante de ces applications ou frameworks bien connus (par exemple, WordPress, phpBB, Mediawiki, etc.). Connaître les composants de l'application web qui sont testés aide considérablement le processus de test et réduira également considérablement l'effort requis pendant le test. Ces applications web bien connues ont des en-têtes HTML, des cookies et des structures de répertoires spécifiques qui peuvent être énumérés pour identifier l'application. La plupart des frameworks web ont plusieurs marqueurs à ces emplacements, ce qui peut aider un attaquant ou un testeur à les reconnaître. C'est fondamentalement ce que font tous les outils automatiques, ils recherchent un marqueur à partir d'un emplacement prédéfini, puis le comparent à la base de données des signatures connues. Pour une meilleure précision, plusieurs marqueurs sont généralement utilisés.

Objectifs du test

• Identifier l'empreinte des composants utilisés par les applications web.

Comment tester

Tests en boîte noire

Il existe plusieurs emplacements courants à considérer afin d'identifier les frameworks ou les composants :

• En-têtes HTTP
• Cookies
• Code source HTML
• Fichiers et dossiers spécifiques
• Extensions de fichiers
• Messages d'erreur

En-têtes HTTP

La forme la plus élémentaire d'identification d'un framework web consiste à examiner le champ `X-Powered-By` dans l'en-tête de réponse HTTP. De nombreux outils peuvent être utilisés pour identifier l'empreinte d'une cible, le plus simple est netcat.

Considérez la requête-réponse HTTP suivante :

$ nc 127.0.0.1 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.0.14
[...]
X-Powered-By: Mono

A partir du champ `X-Powered-By`, nous comprenons que le framework d'application web est susceptible d'être `Mono`. Cependant, bien que cette approche soit simple et rapide, cette méthodologie ne fonctionne pas dans tous les cas. Il est possible de désactiver facilement l'en-tête `X-Powered-By` par une configuration appropriée. Il existe également plusieurs techniques qui permettent à un site d'obscurcir les en-têtes HTTP (voir un exemple dans la section Remédiation). Dans l'exemple ci-dessus, le testeur pourrait soit manquer l'en-tête `X-Powered-By`, soit obtenir une réponse comme la suivante :

HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
X-Powered-By: Blood, sweat and tears

Parfois, il y a plus d'en-têtes HTTP qui pointent vers un certain framework. Dans l'exemple suivant, selon les informations de la requête HTTP, on peut voir que l'en-tête `X-Powered-By` contient la version de PHP. Cependant, l'en-tête `X-Generator` indique que le framework utilisé est en fait `Swiftlet`, ce qui aide un testeur de pénétration à étendre ses vecteurs d'attaque. Lors de l'identification de l'empreinte, inspectez attentivement chaque en-tête HTTP pour de telles fuites.

HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.16-1~dotdeb.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Generator: Swiftlet

Cookies

Un autre moyen similaire et quelque peu plus fiable de déterminer le framework web actuel consiste à utiliser des cookies spécifiques au framework.

Considérez la requête HTTP suivante :

Figure 4.1.8-7 : Requête HTTP Cakephp

Le cookie `CAKEPHP` a été automatiquement défini, ce qui donne des informations sur le framework utilisé. Une liste des noms de cookies courants est présentée dans la section Cookies. Des limitations existent toujours en se fiant à ce mécanisme d'identification - il est possible de changer le nom des cookies. Par exemple, pour le framework `CakePHP` sélectionné, cela pourrait être fait via la configuration suivante (extrait de `core.php`) :

/**
* The name of CakePHP's session cookie.
*
* Note the guidelines for Session names states: "The session name references
* the session id in cookies and URLs. It should contain only alphanumeric
* characters."
* @link https://php.net/session_name
*/
Configure::write('Session.cookie', 'CAKEPHP');

Cependant, ces modifications sont moins susceptibles d'être apportées que les modifications de l'en-tête `X-Powered-By`, ce qui rend cette approche d'identification plus fiable.

Code Source HTML

Cette technique est basée sur la recherche de certains modèles dans le code source de la page HTML. Souvent, on peut trouver beaucoup d'informations qui aident un testeur à reconnaître un composant spécifique. L'un des marqueurs courants est les commentaires HTML qui mènent directement à la divulgation du framework. Le plus souvent, certains chemins spécifiques au framework peuvent être trouvés, c'est-à-dire des liens vers des dossiers CSS ou JS spécifiques au framework. Enfin, des variables de script spécifiques peuvent également pointer vers un certain framework.

A partir de la capture d'écran ci-dessous, on peut facilement déterminer le framework utilisé et sa version grâce aux marqueurs mentionnés. Le commentaire, les chemins spécifiques et les variables de script peuvent tous aider un attaquant à déterminer rapidement une instance du framework ZK.

Figure 4.1.8-2 : Echantillon de code source HTML du framework ZK

Fréquemment, ces informations sont positionnées dans la section `` des réponses HTTP, dans les balises ``, ou à la fin de la page. Néanmoins, les réponses entières doivent être analysées car elles peuvent être utiles à d'autres fins telles que l'inspection d'autres commentaires utiles et champs cachés. Parfois, les développeurs web peuvent ne pas masquer suffisamment les informations sur les frameworks ou les composants utilisés. Il est toujours possible de tomber sur quelque chose comme ceci en bas de la page :

Figure 4.1.8-3 : Bas de page Banshee

Fichiers et dossiers spécifiques

Il existe une autre approche qui aide grandement un attaquant ou un testeur à identifier les applications ou les composants avec une grande précision. Chaque composant d'application web a sa structure de fichiers et de dossiers spécifique sur le serveur. Il a été noté que l'on peut voir le chemin spécifique à partir du code source de la page HTML, mais parfois ils ne sont pas explicitement présentés là et peuvent encore résider sur le serveur.

Afin de les découvrir, une technique connue sous le nom de navigation forcée ou "dirbusting" est utilisée. Le dirbusting consiste à forcer brutalement une cible avec des noms de dossiers et de fichiers connus et à surveiller les réponses HTTP pour énumérer le contenu du serveur. Ces informations peuvent être utilisées à la fois pour trouver des fichiers par défaut et les attaquer, et pour identifier l'empreinte de l'application web. Le dirbusting peut être effectué de plusieurs manières, l'exemple ci-dessous montre une attaque de dirbusting réussie contre une cible alimentée par WordPress à l'aide d'une liste définie et de la fonctionnalité d'intrus de Burp Suite.

Figure 4.1.8-4 : Dirbusting avec Burp

Nous pouvons voir que pour certains dossiers spécifiques à WordPress (par exemple, `/wp-includes/`, `/wp-admin/` et `/wp-content/`), les réponses HTTP sont 403 (Interdit), 302 (Trouvé, redirection vers `wp-login.php`) et 200 (OK) respectivement. C'est un bon indicateur que la cible est alimentée par WordPress. De la même manière, il est possible de dirbuster différents dossiers de plugins d'application et leurs versions. Dans la capture d'écran ci-dessous, on peut voir un fichier CHANGELOG typique d'un plugin Drupal, qui fournit des informations sur l'application utilisée et divulgue une version vulnérable du plugin.

Figure 4.1.8-5 : Divulgation de Drupal Botcha

Astuce : avant de commencer le dirbusting, vérifiez d'abord le fichier `robots.txt`. Parfois, des dossiers spécifiques à l'application et d'autres informations sensibles peuvent s'y trouver. Un exemple d'un tel fichier `robots.txt` est présenté sur une capture d'écran ci-dessous.

Figure 4.1.8-6 : Divulgation d'informations Robots

Les fichiers et dossiers spécifiques sont différents pour chaque application spécifique. Si l'application ou le composant identifié est Open Source, il peut être utile de mettre en place une installation temporaire pendant les tests de pénétration afin de mieux comprendre quelle infrastructure ou fonctionnalité est présentée, et quels fichiers pourraient être laissés sur le serveur. Cependant, plusieurs listes de fichiers utiles existent déjà ; un exemple notable est les listes de mots FuzzDB de fichiers/dossiers prévisibles.

Extensions de fichiers

Les URL peuvent inclure des extensions de fichiers qui peuvent également aider à identifier la plateforme ou la technologie web.

Par exemple, le wiki OWASP utilisait PHP :

https://wiki.owasp.org/index.php?title=Fingerprint_Web_Application_Framework&action=edit§ion=4

Voici quelques extensions de fichiers web courantes et les technologies associées :

• `.php` -- PHP
• `.aspx` -- Microsoft ASP.NET
• `.jsp` -- Java Server Pages

Messages d'erreur

Comme on peut le voir dans la capture d'écran suivante, le chemin du système de fichiers répertorié pointe vers l'utilisation de WordPress (`wp-content`). De plus, les testeurs doivent être conscients que WordPress est basé sur PHP (`functions.php`).

Figure 4.1.8-7 : Erreur d'analyse WordPress

Identifiants courants

Cookies

Code Source HTML

Marqueurs généraux

• %framework_name%
• powered by
• built upon
• running

Marqueurs spécifiques

Remédiation

Bien que des efforts puissent être faits pour utiliser des noms de cookies différents (en modifiant les configurations), en masquant ou en modifiant les chemins de fichiers/répertoires (par réécriture ou modifications du code source), en supprimant les en-têtes connus, etc., ces efforts se résument à la "sécurité par l'obscurité". Les propriétaires/administrateurs de systèmes doivent reconnaître que de tels efforts ne font que ralentir les adversaires les plus rudimentaires. Le temps et les efforts pourraient être mieux dépensés à sensibiliser les parties prenantes et à maintenir les solutions.

Outils

Une liste d'outils généraux et bien connus est présentée ci-dessous. Il existe également de nombreux autres utilitaires, ainsi que des outils d'identification d'empreinte basés sur le framework.

WhatWeb

Site web : https://github.com/urbanadventurer/WhatWeb

WhatWeb est l'un des meilleurs outils d'identification d'empreinte open source actuellement disponibles sur le marché et est inclus dans la construction par défaut de Kali Linux. Langue : Ruby Les correspondances pour l'identification d'empreinte sont effectuées avec :

• Chaînes de texte (sensibles à la casse)
• Expressions régulières
• Requêtes Google Hack Database (ensemble limité de mots-clés)
• Hachages MD5
• Reconnaissance d'URL
• Modèles de balises HTML
• Code ruby personnalisé pour les opérations passives et agressives

Un exemple de sortie est présenté sur une capture d'écran ci-dessous :

Figure 4.1.8-8 : Exemple de sortie Whatweb

Wappalyzer

Site web : https://www.wappalyzer.com/

Wappalyzer est disponible dans plusieurs modèles d'utilisation, dont le plus populaire est probablement les extensions Firefox/Chrome. Ils fonctionnent en grande partie sur la correspondance d'expressions régulières et n'ont besoin de rien d'autre que la page en cours de chargement dans un navigateur. Il fonctionne complètement au niveau du navigateur et donne des résultats sous forme d'icônes. Bien qu'il ait parfois des faux positifs, il est très pratique d'avoir une idée des technologies utilisées pour construire un site cible immédiatement après avoir navigué sur une page.

Un exemple de sortie d'un plug-in est présenté sur une capture d'écran ci-dessous.

Figure 4.1.8-9 : Sortie Wappalyzer pour le site web OWASP

Références

Livres blancs

• Saumil Shah : "An Introduction to HTTP fingerprinting"
• Anant Shrivastava : "Web Application Finger Printing"