WebRTC inherits all the threats of traditional VoIP services together with existing web attacks. In this session Antón Román will explain this together with ad-hoc WebRTC attacks and ways to deal with Identity and keep the services secure.
- 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
2. - WebRTC and security?
- VoIP attacks
- WebRTC new threats
- Protection
- Identity Management
- Questions and answers
Santiago Troncoso
@lauskin
Index
4. Open system, no proprietary implementations
No plugins!
Multi platform
WebRTC and security?
WebRTC - Features
5. Multidevice:
● Desktop and laptops
● Tablets and notebooks
● Smartphones
● Mozilla FirefoxOS devices
● Set-top-boxes and WebTVs
More information about
WebRTC is available:
http://www.webrtc.org/home
http://www.quobis.com/
WebRTC and security?
WebRTC - Features
6. ● 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
More information about
use cases available here:
WebRTC and security?
WebRTC - Use cases
7. New potential weak elements in the IC networks in terms of
security:
● Web server (and related elements)
● WebRTC gateway
● Laptop/desktop
used as endpoint
WebRTC and security?
WebRTC - Architecture
8. WebRTC inherits part of the potential VoIP attacks and adds new
threats:
● New network elements to be
hijacked, etc.
● Open communications (new
open ports, etc.)
● Privacy issues through access
to microphones and cams.
RFC Draft:
Security considerations for
RTC-Web
WebRTC and security?
WebRTC - Security efforts
10. 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.
Types of VoIP attacks:
● Denial of service
● Fraud
● Illegal interception
● Illegal control
VoIP attacks
Introduction
11. 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.
● Bugs in terminals
● Viruses
VoIP attacks
Denial of service
12. Also other "non intentional" attacks should be taking into
account:
● Flood after a power blackout.
● Request for action
● Bugs in terminals.
● Viruses.
http://map.norsecorp.com/
Are you free to receive an attack?
VoIP attacks
Denial of service
13. 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 VoIP network. It is also included
the control of a SIP proxy (illegal control) to originate illegal calls.
● These attacks cause not only economic losses. Sometimes the
legitimate user has to pay the bill !!.
● In most cases, it is difficult to determine the
responsibility (customer or operator) of the
attacks.
VoIP attacks
Fraud
14. 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.)
Traditional VoIP SIP traffic is opened, especially
dangerous in Wi-Fi and open networks.
WebRTC uses ciphered traffic for
media, so interception could only
be done in the endpoints or media
gateway.
VoIP attacks
Illegal interception
15. 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.
VoIP attacks
Illegal control
17. The WebRTC technology is included into a Web internet context.
Under that perspective, we are exposed to the Web technologies
vulnerabilities.
Types of WebRTC threats:
● Access to devices
● WebSocket DDoS
● WebSocket poisoning
● SIPoWS interception
WebRTC new threats
Introduction
18. 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.
WebRTC new threats
Access to devices
19. Users can potentially being recorded with Javascript code
downloaded from a malicious Web Server.
Malicious
WebSever
Malicious
Script
SRTP
WebRTC new threats
Access to devices
20. 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.
WebRTC new threats
WebSocket
21. Websocket allows cross-origin connection. DDoS attacks can be
implemented in a Web-oriented way.
Browser N
Attacked Server
websocket
Malicious
WebSever
Browser 1
websocket
httphttp
Malicious
Script
Malicious
Script
WebRTC new threats
WebSocket DoS & DDoS
Browser 2
Malicious
Script
22. 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.
ebsocket
WebRTC new threats
WebSocket poisoning attack
23. SIP traffic can be sent over Websocket: data is sent over a TCP
socket without any encryption. Equivalent to SIP over UDP/TCP.
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.
Sending the messages in plain-text is
not a good idea, it can be authenticated
but not privacy and integrity.
WebRTC new threats
SIP over WebSockets (SIPoWS)
26. WebRTC standard requires that access to device to be notified to
the user.
A secure environment (https connection) will ask for media access only
once. The browser stores the permissions settings for HTTPS sites which
valid certificates.
A good practise is that
your app includes a
specific device access
permission.
Protection
Access to devices
27. 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.
Protection
Access to devices
28. 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.
Protection
Access to devices
29. Chrome 47 will not allow
getUserMedia without HTTPs!
DECEMBER 2015
From https will not be allowed wss,
so encryption is mandatory.
#moreCrypto
#securityByDefault
Protection
Access to devices
30. Elevated permissions
- Installation of a plugin
Protection
Access to devices
Standard permissions
- Specific consent
- Contents selection
- Visual notification on screen.
Screensharing: Hard & soft protection.
32. 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.
Protection
SIP over Secure WS (SIPoWSS)
33. 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
WebRTC Gateways/servers normally will be exposed to Internet listening
on known ports which are very well known (443 and 80).
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.
Protection
DoS & DDoS: WebRTC signaling
34. Click To Call solutions are specially vulnerable to DoS attacks
● Protect your applications
● Control the exposed resources.
● Limit concurrent calls
Protection
DoS & DDoS: Application layer
Web Visitor
Contact Center
35. TURN server is used to go through traversal NAT networks. It
exposes a place (relayed candidates) where to exchange media
between peers.
It exposes BW, an expensive resource, so it must be
protected with credentials (could be long term).
Control credentials
and ports exposed.
Protection
DoS & DDoS: TURN servers
36. 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
Protection
Interception: ICE
37. In every WebRTC SDP there is an hexadecimal fingerprint per
media session. It is a hash of the certificates used in the DTLS
negotiation.
This fingerprint binds the media negotiated on the signaling plane, with
the DTLS session which is negotiated on the media plane.
DTLS itself provides encryption and integrity. If the signaling provides
authentication and authorization, then this also applies to the media.
Protection
Interception: DTLS fingerprint
a=fingerprint:sha-256 D1:2C:BE:AD:C4:F6:64:5C:25:16:11:9C:AF:E7:0F: 73:79:36:4E:9C:1E:15:54:39
More info at: https://webrtchacks.com/anatomy-webrtc-sdp/
38. 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 (actually DTLS stands for Datagram TLS).
Keys are not exchanged in the SDP protocol. It protects the RTP flow
even if signaling is not encrypted.
It is mandatory on WebRTC, so it will be supported by all WebRTC-
capable browsers.
Protection
Interception: DTLS-SRTP
39. It is a good practice to test your network with automatic tools to
find vulnerabilities. It is a common practice in many IT fields.
Quobis has developed and collaborates with Bluebox, a node.js-based
tool which allows you to implement common as sophisticated attacks,
even over WS and WSS.
It implements the most common attack vector
you can suffer and it allows you to check your
protections against them.
Protection
Testing your network
40. It is possible to monitor all the traffic, similar to standard SIP.
Similar to SIP over TLS, if WSS is used (secure Websockets) monitoring
should be done at the edges (most usually in the server).
Additional measures can be applied:
● IP geolocation.
● Access URL.
● Browser info.
● ...
Protection
Monitoring
42. 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
ID management
Identity management
43. Makes possible to authenticate
the user identity using a third
party server.
The web server can act as an
authentication verification
service
ID management
Identity management. OAuth2
44. Makes possible to be sure of the identity using a third
party
ID management
Identity management. OpenID
45. Application PoC developed by Quobis. Provides a second factor
of authentication including personal ID certificates validation.
ID management
Identity management. IdentityCall
46. Possible identity certification options
● Identify and certify
elements is the key
for a secure
communication
ID management
Identity management. IdentityCall
48. ● Legacy VoIP attacks could also be important in WebRTC.
● Access to mic/cam can cause damage.
● Beware of phishing in web servers.
● WebRTC provides security by default (mandatory encryption,
access permissions, etc).
● SBCs and monitoring tools can help.
● Authentication is a must !!!
● #moreCrypto
Summary
What we have learned
49. Sippo WAC orchestrate all elements on a WebRTC communication
scenario.
Improved Web server that can host and provide advanced features for
WebRTC Sippo Apps.
Sippo Apps had been built on top of SippoJS,
so it can be connected to any WebRTC
gateway to provide a complete
communication experience just by using
a web browser.
Summary
Our offering: Sippo WAC
52. Sippo Web Collaborator is an enterprise-grade WebRTC HTML5
communicator, supporting all most relevant collaboration tools.
Features:
● File transfer
● Desktop sharing
● LDAP integration
● oAuth support
● Chat and group chat
● Mobile applications
Summary
Our offering: Sippo Web Collaborator
53. Sippo Click To Call is an application designed for enterprise
customer interception.
Features:
● File transfer
● Desktop sharing
● Chat and group chat
● PSTN forking integration
● Full browser support
● CC features: queues, agents
and reporting
● Feedback forms
Summary
Our offering: Sippo Click To Call
54. Sippo Web Collaborator demo:
https://demo.quobis.com/sippo-2.3
Sippo Click To Call demo:
https://demo.quobis.com/click2call-2.3
Summary
Try it yourself!
55. See you soon!
Santiago Troncoso
@lauskin
santiago.troncoso@quobis.com
Summary
Any questions?