ntopng: Remote Code Execution über Command-Injection im Schwachstellen-Scan

Jeder authentifizierte ntopng-Nutzer bis zur niedrigsten read-only-Rolle schleust über den ungefilterten scan_ports-Parameter der Schwachstellen-Scan-API Betriebssystembefehle ein und erlangt Codeausführung als Service-Nutzer, auf Bare-Metal-Installationen als root.

Advisory-ID: TP-2026-061
Produkt: ntopng (Open-Source-Werkzeug zur Netzwerkverkehrsüberwachung, C++-Kern mit LuaJIT)
Schwachstellentyp: Einschleusung von Betriebssystembefehlen (CWE-78)
CVE: CVE-2026-82412
CVSS 3.1: 8.8 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Hersteller-Advisory: GHSA-2c6p-4pfj-qv58
Betroffene Versionen: <= 6.7.260716
Behoben in: 6.7.260717
Gemeldet: 4. Juli 2026

Zusammenfassung

ntopng ist ein Open-Source-Werkzeug zur Überwachung von Netzwerkverkehr. Die REST-API des integrierten Schwachstellen-Scans reicht den Parameter scan_ports ungefiltert in eine nmap-Kommandozeile, die über popen() in einer /bin/sh-Shell ausgeführt wird. Das Ziel-Argument wird streng als IP oder CIDR validiert, doch der einzige Filter für scan_ports blockiert nur Leerzeichen und einfaches Anführungszeichen, sodass Shell-Metazeichen und ${IFS} durchkommen. Da die betroffenen Endpunkte keinen Administrator-Check tragen, erreicht jedes authentifizierte Konto bis zur niedrigsten read-only-Rolle den Sink. Das Ergebnis ist die Ausführung beliebiger Betriebssystembefehle als ntopng-Service-Nutzer, auf Bare-Metal-Installationen als root.

Ursache

ntopng hängt den vom Aufrufer gelieferten scan_ports-Wert roh an die nmap-Kommandozeile (command = command .. " -p " .. ports, scripts/lua/modules/vulnerability_scan/vs_utils.lua:2673) und führt den String über ntop.execCmd mit popen() in einer Shell aus (src/Utils.cpp:4444). Das Ziel-Argument host wird per is_valid_nmap_target als IP oder CIDR geprüft, scan_ports jedoch nicht (scripts/lua/modules/vulnerability_scan/vs_utils.lua:2650). Der einzige Filter für scan_ports ist der Lint validateSingleWord, der nur Leerzeichen und einfaches Anführungszeichen sperrt (scripts/lua/modules/http_lint.lua:2422), sodass ; $ { } | & und Backtick überleben und ${IFS} das gesperrte Leerzeichen ersetzt. Beide REST-Endpunkte tragen keinen isAdministrator()-Check (scripts/lua/rest/v2/add/host/to_scan.lua und scripts/lua/rest/v2/exec/host/schedule_vulnerability_scan.lua), sodass jedes authentifizierte Konto bis zur niedrigsten Rolle unprivileged den Sink erreicht. Der eingereihte Scan wird vom Minuten-Hintergrundjob ausgeführt (scripts/callbacks/minute/system/vulnerability_scan.lua), dessen Prozess als Service-Account ntopng läuft, auf typischen Bare-Metal-Installationen als root.

Proof of Concept

GET /lua/rest/v2/add/host/to_scan.lua?host=127.0.0.1&scan_type=tcp_portscan&scan_ports=80;touch${IFS}/tmp/pwned; HTTP/1.1
Cookie: <Session eines unprivileged-Nutzers>

# Der Minuten-Job draint die Warteschlange; innerhalb ~60 s
# entsteht /tmp/pwned, Eigentuemer ntopng (uid 999).

Das gesperrte Leerzeichen wird durch ${IFS} ersetzt, ; beendet den nmap-Aufruf und startet den injizierten Befehl. Beide Endpunkte sind GET ohne CSRF-Token, sodass der Angriff auch als CSRF gegen einen eingeloggten Nutzer ausgelöst werden kann.

Auswirkung

  • Ausführung beliebiger Betriebssystembefehle als ntopng-Service-Nutzer, auf Bare-Metal-Installationen als root.
  • Jedes authentifizierte Konto bis zur niedrigsten read-only-Rolle unprivileged genügt; kein Administrator-Recht nötig.
  • GET-Endpunkte ohne CSRF-Token: auch als CSRF-zu-RCE über einen eingeloggten Nutzer auslösbar.
  • Vollständige Kompromittierung des Monitoring-Hosts, der im Regelbetrieb gespiegelten Netzwerkverkehr sieht.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen