GLPIScan, un scanner de vulnérabilité pour GLPI !
Qu’est ce que GLPI ?
GLPI est un outil de gestion de parc informatique. Développé par des français, cet outil open source est de nos jours de plus en plus déployé chez nos clients. Lors des tests d’intrusion internes, il est toujours utile de s’intéresser à cet outil puisqu’il gère (quand celui-ci est maintenu à jour…) l’intégralité du parc informatique. Il n’est pas rare non plus, d’y trouver des informations intéressantes dans les commentaires, tels que des logins, des clefs SSH, voire parfois des mots de passe…
Dans cet optique et afin de faciliter (d’accélérer ? 😈 ) la compromission du système d’information de nos clients, nous avons développé un outil permettant de scanner GLPI.
Présentation de l’outil GLPIScan
GLPIScan a donc été développé dans le but de scanner l’application GLPI, plusieurs options sont disponibles, notamment :
- Le test des identifiants par défaut ;
- La présence de fichier par défaut ;
- La liste des plugins installés ;
- Les vulnérabilités affectant GLPI ainsi que les plugins installés.
Les versions de GLPI prises en charge sont les suivantes :
- GLPI > 0.85.4
- GLPI <= 9.4.3
Comment utiliser GLPIScan ?
L’outil, les instructions d’installations, ainsi que les sources sont disponibles sur le github Digitemis à l’adresse suivante :
https://github.com/Digitemis/GLPIScan
Je partage
Derniers articles
Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur
Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !
Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client
Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?