Healthcare Cybersecurity

Cisco Warns of Active Exploitation of Zero Day Flaws in IOS XR Software Used by Cisco Carrier-Grade Routers

Posted by HIPAA Journal

Two zero-day vulnerabilities in the IOS XR software used by Cisco Network Converging System carrier-grade routers are being actively exploited by hackers. The first attempts at exploitation of the vulnerabilities were detected by Cisco on August 25, 2020.

While patches have yet to be released by Cisco to correct the vulnerabilities, there are workarounds that can be used to reduce the risk of the vulnerabilities being exploited.

The vulnerabilities, tracked as CVE-2020-3566 and CVE-2020-3569, are present in the distance vector multicast routing protocol (DVMRP) and affect all Cisco devices that use the IOS XR version of its Internetworking Operating System, if the software has been configured to use multicast routing. Multicast routing is used to save bandwidth and involves sending certain data in a single stream to multiple recipients.

An unauthenticated attacker could exploit the flaws to exhaust the process memory of a device by remotely sending specially crafted internet group management protocol (IGMP) packets to the device. If the flaws are successfully exploited it would cause memory exhaustion resulting in a denial of service and could cause instability of other processes, such as interior and exterior routing protocols.

The flaws have been assigned a CVSS v3 base score of 8.6 out of 10.Cisco says the risk of exploitation is high, so it is important for patches to be applied as soon as they are released, but for mitigations to be implemented until patches are made available. The mitigations suggested by Cisco are not complete workarounds but will reduce the risk of exploitation.

Users of vulnerable Cisco products should rate limit IGMP traffic. Administrators must determine what their normal rate of IGMP traffic is and should then set a rate lower than the average rate. This will not prevent exploitation of the flaws, but by reducing the traffic rate, the time taken to exploit the flaws will be increased, which would allow administrators extra time to perform recovery actions.

Customers can also implement an access control entry (ACE) to an existing interface control list (ACL) which will help to block attacks, or a new ACL can be created for a specific interface that denies DVMRP traffic inbound on that interface.

Instructions for determining whether multicast routing is enabled and implementing the mitigations are detailed in the Cisco security advisory. Cisco is currently working on patches to correct the flaws.

The post Cisco Warns of Active Exploitation of Zero Day Flaws in IOS XR Software Used by Cisco Carrier-Grade Routers appeared first on HIPAA Journal.

Agent Tesla Trojan Distributed in COVID-19 Phishing Campaign Offering PPE

Posted by HIPAA Journal

A sophisticated COVID-19 themed phishing campaign has been detected that spoofs chemical manufacturers and importers and exporters offering the recipient personal protective equipment (PPE) such as disposable face masks, forehead temperature thermometers, and other medical supplies to help in the fight against COVID-19.

The campaign was detected by researchers at Area 1 Security, who say the campaign has been active since at least May 2020 and has so far targeted thousands of inboxes. The threat actors behind the campaign regularly change their tactics, techniques, and procedures (TTPs) to evade detection by security tools, typically every 10 days.

The threat actors regularly rotate IP addresses for each new wave of phishing emails, frequently change the companies they impersonate, and revise their phishing lures. In several of the intercepted emails, in addition to spoofing a legitimate company, the names of real employees along with their email addresses and contact information are used to add legitimacy. The emails use the logos of the spoofed companies and the correct URL of the company in the signature. By including correct contact information, should any checks be performed by the recipient they may be led to believe the message is genuine.

Source: Area 1 Security

The aim of the threat actors is to deliver the Agent Tesla Trojan. Agent Tesla is an advanced remote access Trojan (RAT) that gives the attackers access to an infected device, allowing them to perform a range of malicious actions. The RAT is capable of logging keystrokes on an infected device and stealing sensitive information from the user’s AppData folder, which is sent to the command and control server via SMTP. The malware can also steal data from web browsers, email, FTP and VPN clients.

The RAT is offered on hacking forums as malware-as-a-service and has proven popular due to the ease of conducting campaigns and the low cost of using the malware, although the researchers note that Agent Tesla can be downloaded for free via a torrent available on Russian websites. The malware includes a User interface (UI) that allows users to track infections and access data stolen by the malware.

The RAT is delivered a compressed file attachment. If the attachment is extracted, the recipient will be presented with an executable file with a double extension, that will appear to be a .pdf file. Since Windows is configured by default to hide known file extensions, the extracted file will appear to be a.pdf file when it is actually an executable file. The display name is “Supplier-Face Mask Forehead Thermometer.pdf”, but the actual file is “Supplier-Face Mask Forehead Thermometer.pdf.exe” or “Supplier-Face Mask Forehead Thermometer.pdf.gz”.

The hash is frequently changed to avoid being detected as malware by security solutions. When the hash is changed, the malware will not be detected by signature-based security solutions until definitions are updated to include the new hash.

The attackers also take advantage of flaws in the configuration of email authentication protocols such as DMARC, DKIM, and SPF when spoofing the domains of legitimate companies.

According to the researchers, the attackers are mostly using a shotgun approach, rather than spear phishing emails on a select number of targets; that said, the researchers have identified some targeted attacks on executives of Fortune 500 companies.

Since the campaign is regularly updated to evade detection by security solutions, it is important to raise awareness of the campaign with employees to prevent them inadvertently installing the malware.

The post Agent Tesla Trojan Distributed in COVID-19 Phishing Campaign Offering PPE appeared first on HIPAA Journal.

OCR Highlights the Importance of Creating and Maintaining a Comprehensive IT Asset Inventory

Posted by HIPAA Journal

The risk analysis is one of the most important requirements of the HIPAA Security Rule, yet it is one of the most common areas of noncompliance discovered during Office for Civil Rights data breach investigations, compliance reviews, and audits. While there have been examples of HIPAA-covered entities ignoring this requirement entirely, in many cases noncompliance is due to the failure to perform a comprehensive risk analysis across the entire organization.

In order to perform a comprehensive risk analysis to identity all threats to the confidentiality, integrity, and availability of electronic protected health information (ePHI), you must first know how ePHI arrives in your organization, where it flows, where all ePHI is stored, and the systems that can be used to access that information. One of the common reasons for a risk analysis compliance failure, is not knowing where all ePHI is located in the organization.

In its Summer 2020 Cybersecurity Newsletter, OCR highlighted the importance of maintaining a comprehensive IT asset inventory and explains how it can assist with the risk analysis process. An IT asset inventory is a detailed list of all IT assets in an organization, which should include a description of each asset, serial numbers, names, and other information that can be used to identify the asset, version (operating system/application), its location, and the person to whom the asset has been assigned and who is responsible for maintaining it.

“Although the Security Rule does not require it, creating and maintaining an up-to-date, information technology (IT) asset inventory could be a useful tool in assisting in the development of a comprehensive, enterprise-wide risk analysis, to help organizations understand all of the places that ePHI may be stored within their environment, and improve their HIPAA Security Rule compliance,” explained OCR in the newsletter.

An IT asset inventory should not only include physical hardware such as mobile devices, servers, peripherals, workstations, removable media, firewalls, and routers. It is also important to list software assets and applications that run on an organization’s hardware, such as anti-malware tools, operating systems, databases, email, administrative and financial records systems, and electronic medical/health record systems.

IT solutions such as backup software, virtual machine managers/hypervisors, and other administrative tools should also be included, as should data assets that include ePHI that an organization creates, receives, maintains, or transmits on its network, electronic devices, and media.

“Understanding one’s environment – particularly how ePHI is created and enters an organization, how ePHI flows through an organization, and how ePHI leaves an organization – is crucial to understanding the risks ePHI is exposed to throughout one’s organization.”

For smaller healthcare organizations, an IT asset inventory can be created and maintained manually, but for larger, more complex organizations, dedicated IT Asset Management (ITAM) solutions are more appropriate. These solutions include automated discovery and update processes for asset and inventory management and will help to ensure that no assets are missed.

When creating an IT asset inventory to aid the risk analysis, it is useful to include assets that are not used to create, receive, process, or transmit ePHI, but may be used to gain access to ePHI or to networks or devices that store ePHI.  IoT devices may not store or be used to access ePHI, but they could be used to gain access to a network or device that would allow ePHI to be viewed.

“Unpatched IoT devices with known vulnerabilities, such as weak or unchanged default passwords installed in a network without firewalls, network segmentation, or other techniques to deny or impede an intruder’s lateral movement, can provide an intruder with a foothold into an organization’s IT network,” suggests OCR. “The intruder may then leverage this foothold to conduct reconnaissance and further penetrate an organization’s network and potentially compromise ePHI.” There have been multiple incidents where hackers have exploited a vulnerability in one of these devices to penetrate an organization’s network and access sensitive data.

Organizations that do not have a comprehensive IT asset inventory could have gaps in recognition and mitigation of risks to ePHI. Only with a comprehensive understanding of the entire organization’s environment will it be possible to minimize those gaps and ensure that an accurate and thorough risk analysis is performed to ensure Security Rule compliance.

Maintaining an IT asset inventory may not be a Security Rule requirement but covered entities must create policies and procedures that govern the receipt and removal of hardware and electronic media that contain ePHI into and out of a facility. An IT asset inventory can also be used for this purpose. The IT asset inventory can also be compared with the results of network scanning and mapping processes to help identify unauthorized devices that have been connected to the network and used as part of vulnerability management to ensure that no devices, software, or other assets are missed when performing software updates and applying security patches.

The NIST Cybersecurity Framework can be leveraged to assist with the creation of an IT asset inventory. NIST has also produced guidance on IT asset management in its Cybersecurity Practice Guide, Special Publication 1800-5. The HHS Security Risk Assessment Tool can also help with IT asset management. It includes inventory capabilities that allow for manual entry or bulk loading of asset information with respect to ePHI.

The post OCR Highlights the Importance of Creating and Maintaining a Comprehensive IT Asset Inventory appeared first on HIPAA Journal.

Study Reveals Increase in Credential Theft via Spoofed Login Pages

Posted by HIPAA Journal

A new study conducted by IRONSCALES shows there has been a major increase in credential theft via spoofed websites. IRONSCALES researchers spent the first half of 2020 identifying and analyzing fake login pages that imitated major brands. More than 50,000 fake login pages were identified with over 200 brands spoofed.

The login pages are added to compromised websites and other attacker-controlled domains and closely resemble the genuine login pages used by those brands. In some cases, the fake login is embedded within the body of the email.

The emails used to direct unsuspecting recipients to the fake login pages use social engineering techniques to convince recipients to disclose their usernames and passwords, which are captured and used to login to the real accounts for a range of nefarious purposes such as fraudulent wire transfers, credit card fraud, identity theft, data extraction, and more.

IRONSCALES researchers found the brands with the most fake login pages closely mirrored the brands with the most active phishing websites. The brand with the most fake login pages – 11,000 – was PayPal, closely followed by Microsoft with 9,500, Facebook with 7,500, eBay with 3,000, and Amazon with 1,500 pages.

While PayPal was the most spoofed brand, fake Microsoft login pages pose the biggest threat to businesses. Stolen Office 365 credentials can be used to access corporate Office 365 email accounts which can contain a range of highly sensitive data and, in the case of healthcare organizations, a considerable amount of protected health information.

Other brands that were commonly impersonated include Adobe, Aetna, Alibaba, Apple, AT&T, Bank of America, Delta Air Lines, DocuSign, JP Morgan Chase, LinkedIn, Netflix, Squarespace, Visa, and Wells Fargo.

The most common recipients of emails in these campaigns with individuals working in the financial services, healthcare and technology industries, as well as government agencies.

Around 5% of the fake login pages were polymorphic, which for one brand included more than 300 permutations. Microsoft login pages had the highest degree of polymorphism with 314 permutations. The reason for the high number of permutations of login pages is not fully understood. IRONSCALES suggests this is because Microsoft and other brands are actively searching for fake login pages imitating their brand. Using many different permutations makes it harder for human and technical controls to identify and take down the pages.

The emails used in these campaigns often bypass security controls and are delivered to inboxes. “Messages containing fake logins can now regularly bypass technical controls, such as secure email gateways and SPAM filters, without much time, money or resources invested by the adversary,” explained IRONSCALES. “This occurs because both the message and the sender are able to pass various authentication protocols and gateway controls that look for malicious payloads or known signatures that are frequently absent from these types of messages.”

Even though the fake login pages differ slightly from the login pages they spoof, they are still effective and often successful if a user arrives at the page. IRONSALES attributes this to “inattentional blindness”, where individuals fail to perceive an unexpected change in plain sight.

The post Study Reveals Increase in Credential Theft via Spoofed Login Pages appeared first on HIPAA Journal.

FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers

Posted by HIPAA Journal

An ongoing voice phishing (vishing) campaign is being conducted targeting remote workers from multiple industry sectors. The threat actors impersonate a trusted entity and use social engineering techniques get targets to disclose their corporate Virtual Private Network (VPN) credentials.

The Federal Bureau of Investigation (FBI) and the DHS Cybersecurity and infrastructure Security Agency (CISA) have issued a joint advisory about the campaign, which has been running since mid-July.

The COVID-19 pandemic forced many employers to allow their entire workforce to work from home and connect to the corporate network using VPNs. If those credentials are obtained by cybercriminals, they can be used to access the corporate network.

The threat group first purchases and registers domains that are used to host phishing pages that spoof the targeted company’s internal VPN login page and SSL certificates are obtained for the domains to make them appear authentic. Several naming schemes are used for the domains to make them appear legitimate, such as [company]-support, support-[company], and employee-[company].

The threat group then gathers information about company employees by scraping social media profiles and compiles dossiers on specific employees. The types of information collected include personal information such as an employee’s name, address, personal phone number, job title, and length of time at the company. That information is then used to gain the trust of the targeted employee.

Employees are then called from a voice-over-IP (VOIP) number. Initially the VOIP number was anonymous, but later in the campaign the attackers started spoofing the number to make it appear that the call was coming from a company office or another employee in the firm. Employees are then told they will receive a link that they need to click to login to a new VPN system. They are also told that they will need to respond to any 2-factor authentication and one-time password communications sent to their phone.

The attackers capture the login information as it is entered into their fraudulent website and use it to login to the correct VPN page of the company. They then capture and use the 2FA code or one-time password when the employee responds to the SMS message.

The attackers have also used SIM-swap to bypass the 2FA/OTP step, using information gathered about the employee to convince their mobile telephone provider to port their phone number to the attacker’s SIM. This ensures any 2FA code is sent directly to the attacker. The threat actors use the credentials to access the company network to steal sensitive data to use in other attacks. The FBI/CISA say the end goal is to monetize the VPN access.

The FBI/CISA recommend organizations restrict VPN connections to managed devices using mechanisms such as hardware checks or installed certificates, to restrict the hours that VPNs can be used to access the corporate network, to use domain monitoring tools to monitor web applications for unauthorized access and anomalous activities.

A formal authentication procedure should also be introduced for employee-to-employee communications over the public telephone network where a second factor is required to authenticate the phone call prior to the disclosure of any sensitive information.

Organizations should also monitor authorized user access and usage to identify anomalous activities and employees should be notified about the scam and instructed to report any suspicious calls to their security team.

The post FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers appeared first on HIPAA Journal.

Millions of Devices Affected by Vulnerability in Thales Wireless IoT Modules

Posted by HIPAA Journal

A vulnerability in components used in millions of IoT devices could be exploited by hackers and used to steal sensitive information and gain control of vulnerable devices, which could then be used in attacks on internal networks. Thales components are used by more than 30,000 companies, whose products are used across a broad range of industry sectors including energy, telecommunications, and healthcare.

The flaw exists in the Cinterion EHS8 M2M module, along with several other products in the same line (BGS5, EHS5/6/8, PDS5/6/8, ELS61, ELS81, PLS62). The embedded modules provide processing power and allow devices to send and receive data over wireless mobile connections. The module is also used as a digital secure repository for sensitive information such as passwords, credentials and operational code. The flaw would allow an attacker to gain access to the contents of that repository.

X-Force Red researchers discovered a method for bypassing security measures protecting code and files in the EHS8 module. “[The modules] store and run Java code, often containing confidential information like passwords, encryption keys and certificates,” said Adam Laurie, of IBM’s X-Force Threat Intelligence team.

“This vulnerability could enable attackers to compromise millions of devices and access the networks or VPNs supporting those devices by pivoting onto the provider’s backend network. In turn, intellectual property, credentials, passwords and encryption keys could all be readily available to an attacker,” explained the researchers in a recent blog post. “Using information stolen from the modules, malicious actors can potentially control a device or gain access to the central control network to conduct widespread attacks – even remotely via 3G in some cases.”

In medical devices, the flaw could be exploited to alter readings from patient monitoring devices, either to generate false alerts or hide critical changes in a patient’s vital signs. In the case of a drug pump, changes could be made to deliver an overdose or stop a dose of critical medication from being administered.

The researchers also point out that the flaw could be exploited in smart meters used by energy companies to falsely report energy usage. This would result in increases or decreases in bills, but if sufficient numbers of devices were compromised and controlled by an attacker, it could cause damage to the grid and result in blackouts.

The vulnerability, tracked as CVE-2020-15858, was identified in September 2019 and Thales was immediately notified. Thales has been working closely with IBM X Force Red team to develop, test, and distribute a patch. The patch was released in February 2020 and Thales has been working hard to make sure its customers are aware of the patch and the need to apply that patch promptly.

It is taking some time for the patches to be applied by device manufacturers. The patching process is considerably slower for devices used in highly regulated industry sectors. For instance, medical devices may will require recertification after patching, which is a time-incentive process.

Addressing the vulnerability is largely down to device manufacturers, who must make patching a priority. IBM X Force Red says that process has been ongoing for 6 months, but there are still many devices that remain vulnerable. Patches could be applied via a USB device plugged directly into the vulnerable device using the management console or via an over-the-air update. The latter would be preferable, but that would depend on whether the device is accessible over the Internet.

The post Millions of Devices Affected by Vulnerability in Thales Wireless IoT Modules appeared first on HIPAA Journal.

New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers

Posted by HIPAA Journal

A new peer-to-peer (P2) botnet has been discovered that is targeting SSH servers found in IoT devices and routers which accept connections from remote computers. The botnet, named FritzFrog, spreads like a computer worm by brute forcing credentials.

The botnet has been analyzed by security researchers at Guardicore Labs and was found to have successfully breached more than 500 servers, with that number growing rapidly. FritzFrog is modular, multi-threaded, and fileless, and leaves no trace on the machines it infects. FritzFrog assembles and executes malicious payloads entirely in the memory, making infections hard to detect.

When a machine is infected, a backdoor is created in the form of an SSH public key, which provides the attackers with persistent access to the device. Additional payloads can then be downloaded, such as a cryptocurrency miner. Once a machine is compromised, the self-replicating process starts to execute the malware throughout the host server. The machine is added to the P2P network, can receive and execute commands sent from the P2P network, and is used to propagate the malware to new SSH servers. The botnet has been active since at least January 2020 and has been used to target government, healthcare, education, and the finance sectors.

“Nodes in the FritzFrog network keep in close contact with each other. They constantly ping each other to verify connectivity, exchange peers and targets and keep each other synced,” explained the researchers. “The nodes participate in a clever vote-casting process, which appears to affect the distribution of brute-force targets across the network. Guardicore Labs observed that targets are evenly distributed, such that no two nodes in the network attempt to “crack” the same target machine.”

In contrast to other forms of botnet, FritzFrog has greater resiliency, as control of the botnet is decentralized among different nodes, so there is no single command and control (C2) server, which means there can be no single point of failure. According to Guardicore Labs, FritzFrog has been written in Golang from scratch, with the P2P protocol completely proprietary, with almost everything about the botnet unique and not shared with other P2P botnets.

To analyze how FritzFrog worked and to explore its capabilities, Guardicore Labs’ researchers developed an interceptor in Golang which allowed them to participate in the malware’s key-exchange process and receive and send commands. “This program, which we named frogger, allowed us to investigate the nature and scope of the network. Using frogger, we were also able to join the network by ‘injecting’ our own nodes and participating in the ongoing P2P traffic.” Via frogger, the researchers determined that FritzFrog had succeeded in brute-forcing millions of SSH IP addresses at medical centers, banks, educational institutions, government organizations, and telecom companies.

The malware communicates over port 1234, but not directly. Traffic over port 1234 is easy to identify, so the malware uses a netcat utility program, which is usually used to monitor network traffic. “Any command sent over SSH will be used as netcat’s input, thus transmitted to the malware,” explained the researchers. FritzFrog also communicates over an encrypted channel and is capable of executing over 30 commands, which include creating a backdoor, connecting to other infected nodes and servers in the FritzFrog network, and monitoring resources such as CPU use.

While the botnet is currently being used to plant cryptocurrency mining malware (XMRig) on victims’ devices to mine Monero, the botnet could easily be repurposed to deliver other forms of malware and could be used for several other purposes. Ophir Harpaz, security researcher at Guardicore Labs, does not believe cryptocurrency mining is the main purpose of the botnet, due to the amount of code dedicated to mining Monero. Harpaz believes it is access to organizations’ networks which is the main aim, which can be extremely valuable. Access to breached servers could be sold or used in much more profitable attacks.

It is unclear who created the botnet or where they are located. It has spread globally, but the geographic origin of the initial attacks is not known. FritzFrog is also under active development, with the researchers identifying more than 20 versions of the FritzFrog binary.

The botnet relies on network security solutions that enforce traffic only by port and protocol, so process-based segmentation rules are required. Infection takes advantage of weak passwords that are susceptible to brute force attempts, so it is important for strong passwords to be set and to use public key authentication. The botnet targets IoT devices and routers with exposed SSH keys, so organizations can protect themselves by changing their SSH port or disabling access to SSH when the service is not in use. The researchers also point out that “it is crucial to remove FritzFrog’s public key from the authorized_keys file, preventing the attackers from accessing the machine.”

Guardicore Labs has published a script on GitHub that can be run to identify FritzFrog infections, along with known IoCs.

The post New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers appeared first on HIPAA Journal.

Three Vulnerabilities Identified in Philips SureSigns Vital Signs Monitors

Posted by HIPAA Journal

Three low- to medium-severity vulnerabilities have been identified in Philips SureSigns VS4 vital signs monitors. If exploited, an attacker could gain access to administrative controls and system configurations and alter settings to send sensitive patient data to a remote destination.

The vulnerabilities were identified by the Cleveland Clinic, which reported the flaws to Philips. Philips is unaware of any public exploits for the vulnerabilities and no reports have been received to date to indicate any of the vulnerabilities have been exploited.

The flaws have been categorized as improper input validation (CWE-20), Improper access control (CWE-284), and improper authentication (CWE-287).

Philips SureSigns VS4 receives input or data, but there is a lack of input validation controls to check the input has the properties to allow the data to be processed safely and correctly. This vulnerability is tracked as CVE-2020-16237 and has been assigned a CVSS V3 base score of 2.1 out of 10.

When a user claims to have a given identity, there are insufficient checks performed to prove that the identity of the individual is correct during authentication. This vulnerability is tracked as CVE-2020-16239 and has been assigned a CVSS V3 base score of 4.9 out of 10.

The highest severity flaw is due to insufficient access controls, which do not restrict, or incorrectly restrict, access to a resource from an unauthorized individual. Exploitation of the vulnerability could allow access to be gained to administrative controls and system configurations. This flaw is tracked as CVE-2020-16241 and has been assigned a CVSS V3 base score of 6.3 out of 10.

A security advisory about the flaws has now been released under Philips’ Coordinated Vulnerability Disclosure Policy, and mitigations have been suggested to reduce the potential for exploitation.

Philips recommends replacing Philips SureSigns VS4 devices with a newer technology. In the meantime, customers have been advised to change all system passwords on their devices and to use unique passwords for each device and to physically secure the devices when not in use.

The post Three Vulnerabilities Identified in Philips SureSigns Vital Signs Monitors appeared first on HIPAA Journal.

Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed

Posted by HIPAA Journal

A new report has revealed the personal and protected health information of patients and other sensitive data are being exposed online without the knowledge of covered entities and business associates through public GitHub repositories.

Jelle Ursem, a security researcher from the Netherlands, discovered at least 9 entities in the United States – including HIPAA-covered entities and business associates – have been leaking sensitive data via GitHub. The 9 leaks – which involve between 150,000 and 200,000 patient records – may just be the tip of the iceberg. The search for exposed data was halted to ensure the entities concerned could be contacted and to produce the report to highlight the risks to the healthcare community.

Even if your organization does not use GitHub, that does not necessarily mean that you will not be affected. The actions of a single employee or third-party contracted developer may have opened the door and allowed unauthorized individuals to gain access to sensitive data.

Exposed PII and PHI in Public GitHub Repositories

Jelle Ursem is an ethical security researcher who has previously identified many data leaks on GitHub, including by Fortune 500 firms, publicly traded companies, and government organizations. Ursem decided to conduct a search to find out if any medical data had been leaked on GitHub. It took just 10 minutes to confirm that it had, but it soon became clear that this was far from an isolated case.

Ursem conducted searches such as “companyname password” and “medicaid password FTP” and discovered several hard-coded usernames and passwords could be found in code uploaded to GitHub. Those usernames and passwords allowed him to login to Microsoft Office 365 and Google G Suite accounts and gain access to a wide range of sensitive information such as user data, contracts, agendas, internal documents, team chats, and the protected health information of patients.

“GitHub search is the most dangerous hacking tool out there,” said Ursem. Why go to the trouble of hacking a company when it is leaking data that can be found with a simple search on GitHub?

Ursem attempted to make contact with the companies concerned to alert them to the exposure of their data and ensure the information was secured, but making contact with those organizations and getting the data secured proved problematic, so Ursem contacted databreaches.net for assistance.

Together, Dissent Doe of DataBreaches.net and Ursem worked together to contact the organizations concerned and get the data secured. In some cases, they succeeded – with considerable effort – but even after several months of attempts at contacting the companies concerned, explaining the severity of the situation, and offering help to address the problems that led to the exposure of data, some of that data is still accessible.

9 Leaks Identified but There are Likely to be Others

The report details 9 leaks that affected U.S. entities – namely Xybion, MedPro Billing, Texas Physician House Calls, VirMedica, MaineCare, Waystar, Shields Health Care Group, AccQData – and one unnamed entity: Unnamed because the data is still accessible.

The most common causes of GitHub data leaks were developers who had embedded hard-coded credentials into code that had been uploaded into public GitHub repositories, the use of public repositories instead of private repositories, and developers who had abandoned repositories when they were no longer required, rather than securely deleting them.

For example, Ursem found that a developer at Xybion – a software, services and consulting company with a presence in workplace health issues – had left code in a public GitHub repository in February 2020. The code included hard-coded credentials for a system user that, in connection with other code, allowed Ursem to access billing back-office systems that contained the PHI of 7,000 patients, together with more than 11,000 insurance claims dating back to October 31, 2018.

It was a similar story with MaineCare – a state- and federally-funded program that provides healthcare coverage to Maine residents. In that case, hard-coded credentials gave Ursem administrative access to the entire website, access to the internal server infrastructure of MaineCare / Molina Health, MaineCare SQL data sources, and the PHI of 75,000 individuals.

The Typhoid Mary of Data Leaks

The report highlights one developer, who has worked with a large number of healthcare organizations, whose GitHub practices have led to the exposure of many credentials and the PHI of an estimated 200,000 clients. That individual has been called the “Typhoid Mary of Data Leaks”.

The developer made many mistakes that allowed client data to be exposed, including leaking the credentials of 5 employers on GitHub and leaving repositories fully accessible after work had been completed. In one case, the actions of that developer had allowed access to the central telephone system of a large entity in debt collection, and in another credentials allowed access to highly sensitive records for people with a history of substance abuse.

While it was not possible to contact that individual directly, it appears that the work of DataBreaches.net and Ursem has gotten the message through to the developer. The repositories have now been removed or made private, but not before the data was cloned by at least one third party.

This was just one example of several outsourced or contracted developers who were being used by HIPAA-covered entities and business associates, whose practices exposed data unbeknownst to the CEs and BAs.

“No matter how big or small you are, there’s a real chance that one of your employees has thrown the front door key under the doormat and has forgotten that the doormat is transparent,” explained Dissent Doe of DataBreaches.net. Regardless of whether your organization uses GitHub, HIPAA Journal believes the report to be essential reading.

The collaborative report from Jelle Ursem and DataBreaches.net explains how the leaks occurred, why they have gone undetected for so long, and details several recommendations on how data breaches on GitHub can be prevented – and detected and addressed quickly in the event that mistakes are made. You can download the full PDF report on this link.

Many thanks to Dissent Doe for notifying HIPAA Journal, to Jelle Ursem for discovering the data leaks, and for the hard work of both parties investigating the leaks, contacting the entities concerned, and highlighting the problem to help HIPAA-covered entities and their business associates take steps to prevent GitHub data breaches moving forward.

The post Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed appeared first on HIPAA Journal.