WebRTC Security Vulnerabilities You Should Know About

Introduction

Web Real-Time Communication or WebRTC is an open-source and free technology enabling real-time communication between web browsers through APIs. It allows video and audio communication inside the web pages by enabling peer-to-peer interaction while removing the need to download native apps or install plugins. It has a flexible underlying infrastructure and is supported by all major browsers such as Google, Microsoft, Apple, and Opera. 

This technology has been designed to standardize RTC across browsers, enabling the integration of interoperable media streaming VoIP web applications. The core use of this technology is web conferencing, direct data transfers, and real-time audio/video calls. Companies like Facebook, addLive, and Firefox Hello are using WebRTC in their products and services. Not only that but startup companies are also using WebRTC as core technology which clarifies that this tool can easily be used by anyone. 

However, the ability to enable embedded audio or video communication in a browser has raised security concerns of this technology. So, today we will address threats to WebRTC technology and the ways to overcome them.

Overview of WebRTC Architecture

WebRTC is composed of two stages: signaling and communication. Although there are many different architectures that involve multi-domain systems or intermediary servers, the security vulnerabilities are fundamentally similar across systems that are using these technologies.

In the signaling stage, the conversation is set up. It is then managed by signaling servers and also includes crucial steps like protocol negotiation, defining shared information channel, and IP address exchange. The communication between two clients here is secured by Datagram Transport Layer Security (DTLS).

A WebRTC Call Topology

After the establishment of direct communication, participants can directly interchange information with each other. But as the connection is new, both the clients have to revalidate each other by resending ICE-ufrag, DTLS certificate fingerprint, and ICE-pwd. After the revalidation, direct communication between the clients can take place. 

WebRTC Security Measures

The security measures in WebRTC can be divided into three main categories: Server, Client, and Communication Channel. 

1. Server Security: WebRTC is a P2P communication standard with an intermediary server. Here the security measures performed by servers are implemented using pre-WebRTC software components like IdP (Identity Provider) to maintain authenticating party identity and Sessional Traversal Utilities for NAT (STUN) to get an external network address.

2. Client Security: As we know WebRTC is designed to support P2P video/audio communication and direct data transfer. The browsers that support WebRTC implements two authentication mechanisms:

• Request for media device permission before usage (unless stated otherwise by user)

• Information of media being used is shared with the user

3. Communication Channel Security: The most protected and crucial part of WebRTC is the Communication Channel. The WebRTC forbids pure RTP and enforces the use of a secure and encrypted version of real-time communications, called SRTP. Both the media plane (RTP) and signaling plane (HTTP, SIP) must be independently secured, which can be quite difficult and doesn’t guarantee that the user of media and signaling are the same. And for that, it enforces encryption of both planes via DTLS-SRTP that assures the establishment of media stream without revealing Session Descriptor Protocol in the interchange. 

If somehow the communication between peers is compromised, an attacker will be able to listen to the communicating parties by MitM attack. And to prevent that, both the clients exchange TLS certificate via signaling channel and media channel respectively where the two certificates are validated. As any attack requires forging the SSL encryption to the server that is a bit complex task to do, this certification exchange mitigates MitM attacks.

Security Vulnerabilities of WebRTC

While WebRTC implements all the security measures within its context, it’s important to remember the clients exist in the host browser. A standard Web application attack influences the WebRTC ecosystem and can be used to obtain information and perform action assuming the victim’s identity. 

So here’s the list of general client vulnerabilities one can face while using WebRTC based applications.

1. JavaScript Injection: An application is vulnerable to cross-site scripting attacks (XSS) that allow a hacker to insert JavaScript and HTML in the application context. Though classic XSS attacks are mitigated by putting validation on the server-side, WebRTC apps enable users to share information without an intermediary server allowing attackers to send malicious code encoded in the text message to a victim, while in a P2P manner displaying a name or attachment file name.
   
   Input validation should be done in all the data supplied by the user. Validation must be performed against HTML components (DOM attribute, JS String, DOM Value) and malicious content may be executed in certain scenarios.

2. Using Signaling for information disclosure: To establish a P2P connection without a server, WebRTC requires a browser to access information like the IP address of the machine. As this functionality is in the JS API, it can be used in the web application’s context enabling a server to acquire the information from clients using its service for browsing. This also allows attackers to gain important information about the victim and their network.
   
   The signaling server must be configured to send the IP address only at the time when both participants have accepted the communication among each other.

3. Malware facilitation using WebRTC: Web applications allowing users to share files perform a security check on the file before it gets sent to the receiving party. Moreover, the checkup needs to be done by the server-side as an attacker can edit a legitimate request after it has been approved from the client-side.
   
   To mitigate this issue, it’s essential to define a location to sanitize the content of the file and validate it using matching file types and digital signatures. This either needs to be performed by the server or by the receiving clients.

4. Session Termination: An application that allows a client to be connected in multiple locations simultaneously so it’s important to implement a proper session termination mechanism. Otherwise, the attacker may be able to reuse active sessions in the device used before to steal private data and execute actions through the identity of clients.
   
   While there’s no way to implement connection termination on an ongoing interaction in the standard P2P model, one must integrate JavaScript code into the WebRTC app to terminate any open communication channel after the client has been logged out or if unable to communicate through the server.

5. Installation Permissions: An attacker might create a malicious app to use WebRTC to steal audio/video information. In that case, the installation of the WebRTC app must prompt the users to certain privileges. It should also ask the user for an Internet Connection as well as record audio and camera permissions.

6. Credential Storage: A malicious app can also try and capture the credentials of an installed WebRTC application in the android version.
   
   As Android apps by default store the application data in the application’s private folder. Reading any information would require root privileges. That is unless defined otherwise by the developer, accessing information without this privilege will require leveraging the flaw in the Android operating system.

7. Network Traffic Tempering: Although the conversation between clients is secured by DTLS-SRTP, the client’s information might be sent already using an unencrypted channel. And to steal the information from the WebRTC based application in different environments, such as proxy, browser plugin, and Android VPN, an unencrypted channel enables the attacker to reuse the session.
   
   However, keep note that this scenario can only take place if the session credentials are shared over the unprotected channel (non-HTTPS connection) to the WebRTC app server. So using an unprotected channel should be avoided while sharing the credentials.

8. Browser Plugin: An attacker can also attempt to install a plugin in the browser to steal the credentials of the WebRTC app.
   
   While chrome does not allow such plugins to be installed, Firefox might allow plugins that are the same as its desktop version. Browser’s plugins offer additional functionality to the browser so they gain elevated permissions to capture, define and modify browsers configuration. But the configuration can be changed only by the user’s approval.

9. Crashing Server Using Malformed JSON: The JSON object is parsed as one unit, which means a lapse in a part of the object will impact the whole parsing process. If an attacker sends the malformed JSON to the server that will seem like a genuine request. While the server will try to parse the JSON it will catch the error and will exit its original program loop. It will make the server unresponsive to new requests.
   
   It can be easily avoided by implementing input validation on the server side.

10. Communication Disruption/DoS Attacks: If the firewall traversal is allowed in the WebRTC, an attacker can send packets to the client while making the firewall think that the packets are a part of a legitimate conversation. And to avoid such DoS attacks it is important to keep the enterprise firewall updated that backs communication in WebRTC.

Conclusion

WebRTC has sharp capabilities for privacy and security, but it’s not a standalone system. It needs a host server, application, and transportation layer to connect them. This article was shared to analyze different threats and attacks related to WebRTC that show even having a strong set of security features, it is not yet immune to direct attacks. However, with the implementation of proper mitigation methods while developing the WebRTC app most of the issues can be resolved.