It’s been a month already since the Kamailio World RTC security chat! The conversation included Daniel-Constantin Mierla and Olle E. Johansson from the Kamailio project and myself. Daniel is the lead developer of Kamailio, can be found at ASIPTO while Olle is behind Edvina.net.
If you don’t have time to watch the entire conversation, the following is my summary of this discussion:
Introductions and discussions
After introductions from Daniel, I took lead to briefly mention what we at Enable Security have been up to, including our work on SIPVicious PRO, our research on WebRTC security especially regarding the TURN server abuse vulnerability, our work on DoS in VoIP and WebRTC infrastructure and finally, research on how Kamailio may be (mis)configured to introduce vulnerabilities. Olle thanked us for (some of) our work, and then suggested that there may be holes in the code somewhere (referring to Kamailio). I mentioned my concerns about issues in modules that might not be part of the core which are less tested than others, as well as specific configuration in Kamailio, especially involving string concatenation, that can introduce vulnerabilities when it involves user input.
Then there was a short conversation about how likely it is to have SQL injection in Kamailio. Olle suggested that due to the database connectivity, SQL injection might be a concern while I said that we did not come across this in the Kamailio configurations that we looked at. Daniel then mentioned that escaping that is being done in the C code itself, but if one is using the sqlops module in their Kamailio configuration, then it is up to that configuration to make use of a transformations for SQL escaping in the Kamailio interpreter. He mentioned that on the other hand, in the Kamailio code developers should be using an internal API for escaping and intermediate layer that should be addressing SQL injection.
Olle then moved on to talk about his past work and ambition to find clients that really want him to build RTC systems that are actually secure. He gave the example of one of his clients that bought a solution consisting of secure SIP gateways and phones which in reality made use of self-signed certificates and shared certificates and private keys across each phone; he thinks that we’re still at that stage when it comes to secure VoIP. From our part, we admit to having seen similar solutions, especially when often advertised as military grade encryption. Olle also mentioned how the standards do not really describe how to make SIP more secure, then moved on to WebRTC and how it is meant to be secure by design but that it doesn’t mean that the WebRTC infrastructure is necessarily secure. He spoke about WebRTC gateways having the same DTLS certificate for many, many sessions for a long time. This I complemented by mentioning our report for Slack on HackerOne, where a publicly available self-signed certificate and private key were used for a long while for DTLS.
Olle continued with his point that people write their own implementations of parts of the WebRTC infrastructure and WebRTC applications which is likely to be problematic security-wise. He thinks that WebRTC solutions in general have opportunistic privacy, where encryption happens but you cannot verify who you are communicating with. Additionally, WebRTC, similar to SIP, has a lot of standards and documents which add up to the security confusion. He then moved on to talking about how SIP digest authentication now supports SHA (referring to RFC 8760) as an alternative to MD5 digest authentication, which is great but that he’s concerned about downgrade attacks on that.
He also started talking about the oAuth authentication in SIP (RFC 8898) which is quite an interesting standard; he is particularly concerned about how tokens are transported. I mentioned how oAuth systems break when it comes to web applications, which often involves being able to redirect the victim user to an attacker machine leaking the oAuth token, thus allowing for authentication bypass. Olle mentioned that tokens from the IdP should be encrypted using the SIP server’s public key.
At this point, I tried to give my point of view of how often standards seem to be developed which introduce (sometimes by design) new security holes that were somehow missed or ignored during the design stage. Olle explained how he is on the other side where they design and develop these standards.
Then we spoke of SIP TLS, where Olle asked how much SIP TLS we’ve tested. I explained that in the past 2 or so years, we saw SIP TLS being deployed more and more than ever before. He asked if we’ve tested these implementations, especially certificate verification. To that, I responded that often the question is if the certificates are actually being verified. I hinted that especially with hardware phones we noticed that certificate checking is often switched off. I also mentioned how sometimes you have SIP TLS enabled but plaintext RTP is still used, and how one often can’t really enforce (in the protocol) SRTP just because SIP TLS is enabled. In the SIP or VoIP world, I explained, especially with legacy systems out there, security has been mostly patchwork. What I do like about WebRTC is that, even if more security testing is needed, at least the basic vulnerabilities are addressed at standards-level. Olle agreed and added how Kamailio has been upping the level in terms of TLS security.
On working from home and secure RTC
Daniel jumped in to refocus the discussion on working from home and RTC, asking for practical advice about what actually works in terms of secure communications. Olle responded with recommending WebRTC over choosing traditional VoIP and I agreed with Olle. I made the point that a good part of the web applications world has moved to a zero trust model. For RTC, moving from traditional VoIP to WebRTC systems that support systems that play nicely with the rest of the Internet and avoiding the usage of corporate VPNs, is the natural way forward.
Conclusions
I ended my part by mentioning that I’d like to see more focus on offensive security in the RTC world by doing better simulations of hacker attacks rather than implementing untested security solutions. I emphasised showing proof of security problems before investing in solutions that address that particular security problem.
Olle wrapped up by suggesting that the SIP platforms are often managed by telephony people that don’t understand network and application security. He thinks that both parties need to meet and focus on building better platforms and getting people like Enable Security to test it after people like Olle build it with security as part of the design of such systems.
I’d like to thank Daniel for inviting me to this conversation, hope to do this again in the near future.
