[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