Un site web connu subissait des fuites de données régulières. Changement de mots de passe, de clé d’accès, mise à jour des dépendances, rien n’y faisait, il y avait toujours des intrusions.
La situation en venait à menacer l’activité de l’entreprise, à tel point qu’elle envisageait de couper les accès pour préserver ses clients.
Le pentest
La première phase de l’audit est le test d’intrusion. En utilisant les outils et techniques OSINT (Open Source Intelligence) et quelques formes plus offensives, Cédric a réussi à repérer la faille sur le site en question.
Un dossier caché, fondamental, était exposé au public et accessible très facilement. Il s’agissait du dossier .git.
.git est un dossier caché généré par l’outil git. Très connu des développeurs, git est un outil de versionning de code sur un serveur distant ou local. Côté serveur distant, Github et Gitlab sont les plus grands fournisseurs de ce service.
Git reproduit en local le système de version dans un dossier caché nommé .git.
Causes et conséquences de la faille
Les causes
Dans notre cas : un Wordpress utilise des fichiers PHP à la racine du projet, dont index.php qui est le point d’entrée.
Avec un Apache, le serveur sert les fichiers disponibles à la racine. On définit les fichiers à exclure dans un fichier .htaccess. Si le .git n’est pas exclu dans ce fichier, Apache servira le .git.
On se retrouve avec ce type de vue lorsque l’on tape exemple.com/.git dans le navigateur :
Les conséquences
Le .git contient l'ensemble du code source versionné. Vous pouvez le récupérer très facilement à l'aide d'un script de scraping comme ci-dessous :
Pour savoir à quel point le .git est important, vous pouvez, sur un projet, supprimer tout le code et taper la commande suivante : git reset --hard HEAD
Cette action va restaurer tout votre code. Vous pourrez ensuite naviguer normalement avec les commandes
git log
et
git checkout <code du commit>
Maintenant que vous avez accès au code source, vous pouvez aller fouiller à l'intérieur, ou reproduire le repo sur GitHub, pour trouver des mots de passe, des clés API, et autres éléments qui vous permetteront d'utiliser le site.
Dans notre cas, il s'agissait d'un compte de test dont les accès avaient été codés en dur puis supprimés via un commit. Le compte de test existant toujours, celui-ci avait accès à des informations de test issues de la base de production. Périmées, anonymisées pour la plupart mais néanmoins exploitables.
Elle ouvrait la porte à des données sensibles plaçant la société en porte-à-faux avec ses clients et les autorités.
Solution
Dans une configuration Apache, et dans une démarche zéro trust, le mieux est d'interdire l'accès à tout sauf aux fichiers strictement nécessaires à l'exécution.
Voici un exemple de configuration .htaccess pour l'interdiction d'accès (dont le .git) :
<Directorymatch "^/.*/.git/">
Order 'deny,allow'
Deny from all
</Directorymatch>
Côté code, il est possible de renvoyer une 404 sur tout ce qui n'est pas paramétré dans une route correctement définie.
Pensez à la sensibilisation, optez pour la culture cybersécurité pour vous éviter des crises coûteuses.
