WebRTC DoS
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)
이 문제는 다음 블로그 게시물에서 발견되었습니다: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/
WebRTC 미디어 서버에서 설명된 취약점은 미디어 세션 초기화 중 경쟁 조건에서 발생하며, 특히 ICE 미디어 동의 검증과 DTLS 트래픽 시작 사이에서 발생합니다. 다음은 자세한 분석입니다:
UDP 포트 할당: 사용자가 WebRTC 전화를 시작하면, 미디어 서버는 미디어 스트림 처리를 위해 UDP 포트를 할당하며, IP와 포트는 신호를 통해 전달됩니다.
ICE 및 STUN 프로세스: 사용자의 브라우저는 ICE를 사용하여 미디어 동의 검증을 수행하고, STUN을 사용하여 미디어 서버에 대한 연결 경로를 결정합니다.
DTLS 세션: STUN 검증이 성공적으로 완료된 후, SRTP 마스터 키를 설정하기 위해 DTLS 세션이 시작되며, 미디어 스트림을 위해 SRTP로 전환됩니다.
경쟁 조건 악용: 공격자는 정당한 사용자보다 먼저 DTLS ClientHello 메시지를 전송하여 경쟁 조건을 악용할 수 있으며, TLS_NULL_WITH_NULL_NULL과 같은 유효하지 않은 암호 스위트를 사용할 수 있습니다. 이로 인해 서버에서 DTLS 오류가 발생하여 SRTP 세션이 설정되지 않습니다.
포트 스캐닝: 공격자는 어떤 UDP 포트가 들어오는 미디어 세션을 처리하는지 추측해야 하며, 이러한 포트에 null 암호 스위트를 사용한 ClientHello 메시지를 전송하여 취약점을 유발합니다.
공격 다이어그램: 이 과정은 공격자가 서버에 여러 ClientHello 메시지를 전송하고, 정당한 신호 및 DTLS 메시지와 교차하여 잘못된 암호 스위트로 인해 핸드셰이크 실패로 이어지는 순서를 포함합니다.
안전한 테스트: Scapy와 같은 도구를 사용하여 공격자는 특정 미디어 포트를 대상으로 DTLS ClientHello 메시지를 재생합니다. 윤리적 테스트를 위해 Chromium의 수정(예: JsepTransport::AddRemoteCandidates)을 사용하여 피해자 행동을 안전하게 모방했습니다.
완화 조치: 해결책은 검증되지 않은 주소에서 패킷을 차단하는 것을 포함하며, 이는 libnice와 같은 라이브러리의 최신 버전에서 구현되었습니다. 주요 해결책은 ICE 검증 프로세스를 신뢰하고 검증된 IP 및 포트 조합에서만 패킷을 처리하는 것입니다.
DTLS 서버 구성: 브라우저가 DTLS 서버로 작동하거나 미디어 서버가 미디어 세션에 대해 임시 포트를 사용하지 않는 경우는 이 취약점에 영향을 받지 않습니다.
이 취약점은 미디어 세션 초기화 프로세스의 미세한 균형과 악용을 방지하기 위한 정확한 타이밍 및 검증 메커니즘의 필요성을 강조합니다. 개발자는 권장 보안 수정을 구현하고 이러한 취약점을 완화하기 위해 강력한 검증 프로세스를 보장할 것을 권장합니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
