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. Elle demanda donc un Pentest auprès de Cédric, notre formateur expert en OSINT et DevSecOps.
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.
Dans nos formations 100% finançables, Cédric abordera la sensibilisation et la notion de culture axée sur la sécurité.
En résumé
- La découverte du problème : Un site web faisait face à des fuites de données régulières malgré diverses mesures de sécurité. Un audit réalisé par Cédric, expert en OSINT et DevSecOps, a révélé que le problème venait d'un dossier .git exposé publiquement, permettant des intrusions.
- Analyse des causes et des conséquences : La faille était due à une mauvaise configuration du serveur Apache qui, par défaut, servait le dossier .git non exclu via le fichier .htaccess. Cela permettait d'accéder et de récupérer facilement le code source versionné du site, exposant des informations sensibles telles que des mots de passe et des clés API.
- Mise en œuvre de la solution : Pour contrer cette faille, la solution recommandée consistait à adopter une configuration zéro trust avec Apache, en interdisant l'accès à tout sauf aux fichiers nécessaires à l'exécution, notamment en bloquant l'accès au dossier .git. De plus, une sensibilisation et une culture de la cybersécurité ont été préconisées pour prévenir de futures crises.
