Kener Hidden Monitor Information Disclosure PoC

Questo repository contiene un piccolo proof-of-concept in Python per testare un problema di information disclosure (CWE-200) negli endpoint pubblici dei monitor di Kener.

Le versioni di Kener interessate sono dalla 4.0.0 alla 4.1.5, ed è risolto nella 4.1.6

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

Il problema è associato alle ricerche dei monitor basate su tag che possono esporre monitor nascosti o inattivi quando la query non viene filtrata correttamente.

Questo PoC è destinato a:

• ambienti di sviluppo locale
• test di sicurezza autorizzati
• verificare la patch/fix in un ambiente controllato

Non usare questo poc contro target non autorizzati

Scope

Questo PoC dimostra che un monitor nascosto o inattivo può comunque essere restituito dagli endpoint pubblici quando la ricerca non applica filtri come:

• status = ACTIVE
• is_hidden = NO

Il comportamento corretto è che questi endpoint dovrebbero restituire 404 / nessuna corrispondenza per monitor nascosti o inattivi.

Prerequisiti

• Python 3.9+
• Pacchetto requests
• Un'istanza locale o di test di Kener
• Accesso al database per creare un monitor di test

Installa le dipendenze:

python3 -m pip install requests

Avvio Rapido

1. Avvia la tua app Kener in locale
2. Crea un monitor di test nascosto e inattivo
3. Esegui lo script PoC
4. Confronta il comportamento con la release corretta

Creare un Monitor di Test

Se hai accesso al database, crea un monitor che non dovrebbe essere visibile pubblicamente.

Per 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()
);

Puoi anche usare un nome di tag diverso se necessario.

Assicurati che il record sia:

• status = 'INACTIVE' o comunque non attivo
• is_hidden = 'YES'

Ora esegui lo script PoC.

Build Vulnerabile

Se l'applicazione è vulnerabile, uno o più endpoint potrebbero restituire:

• HTTP 200
• JSON o HTML che indica l'esistenza di un monitor
• metadati del monitor come nome, uptime, latenza, stato, timestamp

Questo indica che il monitor nascosto/inattivo viene esposto tramite un'API pubblica.

Build Corretta

Con il filtro appropriato, la risposta dovrebbe invece essere:

• HTTP 404
• oppure un risultato vuoto
• oppure un generico "Monitor not found"

Questo è il comportamento atteso dopo il fix:

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

Perché È Importante

Il problema non è semplicemente la segretezza del tag. Il problema è che un endpoint pubblico non dovrebbe mai rivelare dati di monitor nascosti o inattivi. Se un attaccante scopre un tag di un monitor in qualsiasi modo, potrebbe riuscire ad accedere a:

• dettagli di uptime
• grafici di latenza
• finestre di manutenzione
• cronologia degli incidenti
• metadati operativi

L'attaccante deve comunque trovare il tag in qualche modo, indovinandolo, con la forza bruta o con altri mezzi.

Risoluzione dei Problemi

L'endpoint restituisce 404 quando dovrebbe restituire 200

Verifica che:

• il monitor esista
• il tag corrisponda esattamente
• il monitor sia nascosto/inattivo come previsto

Nessuna risposta / connessione rifiutata

Assicurati che l'app sia in esecuzione in locale e che la porta corrisponda:

BASE_URL=http://localhost:3000

L'app ha HTTPS abilitato

Usa l'URL corretto, ad esempio:

BASE_URL=https://localhost:3000

Uso Legale ed Etico

Usa questo PoC solo:

• sulla tua istanza di test
• in un ambiente di sviluppo locale
• su sistemi che sei esplicitamente autorizzato a testare

Non eseguirlo contro sistemi esterni o di terze parti senza autorizzazione.

Riepilogo

Questo PoC verifica se un tag di un monitor nascosto o inattivo è ancora accessibile tramite gli endpoint pubblici dell'API di Kener.

• Comportamento vulnerabile: l'API pubblica rivela dati di monitor nascosti/inattivi
• Comportamento corretto: vengono restituiti solo monitor attivi e non nascosti
• Obiettivo: verificare la patch di sicurezza in un ambiente controllato