[STANDARD] OWASP - Episode 1

Question de mode ou de professionnalisme, chacun voit les normes et standards à sa manière. Quoi qu'il en soit, elles sont là pour nous guider dans un travail tels que les tests d'intrusion qui ne peuvent être assimilés à une sciences exacte. Dans ce but, nous allons étudier la norme OWASP. Afin d'étudier les différents points qui y sont abordés, 10 épisodes seront rédigés sur ce blog.

1 - Avant-propos

La norme OWASP est découpée de la manière suivante :

• une introduction, la présentation des bases de la norme ;
• la phase préliminaire des tests (collecte d'information) ;
• le déroulement des tests (9 chapitres).

Dans ce premier épisode, nous allons parler des deux premiers points tandis que les 9 prochains épisodes aborderont chacun des 9 chapitres.

Il est important de noter que la norme étudiée est dédiée à la partie tests d'intrusion d'une application WEB. L'OWASP en propose d'autres comme un guide de développement et un guide de revue de code qui sont complémentaires au guide de tests en question [télécharger].

Pour les points 2 et 3 qui suivent, seuls les idées principales seront énoncées. Le but est d'en donner un résumé, non de les retranscrire ;)


2 -Introduction à la norme

2.1 - Le modèle SDLC

La norme OWASP repose sur le modèle SDLC pour Software Development Life Cycle. L'idée est de prendre en compte toutes les étapes de la conception d'une application WEB, c'est à dire les phases de :

• définition (cahier des charges, RFP) ;
• conception ;
• développement ;
• déploiement ;
• maintenance.

L'idée est que plus un problème est détecté tôt, moins il coûtera en temps et en argent. Sachant qu'un test d'intrusion est généralement effectué juste avant son déploiement (tests avant mise en production) ou après son déploiement (pour cause de retard du lancement de tests ou tests récurrents), les trous de sécurité pourraient être traités plus en amont. C'est là qu'entrent en jeu les autres tests : revue du code et développement du code de manière sécurisée.

A cela, il faut ajouter les interviews qui permettent d'obtenir des renseignements auprès des personnes qui ont conçu l'application et qui fourniront par conséquent des informations précieuses et permettront de régler d'éventuels erreurs en amont. S'engage alors la mise en pratique des normes plus organisationnelles tels que l'ISO 27002. Nous pouvons aussi considérer le standard PCI-DSS dans le cadre d'une application bancaire.

Concrètement, la solution se trouve du côté des audits combinés qui permettent de considérer l'ensemble des contrôles aux différentes phases nécessaires. Ce type d'audits devraient comprendre le suivi des standards (ISO 27002), la revue de code, l'audit de configuration et les tests d'intrusion.

2.2 - L'exhaustivité des tests

Pour s'assurer que les tests seront suffisamment exhaustifs, il y a deux concepts à prendre en compte :

• établir les pré-requis avant de lancer les tests qui permettent de prendre en compte les fonctionnalités de l'application WEB et les scénarios possibles. Est-ce que toutes les menaces sont traitées et disposent d'un moyen de contrôle ? de protection ?
  
• l'exhaustivité des tests doit porter sur les composants annexes à l'application (librairies, DLL, etc.) ;
  
• les tests doivent être pondérés :
  
• Tout d'abord, chercher les bugs (tests quantitatifs) ,
  
• Ensuite, évaluer la pertinence et le risque associé (tests qualitatifs).

3 -Les bases de la norme

En premier lieu, la norme recommande la suivi d'un standard de bonnes pratiques pour le développement (ex : eXtreme). Ensuite, il convient d'effectuer les tests à différentes phases :

• Avant le développement de l'application (revue des standards et polices, définition des critères de mesures) ;
• Pendant les phases de définition et de conception (listes des pré-requis, revue de l'architecture, modèle UML, analyse de risque) ;
• Pendant le développement (points d'entrée de l'application ? revue de code) ;
• Pendant le déploiement (tests d'intrusion, audit de configuration) ;
• Pendant la phase de maintenance (gestion de l'infrastructure et de l'application elle-même, tests périodiques et gestion des modifications).

4 - Les tests d'intrusion

Selon la norme OWASP, les tests d'intrusion sont décomposés en :

• 1 phase préliminaire, la phase de collecte (IG pour Information Gathering) ;
• 9 phases de tests actifs.

C'est le premier point que nous abordons dans cette dernière partie de ce post.

4.1 - IG-001 : Aspirateur de site et robots

1/ Il s'agit de récupérer dans un premier temps le fichier robots.txt du site WEB de la cible :

wget http://cible.fr/robots.txt

2/ Analyser ce fichier :
a) Il vous faut un compte google. Si vous n'en avez pas, vous pouvez vous inscrire ici.
b) Utiliser l'outil d'analyse de google.


4.2 - IG-002 : Moteur de recherche

1/ Utiliser un moteur de recherche (ex : google) avec le mot clé site :

site:cible.fr

2/ Glaner des informations sur la page enregistrée en cache :

4.3 - IG-003 : Identification des points d'entrée

Le but ici est de récupérer des informations à l'aide d'un proxy local (tels que Paros, Webscarab ou Burp Suite par exemple).

1/ Ici, identifier les méthodes POST et GET, leur utilisation.
2/ Identifier aussi les paramètres passés dans les URLs, les entêtes et le corps des requêtes et réponses.


3/ Regarder s'il existe des champs cachés ou autre information intéressante dans le code source de l'application.
4/ Étudier l'utilisation des cookies.
5/ Étudier les informations qui peuvent être contenues dans les entêtes.


4.4 - IG-004 : Fingerprinting

Il existe plusieurs manière pour trouver la version du serveur WEB et de l'OS :
1/ Grâce à Netcat :

nc cible.fr 80
HEAD / HTTP/1.0

2/ Si l'entête ne fournit pas directement les informations recherchées, l'ordre des champs peut fournir la réponse.
3/ Tenter les requêtes malformées (exemples) :

nc cible.fr 80
HEAD /truc.html HTTP/1.0
HEAD / HTTP/3.0

4/ Utiliser les outils automatisés comme httprint :

./httprint -h cible.fr -s signatures.txt

5/ Le site Netcraft [site]


4.5 - IG-005 : Découverte de l'application

1/ Trouver les applications annexes via l'URL. Par exemple, http://cible.fr/webmail. Elles peuvent être trouvées en les devinant pour les plus évidentes ou à l'aide d'un scanner WEB comme Nikto.
2/ Trouver les ports non standards hébergeant des interfaces WEB à l'aide d'un scanner de port comme NMAP (puis vérifier avec telnet) :

nmap cible.fr -p- -sS -sV -PN

3/ Lancer les requêtes DNS (pour trouver les hôtes virtuels) :
a) Tenter le transfert de zones ;

host -t ns cible.fr
host -l cible.fr serveur_dns_cible

b) Tenter les requêtes inverses ;

./dns-ptr cible.fr nb_adresse_ip

c) Recherche DNS via le service de Netcraft [site] ;
d) Requêtes inverses [site] ;
e) Autres recherches avec Maltego par exemple.

4.6 - IG-006 : Analyse des erreurs de code

1/ Provoquer des erreurs via les requêtes HTTP (Erreurs 404 et 500 notamment).

nc cible.fr 80
GET /truc.html HTTP/1.0
GET /truc.html HTTP/1.1

2/ Tester les défauts de configuration du serveur WEB, de la base de données, ...



3/ Tenter une mauvaise authentification.

• Le message d'erreur est-il différent quand le login ou le mot de passe sont faux ?
• Une erreur d'authentification révèle-t-elle des informations sur la nature du serveur / équipement d'authentification ?
• Une erreur d'authentification révèle-t-elle des informations sur la nature du login ? du mot de passe ?

La suite au prochain épisode !