[STANDARD] OWASP - Episode 2

Suite du premier épisode qui traitait de la collecte d'information. Ici, nous abordons le premier chapitre des tests actifs. Plus précisément, ils concernent les tests sur l'infrastructure environnante et l'application auditée elle-même.

1 - Avant-propos

Pour rappel, la méthodologie d'OWASP décompose les tests d'intrusion en :

• une phase de tests dits passifs (collecte d'informations) ;
• neuf phases de tests actifs.

C'est la première des 9 phases de tests actifs que nous étudions ici, appelé Configuration Management (CM).

2 - Phase de tests actifs 1 : tests sur la configuration de l'infrastructure et de l'application

2.1 - CM-001 : Tests sur les certificats, SSL/TLS

Les certificats peuvent donner un sentiment de "fausse sécurité". Il est important alors de vérifier que les données sont transmises de manière sécurisée sans quoi un attaquant sera en mesure de récupérer les informations sensibles qui transitent. La démarche du test se déroule en trois axes :

1/ Quelle est la robustesse du chiffrement par défaut (taille de la clé suffisante ? Algorithme de chiffrement satisfaisant ? Algorithme de hashage existant et suffisant ?)


2/ En parallèle, d'autres chiffrements, dits faibles, sont-ils autorisés ? SSLv2, connu pour être vulnérable aux attaques de type Man-in-the-Middle, est-il permis ?

openssl s_client -ssl2 -connect www.cible.com:443

3/ Le certificat utilisé est-il valide ?

• Est-il auto-signé (non recommandé) ?
• Est-il bien signé par une autorité reconnue (recommandé) ?
• Est-il à jour (i.e. non expiré) ?
• L'URL trouvé sur le certificat correspond-elle au site WEB ?

A noter : la sécurité des certificats a déjà été abordé dans un post précédent [plus d'info, partie 2].

2.2 - CM-002 : Tests sur le Listener d'Oracle

Via le Listener d'Oracle, il est possible d'exécuter des commandes, voire de prendre la main sur le serveur. C'est pourquoi cette section a pour objectif de trouver une vulnérabilité sur ce serveur de base de données.

1/ Identifier le service à l'aide de NMAP par exemple (par défaut, il s'agit des ports 1521, 2483 ou 2484).

2/ Auditer le serveur Oracle avec l'outil de INTEGRIGY [info] [télécharger].

3/ Tester avec le client Oracle pour obtenir :

• des informations supplémentaires ;
• la liste des comptes ;
• trouver des procédures capables d'exécuter des commandes arbitraires.

4/ En boîte grise, vérifier la bonne configuration du fichier Listener.ora.

A noter : de nombreuses références et outils pour auditer un serveur Oracle sont disponibles [ici].

2.3 - CM-003 : Audit de l'infrastructure

Ce troisième point nous apportera une meilleure connaissance de l'architecture. Principalement, nous devrions avoir une meilleure vue sur les protections réseau employées.

1/ Revue de l'architecture de l'application :

• Avons-nous un pare-feu ? Si oui, l'isolation des éléments de l'architecture est-elle correctement configurée ?
• Un reverse-proxy ?
• Un répartiteur de charge ?
• Une base de données ?
• Un serveur d'authentification ?
• Etc ...

2/ Existe-t-il des vulnérabilités connues sur les éléments de l'infrastructure identifiés ? (NESSUS + securityfocus.com + tests manuels + ...)

3/ Des outils d'administration sont-ils présents ? Accessibles ?

A noter : Pour la recherche de vulnérabilités connues, voir deux précédents posts sur NESSUS et son utilisation [ici] et [là].

2.4 - CM-004 : Configuration de l'application

La présente section a pour but d'identifier les problèmes de configuration globaux de l'application et la gestion des logs.

1/ Des fichiers d'installation / connus sont-ils présents sur le serveur ? (ex : les fichiers d'installation par défaut d'Apache).


2/ Passer en revue les commentaires contenus dans le code source des pages de l'application.

En boîte grise,

3/ Auditer les fichiers de configuration du serveur WEB. Le niveau de sécurité est-il suffisant ?

4/ La gestion des logs est-elle satisfaisante ?

• Comment sont traitées les informations sensibles ?
• Où sont stockés les logs ?
• De quel manière sont-il stockés ? (espace disque suffisant ? partitionnés par application ? supervisés ?)
• Comment est appliquée la gestion des logs ? (période ? compression des archives ? permissions attribuées sur les archives suffisamment restrictives ?)
• Les logs importants sont-ils bien audités ? (ex : erreurs 40x et 50x).

2.5 - CM-005 : Contrôle des extensions de fichiers

Les extensions de fichiers peuvent d'une part révéler de nouvelles informations. D'autre part, elles peuvent prouver l'existence d'un type de fichier et donc la présence d'informations sensible s et/ou techniques.

1/ Lancer des requêtes HTTP avec des ressources dont l'extension est différente. Quel est le comportement du serveur WEB ?

2/ Trouver les répertoires contenant les scripts (grâce à Nessus, Nikto, Crawler, ...).

2.6 - CM-006 : Fichiers anciens, de sauvegarde et non référencés

Bien souvent, des fichiers sont stockés sur le serveur par oubli ou par mégarde. Malheureusement, ils fournissent souvent des informations précieuses ou des accès illégitimes.

1/ Déduire l'existence de nouveaux fichiers / répertoires. Par exemple,

• s'il existe le fichier removeuser.asp, tenter adduser.asp ;
• s'il existe le répertoire /users, existe-t-il le répertoire /admin ?

2/ Trouver de nouveaux fichiers qui seraient cités :

• dans les commentaires du code source ;
• dans les codes javascript ;
• dans le fichier robots.txt.

Exemple récupéré sur le site www.lemonde.fr/robots.txt :

User-agent: *
Disallow: /web/recherche_resultats/
Disallow: /web/recherche/
Disallow: /web/yahoosearch/resultats/
Disallow: /web/newsletter_exemple/
Disallow: /web/teaser/
Disallow: /web/inscription_newsletter/
Disallow: /qui-sommes-nous/
Disallow: /web/abopapier/
Disallow: /services-aux-internautes/
Disallow: /web/ep/service_clients/
Disallow: /web/siteweb/
Disallow: /web/imprimer_element/
Disallow: /web/imprimer_archive/

3/ Tenter de trouver de nouveaux fichiers en modifiant leur extension ou en ajoutant une nouvelle (ex : .bak, .old, etc ...).

4/ Chercher s'il existe des vulnérabilités connues affectant le serveur WEB permettant par exemple de lister les répertoires et fichiers ou de récupérer des informations techniques.

5/ Chercher des fichiers via :

• les moteurs de recherche ;
• la page cache sauvegardée par Google, Yahoo, ou les sites d'archivage (ex : archive.org) ;
• les liens fournis par les sites tiers.

2.7 - CM-007 : Interfaces d'administration de l'infrastructure ou de l'application

Les interfaces d'administration permettent d'acquérir des droits plus importants ou du moins, d'exécuter des commandes qui ne sont pas permises pour un utilisateur standard. De tels accès peuvent mener à la compromission du serveur lui-même.

1/ Énumérer les répertoires et fichiers pouvant contenir une interface d'administration (ex : /admin).

2/ Trouver les interfaces grâce aux commentaires ou aux liens WEB parcourus par l'application.

3/ Voir la documentation du serveur et de l'application pour en connaître les répertoires d'administration par défaut. Éventuellement, testes les couples login/mot de passe par défaut (ex : site).

4/ Trouver une interface d'administration sur un autre port. Cet exemple a été abordé dans des posts plus anciens avec JonAs et JBoss.


5/ Est-il possible d'accéder à une interface d'administration en modifiant un cookie ?


2.8 - CM-008 : Tester les méthodes HTTP autorisées et test de l'attaque XST

Certaines méthodes HTTP permettent des actions malicieuses. Elles doivent donc être restraintes ou du moins contrôlées correctement pour éviter qu'un pirate en abuse pour exécuter des commandes arbitraires par exemple.

1/Quelles sont les méthodes HTTP autorisées ? Deux manières peuvent nous apporter la réponse :

a) Netcat + la méthode OPTIONS. Cette dernière liste toutes les méthodes actives si elle est elle-même activée.

nc www.cible.fr 80
OPTIONS / HTTP/1.1

b) Utiliser l'outil Metoscan

POST => N/A
GET => 200 (OK) / 400 (BAD REQUEST)
CONNECT => 200 (OK) / 400 (BAD REQUEST)
PUT => 200 (OK) / 400 (BAD REQUEST)
DELETE => 200 (OK) / 400 (BAD REQUEST)
HEAD => 200 (OK) / 400 (BAD REQUEST)
TRACE => 200 (OK) / 400 (BAD REQUEST)
...

Bien sûr, chaque méthode peut être testée manuellement.

2/ Test de l'attaque XST

Possible si la méthode TRACE est active. Il faut aussi qu'une faille de type XSS (côté serveur) ou que l'exécution de code javascript (côté client) nous permette de lancer une attaque.

3/ Tests des commandes arbitraires

Tester si la méthode JEFF est active. Si oui, une attaque pourra être envisagée.

nc www.cible.fr
JEFF / HTTP/1.1

4/ Contournement des contrôles d'accès via la méthode HEAD

nc www.cible.fr
HEAD /admin HTTP/1.1

A suivre : L'épisode 3 de ce post abordera l'authentification.