bwatters-r7 (180)

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/

This is one of a set of vulnerabilities from the Zero Day Initiative affecting VMWare products. This is the most significant and most valuable to attackers in my opinion as this affects ESXi servers which are difficult and sometimes impossible to patch, depending on the age and type of hardware. VMWare ESXi updates can be done through a VMWare vCenter server, but as those are not present in all environments, a complex, manual update may be necessary, assuming the update is compatible with the hardware. The lack of legacy support and possible manual nature of VMWare ESXi’s update process will likely increase the time-availability of this vulnerability for attackers, even in enterprise environments.
The exploit target is the OpenSLP service on port 427, open and running in a default configuration. Here is a UDP nmap scan of an affected server:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-20 13:05 CDT
Nmap scan report for server.redacted (xxx.xxx.xxx.xxx)
Host is up (0.00055s latency).
Not shown: 998 open|filtered ports
PORT    STATE  SERVICE
161/udp closed snmp
427/udp open   svrloc

Nmap done: 2 IP addresses (1 host up) scanned in 10.32 seconds

The service is vulnerable to a specially crafted packet that can cause a use-after-free allowing arbitrary code execution. It is important to note that in the VMWare advisory here (https://www.vmware.com/security/advisories/VMSA-2020-0023.html), they include impacted products other than ESXi, but those are for other vulnerabilities that are less severe. A good breakdown of the vulnerabilities is here: https://www.cybersecurity-help.cz/vdb/SB2020102044

I have not yet seen a PoC for this vulnerability, so it is difficult to comment on the exact difficulty for the exploit, but given the nature of ESXi servers as often critical infrastructure with access to login servers like Domain Controllers, their high uptime requirements, specialty operating system, and difficulty patching, even if the exploit were highly complex, it would still be worth it for a given attacker.

From my reading of https://h0mbre.github.io/atillk64_exploit, this reminds me a bit of heartbleed, though in addition to a read tool, this also allows for writing. . The atillk64.sys driver is vulnerable to abuse of a function that maps physical memory into a process’s virtual memory space. The relative gist of the vulnerability is that you can trick the driver into mapping kernel memory into your unprivileged process’s space to read or write. It reminds me of heartbleed because there’s some guesswork involved, and there is some searching required as an attacker will not know exactly what memory they want to map.
Mapping kernel memory into a arbitrary, unprivileged process is bad because fundamentally, all memory is kernel memory, and being able to change kernel memory allows someone to alter the function of the operating system.
In the case of the above blog, the author maps the kernel’s metadata for processes (the EPROCESS kernel structure) into a user-level process they control. In doing so, it allows them to copy the permission token from a high privileged process into their own low-privileged process, affecting a privilege escalation.
That’s not the limit to this particular exploit. There are a lot of valuable things that could be accessed and this could be easily converted to a code execution vulnerability by overwriting a memory block with executable code and then adjusting a driver dispatch table. Such an action would allow an attacker to patch in their own dispatch handlers. The authors did not do that because token stealing is simpler, easier, and there are far fewer protections against it than patching in code, but as a thought exercise, it is possible with this vulnerability.
Mitigations include updating the driver or removing it from your system. The vulnerable version is 5.11.9.0, so defenders can check to see if it is present on systems.

This vulnerability exists in the Windows Update Orchestrator service. A scheduling API call, ScheduleWork does not validate the caller’s permissions, but will schedule a task to be run as SYSTEM. It is present on all version of Windows 10 and Windows Server Core.
One protection that exists is that the binary scheduled for launch must be signed by Microsoft. Unfortunately, it appears you can bypass this restriction by passing an unsigned binary into the cmd.exe signed Windows binary as a parameter. The only other difficulty is that an attacker cannot schedule the execution, but the schedule is determined by the service, and will take place at a time when the scheduler believes the computer will be idle.
Mitigations to this might include checking all scheduled jobs for any files not in the system32 directory. The specific registry key for the jobs is located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler

More information and PoC code located here: https://github.com/irsl/CVE-2020-1313

This is a vulnerability in the MSI AmbientLink Version 1.0.0.8. The vulnerability allows a regular user access to a Windows device created by the msio driver provided for the MSI Ambientlink system.
The software device is vulnerable to a buffer overflow attack because it assumes that the received buffer will always be less than 48 bytes, apparently, even when longer lengths are specified by the IOCTL request.
Realistically, as this software runs LED lights on MSI gaming motherboards, it is unlikely to pose a large threat to corporate environments and instead, poses a larger threat to home users or individually-managed PCs, making the patching process significantly easier. I imagine it is also possible to simply remove the software temporarily.
See https://www.coresecurity.com/core-labs/advisories/msi-ambient-link-multiple-vulnerabilities for a more in-depth analysis and PoC code.

This is a print spooler vulnerability similar to CVE-2020-1048, but it uses a specially-crafted *.SHD to trigger a print to a trusted location. Introduced at Blackhat on August 6, 2020, a patch is expected to appear next week in Microsoft’s patch Tuesday.
The vulnerability does require low privilege access and for the spooler service to restart.
PoC will be uploaded to https://github.com/SafeBreach-Labs/spooler on August 12.
This is extremely valuable to attackers. The exploit is most likely present on all versions of Windows from Windows 7 to present and the race is now on to patch it while PoCs are already in the wild.

This is a dll hijack against Phillips SmartControl software that provides a privilege escalation. It requires an attacker to place a dll payload in a location writable to low-privilege user and having the user restart the application (or wait for a reboot). This would likely also be a good method for elevated persistence. As the software is likely not present in many enterprise settings and it requires user interaction or reboot, I think this has lower attacker value, but it would be very useful under those limited circumstances.
Mitigations might be as simple as creating dummy DLL files in the four locations created as SYSTEM or Administrator, preventing the attacker from a trivial low-privileges overwrite, adding the file locations to HIDS, or patching the software in question to something above 4.3.15