- VoIP attacks Denial of service. Fraud. Illegal interception. Illegal control. - Adhoc WebRTC attacks: malicious HTML code. Webservers. Forced DoS. Cam/mic control. Etc. - Protection: Role of border elements (SBC, media gateways,...). WebRTC Portal and web servers. Browser mechanisms - Identity Management: Anonymous calls. OpenID and third parties. Telco identity. Real implementations

1. SECURITY AND IDENTITY
MANAGEMENT ON WEBRTC

2. Agenda
1. Introduction into WebRTC security
- VoIP attacks
- WebRTC vulnerabilities
- Protection
- Identity Management
2.WebRTC, IMS, Security and Identities
Víctor Pascual
@victorpascual
Antón Román
@antonroman

3. Introduction into
WebRTC security

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

5. WebRTC. Features.
Multidevice:
○ Desktop and laptops
○ Tablets and notebooks
○ Smartphones
○ Set-Top-Boxes and WebTVs

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 (e-health,...)
○ Extended RCS/Joyn services
○ Online videogames

7. WebRTC. Architecture.
New elements introduced in the UC networks requires
new considerations 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 other
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 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. Access to screen capture. Threats
Malicious
WebSever
SRTP
Malicious
Script
Security in screen sharing is specially critical as
very sensitive information can be stolen.

19. Websocket.
Websocket (RFC6445): provides a full-duplex socket
between a browser and a server.
It is 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

20. 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

21. 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

22. Signaling sent over not TLS connection.
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.
Signaling traffic can be sent over Websocket: data is
sent over a TCP socket without any encryption.
Equivalent to SIP over UDP/TCP.
Sending all the signaling over TLS is a must!

23. Security of TURN server.
TURN is necessary in many WebRTC scenarios to
establish bi-directional flows.
Media relaying is an expensive resource so it is
protected with credentials.
Those credentials can be long-term, if these
credentials are stolen the TURN server can be
abused.

24. Security in Click-to-call solutions
● Click to call solutions are potentially easy to be
attacked.
● The WebRTC Click2Call solution server must
implement mechanism to make sure the user is calling
from a trusted site and limit the amount of calls from
one location.
● Controlling the total amount of calls also will help to
minimize DDoS.
Web Visitor
Contact Center

25. Protection

26. Signaling over TLS.
SIP traffic can be sent over Secure Websocket: data is
sent over a TLS socket. Equivalent to SIP over TLS.
TLS provides privacy, integrity and authentication.
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.
Using, HTTPS and WSS is necessary when working with
WebRTC. For example: Screen sharing only works
from HTTPS sites!

27. Access to devices.
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.

28. Access to devices.
Showing own video to the user helps to be aware that
the browser is accessing cam and micro.
The browser stores the permissions settings for HTTPS
sites which valid certificates.

29. Access to devices.
Screen capture requires to type of permissions:
2. Always active user content
1. Elevated permissions (in practice means installing a plugin once)

30. Websocket poisoning.
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=z9hG4bKFhlN824OuTkQrgQl7FD8t1ejvP08
0E;rport=48095;received=46.25.57.69
Browser-To-Server
Server-To-Browser

31. DDoS.
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 in
Internet listening on well-known ports (443 and 80).

32. DTLS-SRTP for media encryption
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
A fingerprint is included in the SDP to create a
security relationship between the SDP and the
DTLS-SRTP flows.

33. ICE.
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.

34. Monitoring.
It is important monitor all the traffic the same way it is done
with SIP traffic.
It is possible to gather even more information for WebRTC
sessions:
● IP geolocation.
● Host URL.
● Browser info.
● Contextual info.

35. ID management

36. Identity management.
WebRTC does not force any authentication method.
WebRTC API exposes an authentication API based on Identity
Providers which can be:
● Ad-hoc solutions
● Social networks
● Certification Authorities (private or
public)
● Telco authentication
IdP protocols: OpenID or BrowserID, Federated Google Login,
Facebook Connect, OAuth, WebFinger

37. Identity management. OpenID
Makes possible to be sure of the
identity using a third
party
New opportunity for operators as
Identity Providers: Mobile number
as Trusted Identity

38. Identity management.
+----------------+
| |
| Signaling |
| Server |
| |
+----------------+
^ ^
/
HTTPS / HTTPS
/
/
v v
JS API JS API
+-----------+ +-----------+
| | Media | |
Alice | Browser |<---------->| Browser | Bob
| | (DTLS+SRTP)| |
+-----------+ +-----------+
^ ^--+ +--^ ^
| | | |
v | | v
+-----------+ | | +-----------+
| |<--------+ | |
| IdP1 | | | IdP2 |
| | +------->| |
+-----------+ +-----------+
WebRTC API defined by W3C
Alice and Bob have relationships
with some Identity Provider (IdP) that
supports a protocol such as OpenID or
BrowserID, Federated Google Login,
Facebook Connect, OAuth, WebFinger)
that can be used to demonstrate their
identity to other parties.

39. Identity management.
+--------------------------------------+
| Browser |
| |
| +----------------------------------+ |
| | https://calling-site.example.com | |
| | | |
| | Calling JS Code | |
| | ^ | |
| +---------------|------------------+ |
| | API Calls |
| v |
| PeerConnection |
| ^ |
| | MessageChannel |
| +-----------|-------------+ | +---------------+
| | v | | | |
| | IdP Proxy |<-------->| Identity |
| | | | | Provider |
| | https://idp.example.org | | | |
| +-------------------------+ | +---------------+
| |
+--------------------------------------+
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:
ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n
dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v
cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs
XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==
t=0 0
m=audio 6056 RTP/SAVP 0
a=sendrecv
WebRTC API defined by W3C

40. Identity management.
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.
Certification Authority
Certificate
verification
Example of Identity Management

41. WebRTC, IMS,
Security and
Identities

42. WebRTC access to IMS

43. WebRTC access to IMS

45. Reference Model
WebRTC IMS Client (WIC)
P-CSCF enhanced for WebRTC (eP-CSCF)
IMS-AGW enhanced for WebRTC (eIMS-AGW)
WebRTC Web Server Function (WWSF)
WebRTC Authorization Function (WAF)

46. Registration and authentication
SIP/IMS vs Web Authentication

47. WebRTC is signaling agnostic, SIPoWS is just one
option

48. SIP can be used with Web Authentication

49. IMS can be used with Web Authentication

50. Authentication of WebRTC IMS Client with IMS subscription using web
credentials

51. Control plane security

52. Media plane security

53. Media security for RTP

54. Media Security for WebRTC DataChannels

55. NAT traversal
In order to traverse restrictive-firewalls one could also use TCP/TLS transport. Some, are even
multiplexing that over HTTP-based connections

56. Firewall and HTTP proxy traversal

57. Additional Considerations

58. Specs perspective

59. How is it really deployed in the real world?
other existing systems
Experience from 100+ field trials/POCs

60. Customer Use Case: Service Provider in CALA

61. Customer Use Case: Service Provider in EMEA

62. Customer Use Case: Service Provider in APAC

63. Summary

64. What we have learned today
● Legacy VoIP attacks could also be
important in WebRTC.
● WebRTC provides security by default
(mandatory encryption, access
permissions, etc).
● Care should be paid to Authentication
and Identity Management

65. Planning to be in Barcelona during MWC15?
Quobis' booth (#CS60, Spanish Pavilion) will showcase "Sippo
WebRTC Application Controller" to service providers and network
equipment vendors, showing them how to introduce new value-
added WebRTC services to their residential and corporate
customers, hiding the complexity behind the different
implementation of the standards by web browsers and gateway
vendors and providing a complete set of APIs to manage AAA,
user provisioning, contact management, policy control and other
features.
mwc@quobis.com

66. Planning to be in Barcelona during MWC15?
Register today for this free event at http:
//www.meetup.com/WebRTC-Barcelona