WebRTC Penetration Test
WebRTC is an open framework being standardised by the W3C and the IETF which enables Real Time Communication (RTC) directly between browsers without the need for browser plugins. WebRTC supports both peer-to-peer (P2P) communication as well as communication which requires NAT or firewall traversal by leveraging technologies such as STUN, TURN, ICE and RTP proxies. Furthermore, WebRTC abstracts signalling, allowing developers to choose the signalling protocol (WebSockets, XMLHttpRequest, SIP, XMPP…) that best suits their application.
WebRTC enables direct media-rich RTC applications such as real-time audio and/or video calls, web conferencing and P2P direct data transfer using native browser technology. However, the infrastructure to support these applications is typically complex, mission critical and the perfect breeding ground for vulnerabilities and misconfigurations.
Similar to other RTC applications like VoIP, attacks on WebRTC infrastructure can range from service outages as a result of Denial of Service attacks, to malicious users eavesdropping on confidential communications, and may even escalate to compromise of the WebRTC server infrastructure itself.
What do we cover?
The scope of an WebRTC penetration test will largely depend on the WebRTC stack being used. The following are some common attack targets that are often part of a WebRTC pentest.
- SIP vulnerabilities and misconfigurations (extension enumeration, online password cracking, SIP digest leak)
- Injection vulnerabilities in SDP descriptions and custom signalling protocols
- Eavesdropping on other ongoing audio and/or video streams
- DTLS denial of service, certificate handling and information disclosure vulnerabilities
- Message parsing vulnerabilities
- TURN and RTP proxy server misconfigurations
- Transcoding vulnerabilities, typically leading to denial of service or code execution
The following are some of the techniques that are typically employed in a WebRTC pentest:
- SIP vulnerability testing, when SIP is being used for signalling
- Denial of Service testing for different components of the WebRTC stack (signalling, DTLS, media, TURN…)
- RTP bleed testing
- TURN proxy abuse testing
- Mutational fuzzing to find unexpected denial of service and code execution vulnerabilities
- Authentication bypass testing
- SQL injection, LDAP injection, blind cross-site scripting (XSS) and other types of injection
How does the process look like?
Most of our engagements follow these steps:
- First step is that you contact us
- We ask you a number of questions to understand what you have in mind, the goals for the exercise and the scope
- We perform a scoping exercise to better understand the size of the project; in the case of an VoIP penetration test, the scoping exercise often involves answering questionnaires to better understand the exposure and therefore tailor our proposed work to your needs
- We verify with you our scope where appropriate
- We work on a proposal which describes the goals, the scope, the methodology, deliverables, dates allocated for the project, terms and conditions and the price
- The actual work takes place during the allocated dates; your IT staff involved in the project often need to be available during the tests
- Upon completing the tests, we work on the reports and often provide a brief report of the main findings so that your staff are informed of the results immediately
- The deliverables are provided to you
- Often the process also includes testing of the security fixes once applied
What are the deliverables?
At the end of the project, the client usually receives the following:
- Executive report, which is an easy to follow 4 page report that includes information about the penetration test, list of the findings and a short explanation of the security fixes or mitigation techniques
- Technical report, which includes the following sections:
- Introduction, which describes the scope, methodology and purpose of the work
- Methodology, which describes our tests to explain what was covered and how; this would include both tests that led to vulnerability discoveries, and also those that did not
- Findings and recommendations which are categorised as High security threats, Other security threats and Other concerns and recommendations
- Each finding that is considered a security threat includes:
- A description of the security issue as it affects the target system
- Our assessment of the impact of the vulnerability
- Details on how to reproduce the issue found
- Solutions and recommendations, which are tailored for the target audience and can go into quite some detail
- Other material is sometimes provided such as:
- Video demonstrations showing exploitation of your systems
- Dedicated exploit code to reproduce the security issues found
- When the tests are done on-site, we often brief the involved executives and/or technical team and discuss solutions to the security issues found
- Similarly, conference calls can be used when the work is done remotely
What costs can one expect?
Cost is dependent on the size and complexity of the system on test and the level of rigor in which testing is to be performed. This is determined through pre-sale client discussions and scoping questionnaires. The price of an engagement will be delivered as a fixed bid quote.