WebRTC was designed for peer-to-peer communication but It is possible to make WebRTC calls interoperable with other IP or legacy networks, by the use of WebRTC to SIP gateways, that have been released by Session Border Controllers and Media Gateway manufacturers, like the Oracle WSC.
This environment opens up big opportunities for new services for residential (OTT services, vertical applications for e-health, online banking, etc.) and corporate users (BYOD, teleworking, etc.). This new bunch of services and devices could mean an opportunity for intruders and attackers that we should prevent.
As we can see in the figure, that shows a typical WebRTC implementation, we have to introduce a webserver (like the Sippo WebRTC Application Controller) that can be hijacked, a new gateway like theOracle WSC (that could be attacked via DoS attacks or illegally accessed) and, finally a smart endpoint (laptop, smartphone,etc) that can be full of viruses and ad-hoc trojans. In addition, we should take care of the ID of the users involved in the WebRTC session.
- TRADITIONAL VOIP ATTACKS
Some new potential threads are going to appear by the use of WebRTC and part of the traditional VoIP attacks will be inherited, especially in those scenarios where interconnection is going to be present.
Denial of Service attacks (DoS attacks) are based on the delivery of a massive amount of messages (signalling traffic) to collapse CPU, bandwidth or memory of the attacked system or device. The most common objective is to obtain login, password or just extension numbers, by the use of brute force attacks. This information could be used for fraud or illegal interception, but this attack can also force a crash in the SIP proxy or softswitch.
When an attacker knows the extension of a valid user and the password or detects a publicly accessible port not protected, it is possible to make an illegal use of the telephony service. In this case the objective is commonly to make calls to international destinations or premium numbers where it is possible to get important revenues in a short time. A stolen WebRTC account with a PSTN number associated can cause importante legal problems beyond financial losses.
- AD-HOC ATTACKS IN WEBRTC
WebRTC is a browser-centric technology, and web browsers are supposed to be designed to protect the users from different attacks. Traditional VoIP attacks involve network attackers, now we will have to deal also with web attackers, who have an strong knowledge of the weaknesses around the use of web-based services. WebRTC services must be designed to prevent both possibilities..
One main concern when dealing with WebRTC is how to give access to physical input devices to the script, namely microphone and webcam (or screen and file systems, in some scenarios). In the next figure we can see what could potentially happen. The user access a fake web in which he trusts, a malicious script is downloaded with the page. If it gets access to the camera or microphone it can start a background call to a recording server which stores the calls which can later be used with any purpose.
A technique commonly used to make the user aware that his cam is being used, it is to show oneself video stream. The user can be aware that is being recorded and knows what the other side is watching.
Another important thing is to properly notify calls to users and this is not regulated by any standard. It is common to use for both events ringback and ringing tones respectively, simulating the behaviour of any other physical telephone or softphone. An open issue for WebRTC is to notify calls in smartphones when the browser is in background as a push mechanism must be used.
Websockets support cross-domain. This means that you can connect with a server whose domain is different from the domain you downloaded the script from. This gives the necessary flexibility to make websockets useful, but it also could allow some kind of Distributed Denial of Service we must be aware of.
Imagine a web server controlled by Doctor Evil which hosts a fake web which offers free premium Spotify subscriptions for a year, like the one you see in the figure. After accessing the web a malicious script will be downloaded. As soon as it is executed in the web browser, it will try to connect to the attacked server. This can be managed with an implementation of robust DoS protection policies.
There is another interesting point regarding websockets, since they open a TCP socket through which scripts are able to send any kind of traffic. If this traffic looks exactly the same as HTTP request and response, intermediary elements can potentially interpret the traffic as valid and, for instance, include fake pages in the cache.
In the case of DoS and DDoS attacks, as any other service designed to be available on Internet, WebRTC services must be protected against them. It will receive signalling traffic over TCP so it must implement all the basic protection against attacks. Servers should be able to dynamically blacklisting IPs from where they are receiving attacks.
Access of physical devices and DoS or DDoS are just two examples of potential threads in a WebRTC implementation. Another scenario to take into account is the use of ICE or other NAT traversal techniques, that can also be attacked. Besides this network-level protections, authentication is a another key security element that should be also implemented.
An architecture based on security-centric designed elements like the Sippo WebRTC Application Controller(or WAC, in short) and the Oracle Communication WSC can be the best option to make a real field deployment.
Sippo WAC is the right tool to develop, adapt or deploy any WebRTC tool in a SDN or corporate architecture, with the security that it is going to be interoperable with the existing services and with any WebRTC gateway, like the Oracle WSC, which inherits all the expertise in terms of security prevention from the leading Session Border Controller manufacturer. In addition, these elements provision features to manage user provisioning, user authentication, call details records and contextual information to deploy a robust solution.
For more information about our WebRTC security, please visit www.quobis.com to get a complimentary copy of the first-industry whitepaper “WebRTC Security Concerns”.