Kener Hidden Monitor Information Disclosure PoC

Dieses Repository enthält einen kleinen Python-Proof-of-Concept zum Testen eines Information-Disclosure-Problems (CWE-200) in den öffentlichen Monitor-Endpunkten von Kener. Zum Zeitpunkt der Veröffentlichung wurde kein anderer öffentlicher PoC identifiziert.

Die betroffenen Kener-Versionen sind 4.0.0 bis 4.1.5, und das Problem 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

Verwenden Sie diesen PoC nicht gegen nicht autorisierte Ziele

Geltungsbereich

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

• status = ACTIVE
• is_hidden = NO

Das korrigierte Verhalten besteht darin, dass diese Endpunkte für versteckte oder inaktive Monitore 404 / keine Übereinstimmung 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. Starten Sie Ihre Kener-App lokal
2. Erstellen Sie einen Test-Monitor, der ausgeblendet und inaktiv ist
3. Führen Sie das PoC-Skript aus
4. Vergleichen Sie das Verhalten mit der korrigierten Version

Einen Test-Monitor erstellen

Wenn Sie Datenbankzugriff haben, erstellen Sie 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 auch einen anderen Tag-Namen verwenden, falls nötig.

Stelle sicher, dass der Datensatz:

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

Führe nun das PoC-Skript aus.

Verwundbarer Build

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

• HTTP 200
• JSON oder HTML, das auf die Existenz eines Monitors hinweist
• Monitor-Metadaten wie Name, Uptime, Latenz, Status, Zeitstempel

Dies deutet darauf hin, dass der versteckte/inaktive Monitor über eine öffentliche API offengelegt wird.

Behobener Build

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 der Behebung:

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

Warum das wichtig ist

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

• Uptime-Details
• Latenzdiagramme
• Wartungsfenster
• Vorfallhistorie
• operative Metadaten

Der Angreifer muss das 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
• das 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

Verwenden Sie die korrekte URL, zum Beispiel:

BASE_URL=https://localhost:3000

Rechtmäßige und ethische Nutzung

Verwenden Sie dieses PoC nur:

• auf Ihrer eigenen Testinstanz
• in einer lokalen Entwicklungsumgebung
• auf Systemen, für deren Test Sie ausdrücklich autorisiert sind

Führen Sie es nicht ohne Genehmigung gegen externe oder Systeme Dritter aus.

Zusammenfassung

Dieses PoC prüft, ob ein verstecktes oder inaktives Monitor-Tag über öffentliche Kener-API-Endpunkte weiterhin zugänglich ist.

• Anfälliges Verhalten: Die öffentliche API gibt Daten versteckter/inaktiver Monitore preis
• Behobenes Verhalten: Es werden nur aktive, nicht versteckte Monitore zurückgegeben
• Ziel: Überprüfung des Sicherheits-Patches in einer kontrollierten Umgebung