McAfee : A New Program for Your Peloton – Whether You Like It or Not

Executive Summary

The McAfee Advanced Threat Research team (ATR) is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers.As security researchers, something that we always try to establish before looking at a target is what our scopeshouldbe. More specifically, we often assume well-vetted technologies like network stacksor the OS layersare sound and instead focus our attention on the application layers or softwarethat isspecific to a target. Whether that approach is comprehensive sometimes doesn't matter; and it's what we decided to do for this project as well, bypassing theAndroid OS itselfand with a focus on the Peloton code and implementations. During our researchprocess, we uncovereda flaw in the Android Verified Boot (AVB) process, which was initially out of scope, thatleft the Peloton vulnerable.

For those that are not familiar with Peloton, it is a brand that has combined high end exercise equipment with cutting-edge technology. Its products are equipped with a large tablet that interfaces with the components of the fitness machine, as well as provides a way to attend virtual workout classes over the internet. 'Under the hood' of this glossy exterior, however, is a standard Android tablet, and this hi-tech approach to exercise equipment has not gone unnoticed. Viral marketing mishaps aside, Peloton has garnered attention recently regarding concerns surrounding the privacy and security of its products. So, we decided to take a look for ourselves and purchased a Pelton Bike+.

Attempting to Backup

One of the first things that we usually try do when starting a new project, especially whensaid projects involvelarge expenses like the Peloton, is to try to find a way to take a backup or a system dump that could be used if a recovery is ever needed. Not all ofour research techniqueskeep the device in a pristine state (we'd be poor hackers if they did), and having the ability to restore the device to its factory settingsis a safety net that we try to implement on our targets.

Because we are working with a normal Android device with only the Peloton customizations running at the application layer,many of the processes used to back up an Android phone would also work withthe Peloton.It is common in the Android custom ROM sceneto use a custom recoveryimage that allows the user to take full flash dumps of each critical partition andprovidesa method to restore them later. In such communities, it often also goeswithout saying that the device must first beunlocked in order to perform any of these steps. While the Android OS allows users to flash these critical partitions,there are restrictions in place that typicallyprevent an attacker from gaining access to the 'currently' running system.If an attacker was able to get their hands on an Android device with thegoal of installing a rootkit,they would have to jump through some hoops.The first step that an attacker would need to takeis to enable'Original Equipment Manufacturer (OEM)Unlocking', which is a user mode setting within the 'developer options' menu. Even with physical access to the bootloader, an attacker would not be able to 'unlock' the Android device unless this setting is checked. This option is usually secured behind the user's password, PIN, or biometric phone lock, preventing an attacker from accessing it easily. The second security measure in place is that even with the 'OEM Unlocking' setting on, issuing commands to the bootloader to perform the unlock first causesall data on the Android device, including applications, files, passwords, etc., to be wiped.This way, even if an attacker did gain access to theAndroid device of an unsuspecting victim, they wouldn't be able to install a rootkit or modify the existing kernel without deleting all the data,which both prevents personal data from falling into the attacker's handsand makes it obvious the device has been tampered with.

For this research effort, we resisted the urgeto unlock the Peloton, as there areways for apps to query the unlock status of a device within Android,and we wanted to ensure that any vulnerabilities we found weren't the result of the device behaving differently due to it being unlocked. These discrepancies that arise from our research are usually identified by having twotargetdevices:one to serve asthe control and the other to serve asthe test device. Unfortunately,we only had one Pelotonto play with. Another issue was that the Peloton hardware is not very common and the developers of theaforementionedcustom recovery images, like Team Win Recovery Project (TWRP), don't create images for every device, just the most common ones. So,the easy method of taking a backup would not only require unlocking the device but also trying to create our own custom recoveryimage.

This left us as at a crossroads. We could unlock the bootloader and root the device, granting usaccess to the flash memory block devices(raw interfaces to the flash partitions)internally, which would allow us to create and restore backups as needed. However, as mentioned before, this would leave the bike in a recognizably 'tampered' state. Alternatively,we could try to capture one of the bike's Over-The-Air (OTA)updates to use as a backup,but wewould still need to 'unlock' the device to actually flashthe OTA image manually. Bothoptions were less than ideal so we kept looking for other solutions.

Android Verified Boot Process

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). According to Android's documentation, AVB '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 dtbopartition), system partition, vendor partition, and so on.'

The Peloton Bike+ ships with the default settings of 'Verity Mode' set to true, as well as'Device Unlocked' and 'Device Critical Unlocked' set to false, which isintended to prevent the loading ofmodified boot imagesand provide a way to determine if the device has been tampered with. This information wasverified by running on the Peloton, as demonstrated in Figure 1.

Figure 1: OEM device info showing verity mode and unlocked status.

To clarify,asimplified Android boot process can be visualized as follows:

Figure 2: Simplified Android Boot Process

If modified code is found at any of the stages in Figure 2,the boot process should abortor,if the device is unlocked, warn the user that the images are not verified and give the option to the user to abort the boot.

Giventhat we defined our scopeof this projectto not include the Android boot process as a part of our research and verifying that Peloton has attempted to use the security measuresprovided by Android, weagain found ourselves debating if a backup would be possible.

Innewer Android releases,including the Peloton,theupdate method uses Android'sSeamless System Updates (A/B). This update method no longer needsthe 'recovery' partition, forcingusers who wish to use a custom recovery to use the commandwhich will download and boot the supplied image. This is a temporary boot that doesn't 'flash' oralterany of the flash partitions of the deviceand will revert to the previous boot image on restart. Since this option allows for modified code to be executed, it is only available when the device is in an unlocked stateand will error out with a message stating 'Please unlock device to enable this command,' if attempted on a locked device.

This is a good security implementation because if this command was always allowed,it would be very similar to the process of booting from a live USB on your PC, where you can login as a root user and have full control over theunderlyingsystemand components.

Booting Modified Code

This is where our luck or maybe naïveté workedto our advantage. Driven by our reluctance to unlock the device and our desire to make a backup,we tried to boot a generic TWRP recovery image just to see what would happen. The image ended up leaving us ata black screen, and since each recovery image needs to contain a small kernel with the correct drivers for the display, touch digitizer,and other device-specific hardware,this was to beexpected. What we didn't expect, however, was for it to get past the command. While we didn't get a custom recovery running,it did tell us one thing; thesystem was not verifying that the device was unlocked before attempting to boot a custom image. Normally this command would be denied on a 'locked' device and would have just errored out on the fastbootcommand, as mentioned previously.

It is also important to point out that despite having booteda modified image, the internal fuse hadnot been burned. These fuses are usually burned during the OEM unlocking process to identify if a device has allowed for a different 'root of trust' 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 Figure 3, the 'Secure Boot' fuse wasstill present, and the device wasreporting a locked bootloader.

Figure 3: Secure boot enabled with fused protection

Acquiring an OTA Image

Thisdiscovery was unexpected and we felt like wehadstumbled upon a flaw that gave us the ability to finally take a backup of the device and leave the Peloton in an 'untampered' state. Knowing that a custom image could be booted even with a 'locked' bootloader,we began looking at ways to gather a valid boot image, which would contain the correct kernel drivers to facilitate a successfulboot. Ifwe could piece together theOTA update URL and just download an update package directly from Peloton,itwould likely contain a boot imagethatwe could modify. Having the ability to modify a boot image would give us root and access to the blockeddevices.

Even with just ADB debuggingenabled we were able to pull the Peloton-specific applications from the device. We listed allthe Peloton APKs and sought out the ones that could help us get the OTA path,shown in Figure 4.

Figure 4: Listing Peloton Specific Applications and Highlightingthe one related to OTA Updates.

Finding the name OTAService promising, we pulled down the APKandbegan to reverse-engineer it usingJADX. After some digging, we discovered how the app was building the download URL stringfor OTA updates, which would then be passed to , as seen in Figure 5.

Figure 5: OTA image path being constructed as 'key'

We also noticed quite a few Android logcalls that could help us,such as the one right before the call to ,so we used Android's built-in logcatcommand and grepped the output for 'OTA' asseen in Figure 6. Doing so, we were able to find which S3 bucket was used for the OTA updates and even a file manifest titled OTAConfig.json.

Figure 6: Relevant OTA logs in red

Combining the information obtained from OTAService.apkand the logs, we were ableto piece together the full path to the OTA imagesmanifest fileand names for each OTA zip file, as shown in Figure 7.

Figure 7: Contents of OTAConfig.json

Our next step wasto extract the contents of the OTA update toget avalid boot.imgfile that would contain allthe specific kernel drivers for the Peloton hardware. Since the Peloton is using Android's A/B partitions,which facilitate seamless updates,the update packages werestored in a 'payload.bin' format. Using the Android payload dumper tool, we were able to extract all of the images contained in the bin file.

Modifying the Boot Image

Once the boot.img wasextracted, we needed a way to modify the initial kernel to allow us to gain root access on the device. Although there are a variety ofways to accomplishthis, we decided to keep things simple and just use the Magiskinstaller to patch the boot.imgfile to include the 'su' binary. With the boot.imgpatched, we were able to use the bootcommand again but this time passing it our patched boot.imgfile. Since the Verified Bootprocess on the Pelotonfailedto identify the modified boot image as tampered, the OS booted normallywith the patched boot.imgfile. After this process wascomplete, the Peloton Bike+ wasindistinguishable from its 'normal' state under visual inspection andthe process left no artifacts that wouldtip off the user that the Pelton hadbeen compromised.But appearances can be deceiving, and in reality the Android OS had now been rooted, allowingus to use the 'su' command to become root and performactionswith UID=0,as seen in Figure 8.

Figure 8: Booting modified boot.imgand executing whoamias Root

Impact Scenarios

As we just demonstrated, the ability to bypass the Android Verified Boot process can lead to the Android OS being compromised by an attackerwith physical access. A worst-case scenario for such an attack vector might involve a malicious agent booting the Peloton with a modified image to gain elevated privileges and then leveraging those privileges to establish a reverse shell, granting the attacker unfettered root access onthe bike remotely. 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. This sort of attack could be effectively deliveredvia the supply chain process. A maliciousactor could tamper with the product at any point from construction to warehouse to delivery, installinga backdoor into the Android tablet without any way the end user could know. Anotherscenario could be that an attacker could simplywalk up to one of these devices that is installed in a gym or a fitness roomand perform the same attack,gaining root access on these devices for later use.The Pelobuddyinteractive mapin 9below could help an attacker find public bikes to attack.

Figure 9: pelobuddy.com'sinteractive map to help locate public Peloton exerciseequipment.

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,using a technique called SSL unpinning, which requires root privileges to hook calls to internal encryption functionality. Intercepting and decryptingnetwork traffic in this fashioncould lead to users'personal data being compromised.Lastly,the Peloton Bike+ also has a camera and a microphone installed. Having remote access with root permissions on the Android tablet would allow an attacker to monitor these devices and is demoed in the impact video below.

Disclosure Timeline and Patch

Given the simplicity and criticality of the flaw, we decided todisclose to Peloton even as we continue to audit the device for remote vulnerabilities. We sent our vendor disclosure with full details on March 2, 2021- shortly after, Peloton confirmed the issue and subsequently released a fix for it in software version 'PTX14A-290'. The patched image no longer allows for the 'boot' command to work on a user build, mitigating this vulnerability entirely. The Peloton vulnerability disclosureprocess was smooth,and the team were receptive and responsivewith all communications.Further conversations with Peloton confirmed that this vulnerability is also present on Peloton Tread exercise equipment; however, the scope of our research was confined to the Bike+.

Peloton's Head of Global Information Security, Adrian Stone, shared the following 'this vulnerability reported by McAfee would require direct, physical access to a Peloton Bike+ or Tread. Like with any connected device in the home, if an attacker is able to gain physical access to it, additional physical controls and safeguards become increasingly important. To keep our Members safe, we acted quickly and in coordination with McAfee. We pushed a mandatory update in early June and every device with the update installed is protected from this issue.'

We are continuing toinvestigate the Peloton Bike+, so make sure you stay up to date on McAfee's ATR blogs for any future discoveries.