WebRTC is changing the way we live by establishing new norms in communication. WebRTC makes this possible by supporting real-time browser-to-browser communication without additional plugins. It provides peer-to-peer (P2P) file sharing and streaming of P2P audio and video calls. And all these are done by incorporating real-time communication directly in the end user’s browser.
Security Measures Implemented by WebRTC
So, now that this technology is selling like hotcakes, you might be tempted to dig into it. However, it would be advisable to first understand the risks and threats that come with it. The good news is that most of these risks could be mitigated, and this article helps you with it.
WebRTC communication comprises two stages: The signaling stage and the communication stage. We need to consider the threats and security concerns related to all components involved, including the server, client, and communication channel.
Let us first talk about the security measures implemented by WebRTC.
The server security measures are implemented using STUN (Session Traversal Utilities for NAT), which is used to get an external network address and IdP (identity provider). This ensures the identity of the authenticating party.
The client-side security mainly revolves around the access control permission from the user. Most browsers prompt the user for media device access and inform the user when it is in use.
The communication channel is the most critical and most protected part of WebRTC. Both the signaling plane (HTTP, SIP) and media plane (RTP) must be secured separately, which is a complicated task. This segregation between the signaling and media plane does not guarantee that the signaling user is the same as the media messaging user. Due to this, the WebRTC specifications enforce encryption of both the channels using DTLS-SRTP to ensure that the establishment of the media stream can take place without the need to reveal the SDP (Session Descriptor Protocol) in the message exchange.
To secure the communication channel from man-in-the-middle (MitM) attack where an attacker may be able to listen to communicating parties, a TLS certificate exchange is performed between the two parties. The TLS certificate is first sent via the signaling channel and then via the media channel and then compared for validity.
Threats to WebRTC and How to Mitigate Them
Security — Client Server
I have summed up the types of risks associated with the client-server at various levels below.
||Possibility of Attack
||As WebRTC allows users to share information directly without an intermediary server, an attacker may
- extract passwords using phishing techniques
- send malicious code embedded within a text message to the victim
- capture conversation data
|All the user-supplied data must be validated against the HTML component it is displayed in.
||Information disclosure during signaling phase on the local client
||Due to the nature of WebRTC, a browser must be able to access information such as the internal IP address of the machine, which is used to establish a P2P connection without a server.
||The attacker can acquire useful information about the victim and her network.
||Configure the signaling server to send IP addresses only after both the parties have accepted communication with each other.
||Information disclosure during signaling phase on remote client
||WebRTC requires the clients to access each other's communication address with reveals information such as the client's internal IP address.
||The attacker can obtain information about clients by acquiring their internal IP addresses and opening a communication channel with them.
||This problem could be addressed by applying an application architecture in which a virtual client is a proxy to all of the communication which allows the attacker to view only the virtual client's IP address.
||When you share files on web applications, then a security check on the file is performed at the server. However, as WebRTC allows clients to communicate directly, one client can send malware to another directly.
||An attacker may send a malicious payload to be executed by the victim's operating system.
||Define a location where the file contents may be checked for viruses and validated using digital signatures, etc., prior to its delivery to the receiving client. This location could be on a server or on the receiving client.
|Registration and termination
||Registration without identity
||A client may register with a WebRTC application without providing any identifying details. It is even possible for the attacker to bypass email-based or SMS-based verification.
||An attacker can create multiple accounts for issuing WebRTC communication using the provided service. In such cases, the provider may not be able to comply with lawful interception requirements for telecommunication companies.
||Associate the registration process with a credit card even if the service is provided free of charge.
||Session not terminated
||As a WebRTC application allows a client to be connected in several locations at the same time, appropriate session termination mechanisms must be implemented.
||The attacker may reuse an active session in a previously used device, steal private information, and impersonate the client's identity.
||An attacker can create a malicious application that utilizes WebRTC to steal audio/video information.
||The attacker may leverage this application to capture private information about the user.
||Installing the Android WebRTC application must prompt the user for specific privileges like INTERNET, RECORD_AUDIO, and CAMERA permission.
||A malicious application tries to capture the credentials of an existing/installed WebRTC-based application.
||The attacker acquires credentials.
||To read the application data stored in the /data/data folder (default location), root privileges are required. Unless the developer is strictly defined otherwise, access without root privileges requires leveraging a flaw in the Android OS.
||Network traffic tampering via browser plugins
||When information is sent from WebRTC applications, the conversation is protected by DTLS-SRTP. However, a client's credentials may be sent beforehand, using an unencrypted channel and allowing an attacker to reuse the session.
||The attacker can install a browser plugin to steal WebRTC application credentials.
||Browser plugins provide additional functionality to the browser, and they have elevated permissions to define, capture, and modify browser configuration — defining a proxy for the browser could be one of them.
||Network traffic tampering via Android proxy
||A malicious application can redirect traffic to an unwanted destination by creating a proxy.
||The attacker can obtain sensitive information.
||Proxies can be defined by a user, but root permissions are required for proxy configurations by an application.
||Network traffic tampering via Android proxy via VPN
||A malicious application can redirect traffic to an unwanted destination using a VPN proxy.
||The attacker can obtain sensitive information.
||The Android VPN is an alternative to establishing a proxy. The majority of applications that limit network traffic, as well as proxy applications such as Drony, Sendro, etc., utilize this functionality.
After taking a long look at the possibility of security threats and possible solutions, I hope you have not forgotten to take care of the Server.
Security — Server
Let us now take a look at the possible security threats on the server side. As WebRTC is more about peer-to-peer and less about the server, the list of threats is less exhausting than the client list above.
||Possibility of Attack
|Signaling server takeover
||An attacker who gains access to the signaling server can perform various actions such as:
- crashing the system
- altering the data stream recipient
- cloning the data stream by creating an "invisible" user participating in a conference conversation
- performing a MitM attack by creating a fake user
|Implement rigorous authentication
|Crashing the server using malformed JSON
||An attacker can send a malformed JSON to the server as part of a legitimate request (i.e., a new field in the ICE candidate message). When the server attempts to parse the JSON, it will result in an error and exit its main program loop, rendering the server unresponsive to new requests.
||It is possible to avoid these kinds of attacks by rigorous input validation on the server-side.
|Registration hijacking in SIP
||SIP (Session Initiation Protocol) is a communication signaling protocol heavily used in VoIP applications. In this protocol, a client may register itself to the server, sending information such as the IP address. This information is sent in plain text, which can be captured by an attacker who can subsequently modify it so that all calls will be forwarded to the attacker.
||Authentication, authentication, and authentication!
Security — Communication Channel
After having covered the other two major components, namely client and server, let us ensure the security of the communication channel.
||Possibility of Attack
|Deducing information from encrypted communication
||While WebRTC encrypts the information by default, it may still be possible to obtain some insight regarding the type of conversation conducted between two participating users, and even extract other useful information, without tampering with encryption.
||The attacker may use sensitive data received in a social engineering attack.
||In order to tamper inference from encrypted traffic, the WebRTC application may obfuscate the data being sent. The simplest obfuscation method is padding and splitting all data chunks to create packets of the same size and send them with a constant frequency. Such solutions usually result in overutilization of network bandwidth and are not supported by existing WebRTC implementations.
|Communication disruption/DoS attacks
||Traditional enterprise firewalls often fail to manage WebRTC communication appropriately due to the segregation between the signaling and media channels in WebRTC. The UDP nature of WebRTC allows a possibility of IP spoofing.
||If WebRTC firewall traversal is allowed, an attacker can send packets to a client, fooling the firewall into thinking that these packets are a legitimate part of the conversation. In the case of outdated enterprise firewalls, this can end in a DoS attack.
||Enterprise firewalls must by updated to support WebRTC communication.
|Forceful use of rogue Wi-Fi network by leveraging a server's anti-DoS mechanism
||The server's anti-DoS mechanism blocks the IP of any legitimate Wi-Fi network that tries to perform a DoS attack on the WebRTC application. This safety feature can be exploited to force a victim to use a rogue Wi-Fi network instead of a legitimate one.
||The attacker can get the IP of a legitimate Wi-Fi blocked as described and then create a rogue Wi-Fi network aimed at exploiting anyone that connects to it. Clients, being unable to connect to the WebRTC application due to the IP blocking may decide to connect to the rogue network in order to use the WebRTC application.
||Blocked IP lists must be cleared periodically.
WebRTC is rapidly changing the face of communication by replacing some of the traditional means of conducting audio/video calls, it has become especially important to telecommunication companies.
Hence, telecommunication companies are also forced to implement various security measures as the communications are channeled to and from telecommunication servers.
Summary: Risks Before You Dive Into WebRTC
This blog is especially helpful for you if you choose to go for the in-house development for embedding WebRTC in your applications. The idea is not to discourage you from going DIY but to help you make an informed decision. Alternatively, you could also engage a proven CPaaS provider that has the necessary securities in place.