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 ...
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.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 :
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 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 :
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.
- 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).
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é).
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.
1 commentaire:
Thats great
Enregistrer un commentaire