The reality of Apple watch pen testing

Introduction

We were approached to do an Apple Watch application test. It seems this isn’t a service offered by many companies (including us, although we’ve done plenty of work on Android Wear before) but also, little information exists online about attempts, experiences or if it’s even possible. So, what can be done and what are the limitations?

TL;DR

• API testing can be done as normal, like an iOS application
• Limitations are mostly related to access to the Watch’s filesystem and running processes
• Companion Watch applications are usually bundled with .ipa files which allow us to do reverse engineering
• Bluetooth testing is difficult with Apple devices
• Testing of Apple Watch applications can still provide meaningful testing and assurance

Hardware used

• iPhone 6s running iOS 14.6, jailbroken using checkra1n
• Apple Watch Series 6 running watchOS 9.5.1

WatchOS jailbreaks

The real focus on jailbreaking has been and continues to be for iOS devices. This makes sense as it is the more popular device, and it would be assumed that developers or security researchers aren’t as interested in watchOS. So, it’s no surprise that these are even rarer than iOS jailbreaks. The closest was research published by Max Bazaliy for Black Hat Europe 2017. Although this isn’t the full jailbreak that you would see on iOS it would still help with the limitations in testing, but this isn’t possible on the latest watchOS versions. This was compatible with watchOS 4.1 on an Apple Watch Series 3. At the time of writing, the latest is the Apple Watch series 9 and Ultra 2 with watchOS 10. It is unlikely that it is possible to test using this, especially because watchOS versions are tied very closely to iOS versions.

This leaves testing already at a disadvantage in comparison to iOS applications. At least with iOS applications we can access the filesystem of the device, use Frida to hook into the application and get a better understanding of how the application functions. However, we can pair a jailbroken iOS device with an Apple Watch, and this may open up additional testing, depending on if the watch application shares anything with the iOS application and whether this could be stored on the companion iPhone. So where do we go from here?

Types of Apple Watch applications

First let’s understand what kind of applications are available and how to test them. There are typically two types of Apple Watch applications:

Companion

The application has an iOS application which can then be used to install the Apple Watch application

These are typically available on the iOS app store. Once downloaded onto the companion iPhone, it is possible to install the watch version of the application onto the watch. Once installed onto the watch, they can either proxy all their traffic or comms through the companion iPhone or, depending on if the watch is capable, it could make these comms directly using Wi-Fi or cellular. Usually, if the companion iPhone is in range, it will primarily use this to route any traffic/comms.

Standalone

These applications don’t need a companion iPhone and can be installed directly onto the watch from the watch store

This was introduced in watchOS 6, where beforehand an iPhone application was required. Depending on the watch this can use features such as Wi-Fi or cellular to make requests. This has more limitations on testing as it is not possible to gain access to the watch due to the lack of jailbreaks. Where these applications require testing, they would benefit more from a code review then testing.

In Xcode, there is an option when adding a new target to an existing project to bundle it with an existing iOS app:

Figure 1: Creating a companion Watch application in XCode

From this we can gather that companion applications are the preferred method for device testing. Standalone isn’t really an option for effective testing and would benefit from other types of testing such as a code review. As mentioned above, companion applications are bundled into an iOS application. This is typically another .app folder within the iOS application bundle folder. To show this, a ‘hello world’ Apple Watch application called ‘watchTest’ was added to an existing project:

Figure 2: hello world Watch application

This can be installed onto both the Apple Watch and companion iPhone through Xcode, or can be installed just on the companion iPhone and installed on the Apple Watch through the watch app. There are some hurdles to jump through when installing applications outside of the App store, which are explained further in the post.

Once the applications are installed, we can see where this is stored on the companion iPhone using Frida and Objection:

Figure 3: Frida showing iOS package identifier

Figure 4: Objection showing BundlePath of the iOS application

We can now view this ‘BundlePath’ on the iPhone using SSH to see the nested Apple Watch application:

Figure 5: Bundled Watch application

This could allow us to extract the binary of the applications, which can be reverse engineered to identify further vulnerabilities.

Legizmo

WatchOS versions are tied closely to the iOS version, for example, the new watchOS 10 requires an iPhone XS or later with iOS 17. Any attempts to try and pair an older iOS version will result in the following error:

Figure 6: Unsupported device for watchOS 9

With Apple enforcing these restrictions, we wondered if it was possible to bypass this and pair an older version of iOS with a newer watchOS version. This is possible; however, it does require a jailbroken device. This is where Legizmo comes to the rescue, as this solves our problem and covers a wide range of support, including the recently released watchOS 10. Using this we can successfully pair our jailbroken iPhone running iOS 14.6 with an Apple Watch running watchOS 9.5.1, which would usually require a minimum of iOS 16.

Below is the current support by Legizmo:

Figure 7: Legizmo support

Once Legizmo is installed on the companion iPhone, through a package manager such as Cydia or Zebra, further tweaks are required to be installed to allow pairing:

Figure 8: Pairing support tweak installation required

Figure 9: Legizmo compatibility check

Now we can pair our iPhone and Apple Watch with no further issues:

Figure 10: Pairing allowed

Figure 11: Paired Apple Watch on Jailbroken device

So now we have a jailbroken iPhone, paired to an Apple Watch. Success!

There is one more hurdle to jump through if you want to install watch applications from outside of the App Store, e.g., installing the IPA manually, or through Test Flight as a MacBook (and developer account) is required. The steps detailed in the Types of Apple Watch application section where the default ‘hello world’ application is deployed to the companion iPhone and Apple Watch should allow the developer mode option to appear as these settings aren’t available by default:

Figure 12: Watch developer mode

Once enabled, it is then possible to install applications outside of the iOS App store onto the Apple Watch. This can sometimes take multiple attempts of clicking the install button, or the Watch may need to be reset and the service should be restarted within the Legizmo application:

Figure 13: Application outside of the app store can be installed

Figure 14: Restarting the watchOS service through Legizmo

API testing

Now that the devices are set-up for testing and we know the structure of these applications, we can begin to investigate other areas. Let’s start with API testing as that is relatively straight forward and very similar to iOS applications. As watch applications proxy their traffic through the companion iPhone, it follows the same method as setting up for iOS testing, first, configure the iPhone proxy to point at a Burp Suite instance:

Figure 15: Proxy settings on companion device

Then if we browse to http://burp, we can install the certificate on both devices:

Figure 16: Installing Burp Suite certificate on both devices

Figure 17: Installed certificate on companion iPhone

Figure 18: Installed certificate on Apple Watch

Now we can intercept and manipulate any traffic the watch application will send. From an assessment previously, it was identified that APIs used by the watch application can differ from ones used by the iOS application, especially if functionality is only specific to the watch. Although this will depend on whether the application has been hardened with further features such as certificate pinning.

If certificate pinning is implemented, it will not be possible to bypass as we are unable to hook in the watch application process.  This is an area we’re currently researching, it may be possible, depending on the implementation.

Watch applications will require the user to login to the iOS application first to establish a session, which the Watch application will then use afterwards. If jailbreak detection is implemented on the iOS application, then it is likely this would need to be bypassed or an unhardened version would be required. Once logged in, as the Apple Watch is not jailbroken, there should be no further issues using the authenticated session on the Apple Watch.

Bluetooth testing

Certain applications may make use of Bluetooth capability, this is usually where the application requires a third-party product such as headphones or smart products. This for example could be functionality that allows a user to simply turn on and off their smart light bulbs from their Apple Watch.

Unfortunately for us, Apple use all the Bluetooth security features including:

• Pairing: The process for creating one or more shared secret keys
• Bonding: The act of storing the keys created during pairing for use in subsequent connections to form a trusted device pair
• Authentication: Verifying that the two devices have the same keys
• Encryption: Message confidentiality
• Message integrity: Protection against message forgeries
• Secure Simple Pairing: Protection against passive eavesdropping and protection against man-in-the-middle attacks

Additionally, to help with privacy it also uses address randomisation and cross-transport key derivation. Due to the way that this is implemented on Apple devices, it is unlikely to identify any vulnerabilities within this area as it will not be possible to sniff encrypted Bluetooth comms without further, dedicated research.

Why connect to a jailbroken device?

Most of the testing described above can be done from a non-jailbroken iPhone running the latest iOS versions, especially the API testing. So, what are the benefits to pairing it with a jailbroken device? We know there are limitations in this regard, but according to the developer documentation, it’s common for Apple Watch applications to share files, resources, and data between the companion iPhone:

Figure 19: Shared resources between apps

Some watch applications heavily rely on their iOS application to perform more complicated tasks, present content, and exchange data, even when an internet connection is not available. Apple have a connectivity framework that provides APIs to implement two-way communication between paired applications.

If this is the case with an application we might be testing, then it is important to ensure that any resources or shared data is being stored and used correctly. We can still carry out various checks on the iPhone such as checking how data is stored and ensuring that any sensitive information is not stored in plaintext, or that the correct data protection classes are set when stored in the Keychain or within a file. It may be difficult to discriminate information that is only used for the Watch or iOS applications, especially without access to the watch itself, but this is where testing of Watch applications should be carried out alongside iOS assessments. This would provide a clearer view of how data is used between the two applications and having the jailbroken iPhone will allow us to cover more testing.

Many issues that stem from these checks are usually low risk as it would require an attacker to have physical access to the user’s devices. However, it is important to ensure that the confidentiality and integrity of data is protected from unauthorized access.

Conclusion

It’s surprising that little research or posts exist on Apple Watch testing, especially given how much watch technology has grown over the years and how popular they have become. It also raises the question of how secure Apple Watch applications are, and do they go through regular security assessments like iOS applications would?

This post covers a good baseline for getting set-up and what the reality is of testing these applications. Although testing has its limitations there can still be some added benefit to testing them. Ideally, this would be part of a wider assessment on the iOS application where they can be tested simultaneously as they share a lot of commonalities such as data or functionality.

As with mobile applications, most of the risk will be associated with an API, if one is used. This is due to it likely being accessible to everyone if it is available on the app store. While these could be tested independently, it helps with testing if the context in which these APIs are used can be seen in a user interface.

Many other issues that can occur usually require an attacker to have physical access to a user’s device, which presents a much lower risk. As it is possible that Watch and iOS applications can share data, by having a jailbroken device we can view and modify this data which allows us to identify any further vulnerabilities.

This leaves us with limitations of accessing the Apple Watch filesystem directly and what could potentially be stored there, as well as being able to manipulate the application process on the watch with tools such as Frida or Objection. While BLE testing is possible, due to Apple protections it is unlikely that any attack paths will be identified without dedicated research time.