WebRTC is often considered to be secure by default - with most security concerns being around IP address leakage which is more of a privacy issue than anything. Well, I have news for you - the applications and infrastructure that handles WebRTC can be attacked. It may indeed have various types of security vulnerabilities which are often overlooked. This presentation is based on experiences gained through security testing of WebRTC applications with anecdotal stories to illustrate the dangers. We will also take a peek at Video Delivery mechanisms such as RIST and SRT and discuss what could possibly go wrong there too!

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

15. Attacking the Media

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

41. Attacking NAT traversal

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/

71. Contact us
https://www.enablesecurity.com
sandro@enablesecurity.com