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

https://target.com/customer_account?id=132355

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

• Essayer bypass via caractères spéciaux

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

• ID chiffré ? encodé ? Cracker ou decoder via différents outils

• Remplacer les UUID avec un ID numérique ou un email

Exemple: /users/1b16c096-135d-346f-b54a-eda97413ce28 -> /users/02 ou /users/[email protected]

• Essayer des UUID tels que:

00000000-0000-0000-0000-000000000000 -> 11111111-1111-1111-1111-111111111111

• Essayer de retrouver des leaks de GUID via Google Dorks, Github, la Waybackmachine...

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

{
    "userID":[
        1234,
        4321
    ]
}

• Essayer de mettre un double userID.

{
    "userID":{
        "userID":1234
        }
}

• 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)

• Essayer de bypass la restriction via 403 bypass

• IDOR en aveugle

• Coupler IDOR et XSS pour account takeover

Niveau d'impact

Une IDOR est critique si:

• Elle permet-elle de faire fuiter des données personnelles (Identité, emails etc)

• Elle permet de bypass un payement (en payant avec la carte de crédit enregistré d'un autre utilisateur par exemple)

• Elle permet d'effectuer des actions au nom d'un autre utilisateur

• Elle permet de détruire ou endommager des informations ou assets.

REST APIs

Type	Requête	IDOR
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	{"email": " [e-mail]"}	{"email": " [e-mail]"}
Group	GET /api/v1/group/CompanyA	GET /api/v1/group/CompanyB
Group + email	GET /api/v1/group/CompanyA {"email": " [e-mail]"}	GET /api/v1/group/CompanyB {"email": " [e-mail]"}
Nested object	{"Account": 2222 }	{"Account": {"Account": 2223 } }
Token prédictible	{"data": "DflK1df7jSdfa1acaa"}	{"data": "DflK1df7jSdfa2faaa"}

Vulnérabilités UUIDs

Outils

https://www.uuidtools.com/decode: decodeur d'UUID en ligne

Versions

UUID

00000000-0000-0000-0000-000000000000

UUIDv1

Decomposition d'un UUIDv1

UUIDv2

Decomposition d'un 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:

UUIDs attaquant:
https://target.com/reset/99874128-7592-11e9-8201-bb2f15014a14
https://target.com/reset/998796b4-7592-11e9-8201-bb2f15014a14

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é)

cella peut être fait avec l'outil suivant: https://github.com/Lupin-Holmes/sandwich

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 "[email protected]" --timezone "-7"

Ressource: https://github.com/AethliosIK/reset-tolkien