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

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.

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.