{"id":122833,"date":"2021-06-15T21:01:52","date_gmt":"2021-06-16T04:01:52","guid":{"rendered":"\/blogs\/?p=122833"},"modified":"2024-07-05T05:55:05","modified_gmt":"2024-07-05T12:55:05","slug":"a-new-program-for-your-peloton-whether-you-like-it-or-not","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/a-new-program-for-your-peloton-whether-you-like-it-or-not\/","title":{"rendered":"A New Program for Your Peloton \u2013 Whether You Like It or Not"},"content":{"rendered":"

Executive Summary<\/span>\u00a0<\/span><\/h2>\n

The McAfee<\/span>\u00a0<\/span>Advanced Threat Research team\u00a0<\/span>(ATR)\u00a0<\/span>is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers<\/span>.<\/span>\u00a0As<\/span>\u00a0<\/span>security researchers<\/span>, s<\/span>omething that we always try to establish before looking at a target is what our scope<\/span>\u00a0should<\/span>\u00a0be. More specifically, we often assume well-vetted technologies like\u00a0<\/span>network<\/span>\u00a0<\/span>stack<\/span>s<\/span>\u00a0or the OS layer<\/span>s<\/span>\u00a0are sound and instead focus our attention on the application layers or software<\/span>\u00a0that is<\/span>\u00a0specific to\u00a0<\/span>a<\/span>\u00a0<\/span>target.\u00a0<\/span>Whether that approach is comprehensive sometimes doesn\u2019t matter;\u00a0<\/span>and it\u2019s\u00a0<\/span>what we decided to do for this project as well<\/span>, bypassing the<\/span>\u00a0Android OS\u00a0<\/span>itself<\/span>\u00a0and\u00a0<\/span>with a\u00a0<\/span>focus on the Peloton\u00a0<\/span>code and implementations<\/span>. During\u00a0<\/span>our research<\/span>\u00a0process, we<\/span>\u00a0<\/span>uncovered<\/span> a flaw (CVE-2021-33887<\/a>) in the Android Verified Boot (AVB) process<\/span>, which was initially out of\u00a0<\/span>scope, that<\/span>\u00a0left the Peloton vulnerable.<\/span>\u00a0<\/span><\/p>\n

For those that are not familiar with Peloton,\u00a0it is\u00a0a\u00a0brand\u00a0that\u00a0has\u00a0combined high end\u00a0exercise equipment with\u00a0cutting-edge\u00a0technology.\u00a0Its\u00a0products\u00a0are equipped with a large tablet that\u00a0interfaces\u00a0with the\u00a0components of the fitness machine,\u00a0as well as\u00a0provides\u00a0a way to attend virtual workout classes over the internet.\u00a0\u201cUnder the hood\u201d\u00a0of this glossy exterior, however,\u00a0is a standard Android tablet, and this hi-tech\u00a0approach to exercise equipment has not\u00a0gone unnoticed.\u00a0Viral marketing mishaps aside, Peloton has garnered attention recently regarding concerns surrounding the privacy and security of\u00a0its\u00a0products.\u00a0So,\u00a0we decided to\u00a0take a look\u00a0for ourselves\u00a0and purchased a Pelton Bike+.<\/p>\n

Attempting to Backup<\/span>\u00a0<\/span><\/h2>\n

One of the first things that we usually try do when starting a new project, especially when<\/span>\u00a0said projects involve<\/span>\u00a0large expenses<\/span>\u00a0<\/span>like the Peloton, is to try to find a way to take a backup or\u00a0<\/span>a\u00a0<\/span>system dump that could be used if a recovery is ever needed. Not\u00a0<\/span>all<\/span>\u00a0<\/span>of<\/span>\u00a0our\u00a0<\/span>research techniques<\/span>\u00a0keep the device in a pristine state\u00a0<\/span>(we\u2019d be poor hackers if they did)<\/span>,\u00a0<\/span>and having the ability to restore\u00a0<\/span>the device\u00a0<\/span>to\u00a0<\/span>its\u00a0<\/span>factory setting<\/span>s<\/span>\u00a0is a safety net that we try to implement\u00a0<\/span>o<\/span>n our\u00a0<\/span>targets<\/span>.\u00a0<\/span>\u00a0<\/span><\/p>\n

Because we are working with a normal Android device with only the Peloton customizations running\u00a0<\/span>at the application layer<\/span>,<\/span>\u00a0many of the processes\u00a0<\/span>used<\/span>\u00a0<\/span>to back<\/span>\u00a0<\/span>up\u00a0<\/span>an Android phone\u00a0<\/span>would also work with<\/span>\u00a0the Peloto<\/span>n<\/span>.<\/span>\u00a0It is common in the\u00a0<\/span>Android custom ROM scene<\/span>\u00a0to use a\u00a0<\/span>custom recovery<\/span><\/a>\u00a0image that allows the u<\/span>ser to\u00a0<\/span>take full flash dumps of each critical\u00a0<\/span>partition\u00a0<\/span>and<\/span>\u00a0prov<\/span>ide<\/span>s<\/span>\u00a0a method to\u00a0<\/span>restore them later.<\/span>\u00a0<\/span>In such communities,<\/span>\u00a0<\/span>it often\u00a0<\/span>also\u00a0<\/span>goes<\/span>\u00a0without saying that\u00a0<\/span>the device must\u00a0<\/span>first\u00a0<\/span>be<\/span>\u00a0<\/span>unlocked<\/span><\/a>\u00a0<\/span>in order to perform any of these steps.<\/span>\u00a0<\/span>While the Android OS allows users to flash these critical partitions<\/span>,<\/span>\u00a0there are restrictions in place that\u00a0<\/span>typically<\/span>\u00a0prevent an attacker from gaining access to the \u201ccurrently\u201d running system.<\/span>\u00a0If an attacker was able to get their hands on an Android device\u00a0<\/span>with the<\/span>\u00a0goal of\u00a0<\/span>installing a\u00a0<\/span>rootkit<\/span>,<\/span>\u00a0they would have to jump through some hoops.<\/span>\u00a0The first step that an attacker would need to\u00a0<\/span>take<\/span>\u00a0is\u00a0<\/span>to\u00a0<\/span>enable<\/span>\u00a0\u201c<\/span>Original Equipment Manufacturer<\/span>\u00a0<\/span>(OEM<\/span>)<\/span>\u00a0Unlocking\u201d, which is a user mode setting within the \u201cdeveloper options\u201d menu. Even with physical access to the bootloader, an attacker would not be able to \u201cunlock\u201d the Android device unless this setting is checked. This option is usually secured behind the user\u2019s password,\u00a0<\/span>PIN<\/span>, or biometric phone lock, preventing an attacker from accessing it easily.\u00a0<\/span>The second security measure in place is that even with the \u201cOEM Unlocking\u201d setting on, issuing commands to the bootloader to perform the unlock\u00a0<\/span>first\u00a0<\/span>cause<\/span>s<\/span>\u00a0all data on\u00a0<\/span>the<\/span>\u00a0<\/span>Android device, including applications, files, passwords, etc., to be wiped.<\/span>\u00a0This way<\/span>,<\/span>\u00a0<\/span>even\u00a0<\/span>if an attacker did gain access to\u00a0<\/span>the<\/span>\u00a0Android device of an unsuspecting victim, they wouldn\u2019t be able to install a rootkit or modify the existing kernel without deleting all the data<\/span>,<\/span>\u00a0which\u00a0<\/span>both prevents personal data from falling into the attacker\u2019s hand<\/span>s<\/span>\u00a0and makes it obvious the device has been tampered with.<\/span>\u00a0<\/span><\/p>\n

For this research effort<\/span>, w<\/span>e\u00a0<\/span>resisted the urge<\/span>\u00a0to unlock the\u00a0<\/span>Peloton<\/span>,<\/span>\u00a0<\/span>as\u00a0<\/span>there\u00a0<\/span>are<\/span>\u00a0ways\u00a0<\/span>for apps\u00a0<\/span>to query the unlock status\u00a0<\/span>of a device\u00a0<\/span>within Android<\/span>,<\/span>\u00a0and we\u00a0<\/span>wanted to ensure that any vulnerabilities we found weren\u2019t the result of the device behaving differently due to it being unlocked<\/span>. Th<\/span>ese discrepancies\u00a0<\/span>that\u00a0<\/span>arise from our research are<\/span>\u00a0<\/span>usually\u00a0<\/span>identified\u00a0<\/span>by having two<\/span>\u00a0target<\/span>\u00a0devices<\/span>:<\/span>\u00a0one\u00a0<\/span>to serve as<\/span>\u00a0the control and the other\u00a0<\/span>to serve as<\/span>\u00a0the test device<\/span>.<\/span>\u00a0<\/span>Unfortunately,<\/span>\u00a0we only had one Peloton<\/span>\u00a0to play with<\/span>.<\/span>\u00a0<\/span>Another issue\u00a0<\/span>wa<\/span>s that\u00a0<\/span>the Peloton hardware is not very common and the developers of the<\/span>\u00a0aforementioned<\/span>\u00a0custom recovery images, like\u00a0<\/span>Team Win Recovery Project (<\/span>TWRP<\/span><\/a>)<\/span>, don\u2019t create images for every device,\u00a0 just the\u00a0<\/span>most\u00a0<\/span>common ones.\u00a0<\/span>So,<\/span>\u00a0the easy method of taking a backup would not only require unlocking the device but also trying to create our own\u00a0<\/span>custom\u00a0<\/span>recovery<\/span>\u00a0image<\/span>.\u00a0<\/span>\u00a0<\/span><\/p>\n

This left us as at a\u00a0<\/span>crossroad<\/span>s<\/span>.<\/span>\u00a0<\/span>W<\/span>e could unlock the bootloader and root the device<\/span>,<\/span>\u00a0<\/span>granting us<\/span>\u00a0access to the\u00a0<\/span>flash\u00a0<\/span>memory\u00a0<\/span>block devices<\/span>\u00a0(raw\u00a0<\/span>interfaces to the flash partitions)<\/span>\u00a0internally<\/span>,\u00a0<\/span>which would allow us<\/span>\u00a0<\/span>to create and restore backups<\/span>\u00a0<\/span>as needed<\/span>. However,\u00a0<\/span>as mentioned before, this would leave the bike in a recognizably \u201ctampered\u201d state.<\/span>\u00a0<\/span>Alternatively,<\/span>\u00a0we could try to\u00a0<\/span>capture one of<\/span>\u00a0<\/span>the\u00a0<\/span>b<\/span>ike\u2019s<\/span>\u00a0<\/span>Over-The-Air (<\/span>OTA<\/span>)<\/span>\u00a0updates<\/span>\u00a0<\/span>to use as\u00a0<\/span>a\u00a0<\/span>backup,<\/span>\u00a0but\u00a0<\/span>we<\/span>\u00a0would still need to \u201cunlock\u201d the device to\u00a0<\/span>actually flash<\/span>\u00a0the OTA\u00a0<\/span>image\u00a0<\/span>manually<\/span>.<\/span>\u00a0<\/span>Both<\/span>\u00a0options were less than ideal so we kept\u00a0<\/span>looking for other solutions.<\/span>\u00a0<\/span><\/p>\n

Android Verified Boot P<\/span>rocess<\/span><\/h2>\n

Just as Secure Boot provides a security mechanism for properly booting the OS on Windows PCs, Android has implemented measures to control the boot process, called Android Verified Boot (AVB).\u00a0<\/span>According to Android\u2019s documentation<\/span><\/a>, AVB<\/span>\u00a0<\/span>\u201c<\/span>requires cryptographically verifying all executable code and data that is part of the Android version being booted before it is used. This includes the kernel (loaded from the boot partition), the device tree (loaded from the\u00a0<\/span>dtbo<\/span>\u00a0partition), system partition, vendor partition, and so on.<\/span>\u201d<\/span>\u00a0<\/span><\/p>\n

The Peloton Bike+ ships with the default settings of \u201cVerity Mode\u201d set to true<\/span>,\u00a0<\/span>as well as<\/span>\u00a0\u201cDevice Unlocked\u201d and \u201cDevice Critical Unlocked\u201d set to false<\/span>,\u00a0<\/span>which\u00a0<\/span>is<\/span>\u00a0intended to prevent\u00a0<\/span>the loading of<\/span>\u00a0modified boot images<\/span>\u00a0and provide a way to determine if the device has been tampered with<\/span>. This\u00a0<\/span>information\u00a0<\/span>was<\/span>\u00a0verified by running\u00a0<\/span>fastboot<\/code><\/span>\u00a0<\/span>oem<\/code><\/span>\u00a0<\/span>device-info<\/code><\/span>\u00a0on the Peloton<\/span>, as demonstrated in\u00a0<\/span>Figure\u00a0<\/span>1<\/span>.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

To clarify<\/span>,<\/span>\u00a0a<\/span>\u00a0simplified Android boot process can be\u00a0<\/span>visualized\u00a0<\/span>as follows:<\/span>\u00a0<\/span><\/p>\n

If\u00a0<\/span>modified code\u00a0<\/span>is found\u00a0<\/span>at any of the\u00a0<\/span>stages in\u00a0<\/span>Figure\u00a0<\/span>2<\/span>,<\/span>\u00a0the boot process should abort<\/span>\u00a0or<\/span>,<\/span>\u00a0if the device is\u00a0<\/span>unlocked<\/span>,<\/span>\u00a0<\/span>warn the user that the images are not verified and give the option to the user to abort the boot.<\/span>\u00a0<\/span><\/p>\n

Given<\/span>\u00a0that we\u00a0<\/span>defined our scope<\/span>\u00a0of this project<\/span>\u00a0to not include the Android boot process as a part of our research\u00a0<\/span>and verifying that\u00a0<\/span>Peloton has\u00a0<\/span>attempted\u00a0<\/span>to use the security\u00a0<\/span>measures<\/span>\u00a0provided by Android<\/span>,<\/span>\u00a0<\/span>we<\/span>\u00a0again found ourselves debating\u00a0<\/span>if a backup would be possible.\u00a0<\/span>\u00a0<\/span><\/p>\n

In<\/span>\u00a0newer\u00a0<\/span>Android\u00a0<\/span>releases<\/span>,<\/span>\u00a0including the Peloton,<\/span>\u00a0the<\/span>\u00a0update method\u00a0<\/span>uses Android\u2019s<\/span>\u00a0<\/span>Seamless System Updates (A\/B)<\/span><\/a>. This update method<\/span>\u00a0<\/span>no longer need<\/span>s<\/span>\u00a0the \u201crecovery\u201d partition<\/span>,<\/span>\u00a0<\/span>forcing<\/span>\u00a0users who wish to use a custom recovery to use the\u00a0<\/span>fastboot<\/code><\/span>\u00a0<\/span>boot<\/code><\/span>\u00a0command<\/span>\u00a0w<\/span>hich will download and boot the supplied\u00a0<\/span>image<\/span>. This is a temporary boot<\/span>\u00a0<\/span>that\u00a0<\/span>doesn\u2019t \u201c<\/span>flash\u201c or<\/span>\u00a0alter<\/span>\u00a0any of the flash partitions of the\u00a0<\/span>device<\/span>\u00a0and will revert to the previous\u00a0<\/span>boot image on restart<\/span>.\u00a0<\/span>Since\u00a0<\/span>this option allows for modified code to be\u00a0<\/span>executed<\/span>,<\/span>\u00a0<\/span>it is only available when the device is in an unlocked state<\/span>\u00a0and will error out\u00a0<\/span>with a message\u00a0<\/span>stating\u00a0<\/span>\u201c<\/span>Please unlock device to enable this command<\/span>,<\/span>\u201d<\/span>\u00a0<\/span>i<\/span>f a<\/span>ttempted on a locked device.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

T<\/span>his\u00a0<\/span>is a good security implementation because if this\u00a0<\/span>command was\u00a0<\/span>always\u00a0<\/span>allowed,<\/span>\u00a0it would be very similar to the process of booting from a live USB on your PC<\/span>,<\/span>\u00a0<\/span>w<\/span>here y<\/span>ou can\u00a0<\/span>login as a root user and\u00a0<\/span>have full control over the<\/span>\u00a0underlying<\/span>\u00a0system<\/span>\u00a0and components<\/span>.<\/span>\u00a0<\/span><\/p>\n

Booting\u00a0<\/span>M<\/span>odified<\/span>\u00a0<\/span>C<\/span>ode<\/span>\u00a0<\/span><\/h2>\n

This is where our luck or maybe\u00a0<\/span>na\u00efvet\u00e9<\/span>\u00a0<\/span>worked<\/span>\u00a0to our\u00a0<\/span>advantage<\/span>.<\/span>\u00a0<\/span>Driven by\u00a0<\/span>our reluctance to unlock the device and our desire to\u00a0<\/span>make a backup<\/span>,<\/span>\u00a0we\u00a0<\/span>tried to boot a generic TWRP recovery image\u00a0<\/span>just\u00a0<\/span>to see what would happen<\/span>. The<\/span>\u00a0<\/span>image\u00a0<\/span>ended up\u00a0<\/span>leaving us at<\/span>\u00a0a black screen,\u00a0<\/span>and\u00a0<\/span>since each\u00a0<\/span>recovery image needs to contain a small kernel with the correct drivers for the display, touch digitizer<\/span>,<\/span>\u00a0and other device<\/span>–<\/span>specific hardware<\/span>,<\/span>\u00a0this was\u00a0<\/span>to be<\/span>\u00a0expected<\/span>.\u00a0<\/span>What w<\/span>e didn\u2019t\u00a0<\/span>expect<\/span>, however,<\/span>\u00a0<\/span>was for\u00a0<\/span>it to\u00a0<\/span>get past the\u00a0<\/span>fastboot<\/code><\/span>\u00a0<\/span>boot<\/code><\/span>\u00a0<\/span>command.<\/span>\u00a0<\/span>While we didn\u2019t get a custom recovery running<\/span>,<\/span>\u00a0it did\u00a0<\/span>tell us one\u00a0<\/span>thing<\/span>;\u00a0<\/span>the<\/span>\u00a0system was not verifying that the device was unlocked before attempting to boot a custom image<\/span>.\u00a0<\/span>Normally this command would be\u00a0<\/span>denied on a \u201clocked\u201d device and would have just errored out\u00a0<\/span>on the\u00a0<\/span>fastboot<\/span>\u00a0command<\/span>, as mentioned previously.<\/span>\u00a0<\/span><\/p>\n

It is also important to point out that despite\u00a0<\/span>having\u00a0<\/span>boot<\/span>ed<\/span>\u00a0a modified image, the internal fuse\u00a0<\/span>ha<\/span>d<\/span>\u00a0not been burned. These fuses are usually burned during the OEM unlocking process to identify if a device has allowed for a different \u201croot of trust\u201d to be installed. The burning of such a fuse is a permanent operation and a burnt fuse often indicates that the device has been tampered with. As shown in\u00a0<\/span>Figure 3<\/span>, the \u201cSecure Boot\u201d fuse\u00a0<\/span>wa<\/span>s<\/span>\u00a0still present, and the device\u00a0<\/span>wa<\/span>s<\/span>\u00a0reporting a locked bootloader.<\/span>\u00a0<\/span><\/p>\n

Acquiring an OTA\u00a0<\/span>I<\/span>mage<\/span>\u00a0<\/span><\/h2>\n

This<\/span>\u00a0discovery\u00a0<\/span>was\u00a0<\/span>unexpected<\/span>\u00a0<\/span>and\u00a0<\/span>we\u00a0<\/span>felt like we<\/span>\u00a0had<\/span>\u00a0stumbled upon a flaw that\u00a0<\/span>gave us the ability to finally take a backup of the device and leave the Peloton in an \u201cuntampered\u201d state.\u00a0<\/span>K<\/span>nowing that a\u00a0<\/span>custom image could be booted even with a \u201clocked\u201d bootloader<\/span>,<\/span>\u00a0we<\/span>\u00a0<\/span>began looking at ways to gather a valid\u00a0<\/span>boot image<\/span>, which would contain the correct kernel drivers to\u00a0<\/span>facilitate a successful<\/span>\u00a0boot<\/span>.<\/span>\u00a0<\/span>If<\/span>\u00a0we could piece together t<\/span>he<\/span>\u00a0OTA update URL and just download an update package\u00a0<\/span>directly from Peloton<\/span>,<\/span>\u00a0it<\/span>\u00a0would\u00a0<\/span>likely\u00a0<\/span>contain a boot image<\/span>\u00a0that<\/span>\u00a0we could modify<\/span>.\u00a0<\/span>Having the ability to modify a boot image\u00a0<\/span>would\u00a0<\/span>give us root\u00a0<\/span>and access to the\u00a0<\/span>block<\/span>ed<\/span>\u00a0devices<\/span>.<\/span>\u00a0<\/span><\/p>\n

Finding the name\u00a0<\/span>OTAService<\/span>\u00a0<\/span>promising, we pulled down<\/span>\u00a0<\/span>the\u00a0<\/span>APK<\/span>\u00a0<\/span><\/i>and<\/span>\u00a0began\u00a0<\/span>to\u00a0<\/span>reverse-engineer it<\/span>\u00a0<\/span>using<\/span>\u00a0<\/span>JADX<\/span><\/a>.<\/span>\u00a0<\/span>After some digging, we<\/span>\u00a0<\/span>discovered how the app\u00a0<\/span>was\u00a0<\/span>building the download\u00a0<\/span>URL string<\/span>\u00a0for OTA updates<\/span>,\u00a0<\/span>which would then be passed to<\/span>\u00a0<\/span>beginDownload<\/code><\/code><\/span>()<\/code><\/code><\/span>,<\/span>\u00a0<\/span>as seen in\u00a0<\/span>Figure\u00a0<\/span>5<\/span>.<\/span>\u00a0<\/span><\/p>\n

We also noticed quite a few\u00a0<\/span>A<\/span>ndroid log<\/span>\u00a0calls that could help us<\/span>,<\/span>\u00a0such as the one right before the call to\u00a0<\/span>beginDownload<\/code><\/span>()<\/code><\/span>,<\/span>\u00a0so\u00a0<\/span>we\u00a0<\/span>us<\/span>ed<\/span>\u00a0<\/span>Android\u2019s<\/span>\u00a0<\/span>built<\/span>–<\/span>in<\/span>\u00a0<\/span>logcat<\/span>\u00a0command and grepp<\/span>ed<\/span>\u00a0<\/span>the output\u00a0<\/span>for \u201cOTA\u201d<\/span>\u00a0<\/span>as<\/span>\u00a0seen in\u00a0<\/span>Figure\u00a0<\/span>6<\/span>.<\/span>\u00a0<\/span>Doing so,\u00a0<\/span>we were able to find\u00a0<\/span>which S3 bucket was used for the OTA updates and\u00a0<\/span>even\u00a0<\/span>a file manifest\u00a0<\/span>titled\u00a0<\/span>OTAConfig.json<\/span>.\u00a0<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

Combining the information obtained from\u00a0<\/span>OTAService.apk<\/span>\u00a0and the logs,\u00a0<\/span>we were able<\/span>\u00a0to piece together the full path to the OTA images<\/span>\u00a0manifest file<\/span>\u00a0and names for each OTA zip file<\/span>, as shown in\u00a0<\/span>Figure\u00a0<\/span>7<\/span>.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

Our next step was<\/span>\u00a0to extract the contents of the OTA update\u00a0<\/span>to<\/span>\u00a0get\u00a0<\/span>a<\/span>\u00a0valid\u00a0<\/span>boot.img<\/span>\u00a0file that would contain\u00a0<\/span>all<\/span>\u00a0the specific kernel\u00a0<\/span>drivers for the Peloton hardware. Since the Peloton is using Android<\/span>\u2019<\/span>s\u00a0<\/span>A\/B partitions<\/span>,<\/span>\u00a0which facilitate seamless updates<\/span>,<\/span>\u00a0the update packages\u00a0<\/span>were<\/span>\u00a0stored in a \u201c<\/span>payload.bin<\/span>\u201d format.\u00a0<\/span>Using the\u00a0<\/span>Android payload dumper<\/span><\/a>\u00a0<\/span>tool<\/span>,<\/span>\u00a0<\/span>we were able to extract all of the images\u00a0<\/span>contained in the bin file.<\/span>\u00a0<\/span><\/p>\n

Modifying the Boot\u00a0<\/span>I<\/span>mage<\/span>\u00a0<\/span><\/h2>\n

Once the\u00a0<\/span>boot.img<\/span>\u00a0<\/span>was<\/span>\u00a0extracted,\u00a0<\/span>we needed a way to modify the\u00a0<\/span>initial kernel to allow us to gain root access on the device.\u00a0<\/span>Although t<\/span>here are a\u00a0<\/span>variety<\/span>\u00a0<\/span>of<\/span>\u00a0ways to\u00a0<\/span>accomplish<\/span>\u00a0this<\/span>,<\/span>\u00a0<\/span>we decided to\u00a0<\/span>keep things simple and\u00a0<\/span>just use the\u00a0<\/span><\/span>Magisk<\/span><\/span><\/a>\u00a0installer to patch the\u00a0<\/span>boot.img<\/span>\u00a0fil<\/span>e to include the \u201c<\/span>su<\/span>\u201d binary. With the\u00a0<\/span>boot.img<\/span>\u00a0patched,\u00a0<\/span>we were able to use the<\/span><\/span> <\/span>fastboot<\/code><\/span>\u00a0<\/code><\/span>boot<\/span><\/span>\u00a0command again but this time passing\u00a0<\/span>it our patched\u00a0<\/span>boot.img<\/span>\u00a0file<\/span>. Since the Verified Boot<\/span><\/span> process <\/span>on the Peloton<\/span>\u00a0fail<\/span>ed<\/span>\u00a0to identify the modified boot image as tampered, the OS boot<\/span>ed\u00a0<\/span>normally<\/span>\u00a0with the patched\u00a0<\/span>boot.img<\/span>\u00a0file<\/span>. After this process\u00a0<\/span>was<\/span>\u00a0complete, the Peloton Bike+\u00a0<\/span>was<\/span>\u00a0indistinguishable from its\u00a0<\/span>\u201cnormal\u201d state under visual\u00a0<\/span>inspection\u00a0<\/span>and<\/span>\u00a0the process left no\u00a0<\/span>artifacts that would<\/span>\u00a0tip off the user\u00a0<\/span>that\u00a0<\/span>the Pelton ha<\/span>d<\/span>\u00a0been compromised.<\/span>\u00a0But\u00a0<\/span>appearances can be deceiving, and<\/span>\u00a0<\/span>in reality th<\/span>e Android OS\u00a0<\/span>had now been<\/span>\u00a0<\/span>rooted<\/span>,\u00a0<\/span>allowing<\/span>\u00a0us to use\u00a0<\/span>the\u00a0<\/span>\u201c<\/span>su<\/span>\u201d command to become root and\u00a0<\/span>perform<\/span>\u00a0actions<\/span>\u00a0with UID=0<\/span>,<\/span>\u00a0as seen in<\/span>\u00a0<\/span>Figure 8<\/span>.<\/span>\u00a0<\/span><\/p>\n

Impact\u00a0<\/span>S<\/span>cenarios<\/span>\u00a0<\/span><\/h2>\n

Once an attacker has root, they could make their presence permanent by modifying the OS in a rootkit fashion, removing any need for the attacker to repeat this step. Another risk is that an attacker could modify the system to put themselves in a man-in-the-middle position and sniff all network traffic, even SSL encrypted traffic<\/span>,<\/span>\u00a0using a technique called\u00a0<\/span>SSL unpinning<\/span><\/a>, which requires root privileges to hook calls to internal encryption functionality.\u00a0<\/span>Intercepting and decrypting<\/span>\u00a0network traffic\u00a0<\/span>in this fashion<\/span>\u00a0could lead to users<\/span>\u2019<\/span>\u00a0personal data being compromised.<\/span>\u00a0Lastly<\/span>,<\/span>\u00a0the Peloton Bike+ also has a camera and a microphone\u00a0<\/span>installed. Having remote access with root permissions on the Android tablet would allow an attacker to monitor these devices and\u00a0<\/span>is\u00a0<\/span>demoed in the impact video below.<\/span>\u00a0<\/span><\/p>\n

As we just demonstrated, t<\/span>he ability to bypass the Android Verified Boot process can lead to the Android OS being compromised by an attacker<\/span>\u00a0with physical access<\/span>.\u00a0<\/span>A worst-case scenario for such an attack vector might involve a\u00a0<\/span>malicious agent booting the Peloton with a modified\u00a0<\/span>image to gain elevated privileges and then leveraging\u00a0<\/span>those privileges to establish a reverse shell, granting the attacker\u00a0<\/span>unfettered<\/span>\u00a0<\/span>root access\u00a0<\/span>on<\/span>\u00a0the bike remotely<\/span>. Since the attacker never has to unlock the device to boot a modified image, there would be no trace of any access they achieved on the device.<\/span>\u00a0<\/span>This sort of attack could be\u00a0<\/span>effectively delivered<\/span>\u00a0via\u00a0<\/span>the supply chain process. A<\/span>\u00a0<\/span>malicious<\/span>\u00a0actor\u00a0<\/span>could\u00a0<\/span>tamper with the\u00a0<\/span>product\u00a0<\/span>at any point from construction to warehouse to delivery, installing<\/span>\u00a0a backdoor into the Android tablet without any way the end\u00a0<\/span>user\u00a0<\/span>could know.\u00a0<\/span>Another<\/span>\u00a0scenario could be that an attacker could simpl<\/span>y<\/span>\u00a0walk up to one of these devices that\u00a0<\/span>is installed in a\u00a0<\/span>gym or a fitness room<\/span>\u00a0and perform the same attack<\/span>,<\/span>\u00a0gaining root access on these devices for later use<\/span>.<\/span>\u00a0The\u00a0<\/span>Pelobuddy<\/span>\u00a0interactive map<\/span><\/a> in figure <\/span>9<\/span>\u00a0below could help an attacker find public bikes to attack<\/span>.<\/span>\u00a0<\/span><\/p>\n

Even with just\u00a0<\/span>ADB debugging<\/span><\/a>\u00a0enabled we were able to pull the\u00a0<\/span>Peloton<\/span>–<\/span>specific applications from the device.\u00a0<\/span>We listed\u00a0<\/span>all<\/span>\u00a0the Peloton\u00a0<\/span>APK<\/span>s\u00a0<\/span>and\u00a0<\/span>sought out the\u00a0<\/span>ones that could help us get the OTA path<\/span>,<\/span>\u00a0shown in<\/span>\u00a0<\/span>Figure\u00a0<\/span>4<\/span>.<\/span>\u00a0<\/span><\/p>\n