Vulnerabilities in a Third-Party Healthcare Payment Processor

Following a visit to our area hospital, my wife received an email notifying her of an account that was setup on her behalf to facilitate payments online, presumably because she had elected to receive bills electronically when initially filling out her paperwork. It sounded a lot like a phishing email at first, so I started to look into it further.

I did a little research and found the same link in the email above on Christiana Care’s site, so I setup my wife’s account and logged in to the portal. Here’s a look at the initial screen:

This is actually a third party payment processor developed by BYL Companies, LLC. While there is not a ton of information related to the office visits stored in this application, it does include some details regarding the specific department visited and a high-level description of the services rendered in the “Description” field above — obviously very personal information.

The portal is quite simple in terms of functionality, mostly only allowing the user to make payments on outstanding balances and managing personal information/preferences. More interestingly, it also allows the user to manage multiple accounts (assuming they’ve been added through the application). This would, for example, allow me to manage outstanding invoices with other practices who use the same “MyBalanceOnline” system, e.g. a family doctor.

As I was proxying my traffic and navigating throughout the various pages, I noticed some interesting requests. The first one seemed to handle the account changing functionality:

GET https://christianacare.mybalanceonline.com/Account/ChangeAccount?apiAccountID=124399&goHome=True HTTP/1.1
Host: christianacare.mybalanceonline.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Referer: https://christianacare.mybalanceonline.com/Home/AccountHome?requestType=AccountOverview
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: ***REMOVED***

Note the apiAccountID  parameter included in the query string. Based on some of my other passive observations of the requests/responses, I had a strong suspicion that this parameter was an insecure direct object reference. After reaching out to some contacts who I thought might also exist in the portal, I found a volunteer who confirmed I could attempt to view his details (in case it was successful). I replayed the above request, substituting my apiAccountID with his in order to test. Shockingly, this confirmed my suspicion: any authenticated user of the system could use the application as another user entirely, granting an attacker access to some of the details of the victim’s medical history, as well as personal contact information.

If this was not bad enough, another request revealed even more serious issues:

POST https://christianacare.mybalanceonline.com/api/content/getcontent HTTP/1.1
Host: christianacare.mybalanceonline.com
Connection: keep-alive
Content-Length: 298
Accept: */*
Origin: https://christianacare.mybalanceonline.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Content-Type: application/json; charset=UTF-8
Referer: https://christianacare.mybalanceonline.com/Payment/PayByCheck
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: ***REMOVED***

{"Header":{"UserName":"***REMOVED***","Password":"***REMOVED***"},"ContentID":"Voucher","LatitudeAPIAccountID":"***REMOVED***","Xml":"<FileNumber>***REMOVED***</FileNumber><Account>***REMOVED***</Account><AccountName>Longshore, Sherie</AccountName><VoucherDate>03/08/2016</VoucherDate><PaymentAmount>0.00</PaymentAmount>"}

Note the JSON payload including a plain text username and password. While these values did not match the credentials for any related user account, they did appear to belong to a service or administrative account (I did not confirm/test this).

The more I reviewed the web application, the more concerned I grew — here is a third party healthcare payment processor, likely used by multiple hospitals and medical practices (HIPAA compliance?), making careless mistakes that impact all of its users, which almost definitely has existed since its launch (roughly early March of 2014, according to archive.org). Little did I know, this was only the start.

Disclosure

Given the seriousness of the issues above, I immediately attempted to reach out to BYL Companies. After a few days of trying various contact methods, I finally got in touch with their Director of Information Technology. I sent over the details of the two vulnerabilities above and received a response later in the day indicating they were both patched — a quick turnaround, which was certainly a plus.

Although the two issues had been patched, I was still highly concerned about the security of the application overall as a user of the system — if I had identified these two very simple issues within a few minutes of use, how many more vulnerabilities might exist? I expressed my subsequent concerns with my contact, recommending a full audit of their software by any reputable application security firm. The response I received only added to my concerns:

Of course, a web application firewall is great to have in place, but it won’t protect you from mistakes in business logic or authorization. Further concerning is the fact that they are already utilizing security firms, as worthless as they might be. Again, the vulnerabilities I reported above would have unequivocally been caught by even the most rudimentary pen test. After expressing further concerns, I later received a very generic response indicating that they had “addressed” all of my concerns. I asked for more specific details but never received a response.

There’s also the familiar false sense of security that users are encouraged to believe, as evidenced by the “security” and certification seals plastered on the site:

So where does that leave us?

Conclusion

It seems that certifications, compliance, regulations, “security” seals, and even penetration tests are not preventing, or even closely addressing, some of the very serious information security threats that users (and in this case, by extension, hospitals) are facing seemingly everywhere they turn.

Traditional approaches to information security, as exemplified here, seem to be failing miserably. Although Delaware Governor Jack Markell recently established the Delaware Cyber Security Advisory Council (a noble, and worthy-sounding cause), I’m not optimistic that his efforts will result in significant improvement. Though I don’t know DCSAC’s exhaustive member list, the titles in the Executive Order mostly seem to include high-ranking government officials (e.g. the secretary of Delaware’s Department of Safety and Homeland Security and the director of the state Emergency Management Agency) — notably lacking individuals bringing real-world perspective and technical expertise.

Information technology has been one of the largest innovations of our time, yet our reliance on traditional approaches to solve some of its challenges seems nonsensical. Legalizing and protecting legitimate security research would be a great start, along with increasing the adoption of disclosure programs — local and state governments included.

Share this: Facebooktwitterlinkedin