Wide use and lack of support for malware detection technologies has made VMware's virtualization technology a prime target for cyberattackers.

The widespread use of VMware's ESXi hypervisor and the fact that it does not support any third-party malware detection capabilities has made the technology an increasingly attractive target for ransomware operators.

The latest manifestation of that fashion trend is "MichaelKors," a new ransomware-as-a-service (RaaS) program that researchers at CrowdStrike found attackers recently using to target ESXi/Linux systems. MichaelKors is one of several paid services CrowdStrike is tracking — including Alpha Spider, Bitwise Spider, and Sprite Spider — that currently provide attackers with malicious binaries for locking up ESXi systems.

**A Slew of ESXi Ransomware**

Earlier this month, SentinelOne reported a similar trend involving ransomware variants based on leaked source code of the Babuk ransomware strain from 2021. Between the second half of 2022 and so far in 2023, SentinelOne has observed at least 10 ransomware families based on Babuk source code targeting the ESXi hypervisor. Among those using the Babuk ESXi variants were small groups and large ransomware operators such as Conti and REvil. SentinelOne found the attackers often taking advantage of ESXi's native tools and commands to kill guest machines and encrypt hypervisor files.

Other vendors have reported seeing multiple other major ransomware groups, including the operators of Royal ransomware, Luna, and Black Basta, all pivoting from Windows to ESXi/Linux over the past year.

A couple of factors are driving attacker interest in hypervisors and VMware's ESXi technology in particular.

**Hypervisor Jackpotting**

One of them is the fact that many organizations use ESXi to manage their virtual infrastructure. VMware environments often host hundreds of VMs running business critical applications. By compromising ESXi, attackers can potentially gain control over multiple virtual machines on the host, thereby giving them an opportunity to considerably scale up their attacks. In a ransomware scenario, an attacker can encrypt multiple virtual machines and increase their likelihood of collecting a ransom from victims.

Such "hypervisor jackpotting" is a tactic that attackers use in so-called big game hunting campaigns targeting large and high-profile enterprise organizations. "In hypervisor jackpotting, threat actors deploy Linux versions of ransomware tools specifically designed to affect VMware’s ESXi vSphere hypervisor," a CrowdStrike spokeswoman says. "By deploying ransomware on ESXi hosts, adversaries quickly increase the scope of affected systems within the victim environments, resulting in additional pressure on victims to pay a ransom demand."

**A Lack of Support for Malware Detection**

The second reason attackers are increasingly targeting ESXi environments is because they know the hypervisor doesn't support any native malware detection capabilities, according to CrowdStrike. As a hypervisor, ESXi is designed purely to provide virtualization services and services for managing virtual machines. VMware itself has described the hypervisor as not requiring any antivirus software and has not provided any support for third-party malware detection agents either. "ESXi, by design, does not support third-party agents or antivirus software and VMware states in its documentation that antivirus software is not required," CrowdStrike said in its blog post this week. This fact, combined with the popularity of ESXi has made the hypervisor a highly attractive target for modern adversaries, the security vendor said.

Others have highlighted the same problem. Recorded Future, which counted a threefold increase in ransomware targeting ESxi servers between 2021 and 2022 (from 434 to 1,188) recently noted the immaturity of antivirus and malware detection technologies for ESXi — and the difficulty in implementing them — as lowering the barrier for threat actors. "Defensive practices are difficult to implement due to the complex nature of hypervisors," Recorded Future said.

ESXi vulnerabilities are another problem. A case in point is a global ransomware attack on ESXi servers earlier this year that exploited two vulnerabilities in the hypervisor one from 2021 (CVE-2021-21974) and the other from 2020 (CVE-2020-3992) to drop a novel ransomware strain called ESXiArgs.

"Given the popularity of VMware products and the continuous adoption of cloud infrastructure, this problem appears to be getting worse," the CrowdStrike spokeswoman says. "CrowdStrike Intelligence has also observed hypervisor jackpotting becoming a dominant trend."

The larger issue at play is that there is currently no solution out there to help with the threat. Threat actors continue to target VMware as they know that the ESXi environment is vulnerable and without remedy at the moment, the CrowdStrike spokeswoman notes. "More and more threat actors are recognizing that the lack of security technology and monitoring, lack of adequate network segmentation of ESXi interfaces, and in-the-wild vulnerabilities for ESXi create a target-rich environment" for ransomware attackers.

'MichaelKors' Showcases Ransomware's Fashionable VMware ESXi Hypervisor Trend

Former Humu, Google, and Twitter security leader adds deep security experience.

**MOUNTAIN VIEW, Calif.****,** **May 15, 2023** **/PRNewswire/ --** Lacework, the data-driven cloud security company, today announced the appointment of Lea Kissner as its new Chief Information Security Officer (CISO). As CISO, Kissner will be responsible for leading the development and implementation of Lacework's overall security strategy and programs.

Kissner brings over 20 years of experience leading security, privacy, and anti-abuse efforts at global organizations to Lacework. Their experience includes serving as CISO at Twitter, Chief Privacy Officer at Humu, and Global Lead of Privacy Technology at Google. In the spring of 2020, when Zoom experienced security concerns after a massive increase in usage due to the  COVID-19 pandemic, Kissner served as a Security and Privacy consultant for the company to improve the security, privacy and anti-abuse features of Zoom's products and systems.

Kissner currently serves as a board member to the USENIX Association, a nonprofit organization dedicated to supporting the advanced computing systems communities and furthering the reach of innovative research.

"I am thrilled to join the team at Lacework and our mission to secure the cloud at a time when enterprises are increasingly expanding their cloud environments," said Kissner. "My whole career I've been passionate about helping people build respectful, secure products that just work for their users. Lacework's unique, data-driven approach to cloud security allows customers to do just that while taking advantage of all the inherent benefits of the cloud."

Kissner's appointment comes as Lacework continues to expand its presence in the cloud security market, as well as its leadership team. In November of 2022 the company announced 

"Lea brings a deep understanding of both the challenges facing modern CISOs as well as the tremendous value CISOs bring to their organizations and customers when given the chance to implement security best practices," said Jay Parikh, CEO, Lacework. "Every enterprise needs to be investing in security leadership, both at the operator and board level, and Lea's experience will help us better serve our customer CISOs as we continue to deliver a world class cloud security platform to help them do their job."

To learn more about Lacework, visit lacework.com.

**About Lacework**

Lacework offers the data-driven security platform for the cloud and is the leading cloud-native application protection platform (CNAPP) solution. Only Lacework can collect, analyze, and accurately correlate data — without requiring manually written rules — across an organization's cloud and Kubernetes environments, and narrow it down to the handful of security events that matter. Security and DevOps teams around the world trust Lacework to secure cloud-native applications across the full lifecycle from code to cloud. Get started at www.lacework.com.

SOURCE Lacework

Lacework Appoints Lea Kissner as Chief Information Security Officer

Relatives are being alerted that a PharMerica compromise exposed the sensitive data of their deceased loved ones, which could be used for identity theft.

PharMerica Healthcare has disclosed that its systems were breached earlier this year by an unauthorized third party, which resulted in the leak of the personal details of more than 5.8 million deceased people.

PharMerica provides pharmacy services for patients under long-term care, including those in senior living facilities, hospice care, and using behavior health services.

A copy of a letter disclosing the data theft sent by PharMerica and addressed to the "Administrator/Executor of the Estate of...," explained the cybersecurity incident occurred from March 12-13, and exposed information including the deceased person's name address, date of birth, Social Security number, medications, and health insurance details.

PharMerica added that it has conducted a review of the incident and has "taken steps to reduce the risk of this type of incident from occurring in the future, including enhancing our technical security measures."

NextGen Healthcare similarly disclosed a data breach by a third party days before PharMerica. In NextGen's case, an unauthorized actor accessed a database with information on more than 1 million people.

**Seniors Most at Risk**

"This is a devastating data breach both in terms of size and the severity of what was leaked," Paul Bischoff, consumer privacy advocate at Comparitech, said in a statement in reaction to the PharMerica disclosure.

"The Social Security and health insurance information pose the most immediate threat," Bischoff added. "They could be used for identity theft and medical benefits fraud, respectively."

Because the victims are passed, relatives aren't likely to regularly monitor their credit reports, making any cybercrime related to the stolen data even more difficult to detect and stop, Bischoff explained.

"That puts the onus of responsibility on relatives, who could be on the hook for the deceased's debts," Bishoff added. "I suspect this attack disproportionately affects the elderly as well, who are frequently targeted by fraud."

Chris Hauk, consumer privacy advocate at Pixel Privacy, also urged in a statement those impacted by the PharMerica compromise to stay on alert for accounts and lines of credit opened in a deceased person's name, as well as phishing attempts using the stolen sensitive data.

"As senior citizens make up a large number of pharmaceutical customers, they and their caretakers will also need to stay alert for phishing attempts," Hauk added.

PharMerica Leaks 5.8M Deceased Users' PII, Health Information

The freshly minted ransomware gang is customizing leaked Babuk source code to go after cyber targets in the US and South Korea — and it's expanding its operations quickly.

A newly discovered ransomware gang dubbed RA Group is ramping up its cyberattacks — the latest in a line of threat actors leveraging the leaked Babuk source code. The group distinguishes itself from the rest of the Babuk pack, however, with a highly customized approach.

According to an analysis from Cisco Talos this week, RA Group opened shop on April 22 and has been rapidly expanding its operations ever since. So far, it's gone after organizations in the US and South Korea in the manufacturing, wealth management, insurance, and pharmaceutical industries.

By way of background, the full source code for the Babuk ransomware was leaked online in September 2021, and since then several new threat actors have used it to go into the ransomware business. In particular, several have used it to develop lockers for VMware ESXi hypervisors — over the past year, 10 different ransomware families have gone that route.

Others have customized the code in other ways, taking advantage of the fact that it is built to exploit several known vulnerabilities, including those found in Microsoft Exchange, Struts, WordPress, Atlassian Confluence, Oracle WebLogic Server, SolarWinds Orion, Liferay, and others.

"By reusing code written by others and leaked, these groups are reducing their development time significantly and possibly even incorporating features they would otherwise have been unable to create themselves," Erich Kron, security awareness advocate at KnowBe4, said in an emailed comment. 

He added, "In the last few years, especially after ransomware-as-a-service (RaaS) offerings became popular, it's become very clear that you do not have to be a technical marvel to play in the cybercrime and extortion game. Simply using other people's code, through a subscription or through leaks such as this, with minor modifications can get just about anyone equipped to carry out attacks."

**RA Group's Unique Take on Babuk**

In RA Group's case, it's using a typical double-extortion model in which it threatens to leak exfiltrated data if the victim doesn't pay the ransom; however, according to the ransom note, victims have just three days to pay up.

That's not the only tweak to known playbooks the group is employing. "In their leak site, RA Group discloses the name of the victim's organization, a list of their exfiltrated data and the total size, and the victim’s official URL, which is typical among other ransomware groups’ leak sites," according to Cisco Talos' analysis of the ransomware group. But in a twist, the "RA Group is also selling the victim’s exfiltrated data on their leak site by hosting the victims’ leaked data on a secured Tor site."

Despite the RA Group's spin on ransomware, the basics remain effective when it comes to defending against the threat: Organizations should make sure their environments are patched and up to date, continually monitor their networks for any signs of malicious activity (and ensure their security tools are updated with the latest indicators of compromise), and ensure they have effective backup and recovery procedures in place in the event of a successful attack.

RA Ransomware Group Emerges With Custom Spin on Babuk

With the introduction of generative AI, even more business users are going to create low-code/no-code applications. Prepare to protect them.

In recent years low-code/no-code has been empowering business users to address their needs on their own, without waiting for IT, by intuitively building applications and automations. Generative AI, which has captured the imaginations and mindshare of the enterprise and customers, both increases that power and reduces the barrier to entry to practically zero. Embedding generative AI in low-code/no-code turbocharges the business' capability to move forward independently. Now, without a shadow of a doubt, everyone is a developer. Are we ready for the security risk that follows?

As soon as ChatGPT was released, business professionals started using it and other generative AI tools in an enterprise setting to get their jobs done quicker and better. Generative AI writes PR pitches for marketing directors, prospecting emails for sales reps, and many more use cases. While data governance and legal issues have emerged as inhibitors for official enterprise adoption, business users aren't waiting for approval and have already integrated it into their daily operations.

Meanwhile, developers have been using generative AI to write and improve code with tools like GitHub Copilot. A developer specifies a software component in natural language, and the AI generates working code that fits within the developer's context. The developer's role in this workflow is crucial: They must ask the right technical questions, be able to evaluate the generated software, and integrate it with the rest of the code base. These tasks require software engineering expertise.

Note that there's a clear distinction between the business professional and developer use cases specified above; the developer produces software that can be shared and reused, and can act on behalf of users, while the business professional answers a specific question or need, one example at a time. The limiting factor for business professionals to generate their own applications is their ability to reason about software produced by the AI without having the technical expertise of a developer. This is exactly where low-code/no-code comes into play.

**Code Generation for Business Professionals**

Low-code/no-code is, more than anything, an intuitive language that allows anyone to reason about software without having a technical background. This makes it the perfect candidate to act as a translator between generative AI and business users. Instead of generating software code that requires technical expertise to evaluate, generative AI generates low-code/no-code applications and automations that business users can easily evaluate and adjust. Low-code/no-code and AI are the perfect match to empower business professionals.

Major low-code/no-code vendors have already announced AI copilots that generate applications based on text inputs. Analysts are forecasting a five- to 10-times growth in low-code/no-code application development following the introduction of AI-assisted development. Low-code/no-code platforms also allow the AI to easily integrate across the enterprise environment, gaining access to enterprise data and operations. We are getting closer to a reality where every conversation with the AI can leave behind an application. That application would plug into business data, be shared with other business users, and get integrated into business workflows.

**Accept and Manage the Security Risk**

Security teams have traditionally focused on the applications that their development organizations create. We still often fall prey to thinking about business platforms as ready-made solutions, when in reality they have become application development platforms that power many of our business-critical applications. We have only just begun to make progress in bringing citizen developers under the security umbrella.

With the introduction of generative AI, even more business users are going to create even more applications. Business users are already making decisions about where data is stored, how it is processed by their applications, and who can gain access to it. If we leave these choices up to them without any guidance, mistakes are bound to happen.

Some organizations will try to ban citizen development or ask for business users to get approval for any application or data access. While that is a reasonable reaction, I find it difficult to believe it would succeed in face of the massive productivity payoffs for the business. A better approach would be to provide a safe way for business users to leverage generative AI with low-code/no-code, installing automated guardrails that silently handle security issues and leave business users to do what they do best: push the business forward.

Generative AI Empowers Users but Challenges Security

This Tech Tip demonstrates how security engineers can best use rate limits to mitigate distributed denial-of-service attacks.

Distributed denial-of-service (DDoS) attacks are growing in frequency and sophistication, thanks to the number of attack tools available for a couple of dollars on the Dark Web and criminal marketplaces. Numerous organizations became victims in 2022, from the Port of London Authority to Ukraine's national postal service.

Security leaders are already combating DDoS attacks by monitoring network traffic patterns, implementing firewalls, and using content delivery networks (CDNs) to distribute traffic across multiple servers. But putting more security controls in place can also result in more DDoS false positives — legitimate traffic that's not part of an attack but still requires analysts to take steps to mitigate before it causes service disruptions and brand damage.

Rate limiting is often considered the best method for efficient DDoS mitigation: URL-specific rate limiting prevents 47% of DDoS attacks, according to Indusface's "State of Application Security Q4 2022" report. However, the reality is that few engineering leaders know how to use it effectively. Here's how to employ rate limiting effectively while avoiding false positives.

**Understand Expected Network Traffic and Vulnerabilities**

Engineering leaders often find it difficult to implement rate limiting as a DDoS mitigation tool because they don't know what thresholds to set. The first step is to answer the following questions:

*   How many users visit your application every minute?
*   How many report/dashboard actions can your application handle? Is that the same for a reset password page?
*   Since server load on dashboards tends to be high, could a lower rate limit block legitimate users trying to access a cheaper resource, such as a profile page, for example?

Going over 100 requests in one minute on a login page could be enough to take the server down, while a product page might have no trouble handling 300 requests in a minute. That's why it is useful to know the threshold of network traffic for each URL within each application.

Network monitoring tools, log files, and buffer capacity can help teams develop accurate baseline network traffic models and manage incoming and outgoing data flow. Suppose you ran a Christmas holiday campaign over 30 days, and the request limit was 300 per minute. To clearly understand the expected network traffic, the security and DevOps teams need to know two things: How many requests were made each minute on average? And if there were 480 requests in one minute, does the team get an alert to check that it was legitimate traffic?

Having granular details on IP, host, domain, and URI vulnerabilities means teams can act more quickly to thwart DDoS attacks.

Numerous security teams have been surprised to receive alerts about attacks targeting their human resource management systems, not just consumer-facing business websites. It is vital to be aware of all the potential applications targeted by DDoS attacks to reduce false alarms.

**Implement Custom Rate Limits on Various Parameters**

Security teams want around-the-clock application availability and are relying on managed services to get more value from DDoS mitigation software. In-built DDoS scrubbers help security leaders go beyond static rate limits and customize rules based on the behavior of inbound traffic received by host, IP, URL, and geography.

So what should cybersecurity teams know about rate limits?

*   Never do rate limits on the domain level (e.g., acme.com). Hundreds of URLs get added to the domain, which lowers the per-page requests needed to trigger the rate limit. This can cause unnecessary blocking of legitimate requests or, if you compensate by raising the rate limits overall, allow too many malicious requests to pass through.
*   Set rate limits on the URL (e.g., acme.com/login) to control which customers can access a particular URL or set of URLs. Cybersecurity teams can set rate limits differently for each URL, and a server may block requests if the number exceeds the rate limit.
*   Customize the rate of requests on a session level (the time logged in) to detect unusual behavior that may indicate malicious activity and thus prevent servers from being overwhelmed. For example, if a user opens acme.com 100 times a minute, that's not normal behavior.
*   Monitor rate limits at an IP level to limit the number of requests or connections from a particular IP address. IP blacklisting — adding known malicious actors or sources to a blacklist — makes it easier for website owners to block traffic from IP addresses known to be involved in DDoS attacks.
*   Implement geographical rate limiting. Security leaders need to quickly examine IP address reputations and geolocation data to verify the source of traffic. As a best practice, I recommend teams implement geofencing as a standard for all local applications.

By using the above methods, application owners end up setting more granular rate limits by using system recommendations based on user behavior. This — in conjunction with using DDoS mitigation mechanisms, such as tarpitting and CAPTCHA, before blocking requests — can minimize false positives to the maximum extent possible.

Cybersecurity decision-makers must take a multilayered approach to protection by having a clear understanding of network traffic patterns and using fully managed platforms to set rate limits for threat intelligence.

Break the DDoS Attack Loop With Rate Limiting

A misconfigured cloud instance exposed vehicle data, but not personally identifiable information, the car maker says.

Toyota has disclosed that for more than 10 years, a misconfigured cloud bucket left more 2.15 million customer records exposed to the open Internet.

According to the disclosure, the sensitive data from Toyota's cloud-based Connected services was open to unauthorized access from November 2013 to this April. The Toyota Connected offering allows drivers to stream entertainment, use location data to find stolen vehicles, receive flash maintenance reminders, and send for emergency help in case of an accident.

Toyota spokesperson Hideaki Homma told Associated Press that the Connected service breach only impacts customers in Japan. Any unauthorized access to the data would not identify individual customers, the carmaker said in its statement, adding that there has not been any observed use or abuse of the data from a third party.

"We believe that the main reason for this incident was insufficient explanation and thoroughness of rules for data handling," a Google translation of the Toyota data breach disclosure statement read. "(We will) collaborate closely with the \[Toyota corporation\], thoroughly educate employees, work to prevent recurrence, introduce a system to audit the cloud settings, conduct a setting survey of the cloud environment, and continuously monitor the setting status. We will build a system."

This isn't the first security incident for the automaker this year. Just in March, a hacker made headlines by exploiting a flaw in Toyota's C360 customer relationship management (CRM) software, exposing the personal data of an unknown number of the company's customers in Mexico.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Toyota Discloses Decade-Long Data Leak Exposing 2.15M Customers' Data

A two-bit comedian is using a patched Microsoft vulnerability to attack the hospitality industry, and really laying it on thick along the way.

A threat actor is exploiting last year's Follina (RCE) remote code execution vulnerability to deploy the XWORM remote access trojan (RAT) and data-stealer against targets in the hospitality industry.

On May 12, researchers from Securonix broke down the campaign, which uses Follina to drop Powershell code onto target machines, which is rife with various 4Chan and meme references. Thus, the researchers refer to the campaign as "MEME#4CHAN," due to the amorphous line it draws between stealth and internet humor.

**The MEME#4CHAN Attack Flow**

MEME#4CHAN attacks begin with a phishing email, with a hospitality hook in the subject line — something like "Reservation for Room." Attached will be a Microsoft Word document furthering the theme, such as "Details for booking.docx."

Once a victim clicks on the document, they're presented with a dialogue box: "This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?" But regardless of whether they click "Yes" or "No," a Word document opens, containing stolen images of a French driver's license and debit card.

The choice of a .docx file is notable. Hackers often used to use malicious macros in Office files to gain a foothold in a target machine, which isn't as effective of a tactic now that Microsoft decided to block macros from Internet files by default.

Without that option, MEME#4CHAN instead turns to Follina. Follina (CVE-2022-30190) is an RCE vulnerability that carries a "high" CVSS score of 7.8. It allows attackers to create specially-crafted Microsoft Word files that trick Microsoft's Diagnostic Support Tool into downloading and executing malicious code from an attacker-controlled server. The bug was disclosed and patched a year ago.

Through Follina, MEME#4CHAN downloads an obfuscated Powershell script once the Word document is opened. The script is notable for its labored references, memes, and uninspiring jokes. The author laments at multiple points "why my ex left me," for example, and gives directories, variables, and functions such names as "mememan," "shakalakaboomboom," and "stepsishelpme."

The jokes might be considered a unique stealth tactic, designed to instantly repel any researcher of good taste. But Securonix researchers noted that the attack uses other more traditional obfuscation as well.

In fact, the researchers found variables in the Powershell code ranging from "semi-" to "heavily" obfuscated they said, including a "heavily obfuscated" .NET binary which, once decoded, revealed itself as the XWORM RAT.

"The relative amount of effort invested into obfuscation and covertness is higher than for the similar attacks we observed," says Oleg Kolesnikov, vice president of threat research and detection at Securonix, "and it is not yet clear why."

**What Is XWORM?**

XWORM is a bit of a Swiss Army knife of a RAT.

On one hand, it does RAT things — checking for antivirus, communicating with a command-and-control (C2) server, opening a backdoor to a machine, and creating an autorun entry to ensure persistence across restarts.

At the same time, it comes replete with espionage features, including capabilities for accessing a device's microphone and camera, and keylogging; and it can instigate follow-on attacks like distributed denial of service (DDoS) or even ransomware.

That said, the malware is of dubious quality, some note.

Multiple iterations of XWORM have been leaked online in recent months, including a 3.1 version just last month. The individual who published the 3.1 code to GitHub didn't appear to hold it in high regard.

"There are so many sh\*tty Rat \[sic\], XWorm is one of them. I'm sharing it so that you don't pay for such things for nothing," the person wrote in a README file.

"Compared to some of the other similar underground attack tools for which source code was leaked recently," Kolesnikov judges, "XWORM does appear to have arguably somewhat less advanced capabilities, though \[it's usefulness\] often depends on the specific capability \[required\]. It depends on how the malicious threat actors use the tool as part of an attack."

**Which Cybercriminals Are Behind MEME#4CHAN?**

According to the researchers, it's likely the author behind MEME#4CHAN is English-speaking, due to all the 4Chan references in their code.

Dark Reading also independently observed several variables in the code referencing Indian cultural touchpoints, indicating either that the hacker is of Indian origin, or familiar enough with Indian culture to fake it.

Taking further evidence into account adds color and cloudiness to the attribution picture. "The attack methodology is similar to that of TA558, a cybercriminal gang, where phishing emails were delivered targeting the hospitality industry," the Securonix researchers explained.

He added, however, that "TA558 also typically uses a wide range of C2 campaign artifacts and payloads similar, but not positively in line with what we witnessed through the MEME#4CHAN campaign."

Whoever's behind it, it doesn't appear that this campaign is over with, as several of its associated C2 domains are still active.

The researchers recommended that to avoid becoming potential victims, organizations should avoid opening any unexpected attachments, watch out for malicious file hosting websites, and implement log anomaly detection and application whitelisting.

Microsoft Follina Bug Is Back in Meme-Themed Cyberattacks Against Travel Orgs

A predictable patch cadence is nice, but the software giant can do more.

As the 20th anniversary of Patch Tuesday approaches later this year, many are reflecting on the importance of the program that brought predictability to Microsoft security patch cycles. Patch Tuesday undoubtedly improved the security of customers, and the success of the program is reflected in the number of organizations that established their own Patch Tuesdays, including Adobe, Siemens, Schneider Electric, and more.

However, the quality of the vulnerability details published by Microsoft on Patch Tuesday has noticeably declined. Vulnerability descriptions used to be useful. Now they are reduced to being nearly meaningless. Compare, for example, the CVE descriptions in the National Vulnerability Database (NVD) for CVE-2017-0290 and CVE-2023-21554 (aka QueueJumper):

_**CVE-2017-0290 NVD Vulnerability Description**_

_The Microsoft Malware Protection Engine running on Microsoft Forefront and Microsoft Defender on Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 does not properly scan a specially crafted file leading to memory corruption, aka "Microsoft Malware Protection Engine Remote Code Execution Vulnerability."_

_**CVE-2023-21554 Vulnerability Description**_

_Microsoft Message Queuing Remote Code Execution Vulnerability_

The first description details the affected components (Forefront and Defender), the affected versions (various Windows operating systems), the attack vector (crafted file), and a bug class (memory corruption). The second description lacks almost all of those details.

This is not an isolated case. In fact, Microsoft's CVE descriptions have been on the decline for a number of years. The following graph maps the median length of Microsoft-created CVE descriptions over the past 20 years:

    

Source: Jacob Baines

**Impact on Defenders**

The poor descriptions have a serious impact on practitioners. It's difficult to prioritize vulnerabilities when it's unclear what the problems are. How is anyone supposed to know if Microsoft Message Queuing Remote Code Execution Vulnerability is a big deal or not? How many practitioners know what Microsoft Message Queuing is, or what major pieces of software use it? Is it enabled by default? Does it listen on a network port? The practitioner is forced to go looking for all this information themselves.

To avoid that type of thing, MITRE created well-defined rules for what is required in a CVE description. These are the minimum requirements:

_8.2.1 MUST provide enough information for a reader to have a reasonable understanding of what products are affected._

_8.2.3 MUST include one of the following:_

_1\. Vulnerability Type_

_2\. Root Cause_

_3\. Impact_

**Does Microsoft Message Queuing Remote Code Execution Vulnerability Satisfy These Requirements?**

Maybe a very loose interpretation of 8.2.3 would be satisfied with Code Execution Vulnerability. But can anyone reasonably say that "Microsoft Message Queuing" describes the affected products?

At least Microsoft included a specific service for CVE-2023-21554 (Message Queuing). It didn't even do that for CVE-2023-23415. That description doesn't list any software, and instead opts to list an affected protocol:

_**CVE-2023-23415 Vulnerability Description**_

_Internet Control Message Protocol (ICMP) Remote Code Execution Vulnerability_

**CWE Assigned to Microsoft CVE**

It's unclear why MITRE allows Microsoft to ignore (or, generously, skirt) the CVE description rules. What is clear is that everyone else is worse off because of it. If appealing to the overburdened practitioner isn't enough, we can actually measure the impact of Microsoft's bad CVE descriptions on NIST's per CVE common weakness enumeration (CWE) ID assignment.

For every CVE in NIST's NVD, it attempts to assign a CWE. When the vulnerability contains insufficient information to assign any specific CWE, then NIST assigns NVD-CWE-noinfo. Basically, "this CVE has insufficient details for us to know what the weakness is."

Back in 2015, NIST assigned NVD-CWE-noinfo to only a few Microsoft CVEs. In 2022, the majority of Microsoft CVEs received the NVD-CWE-noinfo designation.

    

Source: Jacob Baines

NIST's effort to assign CWE to each CVE helps with vulnerability prioritization and makes it easier to map vulnerabilities to CAPEC and/or MITRE ATT&CK. NVD CWE are used by a host of downstream projects, including MITRE's own CWE Top 25. Recent Microsoft vulnerabilities are largely excluded from these activities, because Microsoft has chosen to provide insufficient information to even assign a CWE to its vulnerabilities.

Unfortunately, it's not as if the information can be found in the Microsoft advisory itself, either. In fact, practitioners need to refer to outside sources, because Microsoft doesn't keep its advisories up to date. For example, both CVE-2022-41080 and CVE-2019-1388 were added to the Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities Catalog in 2023. Microsoft's NVD entries correctly reflect that. But both Microsoft advisories state that the vulnerabilities haven't been "exploited." That's because its advisories only reflect exploitation at the time of publication.

**Microsoft Advisory Exploitability Table for CVE-2019-1388**

    

The result is that Microsoft's advisory is both out of date and lacks information. The NVD entry is up to date, but also lacks information. Thankfully, there are a host of third parties trying to plug the information gap. For example, Zero Day Initiative publishes a rundown of every Patch Tuesday. This is its description of CVE-2023-21554 (aka QueueJumper):

_This is a CVSS 9.8 bug and receives Microsoft's highest exploitability rating. It allows a remote, unauthenticated attacker to run their code with elevated privileges on affected servers with the Message Queuing service enabled. This service is disabled by default but is commonly used by many contact center applications. It listens to TCP port 1801 by default, so blocking this at the perimeter would prevent external attacks. However, it's not clear what impact this may have on operations. Your best option is to test and deploy the update._

This description contains important information that the CVE entry does not, such as:

1\. Message Queuing is a service.

2\. Message Queuing is disabled by default.

3\. Message Queuing listens on TCP port 1801.

4\. Exploitation may result in elevated privileges.

All of that is incredibly useful for defenders — information that should have appeared in the CVE dictionary and the NVD entry, but doesn't. This is information that belongs in the CVE catalog for context, vulnerability prioritization, and historical safekeeping. Instead, already time-constrained defenders are put at a disadvantage because they're forced to go hunting for third-party descriptions of every Microsoft vulnerability.

**Conclusion

Microsoft's Patch Tuesday is almost old enough to drink, but that isn't reflected in the maturity of the program. A predictable patch cadence is nice, but the associated information produced by Microsoft is bad and has been trending that way for years. Microsoft can do much more, and it owes the community as much. Eight-word vulnerability descriptions should not and cannot be the norm.

**

Microsoft Advisories Are Getting Worse

US Transportation Security Agency (TSA) administrator reflects on how the Colonial Pipeline incident has moved the needle in public-private cooperation.

In the wake of the ransomware attack on the Colonial Pipeline, the US Transportation Security Agency — the agency that regulates pipelines as well as air travel, railways, highways, and mass transit systems — brought together the CEOs of more than two dozen critical pipeline operators for a top-secret briefing in the White House.

The TSA planned to hand down security directives to drive pipeline operators to enhance security, and they knew those companies' CISOs would have to ask their CEOs for more resources and higher priority, David Pekoske, administrator of the Transportation Security Administration, told attendees at the Hack the Capitol conference in McLean, Va. on May 11.

During that meeting, the TSA and other administration officials outlined the threat to critical infrastructure and why the pipeline operators needed to work with the government to make pipeline operations more resilient, he said.

"We knew we were going to be asking a lot of the industry — we want the CEOs themselves to see what the threat was, or see why we were so concerned about this," Pekoske said. "I would label that as an absolute best practice, because that really paved the way for rapid implementation and really paved the way for continued top-level communications between myself and those CEOs."

The TSA took the same approach to each of its critical infrastructure sectors as well, which resulted in creating a better approach to implementing a concept to which the government has repeatedly referenced for more than a decade: The public-private partnership. Along with cybersecurity experts at the Joint Cyber Defense Collaborative (JCDC) and government officials with the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), the TSA worked with critical-infrastructure operators and industrial control systems partners to adapt its approach to cybersecurity, Pekoske told attendees.

"We have pivoted over the course of these two years to become, in our view, even more effective in cybersecurity with our partners in the transportation sector," he said. The goal is to "build resiliency within that infrastructure sector, so that if attacked, the services that the critical infrastructure sector provides could come back online quickly."

**Performance, Not Prescription**

Following the Colonial Pipeline attack, the TSA initially focused on prescribing specific cybersecurity measures, but quickly realized — after listening to industry feedback — that if the agency maintained that approach, the technology would change in the next 12 to 18 months, leaving their recommendations outdated.

"We can't turn the crank on the regulatory process within that time frame," he said. "So instead, we've gone into this performance-based model, which is something that the national cyber strategy calls for and is really, I think, the way to go."

The performance-based model requires that specific outcomes be achieved, including focusing on resiliency, creating a cybersecurity implementation plan, establishing regular cyber assessments, and creating a plan for response, Pekoske said.

**Cyber Resiliency Requires Collaboration**

Working with industry, meeting with cybersecurity teams and executives, and understanding their business concerns are all critical to creating a resilient cyber infrastructure, he told Hack the Capitol attendees.

"To me, success as the administrator is when something's really bothering a CEO, that person feels like they can call me and just say, 'Hey, I'm hearing this, I'm really concerned about it. Can you help me out here?'" he said. "As a taxpayer, that's kind of really what I think ought to happen in government ... you can always make 10 or 15 minutes, particularly for somebody who's running a critical piece of our national infrastructure."

Source

DARKReading