Openvas checkmk unverschlüsselter Agent - Versionsgeschichte

Thomas.will: /* Integration: Docker (greenbone-community-container) */

2026-06-24T03:55:44Z

Integration: Docker (greenbone-community-container)

Thomas.will: /* Integration: Paket- / Source-Installation */

2026-06-24T03:45:08Z

Integration: Paket- / Source-Installation

Thomas.will am 24. Juni 2026 um 03:29 Uhr

2026-06-24T03:29:07Z

Thomas.will: Die Seite wurde neu angelegt: „= Checkmk-Agent unverschlüsselt erkennen = Der Checkmk-Agent lauscht auf TCP 6556. Der Legacy-Agent (xinetd / systemd-socket) gibt seine komplette Ausgabe be…“

2026-06-24T03:27:23Z

Die Seite wurde neu angelegt: „= Checkmk-Agent unverschlüsselt erkennen = Der Checkmk-Agent lauscht auf TCP 6556. Der Legacy-Agent (xinetd / systemd-socket) gibt seine komplette Ausgabe be…“

Neue Seite

= Checkmk-Agent unverschlüsselt erkennen =

Der Checkmk-Agent lauscht auf TCP 6556. Der Legacy-Agent (xinetd / systemd-socket)
gibt seine komplette Ausgabe beim Verbindungsaufbau '''im Klartext''' zurück – jeder
unauthentifizierte Client im Netz liest damit Host- und Systeminformationen aus
(Prozesse, Dienste, Pakete, Pfade). Der moderne Agent-Controller (''cmk-agent-ctl'')
würde stattdessen TLS aushandeln.

Dieser Artikel zeigt dieselbe Erkennung in zwei Scannern: zuerst als nmap-NSE-Skript,
dann als NASL-VT für OpenVAS/Greenbone inklusive Feed-Integration.

Detektions-Primitiv in beiden Fällen: Connect auf 6556, Antwort lesen, auf den
Sektions-Marker <code><<<check_mk>>></code> prüfen.

Testziel im Lab: '''10.0.10.104'''

== Variante 1: nmap (NSE) ==

;Skript anlegen
*vi checkmk-plain.nse
<pre>
description = [[
Checks if an unencrypted Checkmk Agent is responding on port 6556.
If the header <<<check_mk>>> is found, it is considered a potential information disclosure vulnerability.
]]
author = "Thomas"
license = "Same as Nmap--See https://nmap.org/book/man-legal.html"
categories = {"default", "discovery", "vuln"}
portrule = function(host, port)
return port.number == 6556 and port.protocol == "tcp"
end
action = function(host, port)
local socket = nmap.new_socket()
socket:set_timeout(3000)
local status, err = socket:connect(host.ip, port.number)
if not status then
return "Connection failed: " .. err
end
local data
status, data = socket:receive_lines(1)
socket:close()
if status and data and data:find("<<<check_mk>>>") then
return "Unencrypted Checkmk Agent detected - potential information disclosure!"
end
end
</pre>

;Aufruf
*nmap -sV --script ./checkmk-plain.nse -p 6556 10.0.10.104
<pre>
PORT STATE SERVICE VERSION
6556/tcp open check_mk check_mk extension for Nagios 2.0.0p38
|_checkmk-plain: Unencrypted Checkmk Agent detected - potential information disclosure!
</pre>

== Variante 2: OpenVAS / Greenbone (NASL) ==

Greenbone nutzt NASL (Nessus Attack Scripting Language), kein Lua – also wird die
Logik übersetzt, nicht 1:1 portiert. Der Befund läuft über <code>security_message()</code>
und landet durch <code>cvss_base 5.0</code> als ''Medium'' im Report.

;Skript anlegen
*vi checkmk_unencrypted.nasl
<pre>
# checkmk_unencrypted.nasl
# Checkmk-Agent unverschlüsselt auf TCP 6556 (Information Disclosure)

if(description)
{
# WICHTIG: NICHT die .1.0.-Arc verwenden - die gehört Greenbone.
# Eigene Arc für lokale VTs, Nummer nur lokal eindeutig halten.
script_oid("1.3.6.1.4.1.25623.1.7.6556001");
script_version("2026-06-24T00:00:00+0000");
script_tag(name:"creation_date", value:"2026-06-24 08:00:00 +0000 (Tue, 24 Jun 2026)");
script_tag(name:"last_modification", value:"2026-06-24 08:00:00 +0000 (Tue, 24 Jun 2026)");
script_name("Checkmk Agent Unencrypted Information Disclosure (TCP 6556)");
script_category(ACT_GATHER_INFO);
script_family("General");
script_copyright("Copyright (C) 2026 Thomas / Xinux");

script_tag(name:"cvss_base", value:"5.0");
script_tag(name:"cvss_base_vector", value:"AV:N/AC:L/Au:N/C:P/I:N/A:N");
script_tag(name:"qod_type", value:"remote_active");
script_tag(name:"solution_type", value:"Mitigation");

script_tag(name:"summary", value:"Es wird geprüft, ob ein unverschlüsselter
Checkmk-Agent auf TCP 6556 antwortet und seine Ausgabe im Klartext liefert.");
script_tag(name:"vuldetect", value:"Sendet einen TCP-Connect auf 6556 und prüft,
ob die Antwort den Sektions-Marker '<<<check_mk>>>' im Klartext enthält.");
script_tag(name:"insight", value:"Der Legacy-Checkmk-Agent (xinetd/systemd-socket)
gibt beim Verbindungsaufbau die komplette Agent-Ausgabe unverschlüsselt zurück.
Der moderne Agent-Controller (cmk-agent-ctl) würde stattdessen TLS aushandeln.");
script_tag(name:"impact", value:"Jeder unauthentifizierte Netzwerk-Client kann
Host- und Systeminformationen (Prozesse, Dienste, Pakete, Pfade) auslesen.");
script_tag(name:"solution", value:"Agent-Controller mit TLS registrieren
(cmk-agent-ctl register) oder den Zugriff auf 6556 per Firewall auf den
Monitoring-Server beschränken.");

script_require_ports(6556);
exit(0);
}

port = 6556;

if(!get_port_state(port))
exit(0);

soc = open_sock_tcp(port);
if(!soc)
exit(0);

# Checkmk-Agent schickt seine Ausgabe sofort nach Connect - kein Request nötig.
data = recv(socket:soc, length:4096);
close(soc);

if(!data)
exit(0);

if("<<<check_mk>>>" >< data)
{
report = "Ein unverschlüsselter Checkmk-Agent antwortet auf TCP-Port " + port +
" und liefert seine Ausgabe im Klartext (Marker '<<<check_mk>>>' erkannt). " +
"Dies offenbart Host- und Systeminformationen an unauthentifizierte Clients.";
security_message(port:port, data:report);
exit(0);
}

exit(0);
</pre>

== Integration ins Greenbone-Feed ==

=== Syntax prüfen ===

;Vor dem Deployen einmal linten:
*openvas-nasl-lint checkmk_unencrypted.nasl

=== OID-Hinweis ===

Die OID liegt bewusst '''nicht''' in der Arc <code>1.3.6.1.4.1.25623.1.0.</code> – die
gehört Greenbone. Drittskripte nutzen das Schema
<code>1.3.6.1.4.1.25623.1.[contributor].[plugin]</code>. Lokal muss die Nummer nur
eindeutig sein – gegenchecken:
*grep -rn "1.3.6.1.4.1.25623.1.7.6556001" /var/lib/openvas/plugins/

=== Paket- / Source-Installation ===

Plugins liegen im über <code>plugins_folder</code> konfigurierten Verzeichnis
(Standard <code>/var/lib/openvas/plugins</code>). Eigene VTs in einen Unterordner legen:

;Skript ablegen (lesbar für den Scanner-User)
*sudo install -o _gvm -g _gvm -m 0644 checkmk_unencrypted.nasl /var/lib/openvas/plugins/custom/checkmk_unencrypted.nasl
;NVTI-Cache neu aufbauen (scannt den Plugin-Ordner, füllt Redis)
*sudo runuser -u _gvm -- openvas --update-vt-info
;Scanner neu laden
*sudo systemctl restart ospd-openvas

Der Scanner findet die Datei automatisch: er durchsucht das Plugin-Verzeichnis
rekursiv nach <code>.nasl</code>-Dateien, parst die Metadaten im Description-Modus
und cached sie in Redis.

=== Docker-Deployment (greenbone-community-container) ===

Achtung, hier wird's fummelig: das Plugin-Verzeichnis liegt im openvas-Container-Volume,
und <code>greenbone-feed-sync</code> verwaltet genau diesen Bereich. Custom-NASL gehört
deshalb in einen '''separaten, nicht vom Feed-Sync verwalteten''' Unterordner, per
eigenem Volume gemountet, danach Container-Restart:

<pre>
# Beispiel: custom-Ordner ins openvas-Volume mounten (docker-compose.yml)
services:
openvas:
volumes:
- ./custom-vts:/var/lib/openvas/plugins/custom:ro
</pre>

;Danach Cache neu aufbauen und Scanner neu starten:
*docker compose exec -u _gvm openvas openvas --update-vt-info
*docker compose restart openvas ospd-openvas

Nur so überlebt das eigene Plugin die nächsten Feed-Updates.

=== In der GSA verwenden ===

# VT per OID oder Name (''Checkmk Agent Unencrypted...'') suchen – erscheint nach dem Reload.
# Eigene Scan-Config anlegen, VT bzw. Family ''General'' aktivieren.
# Task gegen das Ziel 10.0.10.104 anlegen und starten.
# Befund erscheint als ''Medium'' (Information Disclosure).

== Vergleich ==

;nmap-NSE
*Ad-hoc, lokal, schnell. Lua. Ideal für gezielte Einzelprüfung im Pentest.
;OpenVAS-NASL
*Integriert ins Vulnerability-Management, wiederholbar, scheduled, Befund im Report-Workflow. NASL.

Dasselbe Detektions-Primitiv, zwei Werkzeugketten – die eine für den manuellen Griff,
die andere für kontinuierliches Scanning.

@@ Zeile 120: / Zeile 120: @@
 und cached sie in Redis.
-== Integration: Docker (greenbone-community-container) ==
+== Plugin in der GSA finden ==
-Achtung, hier wird's fummelig: das Plugin-Verzeichnis liegt im openvas-Container-Volume,
+Nach dem Cache-Rebuild und dem ospd-openvas-Neustart taucht die VT in der
-und <code>greenbone-feed-sync</code> verwaltet genau diesen Bereich. Custom-NASL gehört
+Weboberfläche auf. So findest du sie:
-deshalb in einen '''separaten, nicht vom Feed-Sync verwalteten''' Unterordner, per
-eigen
+=== Über die VT-Liste ===

@@ Zeile 109: / Zeile 109: @@
 ;Skript ablegen (lesbar für den Scanner-User)
 *sudo install -o _gvm -g _gvm -m 0644 checkmk_unencrypted.nasl /var/lib/openvas/plugins/custom/checkmk_unencrypted.nasl
 ;NVTI-Cache neu aufbauen (scannt den Plugin-Ordner, füllt Redis)

@@ Zeile 1: / Zeile 1: @@
-= Checkmk-Agent unverschlüsselt erkennen =
+= Checkmk-Agent unverschlüsselt erkennen (OpenVAS / Greenbone) =
 Der Checkmk-Agent lauscht auf TCP 6556. Der Legacy-Agent (xinetd / systemd-socket)
@@ Zeile 7: / Zeile 7: @@
 würde stattdessen TLS aushandeln.
-Dieser Artikel zeigt dieselbe Erkennung in zwei Scannern: zuerst als nmap-NSE-Skript,
+Dieser Artikel zeigt eine eigene NASL-VT, die genau das erkennt, inklusive der
-dann als NASL-VT für OpenVAS/Greenbone inklusive Feed-Integration.
+vollständigen Integration ins Greenbone-Feed.
-Detektions-Primitiv in beiden Fällen: Connect auf 6556, Antwort lesen, auf den
+Detektions-Primitiv: Connect auf 6556, Antwort lesen, auf den Sektions-Marker
-Sektions-Marker <code><<<check_mk>>></code> prüfen.
+<code><<<check_mk>>></code> prüfen.
 Testziel im Lab: '''10.0.10.104'''
-== Variante 1: nmap (NSE) ==
+== Das Skript ==
-;Skript anlegen
+Greenbone nutzt NASL (Nessus Attack Scripting Language). Der Befund läuft über
-*vi checkmk-plain.nse
+<code>security_message()</code> und landet durch <code>cvss_base 5.0</code> als
-<pre>
+''Medium'' im Report.
 ;Skript anlegen
@@ Zeile 129: / Zeile 90: @@
 </pre>
-== Integration ins Greenbone-Feed ==
+== Syntax prüfen ==
 ;Vor dem Deployen einmal linten:
 *openvas-nasl-lint checkmk_unencrypted.nasl
-=== OID-Hinweis ===
+== OID-Hinweis ==
 Die OID liegt bewusst '''nicht''' in der Arc <code>1.3.6.1.4.1.25623.1.0.</code> – die
@@ Zeile 144: / Zeile 103: @@
 *grep -rn "1.3.6.1.4.1.25623.1.7.6556001" /var/lib/openvas/plugins/
-=== Paket- / Source-Installation ===
+== Integration: Paket- / Source-Installation ==
 Plugins liegen im über <code>plugins_folder</code> konfigurierten Verzeichnis
@@ Zeile 160: / Zeile 119: @@
 und cached sie in Redis.
-=== Docker-Deployment (greenbone-community-container) ===
+== Integration: Docker (greenbone-community-container) ==
 Achtung, hier wird's fummelig: das Plugin-Verzeichnis liegt im openvas-Container-Volume,
 und <code>greenbone-feed-sync</code> verwaltet genau diesen Bereich. Custom-NASL gehört
 deshalb in einen '''separaten, nicht vom Feed-Sync verwalteten''' Unterordner, per
-eigenem Volume gemountet, danach Container-Restart:
+eigen