PoC Python e laboratorio Docker per CVE-2026-61500: recupera lo stato del PRNG di Rejetto HFS V8 per falsificare un cookie di sessione admin e ottenere RCE tramite server_code.
CVE-2026-61500 è una vulnerabilità di falsificazione di sessione non autenticata in Rejetto
HFS dalla versione 3.0.0 alla 3.2.0. HFS generava la chiave di firma del cookie di sessione Koa con
JavaScript Math.random() ed esponeva output dello stesso PRNG V8 durante
l'handshake di login SRP non autenticato. Un attaccante può ricostruire lo stato del PRNG,
recuperare la chiave di firma, falsificare una sessione amministratore e usare la funzionalità
di configurazione documentata server_code per eseguire JavaScript lato server.
Questo repository contiene un proof of concept in Python e un confronto Docker usa-e-getta che utilizza le immagini ufficiali HFS 3.2.0 e 3.2.1. La build di pubblicazione è intenzionalmente limitata a target HTTP sull'interfaccia di loopback locale.
| Affermazione | Stato |
|---|---|
| Recuperare lo stato V8 xorshift128+ dalle risposte di login non autenticato | Confermato |
| Recuperare la chiave di firma del cookie HFS attiva | Confermato |
| Falsificare una sessione accettata come amministratore HFS | Confermato |
Eseguire un marker server_code benigno nell'HFS 3.2.0 ufficiale | Confermato |
| Ricevere una reverse shell root all'interno della rete Compose isolata | Confermato |
| Fermarsi prima della falsificazione di sessione sull'HFS 3.2.1 ufficiale | Confermato |
| Targeting o persistenza su scala Internet | Non fornito né rivendicato |
loginSrp1 non autenticate per l'account noto admin.
Ogni risposta vulnerabile inserisce un loggingIn.sid numerico e il relativo
cookie di sessione firmato negli header Set-Cookie.randomId(30). Il PoC
tiene conto dell'arrotondamento della stringa più corta di V8 e verifica i candidati
contro un HMAC hfs_http.sig osservato, che identifica anche l'offset di avvio.username: admin, quindi chiamare
get_config per dimostrare che il cookie falsificato ha accesso amministratore.set_config con un piccolo modulo server_code. Il payload predefinito
scrive un marker benigno in /data; è disponibile solo per il
laboratorio Docker su loopback.Questa è una catena HTTP black-box: il PoC non legge file, memoria, variabili d'ambiente o stato del processo dal target. La conoscenza del sorgente è usata per modellare l'algoritmo vulnerabile.
59472e534bf7e056d708382d02935c2eaf956927.Il fix sostituisce la chiave di firma con 32 byte da Node.js randomBytes() e
sostituisce l'identificatore di login numerico esposto con randomUUID(). Fornire un
valore esplicito e robusto di COOKIE_SIGN_KEYS mitiga la previsione della chiave di firma, ma
l'aggiornamento rimane la remediation raccomandata.
rejetto/hfs:v3.2.0, digest
sha256:d6765e93b68de222583be7788afad699695fd08aa2f56377337f5139779e0746.rejetto/hfs:v3.2.1, digest
sha256:61db4da1f494df254aa7f48889c676b424b413e45b7b92cf4276f4b8e632aaec.python:3.13-alpine, digest
sha256:1a63a53928ce53d2b0baf08092a703f4840ac5dfbd61fd48802dbf48e08c801e.Entrambi i servizi HFS si legano solo al loopback dell'host; il callback non pubblica alcuna porta.
Il laboratorio crea un amministratore sintetico
perché loginSrp1 deve essere invocato per un username esistente; la
password non è né nota né usata dall'exploit.
I requisiti sono Docker con Compose, Python 3.10 o successivo e curl.
./verify.sh
Il verificatore rimuove solo lab/runtime/vulnerable e lab/runtime/fixed,
avvia entrambe le immagini con digest fissato, esegue i controlli positivi e negativi e
ferma i container per impostazione predefinita. Usare KEEP_LAB=1 ./verify.sh per lasciare il laboratorio
in esecuzione per l'ispezione.
Con il laboratorio mantenuto, l'invocazione diretta del marker benigno è:
python3 cve-2026-61500-poc.py \
--target http://127.0.0.1:28182 \
--marker cve-2026-61500-rce-marker.txt
Per dimostrare l'esecuzione di comandi all'interno del container del laboratorio posseduto:
python3 cve-2026-61500-poc.py \
--target http://127.0.0.1:28182 \
--command 'id > /data/cve-command-output.txt'
Qualsiasi hostname non-loopback, target HTTPS o IP remoto viene rifiutato dalla validazione
degli argomenti. L'exploit modifica server_code di HFS; usare solo il laboratorio usa-e-getta
o un sistema per cui si ha esplicita autorizzazione.
La demo registrata va un passo oltre: demo.sh avvia il servizio callback
non esposto sulla rete Compose e usa --command per connettere una reverse shell Bash
ad esso. Il callback invia solo id, uname -a, pwd e
exit, registra la trascrizione sotto lab/runtime/ ignorato e chiude. Nessuna
porta callback è associata all'host.
L'esecuzione reale del 2026-09-26 ha recuperato uno stato del PRNG e la sua chiave di firma, ricevuto
HTTP 200 per un get_config amministrativo falsificato, installato il payload marker
e osservato CVE_2026_61500_RCE_CONFIRMED nel container vulnerabile. Un
controllo separato --command 'id > /data/cve-command-output.txt' ha prodotto
uid=0(root) gid=0(root) groups=0(root) all'interno di quel container ufficiale. La
reverse shell registrata solo-Docker ha restituito indipendentemente la stessa identità root
e la directory di lavoro /data. Contro
la 3.2.1, la prima risposta di login conteneva un UUID opaco e il PoC è uscito con
stato 3 prima di tentare la falsificazione di sessione. Vedere
docs/example-output.txt e
docs/e2e-results.json.
Il 2026-09-26 sono state eseguite ricerche esatte per CVE ed exploit/PoC su SearchSploit (indice locale Exploit-DB), risultati web indicizzati da GitHub, Packet Storm, Exploit-DB e il web generale. A quel punto non è stato identificato alcun exploit pubblico funzionante; i risultati trovavano solo metadati CVE/advisory e pagine di tracciamento exploit. Questo è un risultato datato e basato sul miglior sforzo, non un'affermazione che nessun exploit possa esistere altrove o comparire in seguito.
<[email protected]>
(Twitter: @aramosf).Solo per ricerca di sicurezza autorizzata, validazione difensiva e formazione. Sei responsabile di ottenere il permesso e di rispettare la legge applicabile.
--command