Tutos dev’ & informatique

Hacking et protection de dossier .git accessible par le web

Publié le mercredi 14 juillet 2021
Exploitation et protection de dossier .git accessible depuis un site web

Introduction

Récemment, j’ai rencontré dans le site internet d’un client une faille de sécurité assez intéressante pour en faire un article. Il s’agissait d’un défaut de sécurisation du dossier .git (dossier contenant le repository Git pour le versionning des sources) qui permettait à n’importe qui de le télécharger.

Nous allons voir comment déterminer si un site est vulnérable, comment télécharger le dossier .git si c’est le cas et récupérer les codes sources. Finalement, nous verrons comment nous protéger contre cette faille de sécurité dans le cas d’un site sous serveur Apache.

Note : les scripts ont été testés sur une Debian 9, et le code htaccess a été testé dans un environnement Apache 2.4 chez l’hébergeur o2switch. N’oubliez pas de toujours faire une sauvegarde avant de modifier les fichiers de votre site !

Hacking : récupérer le code d’un site avec un dossier .git exposé

1) Tester si le site est exploitable

Avant toute chose, nous devons savoir si le site contient bien un dossier .git, et si nous pouvons lire les fichiers de ce dernier depuis notre navigateur. Trois cas peuvent se présenter : soit le dossier est accessible et nous présente l’index des fichiers, soit le dossier est accessible mais nous n’avons pas accès à l’index, soit le dossier est inaccessible.

Pour voir si le dossier est accessible et indexable, il faut tenter d’y accéder directement. Par exemple, on peut se rendre avec un navigateur à l’adresse http://example.com/.git/ . Si le serveur nous retourne la liste des fichiers cela veut dire que le dossier est accessible et indexable, ce qui nous permettra de le télécharger très facilement.

Contenu du dossier .git accessible et indexable

La plupart des serveurs sont configurés pour ne pas renvoyer ce genre d’index (mais bon, les sites legacy sont encore nombreux). Qu’à cela ne tienne, nous pouvons tenter aussi d’accéder directement aux fichiers. Pour cela, il faut se rendre avec son navigateur sur l’adresse d’un fichier du dossier .git qui est toujours présent : http://example.com/.git/HEAD . Si ca marche, alors nous pourrons exploiter le fait que les fichiers du dossier .git contiennent des références les uns envers les autres, et les parcourir les uns après les autres pour en récupérer la majorité.

Contenu du fichier HEAD du dossier .git accessible

Si rien ne marche, alors soit le site ne contient pas de dossier .git, soit il a été rendu inaccessible, soit il se situe ailleurs.

2a) Télécharger le dossier .git d’un site indexable

Si le dossier est indexable, alors il peut être téléchargé en intégralité depuis un shell avec une commande wget :

# Création du dossier de téléchargement
mkdir ~/sitedump
cd ~/sitedump

# Téléchargement
wget --recursive --no-parent --no-host-directories --reject "index.html*" -e robots=off http://example.com/.git/

# Le contenu est dans ~/sitedump/.git/
ls .git/

2b) Télécharger le dossier .git d’un site non-indexable

Pour télécharger un dossier .git non-indexable, on peut utiliser les outils du projet GitTools mis à notre disposition par Internetwache. Il contient :

  • Dossier Finder : un script de test de la vulnérabilité des sites à l’exploitation de dossier .git
  • Dossier Dumper : un script de téléchargement de dossier .git non-indexable
  • Dossier Extractor : un script de récupération des sources pour les dossiers .git cassés ou incomplets

Une fois les sources de l’outil récupérées, nous pouvons utiliser le Dumper pour récupérer en partie le dossier .git du site cible :

# Création du dossier de téléchargement
mkdir ~/sitedump

# Téléchargement
cd ~/GitTools-master/Dumper
chmod u+x gitdumper.sh
./gitdumper.sh http://example.com/.git/ ~/sitedump

# Le contenu est dans ~/sitedump/.git/
cd ~/sitedump
ls .git/

Le Dumper récupère dans un premier temps certains fichiers prédéfinis du dossier .git, et les utilise pour trouver d’autres fichiers. Pour les curieux, une description des fichiers et dossiers d’un repository est disponible sur le site officiel de Git.

Bien sûr, cela ne permet pas de récupérer l’ensemble des fichiers du dossier .git. Si le dossier contient des objets compressés (fichiers .git/objects/pack/pack-xxx.pack) mais pas de listing de ces derniers (fichier .git/objects/info/packs) alors ceux-ci ne seront pas récupérés, et certaines sources seront manquantes.

A des fins de test, notez que l’on peut forcer la création du listing des objets compressés sur le site testé avec la commande :

git update-server-info

Le Dumper étant un script shell, il est facile de le personnaliser pour rajouter d’autres fichiers à télécharger. Par défaut, il ne travaille qu’avec la branche master, mais en modifiant le script on peut en rajouter d’autres (par exemple si .git/HEAD pointe vers une branche différente) :

function start_download() {
    #Add initial/static git files
    QUEUE+=('HEAD')
    # ...
    QUEUE+=('refs/heads/master')
    QUEUE+=('refs/heads/mabranche')
    # ...
    QUEUE+=('logs/refs/heads/master')
    QUEUE+=('logs/refs/heads/mabranche')
    # ...
}

3a) Récupérer les sources d’un dossier .git

Une fois le contenu du dossier .git en notre possession, nous pouvons l’utiliser pour récupérer les codes sources du site. Si la commande suivante se termine sans erreur, on peut considérer que le dossier est propre et que nous pourrons récupérer l’intégralité du code. Dans le cas contraire, il faudra s’attendre à des fichiers manquants.

# Test de l'intégrité du dossier .git
cd ~/sitedump
git fsck
Commande git fsck pour tester l'intégrité d'un dossier .git

Pour restaurer les sources à partir de là c’est facile, Git sait le faire tout seul via la commande git checkout :

# Restauration des sources depuis un dossier propre
cd ~/sitedump
git checkout -- .

# Lister les fichiers
ls -al
Récupération des sources d'un dossier .git

3b) Récupérer les sources quand Git n’y arrive pas

Si le dossier .git est cassé (incomplet), alors Git fera de son mieux mais ne restaurera que partiellement les sources. Cela se traduira par des fichiers manquants et des messages d’erreur lors de l’exécution des commandes de la section précédente :

Erreurs lors d'un git checkout à partir d'un dossier .git incomplet

Dans le cas où Git n’y arrive vraiment pas, l’outil Extractor présent dans les GitTools vus précédemment peut dépanner. Il n’est pas capable de récupérer les objets manquants (en général les fichiers pack-xxx.pack) mais peut tout de même restaurer les fichiers déjà en notre possession si Git refuse de faire le checkout.

# Création du dossier d'extraction
mkdir ~/sitedump_extract

# Extraction
cd ~/GitTools-master/Extractor
chmod u+x extractor.sh
./extractor.sh ~/sitedump ~/sitedump_extract

# Le contenu est dans des sous-dossiers de ~/sitedump_extract/
cd ~/sitedump_extract
find .

L’outil Extractor extrait les fichiers de chaque commit dans un dossier séparé (un dossier par commit), description du commit incluse. Cela rend l’exploitation plus compliquée, mais pas impossible. Si le site est basé sur un framework connu, le pirate sait déjà quels sont les fichiers sensibles à trouver, où est le code personnalisé (thème enfant, plugin maison…), et n’a qu’à faire une recherche sur l’ensemble des dossiers de tous les commits pour les trouver.

Extraction des sources d'un dossier .git avec GitTools Extractor

4) Que faire avec les sources et le dossier .git

Que risque t’on si un hacker récupère le dossier .git de son site web ? Sur le moment pas grand chose (à part une charge serveur plus élevée vu que le pirate doit télécharger de nombreux fichiers). C’est cependant une très mauvaise idée de pas corriger cette faille de sécurité, car elle permet d’autres attaques.

Tout d’abord, considérons ce que peut faire un pirate avec uniquement le dossier .git en sa possession (sans les sources).

🐞  Récupérer les informations des développeurs (nom, prénom, adresse email) contenues dans les journaux des commits git log. C’est un vecteur de spam au mieux, et une porte ouverte à l’ingénierie sociale au pire.

🐞  Récupérer l’adresse d’un repository distant avec des identifiants et mots de passe en clair est parfois possible à partir du fichier .git/config. Dans ce cas le pirate peut se connecter et télécharger tout ce qu’il contient, voir carrément altérer les sources avec son propre code.

Si le hacker parvient à restaurer les sources, alors il peut aller plus loin encore.

🐞  Trouver les accès à la base de données. Si la base de données est accessible à distance, il pourra s’en servir pour récupérer toutes les données du site (emails des utilisateurs, messages personnels…).

🐞  Trouver les identifiants et mots de passe d’administration. Il pourra ensuite se connecter en tant qu’administrateur sur le site.

🐞  Trouver les urls secrètes (ex : http://example.com/_admin_123/) et accéder à des contenus non-autorisés.

🐞  Trouver les limites des algorithmes utilisés sur le site, pour les exploiter à sa convenance (« mais d’où vient cette commande de 3 articles à zéro euros ? »)

🐞  Trouver les failles qui permettront d’insérer son propre code sur le site (deface, minage de cryptos, optimisation frauduleuse du référencement…)

🐞  Les vendre à qui voudra s’en servir (entreprise concurrente, réseaux de bots, agences de renseignement…)

Sécuriser son site contre l’exploitation de dossier .git

Masquer le dossier .git avec Apache

L’action la plus rapide à entreprendre si votre site internet est concerné est de bloquer l’accès au dossier .git pour les visiteurs. Il est possible de tout simplement supprimer le dossier (le site fonctionnera toujours), mais selon votre workflow la prochaine mise en production pourrait poser quelques problèmes !

Il est préférable de configurer son serveur correctement afin d’interdire l’accès au dossier. La configuration exacte à rentrer dépendra de l’hébergeur et du serveur lui-même, mais même chez la plupart des hébergeurs mutualisés vous pouvez placer un fichier htaccess à la racine du site, avec le code suivant (serveur Apache uniquement) :

# BEGIN Protection git
RedirectMatch 404 "/\.git$"
RedirectMatch 404 "/\.git/"
RedirectMatch 404 "/\.gitignore$"
RedirectMatch 404 "/\.gitmodules$"
# END Protection git

Les visiteurs tentant d’accéder aux fichiers ne trouveront que des erreurs 404, masquant complètement l’utilisation de Git pour la gestion des sources du site. Si vous n’avez pas la possibilité de faire la modification vous même, il faudra faire la demande à votre hébergeur.

Désactiver l’indexation Apache

Si l’indexation est activée pour les dossiers de votre site, vous devriez la désactiver, car elle est une faille de sécurité à elle-seule. Evidemment, si elle est importante pour vous (ex : vous hébergez un service de téléchargement de fichiers qui s’en sert) ne la désactivez pas, et passez à la section suivante.

Certains hébergeurs permettent de désactiver l’indexation directement depuis leur interface d’administration. Je vous recommande donc de lire la documentation qu’ils mettent à votre disposition avant de faire l’opération manuellement.

Pour désactiver manuellement l’indexation des dossiers sous Apache, placez le code suivant dans le fichier htaccess à la racine de votre site :

# BEGIN No indexing
Options -Indexes
# END No indexing

Aller plus loin : bonnes pratiques

Il serait dommage de finir sans rappeler quelques bonnes pratiques en matière de développement web.

✔︎  Ne placer dans le dossier du site accessible sur le web que des fichiers utiles aux visiteurs. Les scripts, les outils internes ne doivent pas pouvoir être contactés depuis un navigateur web. Masquer le dossier .git n’est qu’une rustine, une solution plus élégante aurait été de le déplacer dans un dossier isolé du web (mais cela impacte le workflow, ce qui sort du cadre de cet article).

✔︎  Ne pas ajouter au système de contrôle de version de fichier contenant des identifiants et des mots de passe. On peut cependant ajouter des fichiers contenant des données d’exemple.

✔︎  S’il faut absolument ajouter au repository un fichier contenant un mot de passe, alors il est préférable de revoir le code pour qu’il utilise des hash et des salts, et de remplacer le mot de passe par un couple hash + salt.

✔︎  Ne pas inscrire l’identifiant et le mot de passe d’accès au repository dans le .git/config .

✔︎  Si git pull doit être utilisé sur le serveur de production, alors utiliser un identifiant dédié, facile à changer en cas de fuite. Idéalement, cet identifiant ne devrait pas avoir la possibilité d’écrire sur le repository distant. Faire des corrections de bug sur le serveur de production et les pousser ensuite sur le repository distant avec git push est non-recommandé et dangereux.

Conclusion

Git est un outil formidable, mais il faut s’en servir correctement, sans quoi il peut être un risque pour la sécurité. S’il est pratique de pouvoir faire un passage en production avec un simple git pull, ou d’effectuer ses corrections de bug directement sur la production et de les remonter avec git push, ce n’est pas recommandable en matière de sécurité.

Bon code à vous, à bientôt.

Références

GIT-SCM – Layout d’un repository git
Internetwache – GitTools (Github)
Internetwache – Article concernant les GitTools
Apache HTTPD – Documentation mod_alias

Photo de profil de Loïc Burtin Code Colibri développeur web à Dijon

A propos de l'auteur

Loïc Burtin

Développeur web indépendant, avec une tendance à couper les plumes en quatre pour que les sites se chargent plus rapidement.

Partager cet article :

Lire aussi

Compression deflate gzip du tracker gratuit Matomo Analytics
Apache
Mise en cache du tracker gratuit Matomo Analytics
Apache
apache server support images webp
Apache
Inscription à la newsletter Inscription à la newsletter

Ce sujet vous intéresse ?

Inscrivez-vous à la newsletter pour être informé de la publication des nouveaux articles !

Ce formulaire est protégé par hCaptcha, dont la Politique de Confidentialité et les Conditions d'Utilisation s'appliquent.

Chargement en cours
Succès de l'opération