Recently, the improper use of GitHub led to a large-scale HIPAA security breach, leaving the protected health information (PHI) of 150,000 – 200,000 patients available through publicly searchable employee login credentials for nine healthcare organizations.
Software developers use GitHub for source code management and version control when creating, or making changes to, software. One feature of GitHub is the ability to use a repository to store your code that can be referred back to as you are developing your software. The caveat to this is that if you use a public repository to store your code, which is the default setting in GitHub, your data is available, searchable, and can be copied by anyone. When creating software for an organization, especially one that hosts sensitive information, it is important for developers to use a private repository.
HIPAA Security Breach: What Happened
Jelle Ursem, an ethical security researcher, decided to do research on whether or not GitHub had any medical data available for public view. What he found was concerning to say the least, a HIPAA security breach on a massive scale.
Within 10 minutes, Ursem, self-described as the “lamest hacker you know,” was able to find usernames and passwords for nine healthcare organizations, including covered entities and business associates. All he had to do was conduct a simple search for terms such as “companyname password” and “medicaid password FTP” to find the login credentials for these organizations. Upon finding the login information, he was easily able to gain access to employees’ email accounts without being detected.
Ursem attempted to contact the organizations to let them know that their information was available for public view, reaching out to databreaches.net for assistance. Together, they were able to contact eight of the nine organizations.
These included:
Xybion, MedPro Billing, Texas Physician House Calls, VirMedica, MaineCare, Waystar, Shields Health Care Group, AccQData, and an organization that is unnamed since their data is still available for public view.
To provide healthcare software developers with information on how the data appeared publicly, Ursem and Dissent Doe of databreaches.net, created a report. The report details what the developers did wrong that caused the data to be exposed, and how to use the platform in a secure manner.
The report found that the leaks were mostly due to software developers improper use of GitHub. The following are the common errors developers made that caused the data exposure:
◈ Embedding hard-coded login credentials (usernames and passwords) in code when they should have been configured to be an option on the server running the code
◈ Failing to use private repositories making the data easily viewable to the public
◈ Failing to implement multi-factor or two-factor authentication for email accounts
◈ Leaving repositories that were no longer needed unattended instead of deleting them
What made matters worse is that some of this data was left available for public exposure for years before Ursem discovered the errors.
HIPAA Security Breach: How to Prevent GitHub Leaks
The researches have made several recommendations to prevent a similar HIPAA security breach from occurring in the future. Their recommendations include:
◈ Provide a way for researchers to responsibly disclose security incidents: Create a ‘disclosure@yourcompany’ e-mail address on your Contact / About us webpage that’s monitored by your CISO, CSO or CTO, or MSP/IT provider.
◈ Train employees and especially your first line support and social media team on procedures for escalating notifications they receive.
◈ Teach them how to avoid a phishing attempt, but make sure they always escalate it to have it investigated by someone who has the skills to determine credibility of the communication.
◈ Regularly search GitHub for your firm’s name and domain name(s). Even if you do not use a developer, one of your business associates or vendors might.
◈ Regularly force password changes and do not allow password reuse. If you have objections to this recommendation, at least rotate passwords used by former employees after they left.
◈ Strong passwords are just as useless as weak passwords if you upload them to GitHub and do not change them for three years.
◈ Lock down connections by IP address. Is there really a need for your webservice or secure FTP site to communicate with the whole world? Or do you just want to open the door for a couple specific people?
◈ Use 2FA or MFA for every third party service you use that supports it.
◈ Make sure to enforce admin approval of devices used for MFA and that every account gets logged in to at least once when enabling it. Ursem has encountered more than one case where he would have been able to establish his own phone number as the MFA authenticator.
◈ Require developers to use private repositories; prohibit public repositories. Recognize, however, that attackers may attempt to brute force or credential stuff to gain access to private repositories.
◆ Never allow developers to embed passwords or authentication tokens in code repositories;
◆ Prohibit the use of real (production) data in GitHub repositories; and
◆ When developers terminate, ensure that their repository(ies) is/are deleted.
◈ Vet your business associates. Do they hold themselves to any information security standards like ISO-27001?
This HIPAA security breach was partly the fault of the organizations that contracted these developers for failing to vet them to ensure that they were maintaining the confidentiality, integrity, and availability of PHI. As part of your due diligence, you must always send your business associates vendor questionnaires to assess their safeguards BEFORE you share any PHI with them, or give them access to systems containing PHI.
One of the key takeaways from this mishap is, when developing code for organizations that host sensitive data, or when you don’t need to collaborate on code development, to use a private repository for your code.
To read the full report, please click here.
