bwatters-r7 (198)

Note: While this is an authenticated exploit, CVE-2024-5910 affects the same versions and allows an attacker to reset the admin password to allow authentication.
This vulnerability allows attackers to execute commands on a Palo Alto Expedition web server. The vulnerability is the result of poor sanitization of the start_time parameter when creating a cron_job. By appending a semicolon to the start_time parameter in the web request, a user can then add a command to be executed as www-data.
The attack is somewhat limited by the size of the command, but at ~90 bytes, it is still plenty to use for an attack, especially since the attack is repeatable.
Mitigations:
Given that this appears paired with other exploits (see https://www.horizon3.ai/attack-research/disclosures/palo-alto-expedition-from-n-day-to-full-compromise), patching everything is strongly recommended.
It is possible to limit access through firewall settings and NIDS, but both of those would take far longer and be more difficult than simply patching the affected systems.

Note: While this is a “just” password reset attack, there are authenticated vulnerabilities in the same product versions, including CVE-2024-9464, CVE-2024-9465, and CVE-2024-9466 that are available after the password is reset.
This is a vulnerability in the password reset of the Palo Alto Expedition web server, and is disturbingly simple. The password reset script is located in the /var/www/html directory, so it can be launched with the command curl -k 'https://<host>/OS/startup/restore/restoreAdmin.php'
That resets the admin password to the default paloalto
It is important to know this vulnerability can be paired with CVE-2024-9464, an authenticated command-injection vulnerability in Palo Alto Expedition. Attackers can reset the password using CVE-20245910, then use the credentials to exploit CVE-2024-9464.

This affects Expedition versions 1.2 up to 1.2.92; 1.2.92 is patched.
There ill be an obvious indications of compromise in that the admin password is changed.
Non-patching mitigations are unfortunately slim and rely on limiting access to trusted people, but that may not be an option in most cases. Setting up network based rules to prevent the request would likely work, but probably be as difficult and less reliable than patching to an unaffected version.

CVE-2024-6327 is a critical unauthenticated deserialization vulnerability within Progress Telerik Report Server before 10.1.24.709. This vulnerability comes shortly after the similar CVE-2024-1800 was announced and in tandem with CVE-2024-6096. CVE-2024-6096 also affects versions prior to 10.1.24.709. No in-depth description, PoC, or exploitation in the wild has been reported, though given the description and popularity of the software, I expect there will be more information incoming soon.
Telerik has published a good article with some details and mitigation suggestions to prevent attacks until users have time to patch.
You can find it here: https://docs.telerik.com/report-server/knowledge-base/deserialization-vulnerability-cve-2024-6327.
The mitigation itself is to ensure the user for the Report Server Application has limited permissions, and the documentation for setting that up can be found here: https://docs.telerik.com/report-server/knowledge-base/how-to-change-report-server-iis-user

CVE-2024-5217 is an unauthenticated vulnerability in the input validation checks for GlideExpression scripts that results in remote code execution. It is unclear, but I expect that the vulnerability allows an unauthenticated user to provide a GlideExpression script that contains malicious commands that bypass available sanitization and result in code execution on the server.
ServiceNow’s release versioning is non-canonical, so determining if your release is vulnerable is non-trivial. Patched Versions are
Utah
Patch 10 Hot Fix 3
Patch 10a Hot Fix 2
Patch 10b Hot Fix 1
Vancouver
Patch 6 Hot Fix 2
Patch 7 Hot Fix 3b
Patch 8 Hot Fix 4
Patch 9 Hot Fix 1
Patch 10
Washington
Patch 1 Hot Fix 3b
Patch 2 Hot Fix 2
Patch 3 Hot Fix 2
Patch 4
Patch 5

These releases are similar, but not the same as CVE-2024-4879, another input validation vulnerability resulting in unauthenticated RCE. Several other less critical vulnerabilities with similar number have been released. CVE-2024-4879 and CVE-2024-5217 are the most critical in the batch release, and both have been reported as being exploited in the wild with low technical expertise required.

CVE-2024-4879 is a Jelly Template injection vulnerability in ServiceNow resulting from incomplete input validation. ServiceNow’s release cycle is not numbered, but named after states and with non-canonical minor version, so determining vulnerability is somewhat more difficult.
Utah versions that are patched:
Patch 10 and hot Fix 3
Patch 10a and Hot Fix 2
Vancouver versions that are patched are:
Patch 6 Hotfix 2
Patch 7 Hotfix 3b
Patch 8 Hotfix 4
Patch 9
Patch 10
Washington releases that are patched:
Patch 1Hotfix 2b
Patch 2 Hotfix 2
Patch 3 Hotfix 1
Patch 4

Jelly templates are configuration files used by the ServiceNow system; input validation for data into the file is insufficient, allowing an unauthenticated attacker to alter the Jelly Template file to gain code execution. This vulnerability was patched July 10, but as of this week, there are still reports of numerous internet-facing hosts vulnerable to this exploit with other outlets claiming that the vulnerability is being actively exploited in the wild. It is additionally complicated by the near simultaneous release of CVE-2024-5217, which has a similar vulnerability landscape, but a different vulnerability path.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1645154
https://www.imperva.com/blog/imperva-customers-protected-against-critical-servicenow-vulnerability/
https://www.linhttps://www.darkreading.com/cloud-security/patchnow-servicenow-critical-rce-bugs-active-exploitkedin.com/pulse/cve-2024-4879-cve-2024-5217-exposed-risks-rce-servicenow-nfmtc

This vulnerability is highly technical in that it is closer to a jailbreak than a traditional exploit. The Cisco Nexus switches affected by this exploit:
MDS 9000 Series Multilayer Switches, Nexus 3000, 6000, 7000, 9000 series Switches, and the Nexus 5500 and 5600 Series Platform switches all run a modified version of the Linux Kernel that is abstracted to prevent a user from accessing underlying OS commands not required for switching operation.
CVE-2024-20399 allows an attacker to break through this abstraction layer to issue OS commands directly to the Linux Kernel, allowing the attacker full control of the switch’s underlying operating system.
Through this access, attackers can install implants, routes, or other malicious configuration settings to the switch beyond the standard Cisco command interface, possibly bypassing some logging.
Although possession of such access to a critical and wide-ranging device like a Nexus switch is a powerful tool to an attacker, the advantage this gains is marginal as it required administrative-level credentials to implement the exploit.
Standard controls are recommended to mitigate this attack- certainly, patching is important, but relatively few individuals in an organization require administrative access to Nexus-type switches, and their size and criticality to business uptime preclude them from frequent changes. Limiting the number of individuals with access and logging/alerting to login events on them would not create an undue burden in most cases.

CVE-2023-36874 is a filesystem redirection vulnerability that relies on a trusted process using relative filepath data and poor file validation to allow a malicious actor to escalate privilege on Windows 10 hosts.

How it is supposed to work

The Windows Error Reporting Service (WER) is a privileged (SYSTEM) process that handles errors on Windows systems. It is not meant for user interaction, so many of the ways to interact with it are undocumented COM interfaces.
Through a non-trivial set of calls to COM objects, a user can create an IWerReport COM object. Once the user has that object, they can make a call to submit a report file associated with that object. The file must be located in %PROGRAMDATA%\Microsoft\Windows\WER\ReportArchive\<reportdir>\.
As part of the report submission process, the WER service calls CreateProcess and passes it the executable responsible for handling the WER report, %WINDIR%\system32\wermgr.exe. This results in the wermgr.exe process launching as SYSTEM and handling the reporting.

The Vulnerability

There are two issues at play fort his vulnerability: one is that rather than using the absolute filepath to the wermgr.exe file as above, the CreateProcess function is handed a relative filepath to the wermgr.exe executable based on the location of the error report, so the WER service launches ..\..\..\..\..\..\system32\wermgr.exe with the origination directory as the directory containing the WER report to submit, and the second is that neither file is checked for a symbolic link before it is opened.
That means that a user can:

1. Create a WER report in C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\Report.wer
   
2. Place any executable in C:\arbitrary_dir\system32\ named wermgr.exe
   
3. Create a symbolic link between C:\ProgramData\Microsoft\Windows\WER\ReportArchive\<reportdir>\ and C:\arbitrary_dir\ProgramData\Microsoft\Windows\WER\ReportArchive\Report\<report_dir>\
   
4. Create the IWerReport COM object
   
5. Submit the COM object paired with the report in C:\ProgramData\Microsoft\Windows\WER\ReportArchive\<reportdir>\
   This results in ..\..\..\..\..\..\system32\wermgr.exe being opened as system, and as the symlink created a redirect, it will launch whatever executable we have stored as C:\arbitrary_dir\system32\wermgr.exe
   

Mitigation

Microsoft released a patch for this vulnerability, so the first suggestion is to patch. Alternatively and additionally, because this vulnerability requires an executable file named wermgr.exe and a report named Report.wer, a host-based protection might be simply to ensure that any file named wermgr.exeoutside the legitimate%WINDIR%\system32directory flagged and quarantined. The same tactic could be applied to theReport.werfiles outside the proper structure. Another option might be to prevent symbolic link calls withsystem32` as a directory destination.

CVE-2023-38146, A.K.A. Themebleed was discovered by Gabe Kirkpatrick and is a time-of-check-to-time-of-use dll hijacking vulnerability with a slight twist. Windows 11 Versions 21H2 and 22H2 are vulnerable.

The vulnerability works because under a specific set of circumstances, opening a theme file will cause a dll that is improperly checked to be loaded and run in the context of the user who opened the theme file.

Background

Windows .theme files are simple text files that reference Windows .msstyles files. .msstyles files are just fancy .dll files that contain resources for the theme like icons. While .msstyles files are PE files and follow the .dll format, they should not contain executable code.

Vulnerability

If a .theme file references an .msstyles file with a PACKME_VERSION of 999, a special code branch of code is taken during the loading process and a it causes the process to attempt a call to a function contained in an accompanying .dll file. That second dll will have the same path and name as the .msstyles file, but will be appended with _vrt.dll. To be safe, that new dll is checked to ensure that it is a signed Microsoft .dll before it is loaded and the exported function is called.

The vulnerability lies in the improper verification of that .dll file. The verification and loading are two atomic actions: first the file is opened for reading and verified, then the file is opened for execution and loaded. If a malicious actor can separate the file open action for verification and file open action for execution, they can make it so that a legitimate .dll is used for verification and then a malicious .dll for execution.

One way that an attacker can control the files is by using a UNC path in the .theme file that points to an .msstyles file on an SMB server that the attacker controls. If the hosted .msstyles file has a PACKME_VERSION value of 999, then the theme loader will attempt to call a function contained in a .dll file on the same share. An SMB server must know the requested file actions to enforce permissions, so the action desired by the client is contained within the request to the SMB server. This allows the attacker to serve a legitimate, signed .dll when it receives a read request for the file, but a malicious .dll when it receives a request to open the same file for execution.

Further, the person who discovered the vulnerability also found that by converting the theme file into a cab file and naming it with the .themepack extension, the file will no longer appear as a downloaded file, and the user will not be prompted with a warning when they open it.

Mitigation

Microsoft patched this vulnerability by removing support for PACKME_VERSION 999. It is recommended that you patch, but because this is a very precise vulnerability with many parts, several options exist for mitigation in addition to patching. At a host filesystem level, mitigation for this exploit would be to alert and stop any open file request to files that end in _vrt.dll or at a network level, stop and alert on any SMB connections that request files ending in _vrt.dll. It is also likely safe for many environments to prevent any SMB requests outside the enterprise entirely, or even better, limit SMB connections to specific resources within the enterprise.

I saw this vulnerability and dug a bit because it is an improper fix to CVE-2016-5118, which was a big deal and I wanted to know what was missed. To be clear, this vulnerability is not a big deal. Where CVE-2016-5118 was vulnerable in a default configuration, this vulnerability requires a non-default, purposefully-vulnerable configuration. The maintainers for the project went so far as to revert the community-provided fix for this vulnerability claiming the behavior was a poorly-documented feature. From the issue on ImageMagick (https://github.com/ImageMagick/ImageMagick/issues/6339):

When --enable-pipes is used the user opens themselves up to a potential security risk when they don't filter the input. And you don't even need to use back ticks. It is also possible to do this magick '|cat test.txt > /tmp/leak|< logo.jpg' info: when the user of our library enables this option. And as we said before this option is not enabled by default but we should make it more clear what could happen when the user of our library enables this option.

This is not particularly surprising; enabling pipes in an application like this increases the complexity and makes proper sanitization much more difficult. Users should ensure that the application does not have this vulnerable option turned on.

EDIT: This was a quick description, and while it is still accurate as far as I know, A Rapid7 Evaluation with greater analysis has been published here: https://attackerkb.com/topics/Z0pUwH0BFV/cve-2022-30190/rapid7-analysis

This is a relatively new vulnerability in the Microsoft Support Diagnostic Tool Vulnerability, so it is likely more information will come out in the coming days.
Currently, as seen in the wild, this vulnerability is embedded in a word document and likely distributed with a *.rar file. When the Word document is opened, it reaches out and downloads an HTML file which has a JS section to implement the ms-msdt (Microsoft Support Diagnostic Tool Vulnerability) protocol which is then coerced into launching a command.
As reported by Jake Williams in a thread here: https://twitter.com/MalwareJake/status/1531019243411623939, the command opens the accomplanying *.rar file and pulls a base64 encoded *.cab file from it, then expands the *cab file and runs a file contained in the cab file called rgb.exe THIS FILENAME IS LIKELY MUTABLE, SO I DO NOT RECCOMMEND POLICING FOR IT WITHOUT OTHER RULES.
Microsoft has already published mitigation techniques for this exploit: https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
Users are required to delete a single registry key called HKEY_CLASSES_ROOT\ms-msdt though there is little discussion about the side effects of this operation. In his thread, Jake Williams has verified that the removal of this key prevents execution of the embedded payload.
Further reading:
https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e
Untested and unverified PoC: https://github.com/chvancooten/follina.py/blob/main/follina.py
https://www.scythe.io/library/breaking-follina-msdt-vulnerability

UPDATE: I adjusted the attacker value up in light of reports by Kevin Beaumont that if the attacker uses an RTF file as the host, then the exploit code will run just viewing the file in the preview pane with explorer.exe. (details here: https://github.com/JMousqueton/PoC-CVE-2022-30190 and the above doublepulsar blog post)

Polkit’s pkexec binary is a bit like sudo in that it allows users to run an application as another user.
For instance, when you run something like pkexec ls you’ll be prompted for the root user’s password.
Because it allows elevated launching of programs, pkexec runs as root.

Processes that run like this are considered special and are run in a Secure-execution mode, which causes
the dynamic linker (ld.so) to strip out problematic environment variables that could introduce security
concerns. One of these “untrusted” environment variables stripped out by the linker is GCONV_PATH, which
sets the location for text conversion libraries. If a binary needs to convert a text string to a different
encoding, it will load/execute the library specified by GCONV_PATH.

For example, if we could get pkexec to run with the environment string GCONV_PATH=./exploit, pkexec would
load and execute the exploit as root if we were able to coerce the binary to use an unknown charset. This
is why the dynamic linker prevents such an environment variable from being passed into secure-execution mode
binaries.

The check to prevent GCONV_PATH environment variables is done when a program loads, so if we can modify
the environment variables after the program loads, we could add it, but as the process runs as root, we
could not change those values ourselves.

This is where the logic flaw in pkexec can be abused. pkexec runs through each argument it is passed and
calls g_find_program_in_path which takes a filename and replaces the filename with the full path to the
file, according to its PATH environment. Since there can be multiple binaries, this is done within a
loop. The specific bug in pkexec is that the loop will always run at least once, even if the number of
arguments is 0.

If the number of arguments is 0, then it will still attempt to resolve the element it pulls from memory
at the location the first argument would have been located. Because of how the stack is structured,
environment variables are located right after argument values in memory, so if there are no argument values,
then the environment values are there. The exploit works by coercing g_find_program_in_path into
writing GCONV_PATH=./exploit into the first slot in the environment list.

We can do this by creating a folder in the PATH called GCONV_PATH=. and within that folder, place a
file named abc. We also add the directory GCONV_PATH to the PATH environment variable. Now, when
we launch pkexec without any arguments, but with abc as the first environment variable and PATH=GCONV_PATH=
as the second, g_find_program_in_path will look for abc in the folder GCONV_PATH=. and find it.
It will then overwrite the first environment variable with the full path to the file as it exists in
our PATH: GCONV_PATH=./abc or exactly what we’d like to have as our environment variable.
Now, if we can coerce pkexec to use an unknown charset, it will load the library ./abc.so which we’ll make
the name of our payload.

We can coerce the loading of the .so by adding another environment variable declaring some unknown
charset: CHARSET=garbage would work fine if we could get pkexec to need to write a log. We can
get it to write a log by giving a bad value for something it depends on. In our case, we’re using
the SHELL environment variable.

So, to sum up, if we give pkexec a bad value for the SHELL environment variable and an unknown charset
to encode, it will load the .so file specified by GCONV_PATH and run it as root in an attempt to
encode to the unknown charset.

To break it down, we need to place a .so payload binary in our current working directory called
abc.so and call pkexec with no arguments and the environment values:
abc
PATH=GCONV_PATH=.
SHELL=/garbage
CHARSET=garbage

Once g_find_program_in_path runs, the environment variables will be changed to:
GCONV_PATH=./abc.so
PATH=GCONV_PATH=.
SHELL=/garbage
CHARSET=garbage

The result will be that pkexec errors while trying to encode test to the non-existant charset, causing it to
load the provided abc.so file in the root context.

This vulnerability is generally believed to be present in the Ubuntu Releases from 14.04 to 20.10 LTS. There is some indication in the Debian security tracker that Debian version 10 (AKA Buster) is also vulnerable, but I have not verified this independently.

The vulnerability is based in the implementation of overlayfs inside the Ubuntu Kernel. Overlayfs sets the attributes of a process using a call to vfs_setxattr, but the data within that call should be verified by a prior call to cap_convert_nscap. Ubuntu’s implementation of overlayfs does not make that call for validation, and instead sends the request on to the file system without any check. This means an attacker can set their own permission levels by using overlayfs to make the request.
This vulnerability was corrected by simply adding the verification call to cap_convert_nscap into the vfs_setxattr function code, preventing the ability to call one without the other.
Ubuntu is ranked 6th on distrowatch right now, and is one of the more popular Linux-based operating systems. It is very likely to find an Ubuntu system in enterprise settings, and worse yet, they tend to be ad-hoc systems with little maintenance or oversight, so unlikely to be patched.
As this is a local vulnerability in the kernel itself, patching is required for mitigation. Use apt to upgrade your kernel to an unaffected version.

There exists a race condition bug in the Windows Installer. Specifically, the Windows installer maintains a rollback script of tasks to be performed in the event that an installation fails. If an installation fails, that rollback script will be run as system. By overwriting that script and placing an instruction to overwrite a specific DLL within that script, an attacker can overwrite a trusted DLL. One bright spot is that the default policy for Windows server prevents non-admins from performing installations, blocking this path for elevation.
In the original write-up by SandboxEscaper, the exploit required GUI interaction, but later PoCs released negated the requirement for clicking on pop-up windows.
Microsoft as attempted to patch this exploit on several occasions, but several patches proved to be incomplete, failing to account for file junctions or other bypass techniques. CVEs issued to bypasses include:
CVE-2021-1727
CVE-2020-16902
CVE-2020-0814
CVE-2020-1302
Links:
https://www.exploit-db.com/exploits/46916
https://ssd-disclosure.com/ssd-advisory-windows-installer-elevation-of-privileges-vulnerability/
https://halove23.blogspot.com/2020/12/oh-so-you-have-antivirus-nameevery-bug.html
https://github.com/klinix5/CVE-2021-1727

This entry is based off the blackhat talk by Zhiniang Peng, Xuefeng Li, and Lewis Lee on August 4, 2021.

They said CVE-2021-24088, 24077, and 1722 were all similar, but only described 24088.
For 24088, there’s a bug in EnumJobsInLocalQueue where the user submits a buffer and job size. Because the buffer used in this case has metadata written to the top of the buffer and strings written to the bottom of the buffer, the buffer functionally grows toward the middle (AKA itself). There bug is in the check to ensure proper size of the buffer so that it does not cause an overwrite of the string data to the metadata, but that check is vulnerable to an integer overflow (I am not sure of the exact cause). Because the check can be bypassed using the integer overflow, it means someone can arbitrarily write data in the form of a string to the meta data section, or even underflow the address and write arbitrary data to adjacent heap allocations.
Because the nature of the exploit, being able to write arbitrary data to the heap could result in code execution, but as I have not seen a PoC that goes through all the steps, I’m unable to say definitively how easy the exploit is to create or run or what the attacker value is. Mitigations are as always, patch, and/or disable the spooler service on devices that do not need it.

This attack is super useful to gain privileged access to an Exchange server. Given the ubiquity of the target, it’s remote nature, the presence of a simple python PoC, and the benefits from gaining privileged access to a mail server, hackers will be reaching for this exploit frequently, even if it does require authentication.
Further complicating matters is that the requests themselves are through https, so standard deployment for NIDS likely will not catch the attack. If you’ve added certificates to your NIDS to decrypt traffic, then it might catch the attack, but that scenario is not particularly common, especially in small to midsize organizations.
Patching is the primary method for mitigating this attack, though the logs left afterward (if they are not destroyed) are straightforward and reviewed in the technical analysis here: https://attackerkb.com/topics/taeSMPFD8J/cve-2021-24085?#rapid7-analysis

This remains a spectacularly new vulnerability with little documentation associated with it beyond Microsoft’s blog here: https://msrc-blog.microsoft.com/2021/02/09/multiple-security-updates-affecting-tcp-ip/
In the blog, this is a remote code execution vulnerability reported as associated with IPv6 packet reassembly. According to the vulnerability report here: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24094, there is a patch, and you can create a firewall rule on Windows host-based firewalls to block an attack with the command Netsh int ipv6 set global reassemblylimit=0 to block packet reassembly. THIS MAY AFFECT SOME NETWORK TRAFFIC.
A second denial of service vulnerability (CVE-2021-24086) also associated with IPv6 fragment reassembly is mitigated with the same command.
As pure speculation, this vulnerability might be associated with memory corruption through improper length reporting, such that when packets are reassembled in memory, they are placed in a buffer of insufficient size to store them. Should that be the case, this would most likely be a heap vulnerability, and like other heap vulnerabilities before it like eternalblue, bluekeep, and dejablue, it will be a real pain to get to work on a regular basis or as a worm-able exploit.

This remains a spectacularly new vulnerability with little documentation associated with it beyond Microsoft’s blog here: https://msrc-blog.microsoft.com/2021/02/09/multiple-security-updates-affecting-tcp-ip/
In the blog, they report that this vulnerability is associated with IPv4 source routing, but the default blocks against source routing on Windows are not suffcient, as the default configuration allows a Windows system to process ICMP requests with source routing.
Reported as a remote code execution vulnerability, Microsoft claims that it will likely not be weaponized for that purpose quickly, though it might see a DoS exploit in the near-term.
There is a patch, but also, the mitigations provided in the guidance (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24074) involve the creation of a rule blocking source forwarding from the built-in firewall:
netsh int ipv4 set global sourceroutingbehavior=drop
Such a change in the firewall configuration can be deployed by group policy and would not require a reboot. The rule could also be deployed to infrastructure firewalls, but would then only protect against attacks that took place across the firewall; the rules would need to be set on all Windows system host-based firewalls to protect against lateral movement within a network.

PulseSecure version prior to 9.1.6 can be manually triggered to download and install an update. When this process is started, PulseSecure downloads the legitimate msi update file from the internet, verifies that the msi file is correct, then launches the Windows tool msiexec.exe to run the msi that was downloaded. By placing an oplock on the msiexec.exe file, an attacker can hold open the time between the file is verified and when it is run so that they can replace the downloaded msi after the verification takes place, but before the execution starts.

CVE-2020-0863 is an arbitrary file read vulnerability. During the course of execution, the Diagnostic Tracking service in Windows reads a set of configuration files from a user-controlled directory, and copies them to a directory readable to everyone. While it is not possible to change the location of the write, using an oplock and file junctions, an attacker can manipulate the source file, causing the service to copy a file from a privileged area to a location readable by everyone.
More information is available here: https://itm4n.github.io/cve-2020-0863-windows-diagtrack-info-disclo/