Web

En ouvrant le site, on est accuillies par un site aussi beau qu’inutile (aucun bouton ne fonctionne), mais un bouton est intéressant : “Accès Sécurisé”, menant à la page /login.html

En remplissant le formulaire avec des données aléatoires, on peut vérifier quelles informations sont vraiment utilisées en regardant la requête et sa réponse dans les outils de développement (onglet réseau) :

On voit donc qu’il n’y a pas besoin du niveau d’habilitation ni de la 2FA, seulement l’identifiant et le code d’accès. Il n’y a évidemment pas non plus d’authentification biométrique, et la connexion n’est certainement pas sécurisée par chiffrement AES-256.

Dans ce contexte de formulaire sur une épreuve web, la première idée qui vient à l’esprit est de tenter une injection SQL. On peut confirmer la faisabilité en soulevant une erreur SQL et en regardant la réponse dans un premier temps.

En rentrant ' a dans le champ de l’identifiant, on obtient une erreur SQL :

Bingo !

On peut alors créer notre injection :

admin' or 1=1; --

SELECT * FROM users WHERE username = '<input_username>' AND password = '<input_password>';

1
$username = $_POST['username'];
2
$password = $_POST['password'];
3
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password';";
4
$result = execute_query($query);
5
if ($result) {
6
    // Accès autorisé
7
} else {
8
    // Accès refusé
9
}

SELECT * FROM users WHERE username = '$username'         AND password = '$password';
↓                                    │         └───────┐                │         │
SELECT * FROM users WHERE username = 'admin' OR 1=1; --' AND password = 'something';

On a alors accès à la page sécurisée /user.php, qui contient la mission recherchée :

Exploration

De la même manière que le premier challenge, en ouvrant ce site, on est à nouveau accueillies par un site aussi beau qu’inutile, et cette fois-ci le seul élément intéressant est la barre de recherche permettant d’interroger la base de données :

Des propositions de recherches sont listées sous la barre de recherche, et seulement 2 d’entre elles ne retournent un résultat valide.

En regardant la requête dans l’onglet réseau, on se rend compte que la requête retourne une liste de plusieurs résultats potentiels, eux-mêmes formés d’un champ title et text :

La différence avec le challenge précédent, c’est que cette fois-ci, il ne suffit pas d’obtenir un résultat pour accéder à une page secrète. D’ailleurs, on ne même pas où se trouve le flag. Peut être est-ce une entrée de la table qui est interogée dans la barre de recherche, ou bien est-ce même une autre table.
Dans tous les cas, l’objectif cette fois va être de récupérer la structure de la base de données pour récupérer des informations.

Identification

Comme pour le challenge précédent, la première étape est de tenter une injection SQL pour voir si c’est possible. En rentrant ' a dans la barre de recherche, on obtient une erreur SQL :

Maintenant, il nous faut identifier le logiciel de base de données utilisé, pour pouvoir utiliser la bonne syntaxe. Pour cela, il existe différentes méthodes consistant à exécuter des fonctions ou commandes spécifiques à chaque logiciel, et à observer si elles fonctionnent ou non pour en déduire le logiciel utilisé.

Grâce à ces tests, on peut voir que la fonction sqlite_version() est reconnue, et donc que le logiciel de base de données utilisé est SQLite !

Injection

Cette fois-ci, nous allons utiliser une injection SQL un peu plus avancée que la précédente, qui va nous permettre de faire une union entre notre requête de recherche et une requête qui va nous permettre de récupérer des informations sur la base de données.

Seulement, pour qu’une union fonctionne, il faut que les deux requêtes retournent le même nombre de champs. Sans ça, les requête ne peuvent pas être combinées, résultat en une erreur.

On a vu plus haut que la requête de recherche ne retourne que 2 champs : title et text. Il va donc falloir faire en sorte que notre requête d’union retourne également 2 champs, même si ces champs ne sont pas forcément utilisés.

Commençons par récupérer les différentes tables disponibles. Avec SQLite, c’est possible grace à “super table” sqlite_schema :

aaa' UNION SELECT sql, 'x' FROM sqlite_schema; --

Comme tout à l’heure, décomposons notre injection :

• aaa : le terme de recherche, qui n’a pas d’importance, et qui peut même être laissé vide
• ' : on ferme la chaîne de caractères du terme de recherche
• UNION SELECT : on fait une union entre la requête de recherche et notre requête personnalisée
• sql, 'x' FROM sqlite_schema : on sélectionne le champ sql de la table sqlite_schema, qui contient les requêtes de création des différentes tables, et un champ fictif 'x' vide pour que notre requête retourne 2 champs.
• ; -- : on termine la requête et on commente le reste pour éviter les erreurs

Pour votre plaisir personnel, la requête SQL générée par cette injection ressemble à ça :

SELECT name, description FROM data WHERE name LIKE '%$search';
↓                                                   │       └──────────────────────────────────────────┐
SELECT name, description FROM data WHERE name LIKE '%aaa' UNION SELECT sql, 'x' FROM sqlite_schema; --%';

En exécutant cette injection, on obtient le résultat suivant :

On voit bien la table SONAR_DATA(name TEXT, description TEXT) qui est interrogée pour les recherche, ainsi qu’une deuxième table SECRET_VAULT(flag_key TEXT, flag_val TEXT) qui semble intéressante !

Il ne reste alors plus qu’à faire la requête qui va intéroger cette table pour récupérer le flag :

aaa' UNION SELECT flag_key, flag_val FROM secret_vault; --

Tada !