Welcome to the February edition of the RTCSec Newsletter! Please do reply and tell me what you think - this will help us make future editions better.
In this edition, we cover:
- The SIPVicious PRO workshop, adapted for security teams
- Ribbon’s EdgeMarc SBCs used to launch DDoS attacks (news from November)
- RTC @Scale security talks
- Release of a new SIP tool called sipexer
- Vulnerabilities in various critical software, including PJSIP
- Smart Probes by Intuitive Labs
RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security. We cover both defensive and offensive security as they relate to Real-time Communications.
What is RTC security anyway? Real-time communications security is what determines if you can communicate in real time in a safe way - whether it be with other humans or machines.
You may sign up to receive the RTCSec newsletter here. Do:
- forward to that person who may find this newsletter particularly fruitful.
- let me know if we should include or cover any RTC security news.
To view past issues, please visit our website at https://www.rtcsec.com/newsletter.
SIPVicious PRO introductory workshop - for security teams and testers
We train new SIPVicious PRO members (subscribers) by doing a 4 hour introductory workshop. This training session was originally designed for VoIP engineers, thus knowledge of SIP, RTP and call flows was assumed in designing the training material.
But, of course, security teams are the ones purchasing a subscription and benefit greatly from using SIPVicious PRO internally. Unfortunately, knowledge that is basic for VoIP developers is often quite lacking or absent for the security folks.
That’s why we’re updating our workshop so that it can cover the basics, at least those needed for usage of SIPVicious PRO and security testing of VoIP and RTC environments.
I’m working on a section which covers just the bare minimum of SIP especially with regards to the call flow, an explanation of SIP methods such as REGISTER and INVITE (but not, for example, SUBSCRIBE and NOTIFY), common response codes and some basic understanding of the media in terms of RTP and RTCP.
Any other suggestions? Send me an email: email@example.com
Consultancy subscription (advert)
Last year we made our consultancy service a bit more publicly available. If you have not seen it yet, check out https://www.enablesecurity.com/consultancy/.
Now this year, we started offering our consultancy as a monthly subscription. What we do is that we organize a number of hours throughout the month that are dedicated to working with your security teams, developers and testers. We’re flexible on this but usually the aim is to do the following with your team(s):
- Automated testing processes planning / help with setup (e.g. to set up automated security tests and fuzzing)
- Security testing of specific features
- Knowledge transfer (more “hacking together” in live video sessions rather than prepared training)
- Coaching etc
Sounds interesting? Reply to this newsletter or email us: firstname.lastname@example.org.
EdgeMarc SBC VoIP servers used to launch DDoS attacks
This is some news that escaped me back in November:
AT&T said it’s investigating and has “taken steps to mitigate” a botnet that infected more than 5,700 VoIP servers located inside its network, a spokesperson has told The Record earlier today.
All the infected devices were EdgeMarc Enterprise Session Border Controllers, a type of Voice-over-IP server designed to balance and reroute internet telephony traffic from smaller enterprise customers to upstream mobile providers.
The affected SBC equipment was originally owned by Edgewater which was acquired by Ribbon back in 2018.
This is interesting for us because we often see Ribbon equipment on the systems and VoIP environments that we test during penetration testing. However, in the environments that we test, we never actually see HTTP interfaces being exposed. Thus, we never came across the vulnerability that was abused to compromise these SBCs - CVE-2017-6079. There are various reasons for this of course, but in most cases, the administrative (web) interfaces are not exposed externally. Apparently, not in the case of the 5,700 VoIP servers in the AT&T network that were compromised by the botnet. Or the 100,000 servers that appear to be exposed on the Internet.
In the article on The Record, AT&T said that there is no evidence that customer data was accessed. But of course, once you have shell access to any of these devices, all sorts of valuable data is in your hands. Call detail records (CDR), possibly the audio calls themselves can be recorded and so on.
The original post and research by NetLab focuses on the botnet and gives the technical details for those interested in that.
RTC @Scale 2022 security talks
A virtual event called RTC @Scale 2022 happened on February 16th and organized by Meta (Facebook). The afternoon sessions (session 4) were all about RTC security, with the following titles:
- Making Meta RTC Audio More Resilient - Andy Yang, Meta
- Private Calling at WhatsApp - Xi Deng, Meta
- Group Call End-to-End Encryption and the Challenges of Encrypting Large Calls - Abo-Talib Mahfoodh, Meta
Have not watched any of the sessions myself but I hope that they are published since the topics covered as naturally of interest. Also, heard good things on the twitters about the event!
Modern and flexible SIP (RFC3261) command line tool.
sipexeris a cli tool that facilitates sending SIP requests to servers. It uses a flexible template system to allow defining many parts of the SIP request via command line parameters. It has support for UDP, TCP, TLS and WebSocket transport protocols, being suitable to test modern WebRTC SIP servers.
It is written in Go, making me an instant fan and seems extremely flexible with lots of arguments and template functions and variables. Tools like this are always useful especially when it comes to doing SIP over WebSocket and doing fancy stuff with templates - including manual security testing. Here’s a quick run against our demo server:
sipexer udp:demo.sipvicious.pro:5060 [info] [sipexer.go:1260] main.SIPExerDialogLoop(): local socket address: 192.168.188.69:47029 (udp) [info] [sipexer.go:1261] main.SIPExerDialogLoop(): local via address: 192.168.188.69:47029 [info] [sipexer.go:1262] main.SIPExerDialogLoop(): sending to udp 220.127.116.11:5060: [[--- OPTIONS sip:demo.sipvicious.pro:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.188.69:47029;rport;branch=z9hG4bKSG.303d73d0-9309-4c1b-8c5b-5b1f3d5561db From: <sip:alice@localhost>;tag=344b8149-bbe7-4718-999f-ab889ab1981a To: <sip:bob@localhost> Call-ID: e0956601-4772-44d9-911c-e377cf8f01a9 CSeq: 501999 OPTIONS Date: Fri, 25 Feb 2022 07:07:50 CET User-Agent: SIPExer v1.0.0 Content-Length: 0 [info] [sipexer.go:1264] main.SIPExerDialogLoop(): ---]] [info] [sipexer.go:1315] main.SIPExerDialogLoop(): response-received: from=18.104.22.168:5060 bytes=421 data=[[--- SIP/2.0 200 Keepalive Via: SIP/2.0/UDP 192.168.0.64:47029;rport=13045;branch=z9hG4bKSG.303d73d0-9309-4c1b-8c5b-5b1f3d5561db;received=22.214.171.124 From: <sip:alice@localhost>;tag=344b8149-bbe7-4718-999f-ab889ab1981a To: <sip:bob@localhost>;tag=1fe0194448ea45615c07045ea73eef56.5da6da29 Call-ID: e0956601-4772-44d9-911c-e377cf8f01a9 CSeq: 501999 OPTIONS Server: kamailio (5.4.6 (x86_64/linux)) Content-Length: 0 [info] [sipexer.go:1317] main.SIPExerDialogLoop(): ---]]
Vulnerabilities of the month
- Zyxel Buffer Overflow / File Disclosure / CSRF / XSS / Broken Access Control Vulnerabilities
- Getting access to SIP credentials, among other things when you compromise this device. When people ask me about compromising SIP credentials - yes there still is password guessing of course, but there are too many other ways that SIP credentials can be leaked. Compromising customer premises equipment (CPE) is certainly one of them.
- PJSIP vulnerabilities fixed in version 2.12
- The PJSIP project released fixes for 4 vulnerabilities in the past few days, 3 of which are considered high severity. I’m wondering if and how they affect third-party software such as Asterisk, that relies on this library.
- Asterisk did get a bump in the version of pjsip here: https://github.com/asterisk/third-party/commit/5165c788a16ca292e114d756b71122fcad71cb1c, which, according to the release notes from pjproject, includes the security issue fixes. Thanks to our friends Torrey Searle and Dan Jenkins for pointing me in the right direction!
- Potential out-of-bound read during RTP/RTCP parsing
- Should not affect Asterisk since they do their own RTP/RTCP parsing.
- Prevent OOB read in multipart parsing
- This one is likely to affect Asterisk, comments welcome!
- Use after free of dialog set
- Potential buffer overflow in pjsua_player_create(), pjsua_recorder_create(), pjmedia_wav_player_create(), and pjsua_call_dump()
- This one is considered low severity by the PJSIP team. Looking at the CVE description it seems that the buffer argument for
pjsua_call_dump()would need to be attacker-controlled. This argument is used to set the buffer where the statistics are to be written to.
- Other vulnerabilities were actually fixed in 2.12.
- BIG-IP SIP ALG vulnerabilities
- Supposed to be a DoS due to a null pointer dereference. Affects BIG-SIP setups that have SIP ALG enabled. If you’re running anything like a stateful firewall, disabling SIP ALG will reduce your attack surface.
- Vicidial SQL injection vulnerability
- Vicidial is an open-source contact center solution. According to the advisory, authenticated agents or managers are able to abuse an SQL injection in this software. This vulnerability does not appear to have been fixed. Do reply to me if you have updates on this.
- Dbltek GoIP - VoIP-GSM gateway device - Local File Inclusion
- Pexip WebRTC vulnerabilities:
- CVE-2022-25357: Insufficient authorisation checks in the call join implementation under certain circumstances allows a window where an unauthenticated remote attacker could join a locked but not PIN-protected conference.
- CVE-2022-23228: Insufficient input validation in the WebRTC implementation allows an unauthenticated remote attacker to cause excessive resource usage leading to a temporary loss of service.
Smart Probes: Beyond Elastic’s DIY SIEM
Jiri Kuthan from Intuitive Labs posted on Linkedin about their Smart Probes that are able to detect VoIP fraud and DoS attacks by making use of Elastic Search. Read his post here: https://www.linkedin.com/posts/jirikuthan_proble-for-collecting-encrypting-and-anonymizing-activity-6896562502445191168-YItk
Or check their VoIP probe called sipcmbeat here: https://www.intuitivelabs.com/sipcmbeat
This newsletter was prepared by Sandro Gauci and the Enable Security team for the RTCSec newsletter subscribers. If you have someone in mind who would benefit from our content, please do share.
To subscribe: here