By George McGregor, VP of Marketing, Approov
A new report by Knight Ink, sponsored by Mobile API Security firm Approov describes how thirty leading mHealth applications were tested and everyone contained a vulnerability that exposed private patient data.
If you have published a mobile healthcare app, you should be worried and this report should be essential reading.
In this case, a medical practitioner may not be able to help you, but applying better security practices and using the right controls will.
The Environment – the use of mHealth apps is booming
Even before the pandemic, the use of mobile apps by both patients and medical practitioners was growing rapidly.
This upward adoption curve became a massive spike in 2020 with the growth in demand for virtual healthcare. With the global pandemic now shaping much of our online activity, mobile access to healthcare has become essential. Doctors are no longer working within secure hospital networks and patients are accessing care remotely.
These apps are used by practitioners for all aspects of treatment and practice management and by patients to control and access healthcare data. In addition, government regulations are driving adoption by pushing patient ownership of data as well as innovation through interoperability via standardized APIs.
Because of these trends, mobile healthcare applications and the APIs they access are at the heart of the new healthcare ecosystem. However, they are prime targets for cybercriminals. In fact, in the dark web marketplace, patient data is much more valuable than credit card details, sometimes selling for $1000 a record.
mHealth apps must be protected in order to prevent unauthorized access to Personal Health Information (PHI) and to ensure HIPAA compliance in this highly regulated industry.
The Symptoms – What the Research Found
The results of the study were very worrying indeed.
The report estimates that more than 23 million users may have been exposed by the vulnerabilities they uncovered in only 30 apps. Of the apps investigated, 77% had hardcoded API keys, and 50% did not require tokens to authenticate requests. Half of the records accessed in the study contained personally identifiable information like social security numbers and dates of birth and health data,
100 percent of API endpoints tested were vulnerable to BOLA attacks that allowed the researcher to view the PII and PHI for patients that were not assigned to the researcher’s clinician account.
The report also points out that FHIR/SMART standards merely represent a subset of the steps needed to secure mobile apps and the APIs which retrieve data and interoperate with data resources and other applications.
The study underscores the API shielding actions now urgently required to protect mHealth apps from API abuse.
The Cure – How Can I Better Secure My Mobile Healthcare Apps and APIs
The report recommends that mHealth platform developers and security teams – and all developers and organizations using mobile applications – adopt several key steps to protect their customer data and sensitive resources. Let’s look at these in a little more detail.
- Protect the mobile channel in its entirety. The report recommends that you must focus on the APIs your mobile apps use. A focus on securing the app alone is not enough. It is important to realize that synthetic traffic to the API is an issue and arises from bots and automated tools, not from genuine apps and legitimate data requests. Traditional server-side solutions such as a WAF or Bot Mitigation solutions provide some protection, but these rely on known patterns and involve constant maintenance and updates to keep up with the latest attack vectors. In addition, most are heavily reliant on browser fingerprinting which is not relevant with mobile apps, and they don’t effectively detect scripts impersonating mobile apps. In general, it is good practice to use controls which eliminate problematic traffic before it hits the backend.
- Shift left and shield right: Of course good development discipline and taking steps to consider security early on in the life cycle is very important. You should take steps to protect your mobile app code from tampering or reverse engineering. Costly and comprehensive hardening solutions are available and utilizing them will make the hacker’s job more challenging but not impossible. However the research shows that many apps simply use code obfuscation techniques and those apps are still vulnerable. Also, the secrets required to attack your APIs can be acquired by hackers from other channels, not just by reversing the app, so run-time controls must always be in place to ensure only genuine apps and genuine users are accessing your APIs.
- Protect against X-in the middle attacks: Your patients don’t use VPNs, and you can’t depend on healthcare professionals being on secure networks anymore. If your TLS is not managed properly third parties can steal secrets and manipulate your APIs. Certificate pinning is an effective defense but often not implemented because expired certificates can block apps and impact the customer’s experience. In fact, not one of the apps tested implemented pinning, often because the devops team was concerned about managing certificates. However, when done correctly, certificate pinning does not impact either performance or availability.
- Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and be able to adjust them easily – both for compliance with HIPAA mandates and to sustain data security and privacy. Deploying a new mobile app version every time there is a security policy update is not an option. Seek out solutions that allow dynamic policy adjustments without having to change the app.
- Focus your pentesting on the mobile use-case: Penetration testing and static and dynamic code analysis should be performed regularly. The report provides a practical user guide to the tools and tactics your pentesters can employ to ensure the security of your mobile apps and the APIs they use.
Mobile healthcare apps are here to stay, but they are exposed. It doesn’t need to be that way. There are solutions available today which are easy to deploy and can immediately reduce exposure.
About the Author
George McGregor is VP of Marketing for Approov. He is passionate about cybersecurity and previously held executive roles at Imperva, Citrix, Juniper Networks and HP. Approov API Threat Protection provides a multi-factor, end-to-end mobile API security solution that complements identity management, endpoint, and device protection to lock-down proper API usage. Only safe and approved apps can successfully use your APIs. Bots and fake or tampered apps are all easily turned away and PHI is protected.
George can be reached online at ( @approov_io ) and at our company website https://approov.io/