[BreachExchange] Medical Records Exposed via GitHub Leaks

[Destry Winant]

https://www.databreachtoday.com/blogs/medical-records-exposed-via-github-leaks-p-2933

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: Restructuring Your Third-Party Risk Management Program

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."

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.

Xybion's billing dashboard includes such information as the amount of
money flowing through the system, the amount of paid and rejected
insurance claims, as well as billing sources and providers. (Source:
"No Need to Hack When It's Leaking" report)

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.