IDOR
Insecure Direct Object Reference
Les références d'objet directes non sécurisées (IDOR) sont un type de vulnérabilité de contrôle d'accès qui survient lorsqu'une application utilise une entrée fournie par l'utilisateur pour accéder directement à un objet.
Il existe de nombreux exemples de vulnérabilités de contrôle d'accès dans lesquelles des valeurs de paramètre contrôlées par l'utilisateur sont utilisées pour accéder directement aux ressources ou aux fonctions.
L'un des exemples les plus connu est le populaire paramètre id qu'on peut essayer d'incrémenter pour accéder aux données d'un autre utilisateur.
Cependant ce type d'attaque ne se limite pas à un exemple si simple.
Méthodologie
Créer 2 comptes ou plusieurs comptes pour chaque niveau de permissions
Où peut-on trouver ces IDs ?
En effet on peut retrouver des IDs directement dans une url comme dans l'exemple précèdent mais également dans le code source de la page comme c'est souvent le cas sur les sites de réseaux sociaux.
Comment les ressources sont gérées ?
Se connecter avec un "UserA" et intercepter les requêtes des différentes fonctionnalités pour comprendre le fonctionnement de celles-ci.
Créer un compte pour chaque niveau de privilèges..
Créer une ressource avec un "UserA" et essayer de modifier ces ressources avec un "UserB".
Enumeration de ressources via code de reponse
Exemple si on a un endpoint donnant un 404 pour une ressource qui n'existe pas:
GET /api/user/test987123 404 Not Found HTTP/1.1 => n'exite pas
GET /api/user/userA 405 Unauthorized HTTP/1.1 => exite
GET /api/user/1337 405 Unauthorized HTTP/1.1 => existe
GET /api/user/phone/2018675309 405 Unauthorized HTTP/1.1 => existe
Automatisation avec Burp Suite
Autorize
Si vous avez 2 comptes avec des droits différents, connectez vous aux deux avec un navigateur différent, prenez le cookie de session de celui avec le moins de privilèges et entrez le dans Autorize.
Navigez ensuite sur le site avec le compte ayant le plus de privilèges et vérifiez que le compte avec le moins de privilèges n'ai pas l'autorisation d'accéder à des ressources auquelles il ne devrait pas avoir accès.
AutoRepeater
Pour remplacer les UUID et ID dans les requêtes.
Checklist
Trouver et remplacer les IDs dans les urls headers et body
Exemples: /users/01 -> /users/02
Essayer la pollution de paramètres
Exemple: users=01 -> users=01&users=02
Exemple: /users/01* ou /users/*
Essayer les anciennes versions d'API
Exemple: /api/v3/users/01 -> /api/v1/users/02
Bypass via ajouter d'extension
Exemple: /users/01 -> /users/01.json
Changer la méthode HTTP
Exemple: POST / PUT / PATCH / DELETE /users/01
Bypass via l'en-tête Referer
Exemple:
Get /users/02 403 Forbidden
Referer: target.com/users/01
Get /users/02 200 Ok
Referer: target.com/users/02
Remplacer les UUID avec un ID numérique ou un email
Exemple: /users/1b16c096-135d-346f-b54a-eda97413ce28 -> /users/02 ou /users/abc@xyz.com
Essayer des UUID tels que:
00000000-0000-0000-0000-000000000000 -> 11111111-1111-1111-1111-111111111111
Rechercher des leaks de GUID via le contenu des réponses aux fonctions de signup, reset password etc.
Essayer de mettre les deux userID dans un tableau.
Essayer de mettre un double userID.
Essayer d'utiliser un booleen ("userID":true)
Utiliser un ID très long
Mettre des zéros devant l'ID
Mettre un "-" devant l'ID
Mettre un ,0 après l'ID
Mettre les deux ID dans une même chaîne de caractères simplement séparé par une virgule.
Si le userID est reflété dans une URL => "userID":"1234/../4321" (path traversal)
IDOR en aveugle
Coupler IDOR et XSS pour account takeover
REST APIs
ID prédictible
GET /api/v1/account/2222
GET /api/v1/account/2223
Double ID
GET /api/v1/UserA/data/2222
GET /api/v1/UserB/data/2223
Int
{"Account": 2222 }
{"Account": [2222] }
{"email": " UserA@email.com"}
{"email": " UserB@email.com"}
Group
GET /api/v1/group/CompanyA
GET /api/v1/group/CompanyB
Group + email
GET /api/v1/group/CompanyA {"email": " UserA@email.com"}
GET /api/v1/group/CompanyB {"email": " UserB@email.com"}
Nested object
{"Account": 2222 }
{"Account": {"Account": 2223 } }
Token prédictible
{"data": "DflK1df7jSdfa1acaa"}
{"data": "DflK1df7jSdfa2faaa"}
Vulnérabilités UUIDs
Outils
Versions
UUID
00000000-0000-0000-0000-000000000000
UUIDv1
UUIDv2
UUIDv3 et UUIDv5
UUIDv3 et UUIDv5 sont générés en utilisant le hachage du namespace identifier et du nom. La principale différence entre les versions trois et cinq est que UUIDv3 utilise du MD5 comme algorithme de hachage, tandis que UUID v5 utilise du SHA-1.
UUIDv4
Les UUIDsv4 sont générés presque entièrement aléatoirement. Seuls 4 bits sont utilisés pour indiquer la version et deux 2 bits sont utilisés pour indiquer la variante (lorsque la variante-1 est adoptée). Les autres bits (122) sont générés aléatoirement.
Vulnérabilités
UUIDv1
Sandwitch attack:
Le principe est de générer 3 UUID (attaquant puis victime puis attaquant) le plus rapidement possible en utilisant une race condition par exemple. l'UUIDv1 étant basé sur le temps, les 3 UUIDs devraient être très ressemblant les un des autres:
Le but est ensuite de bruteforcer la plage hexadecimal entre les deux UUIDs de l'attaquant jusqu'à trouver celle de la victime. (Dans le cas où il n'existe pas de rate limite ou s'il peut être contourné)
Attention: Cette possibilité est compromise dans le cas où le site ciblé utilise un load balancer ou plusieurs serveurs différents pour gérer la fonctionnalité auquel cas le seul moyen d'utiliser cette attaque est de trouver un moyen de cibler toujour le même serveur ce qui est complexe. (peut être fait en modifiant le /etc/hosts ou en faisant un plus grand nombre de requêtes simultanées.
Il est aussi possible que la fonctionnalité mette du temps à générer les UUIDs auquel cas plus ce temps est élevé plus l'écart entre les UUIDs sera important et donc logiquement plus le temps de bruteforce sera augmenté.
Répartition des IDOR
Outils
Reset-Tolkien
Reset-Tolkien est un outil d'analyse de secrets permettant d'exploiter les secrets non sécurisés basés sur le temps et les attaques sandwich lors de l'usage d'UUID non sécurisés.
Exemple d'utilisation:
$ reset-tolkien detect <secret> -d "Wed, 27 Mar 2024 14:42:25 GMT" --prefix "attacker@example.com" --timezone "-7"
Dernière mise à jour
Cet article vous a-t-il été utile ?
