Kener Hidden Monitor Information Disclosure PoC

Dieses Repository enthält einen kleinen Python-Proof-of-Concept zum Testen einer Informationsoffenlegung (CWE-200) in den öffentlichen Monitor-Endpunkten von Kener.

Die betroffenen Kener-Versionen sind 4.0.0 bis 4.1.5, und der Fehler ist in 4.1.6 behoben

https://www.rapid7.com/db/vulnerabilities/cve-2026-105030/

Das Problem steht im Zusammenhang mit tag-basierten Monitor-Lookups, die versteckte oder inaktive Monitore offenlegen können, wenn die Abfrage nicht ordnungsgemäß gefiltert wird.

Dieser PoC ist gedacht für:

• lokale Entwicklungsumgebungen
• autorisierte Sicherheitstests
• die Überprüfung des Patches/Fixes in einer kontrollierten Umgebung

Verwende diesen PoC nicht gegen nicht autorisierte Ziele

Umfang

Dieser PoC demonstriert, dass ein versteckter oder inaktiver Monitor weiterhin von öffentlichen Endpunkten zurückgegeben werden kann, wenn das Lookup keine Filterung wie die folgenden erzwingt:

• status = ACTIVE
• is_hidden = NO

Das korrigierte Verhalten ist, dass diese Endpunkte 404 / keine Übereinstimmung für versteckte oder inaktive Monitore zurückgeben sollten.

Voraussetzungen

• Python 3.9+
• requests-Paket
• Eine lokale oder Testinstanz von Kener
• Zugriff auf die Datenbank zum Erstellen eines Test-Monitors

Abhängigkeiten installieren:

python3 -m pip install requests

Schnellstart

1. Starte deine Kener-App lokal
2. Erstelle einen Test-Monitor, der versteckt und inaktiv ist
3. Führe das PoC-Skript aus
4. Vergleiche das Verhalten mit der korrigierten Version

Einen Test-Monitor erstellen

Wenn du Datenbankzugriff hast, erstelle einen Monitor, der nicht öffentlich sichtbar sein sollte.

Für Postgres:

INSERT INTO monitors (
  tag, name, description, status, is_hidden,
  category_name, monitor_type, cron, default_status,
  created_at, updated_at
) VALUES (
  'internal-secret-monitor',
  'Internal Secret Monitor',
  'Hidden/inactive monitor used for PoC',
  'INACTIVE',
  'YES',
  'Home',
  'HTTP',
  '* * * * *',
  'UP',
  NOW(),
  NOW()
);

Du kannst bei Bedarf auch einen anderen Tag-Namen verwenden.

Stelle sicher, dass der Datensatz Folgendes erfüllt:

• status = 'INACTIVE' oder anderweitig nicht aktiv
• is_hidden = 'YES'

Führe nun das PoC-Skript aus.

Anfällige Version

Wenn die Anwendung anfällig ist, können ein oder mehrere Endpunkte Folgendes zurückgeben:

• HTTP 200
• JSON oder HTML, das anzeigt, dass ein Monitor existiert
• Monitor-Metadaten wie Name, Uptime, Latenz, Status, Zeitstempel

Dies zeigt an, dass der versteckte/inaktive Monitor über eine öffentliche API offengelegt wird.

Korrigierte Version

Mit der ordnungsgemäßen Filterung sollte die Antwort stattdessen Folgendes sein:

• HTTP 404
• oder ein leeres Ergebnis
• oder ein generisches "Monitor not found"

Dies ist das erwartete Verhalten nach dem Fix:

const monitors = await db.getMonitors({
  tag,
  status: GC.ACTIVE,
  is_hidden: GC.NO,
});

Warum das wichtig ist

Das Problem ist nicht bloß die Geheimhaltung des Tags. Das Problem ist, dass ein öffentlicher Endpunkt niemals versteckte oder inaktive Monitor-Daten preisgeben sollte. Wenn ein Angreifer einen Monitor-Tag auf irgendeine Weise erfährt, kann er möglicherweise auf Folgendes zugreifen:

• Uptime-Details
• Latenz-Diagramme
• Wartungsfenster
• Incident-Verlauf
• operative Metadaten

Der Angreifer muss den Tag trotzdem irgendwie finden, durch Raten, durch Brute-Force oder auf andere Weise.

Fehlerbehebung

Endpunkt gibt 404 zurück, obwohl er 200 zurückgeben sollte

Prüfe, dass:

• der Monitor existiert
• der Tag exakt übereinstimmt
• der Monitor wie erwartet versteckt/inaktiv ist

Keine Antwort / Verbindung abgelehnt

Stelle sicher, dass die App lokal läuft und der Port übereinstimmt:

BASE_URL=http://localhost:3000

Die App hat HTTPS aktiviert

Verwende die korrekte URL, zum Beispiel:

BASE_URL=https://localhost:3000

Rechtliche und ethische Nutzung

Verwende diesen PoC nur:

• auf deiner eigenen Testinstanz
• in einer lokalen Entwicklungsumgebung
• auf Systemen, für deren Test du ausdrücklich autorisiert bist

Führe dies nicht ohne Genehmigung gegen externe oder Drittsysteme aus.

Zusammenfassung

Dieser PoC prüft, ob ein versteckter oder inaktiver Monitor-Tag weiterhin über öffentliche Kener-API-Endpunkte zugänglich ist.

• Anfälliges Verhalten: öffentliche API legt versteckte/inaktive Monitor-Daten offen
• Korrigiertes Verhalten: nur aktive, nicht versteckte Monitore werden zurückgegeben
• Ziel: Überprüfung des Sicherheitspatches in einer kontrollierten Umgebung