All That We Let In: Hacking Mobile Health APIs (Part 1)

Introduction

Are you being kept up at night wondering just how secure your company's mobile health (mHealth) APIs really are? You aren't alone. And after the research I’ve conducted on mHealth APIs, you very well should be. If you aren't, you will be.

The number of mHealth companies have more than doubled in the past two years and with COVID-19, the protracting work-from-home economy is rewriting workplace norms that have been in place since the first industrial revolution. The court of public opinion on the future of retail shopping, banking, and healthcare in our new mobile-first world has delivered their verdict. Any business requiring a physical trip to a brick and mortar building doesn't have a future unless they offer their service through a mobile app.

What you're reading is the first inculcation of a multipart series on the first-ever vulnerability research campaign performed of mHealth apps and APIs. Multiple mHealth companies participated in this research that will amount to the largest, unprecedented release of vulnerabilities ever published in the healthcare industry without identifying the individual companies that have participated in the research.

The purpose of this research is to draw attention to the new attack surface being created in the 21st century API economy, which is now processing, transmitting, and storing our most vital and currently the most valuable information being sold on the dark web -- protected health information (PHI).

The problem isn't the use of mHealth apps as they're solving real problems, especially for patients needing always-on monitoring and remote access to their clinician or mental health provider. This is the direction healthcare has inevitably headed as new innovations were introduced in the digitalization of healthcare enabling clinicians to care for us in our home remotely from their clinics. The answer to this security challenge isn't stopping the use of mHealth apps and APIs, rather, the proper hardening of them using security solutions on both the endpoint and network.

After identifying the vulnerabilities and findings produced in this primary research, the final part in this series will discuss the solutions so CISOs, cybersecurity engineers, and developers can secure against these attacks.

This series will present my findings from my research, as well as include videos produced on the findings and a link to the white paper sponsored by CriticalBlue (Approov).

Application Programming Interfaces (APIs)

As of September 2020, the mobile phone market has made an unprecedented climb to 50.33% of the global market share, with desktops falling behind to 47.04% (Figure 1). This means that more than half of the people surveyed choose to use their mobile phones for virtually everything in their connected life rather than their desktops. It's no wonder companies can't compete unless they have an app for their service.

Figure 1: The market share of mobile devices compared to other devices

As of 2020, there are 2.2 Million apps available for download in the Apple App Store and 2.7 Million apps in the Google Play Store. What's powering these 4.9 million apps? Application Programming Interfaces, or APIs, which have become the plumbing for virtually everything in the cloud, from connected cars, to banking, and now mobile healthcare.

APIs are the translator between applications allowing them to talk to one another, akin to a virtual waiter communicating orders from patrons at a restaurant to the chef in the kitchen -- for lack of a better analogy. APIs are the endpoints that mobile apps communicate with.

Of this astounding number of apps, the number of mHealth apps in just the Apple App Store alone from the 1st quarter of 2015 to the 2nd quarter of 2020 has grown exponentially to 45,791. (Figure 2), Even more staggering, is the number of mHealth apps across all major app stores. As of March 2019, that number of apps grew to 318,000 since 2015 posing a clear and present danger to anyone using it if the company isn't taking the security of their apps and APIs seriously -- many of which are not, which this research will prove.

The number of mHealth apps remained relatively flat from Q1-17 through Q2-20 but has certainly grown from Q3-20 to now as a result of the COVID-19 pandemic.

Figure 2: The number of mHealth apps from 2015-Q1 to 2020-Q2.

Distinguishing Between the Terms

Before we get any further, it's important to define the different terminology you'll run into in this series. The terms have been mistakenly used interchangeably so it's important you understand it isn’t just arguing semantics. You'll hear me use the terms mHealth, telehealth, and Remote Patient Monitoring (RPM) throughout this series, so it’s important you understand them. While they sound similar, they are in fact very different.

Mobile Health (mHealth) is a subset of telehealth, referring to a specific way mobile technology is utilized to achieve improved health goals for patients. According to the National Institute of Health (NIH), "mHealth is the use of mobile and wireless devices to improve health outcomes, health care services, and health research." The World Health Organization (WHO) defines it similarly as "the use of mobile and wireless technologies to support the achievement of health objectives." Therefore, telehealth should be seen as the overarching ecosystem of digital healthcare technologies that mHealth fits in a subset of limited to mobile technology like smartphones and tablets. One key differentiator between telehealth and mHealth is that telehealth should be viewed as clinician-directed remote patient monitoring technology while mHealth is user-directed, allowing patients to capture their own health data without a clinician's assistance or interpretation.

Just the same, Remote Patient Monitoring (RPM) is a subset of telehealth that enables patients to use specific technology that enables clinicians and patients to interact outside of a clinical setting at home.

The Research

The amount of data we generate each day has created data lakes in the cloud that seem to have no end. Today, 2.5 quintillion bytes of data is created each day and more than 90% of the world's data was created from 2016-2018 according to statistics published in 2018. With all this information also comes misinformation, much of which is perpetuated by vendors themselves, which is why vulnerability research like this is absolutely critical lest we build our defenses on a house of cards built by the lowest bidder.

That said, because of all the information being marketed about the different security controls for securing mobile apps, the network, to the API endpoints, it's important I first emphasize the critical point that protecting the mobile app doesn't protect the API.

This research is fundamental to proving the importance of this message. Last year, I published research on the systemic lack of code obfuscation in the financial services and fintech industries that shook the market to its core This resulted in a global tour across Europe, Asia, and the middle east of presenting at conferences on my findings.

However, only implementing code obfuscation to secure the app against reverse engineering is an exercise in futility if you’re expecting it to secure everything from the app to the API. It only secures against one specific threat. Also, even if the app is obfuscated, it's still possible to deobfuscate it or use an SSL MITM proxy tool to intercept the mobile app traffic to determine the API endpoint URLs and API requests by analyzing the network traffic. Code obfuscation only secures the app against reverse engineering in an attempt to get hardcoded API secrets but does nothing to protect the API endpoint.

While my focus was reverse engineering mobile apps in 2019 and stopping once I had hard coded API keys, tokens, and credentials, this year I'm taking that research further after reverse engineering 30 mHealth apps to get hard coded API secrets and credentials. This time, I’ve engaged with several mHealth companies who've agreed to participate in this research and open their APIs up for me to test.

Conclusion

The number of mHealth apps in the Android and iOS store have more than doubled in just the past couple years alone. mHealth offers quicker and more cost effective treatment of chronic diseases and other health conditions not requiring physical visits to an emergency room or clinic, even active foresight enabling clinicians to monitor what's happening with their patients in real-time on a daily basis instead of waiting until a health emergency occurs. It’s without contestation that there is indeed a health and cost benefit to transitioning to mHealth technology, however, it must be done securely.

It’s my hope that this research will cause much needed discourse and encourage us to take a closer look at how we architect, build, and maintain the security posture around mHealth technology and that my research will push the industry in this much needed direction. Because it isn’t just other people’s PHI at risk, it’s mine, yours, our partners, and our children. Is that a risk you’re willing to take?

In the next part of our series, I’ll begin presenting the results of the first stage of my research where I look at the mHealth apps and perform network interdiction between the mobile device and API endpoints.