Healthcare Cybersecurity

May 2020 Healthcare Data Breach Report

May 2020 saw a marked fall in the number of reported healthcare data breaches compared to April, with 28 data breaches of 500 or more records reported to the HHS’ Office for Civil Rights. That is the lowest number of monthly breaches since December 2018 and the first time in 17 months that healthcare data breaches have been reported at a rate of less than one per day. The monthly total would have been even lower had one breach been reported by the business associate responsible for an improper disposal incident, rather than the 7 healthcare providers impacted by the breach.

Several cybersecurity companies have reported an increase in COVID-19-related breaches, such as phishing attacks that use COVID-19-themed lures. While there is strong evidence to suggest that these types of attacks have increased since the start of the pandemic, the number of cyberattacks appears to have broadly remained the same or increased slightly. Microsoft has reported that its data shows a slight increase in attacks, but says it only represents a blip and the number of threats and cyberattacks has changed little during the pandemic.

Threat activity does not appear to have dropped, so the fall in reported cyberattacks and data breaches could indicate that threat actors have taken the decision not to attack healthcare providers on the front line in the fight against COVID-19. The Maze ransomware gang publicly stated that it would not target healthcare providers during the COVID-19 pandemic, but many other ransomware gangs appear to have stepped up their attacks and are making no such concessions.

It is also possible that rather than cyberattacks and data breaches falling, covered entities and business associates have not been detecting breaches or have delayed reporting. The reason for the fall in reported breaches is likely to become clearer over the coming weeks and months and we will see if this is part of a new trend or if the drop is simply a blip.

While it is certainly good news that the number of breaches has fallen, there was a significant increase in the number of exposed and compromised healthcare records. There were 10 fewer data breaches reported in May 2020 than April, but 1,064,652 healthcare records were breached in May. That is more than twice the number of records breached in April.

Largest Healthcare Data Breaches in May 2020

Name of Covered Entity State Covered Entity Type Individuals Affected Type of Breach
Elkhart Emergency Physicians, Inc. IN Healthcare Provider 550,000 Improper Disposal
BJC Health System MO Business Associate 287,876 Hacking/IT Incident
Saint Francis Healthcare Partners CT Business Associate 38,529 Hacking/IT Incident
Everett & Hurite Ophthalmic Association PA Healthcare Provider 34,113 Hacking/IT Incident
Management and Network Services, LLC OH Business Associate 30,132 Hacking/IT Incident
Sanitas Dental Management FL Healthcare Provider 19,000 Loss
Mediclaim, LLC MI Business Associate 14,931 Hacking/IT Incident
Woodlawn Dental Center OH Healthcare Provider 14,419 Hacking/IT Incident
Mat-Su Surgical Associates, APC AK Healthcare Provider 13,146 Hacking/IT Incident
Mille Lacs Health System MN Healthcare Provider 10,630 Hacking/IT Incident

Causes of May 2020 Healthcare Data Breaches

The largest healthcare data breach of the month affected Elkhart Emergency Physicians, Inc. and involved the improper disposal of paper records by business associate Central Files Inc. Elkhart Emergency Physicians was one of seven Indiana healthcare providers to be affected by the breach. In total, the records of 554,876 patients were exposed as a result of that improper disposal incident. There was one other improper disposal incident reported in May, making this the joint second biggest cause of data breaches in the month. Those improper disposal incidents accounted for 52.17% of breached records in May. The mean breach size was 69,434 records and the median breach size was 938 records.

There were 8 reported unauthorized access/disclosure incidents reported, although those breaches only accounted for 2.35% of breached records in May. The mean breach size was 3,124 records and the median breach size was 3,220 records.

Hacking/IT incidents once again topped the list as the main cause of healthcare data breaches, accounting for 39.28% of the month’s breaches and 43.69% of breached records in May. The mean breach size was 42,290 records and the median breach size was 14,419 records.

There was one loss incident involving a network server that contained the records of 19,000 patients. There were no reports of theft of physical records or devices containing electronic protected health information.

The graph below shows the location of breached protected health information. For the past several months, email has been the most common location of breached PHI due to the high number of healthcare phishing attacks. The number of reported phishing attacks dropped in May, hence the lower than average number of email-related breaches. While the number of incidents fell, there was one major phishing attack reported. An attack on BJC Health System saw 3 email accounts compromised. Those accounts included emails and attachments containing the PHI of 287,876 patients.

May 2020 Healthcare Data Breaches by Covered Entity Type

In line with virtually every other month since the HITECH Act mandated the HHS’ Office for Civil Rights to start publishing summaries of data breaches on its’ Wall of Shame’, healthcare providers were hardest hit, with 21 reported data breaches. It was a good month for health plans, with only one reported breach, but a particularly bad month for business associates. 6 business associates reported data breaches in May, and a further 8 breaches involved business associates but were reported by the covered entity.

Healthcare Data Breaches by State

Data breaches were reported by covered entities and business associates in 17 states in May. Indiana was the worst affected state with 7 reported breaches of 500 or more records, all of which were due to the improper disposal of records by business associate, Central Files, Inc.

There were 3 data breaches reported in each of Michigan and Ohio, two breaches reported by healthcare providers in Pennsylvania, and one breach was reported in each of Alaska, Arizona, California, Connecticut, Florida, Georgia, Illinois, Maryland, Minnesota, Missouri, Nebraska, New York, and Texas.

HIPAA Enforcement Activity in May 2020

There were no announcements about HIPAA penalties from the HHS’ Office for Civil Rights or state attorneys general in May 2020.

The post May 2020 Healthcare Data Breach Report appeared first on HIPAA Journal.

Lack of Visibility and Poor Access Management are Major Contributors to Cloud Data Breaches

More companies are now completing their digital transformations and are taking advantage of the flexibility, scalability, and cost savings provided by public cloud environments, but securing public clouds can be a major challenge.

One of the main factors that has stopped companies from taking advantage of the public cloud has been security. Security teams often feel protecting an on-premise data center is much easier than protecting data in public clouds, although many are now being won over and understand that public clouds can be protected just as easily.

Public cloud providers now offer a range of security tools that can help companies secure their cloud environments. While these offerings can certainly make cloud security more straightforward, organizations must still ensure that their cloud services are configured correctly, identities and access rights are correctly managed, and they have full visibility into all of their cloud workloads.

Cloud security vendor Ermetic recently commissioned IDC to conduct a survey of CISOs to explore the challenges associated with cloud security and see how well organizations were faring at securing their public clouds. More than 300 CISOs and IT decision makers took part in the survey.

79% of respondents said they had experienced a cloud data breach in the past 18 months, and 43% of respondents said they had experienced 10 or more cloud data breaches during that time, strongly suggesting they are finding securing their public cloud environments something of a challenge.

When asked about the biggest security risks, 67% said they were concerned about security misconfigurations, 64% said a lack of visibility into access settings and activities was a key factor contributing to cloud data breaches, and 61% said access management and permission errors were a major breach risk.

The complexity of public cloud environments makes security challenging. The flexibility of the cloud means it is easy to quickly provision more resources on demand, but what often happens is cloud deployments become a maze of interconnected machines, users, applications, services, and containers. If organizations do not have complete visibility into their public cloud environments, it is difficult to ensure appropriate permissions are and the principle of least privilege is correctly applied.

Setting and managing access policies is a major challenge. Access policies need to be adjusted frequently, yet 80% of respondents said they could not effectively manage excessive data access for IaaS and PaaS. Excessive permissions are frequently abused by cybercriminals, who use them for a range of malicious activities such as data theft, data deletion, and delivering malware or ransomware.

“Some of the most high-profile cybersecurity incidents in recent years were the direct result of customers failing to properly configure their cloud environments, or granting excessive or inappropriate access permissions to cloud services, rather than a failure of the cloud provider in fulfilling its responsibilities,” explained Ermetic.

When asked about the main cloud security priorities, 78% of respondents said compliance monitoring, 75% said authorization and permission management, and 73% said security configuration management (73%). One of the biggest concerns was detection of excessive permissions, which was rated important or very important by 71% of respondents; however, only 20% of respondents said they were able to identify situations when employees had been given excessive permissions.

“An overworked security or IT admin may fail to identify and remove such permissions and create a significant vulnerability that may only be detected after the fact. Furthermore, early detection doesn’t necessarily guarantee prevention; more than 13% of respondents that detected excessive permissions reported that they were unable to mitigate the risks before data was exposed,” explained Ermetic in the report.

The survey confirmed that excessive permissions are a major problem in healthcare. 31.25% of healthcare organizations said they had identified a situation where employees had been given excessive permissions.

There have been many cases where security misconfigurations have lead to the exposure of sensitive data, with misconfigured Elasticsearch instances and AWS S3 buckets a common reason for data breaches, but it is also important to ensure that identities and permissions are properly managed.

Ensuring users, applications, and services can access only the cloud data and cloud resources that are necessary for their legitimate purposes was cited as the biggest cloud data protection challenge by respondents to the survey.

“Even though most of the companies surveyed are already using IAM, data loss prevention, data classification and privileged account management products, more than half claimed these were not adequate for protecting cloud environments,” said Ermetic CEO Shai Morag. “In fact, two thirds cited cloud native capabilities for authorization and permission management, and security configuration as either a high or an essential priority.”

The post Lack of Visibility and Poor Access Management are Major Contributors to Cloud Data Breaches appeared first on HIPAA Journal.

Advisories Issued About Vulnerabilities in Baxter, BD, and BIOTRONIK Medical Devices

The DHS Cybersecurity and Infrastructure Security Agency (CISA) has issued medical advisories about vulnerabilities in medical devices manufactured by Baxter, Becton, Dickinson and Company (BD), and BIOTRONIK.

The following products are affected:

  • Baxter PrismaFlex (all versions)
  • Baxter PrisMax (all versions prior to 3.x)
  • Baxter ExactaMix EM 2400 (Versions 1.10, 1.11, 1.13, 1.14)
  • Baxter ExactaMix EM 1200 (Versions 1.1, 1.2, 1.4, 1.5)
  • Baxter Phoenix Hemodialysis Delivery System (SW 3.36 and 3.40)
  • Baxter Sigma Spectrum Infusion Pumps (see below)
  • BIOTRONIK CardioMessenger II-S T-Line (T4APP 2.20)
  • BIOTRONIK CardioMessenger II-S GSM (T4APP 2.20)
  • BD Alaris PCU (Versions 9.13, 9.19, 9.33, and 12.1)

Baxter PrismaFlex and PrisMax

Three vulnerabilities have been identified in Baxter PrismaFlex and PrisMax systems that could allow an attacker to obtain sensitive data, although network access would first be required.

The vulnerabilities are:

  • CVE-2020-12036 – Cleartext transmission of sensitive information when the system is configured to send treatment data to a Patient Data Management System (PDMS) or EMR system. The vulnerability has been assigned a CVSS v3 base score of 6.5 out of 10.
  • CVE-2020-12035 – Vulnerable devices do not require authentication if configured to send treatment data to a PDMS or EMR system, which could allow an attacker to change treatment status information. The vulnerability has been assigned a CVSS v3 base score of 7.6 out of 10.
  • CVE-2020-12037 – The PrismaFlex device has a hard-coded service password which gives access to biomedical information, device settings, calibration settings, and the network configuration. The vulnerability has been assigned a CVSS v3 base score of 5.4 out of 10.

Users should update to PrismaFlex Versions SW 8.2 and PrisMaxv3 with DCM, limit physical access to devices and apply a defense-in-depth approach to security. It is also important to verify compatibility if the affected devices are used with PDMS or EMR systems.

Baxter ExactaMix

Seven vulnerabilities have been identified in ExactaMix EM2400 and EM1200 systems that could allow access to sensitive data, changes to system configuration, and alteration of system resources, which could impact system availability.

  • CVE-2020-12016 – Use of a hard-coded password could allow an unauthorized individual who has access to system resources to view PHI. The vulnerability has been assigned a CVSS v3 base score of 8.1 out of 10.
  • CVE-2020-12012 – Hard-coded administrative account credentials could allow an individual with physical access to the system to view and update system information, which could compromise system integrity and expose PHI. The vulnerability has been assigned a CVSS v3 base score of 6.8 out of 10.
  • CVE-2020-12008 – The use of cleartext messages to communicate order information with an order entry system could expose PHI. The vulnerability has been assigned a CVSS v3 base score of 7.5 out of 10.
  • CVE-2020-12032 – Device data with sensitive information is stored in an unencrypted database. An attacker with network access could view or change PHI. The vulnerability has been assigned a CVSS v3 base score of 8.1 out of 10.
  • CVE-2020-12024 – An unauthorized individual with physical access could use the USB interface to load and run unauthorized payloads, which could affect the confidentiality of data and integrity of the system. The vulnerability has been assigned a CVSS v3 base score of 6.8 out of 10.
  • CVE-2020-12020 – Non administrative users can gain access to the operating system and edit the application startup script. The vulnerability has been assigned a CVSS v3 base score of 6.1 out of 10.
  • CVE-2017-0143 – An SMBv1 input validation vulnerability could allow a remote attacker to gain unauthorized access to sensitive information, create denial of service conditions, or execute arbitrary code. The vulnerability has been assigned a CVSS v3 base score of 8.1 out of 10.

Users should contact their service support team to discuss upgrading to the ExactaMix Version 1.4 (EM1200) and ExactaMix Version 1.13 (EM2400) compounders.

Baxter Phoenix Hemodialysis Delivery System

Baxter has identified a vulnerability in its Phoenix Hemodialysis Delivery System which could allow an attacker with network access to steal sensitive data as a result of transmission of data in cleartext.

This is due to the system not supporting encryption of treatment and prescription data in transit (TLS/SSL) between the Phoenix system and the Exalis dialysis data management tool. The vulnerability is tracked as CVE-2020-12048 and has been assigned a CVSS v3 base score of 7.5 out of 10.

Baxter recommends employing cybersecurity defense-in-depth strategies such as network segmentation, and placing Phoenix machines and Exalis Server PCs on a dedicated subnetwork. If remote access is required, only allow connections using a VPN, admins should firewall each network segment, limit inbound and outbound connections, and scan for malware and unauthorized network access.

Baxter Sigma Spectrum Infusion Pumps

Baxter has identified six vulnerabilities in the following models of its Sigma Spectrum infusion systems:

  • Sigma Spectrum v6.x model 35700BAX
  • Baxter Spectrum v8.x model 35700BAX2
  • Sigma Spectrum v6.x with Wireless Battery Modules v9, v11, v13, v14, v15, v16, v20D29, v20D30, v20D31, and v22D24
  • Baxter Spectrum v8.x with Wireless Battery Modules v17, v20D29, v20D30, v20D31, and v22D24
  • Baxter Spectrum Wireless Battery Modules v17, v20D29, v20D30, v20D31, and v22D24
  • Baxter Spectrum LVP v8.x with Wireless Battery Modules v17, v20D29, v20D30, v20D31, and v22D24

An attacker exploiting the flaws could obtain sensitive data and change the system configuration, which could affect system availability.

  • CVE-2020-12045 is due to the Baxter Spectrum WBM operating a Telnet service on Port 1023 with hard-coded credentials, when used in conjunction with a Baxter Spectrum v8.x. The vulnerability has been assigned a CVSS v3 base score of 8.6 out of 10.
  • CVE-2020-12041 is due to the Baxter Spectrum WBM telnet Command-Line Interface granting access to sensitive data stored on the WBM that permits temporary configuration changes to network settings of the WBM and allow a WBM reboot. The reboot would remove temporary configuration changes to network settings. The vulnerability has been assigned a CVSS v3 base score of 8.6 out of 10.
  • CVE-2020-12047 is due to the use of hard-coded credentials. The Baxter Spectrum WBM (v17, v20D29, v20D30, v20D31, and v22D24), when used with a Baxter Spectrum v8.x (model 35700BAX2) in a factory-default wireless configuration, enables an FTP service with hard-coded credentials. The vulnerability has been assigned a CVSS v3 base score of 7.3 out of 10.
  • CVE-2020-12040 is due to the use of an unauthenticated clear-text communication channel to send and receive system status and operational data. The flaw could be exploited in an MitM attack and could result in circumvention of network security measures and access to sensitive data. The vulnerability has been assigned a CVSS v3 base score of 7.3 out of 10.
  • CVE-2020-12043 affects the Baxter Spectrum WBM and is due to the FTP service operating on the WBM remaining operational until the WBM is rebooted, when configured for wireless networking. The vulnerability has been assigned a CVSS v3 base score of 7.3 out of 10.
  • CVE-2020-12039 is due to the use of hard-coded passwords which could be entered on the keypad to access menus and change the device settings. Physical access would be required to exploit the flaw. The vulnerability has been assigned a CVSS v3 base score of 4.3 out of 10.

Mitigations include controlling physical access to vulnerable devices, operating the devices on a separate VLAN, segregating the system from other hospital systems, and using wireless network security protocols to provide authentication/encryption of wireless data sent to/from the Spectrum Infusion System. It is also recommended that admins should monitor for/block unexpected traffic at network boundaries into the Spectrum-specific VLAN.

BIOTRONIK CardioMessenger II

Five vulnerabilities have been identified in BIOTRONIK CardioMessenger II-S T-Line and II-S GSM (T4APP 2.20) cardiac activity monitors.

Exploitation of the flaws could lead to theft of sensitive data and could allow an attacker to influence communications between the Home Monitoring Unit (HMU) and the Access Point Name (APN) gateway network. In order to exploit the flaws an attacker would need adjacent access.

  • CVE-2019-18246 is due to improper authentication between the affected products and BIOTRONIK Remote Communication infrastructure. The vulnerability has been assigned a CVSS v3 base score of 4.3 out of 10
  • CVE-2019-18248 is due to the products transmitting credentials in plaintext before switching to an encrypted communication channel. The vulnerability has been assigned a CVSS v3 base score of 4.3 out of 10
  • CVE-2019-18252 is a further improper authentication issue, allowing credential reuse for multiple authentication purposes. The vulnerability has been assigned a CVSS v3 base score of 4.3 out of 10
  • CVE-2019-18254 is due to a lack of encryption for sensitive data at rest. The vulnerability has been assigned a CVSS v3 base score of 4.3 out of 10.
  • CVE-2019-18256 is due to the storage of passwords in a recoverable format. The passwords could be used for network authentication and decryption of local data in transit. The vulnerability has been assigned a CVSS v3 base score of 4.6 out of 10

BIOTRONIK has determined the vulnerabilities do not introduce new safety risks and, as such, the company will not be issuing a security update to correct the flaws. The following compensating controls will reduce the risk of exploitation.

These are:

  • Maintain good physical control over home monitoring units.
  • Use only home monitoring units obtained directly from a trusted healthcare provider or a BIOTRONIK representative to ensure integrity of the system.
  • Report any concerning behavior regarding these products to your healthcare provider or a BIOTRONIK representative.

BD Alaris PCUs

A vulnerability has been identified in certain BD Alaris PCUs that could potentially be exploited to trigger a denial of service condition that could affect the wireless functionality of vulnerable devices. The flaw is due to a hard-coded Linux kernel maximum segment size overflow.

The vulnerability only affects the versions 9.13, 9.19, 9.33, and 12.1 of the Alaris PC Unit that have implemented the Linux Kernel v4.4.97 within the Laird Wireless Module WB40N. The vulnerability is tracked as CVE-2019-11479 and has been assigned a CVSSv3 base score of 5.3 out of 10.

BD proactively identified the vulnerability and reported it to CISA. BD recommends using stronger network controls for wireless authentication such as WPA2 protocols, to monitor wireless networks with patient connected devices for possible malicious activity, to operate BD Alaris Systems Manger behind a firewall and to patch regularly, and to separate the BD Alaris PC Unit and BD Alaris Systems Manager with a firewall.

The post Advisories Issued About Vulnerabilities in Baxter, BD, and BIOTRONIK Medical Devices appeared first on HIPAA Journal.

CISA Warns of Ongoing Ransomware Campaign Exploiting Vulnerabilities in RDP and VPNs

The DHS Cybersecurity & Infrastructure Security Agency (CISA) has issued an alert about an ongoing Nefilim ransomware campaign, following the release of a security advisory by the New Zealand Computer Emergency Response Team (CERT NZ).

Nefilim ransomware is the successor of Nemty ransomware and was first discovered in February 2020. In contrast to Nemty, Nefilim ransomware is not distributed under the ransomware-as-a-service model. The developers of the ransomware conduct their own attacks and deploy the ransomware manually after gaining access to enterprise networks.

As with other manual ransomware groups, data is stolen from victims prior to deploying the ransomware. The group then threatens to publish or sell the stolen data if the ransom demand is not met. The group responsible for the attacks gains access to enterprise networks by exploiting vulnerabilities in remote desktop protocol (RDP) and virtual private networks (VPNs). The group uses brute force tactics to exploit weak authentication and the lack of multi-factor authentication, and also exploits unpatched vulnerabilities in VPN software.

Once a foothold has been gained in the network, the attackers use tools such as mimikatz, PsExec, and Cobalt Strike for privilege escalation, lateral movement, and to gain persistence and exfiltrate sensitive data.

The group is highly skilled, and their attacks are sophisticated and well crafted. The extent of network infiltration means it is not possible to recover from an attack simply by restoring data from backups. A comprehensive forensic investigation needs to be conducted to fully investigate the attack and ensure backdoors are identified and removed and the attackers are permanently ejected from the network.

All organizations that use remote access systems that have not been properly secured are at risk of an attack. To prevent an attack, it is essential for RDP vulnerabilities to be addressed and for remote access software to be kept fully patched and up to date. Strong authentication should be used and multi-factor authentication should be enabled.

Application whitelisting and network segmentation can reduce the severity of an attack, and it is important for networks and remote access systems to be monitored for signs of unauthorized access. Backups should be regularly performed, and one copy of a backup should be stored securely on an air-gapped device or media that cannot be accessed through the network.

The post CISA Warns of Ongoing Ransomware Campaign Exploiting Vulnerabilities in RDP and VPNs appeared first on HIPAA Journal.

Exploitable ‘Ripple20’ RCE TCP/IP Flaws Affect Hundreds of Millions of Connected Devices

19 zero-day vulnerabilities have been identified in the TCP/IP communication software library developed by Treck Inc. which impact hundreds of millions of connected devices across virtually all industry sectors, including healthcare.

Treck is a Cincinnatti, OH-based company that develops low-level network protocols for embedded devices. The company may not be widely known, but its software library has been used in internet-enabled devices for decades. The code is used in many low-power IoT devices and real-time operating systems due to its high performance and reliability and is used in industrial control systems, printers, medical infusion pumps and many more.

The vulnerabilities were identified by security researchers at the Israeli cybersecurity company JSOF, who named the vulnerabilities Ripple20 because of the supply chain ripple effect.

A vulnerability in small component can have wide reaching consequences and can affect a huge number of companies and products. In the case of Ripple20, companies affected include HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, B. Braun, and Baxter. JSOF has a list of 66 companies that are also potentially affected.

Four of the vulnerabilities are rated critical, with two (CVE-2020-11896 / CVE-020-11897) receiving the highest possible severity score of 10 out of 10 and the other critical bugs receiving scores of 9.0 (CVE-2020-11901) and 9.1 (CVE-2020-11898). The first three could allow remote code execution and the remaining vulnerability could result in the disclosure of sensitive information.

CVE-2020-11896 could be exploited by sending a malformed IPv4 packet to a device supporting IPv4 tunneling, and CVE-2020-11897 could be triggered by sending multiple malformed IPv6 packets to a device. Both allow stable remote code. CVE-2020-11901 can be triggered by answering a single DNS request made from a vulnerable device. This vulnerability could allow an attacker to take over a device through DNS cache poisoning and bypass all security measures.

The remaining 15 vulnerabilities range in severity from 3.1 to 8.2 and could result in information disclosure, allow a denial of service attack, and some could also potentially lead to remote code execution.

Exploitation of the vulnerabilities is possible from outside the network. An attacker could take full control of a vulnerable internet-facing device or even attack vulnerable networked devices that are not internet-enabled, if a network was infiltrated. An attacker could also broadcast an attack and take control of all vulnerable devices in the network simultaneously. These attacks require no user interaction and could be exploited in a way that bypasses NAT and firewalls. An attacker could take control of devices completely undetected and remain in control of those devices for years.

The vulnerabilities could be exploited by sending specially crafted packets that are very similar to valid packets, making it difficult to detect an attack in progress. JSOF reports that in some cases, completely valid packets could be used, which would make an attack almost impossible to detect.

“The risks inherent in this situation are high,” explained JSOF. “Just a few examples: Data could be stolen off of a printer, an infusion pump behavior changed, or industrial control devices could be made to malfunction. An attacker could hide malicious code within embedded devices for years.”

The video below shows an example of an exploit on a UPS to which several devices are connected, including a drug infusion pump.

Treck is currently reaching out to its clients to warn them about the vulnerabilities. The flaws have been patched in its TCP/IPv4/v6 software, so organizations impacted by the flaws should ensure Treck’s software stack version 6.0.1.67 or higher is used.

You can view the ICS-CERT advisory here

The post Exploitable ‘Ripple20’ RCE TCP/IP Flaws Affect Hundreds of Millions of Connected Devices appeared first on HIPAA Journal.

Misconfigured Public Cloud Databases are Found and Attacked Within Hours

Misconfigured public cloud databases are often discovered by security researchers. Misconfigurations that leave cloud data exposed could be due to a lack of understanding about cloud security or policies, poor oversight to identify errors, or negligent behavior by insiders to name but a few. A recent report from Trend Micro revealed cloud misconfigurations were the number one cause of cloud security issues.

Security researchers at Comparitech often discover unsecured cloud resources, commonly Elasticsearch instances and unsecured AWS S3 buckets. When the unsecured cloud databases are discovered, the owners are identified and notified to ensure data is secured quickly. Providing the owner can be identified, the databases are usually secured within a matter of hours, but there have been several cases where the database owner has been contacted but no response is received, and it is not always apparent to whom the data belongs.

In these cases, data can be left exposed online for several days or even weeks. During that time, the databases remain unprotected and can be accessed and downloaded by anyone that knows where to find them. Comparitech researchers are well practiced at finding unsecured Elasticsearch databases and AWS S3 buckets, but how quickly can malicious actors sniff out an unsecured database? Comparitech decided to find out. It turns out that it does not take long.

To determine the time it takes for unsecured data to be found, Comparitech’s security team conducted an exercise where they created a simulation of an Elasticsearch instance, similar to the many Elasticsearch instances they have found unsecured. They populated it with fake user data and left it exposed without any access controls. The database was exposed from May 11, 2020 to May 22, 2020.

In a recent blog post detailing the exercise, Comparitech security researcher Paul Bischoff explained that the first access request occurred 8 hours and 35 minutes after the database was created. During the 11 days that the database was exposed, there were 175 access requests. Their honeypot averaged 18 requests a day.

Exposed databases are usually located using an IoT search engine such as Shodan. It takes time for the data to be indexed by the search engines, in this case, Shodan indexed the database on May 16, five days after the database was created. Even though the database was not indexed until May 16, by the time it was there had been 3 dozen attempts to access the data. As soon as the database was indexed, the attacks spiked. Two access attempts were made within a minute of the database being indexed, with a further 20 access requests made that same day.

There are several reasons why attempts are made to find unsecured cloud resources. Databases often contain sensitive data, which can be used for identity theft and fraud or sold on underground forums. Databases can be hijacked and ransom demands issued to extort money from the data owners, but not all attacks were concerned with obtaining data. Several attempts were made to hijack the servers and download cryptomining scripts. In one case, an attacker attempted to switch off the firewall and delete the database.

While the test was concluded on May 22, 2020 and the data was mostly deleted, an further attack occurred on May 29. A malicious bot detected the honeypot and deleted the database, leaving a message demanding payment of 0.06 BTC to recover the data. That attack took 5 seconds from start to finish.

The exercise showed that even if databases are only exposed for a short period of time, it is highly likely that they will be found. While many companies say their data was not left unsecured for long when they are notified by Comparitech of an exposed cloud instance, it is probable that data has already been compromised unless data was only exposed for a few hours.

Comparitech pointed out that if the person setting up an Elasticsearch instance fails to put access controls in place, it is reasonable to assume that logging has also not been enabled. When companies report that no evidence was found to suggest data was accessed or exfiltrated, that does not mean data has not been accessed and stolen, only that there is a lack of evidence.   A 2019 report from McAfee suggested 99% of misconfigurations in the cloud go unreported when they are discovered. It is probable that data theft from cloud resources is far more likely than breach reports would lead you to believe.

The post Misconfigured Public Cloud Databases are Found and Attacked Within Hours appeared first on HIPAA Journal.

Attacks on Cloud Services Increased by 630% Between January and April

COVID-19 has forced businesses to close their offices and allow employees to work from home. Cloud services have been provisioned to support home working and communication solutions such as Zoom, Cisco WebEx, and Microsoft Teams have allowed remote workers in collaborate effectively.

A recently published report from cybersecurity company McAfee shows business use of cloud services increased by 50% in the first 4 months of 2020 and collaboration services saw an increase of 600% in usage during the same period. These solutions have allowed businesses to continue to operate, and many have reported productivity has actually improved during the pandemic; however, the rapid change to a largely at-home workforce has introduced vulnerabilities and cybercriminals have taken advantage.

Attacks on Cloud Services Have Surged During the Pandemic

An analysis of data from over 30 million McAfee cloud customers revealed cyberattacks on cloud services increased by 630% between January and April, 2020.

Threats to cloud services were split into two main categories: Excessive usage from an anomalous location and suspicious superhuman. The first involves logins from a location not previously detected. The threat actor then initiates high-volume data access and privileged access activity. Suspicious superhuman is the name given to a login attempt from one location followed by another from a geographically distant location, in a time frame shorter that the minimum time to travel from one location to the other.

McAfee’s analysis indicates the majority of attacks on cloud services are opportunistic rather than targeted and mostly consist of password spraying attacks, where stolen credentials are used to try to gain access to cloud resources.

Targeted attacks tend to be conducted by threat actors in China, Iran, and Russia. These hackers have extensive infrastructure and are well funded and can therefore conduct high volumes of attacks. The McAfee Cloud Adoption & Risk Report confirmed the healthcare industry has been heavily targeted during the pandemic and is the second most targeted vertical behind the financial services. 198 million IP addresses in Russia (111M), China (73M), and Iran (14M) were used in attacks on the healthcare industry during the first four months of 2020. The high number of attacks shows why it is important for healthcare providers to continuously monitor cloud activity and block attempts by malicious actors to gain access to their sensitive cloud data.

Working from home without direct supervision has not increased insider threats, according to McAfee. Insider threats have remained at the same level as before the pandemic. The rise in attacks on cloud services is mostly due to external actors.

Change in Business Operations Requires Changes to Security Solutions

The problem for many businesses is they have adopted cloud services to support remote working but are still using legacy security and networking solutions in a hub and spoke network. While these cloud services can be accessed directly, many organizations require employees to login to their network infrastructure to access those services, often through a VPN.

Unfortunately, while the VPN solutions that have been implemented prior to the pandemic were fine for small numbers of employees, they have struggled to cope with such a rapid increase in remote employees. Connection issues has meant many employees have experienced difficulties accessing data through VPNs. As a result, employees often take shortcuts and access cloud services such as Microsoft 365 directly. That means they bypass the security solutions in the organization’s data center, which increases risk.

“Securing a remote workforce shifts the major security focus control points to the device and cloud. A cloud-native approach to delivering security will provide the most complete coverage, capable of reaching devices off-network and connecting to cloud services directly,” explained McAfee.

McAfee recommends using a cloud-based secure web gateway to protect against web-based threat and permitting users to connect to sanctioned cloud services directly, rather than requiring the use of a VPN with data protected using a cloud access security broker (CASB). The CASB can be configured to perform device checks, implement data controls, and protect against attackers who can access SaaS accounts via the internet, including multi-factor authentication to reduce the risk of stolen credentials from being used to access cloud resources.

The post Attacks on Cloud Services Increased by 630% Between January and April appeared first on HIPAA Journal.

Proof of Concept Exploit Released for Critical SMBGhost Windows 10 SMBv3 Vulnerability

A functional proof of concept (PoC) exploit for a critical remote code execution vulnerability in the Microsoft Server Message Block 3.1.1 (SMBv3) protocol has been released and is being used by malicious cyber actors to attack vulnerable systems, according to an alert issued by the DHS Cybersecurity and Infrastructure Security Agency (CISA).

The vulnerability, referred to as SMBGhost, is due to the way the SMBv3 protocol handles certain requests. If exploited, a malicious cyber actor could remotely execute code on a vulnerable server or client by sending a specially crafted packet to a targeted SMBv3 server. An attack against a client would also be possible if an attacker configured a malicious SMBv3 server and convinced a user to connect to it.

The vulnerability could be exploited to spread malware from one vulnerable system to another in a similar fashion to the SMBv1 vulnerability that was exploited in the 2017 WannaCry ransomware attacks. No user interaction is required to exploit the flaw on vulnerable SMBv3 servers.

The flaw – tracked as CVE-2020-0796 – is present in Windows 10 versions 1909 and 1903 and was the subject of a Microsoft security advisory in early March. The flaw received a maximum CVSS v3 severity rating of 10 out of 10.

Microsoft released a patch to correct the flaw in early March; however, almost three months on and many organizations have yet to apply the patch and are vulnerable to attack. Microsoft also released details of a workaround to prevent exploitation, which involves disabling SMBv3 compression.

While the workaround would prevent the flaw from being exploited on a SMBv3 server, it would not prevent an attack on a client. The workaround involves running a simple PowerShell command. No reboot is required after the command has been executed. Details are available here. Scanners are available on GitHub that can be used to check for the CVE-2020-0796 vulnerability.

Security researchers developed exploits for the flaw with limited success, but the PoC exploit now available would allow an attacker to escalate local privileges and deliver malware. The PoC exploit is not 100% reliable, but more refined exploits are expected to be released. In its current form it could be used to successfully attack a vulnerable SMBv3 server. If the exploit were to fail, an attacker could simply keep on trying until it worked.

CISA strongly recommends that all organizations apply the patch to prevent exploitation. If the patch cannot be applied, the workaround should be used and SMB ports should be blocked from the internet using a firewall until the patch can be applied.

The post Proof of Concept Exploit Released for Critical SMBGhost Windows 10 SMBv3 Vulnerability appeared first on HIPAA Journal.

Voicemail Phishing Scam Identified Targeting Remote Healthcare Workers

The COVID-19 pandemic has forced many companies to change working practices and allow large numbers of employees to work remotely from home. In healthcare, employees have been allowed to work remotely and provide telehealth services to patients. While this move is important for virus control and to ensure patients still have access to the medical services they need, remote working introduces cybersecurity risks and cybercriminals are taking advantage. There has been a significant rise in cyberattacks targeting remote workers over the past three months.

A variety of tactics are being used to trick remote workers into installing malware or divulging credentials, including a new tactic that has recently been uncovered by cybersecurity firm IRONSCALES.

In a recent report, IRONSCALES revealed threat actors are spoofing messages automatically generated by Private Branch Exchange (PBX) systems to steal credentials. PBX is a legacy phone system used by many enterprises to automate the handling of calls. One of the features of these systems is the ability to record voicemail messages and send recordings directly to users’ inboxes. These systems have been hugely beneficial during the COVID-19 pandemic, as they ensure that employees never miss important voicemail messages while working remotely. They have also given cybercriminals another way of conducting an attack.

In this campaign, the attackers spoof messages from the PBX system and inform an employee that they have a new voicemail message. The emails are personalized and include the user’s name or company name to make it appear that the messages are genuine. Subject lines in the messages are also carefully crafted to spoof the messages sent by real PBX systems.

To hear the messages, users are directed to a website that spoofs PBX integrations with the aim of stealing credentails. “It may seem odd for attackers to create phishing websites spoofing PBX integrations as most voicemails are quite benign in the information shared. However, attackers know that the credentials could be used for multiple other logins, including for websites with valuable PII or business information,” explained IRONSCALES. “In addition, any sensitive information that is left in the voicemail could potentially be used for a social engineering attack.”

IRONSCALES detected this voice phishing (vishing) campaign in mid-May. According to the report, the campaign is being conducted globally and at least 100,000 mailboxes have been targeted.

“If your organization automatically sends voicemails to workers inboxes, then your company is at risk of falling victim to this scam. As we know, if an email looks real then someone will fall for it,” explained IRONSCALES.

IRONSCALES suggests raising awareness of this scam with remote workers and implementing an email security system capable of detecting and blocking email security threats such as this, which have so far been effective at bypassing DMARC anti-spoofing measures.

The post Voicemail Phishing Scam Identified Targeting Remote Healthcare Workers appeared first on HIPAA Journal.