CommCon 2023 - WebRTC & Video Delivery application security - what could possibly go wrong?
0 likes74 views
The talk by Sandro Gauci at CommCon 2023 emphasizes the need for security testing in WebRTC and video delivery applications, despite their inherent security features. It discusses various vulnerabilities associated with WebRTC, RTP, and new protocols like WHIP, highlighting attack vectors such as RTP floods, TURN relay abuse, and signaling weaknesses. The presentation advocates for understanding the attack surface and continuous testing to mitigate potential vulnerabilities in these technologies.
CommCon 2023 - WebRTC & Video Delivery application security - what could possibly go wrong?
- 1. WebRTC & Video Delivery what could possibly go wrong? An Application Security talk at CommCon 2023 by Sandro Gauci, Enable Security
- 2. Welcome! Purpose: convince you that WebRTC + Video Delivery infra/apps need security testing Yes .. even if the technology is said to be secure
- 3. On WebRTC security WebRTC, unlike VoIP, comes with modern security features Signaling has to happen on a secure transport layer (i.e. HTTPS) media is encrypted using SRTP keys exchanged over DTLS
- 4. On Video Delivery Fragmented so hard to make blanket statements SRT = Secure Reliable Transport WISH (WHIP) is built on top of WebRTC, thus inherits its security features
- 5. After this talk using secure technology is a great starting point secure communications require more than just using secure technologies ... or having Secure in the protocol's name
- 6. Who am I to talk about this? Sandro Gauci, from Malta 🇲🇹 - living in Bavaria 🇩🇪 accused of releasing SIPVicious OSS on weak VoIP systems on the intertubes leading Enable Security We specialize on RTC security, focused on security testing
- 7. How do we figure out what we need to worry about?
- 8. Threat modelling to the rescue!
- 10. Threat modelling requires us to understand the attack surface
- 12. WebRTC infrastructure Attack Surface components
- 14. still WIP as we learn more about each component not extremely complex but complex enough split into 4 areas: Media - SRTP / DTLS (and data channels) NAT traversal - ICE / STUN / TURN Signalling - no standard signalling so hard to nail Gateway
- 17. Message processing Media servers need to process each incoming message includes SRTP, SRTCP, DTLS and STUN each protocol is complex, especially DTLS third-party libraries required especially for DTLS e.g. OpenSSL comes with a history of vulnerabilities; some of which apply
- 18. CVE-2022-0778 Denial of Service vulnerability in OpenSSL exploited through a specially crafted X.509 certificate when parsed, causes an infinite loop while parsing an elliptic curve key in WebRTC client certificates are parsed by the media server to check the fingerprint presented in the SDP to prevent man-in-the-middle attacks it is an important security feature but also an attack vector
- 23. Further explanation Blog post and video demonstration against a WebRTC demo - RTPEngine with vulnerable OpenSSL: https://www.rtcsec.com/article/exploiting-cve-2022-0778-in-openssl-vs- webrtc-platforms/
- 25. RTP Proxy vulnerabilities In some cases, the WebRTC media server is also an RTP proxy used in VoIP environments This means that some VoIP media vulnerabilities are also found in WebRTC environments We describe two vulnerabilities: RTP Inject and RTP Bleed
- 26. A very quick introduction to RTP Inject
- 30. RTP Inject versus SRTP streams the media server might behave in an undefined way when receiving RTP or SRTP on an ongoing stream surprisingly, we saw instances where malicious unencrypted RTP streams get encrypted by the media server thus an attacker can send unencrypted RTP which is delivered, in full security to the other party either way, when vulnerable, this almost always (at least) leads to denial of service
- 31. A very quick introduction to RTP Bleed
- 36. Attacking Confidentiality/Integrity of DTLS/SRTP private key (which was published) reuse as in the case of Slack usage of weak ciphers - typical vulnerabilities associated with TLS interesting research area for cryptographers (professionals and amateurs alike!)
- 37. RTP Flood and yes, SRTP too not to be confused with RTP Inject/Bleed! both recording and transcoding systems may be affected what is RTP Flood?
- 40. Why is RTP flood dangerous Attackers can send packets at high rates, large RTP payloads Some recording systems will happily store that media filling up storage space (disk, buckets etc) We have seen gigabytes being stored in a few seconds Some transcoding systems might not cope with the data, taking precious resources
- 43. Focus on TURN relay abuse
- 44. Background on TURN relay abuse TURN servers are meant to relay data - often SRTP between parties that cannot reach each other directly Seems obvious that attackers may abuse TURN servers to reach anything else including internal network IP addresses local services (i.e. on 127.0.0.1 or ::1) external services Sometimes, these internal services require no authentication and assume trust based on IP e.g. AWS instance metadata service (169.254.169.254)
- 45. Background on TURN relay abuse We developed a toolset called stunner to abuse this behavior (and more) Allowed us to discover this vulnerability in various WebRTC platforms: Slack 8x8 Vendor X Signal's infrastructure our customers
- 46. Introduction to the TURN relay abuse demo We have configured the web server to block Internet access to /secret Only internal IP addresses are allowed to view this location The TURN server is also configured to block any internal IP addresses, including localhost If one uses the TURN server as a relay for their web browser (stunner supports this) to access 127.0.0.1/secret, the TURN server blocks that
- 47. 0:00 / 1:05
- 49. Brief note on Gateway attacks Sometimes - from a WebRTC platform - you can call out or in through the traditional phone system e.g. Google Meet / Jitsi might have this functionality for a web conference That interaction between the WebRTC platform and external systems might open up security vulnerabilities Examples that come to mind: toll fraud injection of special SIP headers Interesting attack vector but too specific to cover in this talk Not to be forgotten!
- 50. Attacking Signalling This is how you initiate calls, tear them down and various other important functionality outside of media WebRTC does not define a signalling protocol (other than the use of SDP) SIP or XMPP over HTTP or Websocket is somewhat common In such cases, the systems might inherit security vulnerabilities from SIP/XMPP/etc A lot of proprietary protocols reinvent the wheel - thus some vulnerabilities are also reinvented The equivalent of the SIP INVITE flood DoS vulnerability can often be found in other signalling protocols
- 52. Specific attacks on signalling Hard to give generic examples for WebRTC infrastructure due to it having no defined signalling protocol
- 53. What about Video Delivery? We started looking at SRT - Secure Reliable Transport Too complex to learn, let alone build a proper attack surface mindmap for this talk Also not very related to WebRTC Something else is much more related ...
- 54. Hello WHIP! or is it WISH? WISH = WebRTC Ingest Signaling over HTTPS WHIP = WebRTC-HTTP ingestion protocol We focused on WISH/WHIP which is still very new but is/will be a standard signalling protocol for WebRTC signalling just for media ingestion How does its attack surface look like?
- 56. Attack surface for WISH/WHIP Inherits all the WebRTC potential security issues Removed the gateway element; seems irrelevant All the previous generic attack surface for signalling still mostly applies Also identified a few potential and specific attacks
- 58. Limited attack surface The draft for WISH explains that certain things that are normally allowed in WebRTC are not allowed in WISH Examples no SDP renegotiation is supported = DoS on reneg will not be relevant SDP offer - sendonly SDP answer - recvonly and some other restrictions Great for security because they reduce the attack surface SDP is still there, still complex Complexity is the enemy of security
- 59. Potential issues in WISH implementations
- 60. Warning The above is theoretical because we did not properly test any implementations
- 61. Potential issues in WISH implementations access control issues (or IDOR) on the resource location DoS with ICE restarts POST flooding traditional HTTP-style attacks; since it is HTTP specific
- 62. Access control issues on the resource location POST /whip/endpoint HTTP/1.1 Host: whip.example.com Content-Type: application/sdp Content-Length: 1326 v=0 ... HTTP/1.1 201 Created ETag: "xyzzy" Content-Type: application/sdp Content-Length: 1400 Location: https://whip.example.com/resource/id v=0 ...
- 63. Resource location security if there is no authentication and proper authorization .. if attackers can guess the resource location ... then they may send DELETE requests to all ongoing sessions and tear them down
- 64. Flooding with PATCH requests PATCH /resource/id HTTP/1.1 Host: whip.example.com If-Match: "*" Content-Type: application/trickle-ice-sdpfrag Content-Length: 54 a=ice-ufrag:ysXw a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k HTTP/1.1 200 OK ETag: "abccd" Content-Type: application/trickle-ice-sdpfrag Content-Length: 102 a=ice-lite a=ice-ufrag:289b31b754eaa438 a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
- 65. Flooding with POST requests POST /whip/endpoint HTTP/1.1 Host: whip.example.com Content-Type: application/sdp Content-Length: 1326 v=0 o=- 5228595038118931041 2 IN IP4 127.0.0.1 s=-...
- 66. Flooding with POST requests SDP may be very small or very large; different effects on the target This tends to be resource intensive functionality
- 67. Concluding
- 68. Gratitude Alfred Farrugia who assisted greatly with the contents and resources Dan Jenkins and the CommCon team for organising this event Our customers who keep it interesting for us 😄 Anyone who is contributing to RTC security!
- 69. Key take aways Even if WebRTC is considered the most secure VoIP, there are attack vectors This also includes the web attack surface which is very familiar to many security professionals But also RTC specific vulnerabilities (more interesting to us) Vulnerabilities inherited from older applications/protocols
- 70. What to do? Stay informed - we do our bit at At various stages of developing WebRTC and Video Delivery solutions ... Test Test Test! https://rtcsec.com/subscribe https://www.rtcsec.com/tags/webrtc-security/