gwillcox-r7 (475)

Last Login: September 14, 2021
Assessments
191
Score
475
1st Place

gwillcox-r7's Contributions (199)

Sort by:
Filter by:
2
Ratings
Technical Analysis

Hmm so this is quite an interesting one. This is similar to CVE-2021-36963 and CVE-2021-38633, both of which are marked as low complexity for being exploited and which will likely get you SYSTEM access, however if you look at the advisory for this bug at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36955 it is the only one where the “Exploit Code Maturity” is marked as “Functional” in other words Microsoft has verified that code exists to exploit this vulnerability and it works under most scenarios.

Again this is still only local privilege escalation so this isn’t triggerable remotely, hence why the severity is high due to M.S saying this is easy to form an exploit for and the fact that functional exploit code exists according to M.S, however it isn’t Very High since you still need access to an account on the target to exploit this.

Given that this gives SYSTEM level code access and its not hard to make an exploit for it according to Microsoft I would patch this sooner rather than later along with CVE-2021-36963 and CVE-2021-38633. I am still investigating this deeper to figure out what was patched but here is the list of functions within clfs.sys that I believe were patched as part of fixing this bug:

00012	1c00299b4	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	1c0028824	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	0.990	62	61	Perfect match, same name
00013	1c0029d74	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	1c0028bdc	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	0.950	50	49	Perfect match, same name
00024	1c0031a68	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	1c00308c8	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	0.950	14	17	Perfect match, same name
00026	1c0032550	ClfsCreateLogFile	1c00313d0	ClfsCreateLogFile	0.910	169	164	Perfect match, same name
00025	1c0032420	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	1c0031290	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	0.870	17	20	Perfect match, same name
00047	1c004f3d8	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	1c004e238	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	0.740	41	46	Perfect match, same name

More details to come when I get the analysis finished some more.

So far that the function Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() was removed from the new build of clfs.sys, and also from the CClfsBaseFilePersisted::CreateContainer call where it was called from. Now it directly checks the return code from CClfsContainer::Create(_UNICODE_STRING &,unsigned __int64 const &,_CLFS_FILTER_CONTEXT const &,void * const,uchar,uchar &) to see if it returned the status code STATUS_PRIVILEGE_NOT_HELD whereas before it would check the return code of Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() for this status.

2
Ratings
Technical Analysis

Contrary to what the title says this is not a elevation of privilege vulnerability. As noted at https://halove23.blogspot.com/2021/09/zdi-21-1053-bypassing-windows-lock.html and at https://www.zerodayinitiative.com/advisories/ZDI-21-1053/ this is actually an authentication bypass vulnerability that allows one to bypass the Windows lockscreen by taking advantage of a URL link within the page.

This link appears when one tries to log into an Microsoft connected account and hits the “I Forgot My PIN” link, attempts to sign in to a Microsoft account with an invalid password, hits the back link that appears at the top left of the page, then at the sign on page, hits the question mark icon that appears next to “Sign in with a security key”,

This will display a dialog with the title “Sign in with security key” that has a URL link called “Learn how to set this up”. Clicking on this link after enabling Narrator shows that this link actually opens an “How do you want to open this?” prompt. However this prompt is hidden which is why Narrator is used to tell us which elements we are hovered over.

As mentioned in https://halove23.blogspot.com/2021/09/zdi-21-1053-bypassing-windows-lock.html, this can then be used to open Edge, and then via Edge open the Settings window, at which point we can then open Explorer, and finally open a command window where we can execute arbitrary commands.

The risk of this vulnerability overall is still somewhat low. Due to the number of steps which must be taken using soely Narrator, unless someone automates the key presses (something that is entirely possible) you will still have to do a lot of listening and keypressing to get the vulnerability to work, and any one listening in to you attacking the PC will likely find it rather odd what you are doing.

Additionally you only gain privileges as a local user. This vulnerability does not grant you permissions as a administrative user or any privileged user on the system, and whilst you can use other EOP vulnerabilities that take advantage of the NT AUTHORITY\Authenticated Users the user will be granted, you are still reliant on other EoP vulnerabilities not being patched on the target system for you to get SYSTEM level access.

Overall this is a medium-low severity bug with a high degree of exploitability.

1
Ratings
Technical Analysis

So this is a pretty interesting bug in the Linux Kernel from versions 5.7.x to 5.13-rc4. It occurs due to kernel/bpf/verifier.c having a function named adjust_scalar_min_max_vals which is responsible for adjusting the minimum and maximum values an eBPF register can represent, which is used as part of eBPF bounds tracking of registers to make sure that when users submit eBPF programs for the kernel to run, they don’t end up going out of bounds and leaking kernel memory or doing other nasty stuff.

adjust_scalar_min_max_vals has a few switch statements for various types of operations, such as BPF_AND, BPF_OR, BPF_SUB, etc. For the purpose of this we will focus just on the AND vulnerability but the OR vulnerability was also introduced at the same time, and the BPF_XOR vulnerability was introduced with 5.10-rc1 of the Linux kernel.

asdf
asdf
asdf
asdf
asdfasdfasdf
asdf
asdfasfd
asdf
asdfa
sfasdf
asdf
adsf
asfd
asfd
asdf
asfdasfd

I have rated the exploitation of this vulnerability as fairly difficult as whilst chompie1337 did push out a PoC for this bug which we have used to transform it into a Metasploit module, and this is fairly platform agnostic, the actual exploitation details involve a lot of fairly advanced concepts and many steps to get successful code execution to work.

That being said the value of this is high as pretty much any Linux system you can think of is going to have eBPF enabled unless they have explicitly disabled it via sudo sysctl kernel.unprivileged_bpf_disabled=1 which will prevent unprivileged users from being able to load eBPF programs. This setting however is not default and will need to be applied to each affected machine so I’d imagine some people will either not be aware of this, or will end up deploying machines and forget that this setting needs to be set at some point, opening up the door for exploitation of this and similar issues.

When executing BPF_AND’s switch code, as can be seen at https://github.com/torvalds/linux/blob/c9e73e3d2b1eb1ea7ff068e05007eec3bd8ef1c9/kernel/bpf/verifier.c#L7575-L7579, Of particular note is the call to scalar32_min_max_and and the lines at https://github.com/torvalds/linux/blob/c9e73e3d2b1eb1ea7ff068e05007eec3bd8ef1c9/kernel/bpf/verifier.c#L7083-L7093.

In this case the code will call tnum_subreg_is_const(src_reg->var_off); to check if the source register’s lower 32 bits are known, and tnum_subreg_is_const(dst_reg->var_off); to check if the destination register’s lower 32 bits are known. If both the source register’s lower 32 bits are known and the destination register’s lower 32 bits are known, then it assumes that scalar64_min_max_and will be called (it will) and that its safe to skip updating the registers for the known 32 bit values.

However here lies a problem, as if we look at scalar_min_max_and, which is the official name for scalar64_min_max_and, we see something odd in its code at https://github.com/torvalds/linux/blob/c9e73e3d2b1eb1ea7ff068e05007eec3bd8ef1c9/kernel/bpf/verifier.c#L7116-L7127. Specifically it uses tnum_is_const(src_reg->var_off); and tnum_is_const(dst_reg->var_off); to determine if the full contents of the 64 bit source and destination registers are known. Only if the full 64 bit content of the registers are known, does it then mark the destination register as having a known value.

This leads to an edge case where if the operation involves registers where the upper 32 bits are unknown but the lower 32 bits are known, then we can make eBPF improperly verify the register as the 32 bit version of the call will assume the 64 bit version of the call will have properly validated the register’s contents, however in reality the register will not be verified since its upper 32 bits are still unknown.

The patch fixes this by ensuring that scalar32_min_max_and and related affected functions now call __mark_reg32_known on the destination register before returning if the lower 32 bits of the destination and source registers are known. The contents of this function can be seen below:

/* Mark the unknown part of a register (variable offset or scalar  * value) as known to have the value @imm.
*/
static void __mark_reg32_known(struct bpf_reg_state *reg, u64 imm)
{
    reg->var_off = tnum_const_subreg(reg->var_off, imm);
    reg->s32_min_value = (s32)imm;
    reg->s32_max_value = (s32)imm;
    reg->u32_min_value = (u32)imm;
    reg->u32_max_value = (u32)imm;
}

Essentially this code will ensure that all the signed and unsigned minimum and maximum versions of the register are properly set, ensuring the correct bounds will be conserved when calling the final boundary updating functions are called to determine the 64 bit value, whereas before when calling the __update_reg_bounds, __reg_deduce_bounds and __reg_bound_offset functions within adjust_scalar_min_max_vals, a condition could occur whereby due to some internal logic on how to calculate these values, there could be a case where the bounds would be incorrectly determined.

More details on exactly how this is done can be found in the The Vulnerability section of chompie1337’s excellent paper at https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story, but suffice to say its possible to make a register with a maximum 32 bit value of 0 and a minimum 32 bit value of 1, thereby severely messing up the logic of the bounds tracker.

1

Please provide additional information for your rating where possible by adding a comment explaining why you decided to rate this as Medium specifically.

1

Considering other users considered this to be a higher risk vulnerability, please provide more details on why you think this is a low risk vulnerability for comparison.

2

Stating its rating (exploitability & attacker value) without providing additional details is not useful to end users. Please provide more details when creating future assessments as I’ve noticed you’ve provided similar one line assessments for at least 2-3 other vulnerabilities as well.

1

Expanding on this a bit but with https://us-cert.cisa.gov/ncas/alerts/aa21-209a it should be noted that heavy exploitation of this vulnerability was noted by CISA in 2020 by APT groups.

3
Ratings
Technical Analysis

Vulnerability is a WebContent->EL1 local privilege elevation vulnerability in Apple iOS and iPadOS prior to 14.7.1 that exploits a vulnerability in the IOMobileFramebufferLegacy::get_displayed_surface() function whereby an attacker can control a 32 bit value that is being used to index into an array in order to cause an out of bound read. This can then be used to read the port name of an IOSurface object. Once this information is obtained, the attacker can then use known read/write primitives within the IOSurface object to gain the arbitrary kernel read/write they need to elevate their privileges. More details can be found at https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/ along with a working PoC.

It should be noticed that Apple has supposedly stated this was exploited in the wild according to https://support.apple.com/en-us/HT212623 however from what I’ve heard Apple has stated jailbreak exploits were “exploited in the wild” and there are rumors that this was perhaps just used by people in private to jailbreak their phones, so I’d take Apple’s word with a slight grain of salt. That being said the impact should be considered the same regardless given the relative ease of exploitation of this vulnerability combined with the fact that a working PoC has now been published.

1

This is not an unauthenticated attack, and it requires local access, see https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/ and https://vuldb.com/?id.179674 for more info.

3
Technical Analysis

TLDR Version

  • size_t to int conversion vulnerability leading to an integer overflow in the Linux kernel’s filesystem layer.
  • Exploitable by creating, mounting, and deleting a deep directory structure whose total path length exceeds 1 GB.
  • Exploiting it allows an attacker to write the string //deleted to an offset of exactly -2GB-10B (-10B cause the length of //deleted is 10 bytes if you include the NULL terminator) below the beginning of a vmalloc() allocated kernel buffer.
  • Exploit the uncontrolled OOB write to obtain full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, Fedora 34 Workstation. Though with that being said other Linux distributions are vulnerable and likely exploitable.
  • Exploit requires about 5GB of memory and 1M inodes, and exploit will be published by Qualys sometime in near future according to their blog.
  • Vulnerability introduced in July 2014 (Linux 3.16) by commit 058504ed (“fs/seq_file: fallback to vmalloc allocation”), was fixed with https://github.com/torvalds/linux/commit/8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b in Linux kernel 5.13.4.

Preliminary Warning :)

This commentary may get a bit technical as that is my preferred style of writing so if you want the nutshell version take a look at @NinjaOperator or @wvu-r7’s reviews on this for a nutshell version or look at the TLDR section above if you need the pertinent details and aren’t interested in a deeper dive into this bug (you’ll miss out on some good info though :D) Alright, ready? Lets dive into this bug.

Exploit Background and Some History

So according to Qualys this bug was first introduced in July 2014 (Linux 3.16) by commit 058504ed (“fs/seq_file: fallback to vmalloc allocation”) which can be found at https://gitlab.raptorengineering.com/meklort/talos-obmc-linux/–/commit/058504edd02667eef8fac9be27ab3ea74332e9b4. This was when original kmalloc(m->size <<= 1, GFP_KERNEL); call was switched to a seq_buf_alloc(m->size <<= 1); call.

This is interesting as when we look at the earlier source code for kmalloc from say, version 3.15 of the Linux source code we find that the maximum size of memory that kmalloc can allocate is noted at https://elixir.bootlin.com/linux/v3.15/source/include/linux/slab.h#L455 as KMALLOC_MAX_CACHE_SIZE. This is defined at https://elixir.bootlin.com/linux/v3.15/source/include/linux/slab.h#L234 as #define KMALLOC_MAX_CACHE_SIZE (1UL << KMALLOC_SHIFT_HIGH) or the unsigned number 1 left shifted by KMALLOC_SHIFT_HIGH. KMALLOC_SHIFT_HIGH is defined multiple ways, depending on the backend allocator in use by the OS, but its either defined as a max of 25 (for SLAB allocators), PAGESHIFT, which is defined as 12 for x86/x64 systems, or PAGESHIFT+1 aka 13.

Or in other words to make a long story story, the maximum size that kmalloc() may allocate is 32 MB aka 1<<25. This is far below what can be represented by a 32 bit number. However when the kernel changed to calling seq_buf_alloc() it now calls vmalloc as can be seen at https://elixir.bootlin.com/linux/v3.16/source/fs/seq_file.c#L41, which does not have this same limitation and can allocate as much memory as it pleases. Which means that size could technically be a number that is larger than what can be represented by a signed 32 bit integer.

This leads us into the actual code itself, which I’ll explain below.

The Vulnerable Code Explanation

The Linux kernel has a seq_file interface that produces virtual files that contain sequences of records. Each record must fit into a seq_file buffer, whose size is increased as needed by doubling its size by freeing the existing allocation, and then doing a new seq_buf_alloc() call where the size is the previous size bit shifted left by 1, effectively doubling the size allocated. We can see this if we take a look at https://elixir.bootlin.com/linux/v5.13.3/source/fs/seq_file.c#L242, though the relevant parts of the code are shown below:

 168 ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 169 {
 170         struct seq_file *m = iocb->ki_filp->private_data;
 ...
 205         /* grab buffer if we didn't have one */
 206         if (!m->buf) {
 207                 m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
 ...
 210         }
 ...
 220         // get a non-empty record in the buffer
 ...
 223         while (1) {
 ...
 227                 err = m->op->show(m, p);
 ...
 236                 if (!seq_has_overflowed(m)) // got it
 237                         goto Fill;
 238                 // need a bigger buffer
 ...
 240                 kvfree(m->buf);
 ...
 242                 m->buf = seq_buf_alloc(m->size <<= 1);
 ...
 246         }

Note that the m is the seq_read_iter() function is a seq_file structure corresponding to the path to the virtual file that we are currently operating on. Anyway now that we have allocated memory the next question might be “well if we can control m->size, couldn’t we do an overflow here?” Well not really as Qualys notes cause either the allocation will fail, or you will run out of memory before you overflow m->size since it is of type size_t as noted at https://elixir.bootlin.com/linux/v5.13.3/source/include/linux/seq_file.h#L18.

The problem however is that m->size is actually used in functions that expect an int value, aka a signed 32 bit integer, not size_t, a 64 bit unsigned integer. Which leads us to the function show() at https://elixir.bootlin.com/linux/v5.13.3/source/fs/seq_file.c#L269, which according to Qualys ends up calling show_mountinfo().

You see show_mountinfo(), will end up calling seq_dentry(m, mnt->mnt_root, " \t\n\\"); as shown at https://elixir.bootlin.com/linux/v5.13.3/source/fs/proc_namespace.c#L150. Note that m here will be the seq_file object containing a buf pointer to the buffer we allocated earlier. seq_dentry() then gets the size of the allocate buffer that m->buf points to, aka the buffer we allocated earlier, and sets the local variable size to its size as can be seen at https://elixir.bootlin.com/linux/v5.13.3/source/fs/seq_file.c#L544. Note however that size is of type size_t, aka an unsigned 64 bit number

And this is where things go really wrong, as dentry_path(dentry, buf, size); is then called which leads to the code starting at https://elixir.bootlin.com/linux/v5.13.3/source/fs/d_path.c#L385. Note however that dentry_path expects its size argument to be an int, aka a signed 32 bit integer though, yet we passed it a size_t number. So if we allocated a buffer 2GB or greater, aka 2147483648 or greater, this would overflow the limits of a signed 32 bit integer, as signed 32 bit numbers can only represent numbers in the range -2147483648 to 2147483647. So in effect the number 2147483648 in size would be converted inside dentry_path to the value -2147483648. Woops!

This then leads to p = buf + buflen; pointing to the location of the allocated buffer, aka buf minus buflen which will now be -2147483648 assuming the that size was specified as 2GB aka 2147483648. So p will in effect point to a memory location 2GB before where our vmalloc() allocated buffer is.

We then end up calling prepend(&p, &buflen, "//deleted", 10), and we can see the code for prepend at https://elixir.bootlin.com/linux/v5.13.3/source/fs/d_path.c#L11, thought the interesting part starts at https://elixir.bootlin.com/linux/v5.13.3/source/fs/d_path.c#L16. Here we can see that buffer, aka the pointer to the memory at 2GB before the vmalloc() allocated buffer, is subtracted by 10, making it point an additional 10 bytes earlier in memory. Following this 10 bytes of the //deleted string, aka the //deleted string plus the null terminator is written to memory.

This effectively allows the attacker to gain an OOB write in kernel memory as they can adjust the length of the string allocated to adjust where they write in memory. Now typically this wouldn’t lead to much however Qualys was able to use this OOB write to overwrite the instruction of the validated eBPF program after it has been validated by the kernel but before it has been JIT compiled, and use this to transform the uncontrolled OOB write into and information disclosure and then in to a limited but controlled OOB write. Then then used Manfred Paul’s btf and map_push_elem techniques from https://www.thezdi.com/blog/2020/4/8/cve-2020-8835-linux-kernel-privilege-escalation-via-improper-ebpf-program-verification to transform this limited controlled OOB write into a full arbitrary kernel read and write and used this to set modprobe_path to their current executable, a technique that has been described in more detail than I can describe here in places like https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/, to elevate their current process such that it now executes code in kernel mode as root.

Official Patch And Some Important Notes

https://github.com/torvalds/linux/commit/8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b is the official patch for this issue, which fixes the issue by ensuring that seq_buf_alloc doesn’t allocate memory that is larger than MAX_RW_COUNT. Looking at where MAX_RW_COUNT is defined we see https://elixir.bootlin.com/linux/v5.13.4/source/include/linux/fs.h#L2572 where it is defined as #define MAX_RW_COUNT (INT_MAX & PAGE_MASK). This basically page aligns INT_MAX to a page so the max value allowed will be the value of INT_MAX, which is the maximum value of a signed 32 bit integer, minus the size of a page of memory on the system, which is typically 4KB in size.

If the size is over this amount then the allocation will fail and we will never hit the vulnerable code. However this doesn’t really solve the root issue per say. Assuming users can find another way to execute the same vulnerable code and abuse the fact that the kernel is still passing unsigned 64 bit integers to functions that expect signed 32 bit integers, its likely that someone could bypass this patch via alternative means. Whether or not this is possible remains to be seen, but in my opinion, whilst it would be more work, the appropriate solution would be update the functions to pass the appropriate data into one another whilst also taking care to not perform casts between signed and unsigned numbers without performing appropriate checks.

2
Ratings
Technical Analysis

Update: Looks like this was used by the exploit brokerage company Candiru along with CVE-2021-33771 to deliver spyware to targeted users, which according to Microsoft’s blog post, affected at least 100 victims in Palestine, Israel, Iran, Lebanon, Yemen, Spain, United Kingdom, Turkey, Armenia, and Singapore. Victims include human rights defenders, dissidents, journalists, activists, and politicians.

Hmm, this is a particularly juicy bug as it seems to affect all Windows systems from Windows 7 up to the latest Windows 10. This is in contrast to CVE-2021-33771, which only affects Windows 8.1 and later. Both bugs affect the Windows Kernel and are being actively exploited in the wild for LPE.

There is little information on what actually is the issue here, although https://twitter.com/mavillon1/status/1415149124064878593/ suggests that MiFlashDataSecton, EtwpUpdatePeriodicCaptureState and AlpcpProcessSynchronousRequest may be possible culprits and reviewing AlpcpProcessSynchronousRequest shows that a potential integer overflow was fixed.

Given that Microsoft also lists the attack complexity for both vulnerabilities as Low it seems likely that other researchers will find a way to replicate these vulnerabilities and create working PoCs for them, particularly given that they have been exploited in the wild. Based on this evidence, it is highly recommended to patch these issues as soon as possible.

Further updates will be made to this post if and when these CVEs are tied to specific vulnerable functions.

2
Ratings
Technical Analysis

Update: Looks like this was used by the exploit brokerage company Candiru along with CVE-2021-31979 to deliver spyware to targeted users, which according to Microsoft’s blog post, affected at least 100 victims in Palestine, Israel, Iran, Lebanon, Yemen, Spain, United Kingdom, Turkey, Armenia, and Singapore. Victims include human rights defenders, dissidents, journalists, activists, and politicians.

Hmm interesting so this bug only affects Windows 8.1 and later according to https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33771, despite also being disclosed in the same month as CVE-2021-31979, another bug that affected everything from Windows 7 and later onwards. Both bugs however affect the Windows Kernel and are being actively exploited in the wild for LPE.

There is little information on what actually is the issue here, although https://twitter.com/mavillon1/status/1415149124064878593/ suggests that MiFlashDataSecton, EtwpUpdatePeriodicCaptureState and AlpcpProcessSynchronousRequest may be possible culprits and reviewing AlpcpProcessSynchronousRequest shows that a potential integer overflow was fixed.

Given that Microsoft also lists the attack complexity for both vulnerabilities as Low it seems likely that other researchers will find a way to replicate these vulnerabilities and create working PoCs for them, particularly given that they have been exploited in the wild. Based on this evidence, it is highly recommended to patch these issues as soon as possible.

Further updates will be made to this post if and when these CVEs are tied to specific vulnerable functions.

2
Ratings
Technical Analysis

From https://blog.talosintelligence.com/2021/07/microsoft-patch-tuesday-for-july-2021.html there was a note that this vulnerability seems to have been used in some Exchange Server APT attacks detailed at https://blog.talosintelligence.com/2021/03/hafnium-update.html however it wasn’t disclosed that this vulnerability was patched despite being patched back in April 2021. Since this was under active exploitation it is recommended to patch this vulnerability if you haven’t applied April 2021’s patch updates already.

Successful exploitation will result in RCE on affected Exchange Servers, and requires no prior user privileges, so patch this soon!

2
Ratings
Technical Analysis

Looking at Microsoft’s advisory at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34448 shows very little information other than that this is a scripting engine vulnerability which is exploitable across a wide range of Windows OS versions and is exploitable remotely. Further investigation though shows that Cisco Talos at https://blog.talosintelligence.com/2021/07/microsoft-patch-tuesday-for-july-2021.html mentions that this vulnerability is a memory corruption vulnerability triggered when opening a maliciously crafted email or visiting a malicious website.

Further examination of https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34448 using the Download column (which is not enabled by default but can be added) shows several references to IE Cumulative Update which suggests this is potentially an IE related vulnerability. Further examination of past advisories named in the same way like https://msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-0224 shows that IE scripting engine vulnerabilities are also referenced using the same style of language, so it would seem this is a memory corruption vulnerability within IE’s scripting engine.

Users should ideally apply patches to fix this issue given it has been exploited in the wild already, however if this is not possible then users should disable JavaScript in their browsers as most scripting engine vulnerabilities rely on taking advantage of flaws in the JavaScript engine of a given browser, which requires the browser to have JavaScript enabled in the first place. Note that this will break the operation of most sites so patching is preferred where possible.

1
Ratings
Technical Analysis

According to https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-194-06 this is a hardcoded password issue in EVlink City / Parking / Smart Wallbox Charging Stations that would grant attackers administrative level control over a EVlink City / Parking / Smart Wallbox Charging Stations web server. These types of devices may not be updated regularly due to the need for them to be running constantly throughout the city, so I can imagine implementing a proper patching strategy will be paramount for ensuring this patch gets applied quickly, as this type of vulnerability could either be used for something simple like just resetting the amount a user has to pay to charge their car, or for gaining further access to city infrastructure, which could be used as a precursor to more targeted attacks.

1
Ratings
Technical Analysis

Interesting bug in Modicon M340, M580 and other models from the Modicon series, and has been named by Armis as ModiPwn. Bug does require local access to the target’s network so you do have to be on the same network as an affected device, however once you do manage to do this, you can leak hashes from the devices memory via undocumented commands (got to love extra hidden features, they are a real treasure trove of bugs). Once this hash has been leaked the attacker can then take over the encrypted connection between one of the Modicon devices and its managing workstation and reconfigure the Modicon device with a passwordless configuration, then allowing the attack to abuse additional undocumented commands to gain RCE and gain full control over the device.

Whilst there are no reports of in the wild exploitation, the fact that this doesn’t yet have a patch is concerning to say the least given that these types of vulnerabilities have been used in the past such as in the Triton malware, its safe to assume that exploits for this vulnerability may start circulating in the wild soon if they haven’t already been developed. It is highly recommended to prevent access to these devices until a patch is released, and once one is released, to patch as soon as possible.

1
Ratings
Technical Analysis

More info on this vulnerability can be found at https://srcincite.io/blog/2021/07/13/fswa-2021-zero-day-give-away.html where the original author, Steven Steely of Source Insight, shows an example of how this vulnerability could be exploited to leak sensitive credentials from configuration files and combined this with a 0day deserialization vulnerability in Apache Shiro in the rememberMe cookie to gain RCE. For this reason, given a real world example of how this could be used to gain RCE on a typical deployment, I have elevated the Attacker Value.

Overall this vulnerability in a nutshell allows unauthenticated users to leak the content of files on the target system provided the target file is within the web root (aka the attacker can’t leak the content of files outside of the web root). Provided a user can leak sensitive info (which is not that uncommon), they can utilize this information to then conduct privilege elevation attacks and bypass authentication.

1
Technical Analysis

From what I can tell this is a memory corruption vulnerability in WebKit. WebKit vulns are commonly exploited in the wild and this one is no exception with https://support.apple.com/en-us/HT212548 noting that active exploitation in the wild has been discovered. It is a little odd that the patched version is noted as version 12.5.4 of iOS given the latest version is 14.6, but if you are still running on the 12.x branch, make sure to update to 12.5.4 to receive the patches for this vulnerability, particularly given it has a working exploit in the wild. This was likely used alongside the WebKit UAF vulnerability (see https://attackerkb.com/topics/Gyq95f2J1L/cve-2021-30762) that was patched in the same release to form a full working exploit against iOS devices.

2
Ratings
Technical Analysis

From what I can tell this is a UAF vulnerability in WebKit. WebKit vulns are commonly exploited in the wild and this one is no exception with https://support.apple.com/en-us/HT212548 noting that active exploitation in the wild has been discovered. It is a little odd that the patched version is noted as version 12.5.4 of iOS given the latest version is 14.6, but if you are still running on the 12.x branch, make sure to update to 12.5.4 to receive the patches for this vulnerability, particularly given it has a working exploit in the wild. This was likely used alongside the WebKit memory corruption vulnerability (see https://attackerkb.com/topics/DwxtgSIUAV/cve-2021-30761) that was patched in the same release to form a full working exploit against iOS devices.

1
Ratings
Technical Analysis

Apparently this is a UAF vulnerability in the WebGL component of Chrome that has been exploited in the wild according to https://chromereleases.googleblog.com/2021/06/stable-channel-update-for-desktop_17.html. No further details at the moment other than that its triggered via JavaScript, which makes sense given this is a UAF vulnerability. As per usual, disable JavaScript where possible using plugins like NoScript if you want to mitigate the risk of this vulnerability somewhat, however its highly recommended to just update your Chrome and Edge browsers to the latest version available.

1
Technical Analysis

Based on comments at this thread: https://twitter.com/ShaneHuntley/status/1402320071276433408 we should expect to see a full writeup around July 9th or so from the Google threat assessment team. Seems they will be keeping things close to the vest until then to allow people to patch in the meantime.

2
Ratings
Technical Analysis

Public PoC code has been supposively making the rounds courtesy of https://github.com/mavillon1/CVE-2021-33739-POC. There is also a detailed writeup on this issue at https://mp.weixin.qq.com/s/ZjJ4kXOCTSez2erVKYzKbg although it is in Chinese so you will need to translate it.

From the translation it seems this was originally discovered as being exploited in the wild by Shadow Lab in May 2021, and then they worked with Anheng Threat Intelligence Center to notify MSRC, who then patched the bug in the June 2021 patch release. The vulnerability is located in dwmcore.dll, which is the core DLL for DWM, aka the Desktop Windows Manager, on Windows machines. More specifically, its a UAF caused by an reference count tracking issue of the Tracker Binding Manager object. Its interesting also to note that they state this vulnerability only affects Windows 10 machines and does not affect Windows 8.1 and below; this is reflected in Microsoft’s advisory as well.

To trigger the vulnerability, one needs to “create a CinteractionTrackerBindingManagerMarshaler(0x59) resource and a CinteractionTrackerMarshaler(0x58) resource at the code level, and bind the same CinteractionTrackerMarshaler resource as resource1_id and resource2_id to the CinteractionTrackerBindingManagerMarshaler, and do not manually release the CinteractionTrackerBindingManagerMarshaler resource.”. I won’t discuss it further as the technical details are in the original writeup though but this should provide a brief overview for those interested.

The conclusion of this writeup notes that technically this vulnerability falls within the scope of Windows DirectComposition component, which has seen increased attacks over the last two years. It also notes that this may have ties to the release of the Win32k Dark: Attacking The Shadow Part of Graphic Subsystem presentation at the Cansecwest 2017 conference, where researchers discussed how to attack Windows DirectComposition in more detail.

2
Ratings
  • Attacker Value
    Medium
Technical Analysis

Not got much to contribute due to limited public information at this time but I did want to note that the Confidentiality and Integrity scores for this are oddly listed as Low, the Availability as None, and yet Scope is marked as Changed. My guess is that this is some sort of sandbox related escape given that if we were able to get higher permissions these scores would be a lot higher.

1
Ratings
Technical Analysis

Not got much to contribute due to limited public information at this time but I did want to note that the Confidentiality and Integrity scores for this are oddly listed as Low, the Availability as None, and yet Scope is marked as Changed. My guess is that this is some sort of sandbox related escape given that if we were able to get higher permissions these scores would be a lot higher.

2
Ratings
Technical Analysis

This is a heap buffer overflow in ntfs.sys, one of the Windows kernel drivers, which was patched in June 2021. Heap vulnerabilities in the kernel are notoriously unreliable and hard to exploit, particularly given recent mitigations in Windows 8 and then later in Windows 10 that have introduced additional randomness to the kernel heap as well as additional state checks that will result in Windows terminating immediately if data does not look to be valid. Therefore realize that whilst this exploit has been exploited in the wild, I would imagine the reliability may be questionable or there may have been considerable work done behind the scenes to make the exploit more reliable.

In any case, the affected function is NtfsQueryEaUserEaList() in ntfs.sys which processes a list of extended attributes (this is where the ea part of the function name comes from) for a file and saves the retrieved values to a buffer. The problem here though is that users can make a Windows system call to access this function and NtfsQueryEaUserEaList() and its possible to control the size of the output buffer. However the output buffer’s size has to be 32 bit aligned. This causes an issue as whilst the code does check to make sure the output buffer can hold the content of the extended attribute list with padding, it doesn’t check for integer underflows, meaning that the check is done as though the number was an unsigned integer, yet when copying memory its treated as a signed integer, which can result in the number underflowing and becoming a large positive number, such that a lot of memory is copied into a very small buffer.

This is a particularly interesting case as most of the time when one combines an integer underflow/overflow with a heap buffer vulnerability, things don’t tend to pan out so well due to the user corrupting too much memory to reliably control the heap. This can cause issues later on when Windows checks the heap state and suddenly finds everything is trashed, resulting in a BSOD if one corrupts kernel heap memory. For this reason, I’m interested to see how the attackers actually managed to accurately control heap memory in this scenario to exploit the vulnerability.

From the advisory we are given some hints that the Windows Notification Facility (WNF) was used along with this vulnerability to get arbitrary memory read and write primitives, which is a new kernel exploitation strategy I have not heard about before. It appears this was also new to Kaspersky as well as they mention they will be publishing more information about this technique in the future.

Additionally, showcasing the sophistication of the attackers who exploited this vulnerability, they also used a rarely used PreviousMode overwrite instead of stealing overwriting the Token field of the EPROCESS structure to steal the token. As mentioned at https://github.com/oct0xor/presentations/blob/master/2019-02-Overview%20of%20the%20latest%20Windows%20OS%20kernel%20exploits%20found%20in%20the%20wild.pdf, this field controls which mode the kernel was in prior to performing a system call. This can allow an attacker to perform sensitive actions by essentially tricking the OS into thinking a system call was made from kernel mode when in reality it was not.

1
Ratings
Technical Analysis

Ah good old NtQuerySystemInformation() strikes again, never quite going out of style :) In this case CVE-2021-31955 is an information disclosure in good old ntoskrnl.exe, aka the Windows kernel itself, that occurs due to a Windows feature supported since Windows Vista known as SuperFetch. By sending a SystemSuperfetchInformation class request of type SuperfetchPrivSourceQuery via the undocumented NtQuerySystemInformation() function, one can obtain the kernel address of the EPROCESS structure for the current process. This is REALLY bad since the EPROCESS kernel structure contains also contains a pointer to the process’s permissions token. If we know the address of this token, then, provided one has an arbitrary kernel write vulnerability, they can easily overwrite this pointer to point to the permissions token for a higher privilege process, and if this process is running as SYSTEM, they will gain SYSTEM level code execution.

According to https://securelist.com/puzzlemaker-chrome-zero-day-exploit-chain/102771/, this was used in the wild alongside CVE-2021-31956 to escape the Chrome sandbox and gain SYSTEM on affected users computers, after first compromising Chrome and gaining execution inside the Chrome sandbox with what is suspected to be CVE-2021-21224.

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

According to https://securelist.com/puzzlemaker-chrome-zero-day-exploit-chain/102771/ this appears to have been used along with CVE-2021-31955 and CVE-2021-31956, a Windows kernel information leak and a Windows LPE vulnerability, to form a full RCE to go from a user browsing a web page to full SYSTEM control over a target Windows device. This is an extremely powerful and valuable exploit chain, and many exploit brokers are willing to pay large sums of money for these chains as they often are very valuable to nation states who wish to use them for their intelligence operations.

Overall though, on its own it seems like this bug wasn’t super valuable as you only get RCE within the sandbox itself, which is why it was then chained with a Windows kernel bug to escape the Chrome sandbox and gain RCE as SYSTEM on the target device. Therefore the risk for this vulnerability alone is lower, however if we keep in mind the other bugs that existed at the time, the overall risk is quite high.

There also appears to have been public exploit code available for this vulnerability, available at https://github.com/avboy1337/1195777-chrome0day, which was potentially reused by the attackers. In any case at the time that code was released the bug was still unpatched which lead researchers at Kaspersky to conclude that its likely attackers used the code from https://github.com/avboy1337/1195777-chrome0day in their attack.

Otherwise this is your typical V8 type confusion bug. V8 seems to have had quite a few type confusion bugs in the past so this is nothing too new. If you want to limit exposure, disable JavaScript in your browser on untrusted sites, which will help prevent users from being exploited by these types of attacks as most of them rely on JavaScript to do set up the environment in Chrome appropriately. That being said disabling JavaScript will break most sites so take this with a grain of salt :)

1
Ratings
Technical Analysis

No real details on this at the moment but according to Adobe’s website at https://helpx.adobe.com/security/products/acrobat/apsb21-29.html this is a Use-After-Free bug in Adobe Acrobat that leads to remote code execution when opening a PDF. It was anonymously reported and has been reported to be exploited in the wild in limited targeted attacks against Windows users.

Given the available information though I would guess that to trigger this vulnerability a user would have to open a PDF containing malicious code in Adobe Acrobat and then the malicious PDF would run some JavaScript or similar to put memory into a stable state such that it would be able to trigger the UAF and gain control of Adobe Acrobat without crashing it.

Given Adobe Acrobat is popular though the attacker value for this bug is pretty high, though I did deduct a point if only cause an attacker would still need to convince a user to open the PDF. I also set the exploitability at medium as UAF bugs are not that easy to exploit, however web browsers and PDF readers often provide JavaScript engines that allow attackers to more easily control the state of memory, which can greatly ease the process of exploit development. However without knowing more info its difficult to gauge the level of exploitation difficulty for this specific exploit.

4

@JoeUX Continuing on @wvu-r7’s answer though, take a look at XML external entity injection attacks (XXE) as described at https://portswigger.net/web-security/xxe for some more examples. Basically any parser can have RCE attacks in it depending on what features that parser has, and those can be abused at times to grant additional privileges. In the example of an XML parser you might be able to get it to include an external entity that makes a HTTP GET request to a certain page to reset a device back to its default settings, thereby allowing RCE by logging in with default credentials. Another way might be achieving RCE by exfiltrating a file containing the SSH login password hash such as /etc/passwd and then cracking that password to get the login information.

As for deserialization attacks, keep in mind that its often kind of hard to determine the true impact of deserialization bugs without understanding the code around the deserialization itself. In some cases it may be possible to get RCE by abusing the deserialization to set the application state in such a way that when a certain code block is executed, it results in arbitrary code execution. In other cases, it may only be possible to read arbitrary files on the system. This is why determining the impact of a deserialization bug can sometimes be difficult without additional context.

In the case of this vulnerability, it seems there was some chain of code that could be triggered which utilized the adjusted object state (which is caused by the deserialization vulnerability) in such a way that it allowed for remote code execution to occur.

As for C# vs C++ vs other languages and deserialization itself, keep in mind many languages support deserialization. This bug is not unique to C++ or C# or really any programming language in particular and RCE could occur due to deserialization languages in most common languages that you can think of, including PHP, Ruby, Perl, C++, .NET, Python, etc.

Exchange is not open source in and of itself, however as @wvu-r7 mentioned it is trivial to decompile .NET code using tools such as dnspy or dotNetPeek, both of which are freely available tools that can be downloaded from the internet to decompile .NET applications, and which can be used along with manual code review skills to find bugs such as this one. Keep in mind though that decompiling it is one thing, making sense of the code however is another as Exchange is a large application with a complex code base which requires time and patience to understand.

2
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Low
Technical Analysis

Not much to add to @bwatters-r7’s findings but just wanted to note that there is a detailed analysis of this vulnerability now at https://www.armis.com/resources/iot-security-blog/from-urgent-11-to-frag-44-microsoft-patches-critical-vulnerabilities-in-windows-tcp-ip-stack/ and there is also a PoC out that snuck into another blog at the end of https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/ under the Bonus: CVE-2021-24074 section.

3
Ratings
Technical Analysis

Not going to repeat anything that other users have contributed here but one thing I think that was missed from the original advisory that I didn’t see noted here is that ICMPv6 is not routeable over the internet, and instead only over the local subnet (see the line This vulnerability is not routable over the internet, but only over a local subnet. under the Mitigations section of https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-16898).

This means that at best you could only exploit this if you were on the same network as the attacker. Even then this is a NULL pointer dereference vulnerability and all of the affected versions of Windows 10, as well as the affected server versions don’t allow you to map the NULL page needed to turn this into a remotely exploitable vulnerability unless you already have local access to the system (and if you already have local access, then why are you using this vulnerability anyway? There are better alternatives :) ).

A great indepth writeup of this vulnerability can be found at https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/ which covers the exploit in detail along with how it was patched.

If you want to test if systems are affected there is now working BSoD code at https://github.com/0vercl0k/CVE-2021-24086 if you need to check if a system is vulnerable and don’t mind BSoD’ing the target.

2
Ratings
  • Attacker Value
    Very Low
Technical Analysis

At the very least I’d debate the legitimacy of this exploit given reports like https://twitter.com/albinowax/status/1263068436298633216 and https://nvd.nist.gov/vuln/detail/CVE-2020-12440 which suggest this CVE was withdrawn due to it not actually being a valid bug. I’m not sure why this was exploited in the wild as well as I see no evidence of this having been the case minus a light PoC whose validity is disputed (again probably also why this CVE was later revoked as not a security vulnerability).

4

@jermainlaforce Comments welcome but just stating its incorrect doesn’t help anyone; mind explaining why you think its incorrect? We welcome healthy debates :)

3
Ratings
Technical Analysis

An interesting vulnerability in Microsoft SharePoint Server 2019, Microsoft SharePoint Enterprise Server 2016, Microsoft Business Productivity Servers 2010 Service Pack 2, and Microsoft SharePoint Foundation 2013 Service Pack 1 that allows for RCE via a deserialization vulnerability. However for an added twist the vulnerability occurs due to a replay-style attack.

The specifics of the vulnerability are discussed in some detail at https://www.zerodayinitiative.com/blog/2021/3/17/cve-2021-27076-a-replay-style-deserialization-attack-against-sharepoint, however I’ll try cut out a lot of the cruft and boil it down to the key essentials here. Basically in most apps there is a requirement to provide some level of message authentication. This ensures that messages are not tampered with or otherwise altered after they are sent, however there is a fatal flaw that applications can make where they assume that just cause a message is signed, aka it was not tampered, it ensures that the intent of the user was to perform that action.

This issue, aka the lack of intent attached to a message, can lead to incorrect assumptions whereby an application assumes that just cause a message is signed correctly, its intent must be correct. Unfortunately its hard to infer intent based just on some random signed message, as all the signing does is tell us that the sender definitely sent some specific sequence of bytes and that it likely wasn’t tampered with after sending them. This is the basis of the idea behind replay attacks: just cause the message is valid doesn’t mean it can’t be replayed in different scenarios to achieve useful results.

A good example of this is say you have messages to perform action A, B and C and they need to be performed in that order or your factory will explode. Message authentication is great to say okay your doing action A, B, or C and not some other action, but it does nothing to ensure that step B is done after step A and not after step C. That is where intent comes into play.

Now that this logic is understood, we can look at CVE-2021-27076 within SharePoint. This issue occurs in the InfoPath functionality that SharePoint offers, which stores documents in a serialized state within session data, after which they are then retrieved by key using the editingSessionId key and deserialized. As noted in ZDI’s blog post, this deserialization is done by the BinaryFormatter.Deserialize() function, and if arbitrary data can be provided here then an attacker could get RCE.

Now whilst the blog post doesn’t in and of itself say which user gets RCE, if one looks at the advisory from Microsoft they will note some very interesting key words: In a network-based attack an attacker can gain access to create a site and could execute code remotely within the kernel., This to me indicates that whilst the original component that is impacted may not immediately grant kernel level RCE, it is possible to elevate one’s permissions to SYSTEM or similar though the access granted by exploiting this vulnerability. This would ultimately allow an attacker to go from having low permissions on the SharePoint server to gaining full SYSTEM level code execution on the server.

Okay so we know this grants SYSTEM level code execution. Lets continue. The first hurdle we see is that we don’t have direct access to the session data, as this is stored server side. How can we store the arbitrary data we need to store in the session data to trigger the vuln? Well turns out we can use the app itself to store data into the session data, since we can’t directly access it ourselves. We know the app shouldn’t store arbitrary data in the session data that it could end up later deserializing but remember intents from earlier? Well turns out it may not have intended it, but there is a way to do this!

In particular, when uploading files, we normally retrieve the data from the session state using the key associated with a data item that was placed in the session state (remember the earlier discussion about session state being used to hold documents), and the data in the session state is intended to be used for file attachment upload operations (aka file goes to session state, and is then retrieved from session state and used in a file attachment upload operation).

Similarly, DocumentSessionState is used as the deserialization operation, and then when this occurs what normally is expected is that data is retrieved using a key corresponding to an item placed into the session state, with the intent of it being used in a DocumentSessionState deserialization, not a file attachment upload.

In both cases, editingSessionId is used as the key to determine which item should be retrieved from the session state. However, this variable is entirely controlled from client side. Therefore, we can upload arbitrary data via one intent (the attachment upload) and then use that same editingSessionId in a different context, namely to enter the DocumentSessionState deserialization code path.

However now we have a problem, as when uploading an attachment, we can’t see which session state key, aka editingSessionId, is used for that particular attachment. It exists only on the server inside the DocumentSessionState object, which we can’t see as a client side user. To solve this the researcher ended up sending the document state key into the attachment mechanism, which is located at FormServerAttachments.aspx, so that the server replays a serialized DocumentSessionState as an attachment and returns it to the client, and then within this data will be the attachment’s state key, aka its editingSessionId key corresponding to that specific attachment.

As noted in the ZDI report the final steps end up being roughly the following:

  1. Create an InfoPath list.
  2. Begin adding a new item to the list.
  3. Attach a file to the item. The file contains a fake InfoPath DocumentSessionState including arbitrary objects to be deserialized. The file’s extension can be
    set to anything InfoPath allows for extensions, for example, .png. After attaching this file, do not save the form.
  4. Scrape the document’s state key from the page’s HTML.
  5. Feed the document’s state key to the FormServerAttachments.aspx page, maliciously replaying the DocumentSessionState into the attachment mechanism. The entire serialized DocumentSessionState is returned to the client as if it were an attached file.
  6. From within the returned data, extract the state key of the attachment added in step 3.
  7. Feed the attachment’s state key into an undocumented client-side API, maliciously replaying the attachment into the deserialization mechanism. Remote code execution is achieved when the arbitrary objects present in the attachment are deserialized on the server.

Its interesting that they included most of these steps but just leave the last step as an undocumented client-side API. The client-side API part of this gives us some hints, along with the fact that it replays the attachment into the deserialization mechanism, but without further info or discussion on this part, its hard to tell what this function is right now without doing further analysis. I haven’t seen any discussions on this bug online either so I don’t know if others have figured this out or not; most likely people are still working on it.

In conclusion though I would strongly recommend that users patch this vulnerability. Whilst this bug does require some level of authentication to exploit, which mitigates some of its risk, the fact that it allows users to go from basic authentication to full SYSTEM level control over the affected SharePoint server should not be overlooked. I can see this being a potential for threat groups to utilize in more targeted attacks in the future, given the need for some level of authentication, as this allows for easy pivoting and information gathering should attackers manage to gain some initial credentials to a SharePoint server.

3
Ratings
Technical Analysis

Reported as exploited in the wild at https://thehackernews.com/2021/03/another-google-chrome-0-day-bug-found.html and at https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_12.html.

This bug seems to have scarce details from what I can tell online, however it appears to be a UAF bug within Blink that was reported by an anonymous researcher on 2021-03-09. The details for this bug are currently locked so that only Google employees can access it, but should it be opened to the public the details will be at https://bugs.chromium.org/p/chromium/issues/detail?id=1186287.

As per usual the advice to protect against UAF bugs in browsers is to disable JavaScript on untrusted websites via a plugin such as NoScript. Since most UAF’s require JavaScript to be enabled to conduct exploitation, this will act as an effective mitigation in most cases, but users should not rely on this as their sole protection mechanism.

It is interesting to see that this is the third 0day exploited in the wild this year in Chrome, alongside CVE-2021-21166, a object lifecycle issue in the audio component, and CVE-2021-21148, a heap buffer overflow within the V8 scripting engine. Time will tell if this trend continues though, but it is interesting to see such an regular cadence of vulnerabilities being exploited in the wild.

3
Ratings
Technical Analysis

Interesting, so this was a bug within win32kfull.sys!BLTRECORD::bRotate originally disclosed by ZDI as ZDI-CAN-12671, which was a NULL pointer dereference vulnerability within Windows’s win32kfull.sys/win32k.sys kernel driver. However Microsoft originally didn’t want to patch this, most likely because Windows 8 and later has memory protections that prevent one from mapping the first 64kb or so of memory, thereby making it nearly impossible to map the NULL page unless NTVM is enabled for 16 bit support.

However with this being said there have been bypasses of the NULL page protection. One of the most notable was https://twitter.com/waleedassar/status/1270550282695585792/photo/1 which shows that if Intel SGX is enabled on a target PC, it is possible to use NtCreateEnclave() to reserve the NULL page in memory. I imagine that other bypasses may exist however given their rarity and Microsoft’s williness to patch them as fast as possible, they are likely traded privately.

Interestingly this vulnerability also affects Windows 7 and Windows Server 2008 and 2008 R2, which only later got these NULL page mitigations backported from Windows 8. Therefore whilst its unlikely that recently updated systems are going to be able to be exploited as a result of this NULL page mitigation backporting, its possible that servers running very outdated versions of these systems may be readily exploitable via this vulnerability.

Assuming the NULL page is mapped though, what will happen is that if the 4 parameter version of win32kfull.sys!BLTRECORD::bRotate is called with a flag parameter that has the HOOK_PLGBLT bit set within it, it will take the surface object that it is trying to draw on and will look at that surface object’s hdev field to find the handle to the device driver to use. It will then attempt to call the DrvPlgBlt() function of the device driver without first checking to see if that device driver specified by hdev provides a DrvPlgBlt() function. This can lead to an attempt to execute code from the NULL page as SYSTEM.

So overall if you can map the NULL page this is a pretty easy vulnerability to exploit, but with the backporting of the NULL page mitigation and the standardization of preventing the NULL page from being mapped starting with Windows 8, its easy to understand why this was less of a concern for Microsoft to fix.

2
Ratings
Technical Analysis

Update: This is now reported as having been exploited in the wild by North Korean APT actors along with CVE-2020-1380 as noted at https://www.volexity.com/blog/2021/08/17/north-korean-apt-inkysquid-infects-victims-using-browser-exploits/

Reported as exploited in the wild at https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26411. Appears to be a memory corruption bug in Internet Explorer and Edge which would allow for a watering hole or drive by attack whereby a user is convinced to visit an attacker’s malicious website and then the attacker would be able to gain RCE on the user’s computer. Interestingly, despite this being a memory corruption bug, which is typically harder to exploit, Microsoft has still written up the exploitability of this vulnerability as Low.

There also appears to be an analysis of this vulnerability at https://enki.co.kr/blog/2021/02/04/ie_0day.html which suggests that this was the vulnerability used by the Laurus APT group to attack security researchers in Feburary. An English summary can be found at https://www.bleepingcomputer.com/news/security/hacking-group-also-used-an-ie-zero-day-against-security-researchers/ which suggests that this vulnerability was a double free vulnerability in IE which was triggered by sending a user a malicious MHT/MHTML file, and if the user allowed script execution, then CVE-2021-26411 would be exploited.

Given that Mitja Kolsek of 0Patch was able to replicate this issue relatively quickly, I’d say its likely that attackers will be able to exploit this vulnerability as well. I would expect to see more widespread exploitation of this vulnerability in the coming months.

2

Seems at the moment that the patch is broken due to a permissions error on the /root/app/log_upload_wsgi.py file within the docker container appacheServer (no that isn’t a typo, that is the name they used). Here is some info for context, still investigating this further but I’d be wary that applying the update as it is atm will likely bork your setup temporarily until you can address this permissions error. UPDATE: Looks like doing chmod 704 /root/app/log_upload_wsgi.py will do for solving this issue, however you will still run into an issue with trying to send password to the server, which will cause exceptions.

[Wed Mar 10 05:20:40.138462 2021] [wsgi:error] [pid 230:tid 140085055944448] (13)Permission denied: [client 172.20.119.240:57980] mod_wsgi (pid=230, process='', application='localhost|/logupload'): Call to fopen() failed for '/root/app/log_upload_wsgi.py'.
[Wed Mar 10 05:26:06.692072 2021] [wsgi:error] [pid 230:tid 140085039159040] (13)Permission denied: [client 172.20.119.240:57988] mod_wsgi (pid=230, process='', application='localhost|/logupload'): Call to fopen() failed for '/root/app/log_upload_wsgi.py'.
root [ /var/log/httpd ]# ls -alh /root/app/log_upload_wsgi.py 
-rw------x 1 root root 4.5K 2021-03-10 04:03 /root/app/log_upload_wsgi.py
root [ /var/log/httpd ]# ls -alh /root/app
total 8.0K
drwx-----x 2 root root 4.0K 2021-03-10 03:20 .
drwxr-x--x 1 root root 4.0K 2021-03-10 05:02 ..
-rw------x 1 root root 4.5K 2021-03-10 04:03 log_upload_wsgi.py
1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Technical Analysis

Reported as exploited in the wild at https://threatpost.com/google-patches-actively-exploited-flaw-in-chrome-browser/164468/ and at https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop.html.

Details are still scant on this vulnerability as they are being withheld by Google until more people have patched the issue, which was fixed in Chrome 89.0.4389.72. All that we know is that the bug is labeled as an Object lifecycle issue in audio and was found by Alison Huffman, Microsoft Browser Vulnerability Research on 2021-02-11.

Given the description of this vulnerability as well as its link to a similar vulnerability exploited in the wild in the past (see https://threatpost.com/google-discloses-chrome-flaw-exploited-in-the-wild/149784/), its likely that this is a UAF vulnerability. Given the one used in https://threatpost.com/google-discloses-chrome-flaw-exploited-in-the-wild/149784/ was a bug in the same component which was then used in the WizardOpium attacks, its likely that this vulnerability will lead to full compromise of the system given past history.

Users are encouraged to disable JavaScript where possible, particularly for untrusted sites, as this is often needed in order to successfully exploit UAF vulnerabilities in the browser. However this is only a temporary fix, and it is strongly encouraged that users instead upgrade to Chrome 89.0.4389.72 or later, Given there is already active exploitation of this vulnerability, and given the history of bugs within this component, there is a good possibility that we may see more widespread exploitation of this issue in the near future.

5
Ratings
Technical Analysis

A very interesting vulnerability in win32kfull.sys on Windows 10 devices up to and including 20H2. Although the exploit in the wild specifically targeted Windows 10 v1709 to Windows 10 v1909, as noted at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/, the researchers noted that the vulnerability could be modified to work on Windows 20H2 with minor modifications.

From my perspective this is rather significant, particularly given this is a win32kfull.sys bug we are talking about here. Most of the primitives that made win32k exploitation easier were entirely wiped out by Microsoft which prompted a lot of researchers who previously spoke publicly about such primitives in conference talks and similar to go quiet. Whilst rumor has been that there were other primitives one could use for exploitation, they were considered closely guarded secrets due to the difficulty in finding them and the fact that Microsoft would be likely to patch them very quickly.

The new primitive that is used here appears to be setting tagMenuBarInfo.rcBar.left and tagMenuBarInfo.rcBar.top and then calling GetMenuBarInfo(), which allows one to perform an arbitrary read in kernel memory. This has not been discussed before but is similar to another concepted discussed in the paper “LPE vulnerabilities exploitation on Windows 10 Anniversary Update” at ZeroNights which mentioned using two adjacent Windows and then setting the cbwndExtra field of the first window to a large value to allow the first window to set all of the properties of the second window. By chaining this together the attacker could achieve an arbitrary read and write in kernel memory.

The bug itself stems from a xxxClientAllocWindowClassExtraBytes() callback within win32kfull!xxxCreateWindowEx. Specifically when xxxCreateWindowEx() creates a window object with a cbwndExtra field set, aka it has extra Window bytes, it will perform a xxxClientAllocWindowClassExtraBytes() callback to usermode to allocate the extra bytes for the Window.

You may be wondering why such callbacks are needed. Well a long time ago Windows used to handle all its graphics stuff in kernel mode, but then people realized that was too slow given increasing demands for speed, so they made most of the code operate in usermode with key stuff handled by kernel mode. This lead to a big rift and is the reason we have callbacks. Thats the nutshell version anyway but go read up on http://mista.nu/research/mandt-win32k-slides.pdf and https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_WP.pdf if you want to learn more. Its a fascinating read :)

Anyway back on topic. Since xxxClientAllocWindowClassExtraBytes() is a callback that is under the attackers controller, the attacker can set a hook that will trigger when a xxxClientAllocWindowClassExtraBytes() callback is made and call NtUserConsoleControl() with the handle of the window that is currently being operated on. This will end up calling xxxConsoleControl() in kernel mode which will set *((tagWND+0x28)+0x128) to an offset, and will AND the flag at *((tagWND+0x28) + 0xE8) with 0x800 to indicate that the value of the WndExtra member is an offset from the base address of RtlHeapBase. Unfortunately, whatever value is returned by the hooked xxxClientAllocWindowClassExtraBytes() callback (aka whatever value the attacker chooses) will be used as the value of WndExtra, since remember we are meant to be allocating the address of this field at the time due to the earlier xxxCreateWindowEx() call needing to allocate memory for WndExtra.

Once this is done, the callback will be completed, execution will return to usermode, and a call to DestroyWindow() will be made from usermode. This will cause xxxDestroyWindow() to be called in kernel mode which will call xxxFreeWindow(), which will check if *((tagWND+0x28) + 0xE8) has the flag designated by 0x800 set, which it will due to the alterations made by xxxConsoleControl(). This will then result in a call to RtlFreeHeap() which will attempt to free an address designated by RtlHeapBase + offset, where offset is the value of WndExtra (which is taken from the xxxClientAllocWindowClassExtraBytes() callback and therefore completely controlled by the attacker).

This subsequently results in the attacker being able to free memory at an arbitrary address in memory.

I’ll not dive into a full detailed analysis of the rest of the exploitation steps as the article at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/ is very comprehensive but I will say from what I’ve read there, there is enough detail that people of a decent skill level could probably recreate this exploit. It certainly isn’t an easy exploit to recreate but the exploit goes into a lot of detail about the various mitigation bypasses that were used to make this exploit possible, which could help an attacker more readily recreate this bug.

Again, this exploit was exploited in the wild so it is possible for this bug to be recreated, it just might take some time for people to work out a few of the specifics needed to get a working exploit. If you are running Windows 10, it is highly advised to upgrade as soon as possible: everything I am reading here points to signs that this will be weaponized within the coming few weeks or months.

Additionally it should be noted that this exploit was noted to be capable of escaping Microsoft IE’s sandbox (but not Google Chrome’s) so if you are running Microsoft IE within your environment, its even more imperative that you patch this issue to prevent an attacker from combining this with an IE 0day and conducting a drive by attack against your organization, whereby simply browsing a website could lead to attackers gaining SYSTEM level privileges against affected systems.

3
Technical Analysis

Reported as exploited in the wild at https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html. Several news articles such as https://www.theverge.com/2021/2/5/22267872/chrome-88-zero-day-vulnerability-government-backed-hackers-security-researchers have suggested that given the timing of this bug, and that it was reported one day before Google’s report on the North Korea hackers targeting security researchers (see https://www.theverge.com/2021/1/26/22250060/google-threat-analysis-group-north-korean-hackers-cybersecurity-researchers-social-engineering), it may be related to the 0day Chrome bug that was used by North Korean state actors in that engagement.

Given this is a remote heap overflow in the browser there may be some concerns regarding reliability though and whilst I’m sure there will be public exploits for this bug, I do question how reliable they will be given the nature of trying to exploit heap exploits. I would imagine the exploit would take advantage of JavaScript to craft the heap appropriately. Therefore a temporary, but not recommended, precaution may be to disable JavaScript in Chrome until one can apply this update.

Please note that Chrome will automatically apply the update if you open and close your browser. However people do tend to keep Chrome open with many tabs and then suspend their PC at the end of the day, so its possible that these patches will likely see an uptick in application when the next Patch Tuesday or company wide patch cycle is enforced and people are forced to reboot their PCs to apply patches, and therefore restart Chrome.

2
Technical Analysis

Seeing more evidence of people trying to exploit this in the wild in recent days, with samples such as the ones listed at https://twitter.com/dnpushme/status/1350022293464907780 being detected as CVE-2021-1647 exploit files per VirusTotal analysis.

3
Ratings
Technical Analysis

Interesting vulnerability :) On Windows systems running Cisco AnyConnect Secure Mobility Client for Windows releases earlier than Release 4.9.04043, authenticated attackers could modify a configuration file that was loaded and used when Cisco AnyConnect starts up to load an arbitrary DLL and have it be run as the SYSTEM user. The advisory at https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-anyconnect-dll-injec-pQnryXLf does not specify which file this is, however I imagine it would be possible to find it by using ProcMon, applying the appropriate filters, and then restarting the Cisco AnyConnect process and looking for any attempts to load a configuration file. From there it would then just be a case of figuring out the configuration file format.

Unfortunately without knowing the configuration file format, its a little hard to say how tough this vulnerability is to exploit. Given that you can load an arbitrary DLL file though I imagine the file format must not be too stringent, as otherwise such behavior would be blocked, but this says nothing as to whether the file is a binary format, a text format, or something else or if there are many fields that need to be filled in for the exploit to succeed or just a few.

Given this I’m giving this exploitability rating a 3/5 to play on the safe side of things. Its probably possible but without further info its possible it may take some effort to form a valid configuration file which could make exploitation of this vulnerability considerably more difficult.

2
Technical Analysis

This has now been reported as being exploited in the wild as part of the FreakOut attacks as first reported by CheckPoint Research at https://research.checkpoint.com/2021/freakout-leveraging-newest-vulnerabilities-for-creating-a-botnet/.

2
Ratings
Technical Analysis

Reported as exploited in the wild by CheckPoint Research as part of the FreakOut attacks, as written up at https://research.checkpoint.com/2021/freakout-leveraging-newest-vulnerabilities-for-creating-a-botnet/. This operation was designed to create a IRC controlled botnet that could be used for future operations, and for coin mining.

As written in https://research.checkpoint.com/2021/freakout-leveraging-newest-vulnerabilities-for-creating-a-botnet/, the attackers abused the Zend3 feature (which loads classes from objects) of Zend Framework version 3.0.0 and higher to cause a deserialization issue. In the case of the FreakOut attacks, attackers sent a crafted POST request to /zend3/public with a serialized payload containing a callback parameter, and injected commands to be executed into the serialized callbackOptions parameter in place of the normal array.

There is also a nice analysis of this vulnerability at https://github.com/Ling-Yizhou/zendframework3-/blob/main/zend%20framework3%20%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%20rce.md should you wish to dive further into the gory details of the bug. This is written in Chinese though so you might need to translate it first.

As there is a lot of information on this vulnerability out at the moment, I am rating this as a high probability of exploitability not cause its a complex bug, but purely because given Checkpoint Research’s writeable, all an attacker has to do is write a sample request from the screenshot provided, and they will be able to replicate the bug and craft a working exploit. Otherwise this would normally have a lower exploitability rating as deserialization bugs are not always that simple to exploit.

Additionally, the bigger concern here is that there is no patch for this vulnerability for the Zend Framework to the best of my knowledge, since it is no longer supported by its developers. Users who are affected by this vulnerability are therefore encouraged to migrate to a different framework as soon as possible and severely limit interaction with any servers running Zend Framework in the meantime.

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

Noted as exploited in the wild by CheckPoint Research at https://research.checkpoint.com/2021/freakout-leveraging-newest-vulnerabilities-for-creating-a-botnet/, who noted an exploit for this vulnerability was being used as part of a botnet building operation.

Looking into their writeup, they note that remote unauthenticated attackers can use this vulnerability to take over the TerraMaster TOS operating system via command injection in the event parameter in the /include/makecvs.php page. Interestingly they don’t specify the user the attacker’s injected command will run as, but they do include a very useful screenshot which shows that a GET request to /include/makecve.php?Event=%60, followed by the command the attacker wishes to execute, followed by another %60, will allow for arbitrary command injection. %60 is `, which suggests that the command being executed may have been enclosed in backticks, and that by escaping these backticks, the attacker is able to execute arbitrary commands.

Users can patch this vulnerability by upgrading to version 4.2.06 of Terramaster TOS on their NAS devices. Given the severity of this bug and evidence of exploitation in the wild, it is strongly encouraged to patch this vulnerability as soon as possible.

2
Ratings
Technical Analysis

Original advisory and PoC can be found at https://github.com/pear/Archive_Tar/issues/33

This vulnerability is very similar to CVE-2020-28948, with a couple of key differences. In the case of CVE-2020-28948, the root issue was that the code within Archive_Tar didn’t use case sensitive checks to ensure file names didn’t start with phar://. Here the issue is the same however it stems from a lack of checks. More specifically as mentioned in my writeup on CVE-2020-28948, Archive_Tar prior to 1.4.11 checked, using strpos(), that filenames within a TAR archive did not start with the characters phar:// and did not contain the characters ../ or ..\.

Notice however that there is a problem here: we can still use any other file stream wrapper other than the phar:// file handler within a file name to trigger the corresponding wrapper handler. A full list of PHP file stream wrappers can be found at https://www.php.net/manual/en/wrappers.php.

Looking at these stream wrappers reveals there are a few that might help with file writes. In fact, as shown in the PoC at https://github.com/pear/Archive_Tar/issues/33, if one creates a file within a TAR archive with a name such as file:///etc/passwd, then when the TAR archive is extracted, the corresponding file, which in this case would be /etc/passwd, will be overwritten with attacker controlled contents, assuming the user that PHP is running as has permissions to create or overwrite that file.

This leads to an arbitrary file upload vulnerability whereby an attacker could potentially overwrite existing files with arbitrary content. The attacker would however need to know the exact path on disk to the file that they wished to write: remember that ..\ and ../ are not allowed in filenames and even if they were, the file:// stream wrapper requires the use of absolute paths.

Again as noted in my writeup on CVE-2020-28948, this bug entirely depends on the fact that a vulnerable application makes use of this library and also extracts the contents of the TAR file as part of its operations. If the application only allows TAR file uploads but it doesn’t actually try to extract the contents of the TAR file as part of its operations, then this vulnerability will never be triggered.

That being said assuming an attacker does know the right path and the application is set up in to extract TAR files, then this can easily lead to RCE via overwriting existing PHP files on the target system.

4
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
Technical Analysis

Edit: PoC code for this can be found at https://github.com/pear/Archive_Tar/issues/33 along with the original advisory.

An interesting vulnerability using the concepts of PHAR file deserialization as first discussed at BlackHat in this video: https://www.youtube.com/watch?v=OrEar0TiS90. For those who don’t know, the phar:// file stream handler allows opening PHAR files, which are basically PHP archive files containing a bunch of related files (mostly tends to be PHP files within the archive, but can be other things as well). Whats interesting about PHAR files is that their metadata is formed via a serialize() call when their created, and when files are extracted, unserialize() will automatically be called on that metadata string. This leads to the potential for serialization attacks even when the application doesn’t explicitly use unserialize() calls.

In this case, the Archive_Tar developers were aware of this prior research and attempted to explicitly block phar://, ../, and ..\ within any file name contained with the tar archive by performing a strpos call using these strings and erroring out if the string contained these characters. Unfortunately that check is really poor for a number of reasons.

The specific reason related to this CVE, aka CVE-2020-28948, is that users can simply use PHAR:// to bypass this check. In other words, the check performed by strpos() is not case sensitive, so one can easily bypass it by simply changing the case of the string. They could also mix the case, so an example like pHaR:// might also work.

This then allows attackers to perform attacks where they can load a local PHAR file on the target system and use a deserialization attack to perform some malicious action. Assuming an app is already extracting the contents of the TAR files locally, an attacker would simply have to upload a TAR file containing a malicious PHAR file and have the app extract and save the PHAR file locally, after which they could upload a second TAR file containing a file named PHAR://*malicious PHAR file location* and the PHP app would attempt to access and extract the local PHAR file, thereby triggering the vulnerability.

Notice that the PHAR:// file handler does not allow for accessing remote files, which is why this procedure is required.

Research into deserialization gadgets for this exploit showed that most of the potential possibilities seem mostly restricted to file operations. The PoC showed that it would be possible to delete a file using this vulnerability but I was not able to determine any other useful actions that could be performed. Potential impact would depend both on the privileges of the user running PHP as well as what operations the app was doing; again remember the program will only be able to do file operations so most likely an attacker would have to package a malicious PHP file within the PHAR archive, have that be extracted somehow along with the malicious PHAR file, and then also have a file within the TAR archive that has a filename of PHAR://*path to malicious PHAR archive that was uploaded* to form a full end to end payload and get RCE.

Overall I’d say this is an interesting bug but its exploitability is somewhat limited and depends highly on the underlying application it is used within.

3
Ratings
Technical Analysis

There appears to be a lot of hype at the moment surrounding this vulnerability given the recent Tweets from @jonaslyk on Twitter at https://twitter.com/jonasLyk/status/1347900440000811010 as well as the follow up article from BleepingComputer at https://www.bleepingcomputer.com/news/security/windows-10-bug-corrupts-your-hard-drive-on-seeing-this-files-icon/.

Whilst this bug is made out to sound like a catastrophic disaster in Windows that could result in data loss should a user browse to a malicious file path containing the string C:/:$i30: followed by a file name such as C:/:$i30:$bitmap, the reality is that, at least in my tests, this is not the case. In fact during my tests I found the following:

  1. The disk is not actually corrupted. If you try to access files on the disk, you can still interact with them and do things normally without any issues. Windows just somehow thinks that the disk is corrupted, even though it isn’t.
  2. Rebooting will case Windows to check the disk and try to repair it. If you skip this disk check, Windows will still think that the disk is corrupted, even though your computer will work fine. You will have to run a disk check by going to File Explorer, right clicking on the affected drive such as C:\, clicking Properties, then the Tools tab, and click Check under the Error Checking section. This will then require the computer to reboot, which should be pretty quick (a few seconds in my case for a clean Windows 10 20H2 VM), after which Windows will have self corrected itself and will no longer assume the disk is corrupt.
  3. You can trigger this remotely via handlers such as the file:// handler so this could be exploited remotely by embedding a HTML link into a web page that invokes the file:// handler on C:/:$i30:$bitmap. This will cause an immediate warning to display on the user’s computer that the drive is corrupted, which may be enough to convince them to reboot. Alternatively the user could just continue to use the computer and ignore the warning with no side effects.

So in conclusion this seems more like a logic/state error bug where Windows is tricked into thinking a drive is corrupted when it is not than any real serious issue, at least from the results that I am seeing in a VM. I don’t know if physical computers would be any different as I haven’t tested it on a physical machine, but I do not believe there would be any reason to believe the results would be different.

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

A hardcoded username of zyfwp with password PrOw!aN_fXp exists on Zyxel ATP, USG, USG Flex, and VPN firewalls running firmware versions prior to ZLD v4.60 Patch 1. Additionally NXC2500 and NXC5500 AP controllers running firmware versions prior to v6.10 Patch 1 are also affected. The zyfwp account was designed to deliver automatic firmware updates to connected access points via FTP. This means that it has administrative privileges and could be used to compromise the firewall itself and change its settings to allow the attacker to gain further access into an organization’s network.

Security researchers discovered that this account existed, along with its plaintext hardcoded password, whilst looking through the firmware of affected devices, as discussed at https://www.eyecontrol.nl/blog/undocumented-user-account-in-zyxel-products.html.

Note that there has been increased exploitation of this vulnerability in the wild as of January 6th as noted at https://threatpost.com/cybercriminals-exploits-zyxel-flaw/162789/ and https://isc.sans.edu/diary/26954.

2
Ratings
Technical Analysis

A nice little LPE technique which takes advantage of several issues as originally noted by James Forshaw at https://bugs.chromium.org/p/project-zero/issues/detail?id=2082. In particular, by running a program that communicates with the kernel via the CfCreatePlaceholders API, an attacker can exploit an issue within the cloud filter driver cldflt.sys, which runs in kernel mode, whereby placeholder files are not handled appropriately.

As James mentions within his writeup, several issues occur within cldflt.sys when creating placeholder files, which are described below:

  1. The FSCTL control code which is sent to the kernel mode filter driver to instruct it to create the placeholder file will result in the filter driver calling FltCreateFileEx() without specifying the IO_FORCE_ACCESS_CHECK or OBJ_FORCE_ACCESS_CHECK flags to force access checks to occur. As calling FltCreateFileEx() effectively calls IoCreateFileEx() with the IO_NO_PARAMETER_CHECKING flag set.

For more details on these parameters see https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iocreatefile which notes that if IO_NO_PARAMETER_CHECKING is used, the parameters are not probed to see if they reside in user mode memory or cause access violations. Looking at https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes also shows that the OBJ_FORCE_ACCESS_CHECK flag will enforce the permission checking of an object prior to using it even if the handle is being opened in kernel mode.

So effectively what is happening is that cause these flags are not being specified, the kernel is implicitly trusting the user’s input and failing to perform appropriate access checks prior to performing the file operation in kernel mode on the user’s behalf.

  1. The cloud driver takes in a path which is split up into a base sync path, which is checked for write access, and a filename component, which isn’t checked for path separators. So you can specify one base sync path but multiple path separators in the filename component and essentially trick Windows into thinking that you are writing to one directory that you have write access to, whereas in reality you are writing to a subdirectory of that directory that you might not normally have write access to (again remember that the access checks will be bypassed due to the write operation occurring with KeMode privileges).

  2. Whilst the call to FltCreateFileEx() uses the FILE_OPEN_REPARSE_POINT to block directly accessing a reparse point, that only prevents it from attempting to access a mount point directly. If you instead create a subdirectory within the mount point and point it at that instead, it will still access the mount point, allowing you to write the file anywhere you would like.

Combining this all together one can create an exploit that either a) Uses an existing directory that we have write permissions to, and then using the permission check error and the directory path error, we can write a file to one of the subdirectories we wouldn’t normally have access to, or one can use the reparse point bug instead to write a file to anywhere on the system.

Microsoft patched this bug in December 2020 by changing the HsmpOpCreatePlaceholders() function in cldflt.sys to add additional checks. I have only done a preliminary inspection of this function but it appears that there are some new checks for the path, specifically r.e the use of \ characters, and a few jumps were changed in their logic. Unfortunately as the function is rather large at 190 blocks and I don’t have the time to dive into this in depth right now this is as much as I was able to confirm. I also found that if you run the exploit on a patched system you will now get the error message: System.Runtime.InteropServices.COMException (0x8007017C): The cloud operation is invalid. (Exception from HRESULT: 0x8007017C), which was not returned previously when attempting to run the PoC from James Forshaw.

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

A command injection vulnerability in the network POST parameter of the /maint/modules/endpointcfg/endpoint_devicemap.php page on Fonality Trixbox Community Edition versions 1.2.0 through 2.8.0.4 allowed remote authenticated attackers to take complete control over the affected devices as the asterisk user, and then elevate to root by running sudo nmap --interactive followed by !sh from within nmap.

My personal opinion on this is that it is a very wide ranging vulnerability in terms of the number of versions affected. We are talking over 60% of the released versions of Fonality Trixbox Community Edition were affected by this vulnerability, although the main downside is that Fonality TrixBox Community Edition is no longer supported by its developers.

This creates an interesting question cause whilst telephony systems are known to run out of date and depreciated software (as is the case with many public service departments), I don’t know if this particular software would still be used in most departments or if they would have just moved on by this point. Particularly given that this software is the community edition I imagine most users would have moved on to other software by now, but we all know that, like Windows XP, some people will still cling to what they know is tried and true. That being said I would have to imagine that the numbers have diminished significantly in the time between the last release of Fonality TrixBox Community Edition and now.

Additionally the requirement for a user to be authenticated to exploit this vulnerability means that simply setting a strong password on affected devices will likely prevent them from being compromised by this vulnerability.

TLDR: An interesting vulnerability but seeing as the software is no longer supported and it does require authenticated access, its probably not something that should be at the top of your priority list unless you know you are running TrixBox Community Edition, in which case if you can’t upgrade it is recommended you ensure all devices have a strong password, as this will prevent users from easily being able to exploit this vulnerability.

2
Ratings
Technical Analysis

This was a stack overflow vulnerability within the UPNP daemon (/usr/sbin/upnpd) of NETGEAR R6700v3 routers running firmware versions V1.0.2.62 up to but not including V1.0.4.94 that was exploited by Pedro Ribeiro and Radek Domanski of Team Flashback in 2019’s Pwn2Own Tokyo competition. Note that whilst this vulnerability does require authentication to exploit, attackers can easily bypass this requirement via CVE-2020-10923, as was done in the Pwn2Own competition.

Successful exploitation grants the attacker the ability to change memory and settings on the target device, which was used in the Pwn2Own competition, and in the Metasploit module that was subsequently created, to reset the admin password back to its factory default of password, thereby allowing attackers to enable Telnet on the target device and gain a shell as the root user.

As a Metasploit module for this vulnerability exists which reliably results in RCE as root, it is strongly recommended to apply patches for this vulnerability. Do however keep in mind that as this vulnerability relies on UPNP, it is likely that an attacker would still need to be within your local network in order to exploit this vulnerability, though if they do exploit it they will gain full control over the router itself, which could end up allowing them to either gain an initial foothold into your network, or potentially hop between networks.

2
Ratings
Technical Analysis

This was an authentication bypass in NETGEAR R6700 versions V1.0.2.8 and prior that was exploited by Pedro Ribeiro and Radek Domanski of Team Flashback in 2019’s Pwn2Own Tokyo competition. It occurs when network adjacent computers send SOAPAction UPnP messages to a vulnerable Netgear R6700v3 router, which does not appropriately validate that the user is logged in prior to performing the requested actions.

Whilst this vulnerability in and of itself doesn’t allow for remote code execution, its important to note that it is an authentication bypass that allows one to access the router as the Administrator user. Usually after you get this level of access, its considerably easier to start cracking open the security of the device as now its assumed your the Administrator and want to make these changes willingly, so the device generally will not attempt to check as many of your requests before performing your desired action, which can lead to additional security bugs that grant you code execution on the device.

In this case this is exactly what happened and CVE-2020-10924 can be used in combination with this bug to gain RCE on any vulnerable NEATGEAR R6700 router running firmware version V1.0.2.8 or prior to gain full control over the target device. It is therefore strongly recommended to patch this vulnerability alongside CVE-2020-10924 on any affected devices.

2
Ratings
Technical Analysis

The server GET parameter of the /uapi-cgi/testaction.cgi page of Geutebruck G-Cam EEC-2xxx and G-Code EBC-21xx, EFD-22xx, ETHC-22xx, and EWPC-22xx devices running firmware versions <= 1.12.0.25 as well as firmware versions 1.12.13.2 and 1.12.14.5 is vulnerable to command injection when the type GET parameter is set to ntp. Attackers who successfully exploit this vulnerability can gain remote code execution as the root user, meaning that this a perfect vulnerability for attackers looking to gain an initial foothold into a network.

Additionally as these are security cameras, I imagine there are a lot of nasty things one could potentially do with these devices related to spying on companies and operations that could pave the way to more crimes down the line. So the effects of this attack on an enterprise could potentially go beyond just a network breach.

Fortunately this is an authenticated attack and it requires valid login credentials to exploit. Unfortunately though, these are the types of devices that people tend to set up and then forget about until its needed, so I wouldn’t be surprised if people were still running these cameras with the default credentials of root and admin.

2
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

Again this is all part of CVE-2017-0143 to CVE-2017-0147 which were all exploited in NSA’s exploit leak.

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

Though honestly you can just Google “WizardOpium” and find lots of articles such as https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/. This attack got a lot of news attention at the time due to its sophistication and the fact that it was used with a Windows kernel privilege elevation (see https://attackerkb.com/topics/2i67dR7P4e/cve-2019-1458 for more details on the kernel exploit), something that tends to only occur in advanced attacks due to the development effort required. Therefore its not hard to find articles discussing it being used in the wild.

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

This is pretty similar to CVE-2020-1020 and its possible they were used together in a single attack, although for now this is just my theory and without full evidence this should be taken with a healthy few grains of salt.

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Quick update to my previous analysis but this has now been reported as being exploited in the wild. Just goes to show that public research does help level the playing ground a bit since otherwise this bug would have likely been exploited privately without people knowing about it; early announcement gave people time to patch before this exploit started making the rounds.

See Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786 for proof of this being listed as exploited in the wild. The original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original Tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888. Also see @sjossi ’s original analysis where he points out more links to where this was originally announced as being exploited in the wild.

1
Technical Analysis

Reported as exploited in the wild as part of Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786. Original Tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

2
Technical Analysis

Reported as exploited in the wild at https://us-cert.cisa.gov/ncas/alerts/aa20-296a

1
Technical Analysis

Reported as exploited in the wild at https://us-cert.cisa.gov/ncas/alerts/aa20-296a

1
Technical Analysis

This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF

2
Technical Analysis

This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF

1
Technical Analysis

This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF

1
Technical Analysis

This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF

Also the public exploit for this has long since been available at https://github.com/ExpLife0011/CVE-2019-0803

2
Technical Analysis

This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF