WebSocket Attacks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Le connessioni WebSocket vengono stabilite attraverso un iniziale handshake HTTP e sono progettate per essere a lungo termine, consentendo la messaggistica bidirezionale in qualsiasi momento senza la necessità di un sistema transazionale. Questo rende i WebSocket particolarmente vantaggiosi per le applicazioni che richiedono bassa latenza o comunicazione avviata dal server, come i flussi di dati finanziari in tempo reale.
Una spiegazione dettagliata su come stabilire connessioni WebSocket può essere accessibile qui. In sintesi, le connessioni WebSocket sono solitamente avviate tramite JavaScript lato client come mostrato di seguito:
Il protocollo wss indica una connessione WebSocket protetta con TLS, mentre ws indica una connessione non protetta.
Durante l'instaurazione della connessione, viene eseguito un handshake tra il browser e il server tramite HTTP. Il processo di handshake prevede che il browser invii una richiesta e il server risponda, come illustrato nei seguenti esempi:
Il browser invia una richiesta di handshake:
Risposta di handshake del server:
La connessione rimane aperta per lo scambio di messaggi in entrambe le direzioni una volta stabilita.
Punti chiave del handshake WebSocket:
Le intestazioni Connection e Upgrade segnalano l'inizio di un handshake WebSocket.
L'intestazione Sec-WebSocket-Version indica la versione del protocollo WebSocket desiderata, di solito 13.
Un valore casuale codificato in Base64 viene inviato nell'intestazione Sec-WebSocket-Key, garantendo che ogni handshake sia unico, il che aiuta a prevenire problemi con i proxy di caching. Questo valore non è per l'autenticazione ma per confermare che la risposta non sia generata da un server o da una cache mal configurati.
L'intestazione Sec-WebSocket-Accept nella risposta del server è un hash della Sec-WebSocket-Key, verificando l'intenzione del server di aprire una connessione WebSocket.
Queste caratteristiche garantiscono che il processo di handshake sia sicuro e affidabile, aprendo la strada a una comunicazione in tempo reale efficiente.
Puoi usare websocat per stabilire una connessione raw con un websocket.
O per creare un server websocat:
Se scopri che i client sono connessi a un HTTP websocket dalla tua attuale rete locale, potresti provare un ARP Spoofing Attack per eseguire un attacco MitM tra il client e il server. Una volta che il client sta cercando di connettersi, puoi quindi utilizzare:
Puoi utilizzare il tool https://github.com/PalindromeLabs/STEWS per scoprire, identificare e cercare vulnerabilità note nei websockets automaticamente.
Burp Suite supporta la comunicazione MitM dei websockets in modo molto simile a come lo fa per la comunicazione HTTP regolare.
L'estensione socketsleuth di Burp Suite ti permetterà di gestire meglio le comunicazioni Websocket in Burp ottenendo la cronologia, impostando regole di intercettazione, utilizzando regole di corrispondenza e sostituzione, usando Intruder e AutoRepeater.
WSSiP: Abbreviazione di "WebSocket/Socket.io Proxy", questo strumento, scritto in Node.js, fornisce un'interfaccia utente per catturare, intercettare, inviare messaggi personalizzati e visualizzare tutte le comunicazioni WebSocket e Socket.IO tra il client e il server.
wsrepl è un REPL websocket interattivo progettato specificamente per il penetration testing. Fornisce un'interfaccia per osservare i messaggi websocket in arrivo e inviarne di nuovi, con un framework facile da usare per automatizzare questa comunicazione.
https://websocketking.com/ è un web per comunicare con altri web utilizzando websockets.
https://hoppscotch.io/realtime/websocket tra altri tipi di comunicazioni/protocolli, fornisce un web per comunicare con altri web utilizzando websockets.
In Burp-Suite-Extender-Montoya-Course hai un codice per lanciare un web utilizzando websockets e in questo post puoi trovare una spiegazione.
L'hijacking WebSocket cross-site, noto anche come hijacking WebSocket cross-origin, è identificato come un caso specifico di Cross-Site Request Forgery (CSRF) che colpisce i handshake WebSocket. Questa vulnerabilità si verifica quando gli handshake WebSocket si autenticano esclusivamente tramite HTTP cookies senza token CSRF o misure di sicurezza simili.
Gli attaccanti possono sfruttare questo ospitando una pagina web malevola che avvia una connessione WebSocket cross-site a un'applicazione vulnerabile. Di conseguenza, questa connessione viene trattata come parte della sessione della vittima con l'applicazione, sfruttando la mancanza di protezione CSRF nel meccanismo di gestione delle sessioni.
Nota che quando si stabilisce una connessione websocket, il cookie viene inviato al server. Il server potrebbe utilizzarlo per relazionare ogni singolo utente con la sua sessione websocket basata sul cookie inviato.
Quindi, se per esempio il server websocket invia indietro la cronologia della conversazione di un utente se viene inviato un msg con "READY", allora un semplice XSS stabilendo la connessione (il cookie sarà inviato automaticamente per autorizzare l'utente vittima) inviando "READY" sarà in grado di recuperare la cronologia della conversazione.
In questo post del blog https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ l'attaccante è riuscito a eseguire Javascript arbitrario in un sottodominio del dominio in cui avveniva la comunicazione tramite web socket. Poiché si trattava di un sottodominio, il cookie veniva inviato, e poiché il Websocket non controllava correttamente l'Origin, era possibile comunicare con esso e rubare token da esso.
Copia l'applicazione web che desideri impersonare (i file .html per esempio) e all'interno dello script in cui avviene la comunicazione tramite websocket aggiungi questo codice:
Ora scarica il file wsHook.js da https://github.com/skepticfx/wshook e salvalo all'interno della cartella con i file web.
Esporre l'applicazione web e far connettere un utente ad essa ti permetterà di rubare i messaggi inviati e ricevuti tramite websocket:
Le condizioni di gara nei WebSocket sono un problema, controlla queste informazioni per saperne di più.
Poiché i WebSocket sono un meccanismo per inviare dati al lato server e al lato client, a seconda di come il server e il client gestiscono le informazioni, i WebSocket possono essere utilizzati per sfruttare diverse altre vulnerabilità come XSS, SQLi o qualsiasi altra vulnerabilità web comune utilizzando l'input di un utente da un websocket.
Questa vulnerabilità potrebbe consentirti di bypassare le restrizioni dei proxy inversi facendoli credere che una comunicazione websocket sia stata stabilita (anche se non è vero). Questo potrebbe consentire a un attaccante di accedere a endpoint nascosti. Per ulteriori informazioni, controlla la seguente pagina:
Upgrade Header SmugglingImpara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
