WebRTC & security: 101

OWASP Poland

Transcript

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.