L'analyse commence par le coffre-fort des recettes secrètes de l'entreprise. On s'intéresse aux données stockées et aux journaux associés.
On commence par s'intéresser à comment les recettes sont stockées et sécurisées dans l'entreprise. On se penche donc sur le coffre fort sécurisé qui les stocke et les versionne, dont on a extrait la base de données.
Notre premier objectif est de déterminer précisément ce qui a été volé, à partir du message que le cybercriminel a posté sur le darknet.
Il sera ainsi possible par la suite de déterminer qui a exporté ce qui a été volé en exploitant les journaux, en sachant que le format présenté par l'attaquant est celui de la fonction **d'export** du coffre-fort.
Dans cette première partie, le dump d'une base de données est fourni.
Un bref cat ou less nous montre que le fichier est un binaire donc illisible pour un humain. Cependant, on voit en clair dans le fichier des références à "postgres". Il s'agit donc d'une base de données PostgreSQL.
Cela nous est d'ailleurs confirmé en utilisant la commande file :
$ file recipes.dump
recipes.dump: PostgreSQL custom database dump - v1.15-0
````
Pour exploiter ce dump, on peut monter une base de données PostgreSQL vierge, puis importer les données dessus avec la commande :
```bash
$ pg_restore -d postgres recipes.dump
On peut désormais lire les tables de la base de données. D'après le message de la personne qui se propose de revendre la recette volée, on va chercher les versions de la recette "Fizz Is Cool" avec une quantité de gaz de 0.28 et de sucre de 15.
Voici un aperçu de la table recipes qui liste les différents articles versionnés dans cette base de recettes. On constate que "Fizz Is Cool" correspond à l'id 21.
De même, dans la table ingredients, on constate que les identifiants qui correspondent à gaz et sugar sont respectivement 23 et 5.
Il faut donc désormais rédiger les bonnes commandes SQL pour trouver la version de la requête volée. Deux autres tables nous seront utiles pour cela : recipe_versions qui associe à une recette ses différentes versions datées, et recipe_ingredients qui liste les ingrédients de chaque version de chaque recette.
Voici une commande SQL possible pour récupérer l'information recherchée, en faisait une jointure sur l'identifiant unique de version précise d'une recette :
SELECT
*
FROM
(SELECT
version_uuid
FROM
recipe_ingredients
WHERE
ingredient_id = '23'
AND value = '0.28' INTERSECT SELECT
version_uuid
FROM
recipe_ingredients
WHERE
ingredient_id = '5'
AND value = '15'
) AS valid
JOIN
recipe_versions
ON valid.version_uuid = recipe_versions.uuid
WHERE
recipe = 21;
Cette commande nous renvoie les versions de la recette qui remplissent ces contraintes : 4 et 72.
Cependant, en regardant dans la colonne recipe_versions, on constate que l'entrée à l'identifiant 72 a été créée après la publication du message, la version volée est donc la version 4.
Pour la seconde partie de l'étape, il est fourni deux nouveaux fichiers au format .csv, qui correspondent à la journalisation d'un système de "tickets" pour demander des droits d'accès, d'export ou de gestion de recettes stockées dans le coffre-fort numérique :
tickets.csv, recense le contenu de chaque ticket (avec notamment la recette et sa version demandée).logs.csv, liste tous les événements survenus sur ces tickets (création, acception, refus, etc.) avec horodatage et identification de l'utilisateur.On va chercher les logs, et plus particulièrement les exports réalisés pour la recette dans la version identifiée plus tôt. Cela peut se faire avec un script mettant en relation les deux fichiers par leur donnée commune (l'identifiant du ticket), mais aussi avec des commandes bien choisies dans un éditeur de texte avancé. Dans la suite cette explication, nous en ferons la démonstration avec Vim.
On s'intéresse donc aux tickets traitant la version 4 de la recette à l'identifiant 21. En ouvrant le fichier tickets.csv avec Vim, on peut les filtrer en supprimant toutes les autres lignes, afin de ne garder que les tickets qui portent sur cette version de la recette, avec la commande suivante :
Après cette manipulation, il nous reste 132 lignes, donc 132 tickets portant sur cette version de la recette volée.
Dans le fichier logs.csv, on peut réaliser une manipulation similaire, afin de ne conserver que les logs d'ouverture de ticket demandant le droit d'exporter la recette en dehors du coffre-fort (OPEN_TICKET_REQUEST_EXPORT), avec la commande Vim :v/OPEN_TICKET_REQUEST_EXPORT/d.
Cela nous laisse 2758 lignes de journaux.
Par la suite, on va chercher les identifiants communs entre les deux fichiers filtrés. Pour cela, on supprime les colonnes inutiles des fichiers .csv pour ne garder que les identifiants de tickets. Il sera aussi très pratique de trier les identifiants dans l'ordre alphabétique, cela peut se faire avec le programme sort (ou même :%sort directement dans Vim).
Il ne reste plus qu'à comparer les deux fichiers ainsi traités pour chercher des lignes communes. Par exemple avec vimdiff, on remarque rapidement qu'il n'y a qu'une seule ligne commune, pour l'identifiant 9575df87-e3c0-42b5-b3c6-53982898f624.
En recherchant cet identifiant de ticket dans les fichiers originaux, on trouve que son export a été demandé par l'utilisateur à l'identifiant 2002 et accepté par l'utilisateur à l'identifiant 1000. Les dates correspondent au 22 novembre 2024.
