WebRTC is an open-source project that provides browsers and mobile applications with real-time communications capabilities via simple APIs. It allows for real-time audio/video calls, web conferencing, and direct data transfers between browsers. While WebRTC has encryption and permissions to protect users, security issues still exist, such as the potential for JavaScript injection, signaling server takeovers, and IP address leaks. The document outlines best practices for WebRTC security such as secure signaling, user authentication, clear permission requests, and fallback measures in case of compromise.

1. WebRTC & security: 101
OWASP Wroclaw #4
Alexander Antukh

2. What is WebRTC?
WebRTC is a free, open project that provides browsers
and mobile applications with Real-Time Communications
(RTC) capabilities via simple APIs.
>> that’s correct, it’s right in your browser!

3. Real-time what?
• Real-time audio and/or video calls
• Web conferencing
• Direct data transfers

4. WebRTC ITW
• WhatsApp
• Facebook Messenger
• Tons of web chats
• And many more!
http://www.webrtcworld.com/webrtc-list.aspx

5. WebRTC architecture

6. WebRTC: Signaling
• Signaling in three words: exchange of metadata
• Signaling server:
• Loads client-side context (JS code)
• Mediates control messages and meta-meta
between endpoints
• Signaling protocol is not specified (BIY)

7. WebRTC: Media
• Encrypted P2P connection between browsers
• Steps for setting the media path up:
• Exchange of media parameters (SDP)
• Exchange of network parameters
• UDP hole punching
• STUN (Session Traversal Utilities for NAT)
• TURN (Traversal Using Relays around NAT)
• ICE (Interactive Connectivity Establishment)

8. SDP: Session Description Protocol
• Initialization parameters for streaming media
• Session announcement
• Session invitation
• Parameter negotiation (mmtypes, codecs, ...)

9. UDP hole punching
• Simple but not always applicable (e.g. symmetric NATs)
Browser A Browser B
NAT / Firewall NAT / Firewall
Public server (S)
N:P2 M:P4
1. A à N à M : A:P1 ⇄ N:P2
2. B à M à N : B:P3 ⇄ M:P4
3. N:P2, M:P4 à S
4. A:P1, B:P3 ⇄ S (P2, P4)
5. A:P1 à M:P4 à B
B:P3 à N:P2 à A
A ⇄ B
A:P1 B:P3

10. What about other scary acronyms?
• STUN
• To collect your local network setup (local IPs,
local subnets, NAT configuration…)
• TURN
• To relay your media connection if P2P fails
• ICE
• Bundles all STUN/TURN info for exchange via the
signaling channel and probing until pair works

11. WebRTC API
• getUserMedia(): capture audio and video
• MediaRecorder*: record audio and video
• RTCPeerConnection: stream audio and video
between users
• RTCDataChannel: stream data between users
“Be skeptical of reports that a platform 'supports WebRTC'. Often this actually just
means that getUserMedia is supported, but not any of the other RTC components”

12. WebRTC API: getUserMedia()
navigator.getUserMedia = navigator.getUserMedia ||
navigator.webkitGetUserMedia || navigator.mozGetUserMedia;
var constraints = {
audio: false,
video: true
};
…
function successCallback(stream) {
window.stream = stream; // stream avail to console
if (window.URL) {
video.src = window.URL.createObjectURL(stream);
} else {
video.src = stream;
}
}
…
navigator.getUserMedia(constraints, successCallback, errorCallback);

13. WebRTC API: RTCPeerConnection
• Responsible for managing the full life-cycle of each P2P
connection and encapsulates all the connection setup,
management, and state within a single easy-to-use interface
• Connection initiation: SDP description exchange
• After it is established: sending of real-time audio and video
data as a bitstream var conn = new RTCPeerConnection(conf);
conn.onaddstream = function(stream) {
// use stream here
};

14. WebRTC API: RTCDataChannel
• Enables peer-to-peer exchange of arbitrary data,
with low latency and high throughput
• Features:
• Leveraging of RTCPeerConnection session setup
• Multiple simultaneous channels, with prioritization
• Reliable and unreliable delivery semantics
• Built-in security (DTLS) and congestion control
• Ability to use with or without audio or video
Try my* bear: https://www.cubeslam.com/dcegjx

15. WebRTC API: RTCDataChannel
var pc = new webkitRTCPeerConnection(servers,
{optional: [{RtpDataChannels: true}]});
pc.ondatachannel = function(event) {
receiveChannel = event.channel;
receiveChannel.onmessage = function(event){
document.querySelector("div#receive").innerHTML = event.data;
};
};
sendChannel = pc.createDataChannel("sendDataChannel", {reliable: false});
document.querySelector("button#send").onclick = function (){
var data = document.querySelector("textarea#send").value;
sendChannel.send(data);
};

16. WebRTC API: MediaRecorder
https://webrtc.github.io/samples/src/content/getusermedia/record/
• Introduced back in Sep 2016 (still experimental)
• Sample recording functionality:
• mediaRecorder.start()
• mediaRecorder.stop()
• mediaRecorder.ondataavailable à recordedBlobs.push(event.data)
• … and then make it available for play/download
• Example of recorded video object link:
blob:https://webrtc.github.io/4d25f90a-244b-4e1c-9495-e5f21074aab9

17. WebRTC: security perspective
• Browser acts as TCB
• Natural part of it, not a plugin
• Frequent updates
• Permissions (explicit user consent*)
• Enforced encryption
• RTP is explicitly forbidden
• End-to-end encryption between peers
• Mandatory HTTPS + DTLS / SRTP

18. WebRTC: security perspective
What could go wrong?
• What are the effects of JavaScript/HTML injection?
• Can we steal WebRTC credentials?
• Can we steal privileged information about a client?
• What are the effects of taking over a signaling server?
• Can we crash the server, or render it unresponsive?
• What information can be extracted?
• Can we cause a client to connect to a rogue network?

19. WebRTC security: browser
• Direct data transfer between peers e.g. in chat
• … might equal to a complete takeover of the victim’s context
in case of XSS
• ... as well as leads to obtaining internal addresses of your
counterparts (more soon)
• ... and facilitates direct transfers of malware
• Additional considerations:
• Poor registration mechanisms ~ access and abuse
• Poor session termination ~ session reuse

20. WebRTC security: Android client
• Installation permissions
• Malware to capture private info about the user
• Data storage
• Malicious app could steal data from WebRTC-powered app
• Network interception
• Credentials could be sent over HTTP beforehand
• UI phishing / malware

21. WebRTC security: in between
• Signaling server takeover
• MiTM via fake user or creation of “invisible” one? ;)
• Or simply crashing it and bringing chaos
• Registration hijacking
• Capture/change IP addresses to forward calls to attacker’s server
• DoS against user’s device
• Race conditions (overriding legitimate REGISTER requests)
• Replay attacks

22. WebRTC security: authentication
• Signaling server should not be trusted, and it should be
possible to perform authentication independently
Identity Providers (Facebook
Login, BrowserID, OAuth) provide
auth for users without
participation of the signaling
server

23. WebRTC: additional considerations
• Screen (over)sharing
• Privacy issues in SRTP
• IP location privacy

24. Screen (over)sharing in one pic

25. Privacy issues in SRTP
• Encrypts the payload of RTP packets, not the
headers
• Example of possible info leak:
• timestamp
• audio levels of contained media
• ???
• PROFIT!

26. IP location privacy

27. IP location privacy: scan your LAN!
https://aan.sh/LANScan/
What could go wrong with that?

28. IP location privacy: scan your LAN!
Framework for developing exploits using WebRTC – sonar.js
• Enumerate hosts on internal network
• Fingerprint devices using onload() events and known
CSS/images
• Using pre-set DB of exploits for devices, launch them
against detected one
https://thehackerblog.com/sonar-a-framework-for-scanning-and-exploiting-internal-hosts-with-a-webpage/

29. Demo time

30. IP location privacy: protection
• WebRTC Leak Prevent and similar add-ons
• Browser configuration

31. WebRTC: security design practices
• Secure signaling
• Authentication and peer monitoring
• Permission requests
• MitM protection
• Screen sharing
• Fallback measures

32. WebRTC: security design practices
• Secure signaling
It is recommended to implement a signaling protocol
that provides encryption (SIPS, OpenSIP, HTTPS or
WSS), to prevent eavesdropping.

33. WebRTC: security design practices
• Authentication and peer monitoring
Basic apps require only a user's ID to perform a call, so
it might be a good idea to have pre-registration or
authentication to prevent from untrusted parties.
Another best practice is to consistently monitor the
number of peers in communication vs total number on
the signaling server (no spies, please!)

34. WebRTC: security design practices
• Permission requests
Clearly detail on the page what permissions the
application will ask for, as often users will agree to
permission requests or similar dialogs without
consciously reading the message

35. WebRTC: security design practices
• MitM protection
Regular monitoring of the media path for no
suspicious relays and encrypted signaling should be
presented

36. WebRTC: security design practices
• Screen sharing
Before initiating the streaming of any part of the
screen, the user should be properly notified and
advised to close any screen containing sensitive
information

37. WebRTC: security design practices
• Fallback measures
If it is confirmed the call is compromised by unauth
party, it should be within the power of Web
Application server rendering the WebRTC capable
page to cut off the call

38. Further reading:
• https://www.html5rocks.com/en/tutorials/webrtc/basics/
• https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12
• http://webrtc-security.github.io
• https://2015.appsec.eu/wp-content/uploads/2015/09/owasp-appseceu2015-desmet.pdf
• https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/
• https://arxiv.org/pdf/1601.00184.pdf
• https://thehackerblog.com/sonar-a-framework-for-scanning-and-exploiting-internal-hosts-
with-a-webpage/
Contact me: @c0rdis

39. Fin.