Résumé

L'identification de l'empreinte du serveur web est la tâche consistant à identifier le type et la version du serveur web sur lequel une cible s'exécute. Bien que l'identification de l'empreinte du serveur web soit souvent encapsulée dans des outils de test automatisés, il est important pour les chercheurs de comprendre les principes fondamentaux de la façon dont ces outils tentent d'identifier les logiciels, et pourquoi cela est utile.

Découvrir avec précision le type de serveur web sur lequel une application s'exécute peut permettre aux testeurs de sécurité de déterminer si l'application est vulnérable aux attaques. En particulier, les serveurs exécutant des versions plus anciennes de logiciels sans correctifs de sécurité à jour peuvent être sensibles à des exploits spécifiques à une version connus.

Objectifs du test

• Déterminer la version et le type d'un serveur web en cours d'exécution pour permettre une découverte plus approfondie des vulnérabilités connues.

Comment tester

Les techniques utilisées pour l'identification de l'empreinte du serveur web incluent la capture de bannière, l'obtention de réponses à des requêtes malformées et l'utilisation d'outils automatisés pour effectuer des analyses plus robustes qui utilisent une combinaison de tactiques. La prémisse fondamentale sur laquelle toutes ces techniques fonctionnent est la même. Elles s'efforcent toutes d'obtenir une réponse du serveur web qui peut ensuite être comparée à une base de données de réponses et de comportements connus, et ainsi correspondre à un type de serveur connu.

Capture de bannière

Une capture de bannière est effectuée en envoyant une requête HTTP au serveur web et en examinant son en-tête de réponse. Cela peut être accompli en utilisant une variété d'outils, y compris `telnet` pour les requêtes HTTP, ou `openssl` pour les requêtes via TLS/SSL.

Par exemple, voici la réponse à une requête envoyée à un serveur Apache.

HTTP/1.1 200 OK
Date: Thu, 05 Sep 2019 17:42:39 GMT
Server: Apache/2.4.41 (Unix)
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
ETag: "75-591d1d21b6167"
Accept-Ranges: bytes
Content-Length: 117
Connection: close
Content-Type: text/html
...

Voici une autre réponse, cette fois envoyée par nginx.

HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 05 Sep 2019 17:50:24 GMT
Content-Type: text/html
Content-Length: 117
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
Connection: close
ETag: "5d71489a-75"
Accept-Ranges: bytes
...

Voici à quoi ressemble une réponse envoyée par lighttpd.

HTTP/1.0 200 OK
Content-Type: text/html
Accept-Ranges: bytes
ETag: "4192788355"
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
Content-Length: 117
Connection: close
Date: Thu, 05 Sep 2019 17:57:57 GMT
Server: lighttpd/1.4.54

Dans ces exemples, le type et la version du serveur sont clairement exposés. Cependant, les applications soucieuses de la sécurité peuvent masquer leurs informations de serveur en modifiant l'en-tête. Par exemple, voici un extrait de la réponse à une requête pour un site avec un en-tête modifié :

HTTP/1.1 200 OK
Server: Website.com
Date: Thu, 05 Sep 2019 17:57:06 GMT
Content-Type: text/html; charset=utf-8
Status: 200 OK
...

Dans les cas où les informations du serveur sont masquées, les testeurs peuvent deviner le type de serveur en fonction de l'ordre des champs d'en-tête. Notez que dans l'exemple Apache ci-dessus, les champs suivent cet ordre :

• Date
• Server
• Last-Modified
• ETag
• Accept-Ranges
• Content-Length
• Connection
• Content-Type

Cependant, dans les exemples nginx et serveur masqué, les champs en commun suivent cet ordre :

• Server
• Date
• Content-Type

Les testeurs peuvent utiliser ces informations pour deviner que le serveur masqué est nginx. Cependant, étant donné qu'un certain nombre de serveurs web différents peuvent partager le même ordre de champs et que les champs peuvent être modifiés ou supprimés, cette méthode n'est pas définitive.

Envoi de requêtes malformées

Les serveurs web peuvent être identifiés en examinant leurs réponses d'erreur et, dans les cas où ils n'ont pas été personnalisés, leurs pages d'erreur par défaut. Une façon de contraindre un serveur à les présenter est d'envoyer des requêtes intentionnellement incorrectes ou malformées.

Par exemple, voici la réponse à une requête pour la méthode inexistante `SANTA CLAUS` d'un serveur Apache.

GET / SANTA CLAUS/1.1


HTTP/1.1 400 Bad Request
Date: Fri, 06 Sep 2019 19:21:01 GMT
Server: Apache/2.4.41 (Unix)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1





Bad Request
Your browser sent a request that this server could not understand.

Voici la réponse à la même requête de nginx.

GET / SANTA CLAUS/1.1





404 Not Found
nginx/1.17.3

Voici la réponse à la même requête de lighttpd.

GET / SANTA CLAUS/1.1


HTTP/1.0 400 Bad Request
Content-Type: text/html
Content-Length: 345
Connection: close
Date: Sun, 08 Sep 2019 21:56:17 GMT
Server: lighttpd/1.4.54




 
  
 
 
  
400 Bad Request
 

Comme les pages d'erreur par défaut offrent de nombreux facteurs de différenciation entre les types de serveurs web, leur examen peut être une méthode efficace pour l'identification, même lorsque les champs d'en-tête du serveur sont masqués.

Utilisation d'outils de scan automatisés

Comme indiqué précédemment, l'identification de l'empreinte du serveur web est souvent incluse comme fonctionnalité des outils de scan automatisés. Ces outils sont capables d'effectuer des requêtes similaires à celles démontrées ci-dessus, ainsi que d'envoyer d'autres sondes plus spécifiques au serveur. Les outils automatisés peuvent comparer les réponses des serveurs web beaucoup plus rapidement que les tests manuels, et utiliser de grandes bases de données de réponses connues pour tenter d'identifier le serveur. Pour ces raisons, les outils automatisés sont plus susceptibles de produire des résultats précis.

Voici quelques outils de scan couramment utilisés qui incluent la fonctionnalité d'identification de l'empreinte du serveur web.

• Netcraft, un outil en ligne qui analyse les sites pour obtenir des informations, y compris les détails du serveur web.
• Nikto, un outil de scan en ligne de commande Open Source.
• Nmap, un outil en ligne de commande Open Source qui a également une interface graphique, Zenmap.

Remédiation

Bien que les informations de serveur exposées ne soient pas nécessairement en elles-mêmes une vulnérabilité, ce sont des informations qui peuvent aider les attaquants à exploiter d'autres vulnérabilités qui peuvent exister. Les informations de serveur exposées peuvent également conduire les attaquants à trouver des vulnérabilités spécifiques à la version du serveur qui peuvent être utilisées pour exploiter des serveurs non corrigés. Pour cette raison, il est recommandé de prendre certaines précautions. Ces actions incluent :

• Masquer les informations du serveur web dans les en-têtes, comme avec le module mod_headers d'Apache.
• Utiliser un serveur proxy inverse renforcé pour créer une couche de sécurité supplémentaire entre le serveur web et Internet.
• S'assurer que les serveurs web sont maintenus à jour avec les derniers logiciels et correctifs de sécurité.