
CVE-2018-10933 - libssh Bypass dell'autenticazione
Implementazione Proof-of-Concept per CVE-2018-10933, una vulnerabilità critica di bypass dell'autenticazione che interessa l'implementazione lato server di libssh.
Disclaimer
Questo repository è fornito esclusivamente a scopo educativo, per la ricerca sulle vulnerabilità e per test di sicurezza autorizzati. Non testare mai sistemi senza autorizzazione esplicita.
CVE-2018-10933 è una vulnerabilità critica di bypass dell'autenticazione scoperta nella macchina a stati lato server di libssh.
A differenza dei difetti di autenticazione tradizionali che coinvolgono password deboli o debolezze crittografiche, questa vulnerabilità esiste perché il server si fida erroneamente di un messaggio di protocollo che dovrebbe essere inviato solo dal server al client.
Un attaccante può quindi convincere un server libssh vulnerabile che l'autenticazione è già stata completata con successo senza fornire alcuna credenziale.
Ciò consente a un attaccante non autenticato di stabilire una sessione SSH autenticata contro applicazioni vulnerabili che utilizzano libssh in modalità server.
| Campo | Valore |
|---|
| CVE | CVE-2018-10933 |
| Gravità | Critica |
| CVSS v3 | 9.1 |
| CWE | CWE-287 (Autenticazione non corretta) |
| Vettore di attacco | Rete |
| Interazione utente | Nessuna |
| Privilegi richiesti | Nessuno |
La vulnerabilità interessa libssh in esecuzione in modalità server.
Le versioni interessate includono:
Le applicazioni che utilizzano libssh esclusivamente come client SSH non sono vulnerabili.
La vulnerabilità ha origine dalla macchina a stati dell'autenticazione implementata nel codice server di libssh.
Durante un normale flusso di autenticazione SSH:
Client ----------------------> Server
SSH_MSG_USERAUTH_REQUEST
|
V
Server validates credentials
|
V
SSH_MSG_USERAUTH_SUCCESS
|
V
Authenticated Session
Il protocollo specifica che SSH_MSG_USERAUTH_SUCCESS viene generato solo dal server dopo un'autenticazione riuscita.
Tuttavia, le versioni vulnerabili di libssh non riescono a validare correttamente l'origine di questo messaggio.
Invece di rifiutare un SSH_MSG_USERAUTH_SUCCESS fornito dal client, il server porta erroneamente il proprio stato di autenticazione interno direttamente a:
Authenticated = TRUE
senza mai verificare le credenziali.
Questo è un classico esempio di autenticazione non corretta (CWE-287).
Client
|
| USERAUTH_REQUEST
|
V
Server
Validate Username
Validate Password
Validate Keys
|
V
USERAUTH_SUCCESS
Authenticated
Attacker
|
| USERAUTH_SUCCESS
|
V
Vulnerable Server
(No validation)
Authenticated
Lo sfruttamento riuscito consente a un attaccante non autenticato di:
L'impatto effettivo dipende da come l'applicazione vulnerabile utilizza libssh dopo l'autenticazione.
La vulnerabilità esiste perché la macchina a stati dell'autenticazione accetta erroneamente il pacchetto:
SSH2_MSG_USERAUTH_SUCCESS
dal client.
Invece di verificare che il pacchetto provenga dal server, libssh aggiorna il proprio stato di sessione interno come se l'autenticazione fosse stata completata con successo.
Poiché i successivi controlli di autorizzazione si basano su questo stato interno, gli attaccanti possono aprire immediatamente canali autenticati.
Questa vulnerabilità non sfrutta:
Invece, sfrutta un difetto logico nella gestione dello stato del protocollo.
L'attaccante necessita di:
Nessuna delle seguenti è richiesta:
I potenziali indicatori includono:
Le firme IDS di rete possono anche identificare pacchetti SSH2_MSG_USERAUTH_SUCCESS anomali inviati dai client.
Aggiornare libssh a una delle versioni corrette:
Se l'aggiornamento non è immediatamente possibile:
Non esiste alcuna soluzione alternativa affidabile oltre all'aggiornamento del software interessato.
Questo repository dimostra come le vulnerabilità della macchina a stati dell'autenticazione possano derivare da errori nell'implementazione del protocollo.
È pensato per assistere:
Il Proof-of-Concept incluso illustra la vulnerabilità in ambienti controllati per migliorare la comprensione dell'implementazione sicura dei protocolli.