OpenSSL DoS and DTLS, SIMBoxes, SIP-TLS and lots of advisories

Published on Mar 29, 2022

And a warm welcome to the March edition of RTCSec Newsletter! We have new content for this newsletter, in the form of a video demo of an OpenSSL DoS (CVE-2022-0778). We’ll publish more about this on our blog.

In this edition, we cover:

OpenSSL DoS (CVE-2022-0778) versus WebRTC infrastructure
Usage of SIMBoxes to evade Ukrainian phone companies blocking external phone calls
VoIP calls and TLS security instructions
Vulnerability reports for PJSIP, Asterisk, Mitel, Pascom, VoIPmonitor, 3CX and Cisco equipment

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.enablesecurity.com/newsletter/.

Our news

We are preparing a new list called Offense and defense: RTC security tips. When launched, we will send out tips every 2 weeks. Here are some examples of tips that we would like to cover:

RTP bleed protection for rtpengine
how to use SIPVicious OSS or nmap to find SIP devices
preventing digest leak in Kamailio / OpenSIPS
preparing for volumetric DDoS
how to manually detect if SIP extension enumeration is possible
fingerprinting SIP devices manually, without a user-agent or server header

If this is interesting for you, subscribe here: https://www.enablesecurity.com/subscribe/ Be sure to share this with your colleagues and anyone who may also benefit.

Subscribe to the RTC security tips list

OpenSSL DoS (CVE-2022-0778) versus WebRTC infrastructure

Philipp Hancke teased me into checking how the latest OpenSSL DoS vulnerability affects servers doing DTLS certificate parsing, such as WebRTC servers.

A few hours later, we had a hacked up SIPVicious PRO to send the custom malformed certificates when generating a call over WebRTC infrastructure. We used the certificate created by Riccardo Zanotto on his github page. Finally, we put out a video showing exploitation against our demo server which runs an RTPEngine instance that uses a vulnerable version of OpenSSL.

So, check out our video at https://youtu.be/A-2lYuPjAI0

Interested in Meta’s (Facebook) RTC security efforts?

The previous month, Facebook had a virtual WebRTC event called RTC@Scale. Of interest to us was the “Resilience and Encryption” track that naturally covers our favorite topic. If this is of interest, then we should redirect you to the BlogGeek.me site that has an excellent summary of what went on: https://bloggeek.me/rtcscale-summary-and-insights/.

Other references:

Official RTC@Scale 2022 page: https://www.facebook.com/watch/1576488989290866/966302517337100

As part of our security audit and penetration tests, we simulate DDoS attacks on RTC applications and infrastructure. Reply to this newsletter or contact us for more information: https://www.enablesecurity.com/contact.

VICE article on hacker abusing the phone network to help Russians in Ukraine

Joseph Cox published an article on Vice about a hacker aiding the Russian military by routing their calls through a SIMBox.

These are devices that take a set of mobile phone SIM cards and route incoming calls over the Internet, typically using SIP. In normal situations, they are used to commit fraud by offering cheaper rates than the local phone company. In this case, however, they were actually used to bypass Ukrainian phone companies’ blockage of Russian and Belarusian destination phone numbers.

Such activity is of course quite easy to detect for phone companies, and is definitely not military-grade.

Reference: https://www.vice.com/en/article/v7djda/ukraine-arrests-hacker-routing-calls-for-russian-troops

VoIP calls and TLS security

Giovanni Tommasini wrote about how to use Let’s Encrypt certificates with Kamailio. His work references Fred Posner’s previous article on the topic and Giovanni published a github repository with a docker-compose setup ready to be used. This is as easy as it gets to get SIP-TLS working on the Internet with a certificate that is trusted by most system certificates stores.

Read the article here: https://blog.giovannitommasini.info/voip-calls-and-tls-security

Incidentally this is very similar to how we make use of Let’s Encrypt certificates on our demo server at https://demo.sipvicious.pro, both for Nginx for HTTPS as well as Kamailio for SIP-TLS and secure websocket on port 8443.

CUCM username enumeration

N00py published a blog post about enumerating Cisco Unified Communications Manager users (CUCM). His research started while he was testing out SeeYouCM Thief (which we covered 2 months ago) and came across a feature on CUCM called “User Data Services” (UDS) which is a REST API. Long story short, UDS allowed recovery of usernames without any authentication. Since the CUCM setup on test was linked to Active Directory, n00py ended up with AD user enumeration.

CUCM administrators who want to close this issue have to enable “Contact Search Authentication” as described here: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/11_5_1/cucm_b_release-notes-cucm-imp-1151/cucm_b_release-notes-cucm-imp-1151_chapter_010.html#task_AE831C159B03176B3451FB5834A5C0B0

The original blog post can be read here: https://www.n00py.io/2022/01/unauthenticated-dumping-of-usernames-via-cisco-unified-call-manager-cucm/

More on PJSIP’s vulnerabilities fixed last month

We covered the advisories issued by PJSIP on the February edition of this newsletter, and how they might affect Asterisk. The original reporters from JFrog have now issued technical details about the PJSIP vulnerabilities on their blog, here: https://jfrog.com/blog/jfrog-discloses-5-memory-corruption-vulnerabilities-in-pjsip-a-popular-multimedia-library/.

The vulnerabilities are tracked under the following CVEs:

CVE-2021-43299 - Stack overflow in PJSUA API when calling pjsua_player_create
CVE-2021-43300 - Stack overflow in PJSUA API when calling pjsua_recorder_create
CVE-2021-43301 - Stack overflow in PJSUA API when calling pjsua_playlist_create
CVE-2021-43302 - Read out-of-bounds in PJSUA API when calling pjsua_recorder_create
CVE-2021-43303 - Buffer overflow in PJSUA API when calling pjsua_call_dump

It looks like by mentioning 3rd party software such as Asterisk, WhatsApp and BlueJeans, journalists covering this might have assumed that these third-party applications are necessarily vulnerable. In their blog post, the JFrog security team tried to clarify that they did not actually test software that relies on the PJSIP library and only tested the library itself.

Clearly, as the next section shows, Asterisk was vulnerable to some of these issues.

Asterisk advisories of the month

Asterisk released 3 advisories this month:

AST-2022-004 / CVE-2021-37706: pjproject: integer underflow on STUN message
AST-2022-005 / CVE-2022-23608: pjproject: undefined behavior after freeing a dialog
AST-2022-006 / CVE-2022-21723: pjproject: unconstrained malformed multipart SIP message

With regards to the multipart issue, the Asterisk developers are not sure if it really a problem but they issued an advisory anyway. Then, the STUN issue is relevant when ICE/WebRTC support is switched on (not default). Finally the “use after free of dialog set” is marked as a major vulnerability too.

References:

CVE-2022-26143: Mitel MiCollab and MiVoice Business Express used to launch DDoS attacks

Mitel MiCollab phone system has a vulnerability that may be abused in UDP amplification attacks, i.e. be used to launch DDoS attacks. The impressive thing about this issue is the amplification factor of 220 billion percent.

To abuse this issue, attackers need to find Mitel equipment that runs tp240dvr (“TP-240 driver”) on UDP port 10074 that happens to be exposed to the Internet. Then the attacker needs to be able to send a debugging command startblast from a spoofed IP address which belongs to the target victim organisation. When this is done on a wide scale, attackers get to do bandwidth saturation DDoS attacks for free.

The vulnerable TP-240 driver can also be used for other purposes, such as toll fraud.

This issue was abused in the wild by booter DDoS services which is why it is such a great deal.

Kerbit blog posts about Pascom and VoIPmonitor

Security researchers at Kerbit released two interesting blog posts:

Pascom: The story of 3 bugs that lead to unauthed RCE.
Multiple vulnerabilities in VoipMonitor.

In the case of Pascom’s phone system, they essentially chained three different vulnerabilities to get remote code execution. The first vulnerability was a path traversal in the Nginx proxy. This allowed them to reach any application on a Tomcat server behind Nginx. This in turn, exposed an Openfire (XMPP) server that had an SSRF vulnerability - this being the second vulnerability in the chain. This SSRF issue was then used to reach a localhost web service that exposes a (random) password for the user moby. These credentials could then be used to schedule a task that is executed by a Perl script that runs as root.

Read the full post here: https://www.kerbit.io/research/read/blog/4

The second post is about the VoIPmonitor GUI where they found multiple vulnerabilities, such as authentication bypass, SQL injection and remote code execution.

Read the full post here: https://www.kerbit.io/research/read/blog/3

Great work by the Kerbit team as well as Pascom and VoIPmonitor for getting these fixed!

Two advisories for 3CX published and a hotfix from 3CX for a separate issue

Emanuel Duss from Compass Security reported 2 medium severity security issues in 3CX phone system components:

CVE-2021-45490: Missing Certificate Verification
CVE-2021-45491: Exportable Cleartext Passwords

In the first case, the subject of the advisory explains everything. The Windows (legacy), Android or iOS clients simply do not verify the TLS certificate of the 3CX server. This allows man-in-the-middle attackers to get the provisioning data which would typically include credentials and so on.

As for mitigation, the advisory says:

According to the 3CX, the vulnerability will be tackled in future redesigns of the mobile apps.

Users of the legacy Windows client can switch to the new Electron based 3CX Desktop App which is not affected.

The second issue has been well known since a few years according to the references to German 3CX forums but does not appear to be addressed yet.

The advisory says that:

There is no security update for this vulnerability at the moment. According to the 3CX, the vulnerability will be tackled in future redesigns of the management console.

Advisories here:

3CX also published a hotfix with the following basic information in their changelog:

Fix for a security vulnerability
Fix of memory leak affecting business systems in particular conditions
Fix for application crash of the call manager if under DDOS attack.

If you use 3CX’s software, do upgrade as we’re told these are high or critical severity vulnerabilities. See their post here: https://www.3cx.com/blog/releases/v18-security-hotfix/.

Cisco fixed two critical flaws in Expressway, TelePresence VCS solutions

Reference: https://securityaffairs.co/wordpress/128627/security/cisco-expressway-telepresence-vcs-flaws.html

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