CVE-2025-68620 in Server
Riassunto
di VulDB • 19/07/2026
Signal K Server è un'applicazione server che viene eseguita su un hub centrale a bordo di una nave. Le versioni precedenti alla 2.19.0 espongono due funzionalità che possono essere concatenate per rubare i token di autenticazione JWT senza alcuna previa autenticazione. L'attacco combina l'enumerazione delle richieste basata su WebSocket con il polling non autenticato dello stato delle richieste di accesso.
La prima vulnerabilità è l'**Enumerazione Non Autenticata delle Richieste WebSocket**: quando un client WebSocket si connette all'endpoint del flusso SignalK utilizzando il parametro query `serverevents=all`, il server invia tutti gli eventi memorizzati nella cache, inclusi gli eventi `ACCESS_REQUEST` che contengono dettagli sulle richieste di accesso in sospeso. La funzione `startServerEvents` itera su `app.lastServerEvents` e scrive ogni evento memorizzato nella cache su qualsiasi client connesso senza verificare il livello di autorizzazione. Poiché le connessioni WebSocket sono consentite per gli utenti solo lettura (che includono gli utenti non autenticati quando `allow_readonly` è impostato su true), gli attaccanti ricevono questi eventi contenenti ID delle richieste, identificatori del client, descrizioni, permessi richiesti e indirizzi IP.
La seconda vulnerabilità è il **Token Polling Non Autenticato**: l'endpoint dello stato della richiesta di accesso all'indirizzo `/signalk/v1/access/requests/:id` restituisce lo stato completo di una richiesta di accesso senza richiedere autenticazione. Quando un amministratore approva una richiesta, la risposta include il token JWT emesso in chiaro. La funzione `queryRequest` restituisce l'oggetto della richiesta completo, incluso il campo del token, e l'endpoint REST utilizza l'autenticazione solo lettura, consentendo l'accesso non autenticato.
Un attaccante ha due percorsi per sfruttare queste vulnerabilità. Il primo consiste nel creare una propria richiesta di accesso (utilizzando la vulnerabilità di spoofing IP per elaborare una richiesta falsificata convincente), quindi effettuare il polling del proprio ID di richiesta fino a quando un amministratore non la approva, ricevendo così il token JWT. Il secondo percorso prevede che l'attaccante monitori passivamente lo stream WebSocket per scoprire gli ID delle richieste da dispositivi legittimi, effettui poi il polling di tali ID e rubi i token JWT una volta approvati dagli amministratori, dirottando le credenziali dei dispositivi legittimi. Entrambi i percorsi richiedono zero autenticazione e consentono un completo bypass dell'autenticazione. La versione 2.19.0 risolve le problematiche alla base.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.