Pentesting Healthcare Apps

“An employee’s college degree and certifications won’t keep you safe.”

Security in healthcare is bad.

Having worked in the healthcare industry, I’m all too aware of the security shortfalls that are all too common in organizations of all shapes and sizes. From startups to SMBs to massive healthcare systems, there are issues everywhere.

In my experience, there are 3 obvious security shortfalls in the healthcare space:

  1. There’s a complete absence of basic security because the organization is 1) understaffed and focusing on development rather than ACLs and JS exploits, 2) owned by an old school way of thinking haunts the IT division, where the decision makers are utterly convinced nobody will ever figure out how to exploit the systems or firmly believe nobody will ever try, or 3) lacking in security expertise.
  2. Web and mobile applications are made by overworked developers with deadlines that are too tight, and the deliverable delivers and nothing more. Client requests an app, gets an app, and app is deployed and supported. But having something developed by a developer with 20+ years of experience means nothing. Security is an obscure, niche field that changes every few days. Those 20+ years of “secure coding” experience mean nothing if the developer’s skillset isn’t modern (which it often isn’t) or the developer doesn’t use it because it’s outside the scope of the project.
  3. Networks and hosts aren’t hardened. There’s an odd and outrageous belief that if firewall rules prevent inbound access for unauthorized sources nobody can exploit their network because they can’t get in. From there, host and network hardening, which if done properly mitigates all of the low-hanging fruit for attackers, is either ignored or done half to completion. It takes a single machine to be infected by malware to compromise your entire organization.

Healthcare companies need to hire with purpose.

Healthcare companies also tend to gravitate toward traditional, safe hires. For example, success as an IT administrator or engineer is often defined by holding a relevant bachelor’s degree and certification. Degrees and certifications don’t provide you any security expertise or experience that will be effective against a real, coordinated attack. Installing and monitoring IDS/IPS are part of the CCNA/CCNP curriculum, and an employee with just those skills is fine, but how will that person use that college degree and CCNA/CCNP to mitigate attacks that bypass IDS/IPS, which is frankly easy to do?

Degrees and certifications don’t provide you any security expertise or experience that will be effective against a real, coordinated attack. Having done it does. Installing and monitoring IDS/IPS are part of the CCNA/CCNP curriculum, and an employee with just those skills is fine, but how will that person use that college degree and CCNA/CCNP to mitigate attacks that bypass IDS/IPS, which is frankly easy to do?

An employee with a B.S. in Computer Science and a CCNP Security won’t be much use against a sophisticated SQL Injection attack. They can install and monitor IDS/IPS/WAFs and SIEMs, but everyone needs to understand that the instrumentation will hardly help. If you need web application security, you need to hire for that, and credentialing doesn’t show competence in that field.

If you don’t open your doors to the folks who live and breath security but might not have finished college or have a long list of GIAC certs, you’re limiting yourself and forfeiting their vast, hands-on expertise. Some of the world’s most notable hackers and security folk are college dropouts with no certs. Keep that in mind.

Hiring for credentials is fine. It’s your department, your policy, and your budget. But when you begin to equate credentials with security prowess, you’re going to get hacked. An employee’s college degree and certifications won’t keep you safe.

Pentesting Healthcare Apps – A Demonstration

My most recent pentesting engagement for a telehealth startup is a perfect example my previous points. My finding aren’t exclusive to startups – I’ve seen the same and even worse in some of the world’s largest healthcare networks.

Server Response Headers

HTTP/1.1 200 OK
Date: Mon, 07 Jan 2017 23:00:14 GMT
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips PHP/5.5.38

Across the entire application, every HTTP response contains the exact version of Apache, PHP and OpenSSL. This in itself isn’t a security vulnerability, but can lead to one.  For example, there are outstanding, easily reproducible exploits out for Apache 2.4.23 just a Google search away. Same thing with PHP 5.5.38 – it’s a hot mess. And if I needed something that wasn’t patched, finding an exploit, while it would take some time, would be infinitely easier with the exact software version than without. I’d bet my investment portfolio that a skilled, motivated attacker could find an exploit even where it’s not publicly available.

Exploiting Open MySQL DB

Uh oh. It’s open to the public internet, I have an exact version, I have its capabilities and the salt is mine.

3306/tcp open mysql MySQL 5.6.26
| mysql-info:
| Protocol: 53
| Version: .6.26
| Thread ID: 381660
| Capabilities flags: 63487
| Some Capabilities: Speaks41ProtocolNew, Support41Auth, DontAllowDatabaseTableColumn, IgnoreSigpipes, LongColumnFlag, SupportsCompression, Speaks41ProtocolOld, LongPassword, FoundRows, SupportsLoadDataLocal, ODBCClient, InteractiveClient, IgnoreSpaceBeforeParenthesis, SupportsTransactions, ConnectWithDatabase
| Status: Autocommit
|_ Salt: [----]

Having an exposed MySQL database in itself isn’t an exploit. However, the goal is to protect the data inside of the database. An exploit serves to break that protection and for an attacker to retrieve the database’s contents.

The problem here is that I can talk to the MySQL database like the owner can. Most importantly, I can make authentication attempts.

When you can make authentication attempts, the only things stopping you from getting in is time, rate limiting, IDS (followed by action), IPS, some other security appliance, or everything breaking.

Based on the data I’ve collected so far, chances are there’s no security appliance in front of the application, so I’m confident I can go ahead and try to get authorization to the database. However, I used Fragroute to verify.

Brute force tends to be effective and fast because even though we all conceptually understand the importance of strong credentials, very few people implement it because they falsely believe they will never be attacked.

For this engagement, there was no WAF/IDS/IPS or rate limiting implemented on a public-facing MySQL database. Hydra made easy work of brute forcing the credentials.

[14945][mysql] host: [----] login: root password: [----]

I dumped the database and determined passwords were hashed with SHA-1 and salted, without pepper. JTR made easy work of this, and approximately 5 hours later I had 80% of the passwords. I also had patient information, emails and passwords. Uh oh! That’s a HIPAA violation if I’ve ever seen one!

Public Git server

One of the most powerful tools in a pentesters belt is Google. Using a basic Google search, I was able to find a public facing Git server with this telehealth company’s web and mobile app source code.


For obvious reasons, this is catastrophic for the company’s security.

Game Over

At this point I have a database dump with confidential patient health information and 80% yield on hashed passwords. I also have the source for the company’s web and mobile apps. I now know the mechanism of all data transfers, as well as information on architecture for video and audio streaming, which happens to be an expertise of mine. It took me almost no time at all, but I’ve done about as much damage I could do.

Moral of the story

Invest in security and be mindful of who you hire. Hackers can and will ruin your business if given the opportunity. They don’t play by the rules. You are a target, so prepare as such. Hope is not a strategy.

It may seem like the pentest example I provided here is uniquely bad, but it really isn’t. Take some time to reflect on how secure your network is. Think about how exposed Kerberos really is and how easy it is for somebody who knows it in and out to exploit. Think about how attackers are detected and prevented once inside your network. Think about how your REST APIs are secured. Think about how your development logic can be leveraged against you. And think about the thousands of people out there actively looking for a challenge, and who may pick you as the next target.

Technology is the future. We’re in a transitionary period where there are no barriers to entry and everyone is embracing it. Security is an issue and liability, and it will be for many years to come. Don’t fall victim to complacency and wishful thinking. Embrace best practices. Go above and beyond. If not for pride in your own work, then for the people you serve.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s