Une étape primordiale dans les tests de vulnérabilités des applications web est de savoir quelles applications particulières sont hébergés sur un serveur web. De nombreuses applications sont vulnérables à des stratégies d'attaque connues qui peuvent être exploitées dans le but de prendre le contrôle à distance ou d'exploiter les données. En outre, de nombreuses applications sont souvent mal configurées ou non mises à jour, en raison de la croyance en le fait qu'une application qui n'est utilisée «qu'en interne» n'est pas menacée.

Avec la prolifération des serveurs web virtuels, le traditionnel 1:1-type de relation entre une adresse IP et un serveur Web perd beaucoup de sa signification originelle. Il n'est pas rare d'avoir plusieurs sites web / applications dont les noms symboliques pointent vers la même adresse IP (ce scénario ne se limite pas aux environnements d'hébergement, mais s'applique également aux environnements d'entreprises ordinaires).

En tant que professionnel de la sécurité, il vous est parfois donné un ensemble d'adresses IP (ou éventuellement une seule) comme à tester. On peut considérer que ce scénario est plus proche d'un pentest, mais en tout cas, on s'attend à ce qu'en de telle circonstances vous testiez toutes les applications Web accessibles par le biais de cette cible (et peut-être d'autres choses). Le problème est que l'adresse IP donnée héberge un service HTTP sur le port 80, mais si vous y accédez en spécifiant l'adresse IP (ce qui est tout ce que vous savez), il signale «Aucun serveur web configuré à cette adresse“ ou un message similaire. Mais ce système peut “cacher” un certain nombre d'applications web, sans lien associé à un nom symbolique (DNS). De toute évidence, votre analyse sera profondément affectée par le fait de tester des applications, dont vous n'avez pas idée du nombre parce que, même si vous en détectez, vous n'aurez pas la certitude de les avoir toutes détecté. Parfois, la spécification de cible est plus riche - peut-être vous seront remis une liste des adresses IP et des noms symboliques correspondants. Néanmoins, cette liste pourrait véhiculer une information partielle, c'est à dire qu'elle peut omettre certains noms symboliques ( le client peut même ne pas être au courant de cela, ce qui est plus susceptible de se produire dans les grandes organisations)!

D'autres questions touchant la portée de l'évaluation sont représentés par des applications web publiées sous des formes d'URL non standard (par exemple, http://www.example.com/some-strange-URL), qui ne sont pas référencées ailleurs. Cela peut se produire soit par erreur (en raison de défauts de configuration), ou intentionnelle (par exemple, cache des interfaces d'administration).

Pour répondre à ces questions, il est nécessaire d'effectuer une découverte d'applications Web.

La découverte d'applications Web est un processus visant à identifier les applications Web sur une infrastructure donnée. Cette dernière est généralement défini comme un ensemble d'adresses IP (peut-être un bloc net), mais peut consister en un ensemble de noms DNS symboliques ou un mélange des deux. Cette information est donnée avant l'exécution d'une évaluation, que ce soit 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 du cahier de charges indiquent le contraire (par exemple, “ne tester que l'application situé à l'URL http://www.example.com/”), l'évaluation doit s'efforcer d'être la plus complète dans sa portée, l'auditeur doit identifier toutes les applications accessibles via la cible donnée. Dans les exemples suivants, nous allons examiner quelques techniques qui peuvent être employées pour atteindre cet objectif.

Remarque: Certaines des techniques suivantes s'appliquent sur les données publiques des serveurs web, à savoir le nom DNS, le reverse IP des services de recherche sur le Web et l'utilisation de moteurs de recherche. Dans les exemples qui suivent nous utiliserons des adresses IP privées (telles que 192.168.1.100), qui, à moins d'indication contraire, représentent des adresses IP génériques et sont utilisés uniquement à des fins d'anonymat.

Il y a trois facteurs qui influent sur combien de demandes sont liées à un nom DNS donné (ou une adresse IP):

1. URL de base différentes

Le point d'entrée évident pour une application web est [www.example.com,] c'est avec cette notation abrégée que nous adressons généralement l'application Web d'origine à http://www.example.com/ (la même chose s'applique pour https). Cependant, même si cela est le cas le plus fréquent, il n'est pas obligatoire que l'application soit sur «/». Par exemple, le même nom symbolique peut être associé à trois applications Web telles que: http://www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3 Dans ce cas, l'URL http://www.example.com/ ne serait pas associé à une page significative, et les trois applications serait «cachées», à moins que nous sachions explicitement comment les atteindre, c'est à dire,que nous connaissions url1, url2 ou url3. Il n'est généralement pas nécessaire de publier des applications Web de cette façon, à moins que vous ne vouliez pas qu'elles soient accessibles de façon standard, et que vous vouliez informer les utilisateurs sur leur emplacement exact. Cela ne signifie pas que ces applications sont secrètes, c'est juste que leur existence et leur emplacement n'est pas explicitement annoncé.

2. Des ports non standards

Alors que les applications Web écoutent habituellement sur le port 80 (http) et 443 (https), il n'y a rien de figé dans ces numéros de port. En fait, les applications web peuvent être associés à des ports TCP arbitraires, et peuvent être atteintes en spécifiant le numéro de port comme suit: http[s]:www.example.com:port/. Par exemple, http://www.example.com:20000/. 3. Les hôtes virtuels Un nom DNS permet d'associer une adresse IP unique à un ou plusieurs noms symboliques. Par exemple, l'adresse IP 192.168.1.100 pourrait être associée à des noms DNS [www.example.com,] helpdesk.example.com, webmail.example.com (en fait, il n'est pas nécessaire que tous les noms appartiennent au même domaine DNS) . Cette relation 1-à-N peut être utilisée pour servir un contenu différent en utilisant ce qu'on appelle des hôtes virtuels. Les informations spécifiant l'hôte virtuel, auquel nous faisons référence, est intégré dans le protocole HTTP 1.1 Host: header ¹⁾. Nous ne pouvons deviner l'existence d'autres applications Web, en plus de la [www.example.com] évident, à moins que nous ne connaissons helpdesk.example.com et webmail.example.com. ## Approches numéro 1 - URL non standard ## Il n'existe aucun moyen pour bien s'assurer de l'existence d'applications web nommées de manière non-standard. Il n'existe pas de critère fixe qui régisse la convention de nommage, mais il y a un certain nombre de techniques que le testeur peut utiliser pour avoir un aperçu supplémentaire. Tout d'abord, si le serveur web est mal configuré et permet l'exploration des 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, à ce titre, il y a une chance qu'elles aient déjà été indexées par les moteurs de recherche. Si l'on soupçonne l'existence de ces applications «cachées» sur [www.example.com] nous pourrions faire un peu de googling en utilisant l'opérateur « :site » et en examinant le résultat d'une requête (ex: “site: [www.example.com”).] Parmi les adresses URL renvoyées il pourrait y en avoir une pointant sur une telle application. Une autre option est de sonder les URLs qui pourraient être des candidates probables pour les applications non publiées. Par exemple, une interface web mail peut être accessible à partir d'URL tels que https://www.example.com/webmail, https://webmail.example.com/ ou https://mail.example.com/. La même chose vaut pour les interfaces administratives, qui peuvent être publiés aux adresses cachées (par exemple, une interface d'administration Tomcat), et pourtant pas référencé. Donc, faire un peu de recherche de style dictionnaire(ou «deviner intelligent») pourrait donner des résultats. Les scanners de vulnérabilités peut aider à cet égard. ## Approches numéro 2 - ports non standards ## Il est facile de vérifier l'existence d'applications web sur des ports non standards. Un scanner de ports comme nmap [2] est capable d'effectuer la reconnaissance de services au moyen de l'option -sV, et permettra d'identifier des services http [s] sur des ports arbitraires. Ce qu'il faut c'est une analyse complète des 64k ports TCP. Par exemple, la commande suivante va chercher, avec un scan TCP connect, tous les ports ouverts sur l'adresse IP 192.168.1.100 et va essayer de déterminer quels services actifs (seuls les commutateurs essentiels sont représentés - nmap dispose d'un plus large éventail d'options): <code>nmap –PN –sT –sV –p0-65535 192.168.1.100 </code>Il suffit d'examiner la sortie et chercher les services http ou SSL (qui devraient être sondé pour confirmer qu'ils sont https). Par exemple, la sortie de la commande précédente pourrait ressembler à ceci: <code>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 ²⁾ 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 </code> De cet exemple, nous voyons que: Il y a un serveur http Apache sur le port 80. Il semble qu'il y ait un serveur https sur le port 443 (mais cela reste à être confirmée, par exemple, en visitant https://192.168.1.100 avec un navigateur). Sur le port 901 il y a un interface Web d'un Samba SWAT.Le service sur le port 1241 n'est pas https, mais le démon SSL de Nessus. Le port 3690 dispose d'un service non spécifié (nmap donnera son empreinte - ici omise pour plus de clarté - conjointement avec les instructions permettant de soumettre son incorporation dans la base de données d'empreintes digitales nmap, si vous savez quel service il représente). Un autre service non spécifié écoute sur le port 8000, ce qui pourrait éventuellement être http, car il n'est pas rare de trouver des serveurs HTTP sur ce port. SI on jette un coup d'oeil: <code>$ 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 </code> Cela confirme que, en fait, il s'agit d'un serveur HTTP. Sinon, nous aurions pu visité l'URL avec un navigateur Web, ou utiliser les commandes Perl GET ou HEAD, qui imitent des interactions HTTP telles que celle donnée ci-dessus (mais les requêtes HEAD peut ne pas être honoré par tous les serveurs). ### Apache Tomcat sur le port 8080. ### La même tâche peut être effectuée par les scanners de vulnérabilités - mais vérifiez d'abord que votre scanner est en mesure d'identifier les services http s'exécutant sur des ports non standards. Par exemple, Nessus [3] est capable de les identifier sur les ports arbitraires (à condition de le charger d'analyser tous les ports), et réalisera un certain nombre de tests sur les vulnérabilités connues du serveur Web, ainsi que sur la configuration SSL de services https. Nessus est également en mesure de repérer les applications courantes / interfaces web qui pourraient autrement passer inaperçus (par exemple, une interface d'administration Tomcat). ## Approches numéro 3 - des hôtes virtuels ## Il yaa un certain nombre de techniques qui peuvent être utilisées pour identifier les noms DNS associées à une adresse IP xyzt donnée ### Transferts de zones DNS ### Cette technique a un usage limité de nos jours, compte tenu du fait que les transferts de zone sont en grande partie non honoré par les serveurs DNS. Toutefois, il peut être utile d'essayer. Tout d'abord, nous devons déterminer les serveurs de noms qui servent xyzt Si un nom symbolique est connu pour xyzt ([www.example.com]), ses serveurs de noms peuvent être déterminés au moyen d'outils tels que nslookup en récupérant les enregistrements NS du DNS. Si aucun des noms symboliques sont connus pour xyzt, mais votre définition de la cible contient au moins un nom symbolique, vous pouvez essayer d'appliquer le même processus et interroger le serveur de noms sur le nom (en espérant que xyzt soit servi ainsi par ce serveur de noms) . Par exemple, si votre cible est constituée de l'adresse IP xyzt et du nom mail.example.com, l'exemple suivant montre comment identifier les serveurs de noms pour [www.owasp.org] en utilisant la commande host: <code>$ 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 </code>Un transfert de zone peut désormais être demandée aux serveurs de noms de domaine example.com. Si vous êtes chanceux, vous pourrez retrouver la liste des entrées DNS pour ce domaine. Il s'agira notamment de [www.example.com] (évident) et de helpdesk.example.com (pas si évident) et webmail.example.com (et probablement d'autres). Il faudra vérifier tous les noms renvoyés par le transfert de zone et de tenir compte de tous ceux qui sont liés à la cible en cours d'évaluation. Essai de demande d' un transfert de zone pour owasp.org de l'un de ses serveurs de noms: <code>$ 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 </code> ### Requêtes DNS inverses ### Ce processus est similaire à la précédente, mais s'appuie sur les enregistrements DNS inverses (PTR). Plutôt que de demander un transfert de zone, essayez de définir le type d'enregistrement PTR et lancez une requête sur l'adresse IP donnée. Si vous êtes chanceux, vous pouvez récupérer une entrée de nom DNS. Cette technique repose sur l'existence de cartes IP-to-symboliqc-name, qui n'est pas garanti. ### Recherches DNS Web-based ### Ce type de recherche s'apparente à un transfert de zone DNS, mais s'appuie sur des services Web qui permettent des recherches sur le nom DNS.Par exemple le service Netcraft Search DNS, disponible sur http://searchdns.netcraft.com/?host. Vous pouvez demander une liste de noms appartenant à votre domaine de prédilection, tel que example.com. Ensuite, vous pourrez vérifier si les noms que vous avez obtenus sont pertinents à la cible que vous examinez. ### Reverse-services IP ### Les reverse-services IP sont similaires aux requêtes DNS inverses, à la différence que vous interrogez une application Web au lieu d'un serveur de noms. Il y a un certain nombre de ces services disponibles. Comme ils ont tendance à rendre un résultat partiel (et souvent différente, il est préférable d'utiliser de multiples services afin d'obtenir une analyse plus approfondie. Service IP inverse .domaintools : http://www.domaintools.com/reverse-ip/ (nécessite une adhésion gratuite) MSN Search: syntaxe http://search.msn.com: “ip: xxxx” (sans les guillemets) Services d'informations hébergement: http://whois.webhosting.info/ syntaxe: http://whois.webhosting.info/xxxx DNSstuff: http://www.dnsstuff.com/ (plusieurs services disponibles) http://www.net-square.com/mspawn.html (plusieurs requêtes sur les domaines et les adresses IP, nécessite une installation) tomDNS: http://www.tomdns.net/index.php (certains services sont encore privés) SEOlogs.com: http://www.seologs.com/ip-domains.html (reverse-IP/domain lookup) L'exemple suivant montre le résultat d'une requête à l'un des services de recherche inverse ci-dessus sur l'adresse IP 216.48.3.18 de www.owasp.org. Trois autres noms symboliques à la même adresse ont été révélés. ### Googling ### Suite à la collecte d'informations à partir des techniques précédentes, vous pouvez utiliser les moteurs de recherche pour éventuellement affiner et augmenter votre analyse. Cela peut donner des preuves supplémentaires de noms symboliques appartenant à votre cible, ou des applications accessibles via des URL non évidentes. Par exemple, compte tenu de l'exemple précédent en ce qui concerne [www.owasp.org,] vous pouvez interroger Google et autres moteurs de recherche à la recherche d'informations concernent les domaines nouvellement découverts de webgoat.org, webscarab.com et webscarab.net . Les techniques Googling sont expliquées dans Testing: Spiders, obots, and Crawlers # Test boîte grise # La méthodologie reste la même que celle figurant dans la section précédente et ce peu importe le nombre d'information que vous déttenez. # Références # ## Livres blancs ## <references/> ## Outils ## - Outils DNS tels que nslookup, dig ou similaire. - Scanners de ports (comme nmap, http://www.insecure.org) et les scanners de vulnérabilités (comme Nessus: http://www.nessus.org; wikto: http://www.sensepost.com/research/wikto /). - Les moteurs de recherche (Google, et autres moteurs majeurs). - Services DNS spécialisés lié à la recherche sur le web. - nmap - http://www.insecure.org - Scanner de Vulnerabilités Nessus