Check Point Researchers have identified a susceptibility to advanced phishing attacks in certain modern Android-based phones, including models by Samsung, Huawei, LG and Sony. In these attacks, a remote agent can trick users into accepting new phone settings that, for example, route all their Internet traffic through a proxy controlled by the attacker.
This attack vector relies on a process called over-the-air (OTA) provisioning, which is normally used by cellular network operators to deploy network-specific settings to a new phone joining their network. However, as we show, anyone can send OTA provisioning messages.
The industry standard for OTA provisioning, Open Mobile Alliance Client Provisioning (OMA CP), includes rather limited authentication methods; a recipient cannot verify whether the suggested settings originate from his network operator or from an imposter. We found that phones manufactured by Samsung, Huawei, LG and Sony (corresponding to over 50% of all Android phones, according to market share data from 2018: http://gs.statcounter.com/vendor-market-share/mobile/worldwide/) allow users to receive malicious settings via such weakly-authenticated provisioning messages. Samsung phones compound this by allowing unauthenticated OMA CP messages as well.
We disclosed our findings to the affected vendors in March. Samsung included a fix addressing this phishing flow in their Security Maintenance Release for May (SVE-2019-14073). LG released their fix in July (LVE-SMP-190006). Huawei is planning to include UI fixes for OMA CP in the next generation of Mate series or P series smartphones. Sony refused to acknowledge the vulnerability, stating that their devices follow the OMA CP specification. OMA is tracking this issue as OPEN-7587.
To send OMA CP messages, an attacker needs a GSM modem (either a $10 USB dongle, or a phone operating in modem mode), which is used to send binary SMS messages, and a simple script or off-the-shelf software, to compose the OMA CP.
The phishing CP messages can either be narrowly targeted, e.g. preceded with a custom text message tailored to deceive a particular recipient, or sent out in bulk, assuming that at least some of the recipients are gullible enough to accept a CP without challenging its authenticity.
OMA CP allows changing the following settings over-the-air:
MMS message server
Browser homepage and bookmarks
Directory servers for synchronizing contacts and calendar
The following scenarios assume that the attacker attempts to trick victims into routing all their traffic through the attacker-controlled proxy.
To target victims using Samsung phones, the attacker can send them unauthenticated OMA CP messages, specifying a proxy that he controls. We emphasize that there is no authenticity check for the attacker to overcome: all that is needed is for the user to accept the CP.
Figure 1: An unauthenticated CP message as it appears to a Samsung user.
Authenticated with IMSI
If the attacker is able to obtain the International Mobile Subscriber Identity (IMSI) numbers of potential victims using Huawei, LG or Sony phones, he can mount a phishing attack as effective as the one against Samsung phone users.
IMSI is a 64-bit identifier of each device on a mobile network, in use since GSM and up to 3G. This number is used for routing, and is roughly equivalent to an IP address in computer networks. A person’s IMSI is pseudo-confidential, but:
It’s necessarily available to all network operators, as routing data or calls to a mobile subscriber requires resolving his phone number into IMSI.
As a result, forward and reverse IMSI lookups (mobile number to IMSI and vice versa) are cheaply available via commercial suppliers.
A rogue Android application can read the user’s IMSI number via the standard API ((TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE)).getSubscriberId()
– as long as the application has the permission permission.READ_PHONE_STATE. Over a third of all Android apps released in the last three years already require this permission, so it wouldn’t raise any suspicion.
Anyone who can take a look at the physical SIM card will see the ICCID engraved or printed on it, and the ICCID often matches the IMSI!
OMA CP messages have an optional security header to enable validation of the CP’s authenticity. When a CP is authenticated with the recipient’s IMSI number, Huawei, LG and Sony phones allow installation of malicious settings. Note that these phones don’t show any details about the CP when they suggest the user install it; in particular, the sender of the CP is not identified in any way.
Figure 2: A NETWPIN-authenticated CP message as it appears to a Sony user.
Authenticated with PIN
For those potential victims whose IMSI could not be obtained, the attacker can send each victim two messages. The first is a text message that purports to be from the victim’s network operator, asking him to accept a PIN-protected OMA CP, and specifying the PIN as an arbitrary four-digit number. Next, the attacker sends him an OMA CP message authenticated with the same PIN. Such CP can be installed regardless of the IMSI, provided that the victim accepts the CP and enters the correct PIN.
Figure 3: A USERPIN-authenticated CP message as it appears to a Huawei user.
Provisioning is the process by which devices are provided with the settings they need to function in their environment. The main original use case for OTA provisioning is to deploy operator-specific settings, such as the address of the operator’s MMS service center. Enterprises, too, use this facility to deploy settings such as email server addresses to the employees’ devices. OMA CP, one of the two standards that OMA maintains for provisioning settings over the air, dates back from 2001, with the latest specification from 2009.
Our research shows that the security implications of OMA CP remain relevant even a decade later. The basic distribution of Android doesn’t handle OMA CP messages, but many vendor implementations do, as OMA CP is the industry standard for OTA provisioning. Its specification allows (but does not require!) CP messages to be authenticated using USERPIN, NETWPIN, or other methods, which are less widely used.
Any SMS, whether a text message, an MMS, a voicemail notification, or anything else, is transmitted as Protocol Data Units (PDUs) specified by Short Message Transfer Protocol (SM-TP) aka GSM 03.40. GSM PDUs containing the OMA CP payload consist of:
SM-TP header at the bearer layer, specifying the recipient’s phone number and data coding scheme.
User Data Header (UDH) at the transport layer, including:
Wireless Datagram Protocol (WDP) header, specifying destination port 2948 (wap-push) and source port 9200 (wap-wsp).
Optional concatenated message header: user data of each PDU is limited to 140 bytes, and longer messages must be chunked.
Wireless Session Protocol (WSP) header at the session layer, containing authentication (if any).
WAP Binary XML (WBXML) at the application layer, containing the payload.
As a demonstration, our initial (unauthenticated) proof of concept for Samsung phones contained the following XML document as the payload, with the strings specifying the proxy address and port number highlighted:
Figure 4: XML payload for OMA CP.
The complete OMA CP carrying this payload is split over two physical SMS messages, shown in the following diagram as two strings of octets:
Figure 5: Physical representation of an OMA CP message.
In the WBXML string, the proxy address and port number (highlighted with the same colors as in the XML source) are included as null-terminated ASCII strings, whereas strings defined in the XML schema, such as element names and the values of type and name attributes, are represented in WBXML as fixed one-byte values.
The WBXML payload follows the WSP header which includes the message authentication code, calculated using the recipient’s IMSI, as an ASCII hex string.
We described an advanced phishing attack flow against modern Android-based phones. This attack flow enables anyone who has a cheap USB modem to trick users into installing malicious settings onto their phones. To target some of the susceptible phones, the attacker needs to know the victims’ IMSI numbers, which can be obtained via an Android application having READ_PHONE_STATE permission.
We verified our proof of concept on the Huawei P10, LG G6, Sony Xperia XZ Premium, and a range of Samsung Galaxy phones, including S9.
Check Point SandBlast Mobile prevents Man-in-the-Middle and phishing attacks, to help protect your devices against such malicious OMA CP messages.