WebRTC & security: 101

WebRTC & security: 101

OWASP Poland

8b92dd9cdb06779f63c8747f3a3a2401?s=128

Alexander Antukh

October 27, 2016
Tweet

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.