Exclusive research found 9 critical system-level Android VoIP Zero-day vulnerabilities that allow attackers to perform malicious operations, including denying voice calls, caller ID spoofing, unauthorized call operations, DOS attack, and remote code execution.
A Team of academics and researchers from OPPO ZIWU Cyber Security Lab, Chinese University of Hong Kong and Singapore Management University uncovered these serious Android vulnerabilities and successfully tested in Android version 7.0 to the recent 9.0.
VoIP is a new technology that offers voice, fax, SMS, voice-messaging to mobile devices over the packet switching IP network, and VoIP also supports Android that includes VoLTE and VoWiFi standards.
Researchers uncovered these vulnerabilities by digging deeper into the VoIP security in system-level to analyse the Android VoIP’s protocol stack and all its four attack surfaces.
All the 4 attack surfaces that uncovered by the researchers will allow attackers to physical, local, remote nearby attack surfaces against Android VoIP devices.
Most parts of the research focused on a novel vulnerability assessment approach called Fuzzing, an automated software testing technique that involves providing invalid, unexpected, or random data as inputs. Relatively this research has been approached via both Intent/API fuzzing, network-side packet fuzzing, and targeted code auditing.
Researchers discovered 2 vulnerabilities using the On-Device Fuzzing method, 4 vulnerabilities were uncovered using Network Side Fuzzing, and rest of the 3 vulnerabilities were discovered with the help of Code Auditing.
Out of the 9 Android Zero-day Vulnerabilities, eight of them were finalized as system vulnerabilities and acknowledge by Google with bug bounty awards and one vulnerability affected the 3 rd party app.
Nearly 6 vulnerabilities can be exploited by a network side adversary that allows local and remote attackers to exploit the Android VoIP and 7 out of 9 vulnerabilities are marked as “Critical” and “High” severity by Google.
Two remote vulnerabilities could be triggered only when the phone is connected with a nearby Bluetooth-based HFP (Hands-Free Profile) device.
Let’s Explore The All 9 Zero-day Vulnerabilities
1. Maliciously Triggering a VoIP call in the VK App (Low)
A Vulnerability resides in the vk.voip data type and the existence of an exported component, LinkRedirActivity allows the local attacker to directly make a VoIP call to a VK user account by installing the malicious app without user’s consent and even the mobile screen is turned off.
According to the researchers, “victim user could eavesdrop if the callee VK account was set to an account under the attacker’s control, the idea of which is similar to the login CSRF (CrossSite Request Forgery) attack in web security.” The vulnerability discovered by using the On-Device Fuzzing method.
2. Unauthorized Call Transfer in the IMS interface (Moderate)
An Android system service called “QtilMS” implemented by Qualcomm exposed two VoIP APIs, (SendCallTransferRequest and SendCallForwardUncondTimer) to any 3 rd party applications.
These 2 API’s are very sensitive and is only accessible to those with the CALL_PRIVILEGES permission. Due to the failure of QtilMS checking the privilege, any app without permission can also invoke the APIs and the malicious apps misuse the API’s and perform unauthorized call transfer.
3. Undeniable VoIP call spam due to long SIP name (High)
Another interesting Zero-day vulnerability uncovered by researchers using SIP fuzzing that attacker to perform an Undeniable VoIP call by filled up by the very long SIP name.
This attack prevents the user from neither to attend the call nor reject the call because there will be no button to perform the task. researchers call it a “VoIP call bomb”
“If the adversary frequently launches this undeniable VoIP call spam, the victim has to disable the network connection or shut down her phone”
4. Remote DoS in Telephony once Accepting a call(High)
A remote DoS attack via a malformed configuration file: $./uac.sh -f malformed.cfg that can crash the victim’s Android phone once he/she attends the call.
Researchers said ” Our fuzzing identified two weaknesses in the affected Telephony module, either of which could be exploited for the attack and the other way is to use the invalid SDP description.
5. Remote code execution due to stack buffer overflow (Critical)
This RCE vulnerability can be triggered by an attacker only when the victim’s phone is connected with a nearby Bluetooth device.
“A stack buffer overflow thus happens when a caller number with more than 513 bytes is inputted. This vulnerability allows an adversary to overwrite the return address of the ClccResponse function, causing remote code execution.” Google marked this vulnerability as “Critical” severity.
6. Remote DoS in Bluetooth once Receiving a call (High)
Very Similar to previous vulnerability, it could be triggered when the BTHF_CALL_INCOMING call state is changed and only when the phone is connected with a nearby Bluetooth device.
Compared to the DoS in V4, triggering DoS in V6 just needs to receive, rather than answer, a call, and the vulnerability can be patched by restricting to the length of caller number input in the Bluetooth module.
7. Data leak and Permanent DoS due to Path Traversal (High)
Researchers exploit this vulnerability due to the inconsistency between SIP URI and Android/Linux file directory, and it could lead to a permanent DoS that could also happen if “server ip” is set to overwrite another system app’s file.
“Due to this fake mmssms.db file, the real one cannot be created and thus deny any SMS functionality. Only a factory reset can recover the phone.”
8. Caller ID spoofing Due to Mis-parsing “&” (High)
This Vulnerability affected the Android devices due to the inconsistency between SIP URI and PSTN (Public Switched Telephone Network) number format and is related to the specific character “&” in the caller number.
According to the PSTN’s convention ” a caller number with “&”, the system dialer app treats the number before “&” as the actual calling number and the number after “&” as the call transfer number, “
It can be abused by an attacker by simply adding a “&” character in the end, causing a caller ID spoofing attack.
9. Caller ID spoofing due to “phone-context” ( High )
Same as the previous attack, another inconsistency takes place in this attack due to“phone-context” that is basically used to mention the prefix of a phone number.
In this case, Google is automatically performed by Android’s CallerID mechanism, which tries to correlate well-known phone numbers or mark spam numbers in the normal scenario.
“New root cause, incompatible processing between VoIP and PSTN calls, that leads to six VoIP vulnerabilities and requires developers’ extra attention in their future design and implementation.” Researchers concluded.
