Attacks increased by "only" 19% last year. But that number is expected to grow significently.

Andrew Ginter, Vice President of Industrial Security, Waterfall Security Solutions

April 24, 2024

4 Min Read

Source: Nicholas Klein via Alamy Stock Photo

COMMENTARY

Waterfall Security Solutions, in collaboration with ICS Strive, recently released its "2024 Threat Report." The bad news is that, in 2023, there were 68 cyberattacks that took down more than 500 physical operations. The good news (sort of) is that this is only 19% more attacks than the previous year. What's going on? Ransomware attacks with physical consequences are down slightly, hacktivist attacks are constant, and everything else is increasing. The report's authors conclude that the 19% increase is most likely an aberration, and that we'll see an increase closer to 90% to 100% in 2024.

**The Details**

Waterfall's operational technology (OT) security threat report is the most cautious in the industry — it tracks only deliberate cyberattacks that caused physical consequences in building automation, heavy industry, manufacturing, and critical industrial infrastructures in the public record. That is, no private or confidential disclosures. The complete data set for the report is included in its appendix. This means the report is certain to be an underestimate of what's really happening in the world, because the authors report regular confidential disclosures that they cannot include in their counts.

OT incidents since 2010. Source: "2024 Threat Report," Waterfall Security Solutions, in collaboration with ICS Strive

**More Attacks**

In spite of this underestimate, cyberattacks that met the inclusion criteria continue to increase, nearly doubling annually since 2019. This is a big change from 2010–2019, when OT attacks with physical consequences were flat, bouncing around between zero and five attacks annually.

Threat actors. Source: "2024 Threat Report," Waterfall Security Solutions, in collaboration with ICS Strive

What are these attacks? In 24 of 68 cases, there was not enough information in the public record to attribute the attack. Of the remaining, 35 attacks (80%) were ransomware, six (14%) were hacktivists, two were supply chain attacks, and one was attributed to a nation state. The 35 ransomware attacks are down slightly from last year's 41, which is unexpected, given that ransomware attacks on IT networks continue to increase at between 60% to 70% per year, depending on the report. Why? In part, because public reports this year were less detailed, there were many more "unknown" threat actors this year. 

Another factor has to do with the fact that most ransomware attacks that impact physical operations did so only accidentally — either because of "abundance of caution" OT shutdowns, when IT is impaired, or physical operations being dependent on crippled IT infrastructure. In 2023, we saw a material fraction of ransomware criminal groups shift away from encrypting and disabling systems to simply stealing the data and demanding ransoms to destroy the stolen data rather than publish it. With fewer IT systems being crippled through encryption, it looks like fewer OT systems and physical operations are being impaired.

We expect this trend to stabilize in 2024, and for OT impacts due to ransomware to go back to the recently historic norm of nearly doubling annually. Why? Because not all businesses have data they are willing to pay to protect. Such businesses, especially critical infrastructures, may still, however, pay a ransom to restore functionality to crippled systems, so it makes sense that at least some ransomware criminals will not leave money on the table and will continue to cripple servers, in addition to stealing what data they can.

**Supply Chain**

Supply chain attacks with physical consequences showed up this year for the first time in many years. Newag SA was accused of embedding code in its trains to maximize the revenues of authorized repair shops. It is accused of acting to "lock up the train with bogus error codes after some date, or if the train wasn't running for a period of time." Some of the code was found to contain GPS coordinates to confine the behavior to third-party workshops. Newag denies the accusations, blaming "unknown hackers." And in an apparent contractual dispute, ORQA, a manufacturer of first-person view (FPV) virtual reality headsets, had its products locked up by what it describes as a "greedy former contractor."

**Wrapping Up**

There are many other findings in the report: GPS blocking and spoofing is becoming a widespread problem, manufacturing businesses accounted for more than one half of the attacks with outages, hacktivists are targeting critical infrastructures, and there is an alarming batch of near misses, including the many critical infrastructures and utilities  targeted by China's Volt Typhoon "living off the land" campaign. The report also touches on promising new developments on the defensive side, including the Cyber-Informed Engineering Strategy. 

**About the Author(s)**

Vice President of Industrial Security, Waterfall Security Solutions

At Waterfall, Andrew leads a team of experts who work with the world's most secure industrial enterprises. Before Waterfall, he led the development of high-end industrial control system products at Hewlett-Packard, of IT/OT middleware products at Agilent Technologies, and of the world's first industrial SIEM at Industrial Defender. He is the author of two books on industrial / OT cybersecurity, a co-author of the Industrial Internet Security Framework, and a co-author of the UITP report on cybersecurity requirements in rail system tendering. Andrew co-hosts the Industrial Security Podcast and contributes regularly to industrial security standards and best-practice guidance.

2023: A 'Good' Year for OT Cyberattacks

An exploit for the vulnerability allows unauthenticated attackers to escape a virtual file system sandbox to download system files and potentially achieve RCE.

Source: Andre Boukreev via Shutterstock

Virtual file transfer system provider CrushFTP and various security researchers are sounding the alarm about a sandbox escape flaw in the CrushFTP server that attackers already have exploited as a zero-day in attacks against organizations in the US.

CrushFTP is a multiprotocol, multiplatform, cloud-based file transfer server. The security vulnerability, tracked as CVE-2024-4040, is an improper input validation bug in the CrushFTP file transfer server version 11.1. The company unveiled and patched the flaw on April 19 with the release of version 11.1.0 of the product; however, there already were various reports of threat actors hammering the flaw with an existing exploit.

These attacks, which were potentially "politically motivated," were targeted in nature for intelligence gathering and detected at various US entities, according to Crowdstrike's threat hunters Falcon OverWatch and Falcon Intelligence, which published an advisory on Reddit.

**A Developing Attack Scenario for Cloud File Transfer**

The attack scenario is developing, with new research by Tenable published April 23 identifying more than 7,100 CrushFTP servers publicly accessible "based on a Shodan query in a Nuclei template created by h4sh," according to the report. However, "it's unclear how many of these systems are potentially vulnerable," Satnam Narang, a Tenable senior staff research engineer, noted in the post.

Attacks are likely to continue on unpatched servers given that a proof-of-concept (PoC) exploit for the flaw is now publicly available, posted April 23 to GitHub by the researcher who discovered and reported the flaw to CrushFTP, Simon Garrelou of Airbus Community Emergency Response Team (CERT), Narang added.

Other attackers also aim to benefit from all the attention in the flaw, by targeting users with fake PoCs, Narang wrote, noting there already is a repository posted to GitHub that directs users to a third-party site called SatoshiDisk, which requests a payment of 0.00735 bitcoin (around $513) for an alleged exploit.

"It is unlikely that the exploit code will work and we do not expect it to be malicious in nature," Narang wrote. "Instead, it is more likely that the attackers are seeking to make money from the interest in the exploit code for this vulnerability."

**CVE-2024-4040: Potential for RCE**

The vulnerability as described by the vendor is an arbitrary read flaw that allows an attacker with low privileges to escape the server's virtual file system (VFS) sandbox to access and download system files.

However, there is evidence that it is more to the flaw than has so far been reported, Rapid7 researchers noted in a blog post published on April 23.

"Although the vulnerability has been formally described as an arbitrary file read, Rapid7 believes that it can be more accurately categorized as a server-side template injection (SSTI)," Caitlin Condon, Rapid7's director of vulnerability intelligence, wrote in the post.

CVE-2024-4040 is a "fully unauthenticated flaw" and is easy to exploit; successful exploitation allows not only or arbitrary file read as root, but also authentication bypass for administrator account access and full remote code execution (RCE), she observed.

"Successful exploitation allows a remote, unauthenticated attacker to access and potentially exfiltrate all files stored on the CrushFTP instance," Condon wrote.

**Exploit Code Available**

The PoC exploit posted by Garrelou includes two scripts. The first, scan\_host.py, attempts to use the vulnerability to read files outside the sandbox, according to the GitHub post.

"If it succeeds, the script writes Vulnerable to standard output and returns with exit code 1," according to Garrelou. "If exploiting the vulnerability does not succeed, the script writes Not vulnerable and exits with status code 0."

The second script, scan\_logs.py, looks for indicators of compromise in a CrushFTP server installation directory and, upon finding them, will attempt to extract the IP that tried to exploit the server.

**Patch Now for Full Protection**

The best way for organizations with CrushFTP present in their environment to mitigate the situation is to update their systems to the patched version of the product now, the company and security researchers alike advised.

Customers using a front-end demilitarized zone (DMZ) server to process protocols and connections in front of their main CrushFTP instance are afforded partial protection from exploit due to the protocol translation system used in the DMZ, according to CrushFTP.

"A DMZ, however, does not fully protect you, and you must update immediately," the company advised customers in its advisory. One of the factors complicating an organization's detection of exploitation of CVE-2024-4040 is that payloads "can be delivered in many different forms," Rapid7's Condon noted.

"When certain evasive techniques are leveraged, payloads will be redacted from logs and request history, and malicious requests will be difficult to discern from legitimate traffic," she wrote.

For this reason, Rapid7 recommends that CrushFTP customers harden their servers against administrator-level RCE attacks by enabling Limited Server mode with the most restrictive configuration possible. Condon added that they also should use firewalls wherever possible to aggressively restrict which IP addresses are permitted to access CrushFTP services.

**About the Author(s)**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Patch Now: CrushFTP Zero-Day Cloud Exploit Targets US Orgs

Just like you should check the quality of the ingredients before you make a meal, it's critical to ensure the integrity of AI training data.

Source: Nico El Nino via Shutterstock

COMMENTARY

Picture this: It's a Saturday morning, and you made breakfast for your family. The pancakes were golden brown and seemingly tasted OK, but everyone, including you, got sick shortly after eating them. Unbeknown to you, the milk that you used to make the batter expired several weeks ago. The quality of the ingredients impacted the meal, but everything looked fine on the outside.

The same philosophy can be applied to artificial intelligence (AI). Regardless of its purpose, AI's output is directly related to the quality of its input. As the popularity of AI continues to rise, security concerns around the data being fed into AI are coming into question.

A majority of today's organizations are integrating AI into business operations at some capacity — and threat actors are taking note. Over the past few years, a tactic known as AI poisoning has become increasingly prevalent. This new malicious practice involves injecting deceptive or harmful data into AI training sets. The tricky part about AI poisoning is that, despite the input being compromised, the output can initially continue as normal. It isn't until a threat actor gets a firm grip on the data and begins a full-fledged attack that deviations from the norm become obvious. The consequences range from slightly inconvenient to damaging a brand's reputation.

It's a risk affecting organizations of all sizes, even today's most prominent tech vendors. For example, over the past few years, adversaries launched several large-scale attacks to poison Google's Gmail spam filters and even turned Microsoft's Twitter chatbot hostile.

**Defending Against AI Data Poisoning**

Fortunately, organizations can take the following steps to shield AI technologies from potential poisoning.

*   Build a comprehensive data catalog. First, organizations should create a live data catalog that serves as a centralized repository of information that is being fed to its AI systems. Any time new data is added to AI systems, it should be tracked in this index. In addition, the catalog should be able to categorize the data flowing into AI systems by the who, what, when, where, why, and how to ensure transparency and accountability.
    
*   Develop a normal baseline for users and devices interacting with AI data. Once the security and IT teams have a solid understanding of all of the data in AI systems and who has access to it, it's important to develop a baseline of normal user and device behavior.
    

Compromised credentials are one of the easiest ways for cybercriminals to break into networks. All a threat actor has to do is either play a guessing game or buy one of the 24 billion username and password combinations available on the cybercriminal marketplace. Once they have access, a threat actor can easily maneuver their way into accessing AI training datasets.

By establishing user and device baseline behavior, security teams can easily detect abnormalities that might be indicative of an attack. Often, this helps stop a threat actor before an incident escalates into a full-blown data breach. For example, say you have an IT executive who typically works from the New York office and who oversees the AI data training sets. One day, it shows that he is active in another country and is adding large amounts of data to the AI. If your security team already has a baseline of user behavior, they can quickly tell that this is abnormal. Then security could either talk to the executive and verify that he was performing the action or, if he wasn't, temporarily disable his account until the alert is thoroughly investigated to prevent any further damage.

**Taking Responsibility of AI Training Sets**

Just like you should check the quality of the ingredients before you make a meal, it's critical to ensure the integrity of AI training data. AI intelligence is intricately linked to the quality of data it processes. Implementing guidelines, policies, monitoring systems, and improved algorithms plays a pivotal role in ensuring the safety and effectiveness of AI. These measures safeguard against potential threats and empower organizations to harness the transformative potential of AI. It is a delicate balance where organizations must learn to leverage AI's capabilities, while remaining vigilant in the face of the ever-evolving threat landscape.

**About the Author(s)**

CISO, Exabeam

Tyler Farrar is the Chief Information Security Officer (CISO) at Exabeam. He graduated from the United States Naval Academy in 2012, and received his Bachelor of Science in Aerospace Engineering. Tyler continued his education at Robert H. Smith School of Business, where he earned a Master of Business Administration in Accounting and Finance.

Fortify AI Training Datasets From Malicious Poisoning

PRESS RELEASE

DOWNERS GROVE, Ill., April 23, 2024 – CompTIA, the world’s leading information technology (IT) certification and training body, announced today that eight of its certifications are included in U.S. Department of Defense efforts to create, qualify and upskill a more diverse workforce to protect the nation’s interests, information and infrastructure.

The Cyber Workforce Qualification Program, which includes U.S. Department of Defense Manual 8140.03 (DoDM 8140.03), modernizes DoD talent management, allowing for more targeted and flexible approaches and options to manage and achieve a qualified cyber workforce in IT, cybersecurity, cyber effects, cyber intelligence and cyber enablers.

"As a leader in cybersecurity and IT upskilling, we have worked for years to create, qualify and upskill a more diverse workforce," said Dr. James Stanger, chief technology evangelist, CompTIA. "The DoD has adopted a targeted, role-based approach to identify, develop and qualify cyber personnel. This includes clear, standards-based certifications and training options for military personnel, civilian staff and government contractors."

The eight CompTIA certifications approved for DoDM 8140.03 cover 31 different work roles within the DoD cyber workforce. These job roles range from technical support and network operations specialists to cyber defense forensic analysts, cyber policy and strategy planners and information systems security developers and managers.

"It's exciting to see how CompTIA and the DoD have taken independent paths to achieve the same goals,” Dr. Stanger said. "Pathways are vital, and we're pleased to see how the U.S. DoD has specified the need for standards-based certifications and training options for military personnel, civilian staff and government contractors."

CompTIA certifications validate essential skills through performance-based exams that assess an individual’s ability to solve problems in real-world settings. These certifications are vendor-neutral, internationally recognized and accredited by the American National Standards Institute (ANSI) to comply with the ISO 17024 standard. CompTIA has awarded 3.5 million certifications to technology professionals around the world, including more than 800,000 in cybersecurity-related disciplines.

CompTIA will lead an education session on "Navigating and Implementing DoD 8140" at TechNet Cyber, the flagship event presented annually by the Armed Forces Communications & Electronics Association International (AFCEA). This year’s conference is June 25-27 at the Baltimore Convention Center.

To learn how CompTIA certifications map to DoDM 8140.03 work roles visit https://www.comptia.org/content/tools/comptia-and-dodm-8140.

About CompTIA

The Computing Technology Industry Association (CompTIA) is the world’s leading information technology (IT) certification and training body. CompTIA is a mission-driven organization committed to unlocking the potential of every student, career changer or professional seeking to begin or advance in a technology career. Millions of current and aspiring technology workers around the world rely on CompTIA for the training, education and professional certifications that give them the confidence and skills to work in tech. https://www.comptia.org/

CompTIA Supports Department of Defense Efforts to Strengthen Cyber Knowledge and Skills

Dark Reading talks cloud security with John Kindervag, the godfather of zero trust.

Source: Diego Schtutman via Alamy Stock Photo

While cloud security has certainly come a long way since the wild west days of early cloud adoption, the truth is that there's a long way to go before most organizations today have truly matured their cloud security practices. And this is costing organizations tremendously in terms of security incidents.

A Vanson Bourne study earlier this year showed that almost half of the breaches suffered by organizations in the past year originated in the cloud. That same study found that the average organization lost almost $4.1 million to cloud breaches in the last year.

Dark Reading recently caught up with the godfather of zero trust security, John Kindervag, to discuss the state of cloud security. When he was an analyst at Forrester Research, Kindervag helped conceptualize and popularize the zero-trust security model. Now he's chief evangelist at Illumio, where amid his outreach he's still very much a proponent of zero trust, explaining that it is a key way to redesign security in the cloud era. According to Kindervag, organizations must deal with the following hard truths in order to achieve success.

**1\. You Don't Become More Secure Just by Going to the Cloud**

One of the biggest myths about the cloud is that it is innately more secure than most on-premises environments, Kindervag says.

"There's a fundamental misunderstanding of the cloud that somehow there's more security natively built into it, that you're more secure by going to the cloud just by the act of going to the cloud," he says.

The problem is that while hyperscale cloud providers may be very good at protecting infrastructure, the control and responsibility they have over their customers' security posture is very limited.

"A lot of people think they're outsourcing security to the cloud provider. They think they're transferring the risk," Kindervag says. "In cybersecurity, you can never transfer the risk. If you are the custodian of that data, you are always the custodian of the data, no matter who's holding it for you."

This is why Kindervag is not a big fan of the oft-repeated phrase "shared responsibility," which he says makes it sound like there's a 50-50 division of labor and effort. He prefers the phrase "uneven handshake," which was coined by James Staten, his former colleague at Forrester.

"The fundamental problem is that people think that there's a shared responsibility model, and there's an uneven handshake instead," he says.

**2\. Native Security Controls Are Hard to Manage in a Hybrid World**

Meanwhile, let's talk about those improved native cloud security controls that providers have built up over the past decade. While many providers have done a good job offering customers more control over their workloads, identities, and visibility, that quality is inconsistent. As Kindervag says, "Some of them are good, some of them aren't." The real problem across all of them is that they're hard to manage out in the real world, beyond the isolation of a single provider's environment.

"It takes a lot of people to do it, and they're different in every single cloud. I think every company that I've talked to in the past five years has a multicloud and a hybrid model, both happening at the same time," he says. "Hybrid being, 'I'm using my on-premises stuff and clouds, and I'm using multiple clouds, and I may be using multiple clouds to deliver access to different microservices for a single application.' The only way that you can solve this problem is to have a security control that can be managed across all the multiple clouds."

This is one of the big factors driving discussions about moving zero trust to the cloud, he says.

"Zero trust works no matter where you put data or assets" he says. "It could be in the cloud. It could be on-premises. It could be on an endpoint."

**3\. Identity Won't Save Your Cloud**

With so much emphasis placed on cloud identity management and disproportionate attention on the identity component in zero trust, it's important for organizations to understand that identity is only part of a well-balanced breakfast for zero trust in the cloud.

"So much of the zero trust narrative is about identity, identity, identity," Kindervag says. "Identity is important, but we consume identity in policy in zero trust. It's not the end-all, be-all. It doesn't solve all the problems."

What Kindervag means is that with a zero-trust model, credentials don't automatically give users access to anything under the sun within a given cloud or network. The policy limits exactly what and when access is given to specific assets. Kindervag has been a longtime proponent for segmentation — of networks, workloads, assets, data — long before he began mapping out the zero-trust model. As he explains, the heart of defining zero-trust access by policy is divvying up things into "protect surfaces," since the risk level of different kinds of users accessing each protect surface will define the policies that will be attached to any given credential.

"That's my mission, to get people to focus on what they need to protect, put that important stuff into various protect surfaces, like your PCI credit card database should be in its own protect surface. Your HR database should be in its own protect surface. Your HMI for your IoT system or OT system should be in its own protect surface," he says. "When we break up the problem into these small bite-sized chunks, we solve them one chunk at a time, and we do them one after another. It makes it much more scalable and doable."

**4\. Too Many Firms Don't Know What They're Trying to Protect**

As organizations decide how to segment their protect surfaces in the cloud, they first need to clearly define what it is that they're trying to protect. This is crucial because each asset or system or process will carry its own unique risk, and that will determine the policies for access and the hardening around it. The joke is that you wouldn't build a $1 million vault to house a few hundred pennies. The cloud equivalent to that would be putting tons of protection around a cloud asset that's isolated from sensitive systems and doesn't house sensitive information.

Kindervag says it is incredibly common for organizations to not have a clear idea of what they're protecting in the cloud or beyond. In fact, most organizations today don't even necessarily have a clear idea of what is in the cloud or what connects to the cloud, let alone what needs protecting. For example, a Cloud Security Alliance study shows that only 23% of organizations have full visibility into cloud environments. And the Illumio study from earlier this year shows that 46% of organizations don't have full visibility into the connectivity of their cloud services.

"People don't think about what they're actually trying to accomplish, what they're trying to protect," Kindervag says. This is a fundamental issue that causes companies to waste a lot of security money without appropriately setting up protection in the process.

"They'll come to me and say, 'Zero trust isn't working,' and I'll ask, 'Well, what are you trying to protect?' and they'll say, 'I haven't thought about that yet,' and my answer is, 'Well, then, you're not even close to beginning the process of zero trust,'" he explains.

**5\. Cloud Native Development Incentives Are Out of Whack**

DevOps practices and cloud native development have been greatly enhanced through the speed, scalability, and flexibility afforded them by cloud platforms and tooling. When security is appropriately layered into that mix, good things can happen. But Kindervag says that most development organizations are not properly incentivized to make that happen — which means that cloud infrastructure and all of the applications that rest on it are put at risk in the process.

"I like to say that the DevOps app people are the Ricky Bobbys of IT. They just want to go fast," Kindervag says. "I remember talking to the head of development at a company who eventually got breached, and I was asking him what he was doing about security. And he said, 'Nothing, I don't care about security.' I asked, 'How can you not care about security?' and he says, 'Because I don't have a KPI for it. My KPI says I have to do five pushes a day in my team, and if I don't do that, I don't get a bonus.'"

Kindervag says this is an illustration of one of the big problems, not just in AppSec, but in moving to zero trust for the cloud and beyond. Too many organizations simply do not have the right incentive structures to make it happen — and, in fact, many have perverse incentives that end up encouraging insecure practice.

This is why he's an advocate for building up zero-trust centers of excellence within enterprises that include not just technologists but also business leadership in the planning, design, and ongoing decision-making processes. When these cross-functional teams meet, he says, he's seen "incentive structures change in real time" when a powerful business executive steps forward to say the organization is going to move in that direction.

"The most successful zero-trust initiatives were the ones where business leaders got involved," Kindervag says. "I had one in a manufacturing company where the executive vice president — one of the top leaders of the company — became a champion for zero-trust transformation for the manufacturing environment. That went very smoothly because there were no inhibitors."

5 Hard Truths About the State of Cloud Security 2024

Growing attacks targeting the flaw prompted CISA to include it in the known exploited vulnerabilities catalog earlier this month.

Source: HJBC via Shutterstock

Siemens is urging organizations using its Ruggedcom APE1808 devices configured with Palo Alto Networks (PAN) Virtual NGFW to implement workarounds for a maximum severity zero-day bug that PAN recently disclosed in its next-gen firewall product.

The command injection vulnerability, identified as CVE-2024-3400, affects multiple versions of PAN-OS firewalls when certain features are enabled on them. An attacker has been exploiting the flaw to deploy a novel Python backdoor on affected firewalls.

**Actively Exploited**

PAN patched the flaw after researchers from Volexity discovered the vulnerability and reported it to the security vendor earlier this month. The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2024-3400 to its catalog of known exploited vulnerabilities following reports of multiple groups attacking the flaw.

Palo Alto Networks itself has said it is aware of a growing number of attacks leveraging CVE-2024-3400 and has warned about proof-of-concept code for the flaw being publicly available.

According to Siemens, its Ruggedcom APE1808 product — commonly deployed as edge devices in industrial control environments — is vulnerable to the issue. Siemens described all versions of the product with PAN Virtual NGFW configured with the GlobalProtect gateway or GlobalProtect portal — or both — as affected by the vulnerability.

In an advisory, Siemens said it is working on updates for the bug and recommended specific countermeasures that customers should take in the meantime to mitigate risk. The measures include using specific threat IDs that PAN has released to block attacks targeting the vulnerability. Siemens' advisory pointed to PAN's recommendation to disable GlobalProtect gateway and GlobalProtect portal, and reminded customers that the features are already disabled by default in Ruggedcom APE1808 deployment environments.

PAN initially also recommended organizations disable device telemetry to protect against attacks targeting the flaw. The security vendor later withdrew that advice, citing ineffectiveness. "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability," the company noted.

Siemens urged customers, as a general rule, to protect network access to devices in industrial control environments with appropriate mechanisms, saying, "In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security."

The Shadowserver Foundation, which monitors the Internet for threat related traffic, identified some 5,850 vulnerable instances of PAN's NGFW exposed and accessible over the Internet as of April 22. Some 2,360 of the vulnerable instances appear to be located in North America; Asia accounted for the next highest number with around 1,800 exposed instances.

**Internet-Exposed Devices Remain a Critical Risk for ICS/OT**

It's unclear how many of those exposed instances are in industrial control system (ICS) and operational technology (OT) settings. But generally, Internet exposure continues to be a major issue in ICS and OT environments. A new investigation by Forescout uncovered nearly 110,000 Internet-facing ICS and OT systems worldwide. The US led the way, accounting for 27% of the exposed instances. However, that number was significantly lower compared with a few years ago. In contrast, Forescout found a sharp increase in the number of Internet-exposed ICS/OT equipment in other countries, including Spain, Italy, France, Germany, and Russia.

"Opportunistic attackers are increasingly abusing this exposure at scale — sometimes with a very lax targeting rationale driven by trends, such as current events, copycat behavior, or the emergencies found in new, off-the-shelf capabilities or hacking guides," Forescout said. The security vendor assessed that the exposure had to do at least in part with systems integrators delivering packaged bundles with components in them that inadvertently expose ICS and OT systems to the Internet. "In all likeliness," Forescout said, "most asset owners are unaware these packaged units contain exposed OT devices."

**About the Author(s)**

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 career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Siemens Working on Fix for Device Affected by Palo Alto Firewall Bug

An utterly innocuous feature in popular Git CDNs allows anyone to conceal malware behind brand names, without those brands being any the wiser.

Source: Image Source Limited via Alamy Stock Photo

Hackers are using unpublished GitHub and GitLab comments to generate phishing links that appear to come from legitimate open source software (OSS) projects.

The clever trick, first described by Sergei Frankoff of Open Analysis last month, allows anyone to impersonate any repository they wish without the owners of that repository knowing about it. And even if the owners do know about it, they can't do anything to stop it.

Case in point: Hackers have already abused this method to distribute the Redline Stealer Trojan, using links associated with Microsoft's GitHub-hosted repos "vcpkg" and "STL," according to McAfee. Frankoff independently discovered more cases involving the same loader used in that campaign, and Bleeping Computer found an additional affected repo, "httprouter."

According to Bleeping Computer, the issue affects both GitHub — a platform with more than 100 million registered users, and its closest competitor, GitLab, with more than 30 million users.

**Undetectable, Unstoppable, Believable Phishing Links**

This remarkable flaw in GitHub and GitLab lies in possibly the most mundane feature imaginable.

Developers will often leave suggestions or report bugs by leaving comments on an OSS project page. Sometimes, such a comment will involve a file: a document, a screenshot, or other media.

When a file is to be uploaded as part of a comment on GitHub's and GitLab's content delivery networks (CDNs), the comment is automatically assigned a URL. This URL is visibly associated with whatever project the comment pertains to. On GitLab, for example, a file uploaded with a comment earns a URL in the following format: https://gitlab.com/{project\_group\_name}/{repo\_name}/uploads/{file\_id}/{file\_name}.

What hackers have figured out is that this provides perfect cover for their malware. They can, for example, upload a malware loader for the RedLine Stealer to a Microsoft repo, and get a link in return. Though it houses malware, to any onlooker, it will appear to be a legitimate link to a real Microsoft repo file.

But that's not all.

If an attacker posts malware to a repo, you'd figure that the owner of that repo or GitHub would spot it and address it.

What they can do, then, is publish and then quickly delete the comment. The URL continues to work and the file remains uploaded to the site's CDN, nonetheless.

Or, even better: The attacker can simply not post the comment to begin with. On both GitHub and GitLab, a working link is automatically generated as soon as a file is added to a comment in progress.

Thanks to this banal quirk, an attacker can upload malware to any GitHub repo they wish, get a link back associated with that repo, and simply leave the comment unpublished. They can use it in phishing attacks for as long as they'd like, while the impersonated brand will have no idea that any such link was generated in the first place.

**Don't Trust Links**

Malicious URLs tied to legitimate repos lend credence to phishing attacks and, conversely, threaten to embarrass and undermine the credibility of the impersonated party.

What's worse: they have no recourse. According to Bleeping Computer, there is no setting that allows owners to manage files attached to their projects. They can temporarily disable comments, concomitantly preventing bug reporting and collaboration with the community, but there is no permanent fix.

Dark Reading reached out to both GitHub and GitLab to ask if they plan on fixing this issue and how. Here's how one responded:

"GitHub is committed to investigating reported security issues. We disabled user accounts and content in accordance with GitHub's Acceptable Use Policies, which prohibit posting content that directly supports unlawful active attack or malware campaigns that are causing technical harms," a GitHub representative said in an email. "We continue to invest in improving the security of GitHub and our users, and are looking into measures to better protect against this activity. We recommend users follow the instructions provided by maintainers on how to download the software that is officially released. Maintainers can utilize GitHub Releases or release processes within package and software registries to securely distribute software to their users."

Dark Reading will update the story if GitLab responds. In the meantime, users should tread lightly.

"Developers seeing the name of a trusted vendor in a GitHub URL will often trust that what they are clicking on is safe and legitimate," says Jason Soroko, senior vice president of product at Sectigo. "There has been a lot of commentary about how URL elements aren't understood by users, or don't have much to do with trust. However, this is a perfect example that URLs are important and have the capacity to create mistaken trust.

"Developers need to rethink their relationship to links associated with GitHub, or any other repository, and invest some time scrutinizing, just like they might with an email attachment."

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Hackers Create Legit Phishing Links With Ghost GitHub, GitLab Comments

The company reports most systems are functioning again but that analysis of the data affected will take months to complete.

Source: Yuri Arcurs via Alamy Stock Photo

UnitedHealth Group, in another unfortunate turn of events, has discovered that a large amount of its customers' personal data was compromised by two recent cyberattacks, from which it is still recovering.

A data review is ongoing, and the company says it expects it to take several more months of analysis before it has "enough information … available to identify and notify impacted customers and individuals." However, the company has not seen personal information like doctors' charts or full medical histories among the impacted data it's examined so far.

Change Healthcare, a subsidiary of UnitedHealth Group, fell victim to a ransomware attack on Feb. 23, ultimately leading to the company deciding to pay off the BlackCat/ALPHV ransomware affiliate responsible, after the US healthcare system fell into disarray. 

The enormity of the attack gained the attention of those in Washington, such as chairman of the Senate's Homeland Security and Governmental Affairs Committee, Sen. Gary Peters (D-Mich.), who encouraged HHS to take whatever steps necessary to prevent such an attack from ever happening again.

However, it didn't stop there. The company reportedly experienced another attack at the hands of RansomHub, which allegedly stole 4TB of company information, including financial data.

Now, in the wake of these new discoveries in its ongoing investigation and analysis, the company reported that many of its affected systems are on their way to being fully operational again: 99% of pre-incident pharmacies are able to process claims, medical claims are flowing at near-normal levels, and payment processing is at 86% of pre-incident levels. UnitedHealth Group also reports that it is in communication with law enforcement and regulators and is providing resources for impacted customers at http://changecybersupport.com. 

**About the Author(s)**

Back from the Brink: UnitedHealth Offers Sobering Post-Attack Update

It's time to start regulating LLMs to ensure they're accurately trained and ready to handle business deals that could affect the bottom line.

Kevin Bocek, Chief Innovation Officer, Venafi

April 23, 2024

5 Min Read

Source: Bakhtiar Zein via Alamy Stock Photo

COMMENTARY

OWASP recently released its top 10 list for large language model (LLM) applications, in an effort to educate the industry on potential security threats to be aware of when deploying and managing LLMs. This release is a notable step in the right direction for the security community, as developers, designers, architects, and managers now have 10 areas to clearly focus on. 

Similar to the National Institute of Standards and Technology (NIST) framework and Cybersecurity and Infrastructure Security Agency (CISA) guidelines provided for the security industry, OWSAP's list creates an opportunity for better alignment within organizations. With this knowledge, chief information security officers (CISOs) and security leaders can ensure the best security precautions are in place around the use of LLM technologies that are quickly evolving. LLMs are just code. We need to apply what we have learned about authenticating and authorizing code to prevent misuse and compromise. This is why identity provides the kill switch for AI, which is the ability to authenticate and authorize each model and their actions, and stop it when misuse, compromise, or errors occur.

**Adversaries Are Capitalizing on Gaps in Organizations**

As security practitioners, we've long talked about what adversaries are doing, such as data poisoning, supply chain vulnerabilities, excessive agency and theft, and more. This OWASP list for LLMs is proof that the industry is recognizing where risks are. To protect our organizations, we have to course correct quickly and be proactive. 

Generative artificial intelligence (GenAI) is putting a spotlight on a new wave of software risks that are rooted in the same capabilities that made it powerful in the first place. Every time a user asks an LLM a question, it crawls countless Web locations in an attempt to provide an AI-generated response or output. While every new technology comes with new risks, LLMs are especially concerning because they're so different from the tools we're used to.

Almost all of the top 10 LLM threats center around a compromise of authentication for the identities used in the models. The different attack methods run the gamut, affecting not only the identities of model inputs but also the identities of the models themselves, as well as their outputs and actions. This has a knock-on effect and calls for authentication in the code-signing and creating processes to halt the vulnerability at the source.

**Authenticating Training and Models to Prevent Poisoning and Misuse**

With more machines talking to each other than ever before, there must be training and authentication of the way that identities will be used to send information and data from one machine to another. The model needs to authenticate the code so that the model can mirror that authentication to other machines. If there's an issue with the initial input or model — because models are vulnerable and something to keep a close eye on — there will be a domino effect. Models, and their inputs, must be authenticated. If they aren't, security team members will be questioning if this is the right model they trained or if it's using the plug-ins they approved. When models can use APIs and other models' authentication, authorization must be well defined and managed. Each model must be authenticated with a unique identity.

We saw this play out recently with AT&T's breakdown, which was dubbed a "software configuration error," leaving thousands of people without cellphone service during their morning commute. The same week, Google experienced a bug that was very different but equally concerning. Google's Gemini image generator misrepresented historical images, causing diversity and bias concerns due to AI. In both cases, the data used to train GenAI models and LLMs — as well as the lack of guardrails around it — was the root of the problem. To prevent issues like this in the future, AI firms need to spend more time and money to adequately train the models and inform the data better. 

In order to design a bulletproof and secure system, CISOs and security leaders should design a system where the model works with other models. This way, an adversary stealing one model does not collapse the entire system, and allows for a kill-switch approach. You can shut off a model and keep working and protecting the company's intellectual property. This positions security teams in a much stronger way and prevents any further damages. 

**Acting on Lessons From the List **

For security leaders, I recommend taking OWASP's guidance and asking your CISO or C-level execs how the organization is scoring on these vulnerabilities overall. This framework holds us all more accountable for delivering market-level security insights and solutions. It is encouraging that we have something to show our CEO and board to illustrate how we're doing when it comes to risk preparedness. 

As we continue to see risks arise with LLMs and AI customer service tools, like we just did with Air Canada's chatbot giving a reimbursement to a traveler, companies will be held accountable for mistakes. It's time to start regulating LLMs to ensure they're accurately trained and ready to handle business deals that could affect the bottom line. 

In conclusion, this list serves as a great framework for rising Web vulnerabilities and the risks we need to pay attention to when using LLMs. While more than half of the top 10 risks are ones that are essentially mitigated and calling for the kill switch for AI, companies will need to evaluate their options when deploying new LLMs. If the right tools are in place to authenticate the inputs and models, as well as the models' actions, companies will be better equipped to leverage the AI kill-switch idea and prevent further destruction. While this may seem daunting, there are ways to protect your organization amid the infiltration of AI and LLMs in your network.

**About the Author(s)**

Chief Innovation Officer, Venafi

As Chief Innovation Officer, Kevin is leading Venafi’s growth in new innovations, and is at the forefront of Venafi’s cutting-edge machine identity management for workload identity, Kubernetes and AI. He also drives Venafi’s technology ecosystem and developer community to futureproof customer success and is responsible for the company’s Machine Identity Management Development Fund, which has sponsored innovations with more than 50 developers globally. Kevin brings more than 25 years of experience in cybersecurity with industry leaders including RSA Security, PGP Corporation, IronKey, CipherCloud, Thales, nCipher, and Xcert.

Lessons for CISOs From OWASP's LLM Top 10

The State Department can now deny entrance to the US for individuals accused of profiting from spyware-related human rights abuses, and their immediate family members.

Source: Robert Brown via Alamy Stock Photo

The US State Department is imposing visa restrictions on 13 people involved in the development and sale of commercial spyware, as well as their spouses and children. 

"These individuals have facilitated or derived financial benefit from the misuse of this technology, which has targeted journalists, academics, human rights defenders, dissidents and other perceived critics, and US government personnel," according to a press statement from the department issued yesterday. It's the first implementation on a spyware-related visa-restriction program announced in February.

Visa restrictions mean that the State Department can deny entrance to the United States for any of the people placed under the order. The move is the latest in a series of efforts by the government to combat the commercial spyware used by authoritarian governments, which it says constitutes a human rights abuse. NSO Group's infamous Pegasus mobile tracking tool, for instance, has been involved in a series of attacks on civil society by repressive regimes, the US has alleged.

Other efforts have included restrictions on the US government's own use of commercial spyware, export controls and sanctions, and private-public threat intelligence partnerships.

**About the Author(s)**

Source

DARKReading