Researchers Find 8 Critical Risks in Android’s VoIP Components
- Out of the eight cybersecurity risks the team found, six were remotely exploitable issues.
- The vulnerabilities could have enormous security consequences for telecoms first and then to the users.
A group of Chinese researchers recently revealed the findings of its pathbreaking investigation into Android’s voice-over-internet-protocol (VoIP) components that had eight critical risks affecting everyone on the planet.
Cybercriminals could exploit vulnerabilities to:
- Transfer calls without the recipient’s knowledge
- Spoof caller IDs
- Crash VoIP devices
- Run malicious code on a victim’s device
List of vulnerabilities
Many businesses and organizations are transitioning to a VoIP phone system, hence it’s important to know the threats. Out of the eight cybersecurity risks the team found, six were remotely exploitable issues.
Vulnerability 1: Unauthorized Call Transfer
The researchers found that QtilMS(an Android’s system service found in VoIP component) exposed two APIs to third-party apps. Any app without permission could invoke the APIs, enabling a malicious app on a device to set unauthorized call transfer.
Vulnerability 2: VoIP Call Bomb
The vulnerability is remotely exploitable. The risk linked with this is similar to an existing denial of service (DoS) attack called an ‘SMS Bomb’. Crooks can launch a VoIP Call Bomb attack by calling a victim’s device using a lengthy SIP name. A name of 1,043 characters or more fills up the device’s screen. While a user is more likely to avoid answering the call, repeated calls, one after the other, can lock the user out of their device for an extended period.
Vulnerability 3: Remote Denial of Service (DoS) in Telephony
Two more weaknesses were identified in the Android OS’s telephony module, both leading to a DoS attack. With this flaw, attackers could send malformed SDP packets causing a device to crash when the user attempt to answer a call.
Vulnerability 4: Remote Code Execution (RCE)
This only applies when a phone connects to a device via Bluetooth. An attacker can trigger a stack buffer overflow by using a caller number or user name with more than 513 bytes for a VoIP call. That, in turn, lets the attacker run malicious code on the compromised device.
Vulnerability 5: Remote DoS in Bluetooth
This issue is similar to vulnerability four and obviously involves Bluetooth. In this case too attackers may use large caller numbers. Rather than allowing RCE, this specific vulnerability causes a phone to crash. Unlike the remote DoS risk in telephony, it occurs when a device receives a call (the user doesn’t even have to try and answer that call).
Vulnerability 6: Data Leak and Permanent DoS
The sixth risk is one of the two that aren’t remotely exploitable. Attackers can obtain control only when a device has malicious apps installed on it. The vulnerability stems from Android and SIP treating “..” and “/” characters differently. This behavior lets attackers leak the sensitive SIP profile file to the public SD card. This opportunity can be further exploited to overwrite another system app’s file. Moreover, depending on the file that gets overwritten, it can also lead to a DoS. Only a factory reset could fix that.
Vulnerability 7: Caller ID Spoofing
The last vulnerability enables attackers to spoof caller IDs in two ways; both stem from inconsistency in the number format of SIP and the Public Switched Telephone Network (PSTN).
Due to Mis-Parsing ‘&’: Due to the way PSTN number convention treats an ‘&’ in a number, it helps crooks in spoofing VoIP caller IDs. They only have to put an ‘&’ at the end of the real number, and Android will display a spam call as if it were coming from the actual number.
Due to ‘Phone Context’ Parameter: Android’s dialler app applies the ‘Phone Context’ parameter in the same way for VoIP as one does to specify a phone number’s prefix for a traditional call. Attackers, as a result, can use this parameter to spoof caller IDs.
Good news, Google has fixed many of the above vulnerabilities. The above-listed vulnerabilities could have enormous security consequences for telecoms first and then to the users.