bwatters-r7 (171)

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

There is a vulnerability in Teamviewer that will attempt to access a remote SMB site when a user visits a malicious website. Part of a smb handshake involves the exchange of credentials. The SMB handshake would contain the username and hashed password of the user. Attackers could redirect the connection with something like responder and/or store the hash for later cracking.
Affected versions are 8 -15.8.2; 15.8.3 is the first patched version. Administrators should patch immediately of attempt to disable SMB connections from local networks if possible.

EDIT: This is not a privilege escalation per se. This overwrites the dll and gains injection, but it relies on a second user with greater privileges to log in and kick off OneDrive.

This exploit was not granted a CVE, but it was patched by an automated patch rollout. Microsoft denied the CVE as the update will happen automatically (see [here]{https://labs.redyops.com/index.php/2020/04/27/onedrive-privilege-of-escalation/} for more information).
The exploit is a very simple dll hijacking vulnerability in the OneDrive executable. The onedrive executable will attempt to load a specific (and often non-existant) dll if a specific config file is present.
Specifically, Onedrive will load the dll C:\Qt\Qt-5.11.1\qml\QtQuick.2.7\qtquick2plugin.dll if the file C:\Qt\Qt-5.11.1\qml\QtQuick.2.7\qmldir with the following contents:

module QtQuick 
plugin qtquick2plugin 
classname QtQuick2Plugin 
typeinfo plugins.qmltypes 
designersupported

Onedrive will load this dll into its trusted process if a user interacts with OneDrive.

This exploit is already patched and has a published Defender signature, but the service does not have to be in-use or logged in for the exploit to work. In my testing, an unpatched Windows 10x64 1903 VM was vulnerable in the default configuration (apart from disabling defender).

Because this exploit is patched, automatically updated, and already has a signature for it, it will likely have a short shelf life in most locations, but it does provide an opportunity for exploitation of air-gapped or other system that does not talk to the internet.

This vulnerability came out recently and it is not only difficult to trigger, it also requires authentication and it would be unreliable and difficult to use for remote code execution. So to be clear, this is mostly just a very difficult way to sabotage a computer you’re already logged into. The top-level method to exploit this vulnerability is a race condition that results in a use-after-free bug. A write up exists here: https://0xeb-bp.github.io/blog/2020/05/12/cve-2020-1015-analysis.html I’m super happy that the blog authors come out immediately and recognize the scope and utility of this vulnerability:

This bug is likely not the most ideal candidate for a fully functioning and reliable exploit. Especially when taking in consideration other EoPs from the April 2020 security patches with an exploitability rating of 1.
Microsoft has classified this as a ‘2’ (https://www.microsoft.com/en-us/msrc/exploitability-index):
Microsoft analysis has shown that while exploit code could be created, an attacker would likely have difficulty creating the code, requiring expertise and/or sophisticated timing, and/or varied results when targeting the affected product. Moreover, Microsoft has not recently observed a trend of this type of vulnerability being actively exploited in the wild. This makes it a less attractive target for attackers. That said, customers who reviewed the security update and determined its applicability within their environment should still treat this as a material update. If they are prioritizing against other highly exploitable vulnerabilities, they could rank this lower in their deployment priority.

The exploit works because a critical code section was not properly defined during the deletion and freeing of a shared object in memory. A critical code section prevents other threads from accessing memory as it is being created and populated. Critical code sections increase runtime, but they secure objects in memory as they are being built. In this case, the critical code section takes place between the deletion and free of the object. It is possible to access the memory location after the contents are deleted, but before the contents are freed.

It is possible that an attacker can take advantage of the race condition and modify the data in the registrant structure:

struct registrant {
    // pointer to next
    next: usize,
    // pointer to prev
    prev: usize,
    // set to 1 after alloc
    count: u32, 
    // Flags
    flags: u32, 
    // handle we pass
    handle: usize, 
    // heap alloc which is size of service_name + 2 for null char
    service_name: usize,
    // sessionID
    session_id: u32,
    // unknown, might be two u16s
    unknown: u32,
}

While it may be possible to take over this structure and achieve RCE, the path is not immediately apparent, and according to Microsoft, it is likely unreliable.

Unfortunately, looking throught he PoC here (https://github.com/0xeb-bp/cve-2020-1015/blob/master/cve_2020_1015.cpp), I am unable to locate an action that would be “known evil” to allow blue team members to flag on it.