Medical Records Exposed via GitHub LeaksReport: 9 Leaks Account for Exposure of PHI for at Least 150,000 Patients
Repeat after me: Do not store hardcoded credentials for systems in GitHub repositories. Also make sure that none of your vendors or business associates are doing that.
See Also: What is next-generation AML?
GitHub provides hosting for software development using the open source version control system called Git. Many organizations rely on GitHub to help them maintain code.
"The problems we describe and the recommendations apply to other sectors as well."
Unfortunately, more than a few developers continue to accidentally expose administrator credentials via code they post to public GitHub repositories. Such credentials can give enterprising attackers a way to directly access sensitive systems, databases, email inboxes and more.
The latest example comes from a new report that describes how nine U.S. organizations have exposed protected health information, or PHI, for a total of at least 150,000 patients.
That information was gathered by Jelle Ursem (@SchizoDuckie), a Netherlands-based security researcher who over the past 18 months says he's found and reported GitHub credential exposure problems directly to more than 400 organizations, including cybersecurity firm Comodo.
The researcher, along with a privacy advocate known as "Dissent" (@PogoWasRight), who runs the Databreaches.net blog, has published a new report: "No Need to Hack When It's Leaking: GitHub Healthcare Leaks Protected Health Information On the Public Web."
"We describe nine cases, causes and recommendations," Dissent writes. "But the problems we describe and the recommendations apply to other sectors as well."
Before you read it, care to guess how many of the 9 entities did not respond to initial attempts at responsible disclosure?— Dissent Doe, PhD (@PogoWasRight) August 17, 2020
The organizations are AccQData, MaineCare, MedPro Billing, Shields Health Care Group, Texas Physician House Calls, VirMedica, Waystar, Xybion and "one entity that we are not naming at the present time but are describing," she says.
All of the exposed data was discovered by Ursem via GitHub searches, and some of it had been inappropriately exposed for years. The report describes the ease of finding such data:
"Ursem, who unabashedly claims to be 'the lamest hacker you know,' uses variations on simple search phrases like 'companyname password' (or in this case, 'medicaid password FTP') to quickly find potentially vulnerable, hardcoded login usernames and passwords for systems. You don't even need to be a nerd to be able to do this, he notes - literally anyone could do the same."
Using those credentials, a security researcher - or in a potential worst-case scenario for an organization, a criminal with extortionist tendencies - can log into corporate databases or FTP hosts, as well as users' Office 365 or Gmail accounts.
Ursem reached out to Dissent for help, owing to his failed attempts to notify the nine organizations - either because they refused to respond, or he could find no way to contact them. In at least one case, an organization later told Dissent that it thought Ursem had been attempting to socially engineer them.
Clearly, more organizations would benefit from offering a contact point for well-intentioned security researchers to give them a heads-up on any problems they've discovered.
Cautionary Tale: The Uber Debacle
The problems described in the report from Ursem and Dissent persist despite the perils of administrator credentials ending up in public-facing GitHub repositories being well known, leading not just to the exposure of protected health information, but also personally identifiable information.
Witness the Uber debacle, in which the ride-sharing company in October 2016 paid $100,000 through the HackerOne bug-bounty program to two men who discovered a leak that allowed them to access 57 million accounts of its riders and drivers.
In code they'd posted to GitHub, Uber's developers had left credentials that enabled the two men to access a backup file stored on Amazon's S3 storage service, which contained the rider and driver details.
In a classic "it's not the crime but the coverup" move, Uber landed in hot water because it failed to disclose the breach until November 2017. What it described also looked less like a bug bounty and more like they'd been at the receiving end of an extortion shakedown (see: Uber: 'No Justification' for Breach Cover-Up). Indeed, the two men - one Canadian, the other a Florida resident - later pleaded guilty in U.S. federal court to hacking both Uber and Lynda.com.
Uber later reached a $148 million settlement agreement with the attorneys general of all 50 U.S. states and the District of Columbia, and was fined a total of more than $1 million by data protection authorities in both the U.K. and the Netherlands, over the security failures leading to the breach, as well as its coverup.
Hits by GnosticPlayers, ShinyHunters
Other groups have also shaken organizations down, using credentials obtained via GitHub. From 2018 to 2019, a group known as GnosticPlayers used this practice against dozens of organizations. More recently, a group called ShinyHunters has followed in the GnosticPlayers' footsteps, for example, to steal information from Microsoft's private GitHub repositories, among many other victims (see: Anatomy of a Breach: Criminal Data Brokers Hit Dave).
Data breaches or inadvertently exposed data also continues to be traced to unprotected MongoDB databases - sometimes containing data copied by an organization's business partners - as well as to misconfigured Elasticsearch databases and other so-called big data repositories.
Lock Down GitHub
For organizations using GitHub to manage code, the report from Ursem and Dissent offers advice for locking it down. Start by requiring developers to use private repositories, and make it mandatory to use multifactor authentication to protect email accounts and third-party services.
They also recommend training developers to never "embed passwords or authentication tokens in code repositories," ensuring developers never use live production data in GitHub repositories, and deleting repositories when they are no longer required. Organizations must also audit their developers' compliance with security policies, and demand to see audits from their business partners, to verify that they're correctly locking down their use of GitHub.