STE WILLIAMS

The US Cybersecurity and Infrastructure Agency (CISA) today issued an advisory for six high-severity security vulnerabilities in patient monitoring devices manufactured by GE Healthcare.

These flaws, collectively dubbed “MDhex,” could allow an attacker to make changes at the software level of a device and in doing so interfere with its functionality, render it unusable, change alarm settings, or expose personal health information (PHI). Their discovery began with CyberMDX security researchers investigating the CIC Pro, a common product among customers.

The CIC Pro is a workstation that hospital staff use to view their patients’ physiological data, waveforms, and demographics. Data is transmitted from multiple patient-side monitors and collected through a shared network. CIC Pro may be used to centrally manage patient monitors for things such as admission, date and time synchronization, and setting alarm limits.

Researchers started the investigation when they noticed CIC Pro devices in the field had open ports running an outdated and potentially problematic version of Webmin. “It was allowing incoming traffic on a range of management ports,” says head of research Elad Luz. “With that [discovery], we thought we’d do an in-depth examination of that product ourselves.”

Their analysis led to a total of six severe vulnerabilities, as listed in CISA’s advisory. Five were assigned a CVSS maximum severity score of 10: CVE-2020-6961, CVE-2020-6963, CVE-2020-6964, CVE-2020-6966, and CVE-2020-6962. The sixth, CVE-2020-6965, was given a high-severity score of 8.5. MDhex was reported to GE on September 18, 2019, and is being formally disclosed today after a period of collaboration among GE, CISA, and CyberMDX to confirm and evaluate the vulnerabilities.

The popular Carescape product line, launched in 2007, has been adopted by hospitals around the world. Products affected by these vulnerabilities include certain versions of the Carescape CIC, Apex Telemetry Server/Tower, Central Station (CSCS) Telemetry Server, B450 patient monitor, B650 patient monitor, and B850 patient monitor. GE did not disclose the number of affected devices; however, CyberMDX believes the installed base is in the hundreds of thousands.

Inside a hospital, these devices are deployed on a network they share with other monitoring equipment, which also consists of vulnerable devices. If a hospital has one of these affected products, they likely have the others, Luz points out.

Each flaw exists in a different aspect of device design and configuration. CVE-2020-6961 is an SSH vulnerability. An SSH server configuration typically holds a file holding public keys of entities authorized to connect. In vulnerable devices, the configuration also has a private key — which is the same across the entire medical product line.

“The same private key is universally shared across an entire line of devices in the CARESCAPE and GE Healthcare family of products,” researchers write in a blog post. “Using the private key, an attacker could remotely access and execute code on these devices — potentially comprising the device’s very availability as well as the confidentiality and integrity of any data it holds.”

The issue of hard-coded credentials also exists in Microsoft Server Message Block vulnerability CVE-2020-6963. Credentials underlying this flaw can be accessed by doing password recovery on the Window XP operating system of affected devices. With these credentials, an attacker could break into other devices. CVE-2020-6964 exists in MultiMouse/Kavoon KM software, which enables remote keyboard, mouse, and clipboard control of a device. The bug could let an attacker abuse this functionality and take over devices without any credential controls to alter device settings and change data.

VNC vulnerability CVE-2020-6966 enables remote control in VNC, a software used for remote desktop access. Credentials for this are insecurely stored and can be found in publicly available and easily searchable product documentation. CVE-2020-6962 pertains to the deprecated version of Webmin (1.2.5) in affected devices, which are exposed to known exploits in the wild.

These vulnerabilities generated the highest scores because they easily allow hackers to do remote code execution, which Luz considers “the endgame” for the majority of cyberattacks.

“Once you gain that remote code execution, you can [alter] the device functionality, perhaps make it unusable, perhaps make it display false data, things like that,” he explains. While it’s not clear why an attacker might target a specific medical device, the level of access granted by these vulnerabilities could enable a large-scale ransomware attack on a healthcare target.

GE plans to provide patches and additional security information for affected users over the coming months. Users can check its website for more updates or contact the company directly. In the meantime, mitigations are offered in the CyberMDX blog post.

Related Content:

• To Avoid Disruption, Ransomware Victims Continue to Pay Up
• Eight Flaws in MSP Software Highlight Potential Ransomware Vector
• 7 Ways to Get the Most Out of a Penetration Test
• Assessing Cybersecurity Risk in Today’s Enterprise

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/severe-vulnerabilities-discovered-in-ge-medical-devices/d/d-id/1336867?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

“Web cache” refers to any technology that fronts an origin web server and temporarily stores frequently accessed content so that subsequent requests for the same content can be served efficiently. Be they centralized caching proxies deployed on-premises at an enterprise or content delivery networks (CDNs) with massively distributed caching edge servers, caches have become critical Internet infrastructure that enable scalable traffic delivery.

Attacks targeting caches are nothing new. However, it wasn’t until 2017 that web cache attacks saw a significant surge in popularity, with novel exploits regularly making the headlines. Works such as “Web Cache Deception Attack,” “Practical Cache Poisoning,” and “CPDoS: Cache Poisoned Denial of Service” demonstrate disastrous vulnerabilities that are easy for miscreants to exploit.

In our own research with academics from the University of Trento and Northeastern University, we homed in on the aforementioned web cache deception attack, or WCD for short. WCD is a particularly damaging threat, where the adversary tricks a cache into storing the victim’s sensitive data, therefore leaking it on the Internet. We analyzed 340 popular websites and found that 37 were affected by WCD, also finding that simple tweaks to existing attack techniques are sufficient to discover new exploitable targets. (We will present this work, titled “Cached and Confused: Web Cache Deception in the Wild,” at Usenix Security Symposium in August 2020.)

Is WCD a genuine security concern? Absolutely. That point was already made repeatedly over the past years. In this column, I will focus on a largely overlooked question: Given the severity of the issue, why aren’t we seeing researchers scrambling to propose defenses? Why aren’t security vendors flooding the market with solutions?

Unfortunately, this is a direct consequence of the fact that web caches are easy to exploit but disproportionately difficult to secure. Let’s dig deeper into how the attack works to understand why.

WCD stems from a discrepancy between how a cache and an origin server interpret a given HTTP request. For instance, an attacker can craft a URL that points to the account information on a banking website but append to it a nonexistent path component disguised as a static image, such as “/account.php/nonexistent.jpg.” Many origin servers will simply ignore the invalid suffix and respond with account details. However, a web cache proxying the content will be oblivious to the processing that happens on the origin server, and it will store the response as if it were an image. If the attacker can trick a user into clicking on this link, the victim’s account information will be cached, giving the attacker an opportunity to steal it.

The key observation here is that neither the origin server nor the web cache is individually at fault. In fact, when we examine them in isolation, they are both perfectly secure, performing their intended functions. Instead, the vulnerability results from different interpretations of the same request by two technologies that process the traffic, leading to a disagreement on the “cacheability” of the response. Perhaps a safety model — as opposed to a more traditional security model — is more appropriate when analyzing WCD: Faulty components don’t lead to a vulnerability; instead, hazardous interactions between components lead to an accident.

Dire Implications
This has dire implications for security professionals. Fixing a WCD vulnerability is very different from applying a patch to a broken software; it requires site operators to adopt a holistic view of their web infrastructure. Operators need to identify all technologies that may influence the Internet traffic traversing their environment, understand how they individually work, and how they influence each other, just to pinpoint a vulnerability. The fix may then require intrusive architectural changes.

This is already nontrivial for a small web deployment but large enterprises often span global infrastructures, utilize a patchwork of centralized caches, and chain together multiple CDN providers. The task quickly becomes intractable.

Attackers, on the other hand, do not need to concern themselves with this complexity. They do not need to understand why a vulnerability exists but merely test their exploits treating their target as a black box. Sweeping through a large array of sites looking for vulnerabilities is straightforward, whereas fixing a single vulnerability requires considerable effort.

Fundamental Challenges
With the flood of new attack variants, exciting offensive research opportunities, and the media’s focus on exploited sites, it’s easy to overlook the fundamental challenges for an effective WCD defense. Cache attacks will likely get worse before they get better, and we don’t yet have a good solution. Automatic discovery of hazardous interactions in a web architecture is an open research problem.

In the meantime, falling back on asset management best practices is a good bet. A well-maintained system register that describes entities and the relationships between them goes a long way in helping site operators track down potential WCD vulnerabilities. Perhaps most important, though, is realizing that a systems safety problem like WCD can’t possibly be addressed by system owners, cache vendors, or CDN providers on their own. Systems-centric security and safety analyses of Internet-wide infrastructures require the collaboration of all parties involved.

Related Content:

• A Murderers’ Row of Poisoning Attacks
• 13 Security Pros Share Their Most Valuable Experiences
• Transforming ‘Tangible Security’ into a Competitive Advantage
• 2019 Online Malware and Threats: A Profile of Today’s Security Posture

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Kaan Onarlioglu is a researcher and engineer at Akamai who is interested in a wide array of systems security problems, with an emphasis on designing practical technologies with real-life impact. He works to make computers and the Internet secure — but occasionally … View Full Bio

Article source: https://www.darkreading.com/deconstructing-web-cache-deception-attacks-theyre-bad-now-what/a/d-id/1336845?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The National Security Agency (NSA) today published a new document outlining common types of cloud vulnerabilities and offering different ways for companies to protect cloud environments.

“Mitigating Cloud Vulnerabilities” addresses how cloud adoption can improve security posture but introduce risks that organizations should understand. It addresses four types of cloud architectural services – identity and access management, compute, networking, and storage – and explains the importance of shared responsibility with cloud service providers. For example, this model affects tasks like patching but varies by CSP, cloud service, and product offering.

It also digs into different types of cloud threat actors, which may include malicious admins who use their privileged credentials to access sensitive data. These may come from the CSP or the customer, NSA notes. Other cloud-focused attacks may come from cybercriminals, nation-state attackers, or untrained or neglectful customer cloud administrators, officials state.

The document breaks cloud vulnerabilities into four classes. Misconfigurations, considered to be the lowest in sophistication, often arise from CSP policy mistakes or misunderstanding the shared responsibility model. It’s the most widespread of the four and could expose an organization to a range of threats including denial of service and account compromise.

Poor access control is another widespread threat of moderate sophistication. This occurs when cloud resources use weak authorization methods or have vulnerabilities that would let an attacker bypass authentication. An attacker could elevate privileges and compromise resources.

Shared tenancy vulnerabilities are considered rare and of high sophistication. Hypervisor flaws are difficult and expensive to find and exploit; CSPs continuously scan hypervisor code for bugs. Containers run on a shared kernel, and a vulnerability in the container platform could let an attacker target containers run by other tenants on the same host.

Supply chain flaws, the fourth type of cloud vulnerability, are also considered to be rare and advanced. These vulnerabilities include the presence of inside attackers, as well as intentional backdoors built into hardware and software. Bringing someone into the supply chain could give attackers an easy route into a target organization.

Read more details and mitigations in the full document here.

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/cloud/nsa-offers-guidance-on-mitigating-cloud-flaws/d/d-id/1336871?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The Department of Homeland Security’s CISA (Cybersecurity and Infrastructure Security Agency) has issued a warning of increased activity around highly targeted Emotet attacks. Emotet’s main threat is that it can act as a carrier (or “dropper”) for a wide variety of different malware payloads.

Emotet is classified as a banking Trojan that spreads primarily through email attachments. It is known for its ability to quickly and widely spread through an organization once an initial infection occurs. According to the DHS, Emotet is “…among the most costly and destructive malware affecting state, local, tribal, and territorial (SLTT) governments, and the private and public sectors.”

For more, read here and here.

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/dhs-warns-of-increasing-emotet-risk/d/d-id/1336873?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Mac users generally tend to be better protected against malware and other online threats than Windows users. That doesn’t mean they are immune, however.

Shlayer, a malware tool for distributing unwanted advertisements on MacOS systems, is a case in point. Since first surfacing in February 2018, the malware has emerged as the most widely distributed threat on the MacOS platform. Among those most impacted by the malware are MacOS users in the US, Germany, France, and the UK.

Kaspersky, which has been tracking Shlayer for some time, this week described it as currently infecting at least one in 10 Mac users. Though the malware has little to separate it from other malicious software from a purely technical standpoint, it continues to remain as active as when it first surfaced.

According to Kaspersky, in 2019 Shlayer-related attacks accounted for nearly 30% of all attacks on MacOS devices protected by the company’s products. Worse, almost all of the other remaining top 10 MacOS threats were adware products distributed by Shlayer. Among them were AdWare.OSX.Bnodlero, AdWare.OSX.Geonei, AdWare.OSX.Pirrit, and AdWare.OSX.Cimpli, the security vendor noted.

One reason for Shlayer’s continuing prevalence is the manner in which it is being distributed. Currently, over 1,000 “partner” websites distribute Shlayer on behalf of the malware’s authors. Unsuspecting users who arrive on these sites — many of which hawk pirated content — are typically redirected to fake Flash Player update pages from where the malware gets downloaded on MacOS systems. The partner sites get paid for each download.

“The affiliate network is an intermediate link between the creators of the Trojan and those who are willing to distribute it for a fee,” says Vladimir Kuskov, head of advanced threat research and software classification at Kaspersky. “The role of partner sites is to attract users to their resource and instill the need to download and run a malicious file.” 

Shlayer is being distributed in a variety of other ways, including malicious links to fake Adobe Flash update sites embedded in article references on Wikipedia and video descriptions on YouTube. Kasperksy researchers have so far found links to at least 700 malicious domains for downloading Shlayer hidden in a variety of legitimate sites.

Users looking for pirated content are more likely to get infected, Kuskov says. At the same time, even those clicking on links below a YouTube video or while searching for something on Wikipedia are at risk, he notes.

Annoying but Less Harmful
Shlayer is distributed under the guise of a Flash Player installer and, at first sight, looks pretty legitimate. Like other installers, the malware installs software, except that in this case it installs adware instead of legitimate software.

One alleviating fact is that Shlayer does not load on its own. Users have to actively click and download the installer for it to load on a system. But those distributing the malware have employed a variety of social engineering tricks to redirect users to fake Flash Player update sites to get users to download the malware, Kuskov notes.

Shlayer itself is also not persistent on an infected system. A user who discovers the malware can simply delete the installation file to get rid of it, he says.

The real problem is the adware it installs. “It’s important to understand that Shlayer itself performs only the initial stage of the attack — it penetrates the system, loads the main payload, and runs it,” Kuskov says. The installed adware is not easy for the average user to remove. It can be especially challenging because of the multiple adware family Shlayer can install on a single system.

Also, some adware like AdWare.OSX.Cimpli can intercept a user’s HTTP and HTTPS traffic and inject code into the Web pages requested by the user. “In theory, that means that Cimpli can steal any data entered by the user on the Web page,” Koskov said.

Even so, Shlayer is relatively innocuous compared to other more destructive malware. It is also an example of how attackers are constantly looking for ways to earn money by attacking MacOS systems.

The threat landscape for Apple devices is changing, and the amount of malicious and unwanted software is growing, Kaspersky said. Since at least 2012, the volume of malicious and potentially unwanted files targeted at MacOS has been doubling each year. 

“But instead of full-fledged malware, MacOS users increasingly receive annoying, but less harmful, adware,” Kuskov says. “It seems that this way of monetizing an infection allows attackers to make more profit and save on expenses.”

Related Content:

• Malware Coming to a Mac Near You? Yes, Say Security Firms
• New MacOS Malware Discovered
• Researchers Explore Remote Code Injection in MacOS
• 7 Ways to Get the Most Out of a Penetration Test

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/the-annoying-macos-threat-that-wont-go-away/d/d-id/1336875?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

S4x20 CONFERECE – Miami – More signs that the industrial control system (ICS) sector has become one of the latest favorite targets of ransomware attacks: The head of an operational technology (OT) cybersecurity services firm says at least five organizations in the oil and gas industry were recently hit by Ryuk.

Clint Bodungen, founder and CEO of ThreatGen, which conducts incident response and other security services, says he believes the ransomware attack revealed late last month by the US Coast Guard in a Marine Safety Information Bulletin may have been part of a more widespread Ryuk ransomware attack campaign that included two of his firm’s oil and gas organization clients as victims.

The Coast Guard in its Dec. 16, 2019, alert warned of a Ryuk ransomware attack at a Maritime Transportation Security Act (MTSA)-regulated facility that began with a user opening a malicious link in a phishing email, leading to Ryuk locking the victim out of “critical” files in the IT network. Ryuk also spread to systems that monitor and control the transfer of cargo, ultimately knocking the facility’s “primary operations” for 30 hours during the incident response.

“The impacts to the facility included a disruption of the entire corporate IT network (beyond the footprint of the facility), disruption of camera and physical access control systems, and loss of critical process control monitoring systems,” the Coast Guard said in the alert. 

The Coast Guard alert caught Bodungen’s attention. “I don’t know if the … Coast Guard is talking directly about one of my customers, but the data was relative enough and close enough that even one of my customers thought, ‘Are they talking about us?'” says Bodungen, who is scheduled to give a presentation here today about the ransomware incidents.

Either way, he says, the tactics, techniques, and procedures (TTPs) used against all five oil and gas victims were similar, indicating that the Ryuk attackers were specifically targeting the sector – possibly in a coordinated campaign. In addition to his two oil and gas customers, he points to the attack on Mexico’s Pemex in November as well two additional oil and gas firms he is aware of.

“This feels like one campaign because the TTPs are that similar,” he says. The Coast Guard and ICS-CERT were contacted by at least one of his customers in the wake of their ransomware attack.

Ryuk, a ransomware variant created by a Russian cybercrime group known as Wizard Spider, is well-known for targeting large companies and organizations with the aim of scoring more lucrative ransom payments. As of the third quarter of 2019, the average initial ransom demand from Ryuk attacks was $377,000, according to data from Coveware. 

The malware was behind several local government attacks, including one against Riviera Beach, Fla., in which the city paid out $600,000 in ransom, and another against Lake City, Fla., which coughed up $460,000 in ransom. New Orleans reportedly also was hit with Ryuk in its recent ransomware attack.

Bodungen says neither of his firm’s oil and gas sector clients paid the ransom demands. He would not disclose the actual ransom amount out of concern that it could be used to identify those customers, who he had promised not to name publicly. He plans to share here today the TTPs gathered from the IR engagements with his clients.

Efforts to reach the US Coast Guard were unsuccessful as of this posting.

The Attacks
The attackers apparently had sat dormant in both of ThreatGen’s oil and gas customer networks for several months before launching the ransomware attack itself. The initial infiltration began with a spear-phishing email in one case and a water-holing attack in another, which planted the infamous Trickbot backdoor, Bodungen says. Trickbot is typically used by attackers to move quietly through the victim network to identify the location of potentially sensitive data they can lock down in the ransomware stage of the attack.

The attackers hacked into the victims’ Active Directory servers via the Remote Desktop Protocol (RDP). “They actually weaponized AD by putting not Trickbot, but Ryuk, into the AD [roaming] login script. So anybody who logged into that AD server was immediately infected,” namely Windows-based servers and endpoints, Bodungen says.  

So as soon as an engineer, for example, logged in from his or her workstation, the payload would drop, execute, and lock the user out of the machine.

While the Coast Guard alert said industrial systems were hit by Ryuk in the victim’s network, Bodungen says, that was not the case with the oil and gas firms his company investigated.

“Some engineering workstations and [HMI and other] terminals got infected, so as soon as that started to happen, they did a manual switchover [with the industrial systems],” he says. “The industrial processes were not shut down by Ryuk … it disables your ability to monitor, view, and control,” so the plants went into manual mode.

Ryuk did not directly infect his oil and gas client’s physical security cameras or physical access control as the Coast Guard alert appears to indicate, he says. Instead, the network links to those systems were temporarily disrupted during ThreatGen’s IR investigation, when the plant was “isolated” to thwart further spread of the attack, according to Bodungen. In all, the two oil and gas organizations were down anywhere from 24 to 72 hours during the IR engagements.

Meanwhile, Trend Micro late last month warned that the oil and gas industry was increasingly at risk of ransomware attacks. The security firm referenced the case of a US oil and natural gas firm that was hit with a very targeted ransomware attack in which just three computers were affected, as well as its cloud backups. The infected machines hosted “essential” company data and cost the company some $30 million in losses.

“While we do not have additional details on this case, we believe the attackers did plan this attack carefully and were able to target a few strategic computers rather than hitting the company with a massive infection,” the company said in an oil and gas threat report it issued.

Bad News Backups
For one of ThreatGen’s Ryuk victim clients, restoring from its backup systems backfired. “When they restored from backup, they restored to a compromised state” because the attackers had been in the network for months, Bodungen explains.

It’s unclear just what the motivation was for the quiet phase of the infection by the attackers. Sometimes this approach is about reconnaissance and timing for triggering the ransomware payload. There’s another possible angle, too: A nation-state, for example, could employ this strategy for cover if they were to get discovered in the network.

“If I just have a foothold for future use and I get caught, I could immediately deploy ransomware like Ryuk as a diversionary [tactic],” he says. “So hopefully they then restore back to the compromised state and [the attacker] lays low for a while.”

The bottom line is you can’t trust your backups if they’re conducted while you’re infected, so in those cases the next step is to replace the hard drives, Bodungen says.

Eddie Habibi, founder and CEO of ICS security firm PAS Global, recommends that OT and other organizations maintain “clean” copies of their systems. “Make sure you have the ability to tell the ransomware guys to knock it off,” he says. “Be prepared to shut down systems and start over from scratch.”  

Habibi expects ransomware attacks to increase against industrial firms, with potentially dangerous consequences. Holding a chemical plant’s systems for ransom could be more lucrative for attackers because that would be “more severe than shutting down a business [network],” he notes.

Related Content:

• Ransomware Situation Goes From Bad to Worse
• New Orleans to Boost Cyber Insurance to $10M Post-Ransomware
• Targeted Ransomware Attacks Show No Signs of Abating
• 8 Head-Turning Ransomware Attacks to Hit City Governments

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem.”

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/ryuk-ransomware-hit-multiple-oil-and-gas-facilities-ics-security-expert-says-/d/d-id/1336865?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple