Audit GLPI - Recherche vulnérabilités GLPwnMe

Comment auditer la sécurité d’un serveur GLPI ?

13/05/2025 Mickael Dorigny 1 commentaire Cybersécurité, GLPI

Sommaire

I. Présentation
II. Sécuriser GLPI : pourquoi est-ce important ?
III. GLPwnMe : audit et exploitation de GLPI
IV. Sécurisation de GLPI: pour aller plus loin
V. Conclusion

I. Présentation

Dans cet article, nous allons voir comment contrôler la sécurité de l'application web GLPI, nous utiliserons pour cela un outil d’audit dédié et rappellerons les bonnes pratiques.

GLPI, qui signifie Gestionnaire Libre de Parc Informatique, est un outil français de ticketing et d’inventaire du SI très utilisé dans les entreprises. II s’agit d’une solution open-source, existante depuis de nombreuses années et reposant sur une interface web PHP et une base de donnée SQL.

Sa présence quasi systématique au sein des systèmes d’information en fait une cible de choix pour les attaquants, d’autant plus que de nombreuses CVE sont régulièrement publiées le concernant :

L’objectif de cet article est de vous présenter un outil open-source qui vous permettra d’auditer simplement et régulièrement vos instances GLPI : glpwnme.

Attention : Certaines des techniques et des outils présentés dans cet article peuvent avoir un comportement offensif, soyez sûrs de savoir les utiliser pour éviter tout effet de bord indésirable.

II. Sécuriser GLPI : pourquoi est-ce important ?

GLPI est un composant central du système d’information pour sa gestion et le suivi des incidents/tickets utilisateur. Il s’agit du point de rencontre entre le support, les utilisateurs et les gestionnaires du SI. Ces différents usages mènent souvent GLPI à stocker des informations qui ont une grande valeur pour un attaquant.

En effet, les tickets utilisateurs, souvent sous forme d’échanges textuels, peuvent contenir des informations techniques sur le SI, des logins et même des mots de passe ou autres secrets d’authentification. Également, ces tickets peuvent contenir des pièces jointes pouvant intéresser l’attaquant dans sa phase de collecte d’informations et d’identifiants.

GLPI est aussi utilisé pour maintenir l’inventaire du système d’information. Un attaquant qui compromet GLPI aura accès à des informations telles que la liste des réseaux, les noms et IP des serveurs, des postes de travail, mais aussi les noms et versions des logiciels installés, etc. Ces informations permettent à l’attaquant d’avoir une cartographie sans efforts et en réduisant les chances de se faire détecter lors de son opération.

Les paramètres de configuration de GLPI contiennent aussi des informations sensibles, celui-ci étant souvent relié à l’Active Directory pour l’authentification ou à un compte mail pour l’envoi d’informations aux utilisateurs. La compromission de GLPI permet à l’attaquant de mettre la main sur ces informations, et souvent, d’obtenir un premier accès authentifié à l’Active Directory.

Enfin, GLPI est utilisé par presque tous les utilisateurs du SI, que ce soit pour déclarer un incident ou le résoudre. Le fait de compromettre GLPI permet donc à l’attaquant d’y insérer du code piégé en impactant le plus d’utilisateurs possible.

Pour ces différentes raisons, il est important de sécuriser son application GLPI et de régulièrement auditer les différents éléments et composants que nous allons voir ici.

III. GLPwnMe : audit et exploitation de GLPI

A. Présentation de GLPwnMe

Glpwnme est un outil open-source écrit en Python, il est proposé et maintenu par les équipes d’Orange Cyberdéfense. Cet outil est souvent mis à jour et propose différentes options pour auditer et exploiter les vulnérabilités d’une instance GLPI.

Ainsi, il peut être utilisé aussi bien par des auditeurs cybersécurité dans le cadre d’un test d’intrusion (pentest), par des attaquants réels ou par des administrateurs système et équipes de sécurité internes qui effectuent un contrôle régulier de leurs instances.

Sur un système Linux disposant de Python et de pipx, glpwnme peut être déployé via la commande suivante :

# Installation de glpwnme via pipx
pipx install git+https://github.com/Orange-Cyberdefense/glpwnme

Voici le retour attendu si tout se passe bien :

Installation réussie de glpwnme via pipx.

Pour en savoir plus sur pipx, je vous invite à consulter cet article :

IT-Connect - Pip vs pipx : comprendre leurs différences pour mieux gérer vos projets Python

B. Déploiement d’un GLPI vulnérable avec Docker

Pour tester glpwnme, je vous conseille dans un premier temps d’utiliser un lab. Une fois que vous maitriserez l’outil (ce qui se fait assez vite), vous pourrez passer à des instances GLPI de production.

Assurez-vous d’avoir toutes les autorisations nécessaires avant d’auditer ou tenter de compromettre un service GLPI, même s’il s’agit de celui de votre entreprise. Toute tentative d’exploitation peut avoir des effets de bords et entrainer des alertes de sécurité sérieuses. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

Pour la démonstration, j’ai déployé un GLPI dans une version vulnérable via Docker à l’aide du fichier docker-compose.yml suivant. Il a été récupéré ici et légèrement modifié :

version: "3.8"
services:

# MariaDB Container
  mariadb:
    image: mariadb:10.7
    container_name: mariadb
    hostname: mariadb
    environment:
     - MARIADB_ROOT_PASSWORD=password
     - MARIADB_DATABASE=glpidb
     - MARIADB_USER=glpi_user
     - MARIADB_PASSWORD=glpi
    ports:
     - "3306:3306"

# GLPI Container
  glpi:
    image: diouxx/glpi
    container_name : glpi
    hostname: glpi
    environment:
       - VERSION_GLPI=10.0.10
    ports:
       - "8008:80"

Cette configuration déploie un conteneur MariaDB et un GLPI en version 10.0.10, qui date de septembre 2023 et est concerné par plusieurs vulnérabilités connues. Une fois le fichier docker-compose.yml sur votre système de fichier, le déploiement se fait via la commande suivante :

docker compose up -d

Voici une vue classique d'un déploiement via docker-compose :

Déploiement d'un GLPI vulnérable via Docker.

Il faut ensuite se rendre sur l’URL de GLPI (http://127.0.0.1:8008/) pour effectuer le paramétrage initial et renseigner les identifiants de base de données après cliqué sur OK, Continuer, Installer, Continuer :

Configuration de la base de données lors du déploiement de GLPI.

Il suffit ensuite de sélectionner glpidb lors du choix de la base de données à créer, puis sur Continuer jusqu’à tomber sur la page de login habituelle de GLPI.

C. Utilisation de GLPwnMe pour vérifier la sécurité de GLPI

Il est maintenant temps d’apprendre à utiliser glpwnme afin d’auditer le serveur GLPI. Commençons par regarder sur le dépôt Github du projet les différentes CVE qui sont prises en charge par l’outil :

Liste des CVE prises en charge par glpwnme (début 2025).

Ce tableau est important, puisque si vous connaissez la version de votre instance GLPI, vous pouvez déjà savoir si elle est concernée par des vulnérabilités connues (colonne Vulnerable versions). Pour chaque CVE, vous pouvez aussi savoir si elle est exploitable sans authentification ou à partir d’un certain niveau de droit. Enfin, le score CVSS vous indiquera s’il s’agit d’une vulnérabilité impactante et/ou facile à exploiter ou non.

Vérifier la présence de CVE

Nous allons rapidement retrouver ce tableau dans le résultat d’exécution de l’outil. Sans plus attendre, commençons par effectuer une vérification des CVE présentes sur notre instance de test via glpwnme :

# Exécution d'un scan complet et safe
glpwnme -t http://127.0.01:8008 --check-all

Sur cette version spécifique (10.0.10), nous avons déjà pas mal d’informations en retour (Cliquez sur l'image pour zoomer) :

Retour d'un scan --check-all de glpwnme.

On retrouve l’identification de la version, du système d’exploitation, du répertoire d’installation (ce qui fait déjà beaucoup sans être authentifié). Ensuite, nous avons les résultats des checks qu’il a été possible de réaliser. Avec la seule option que nous avons fournie, cela concerne :

Les vérifications opsec.
Les CVE identifiées à partir de la version récupérée ;
Les checks réalisables sans identifiants (CVE en Unauthenticated).

La notion d’opsec (Operationnal Security) est ici importante, l’outil ayant été créé par des auditeurs, il est possible de l’utiliser en toute sécurité dans son comportement par défaut. Ainsi, l’exploitation effective de vulnérabilité ou la réalisation d’opérations pouvant avoir des effets de bords passe forcément par une option précise, que l’on ne doit pas utiliser sans connaissance de cause. Sans ces options explicites (options par défaut), nous sommes donc sûrs qu'aucun effet de bord n'est à attendre.

Suite à ces différentes informations, nous avons un résumé des CVE affectant la version scannée. On retrouve ici le tableau renseignant le nom de la CVE, son auteur, le score CVSS, la version, l’impact (injection SQL, exécution de commande, élévation de privilège, etc.) et enfin le privilège requis et les options d’exploitation.

Les CVE concernant GLPI sont très différentes et chacune peut nécessiter des options différentes pour être exploitée. Nous allons voir ça par la suite.

Ici, pas de doute, nous avons affaire à une instance GLPI vulnérable, qui peut être compromise à tout moment par un attaquant y ayant accès via le réseau.

Rechercher les identifiants par défaut

Nous allons à présent aller un peu plus loin dans nos actions et vérifier la présence d’identifiants par défaut sur l’instance ciblée.

Cette opération est déjà considérée comme “non opsec”, car tenter de s’authentifier avec un ou plusieurs mauvais mots de passe peut avoir des impacts comme la levée d’une alerte ou le blocage du compte.

# Vérifier la présence d'identifiants GLPI par défaut
$ glpwnme -t http://127.0.0.1:8008 --run --exploit DEFAULT_PASSWORD_CHECK

[+] Version of glpi is >= 10.0.8
[+] Version of glpi found: 10.0.10
[+] Operating system found: Unix
[+] GLPI root dir found: /var/www/html/glpi
[+] GLPI API is disable
[+] Inventory is disable
[+] Authentication successfull for glpi:glpi
[+] Authentication successfull for tech:tech
[+] Authentication successfull for normal:normal
[+] Authentication successfull for post-only:postonly

Plutôt que --check, j’ai utilisé l’option --run, suivi de l’option -e et du nom de l’exploit à exécuter (DEFAULT_PASSWORD_CHECK). Ici, il n’est pas lié à une CVE mais aux mots de passe par défaut configurés à l’installation de toute instance GLPI (et qu’il convient donc de modifier systématiquement).

Le résultat est assez clair, les comptes glpi, tech, normal et post-only ont un mot de passe par défaut, qu’un attaquant pourra donc aisément trouver et exploiter. Le message Authentication successfull indique que ces comptes sont valides et actifs.

Effectuer un audit authentifié

Pour aller plus loin et notamment vérifier la présence de CVE qui sont exploitables uniquement en mode authentifié (à partir d’un compte valide), nous utiliserons les options -u (username) et -p (password) :

# Réalisation d'un audit authentifié via glpwnme
glpwnme -t http://127.0.01:8008 --check-all -u glpi -p glpi

Pour cette version de GLPI, le résultat sera sensiblement le même. Mais, il faut garder en tête que certaines CVE ne peuvent être vérifiées ou exploitées qu’à partir d’un compte avec un certain niveau de privilège.

En conditions réelles, l’attaquant ayant identifié une telle vulnérabilité cherchera à compromettre un compte par différents moyens jusqu’à obtenir le niveau de privilège requis, et exploitera ensuite la CVE.

Effectuer un audit non opsec

Par “non opsec”, j’entends que certaines des vérifications effectuées peuvent avoir un impact sur votre instance GLPI. Cet impact peut être le dépôt d’un fichier contenant du code, la création d’un nouvel utilisateur, etc. Certains exploits peuvent entrainer la modification de paramètres de sécurité ou le changement d’un mot de passe. Lisez attentivement la documentation.

Il faut savoir que toutes les vulnérabilités ne peuvent être vérifiées de façon “safe”. Par exemple, pour vérifier que le dépôt de fichier malveillant est autorisé, il faut tout simplement tenter de déposer le fichier et constater que cela a fonctionné. Auquel cas, on laisse forcément une trace ou une modification sur le système audité.

Pour réaliser ces vérifications, il faut utiliser l’option --no-opsec :

# Sans authentification
glpwnme -t http://127.0.01:8008 --check-all --no-opsec

# Avec un compte admin
glpwnme -t http://127.0.01:8008 --check-all -u glpi -p glpi --no-opsec

Avec cette option, vous remarquerez que les résultats sont plus précis. Pour le scan en version non authentifié, glpwnme a de lui-même effectué la vérification des identifiants par défaut :

Audit non opsec de GLPI via glpwnme, sans identifiants.

Certaines vulnérabilités sont toujours marquées en orange, ce qui indique une vulnérabilité potentielle, mais non vérifiée. L’utilisation des identifiants permet d’aller plus loin encore, en vérifiant la présence de vulnérabilités exploitables qu’à partir d’un compte valide :

Audit non opsec de GLPI via glpwnme, avec identifiants.

Ici, aucun doute n’est possible, notre instance est bien vulnérable aux CVE 2024-29889, 2024-37148 et 2024-40638, en plus d’avoir des identifiants par défaut. Pour les autres CVE, leur présence reste une éventualité non vérifiée (mais fortement probable), généralement une déduction à partir du numéro de version. Le tableau qui suit permet d’en savoir plus sur ces vulnérabilités.

Enfin, pour avoir des détails très précis sur un exploit avant de l’utiliser, nous pouvons utiliser les options suivantes :

# Afficher la documentation d'un exploit
glpwnme -t http://127.0.0.1:8008 -e <NOM_EXPLOIT> --infos

Voici un exemple :

Ici, nous pouvons obtenir plusieurs informations sur l’exploit, la description, les paramètres attendus, un exemple de sortie et les options possibles.

Pour une utilisation et exploitation sur des instances en production, je vous conseille de systématiquement lire les informations relatives à tout exploit que vous comptez utiliser. Cela permet de s’assurer que vous comprenez ce qu’il va tenter de faire, son impact, etc.

Le PoC (Proof of Concept) et la découverte de cette vulnérabilité sont d’ailleurs détaillés dans un blogpost complet écrit en français par son auteur. En plus du code source dédié à l’exploit de cette vulnérabilité (cve_2024_27937.py), il s’agit d’une lecture obligatoire avant tout exploitation en production :

CVE-2024-27937 - CVE-2024-27930 - Walkthrough

D. Exploiter des CVE via GLPwnMe

Glpwnme peut aussi être utilisé pour exploiter les vulnérabilités identifiées. Il s’agit alors d’effectuer les opérations offensives comme le ferait un attaquant pour extraire des données sensibles, s’implanter de façon durable dans l’application, compromettre des comptes, etc.

Dans le cadre d’une revue classique et régulière de sécurité menée par une équipe interne, l’exploitation active d’une vulnérabilité est rarement nécessaire. Il est recommandé de laisser cette opération à des équipes spécialisées d’audit en cybersécurité, red team, etc. Celles-ci maitrisent leurs actions et sont explicitement autorisées à exploiter des vulnérabilités sur un SI.

Bien, nous savons que notre instance GLPI est vulnérable à plusieurs CVE et nous avons déjà des identifiants pour en exploiter certaines. Nous allons tenter d’exploiter la CVE_2024_27937 sur laquelle nous avons affiché et lu attentivement les informations (--infos).

Cette vulnérabilité permet à n’importe quel utilisateur authentifié de lire n’importe quel champ de la base de données de GLPI, incluant les mots de passe, tickets, inventaires, paramètres d’authentification LDAP, etc.

L’exploitation d’une vulnérabilité passe par l’option --run et -e <NOM_EXPLOIT> comme nous l’avons fait pour la découverte des identifiants par défaut. La revue des paramètres de l’exploit nous indique que toutes les options utilisables (fields, itemtype, page_limit et page) ont une valeur par défaut, et qu’elle s’exploite avec un compte authentifié valide. En conséquence, nous pouvons simplement l’exploiter avec la commande suivante :

# Exploitation de la CVE_2924_27937 via glpwnme
glpwnme -t http://127.0.0.1:8008 --run -e CVE_2024_27937 -u glpi -p glpi

Voici le retour attendu pour une instance vulnérable :

Exploitation de la CVE_2924_27937 via glpwnme

Par défaut, l’exploit va récupérer les secrets d’authentification des comptes GLPI. Comme l’indique la documentation de l’exploit, nous pouvons spécifier via des options passées au paramètre -O le type d’élément à exploiter, ainsi que les champs associés. Dans ce second exemple, j’exfiltre la configuration complète du GLPI :

# Exploitation de la CVE_2924_27937 via glpwnme avec options
$ glpwnme -t http://127.0.0.1:8008 --run -O itemtype='Config' fields='value' -e CVE_2024_27937 -u normal -p normal

[...]
============
add_followup_on_update_ticket;1
admin_email;admsys@localhost
admin_email_name
ajax_limit_count;10
ajax_wildcard;*
allow_search_all;0
allow_search_global;1
allow_search_view;2
attach_ticket_documents_to_mail;0
auto_create_infocoms;0
backcreated;0
cas_host
cas_logout
cas_port;443
cas_uri

Toutes les CVE présentes dans glpwnme sont exploitables au travers l’option --run et leurs paramètres spécifiques. À nouveau, je vous invite à consulter la description précise de chacune pour connaitre leur impact et les options d’exploitation.

IV. Sécurisation de GLPI: pour aller plus loin

L’exécution régulière de l’outil glpwnme peut faire partie des opérations de routines d’une équipe de sécurité interne ou d’un administrateur système. Nous avons vu que par défaut, l’outil n’exploite pas activement de vulnérabilité. Il permet de faire un contrôle basé sur des vérifications non impactantes ou des déductions à partir de la version.

L’outil est très actif et souvent amélioré avec les CVE récentes de GLPI. Pensez à le mettre à jour avant toute nouvelle utilisation, au risque de passer à côté d’une CVE récemment découverte :

# Mise à jour de glpwnme via pipx
$ pipx upgrade glpwnme

glpwnme is already at latest version 0.4.0 (location: /home/mickael/.local/share/pipx/venvs/glpwnme)

Pour aller plus loin concernant la sécurisation de GLPI, je vous rappelle brièvement les recommandations classiques, mais tout à fait valables et efficaces, au sujet de la sécurité de toute application web :

Utilisez le chiffrement des échanges HTTP via TLS ;
Changez les identifiants par défaut suite au déploiement ou la mise à jour de l’application ;
Mettez à jour régulièrement l’application web GLPI, ses dépendances logicielles, ses plugins et le système d’exploitation qui l’héberge ;
Protégez votre instance GLPI à l’aide d’un pare-feu applicatif correctement configuré qui pourra identifier et bloquer les requêtes malveillantes basiques ;
Journalisez les requêtes faites à GLPI et les envoyer vers un SIEM/XDR pour identifier et bloquer au plus tôt les tentatives d’exploitation ;
Sensibilisez les utilisateurs et administrateurs à la robustesse des mots de passe à utiliser, mais aussi sur la sécurité des échanges (transmission des mots de passe en clair dans un ticket) ;
Effectuez une revue régulière des accès, permissions et comptes de l’instance GLPI ;
Supprimez les informations inutiles et obsolètes, notamment les anciens tickets et leurs pièces jointes ;
Effectuez des audits réguliers, internes et par des équipes spécialisées, sur votre SI.
Appliquez les recommandations de l’ANSSI concernant la sécurisation des applications web.

Bien que très communes, l’application de l’ensemble de ces recommandations permet de se protéger contre une bonne partie des attaques.

V. Conclusion

GLPI regorge de fonctionnalités, de paramètres et surtout de plugins qui peuvent chacun amener faiblesses ou durcissements à l’application. Savoir utiliser glpwnme pour réaliser un audit de son instance GLPI est un bon début, mais ne remplace pas la démarche complète et rigoureuse d’un auditeur cybersécurité.

Notamment, ce n’est pas parce que l’outil ne vous remonte rien que votre instance est 100% sécurisée. Mais, cela permet au moins de savoir si des vulnérabilités connues sont à corriger. Il est donc intéressant d’effectuer cette opération régulièrement

L’outil étant souvent mis à jour, comme les vulnérabilités publiques liées à GLPI, n’oubliez pas de mettre à jour l’outil à partir du dépôt Github avant chaque utilisation.