Enumérer les applications sur le serveur Web

Résumé

Une étape primordiale dans le test des vulnérabilités des applications web est de découvrir quelles applications particulières sont hébergées sur un serveur web. De nombreuses applications ont des vulnérabilités connues et des stratégies d'attaque connues qui peuvent être exploitées afin d'obtenir un contrôle à distance ou d'exploiter des données. De plus, de nombreuses applications sont souvent mal configurées ou non mises à jour, en raison de la perception qu'elles ne sont utilisées qu'"en interne" et qu'il n'y a donc aucune menace.

Avec la prolifération des serveurs web virtuels, la relation traditionnelle de type 1:1 entre une adresse IP et un serveur web perd une grande partie de sa signification originale. Il n'est pas rare d'avoir plusieurs sites ou applications dont les noms symboliques se résolvent à la même adresse IP. Ce scénario ne se limite pas aux environnements d'hébergement, mais s'applique également aux environnements d'entreprise ordinaires.

Les professionnels de la sécurité reçoivent parfois un ensemble d'adresses IP comme cible à tester. Il est discutable que ce scénario ressemble davantage à un engagement de type test de pénétration, mais dans tous les cas, on s'attend à ce qu'une telle mission teste toutes les applications web accessibles via cette cible. Le problème est que l'adresse IP donnée héberge un service HTTP sur le port 80, mais si un testeur devait y accéder en spécifiant l'adresse IP (ce qui est tout ce qu'il sait), il signale "Aucun serveur web configuré à cette adresse" ou un message similaire. Mais ce système pourrait "cacher" un certain nombre d'applications web, associées à des noms symboliques (DNS) non liés. De toute évidence, l'étendue de l'analyse est profondément affectée selon que le testeur teste toutes les applications ou seulement les applications dont il a connaissance.

Parfois, la spécification de la cible est plus riche. Le testeur peut recevoir une liste d'adresses IP et de leurs noms symboliques correspondants. Néanmoins, cette liste peut transmettre des informations partielles, c'est-à-dire qu'elle peut omettre certains noms symboliques et le client peut même ne pas en être conscient (cela est plus susceptible de se produire dans les grandes organisations).

D'autres problèmes affectant la portée de l'évaluation sont représentés par les applications web publiées à des URL non évidentes (par exemple, `https://www.example.com/some-strange-URL`), qui ne sont référencées nulle part ailleurs. Cela peut se produire soit par erreur (en raison de mauvaises configurations), soit intentionnellement (par exemple, des interfaces administratives non annoncées).

Pour résoudre ces problèmes, il est nécessaire d'effectuer une découverte d'application web.

Objectifs du test

• Enumérer les applications dans le périmètre qui existent sur un serveur web.

Comment tester

La découverte d'applications web est un processus qui vise à identifier les applications web sur une infrastructure donnée. Cette dernière est généralement spécifiée comme un ensemble d'adresses IP (peut-être un bloc réseau), mais peut consister en un ensemble de noms symboliques DNS ou un mélange des deux. Ces informations sont remises avant l'exécution d'une évaluation, qu'il s'agisse d'un test de pénétration de style classique ou d'une évaluation axée sur l'application. Dans les deux cas, à moins que les règles d'engagement ne spécifient le contraire (par exemple, tester uniquement l'application située à l'URL `https://www.example.com/`), l'évaluation doit s'efforcer d'être la plus complète possible, c'est-à-dire qu'elle doit identifier toutes les applications accessibles via la cible donnée. Les exemples suivants examinent quelques techniques qui peuvent être employées pour atteindre cet objectif.

Certaines des techniques suivantes s'appliquent aux serveurs web accessibles sur Internet, à savoir les services de recherche web DNS et IP inversé et l'utilisation de moteurs de recherche. Les exemples utilisent des adresses IP privées (telles que `192.168.1.100`), qui, sauf indication contraire, représentent des adresses IP génériques et ne sont utilisées qu'à des fins d'anonymat.

Il y a trois facteurs qui influencent le nombre d'applications liées à un nom DNS donné (ou une adresse IP) :

1. URL de base différente

   Le point d'entrée évident pour une application web est `www.example.com`, c'est-à-dire qu'avec cette notation abrégée, nous pensons à l'application web provenant de `https://www.example.com/` (la même chose s'applique pour HTTPS). Cependant, même si c'est la situation la plus courante, rien n'oblige l'application à démarrer à `/`.

   Par exemple, le même nom symbolique peut être associé à trois applications web telles que : `https://www.example.com/app1` `https://www.example.com/app2` `https://www.example.com/app3`

   Dans ce cas, l'URL `https://www.example.com/` ne serait pas associée à une page significative. Les trois applications resteraient **cachées** à moins que le testeur ne sache explicitement comment y accéder, c'est-à-dire que le testeur connaisse *app1*, *app2* ou *app3*. Il n'est généralement pas nécessaire de publier des applications web de cette manière, à moins que le propriétaire ne souhaite pas qu'elles soient accessibles de manière standard et qu'il soit prêt à informer les utilisateurs de leur emplacement exact. Cela ne signifie pas que ces applications sont secrètes, mais simplement que leur existence et leur emplacement ne sont pas explicitement annoncés.

2. Ports non standard

   Bien que les applications web résident généralement sur le port 80 (HTTP) et 443 (HTTPS), il n'y a rien de fixe ou d'obligatoire concernant ces numéros de port. En fait, les applications web peuvent être associées à des ports TCP arbitraires et peuvent être référencées en spécifiant le numéro de port comme suit : `http[s]://www.example.com:port/`. Par exemple, `https://www.example.com:20000/`.

3. Hôtes virtuels

   DNS permet à une seule adresse IP d'être associée à un ou plusieurs noms symboliques. Par exemple, l'adresse IP `192.168.1.100` peut être associée aux noms DNS `www.example.com`, `helpdesk.example.com`, `webmail.example.com`. Il n'est pas nécessaire que tous les noms appartiennent au même domaine DNS. Cette relation 1-à-N peut être reflétée pour servir un contenu différent en utilisant ce que l'on appelle des hôtes virtuels. Les informations spécifiant l'hôte virtuel auquel nous nous référons sont intégrées dans l'en-tête HTTP 1.1 Host.

   On ne soupçonnerait pas l'existence d'autres applications web en plus de l'évidente `www.example.com`, à moins de connaître `helpdesk.example.com` et `webmail.example.com`.

Approches pour résoudre le problème 1 - URL non standard

Il n'y a aucun moyen de s'assurer pleinement de l'existence d'applications web nommées de manière non standard. Etant non standard, il n'y a pas de critères fixes régissant la convention de nommage, cependant il existe un certain nombre de techniques que le testeur peut utiliser pour obtenir des informations supplémentaires.

Tout d'abord, si le serveur web est mal configuré et permet la navigation dans les répertoires, il peut être possible de repérer ces applications. Les scanners de vulnérabilités peuvent aider à cet égard.

Deuxièmement, ces applications peuvent être référencées par d'autres pages web et il est possible qu'elles aient été explorées et indexées par les moteurs de recherche web. Si les testeurs soupçonnent l'existence de telles applications **cachées** sur `www.example.com`, ils pourraient effectuer une recherche en utilisant l'opérateur *site* et en examinant le résultat d'une requête pour `site: www.example.com`. Parmi les URL renvoyées, il pourrait y en avoir une pointant vers une telle application non évidente.

Une autre option consiste à rechercher des URL qui pourraient être des candidats probables pour des applications non publiées. Par exemple, une interface web de messagerie pourrait être accessible à partir d'URL telles que `https://www.example.com/webmail`, `https://webmail.example.com/` ou `https://mail.example.com/`. Il en va de même pour les interfaces administratives, qui peuvent être publiées à des URL cachées (par exemple, une interface administrative Tomcat), et pourtant non référencées nulle part. Donc, faire un peu de recherche de type dictionnaire (ou "devinette intelligente") pourrait donner des résultats. Les scanners de vulnérabilités peuvent aider à cet égard.

Approches pour résoudre le problème 2 - Ports non standard

Il est facile de vérifier l'existence d'applications web sur des ports non standard. Un scanner de ports tel que Nmap est capable d'effectuer une reconnaissance de service au moyen de l'option `-sV`, et identifiera les services http[s] sur des ports arbitraires. Ce qui est nécessaire est une analyse complète de tout l'espace d'adressage des ports TCP 64k.

Par exemple, la commande suivante recherchera, avec une analyse de connexion TCP, tous les ports ouverts sur l'IP `192.168.1.100` et tentera de déterminer quels services y sont liés (seuls les commutateurs *essentiels* sont affichés – Nmap propose un large éventail d'options, dont la discussion est hors de portée) :

nmap –Pn –sT –sV –p0-65535 192.168.1.100

Il suffit d'examiner la sortie et de rechercher HTTP ou l'indication de services enveloppés par TLS (qui doivent être sondés pour confirmer qu'il s'agit de HTTPS). Par exemple, la sortie de la commande précédente pourrait ressembler à :

Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

A partir de cet exemple, on peut voir que :

• Il y a un serveur HTTP Apache fonctionnant sur le port 80.
• Il semble qu'il y ait un serveur HTTPS sur le port 443 (mais cela doit être confirmé, par exemple, en visitant `https://192.168.1.100` avec un navigateur).
• Sur le port 901, il y a une interface web Samba SWAT.
• Le service sur le port 1241 n'est pas HTTPS, mais le démon Nessus enveloppé par TLS.
• Port 3690 propose un service non spécifié (Nmap renvoie son *empreinte* - ici omise pour plus de clarté - avec des instructions pour la soumettre pour incorporation dans la base de données d'empreintes Nmap, à condition que vous sachiez quel service il représente).
• Un autre service non spécifié sur le port 8000 ; il pourrait s'agir de HTTP, car il n'est pas rare de trouver des serveurs HTTP sur ce port. Examinons ce problème :

$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...

Cela confirme qu'il s'agit en fait d'un serveur HTTP. Alternativement, les testeurs auraient pu visiter l'URL avec un navigateur web ; ou utiliser les commandes Perl GET ou HEAD, qui imitent les interactions HTTP telles que celle donnée ci-dessus (cependant, les requêtes HEAD peuvent ne pas être honorées par tous les serveurs).

• Apache Tomcat fonctionnant sur le port 8080.

La même tâche peut être effectuée par des scanners de vulnérabilités, mais vérifiez d'abord que le scanner de votre choix est capable d'identifier les services HTTP[S] fonctionnant sur des ports non standard. Par exemple, Nessus est capable de les identifier sur des ports arbitraires (à condition qu'il soit invité à analyser tous les ports), et fournira, par rapport à Nmap, un certain nombre de tests sur les vulnérabilités connues du serveur web, ainsi que sur la configuration TLS/SSL des services HTTPS. Comme indiqué précédemment, Nessus est également capable de repérer les applications ou interfaces web populaires qui pourraient autrement passer inaperçues (par exemple, une interface administrative Tomcat).

Approches pour résoudre le problème 3 - Hôtes virtuels

Il existe un certain nombre de techniques qui peuvent être utilisées pour identifier les noms DNS associés à une adresse IP donnée `x.y.z.t`.

Transferts de zone DNS

Cette technique a une utilité limitée de nos jours, étant donné que les transferts de zone ne sont largement pas honorés par les serveurs DNS. Cependant, il pourrait être utile de l'essayer. Tout d'abord, les testeurs doivent déterminer les serveurs de noms desservant `x.y.z.t`. Si un nom symbolique est connu pour `x.y.z.t` (que ce soit `www.example.com`), ses serveurs de noms peuvent être déterminés au moyen d'outils tels que `nslookup`, `host` ou `dig`, en demandant des enregistrements DNS NS.

Si aucun nom symbolique n'est connu pour `x.y.z.t`, mais que la définition de la cible contient au moins un nom symbolique, les testeurs peuvent essayer d'appliquer le même processus et d'interroger le serveur de noms de ce nom (en espérant que `x.y.z.t` sera également servi par ce serveur de noms). Par exemple, si la cible se compose de l'adresse IP `x.y.z.t` et du nom `mail.example.com`, déterminez les serveurs de noms pour le domaine `example.com`.

L'exemple suivant montre comment identifier les serveurs de noms pour `www.owasp.org` en utilisant la commande `host` :

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

Un transfert de zone peut maintenant être demandé aux serveurs de noms pour le domaine `example.com`. Si le testeur a de la chance, il peut recevoir une liste des entrées DNS pour ce domaine en réponse. Cela inclura l'évident `www.example.com` et les moins évidents `helpdesk.example.com` et `webmail.example.com` (et éventuellement d'autres). Vérifiez tous les noms renvoyés par le transfert de zone et considérez tous ceux qui sont liés à la cible évaluée.

Tentative de demander un transfert de zone pour `owasp.org` à partir de l'un de ses serveurs de noms :

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.

Requêtes DNS inverses

Ce processus est similaire au précédent, mais repose sur des enregistrements DNS inverses (PTR). Plutôt que de demander un transfert de zone, essayez de définir le type d'enregistrement sur PTR et d'émettre une requête sur l'adresse IP donnée. Si les testeurs ont de la chance, ils peuvent recevoir une entrée de nom DNS en réponse. Cette technique repose sur l'existence de mappages IP-vers-nom symbolique, ce qui n'est pas garanti.

Recherches DNS basées sur le Web

Ce type de recherche s'apparente au transfert de zone DNS, mais repose sur des services web qui permettent des recherches par nom sur DNS. L'un de ces services est le service Netcraft Search DNS. Le testeur peut demander une liste de noms appartenant à votre domaine de choix, tel que `example.com`. Il vérifiera ensuite si les noms qu'il a obtenus sont pertinents pour la cible qu'il examine.

Services IP inversés

Les services IP inversés sont similaires aux requêtes DNS inverses, à la différence que les testeurs interrogent une application web au lieu d'un serveur de noms. Il existe un certain nombre de ces services disponibles. Etant donné qu'ils ont tendance à renvoyer des résultats partiels (et souvent différents), il est préférable d'utiliser plusieurs services pour obtenir une analyse plus complète.

• MxToolbox Reverse IP
• DNSstuff (plusieurs services disponibles)
• Net Square (plusieurs requêtes sur les domaines et les adresses IP, nécessite une installation)

Googler

Suite à la collecte d'informations à partir des techniques précédentes, les testeurs peuvent s'appuyer sur les moteurs de recherche pour éventuellement affiner et incrémenter leur analyse. Cela peut donner la preuve de noms symboliques supplémentaires appartenant à la cible, ou d'applications accessibles via des URL non évidentes.

Par exemple, en considérant l'exemple précédent concernant `www.owasp.org`, le testeur pourrait interroger Google et d'autres moteurs de recherche à la recherche d'informations (donc, de noms DNS) liées aux domaines nouvellement découverts de `webgoat.org`, `webscarab.com` et `webscarab.net`.

Les techniques de Googling sont expliquées dans Tests : Araignées, robots et crawlers.

Certificats numériques

Si le serveur accepte les connexions via HTTPS, alors le nom commun (CN) et le nom alternatif du sujet (SAN) sur le certificat peuvent contenir un ou plusieurs noms d'hôtes. Cependant, si le serveur web n'a pas de certificat de confiance, ou si des caractères génériques sont utilisés, cela peut ne renvoyer aucune information valide.

Le CN et le SAN peuvent être obtenus en inspectant manuellement le certificat, ou via d'autres outils tels que OpenSSL :

openssl s_client -connect 93.184.216.34:443 /dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org
DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net

Outils

• Outils de recherche DNS tels que nslookup, dig et similaires.
• Moteurs de recherche (Google, Bing et autres moteurs de recherche majeurs).
• Service de recherche web spécialisé lié à DNS : voir le texte.
• Nmap
• Nessus Vulnerability Scanner
• Nikto