
CVE-2025-8517: Session Fixation in Vvveb CMS v1.0.6.1
Author: Andrew Paul
Date of Discovery: 9 giugno 2025
Vendor: Vvveb
Vendor URL: http://vvveb.com
Vendor GitHub: https://github.com/givanz/Vvveb
Affected Version: 1.0.6.1 (e probabilmente versioni precedenti)
CVE ID: CVE-2025-8517
È stata scoperta una vulnerabilità di Session Fixation, classificata come CWE-384: Session Fixation, nel meccanismo di autenticazione di Vvveb CMS versione 1.0.6.1. Il sistema non crea né impone un nuovo identificativo di sessione dopo un login riuscito. Questo difetto fondamentale consente due varianti di attacco: un attacco standard di Session Fixation che utilizza un ID di sessione emesso dal server, e un attacco più grave in cui un attaccante può inventare una stringa arbitraria da usare come ID di sessione. In entrambi i casi, la vulnerabilità può essere sfruttata per dirottare la sessione autenticata di un utente, portando alla completa compromissione dell'account.
Questa vulnerabilità corrisponde a diverse categorie della OWASP Top 10 2021:
A01:2021 - Broken Access Control: L'impatto finale dell'attacco è un completo fallimento del controllo degli accessi, poiché l'attaccante ottiene tutti i permessi e i diritti di accesso dell'account utente dirottato.
A04:2021 - Insecure Design: Il processo di autenticazione è insicuro by design perché manca di un controllo di sicurezza fondamentale: la rigenerazione dei token di sessione al variare del livello di privilegio.
A07:2021 - Identification and Authentication Failures: L'applicazione non riesce a gestire correttamente il ciclo di vita degli identificativi di sessione dopo il login, consentendo a un attaccante di fissare una sessione e impersonare un utente.
La causa principale di questa vulnerabilità è la completa incapacità di gestire in modo sicuro lo stato della sessione durante il processo di autenticazione. Ciò si manifesta in due difetti distinti ma correlati:
Mancata rigenerazione degli ID di sessione legittimi: L'applicazione non genera un nuovo PHPSESSID dopo un login valido. Ciò consente a un attaccante di visitare la pagina di login, ottenere un ID di sessione legittimo pre-autenticazione, fissarlo nel browser della vittima e successivamente utilizzare lo stesso ID per dirottare la sessione.
Accettazione di ID di sessione arbitrari: Ancora più critico, il meccanismo di sessione dell'applicazione si fida ciecamente degli identificativi forniti dal client. Un attaccante non ha bisogno di un ID di sessione reale dal server; può inventare una qualsiasi stringa arbitraria (ad esempio 'hacked'), che il server accetterà e poi eleverà a sessione autenticata al momento del login. Questo elimina un passaggio per l'attaccante e sottolinea la profonda natura del difetto.
Questa vulnerabilità può essere sfruttata attraverso qualsiasi vettore che consenta a un attaccante di impostare o "fissare" un cookie nel browser della vittima. I vettori comuni includono:
Cross-Site Scripting (XSS): Un difetto XSS separato potrebbe consentire lo sfruttamento remoto.
Accesso fisico (postazione di lavoro condivisa): Un attaccante può impostare manualmente il cookie su un computer condiviso.
Man-in-the-Middle (MitM): Un attaccante su una rete non sicura potrebbe intercettare il traffico per inserire il cookie.
Questa PoC dimostra la completa compromissione di un account amministratore da una macchina separata, evidenziando il percorso di attacco più grave tramite un identificativo inventato dall'attaccante.
Passaggi:
L'attaccante inventa un identificativo: L'attaccante sceglie una stringa arbitraria come identificativo di sessione, ad esempio: session-hijacked-by-andy.
L'attaccante inserisce il cookie: Sulla macchina della vittima, l'attaccante usa gli strumenti per sviluppatori del browser per impostare il cookie PHPSESSID su session-hijacked-by-andy per il dominio di Vvveb CMS.
La vittima (amministratore) accede: La vittima, usando lo stesso browser, accede a Vvveb CMS con le proprie credenziali di amministratore.
Errore del sistema: Il CMS valida le credenziali della vittima ma non genera un nuovo cookie di sessione. Al contrario, promuove il cookie dell'attaccante (session-hijacked-by-andy) a sessione amministratore completamente autenticata.
L'attaccante dirotta la sessione: Da un computer separato, l'attaccante imposta il cookie PHPSESSID del proprio browser su session-hijacked-by-andy e naviga alla dashboard amministrativa di Vvveb CMS.
Risultato: All'attaccante viene concesso un accesso amministrativo immediato e completo al CMS senza bisogno della password della vittima.
Uno sfruttamento riuscito comporta la compromissione totale dell'account dell'utente preso di mira. Se la vittima è un amministratore, l'impatto è critico e include:
Controllo amministrativo completo: L'attaccante ottiene il pieno controllo del CMS, equivalente a quello dell'amministratore dirottato.
Compromissione dei dati: Piena capacità di leggere, modificare, esportare o eliminare tutti i contenuti del sito, i dati degli utenti e i dettagli di configurazione sensibili.
Persistenza nel sistema: L'attaccante può creare un nuovo utente con pieni privilegi di amministratore. Questo fornisce una backdoor persistente nel sistema, anche dopo la scadenza della sessione dirottata originale o il logout dell'amministratore legittimo.
Ulteriori attacchi: L'account amministratore compromesso può essere utilizzato per caricare file dannosi (ad esempio web shell) o lanciare ulteriori attacchi contro il server sottostante e i suoi visitatori.
L'applicazione deve rigenerare l'identificativo di sessione a ogni variazione del livello di privilegio, in particolare in corrispondenza dell'autenticazione dell'utente. L'implementazione standard in PHP consiste nel chiamare session_regenerate_id(true); immediatamente dopo aver validato le credenziali dell'utente e prima di concedere l'accesso alla parte autenticata dell'applicazione.
Data di scoperta: 9 giugno 2025
Data di notifica al venditore: 10 giugno 2025
Data di conferma da parte del venditore: 16 giugno 2025
Data di rilascio della patch: 17 giugno 2025
Data di divulgazione pubblica: 26 luglio 2025