Exercice 1

L’accès aux profils n’est pas contrôlé côté serveur. Pour trouver la clef, il faut donc envoyer la même requête POST que pour accéder à son propre profil, mais en remplaçant le BODY par {username: "admin"}

Exercice 2

La vérification de la bonne valeur est vérifiée côté client, mais pas côté serveur.

En utilisant un point d’arrêt avant l’appel AJAX, on peut soumettre une bonne valeur, puis, une fois que le point d’arrêt est atteint, remplacer la bonne valeur par une valeur incorrecte (par exemple, -1)

Une fois ceci fait, la requête sera envoyée, sans vérification côté serveur et la partie est gagnée.

Exercice 3

Le mot de passe par défaut n’a jamais été retiré.

Pour se connecter, il suffit d’utiliser l’username admin, et le mot de passe password

Exercice 4

La vérification n’utilise aucune encryption du cookie de session.

Ici, le cookie de session à modifier s’appelle lessonComplete. En utilisant l’inspecteur, onglet Stockage, on peut changer sa valeur de lessonNotComplete à lessonComplete, et la partie est gagnée.

Exercice 5

L’URL de la page des admins est restée dans le code HTML de la page du défi, ce qui la rend très simple à trouver. Il s’agit de /adminOnly/resultKey.jsp

Exercice 6

Le niveau de vérification des injections est zéro. Rentrer <script>alert("xss")</alert> suffit.

Exercice 7

Les balises script sont filtrées. Il faut donc trouver autre chose. Cependant, les script dans les balises html classiques ne sont pas vérifiées.

On peut donc réussir la xss avec <img src="#" onerror="alert("xss") />

Exercice 8

Pour réussir ce challenge, il faut ouvrir l’app dans la VM android. Une fois le message disant que la db est initialisée, on peut se rendre dans la console (alt+F1), puis :

cd /data/data/com.mobshep.insecuredata/databases
sqlite3 Members

Et une fois dans la console sqlite :

select * from members;

Exercice 9

Le mot de passe est encodé en base64. Pour résoudre, on peut juste copier coller et faire, dans une console python

import base64

base64.b64decode(<le mot de passe à décoder>)

Exercice 10

Il s’agit d’une injection SQL.

Pour avoir tous les résultats, il faut remplir l’input avec toto 'or' 1=1

Exercice 11

Il s’agit ici d’un code César.

https://dcode.fr/chiffre-cesar est notre ami ;)

Exercice 12

Certains utilisateurs ne sont pas listés, mais ils existent quand même et l’accès à leur profil n’est pas filtré.

Pour obtenir le profil de l’utilisateur caché, il suffit de changer la value d’une des options dans l’inspecteur (en l’occurence, l’utilisateur qu’on veut à l’id 11, donc il faut mettre value="11").

Puis on demande à montrer le profil donc on vient de changer la value de l’input, et on obtient les données voulues.

Exercice 13

Absolument aucune vérification n’est faite sur la valeur des entrées (même pas côté client).

On veut le troll, donc on met 1 dans l’input. Puis on met une valeur négative de n’importe lequel des autres items. La seule chose qui compte est de commander assez dans le négatif pour composer le prix.

Ici, par exemple, le troll vaut 3000€, donc demander -101 items à 30€ fonctionne.

Exercice 14

A l’exercice 10, la db utilisait des ’ comme délimiteurs. Ici, la db utilise des “.

Il suffit donc de demander : 1 "or" 1=1

Exercice 15

Ici, un cookie de checksum est ajouté à la requête.

Il s’agit d’un encodage base64 du rôle de l’utilisateur. Par défaut, ce rôle est user.

Mais on peut, grâce à l’inspecteur, remplacer la valeur de ce cookie par la valeur obtenue avec le code python suivant :

import base64
base64.b64encode(b"userRole=administrator")
# => b'dXNlclJvbGU9YWRtaW5pc3RyYXRvcg=='

Il faut également changer la valeur HttpOnly du cookie à true, et ça marche ! On est considéré comme admin.

Exercice 16

Pour cet exercice, il faut utiliser dex2jar pour extraire l’apk en format jar, puis jd-gui pour lire le code java décompilé du jar.

Pour dex2jar :

chmod +x d2j-dex2jar.sh
./d2j-dex2jar.sh ReverseEngineer.apk

Puis, en examinant le jar ainsi généré, on peut trouver la clef secrète dans le fichier com.mobshep.reverseengineer/Reverse_Engineering.class

Exercice 17

Ici, on peut trouver deux formulaires dans le code JS : un pour les admins (invisible), et un pour les utilisateurs (visible). Chaque formulaire utilise une URL différente.

Pour réussir, il suffit de ré-envoyer la requête qui a été envoyée en essayant d’accéder au statut du serveur en tant qu’utilisateur normal, mais cette fois vers l’url qu’on a obtenu dans le code de la page.

Exercice 18

Comme durant l’exercice 8, on se rend sur la console android. Là, on fait :

cd /data/data/com.mobshep.udataleakage/files
cat Tue Jul 08 ...

Le fichier en question est une log d’une autre session Android, qui contient la clef nécessaire.

Exercice 19

Ici, le formulaire n’est pas protégé contre les attaques csrf.

On peut donc mettre, dans l’input, l’url malicieuse qu’on veut voir accédée : http://192.168.56.101/root/grantComplete/csrfLesson?userId=1092009423

Exercice 20

Ici, il faut accéder au shell adb d’Android. Pour ça :

adb shell content query --uri content://com.somewhere.hidden.SecretProvider/data

Et on obtient ainsi des données contenant la clef.