We at sipgate provide a cloud telephony platform for our customers, who can use our desktop apps, custom soft-phones, SIP desk phones, and mobile phones using our sim cards. sipgate acts as an MVNO for its customers, and since the end of 2023, we also provide Voice-over-LTE / IMS services for our customers. While this rollout took a lot of energy and time to track down bugs, as described in our German post of the 8 seconds problem, we are now happy to provide much quicker call-setup times and better audio quality, especially when roaming abroad.
Compared to 2G, the phone and the core network connect through a dedicated IP tunnel and can negotiate their connection using SIP directly. This special network for voice services is called IP Multimedia Subsystem (IMS). For the first time for our mobile department, we were contacted by a diverse set of SIP dialects of various phone vendors, models and generations, because every phone uses slightly different codecs, headers, transport layer security, etc.
For this reason, we have spread the rollout over multiple months, at first only allowing our exact testing devices, then more and more phones from an internal and public beta-testing cohort. For some devices – but far from all of them – we have found that they had a specific issue when connecting to our network. Those phones included Huawei, Xiaomi, Gigaset and Motorola devices, among others.
At first, everything seems normal and as expected: The phone connects to the 4G network, sets up an IMS tunnel, receives an IP address and sends its REGISTER messages. At the same time, the 4G internet connection is created and the device shows “4G / LTE” in its control center. Browsing the internet works great!
On our end, we mark the device as “register via VoLTE” and remember to contact the customer through this 4G connection whenever we want to forward them a call. However, when sending INVITE messages to the phone, the SIP client would not respond at all, and the call ultimately (after some other attempts) fails. It is highly unusual that there is absolutely no response, since usually SIP peers will try to communicate with clear error messages, why something is not working right. Also, the phones were able to make outbound calls, albeit only using a 2G connection.
Traces, Headers, Specifications
In our traces, we have then found that the phones reporting issues are acting a little bit different to all other phones: Most basebands will send their messages in UDP and we answer in UDP. The affected devices however were the only ones that quickly changed over to TCP when the messages became too large (see RFC 3261, section 18.1.1). While not an issue on its own, we saw it as the first differentiator and tried researching in that direction.
To dig deeper, we bought a handful of affected test phones that matched the ones of our customers. While the beta-testing crew was a great asset, having our hands on our own devices made things a lot easier to debug.
Like in the IMS core, the smartphone writes a lot of log files, and when checking them, we found that the application volte_stack crashes when receiving a certain SIP message. Although the phone instantly restarted the application, the existing VoLTE connection was in an undefined state. For some devices, the restart loop caused a lot of load for the processors and thus a sluggish user interface and sometimes even noticeably-warm devices. The vendor has later told us that the supervising process manager keeps volte_stack in persistent mode and will restart it immediately and without buffers or back-off.
To understand the issue better, we have to have a closer look at the SIP session setup handshake: To connect to the server, the client needs to send a REGISTER message to the server which the server can respond to with a cryptographic challenge. If the client can solve this challenge, it will send another REGISTER message with the challenge response, and receive a 200 OK answer. Now, the client asks the server to report events to it, using a SUBSCRIBE message, and the server will notify the phone with a NOTIFY message of its state. You can read more about this in the technical document 3GPP TS 124 229, section 5.1.1.
When reading the logs of the test devices using ADB/logcat, we have found that we missed on sending a mandatory Contact header in the NOTIFY message. Other phones, and also some phones running MediaTek basebands have ignored the issue, but others did crash and went into the restart loop.
To use this problem in the wild, a threat actor needs to be in a privileged condition (namely the serving function of the phone operator’s IMS) which means that there have already been some pre-checks and authorizations. But, hostile takeovers and VoLTE Local Breakout could lead to these situations, and using this, to a denial of service and a down-grade attack of calls to the 2G network which makes the calls significantly less secure.
Disclosing the issue
At this point, we knew what the issue was, and had to report it to multiple contacts. Firstly, we informed the vendor of our IMS core who had missed on sending the Contact header, and then the vendor of the baseband – MediaTek. For our own service, we were quickly able to add a provisional Contact header, but we knew that this wouldn’t solve the issue for the long term, and that the phones did need the information of the header to work correctly, one way or another.
While we have partners at the IMS core vendor that we can call and text, we did not really know how to contact such a big company as MediaTek. Thankfully, at the Mobile Security Conference 2024, we have met some researchers of ISMK in Stralsund and SBA Research in Vienna, who have experience in reporting security issues and were able to help. When we met in Vienna, they were able to work on the firmware, and see the concrete problem behind the crash.
During these investigations, we have found that the bug in volte_stack also happens when registering to a Voice over WiFi (VoWiFi) endpoint. These are similar to Voice over LTE, but are much quicker to set up and hook into in lab environments.
With everything we knew, we contacted MediaTek as the LTE chip vendor, and Motorola as the phone manufacturer of our test phones. Even though the release of this issue took a couple of months, we were happy with the open communication and answering of the many questions that we had.
Sadly, we were not able to get a list of affected chipsets and thus the affected user equipment types and sales numbers due to an NDA restriction. The list below of affected chipsets was published with the public release, and researchers are able to map those to model names.
- CVE
- CVE-2025-20647
- Affected Software Versions
- Modem NR12A, NR13, NR15, NR16
- Affected Chipsets
- MT2735, MT2737, MT6739, MT6761, MT6762, MT6762D, MT6762M, MT6763, MT6765, MT6765T, MT6767, MT6768, MT6769, MT6769K, MT6769S, MT6769T, MT6769Z, MT6771, MT6779, MT6781, MT6783, MT6785, MT6785T, MT6785U, MT6789, MT6833, MT6833P, MT6853, MT6853T, MT6855, MT6855T, MT6873, MT6875, MT6875T, MT6877, MT6877T, MT6877TT, MT6879, MT6880, MT6883, MT6885, MT6886, MT6889, MT6890, MT6891, MT6893, MT6895, MT6895TT, MT6896, MT6980, MT6980D, MT6983, MT6983T, MT6985, MT6985T, MT6989, MT6989T, MT6990, MT8666, MT8667, MT8675, MT8765, MT8766, MT8768, MT8781, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8795T, MT8797, MT8798
Timeline
- 2024-10-15: Finding of the issue that a missing Contact header in a NOTIFY message crashes
volte_stack, and of the fix that adding a stub header in routing may solve the problem. - 2024-10-16: Inquiry to ISMK whether they know a security contact and would like to cooperate
- 2024-10-21: Initial disclosure to Motorola and quick response “We agree that the phone shouldn’t crash”
- 2024-10-25: Meeting with researchers of SBA and ISMK
- 2024-10-29: Disclosure email to MediaTek and response early of the next day (10-30)
- 2024-11-05: Classification of the issue as “Medium Severity” since privileged access to the home IMS / SCSCF is needed to send rouge messages.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. Overall CVSS score of 5.3 - 2024-12-11: Announcement of publishing this issue with Mediatek’s Security Bulletin in March 2025
- 2025-01-05: MediaTek has assigned CVE-2025-20647 and shared the patch with their OEM partners.
- 2025-03-03: Publication of the bug in the Security Bulletin, announcement of affected chipsets and software versions
- 2025-05-15: Recording of Risikozone Podcast
- 2025-05-21: Release of sipgate blogpost and podcast episodes
Acknowledgements
We would like to thank Viktor Garske of ISMK Stralsund, and Gabriel Gegenhuber and Michael Pucher of SBA Research / University of Vienna for their great cooperation. From sipgate, the entire mobile communications team was involved, especially Hendrik Wedhorn, Denis Kollar and Jannik Volkland. We also recorded an episode of ISMK’s Risikozone Podcast, which is published in German language.
If you want to do more research, you can get deeper information such as crash logs, pcap files and an incomplete list of affected devices through sipgate’s public relations team. We’d be happy if more research is conducted with the data.
Keine Kommentare