Hope you had some lovely holidays in August! And if not, what are you waiting for? This month we’re keeping the short news section and inviting people to participate in the upcoming edition of OpenSIPit!
In this edition, we cover:
- our latest news and how to keep us in business
- Android security - 2G and VoLTE
- Zoom and AudioCodes vulnerabilities revealed at Blackhat
- Skype IP leak and how this is more common in RTC than assumed
- Memory corruption in Qualcomm chipsets handling VoLTE EVS audio (CVE-2022-40510)
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 us 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.
Our news
What’s new at Enable Security?
Besides providing security audits and pentesting for our clients, we have been creating our own libraries for handling DTLS, STUN, SDP, RTP, and enhancing our internal fuzzers to support more specific security tests.
This code is very valuable for our current security testing projects and for future ones in the field of VoIP and WebRTC security.
If you are thinking of working with us in the next year, don’t hesitate to contact us now.
OpenSIPit’s open invitation for RTC projects interested in SIPREC, security, performance and more!
Are you ready for the next OpenSIPit event? It’s happening from September 18 to 22, and the OpenSIPit crew is busy preparing for it.
We’re excited to participate and contribute as usual, by testing different implementations and finding potential bugs. This is also a great chance for us to check our own software implementations and libraries that we develop internally. This time, we’re interested in these topics:
- SIPREC
- STIR/SHAKEN recap
- DTLS
- Performance
- Security / DoS
If you have a software project that could benefit from joining, don’t miss this opportunity and fill in the RSVP!
Application DDoS resilience testing [advert]
Would you like to find out where your critical services are weakest so that they can be made more robust? Get in touch or reply to this newsletter.
What’s happening?
Android allows disabling 2G support
Google’s blog post:
The obsolete security of 2G networks, combined with the ability to silently downgrade the connectivity of a device from both 5G and 4G down to 2G, is the most common use of FBSs (false base stations), IMSI catchers and Stingrays.
This is why Android now allows disabling 2G support, even for IT administrators who manage their device fleet. It is progress as the security of 2G has been considered broken since years. On the other hand, I can’t help but think about the attack surface of 4G and 5G and how more complex it is. In fact, Mathew Solnik posted the following tweet:
LTE/5G IMO is LESS secure than 2G when it comes to true RCE (no fake basestation) part 2:
@natashenka’s presentation on Shannon hacking is one of the best overviews on true remote baseband hacking I have seen in a long time! Amazing work Natalie!
Dealing with carrier filtering/packet modification has been a bane of my existence since 2014. I mentioned it in my slides back then too!
https://hardwear.io/usa-2023/presentation/how-to-hack-shannon-baseband.pdf
https://m.youtube.com/watch?v=NnmAikOTHaA
Link to my old talk:
https://2014.ruxconbreakpoint.com/assets/2014/slides/bpx-solnik-BreakPoint2014-Final.pdf
P.S. If you made it this far down - my next tweet will talk about why nation state (or even just well funded private entities) have less issues with carrier filters than standard researchers.
And then this tweet:
LTE/5G IMO is LESS secure than 2G when it comes to true RCE (no fake basestation).
The IMS/VoLTE stacks can be hit from anywhere in the world with just a phone number.
Media parsing, XML, etc… Android in baseband, iOS in userland.
Plenty of 0days to be found. Have fun!
P.S. Project Zero has dropped some fun bugs @natashenka
P.P.S. I can confirm this area has been a heavily hit target by offensive companies for years. I’m taking a break from cellular so I figured I would drop some fun info.
Not much to add except that yes with modern mobile networks, there is a lot to parse, a lot of protocols to handle, a lot more business logic, more encryption and more of everything. And XML. What can possibly go wrong?
Presentation at Blackhat USA about Zoom and AudioCodes vulnerabilities
Moritz Abrell, a security researcher from SySS, presented a Blackhat talk called Zero-Touch-Pwn - Abusing Zoom’s Zero Touch Provisioning for Remote Attacks on Desk Phones. During this presentation, he showed how malicious users could abuse a series of vulnerabilities in Zoom’s phone management system, AudioCodes’ provisioning and AudioCodes IP Phones.
The job of provisioning phones - i.e. setting them up automatically for the first time - is always somewhat problematic from a security standpoint. Vendors are faced with the question: how do you authenticate a brand new device so that it can … authenticate? This is of course a typical chicken-and-egg problem!
Zoom, in collaboration with AudioCodes, try to solve it by making use of a redirection server redirect.audiocodes.com. Essentially, newly installed phones will send an HTTP request to this server and provide it with its own MAC address. For example, if the MAC address of the phone is 00908F9D8992, then it will visit https://redirect.audiocodes.com/00908F9D8992. The web server would then redirect the phone to another location. In cases where the particular MAC address has been assigned to a Zoom account through the Zoom Phone System Management system, it would redirect to a Zoom provisioning server.
What the security researcher found was that Zoom could be told to setup a particular custom provisioning template which instructs the phone to use a custom firmware URL. This means that custom firmware could be loaded on phones by simply guessing their MAC address. MAC addresses are not considered a secret. Attackers could simply assign a large number of MAC addresses on Zoom’s system and get them to install their own malicious firmware upon first installation. The problem was that Zoom did not verify that the user who assigned the MAC address actually owned the phone. This is covered in the SYSS-2022-056 advisory. Full abuse of these security issues could lead to remote control of a fleet of phones, eavesdropping of calls, building a botnet of phones and various other attack scenarios.
The related blog post and presentation slides also detail the following related concerns:
- A hardcoded cryptographic key is used to encrypt sensitive information in the configuration files of the AudioCodes VoIP phones - this is covered in the SYSS-2022-052 advisory.
- Another hardcoded cryptographic key which is used to encrypt configuration files that are retrieved from the provisioning servers - this is covered in the SYSS-2022-054 advisory.
- The AudioCodes redirection server redirects to URLs that include credentials in the URI or sensitive provisioning files with SIP usernames and passwords - this is covered by the SYSS-2022-053 advisory.
- AudioCodes IP phones do not perform sufficient validation of the firmware images, which seems to rely on a CRC check. This naturally allows malicious firmware to be loaded on the phones - covered by the SYSS-2022-055 advisory.
Skype leaks IP addresses without user interaction
Joseph Cox wrote about a security report by a researcher named Yossi where Skype on mobile leaks the IP of any user by sending a link to some website. The article does not really explain how the privacy issue can be exploited but tells us that no link clicking is involved and that it only affects the mobile app, not the desktop version.
Back in the days, Skype used to reveal IPs in various ways due to its peer-to-peer origins. Of course this has changed a lot so I’m curious about the details. Microsoft originally said that they won’t fix but upon being contacted by 404media, they said that the fix will be included in a future update.
Unrelated to this particular issue, when making voice or video calls between Skype users, the IP is also leaked since Skype tries to send the audio/video media directly. In a quick test that I made while preparing this article, I noticed STUN messages being sent from my mobile phone’s 5G IP address to my desktop during a Skype call. This is common and expected among real-time communications software where latency is generally a bigger concern than privacy. You will find this issue in almost all software that allows audio/video calling between two parties. In fact, for privacy, this is not necessarily a bad thing and it greatly depends on your threat model. Long discussions can be had here but we’ll leave that for another time!
Short news and commentary
- Authentication on meet.jit.si
- The public instance of Jitsi is now requiring authentication to curb abuse from anonymous users. This is unfortunately always an issue when providing a public service on the Internet - it will get abused.
- X2/X3 Lawful Interception Dissector
- Hossein Yavari published a Wireshark dissector and related blog post for the X2/X3 PDU Format, making it easier for network analysts to understand and interpret captured traffic related to this protocol.
- Rapid7’s Mid-Year Threat Review mentions VoIP devices
- The report from Rapid7 mentions VoIP solutions being the target of APT (advanced persistent threat) groups without giving much details. What they do highlight is that VoIP technology is an underappreciated attack vector in traditional network security reporting and we expect this to become more targeted by such adversaries.
- CXTech Week 34 newsletter
- The newsletter from Alan Quayle about the telecom industry (and more) is worth tracking. This edition covers national security issues, SMS scams and robocall regulations news. We recommend subscribing if this is your thing.
- Fake Call Centre Busted: 84 Arrested
- What is interesting is that the VoIP software in use is mentioned in the news article: VICIdial and eyeBeam.
- CVE-2022-40510 fixed in Qualcom chipsets - Memory corruption due to buffer copy without checking size of input in Audio while voice call with EVS vocoder.
- This is interesting because EVS stands for Enhanced Voice Services which is a speech audio coding standard that was developed for VoLTE. Exploiting media/codecs on VoLTE is a major attack vector. The security community hasn’t been discussing this one at all but we’re sure that it will catch the attention of actual attackers!
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