bwatters-r7 (81)

Last Login: June 02, 2020
Assessments
20
Score
81
6th Place

bwatters-r7's Contributions (22)

Sort by:
Filter by:
4
Ratings
Technical Analysis

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.

8
Ratings
Technical Analysis

OK, so to start off with, this is bad and you should patch. That said, to my understanding, it is completely disingenuous to say:
Attackers can exploit CVE-2020-1048 with a single PowerShell command:
Add-PrinterPort -Name c:\windows\system32\ualapi.dll

From a cursory read and some playing, I think the way this exploit works is by creating a printer (something regular users can do) and instead of giving it a port, give it a path. That means when it tries to write to the printer port, it finds a file and writes to it. That’s relatively straightforward, but significantly oversimplified. In the above example, we write to a location vulnerable to a dll hijack (C:\windows\system32\ualapi.dll) which is well-known and talked about here: https://enigma0x3.net/2019/07/24/cve-2019-13382-privilege-escalation-in-snagit/.

The novel trick here, like many recent exploits, is magic to get an arbitrary file write to a trusted location.

So to do that, you can use the above command, but you need to set up several steps first, and even then it won’t work as advertised. I really appreciate their work, but In the blog out right now (https://windows-internals.com/printdemon-cve-2020-1048/) the authors attempt to obfuscate to prevent script kiddies so much they miss the mark on assisting and explaining how the exploit works. They take you down so many false leads, it is like talking to a southerner, and after every direction you get, they say “but that’ll do ya no good.” To explain with brevity, run these commands in powershell:

Add-PrinterDriver -Name "Generic / Text Only"
Add-PrinterPort -Name "<whatever>"
Add-Printer -Name "PrintDemon" -DriverName "Generic / Text Only" -PortName "<whatever>"
"Hello World" |  Out-Printer -Name "PrintDemon"

Viola, you create a file with markup trash in it. If this were your payload, it would not run. Unless the authors are hiding something, you need to use the WindowsAPI to actually get a file without any sort of markup garbage in it.
So…. yes, you can write a useless file with that one command….. if you’ve already run several other commands?

There is a PoC, so it is serious, but this is not a single command to root backdoor. It is more like several thousand lines of code and some well-timed execution gets you a rooted backdoor.

10
Ratings
Technical Analysis

This is a complex and poorly-defined vulnerability.
Microsoft’s description from https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0668 is essentially useless:
“An elevation of privilege vulnerability exists in the way that the Windows Kernel handles objects in memory. An attacker who successfully exploited the vulnerability could execute code with elevated permissions. To exploit the vulnerability, a locally authenticated attacker could run a specially crafted application. “

There is little surprise that there exists some confusion about the vulnerability.

Contrary to the earlier poster, I do not believe that this is a System Orchestrator bug. I agree with https://packetstormsecurity.com/files/cve/CVE-2020-0668 and think the vulnerability is in the Remote Access Service. Part of the confusion is that the vulnerability is a file overwrite vulnerability, and many PoCs are leveraging a dll-hijacking vulnerability in the system orchestrator service to gain code execution after the trusted file write takes place.

The Remote Access Service runs as system and creates a log of its actions called RASTAPI.LOG. Once the RASTAPI.LOG reaches a defined size, the Remote Access Service copies RASTAPI.LOG to RASTAPI.OLD in the same directory.
The issue is twofold. First, the behavior of the Remote Access Service Tool API is defined by three registry keys:
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\EnableFileTracing
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\FileDirectory
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\new_size
These three registry keys allow a user to turn on the RASTAPI and configure the size and location of the log file. These registry keys are writable by a regular user.
The second issue is that the RAST service performs only a trivial check on the filesystem location of the RASTAPI.OLD destination. If an attacker creates a filesystem link between the old log destination (i.e. C:\users\user\temp\RASTAPI.OLD) and a trusted location (C:\windows\system32\badfile.dll), RASDIALER will copy the old log file to the linked location as the SYSTEM user. Because there is a file hijacking vulnerability in the System Orchestrator service, many PoCs use the location C:\Windows\System32\WindowsCoreDeviceInfo.dll, which does not exist in a default configuration, but System Orchestrator Service will load if it does exist,

The attack looks something like:
1) Gain lower-privileged access to a vulnerable target.
2) Create a dummy directory to hold files.
3) Mount the dummy directory to \RPC Control
3) Upload a dll payload
4) Create a link between \RPC Control\RASTAPI.LOG and the uploaded payload
5) Create a link between \RPC Control\RASTAPI.OLD and the destination location the attacker would like to write (in this example, C:\Windows\system32\WindowsCreDeviceInfo.dll)
6) Write the registry keys to turn on FileTracing, set the file directory to the dummy directory, and set the max file size to one byte less than the size of the payload,
7) Upload a configuration file for the rasdialer
8) Launch the rasdialer. When RAST service kicks off, it tries to write a log file to the directory specified in the registry, but it finds one already exists, and it is already full, so RAST service then copies the file to the “old” location that’s linked to the trusted location. The result is an arbitrary file write to a trusted location.
9) At this point, the overwrite is complete. PoC’s leverage the System Orchestrator service to get execution of the overwritten dll file by launching the system orchestrator.

Many PoC exploits leverage https://github.com/googleprojectzero/symboliclink-testing-tools which allow for the manipulation of symbolic links and mount points and also https://github.com/itm4n/UsoDllLoader to start the System Orchestrator service to launch the dll.

While the exploit is difficult, there are several PoC exes out there, and a metasploit module in progress, so I consider the exploitability relatively easy, though the exploit itself is difficult.

1
Ratings
Technical Analysis

This vulnerability was the Linux equivalent to Wanncry according to some journalists. It was not.
This vulnerability (AKA SambaCry) worked by writing a link library (.so file) to a linux host running Sama in such a way that samba then loaded it. On the face of it, this was a problem, but attackers had 2 large hurdles:

  1. Anonymous file creation had to be enabled and
  2. Attackers had to guess the right absolute path

In the first case, it is unlikely any enterprise will have anonymous file creation turned on, so immediately attackers are thwarted. In the second case, an attacker must guess the absolute path to the share as it is mounted on the remote computer. There are obvious guesses attackers could make, but nothing that was guaranteed. This was the classic example of a terrifying exploit mitigated by large caveats. Most common-sense approaches to SAMBA and SMB shared will mitigate this threat, namely not opening SMB/SAMBA shares to the internet, not allowing anonymous logins, and keeping software up to date.

1
Ratings
Technical Analysis

Security products are notorious targets for attack because for them to perform their function, they must be elevated, so gaining execution means immediate execution as a privileged user. This CVE was discovered along with four other vulnerabilities after an internal review by Trend Micro Security Research:
CVE-2020-8468
CVE-2020-8470
CVE-2020-8598
CVE-2020-8599

There is evidence that this CVE (8468) and 8467 have exploit candidates that were seen in the wild. At this time, there are no PoCs that I could discover.

Trend Micro defines this vulnerability as a “content validation escape.” That sounds like a specially-crafted config file, so mitigation may include looking for configuration files on filesystems, but that’s a stretch. Many aspects on this will likely have to wait until we see more information come out, but there is a patch, so that is a likely strong starting point.

2
Ratings
Technical Analysis

Security products are notorious targets for attack because for them to perform their function, they must be elevated, so gaining execution means immediate execution as a privileged user. This CVE was discovered along with four other vulnerabilities after an internal review by Trend Micro Security Research:
CVE-2020-8468
CVE-2020-8470
CVE-2020-8598
CVE-2020-8599
There is evidence that this CVE (8467) and 8468 have exploit candidates that were seen in the wild. At this time, there are no PoCs that I could discover.

This CVE (8467) is an attack against a migration tool in Apex One and OfficeScan XG. The exact details are very murky, so it is hard to say what the remote attack surface is or how difficult it is to exploit. We can make some guesses as Trend Micro is relatively popular and remains a trusted enterprise security product.

3
Ratings
Technical Analysis

This is another of the recent junction-dependent local privilege exploits that rely on tricking a trusted process to move a payload to a trusted location to be executed by a (possibly other) trusted process. These particular exploits work because many of the trusted binaries fail to evaluate symlinks prior to file moves. This particular exploit is slightly more difficult, as the timing for it is trickier than some of the other exploits in this style.
This particular exploit relies on the Background intelligent Transfer Service (BITS), a trusted service used for uploading and downloading files. BITS is a powerful service that downloads files and can pause, or adjust download speeds based on network state. To do so, it first downloads files to a temporary location and then moves them to the final location when the download is complete. In this case, the service impersonates the user who called it when creating the temporary file, but not on the final move.
To trigger this vulnerability, an attacker must call the BITS service to download a file to a location that represents a symlink to another area of the filesystem. While BITS is downloading to the temporary location, the attacker must insert a mountpoint and symlink to redirect future file queries for the temporary destination to a malicious file (typically a DLL) and for the final location to redirect to a trusted location (for example C:\windows\system32). BITS will then continue to write tot he original file, but when it completes the task, it performs the final copy not as the user who called it, but as SYSTEM. That means when the move is called, the attacker has changed the symlink to the temporary file to now point to the malicious file, and the destination directory now redirects to a trusted directory. When the final move is called, the malicious file is moved to the trusted location as SYSTEM. It the remains the attacker’s task to find something to execute the malicious file. There are several was to achieve that goal, as multiple trusted processes will blindly load dll files from the system32 directory. In the PoC I’m looking at now (https://itm4n.github.io/cve-2020-0787-windows-bits-eop/), the overwrite targets WindowsCoreDeviceInfo.dll, which is loaded by the Windows Session Orchestrator service into a system-privileged process, but other options exist.
Given the race conditions and junctions required, this is not a particularly easy exploit to develop, but PoCs exist, so defenders should be aware of the technique.
Basic mitigations might start with something as simple as checking for any strings shared with James Foreshaw’s symbolic link testing tools (https://github.com/googleprojectzero/symboliclink-testing-tools); the advantage being that it would trigger on many of the basic PoCs for this class of vulnerability as they import these libraries during compilation, and leave in the diagnostic strings. Further mitigations might be to monitor filesystems for the creation of junctions or symlinks to trusted locations.

1

Good catch on the vmware-vmx process; I’d assumed it would be high privilege!

3
Ratings
  • Attacker Value
    Low
  • Exploitability
    Medium
Technical Analysis

This is one of a set of vulnerabilities discovered in the AMD Radeon graphics drivers for VMWare workstation by Talos including DoS vulnerabilities CVE-2019-5124, CVE-2019-5147, CVE-2019-5146. 2019-5183 is important because it allows overwriting the vtable and causing arbitrary code execution on the host OS, ~likely as a privileged~ user under vmware-vmx.exe. The breakout allows an assailant to leave the Guest OS and enter the host OS.
While it poses a risk, many mitigating factors affect the utility of the vulnerability. This is a local exploit to the guest operating system, and thus requires previous access through another means. Talos performed coordinated disclosure, so this vulnerability is already patched, allowing a fast mitigation strategy. Further, given the limited and local nature of VMWare workstation, as well as the necessity for a specific driver to be in use, the reduced surface area for attackers decreases the return on investment to develop an attack which to my knowledge has not been seen in the wild, yet.
Bottom line is that this poses a risk and should be addressed, but it is not a scary, immediate risk. Continue to patch through patching cycles and add signatures to IDS systems, but unless you have a very aggressive threat model, this is not an immediate threat.

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

This appears to be a bug with the authentication of elliptical curve cryptographic certificates definitely related to file source authentication through signing and possibly channel communications; there are unsubstantiated rumors about RCE, though I don’t see a pathway for that beyond a MitM attack. This is going to serve primarily as a local privilege escalation tool because Microsoft OSs depend on file authentication and privileged execution in some instances to avoid a requirement for user authenticated elevation for execution. I am unclear on how difficult breaking into an established session might be, but certainly spoofed signed files would be useful to a hacker.
Of the two likely scenarios, local privilege escalation seems the most likely, with MitM attacks possible. This is likely not a wormable threat and will require some amount of time and effort on the part of the attacker. Nation-state-level players might abuse this by owning update servers or routers and serving clients malicious signed updates or other binaries, but that’s not a likely threat model for average person or even company. In addition to the personalized nature of the attack vector, I imagine the barrier to writing even a local exploit would be higher than most, as cryptography is hard.
This is interesting, it is bad, and it should be patched, but it is not at the level of something like eternalblue or even bluekeep, in my opinion. I think that it was reported by the NSA has caused a bit more attention to it than the vulnerability warrants, but since there is a path to exploitation and a simple patch out that should have little effect on users, you should patch immediately.

2
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

I played around trying to create a module for this, and it matches the original PoC put out by Polarbear. The way it works is that on a VM with the proper version of VMWare tools installed, you can run the repair operation and briefly, a trusted file in a trusted location (C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat) has permissions lowered. If an attacker can touch the file at the right time, they can maintain control over the file after the repair is over if the timing is right. The method to take that overwrite to SYSTEM is still as yet unreleased, as far as I can tell.

Defenders can watch for some obvious behaviors just in this process. The attacker has to run a specific command (msiexec /fa <installer file>), then while it is running, continually attempt to access a specific file (C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat), and once they control that file, they must include malicious code and somehow somehow run it resulting in a privilege escalation. Defenders can add this behavior to HIDS signatures as a stopgap.

This exploit relies on previous access, and results in further compromise of the VM. While important, there are challenges to get to a location that this exploit is useful, the required files represent a bottleneck on behavior, mitigations will not affect most users, the results are limited to the VM, and a patch is already out. Defenders should patch as soon as possible, and add mitigations quickly, but for this to be a problem, attackers must already have a foothold into the computer.

3
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very High
Technical Analysis

Patch, but don’t freak out.

3

Completely agree. Just like Brent, when I first saw the OMG!!!! Sudo bypass as easy as ‘-u’ I was super concerned, so I tried it out on a fairly stock Ubuntu, a popular Linux distro, and got:

> sudo -u -1 id
sudo: unknown user: -1
sudo: unable to initialize policy plugin
> sudo -u 4294967295 id
sudo: unknown user: 4294967295
sudo: unable to initialize policy plugin

Then I got to the penultimate line of the article I was reading where it said “Since the attack works in a specific use case scenario of the sudoers configuration file, it should not affect a large number of users.”

Come on, people; be honest. Put that line in your opening paragraph! Should you patch? Yes! Should you be concerned this has torn through your mostly stock servers? Nope. The hype this got was way disproportional to the threat. There are far more scary privilege escalations for Linux out there, and this one is pretty easy to patch.

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

This exploit is difficult to judge. Some exploitation scores for this vulnerability have been very high, and I understand why: This is a vulnerability on a typically externally facing, or universally-internally-facing service, but the service is optional. While certainly this is a priority to patch and mitigate, I find it hard to understand why a vulnerability on an optional service ranks as a 10/10 on vulnerability scores. That conclusion may be based on my ignorance of deployed Cisco products.
Edit

3
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This is a terrible situation for any development team. A hacker took over a server that managed webmin code and changed the code in a subtle way to allow them (or others) to execute commands as root on computers running Webmin. It took nearly a year and a half for the attack to be discovered and fixed.

4
Ratings
  • Attacker Value
    High
  • Exploitability
    Low
Technical Analysis

This vulnerability was discovered while researchers audited the RDP code from the previous vulnerability, Bluekeep. This vulnerability is likely going to be worse than Bluekeep, as it targets more modern operating systems. The saving grace with Dejablue, as with Bluekeep and even Eternalblue is the complexity of turning the vulnerability into a reliable exploit, as the attacker must successfully trigger the vulnerability, write to kernel memory and to user memory, then execute the code in kernel memory to locate and execute the code in user memory. Without question this is in the ability of nation states and probably even organized crime, but until a public version is released, this will be treated as a zero day by those attackers that posses it. I would be surprised to see a public version of this that works reliably across Windows kernel 10 releases for at least another six to eight weeks (October 2019).

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Technical Analysis

As exploits go, being able to serve payloads to all Dell computers in a subnet us a pretty useful tool. It would require DNS hijacking and other noisy things, but not everyone is checking networks for those attacks, and if they are, they might be doing it on a Dell.

2
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

This is very hard to quantify in any way given the lack of reporting on the internal workings. It is a Priv Esc that affects all recent versions of Windows, though, so it would be a concern. I have seen no PoC for it, though it was used in the wild.

3
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Low
Technical Analysis

This is a priv esc being used in the wild. It targets older versions of Windows, with part of the path to execution stopped in recent Workstation OS internal changes. If you are running the affected OS, you should patch and think about upgrading the OS to something released in the last decade.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Medium
Technical Analysis

This is a memory corruption vulnerability that allows an attacker to send a malformed HTTPS packet, which will then generate the corruption. At this time, there are no reports that the memory corruption will result in remote code execution, just a Denial of Service.

These switches are not Cisco’s flagship products, so distribution will be limited, though that also means they are likely to be in locations without robust IT support, and upgrading the software on a core switch can be daunting and may have unanticipated consequences to the configuration, especially for novices.

While the surface area for attack is limited, this will likely retain a longer shelf life. It requires that HTTPS be enabled on the switch, which should be done to prevent eavesdropping, anyway.

Mitigations are fairly straight-forward; it is not a great practice to allow access to critical infrastructure configuration ports from untrusted areas, you should not disable the HTTPS connections, and there is a patch available from Cisco.

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Technical Analysis

This is a local priv-esc 0-day, so there is no patch. It uses a taskmanager file to provide escalated privileges.

5
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very Low
Technical Analysis

It is a scary vuln, and you should patch immediately. As no PoC is out, don’t trust the patch entirely and limit exposure to critical systems.