My name is Elías Pérez and together with my colleagues Iago Soto and Antón Román, we are going to talk about WebRTC and security during 40-45 minutes In this slide you can review the agenda of this webinar. Iago Soto is going to introduce the problem of security in WebRTC and is going to mention traditional VoIP attacks that are going to be present in WebRTC services. Later, our CTO, Antón Román, is going to talk about ad-hoc WebRTC attacks and protection mechanisms. Finally, we are going to close with an overview of identity management solutions and we will leave time to your questions. Please, feel free to use the chat tool of GoToWebinar to send us your questions during this webinar. At the end, we will try to answer them. Now it’s the turn of Iago Soto, who will try to answer this suggestive question. Thank you very much Elias. I understand that part of our audience has a strong background about WebRTC so I am going to pass quickly through the description of the technology WebRTC is called to be the next big thing in unified communications during the next years, as Web browsers will be able to manage voice and video communication in a native way, with no plugins, extensions or applications to be installed. WebRTC is promoted by Google and is being standardized by W3C and IETF in a coordinated way. WebRTC technology was initially designed to have a browser-to-browser real-time communication in mind, but it allows to be used in conjunction with different kinds of servers to provide additional services such as connection to PSTN. The independence from the platform or the type of device, together with the fact that there is no need to install or update anything, is going to make easier the adoption by end users. This represents a big opportunity for industry, but (!!!) could be the base of new security holes that we will try to explain here. WebRTC is independent of the device so could be the best enabler or the base to create the new business strategy for service providers and internet companies. WebRTC adoption is increasing because it can be use in different devices like: Desktops and laptops, that were the first adopters of WebRTC services. The use of WebRTC makes sense in enterprises and residential cases, because is not needed to install or upgrade anything and is independent of the operating system that is being used. Additionally, Most recent devices include webcam and mic so the adoption is really fast. Since Google for Android supports WebRTC, tablets have become a new device for real time communications, taking into consideration that this type of devices have microphone and camera, are mobile and include a wide screen to extend collaboration environments that could not be deploy in smartphones. In addition, netbooks like Chromebook are a new type of low-cost laptops that only run web browsers but can be great for the use of WebRTC services.

2. Agenda
- WebRTC and security?
- VoIP attacks
- WebRTC vulnerabilities
- Protection
- Identity Management
- Questions and answers
Iago Soto Mata
@iagosoto
Antón Román
@antonroman
Elías Pérez Carrera
@epcarrera

3. WebRTC and
security?

4. WebRTC. Features
Open system, no propietary implementations
¡No plugins!
Multi-platform...

5. WebRTC. Features.
Multidevice:
○ Desktop and laptops
○ Tablets and notebooks
○ Smartphones
○ Mozilla FirefoxOS devices
○ Set-Top-Boxes and WebTVs
More information about
WebRTC is available :

6. WebRTC. Use cases.
More information about
use cases available here:
Corporate:
○ Audio webclients for IMS, NGN, MS Lync, Cisco, etc.
○ Video webclients for conference bridges
○ Click to call (click to video/chat) solutions
○ Contact center solutions
Residential:
○ OTT services
○ Audio webclients for residential users
○ Webchats
○ Vertical applications (ehealth,...)
○ Extended RCS/Joyn services

7. WebRTC. Architecture.
New potential weak elements in the UC
networks in terms of security:
○ Web Server
○ WebRTC gateway
○ Laptop/desktop used as endpoint

8. Efforts in WebRTC security.
RFC Draft:
Security considerations
for RTC-Web
WebRTC inherits part of the potential VoIP attacks and
adds new threads:
○ New network elements to be hijacked, etc.
○ Open communications (new open ports, etc.)
○ Privacy issues through access to microphones and cams.

9. VoIP attacks

10. VoIP attacks. Introduction.
Types of VoIP attacks:
1. Denial of service
2. Fraud
3. Illegal interception
4. Illegal control
A VoIP attack causes an immediate economic damage for the attacked entity
and a direct economic profit to the attacker. This does not occur with ther
type of attacks.
VoIP security

11. VoIP attacks. Denial of service.
The aim of an attack of DoS is to degrade the quality of the service that
perceives the user by means of the massive delivery of messages that require
of the use of resources (CPU, BW or memory) in the attacked system.
Examples: flood of register requests or calls in a softswitch or switchboard
that can pretend:
■ A simple failure of the service.
■ Attack for telephone fraud.
Also other "non intentional" attacks should be taking into account:
■ flood after a power blackout.
■ Bugs in terminals.
■ Viruses.

12. VoIP attacks. Fraud.
An attacker registers in the system with a valid user (discovers the password,
alters an IP, etc.) with the aim to do calls to international numbers. CFCA
estimates 40 Billions USD annually.
They are not only calls through the network. Sometimes the attacker obtains
remote access to a SIP proxy or softswitch that can use to originate illegal
calls by console.
● These attacks cause not only economic losses. Sometimes the legitimate
user has to pay the bill !!.
● In most cases, it's difficult to determine the responsibility (customer or
operator) of the attacks.

13. VoIP attacks. Illegal interception.
Because of the IP nature is simpler to capture signalling and media traffic by
potential attackers to obtain information (audio of the call, other information
of the call exchanged, etc.)
As traditional VoIP SIP traffic is opened, this is more dangerous in Wi-Fi
networks where traffic is not ciphered.
WebRTC uses ciphered traffic for
signalling and media, so interception
could only be done in the endpoints
or media gateway.

14. VoIP attacks. Illegal control.
If an attacker achieves the credenciales of an
user or an administrator, he has absolute
control:
● Can be used to do calls with high costs:
causing losses to the service provider
and/or end customer.
● Hijacked lines can be used to finish calls
of other customers to which the attacker
sells services
● For illegal activities, makes more
difficult the judicial follow-up of the
calls.

15. WebRTC
vulnerabilities

16. Access to devices. Threats
HTML and JS script are executed by the browser as a
"sandbox" designed to be isolated from the rest of the
computer. However bugs may exist.
WebRTC API needs to access physical devices which
will provide real-time media information (and files):
THREAT: Web pages access to user's camera and
microphone without permissions.

17. Access to devices. Threats
Malicious
WebSever
Users can potentially being recorded with
Javascript code downloaded from a malicious
Web Server.
Malicious
Script
SRTP

18. Websocket.
Websocket (RFC6445): provides a full-duplex socket
between a browser and a server.
It's just a TCP socket upgraded from an HTTP
handshake.
Standardized way for the server to send content to the
browser without being solicited by the client.
Image from http://blog.kaazing.com Image from: http://stackoverflow.com

19. Websocket DoS. Threats
Browser N
Attacked Server
websocket
Malicious
WebSever
Websocket allows cross-origin connection. DDoS attacks
can be implemented in a Web-oriented way.
Browser 1
websocket
httphttp
Malicious
Script
Malicious
Script

20. Websocket cross-protocol attack. Threats
ebsocket
A malicious script could potentially inject code which
is valid in HTTP poisoning HTTP intermediaries (i.e.
HTTP proxy). This is avoided natively by WS RFC.
http://tools.ietf.org/agenda/80/slides/hybi-2.pdf

21. SIPoverWS.
By default it implements digest authentication, however it has
a number of disadvantages:
● Several security options (like 'qop' for integrity) are
optional.
● Vulnerable to man-in-the-middle attacks.
Sending the messages in plain-text is not a good idea, it can
be authenticated but not privacy and integrity.
SDES negotiated over plain-text messages is totally
useless.
SIP traffic can be sent over Websocket: data is sent
over a TCP socket without any encryption. Equivalent
to SIP over UDP/TCP.

22. Protection

23. SIPoverWSS.
SIP traffic can be sent over Secure Websocket: data is
sent over a TLS socket. Equivalent to SIP over TLS.
TLS provides privacy and integrity.
It also provides server authentication, and client
authentication if a client certificate is provided.
If the client certificate is signed by a Trusted Certification
Authority (CA) the real-time communication can have legal
value.

24. Access to devices. Protections
WebRTC standard requires that access to device to be
notified to the user.
Browser notifies the
user that a tab is
currently accessing
media devices. With a
blinking red spot In
Chrome.

25. Access to devices. Protections
Showing own video to the user helps to be aware that
the browser is accessing cam and micro. It also helps to
check if you got your hair done right ;-)
Applications should prevent the user from
automatically clicking on the permission pop-up.

26. Access to devices. Protections
Another WebRTC features like screen sharing could get
you in trouble if it's not properly notified to the user

27. Protection. SDES vs DTLS-SRTP
SIP devices implement
normally RTP encryption
using SRTP with SDES.
They exchange the key in the SDP protocol. It requires
signaling to be encrypted >> TLS.
It is not mandatory (optional) for
Implemented by
Not implemented by
WebRTC forces audio encryption.

28. Protection. SDES vs DTLS-SRTP
DTLS-SRTP manage the SRTP key exchange within the
RTP flow before starting media. This is done using DTLS,
a version of TLS based on datagrams.
Keys are not exchanged in the SDP protocol. It protects
the RTP flow even if signaling is not encrypted.
It is mandatory for
Implemented by
Not implemented by

29. Websocket poisoning. Protection
websocket
http://tools.ietf.org/agenda/80/slides/hybi-2.pdf
Browser Server<Websocket opening handshake string>
*u0!GDDD&GIO[[[ONx<
[&BM#>;:$MMGGDDDF4xOFDA@E6XU7$&UU<'U<!
4U6UY&0OY X$%CIOCBM#HNXDWBK69E
SIP/2.0 200 OK
Via: SIP/2.0/WS NO72tU858jVE.invalid;
branch=z9hG4bKFhlN824OuTkQrgQl7FD8t1ej
vP080E;rport=48095;received=46.
25.57.69
Browser-To-Server
Server-To-Browser

30. DDoS. Protection
DoS and DDoS protections are pretty similar to the
implemented in Web Servers. Attacks can be potentially be
launched from thousands of browsers.
Signaling is going to be received via TCP/TLS: WS, WSS,
REST APIs, etc
Typical attack vectors (SYN flood, RESET attack etc) must
be stopped as soon as possible to limit resources exhaustion
which causes a denial of service.
WebRTC Gateways/servers normally will be exposed to
Internet listening on know ports which are very well known
(443 and 80).

31. ICE. Protection
ICE(RFC5245) allows RTP flows to traverse NAT routers. It
finds the best path for RTP/RTCP traffic.
STUN is used to find out the paths to send the RTP flow.
ICE, includes a handshake designed to verify that the
receiving element wishes to receive traffic from the sender.
This identifier/password are created by the browser and used
during the ICE negotiation. The scripts running on the
browser must send this identifier to each other. The callee
can be sure that

32. Testing your network. Protections
- It's a good practice to test your network with
automatic tools to find vulnerabilities.
- It is a common practice in many IT fields.
- It implements the most common attack vector
you can suffer and it allows you to check your
protections against them.
Quobis has
developed Bluebox,
a node.js-based tool
which allows you to
implement common
as sophisticated
attacks, even over
WS and WSS.

33. Monitoring. Protection
It is possible to monitor all the
traffic, similar to standard SIP.
Similar to SIP over TLS, if
WSS is used (secure
Websockets) monitorization
should be done at the edges
(most usually in the server).
Additional measures can be
applied:
- IP geolocation.
- Access URL.
- Browser info.
- ...

34. ID management

35. Identity management. OpenID vs IdentityCall
By default, WebRTC does not define any authentication method, so
different identity management solutions could be deployed:
● Anonymous calls
● Third party companies
● Third party entities
● Telco authentication
● Strong or Double-factor
authentication

36. Identity management. OpenID vs IdentityCall
Makes possible to be sure of the
identity using a third
party
Adds a second factor of authentications because we
validate the device (smartphone or PC) and the
credentials are introduced ciphered in a SIP
signalling packet.

37. Identity management. IdentityCall

38. Summary

39. What we have learned
● Legacy VoIP attacks could also be
important in WebRTC.
● Access to mic/cam can cause damage.
● Beware of phising in web servers.
● WebRTC provides security by default
(mandatory encryption, access
permissions, etc).
● SBCs and monitoring tools can help.
● Authentication is a must !!!

40. Our offering: SIPPO
SIPPO is the first enterprise-grade WebRTC HTML5 communicator, supporting
audio, video and instant messaging with presence support
SIPPO has been built on top of QoffeeSIP, so it can be connected to any SIP
PBX to provide a complete communication experience just by using a web
browser.
Coming soon:
- File transfer
- Desktop sharing
- LDAP integration
- oAuth support
- Local call recording
Download the
datasheet here

41. Try it yourself!
Basic WebRTC demo: http://webrtc.
quobis.com
Open WebRTC client: http://webrtc.
quobis.com/opendemo
Online meetings with WebRTC http:
//meetings.quobis.com
Sippo (with PSTN connectity) http://sippo.
quobis.com

42. Iago Soto Mata
CMO
@iagosoto
iago.soto@quobis.com
Antón Román
CTO
@antonroman
anton.roman@quobis.com
Elías Pérez Carrera
CEO
@epcarrera
elias.perez@quobis.com
See you in
Any questions?