Vulnerabilities found in remote management software that carriers insist be installed on smart phones and other mobile-enabled devices they sell are likely to put many devices at risk of compromise for some time to come.
Dangerous security flaws were discovered in widely deployed client implementations of the OMA Device Management (OMA-DM) protocol that allows carriers to remotely deploy firmware updates, change device data connection settings, install applications, lock and wipe devices and more.
OMA-DM capabilities vary from carrier to carrier, depending on the features they choose to enable. The technology itself is developed by third-party companies and built by manufacturers into devices that are meant to sold through those carriers.
It’s not just mobile phones that have this technology built-in, but other devices with mobile connectivity as well, such as laptops, mobile hotspots and an increasing number of embedded devices that fall into the Internet of Things category, including those in cars.
Mathew Solnik and Marc Blanchou, two scientists at Denver-based security firm Accuvant, have analyzed the OMA-DM implementations in Apple, Android and BlackBerry devices sold through carriers in the U.S. and other countries around the world. They found multiple vulnerabilities that could allow attackers to hijack the remote management functionality and take control of devices that have this technology.
While the two researchers spoke about the issues last week, on Wednesday they released details about the specific vulnerabilities they identified during a presentation at the Black Hat security conference in Las Vegas.
Their research focused primarily on an OMA-DM client implementation from a company called Red Bend Software that according to them is installed on 70 to 90 percent of carrier-sold mobile phones in the world. The researchers estimate, based on public statistics, that around 2 billion devices have some kind of OMA-DM software installed.
Controlling the Red Bend client software requires authentication, is done over HTTPS (HTTP Secure) and can be triggered through special WAP push messages, the researchers said. However, the authentication mechanism uses the device IMEI (International Mobile Station Equipment Identity) number and a static secret token shared by all devices on a particular carrier, both of which can be easily acquired by an attacker, they said.
Furthermore, Solnik and Blanchou found ways to bypass the HTTPS requirement. One method takes advantage of a vulnerability in the SSL certificate validation code that accepts any valid certificate for any hostname. Another involves tricking devices into using HTTP-only test servers specified in the software code and impersonating those servers.
There are also multiple ways to potentially attack OMA-DM-enabled devices including sending device-to-device WAP push messages, using WAP push interfaces that carriers make available to third parties and by setting up rogue cellular base stations for nearby devices to connect to instead of the real carrier’s network.
The researchers ran a test base station in the room during their presentation at Black Hat that was powered down as much as possible to restrict its range of influence over phones in the area. They also used several layers of encryption to make sure that no unintended devices actually connect to the base station and asked people in the audience to shut off their phones.
Despite these precautions, 70 mobile phones attempted to connect to the rogue base station during the presentation, the researchers said, highlighting that hijacking mobile device connections in this way can be fairly easy. Even 3G or LTE devices can be tricked to connect to a GSM base station by jamming the 3G and LTE frequencies in the area, they said.
The OMA-DM functionality itself can be abused to modify APN and proxy settings, change routing and preferred gateway settings, install applications and more. However, since this functionality differs from carrier to carrier, the researchers focused on identifying memory corruption vulnerabilities in the Red Bend software code that could allow them to achieve remote code execution on devices regardless of carrier mandated customizations. They also managed to defeat the anti-exploitation defenses on iOS and Android.
On smart phones the management code runs in the user space (outside the kernel) like other applications, but has a privileged interface to the baseband—the firmware that controls the phone’s radio communications—so by exploiting the OMA-DM software an attacker can potentially go even deeper and exploit baseband vulnerabilities, the researchers said.
In the U.S., three out of four Android devices sold through major carriers have this technology built into them, while iOS devices only have it on Sprint, Solnik and Blanchou said. BlackBerry devices also have it on most U.S. carriers. The researchers cautioned that the problem is global, as they tested phones from carriers in multiple countries, but they declined to name them because they’re still in the process of responsible disclosure with some of them.
According to them, OMA-DM client software developed by companies other than Red Bend is also vulnerable, because most implementations, including Red Bend’s have the same code base—an open source project called the SyncML Reference Toolkit that hasn’t been updated since 2004.
According to the researchers, Red Bend Software has been notified and has made patches available to manufacturers.
“Since receiving this report in mid-June, Red Bend has worked with its customers and confirmed that all identified risks have been mitigated,” the company said in a statement on its website. “All new versions of vDirect Mobile provided to our customers contain these mitigations.”
The risk to iOS devices on Sprint has been largely mitigated, the researchers said. However, addressing the problem on Android devices depends on when manufacturers will issue updates and carriers will distribute them to their affected customers.
Due to the fragmentation of the Android ecosystem the risk of OMA-DM attacks is likely to persist for some time to come. Some affected devices might not even be supported anymore and might not receive patches.
History has showed that some vulnerabilities affecting Android devices have lingered on for months and even years, primarily because developing and distributing patches involves multiple parties, from the Android OS developers themselves to device manufacturers, carriers and even app developers in some cases.