User Tools

Site Tools


hack:testing_for_privilege_escalation

testing_guide

Résumé

Cette section traite de l'escalade de privilèges. Au cours de cette phase, le testeur doit vérifier qu'il n'est pas possible pour un utilisateur de modifier ses rôles /privilèges à l' intérieur d'une application, d'une manière qui pourrait permettre des attaques d'escalade de privilèges.

Description

L'élévation de privilèges d'émission se produit lorsqu'un utilisateur a accès à plus de ressources ou des fonctions qu'il ne devrait être normalement autorisé, et lorsqu'une telle élévation / modification aurait pu être évités par l'application. Ceci est habituellement causé par un défaut dans l'application. Le résultat est que l'application effectue des actions avec plus de privilèges que ceux prévus par le développeur ou l'administrateur système.

Le degré de progressivité dépend de quel privilège l'attaquant est autorisé à posséder, et quel privilège peut être obtenue par une exploitation réussie de la faille. Par exemple, une erreur de programmation qui permet à un utilisateur d'obtenir les privilèges supplémentaires après une authentification réussie limite le degré de l'escalade, parce que l'utilisateur est déjà autorisée à détenir un privilège. De même, un attaquant distant qui gagne privilèges de superutilisateur sans aucune authentification présente un plus grand degré de progressivité.

Habituellement, nous nous référons à une escalade verticale quand il est possible d'accéder à des ressources accordées à des comptes plus privilégiés (par exemple, l'acquisition des droits d'administrateur pour l'application), et à une escalade horizontale quand il est possible d'accéder à des ressources accordées à un compte dont la configuration est similaire (par exemple, dans une application bancaire en ligne, accéder à des informations associées à un utilisateur différent).

Test Boîte Noire

Exemple de manipulation de rôle/ privilège

Dans chaque partie de l'application dans laquelle un utilisateur peut créer de l'information dans la base de données (par exemple, effectuer un paiement, ajouter un contact, ou envoyer un message), recevoir des informations (relevé de compte, détails de la commande, etc), ou supprimer des informations (supprimer des utilisateurs, des messages, etc), il est nécessaire de tester cette fonctionnalité. Le testeur doit tenter d'accéder à des fonctions réservées à un autre utilisateur afin de vérifier, par exemple:

  • Est-il possible d'accéder à une fonction qui ne devrait pas être permise pour le rôle/ privilège de l'utilisateur (mais peut être autorisé avec un autre utilisateur)?.

Exemple:

Le POST HTTP suivant permet à l'utilisateur qui appartient à grp001 d'accéder à la commande n ° 0001:

POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...
gruppoID=grp001&ordineID=0001
  • Un utilisateur qui n'appartient pas à grp001 peut il modifier la valeur des paramètres 'gruppoID' et 'ordineID ' pour accéder à ces données privilégiées?.

Exemple:

La réponse du serveur suivante montre un champ caché dans le code HTML renvoyé à l'utilisateur après une authentification réussie.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com 
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache 
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close
<form  name=“autoriz" method="POST" action = “visual.jsp"> 
 <input type="hidden" name="profilo" value="SistemiInf1">                                         
 <body onload="document.forms.autoriz.submit()">
 </td>
 </tr>
  • Si le testeur modifie la valeur des variables “profilo” à “SistemiInf9” Est-il possible de devenir administrateur?

Exemple:

Dans un environnement dans lequel le serveur envoie un message d'erreur contenant comme valeur un paramètre spécifique relatif à un ensemble de codes de réponse, comme suit:

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValido`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`    
StateExecToolBar`0`0`0`FlagsToolBar`0

Le serveur donne une confiance implicite à l'utilisateur. Il croit que l'utilisateur répondra avec le message ci-dessus pour fermer la session. Dans ce cas, vérifiez qu'il n'est pas possible d'élever ses privilèges en modifiant les valeurs des paramètres. Dans cet exemple particulier, en modifiant lavaleur de PVValido de '-1' à '0 '(pas de conditions d'erreur), il peut être possible de s'authentifier en tant qu'administrateur sur le serveur.

Références

Livres blancs

Outils

  • OWASP WebScarab: OWASPWebScarabProject
hack/testing_for_privilege_escalation.txt · Last modified: 2019/02/13 13:10 by 127.0.0.1