For years, “The Spine Collector” has been haunting publishers around the world, attempting to steal manuscripts by famous authors.

Read more in my article on the Hot for Security blog.

Read More

Security researchers say they have seen a “massive wave” of hackers exploiting the comment feature in Google Docs to spread malicious content into the inboxes of unsuspecting targeted users.

Read more in my article on the Tripwire State of Security blog.

Read More

The internet’s greatest feat? Fundamentally shifting how we live. Once a revelation, it quickly set our long-standing beliefs about how we work, play, and connect into a whole new context. 

Today, the shifts come fast. Video meetings once felt alien. Now, they’re part of our routine. We’ve gone from setting doctor’s appointments online to actually seeing the doctor online—and from family visits to seeing everyone in seconds on a screen.  

At McAfee, we’ve seen our share of shifts as well. Looking back across our thirty-plus years, we were among the first to deliver antivirus technology. First to create a biometric password manager. First to give people an intuitive Protection Score, and so much more. And we’re not stopping. We’re protecting people and their ever-changing lives. That means covering all your life online, from security to privacy to identity, in a way that adds to your confidence and enjoyment too. 

Confidence and enjoyment. Those two words mark our next shift in online protection. We’re bringing those feelings to life across the McAfee experience. And it’ll redefine the way you stay safe online.  

Safety has an unmistakable feeling. As we bring that feeling to online protection, you’ll see a remarkable evolution. It will look and act in bold new ways, guide you, reassure you, and most importantly, keep you safe. In all, it’s a new breed of online protection that’s helpful, even thoughtful, in the ways it looks out for you. 

And this evolution is already underway. You’ll find that feeling in everyday moments as we make them simpler, freer, and safer—such as paying your bills at a coffee shop, managing your family’s healthcare from your laptop, and booking flights to catch up with old friends. Across them all, our protection will have your back, and even offer guidance when needed, all while you do you—wherever your day takes you and no matter what “online” looks like next. 

There’s simply so much to see out there. And with us by your side, you’ll feel safe and stay that way. Life online will continue to surprise us. In the best of ways. And people have a right to enjoy every moment of it, confident that they’re safe and secure, in ways they can point to and feel.  

That’s our next big shift. Giving you the unmistakable feeling of safety. You deserve it. More than that, it’s your right. And we’re proud to bring it to you. 

The post The Feeling of Safety appeared first on McAfee Blogs.

Read More

This blog was written by an independent guest blogger.

Online transactions are essential for every modern business. From online shopping to banking, transferring funds, and sending invoices, online transactions ensure utter convenience and efficiency.

However, the familiarity of making financial transactions online can make people forget about security and all the dangers that they may be facing. On top of that, new cybersecurity threats keep popping up constantly.

That’s why it’s crucial to have a robust IT security strategy in place.

How safe are your company’s online transactions?

Source; Pexels

From hardware or software issues and hidden backdoor programs to vulnerable process controls, weak passwords, and other human errors, many problems can put your transactions at risk and leave the door open to cybercriminals.

Did you know that human error is the main culprit of 95% of data breaches? Many people still don’t realize the dangers of phishing, malware, ransomware, unpatched software, and weak passwords. They could expose your sensitive data and put you, your employees, clients, and customers at risk of identity theft and fraud.

Believe it or not, pay stubs are among the most common vulnerabilities because many companies don’t store them carefully, risking theft of their employee data and confidential files.

That’s why savvy businesses have started using online generators for making stubs. With a paystub generator, you can create and store your pay stubs online, so you don’t have to keep them in your system, preventing cybercriminals from gaining access to your sensitive data.

No cybersecurity experts

Cybersecurity is a complex issue that requires comprehensive knowledge. Sadly, most companies don’t hire any cybersecurity experts. What they don’t realize is that they could be supercharging their productivity.

What can a business do to improve its productivity?

By putting experts in charge of  cybersecurity, companies can keep other employees productive. They can work with up-to-date  technology, reduce their workload, work  smarter, and improve their performance.

A cybersecurity team can even train your employees and teach them how to identify and avoid threats. This way, your employees won’t make security mistakes, and can focus on their core competencies.

How to protect your transactions

Given that the average cost of a data breach is $3.86 million, implementing proper security measures  to protect your transactions is a no-brainer. Here are some of the best ways to do so.

Use a Secure Sockets Layer

Secure Sockets Layer (SSL) is a standard security protocol that encrypts the connection between a web browser and a server. It prevents a third party from intercepting the data that is exchanged between the two.

This is especially  beneficial for financial transactions as all the data, including credit card information, remains private. .

An SSL certificate is beneficial  for your SEO as well, since Google uses HTTPS as a ranking signal.

To secure your transactions with an SSL certificate, you need to purchase the right one for your business and install it on your server with the help of your web host manager. This only takes a few clicks, because an SSL certificate is a text file with encrypted data.

Implement multi-layered protection

A multi-layered security approach is a defense mechanism for cybersecurity protection. It’s about  implementing multiple components to protect your entire IT infrastructure.

If a potential hacker finds a loophole and tries to break into your system, they will be prevented from doing so by another layer of security. .

Some of the most important security layers include the network (IP and ICMP), the application (e.g., HTTPS and DNS), data link (e.g., Ethernet and MAC), the session (WEB sockets), transport (SSL, TCP, and UDP), perimeter (firewalls), and physical layers (securing endpoint devices).

Avoid storing payment data from your customers

If you store payment details from your customers, a potential data breach could expose their personal and sensitive information. This could severely damage your company’s reputation.

So, once a customer completes a purchase, make sure there are no logs of their financial information

If you want to ensure a seamless shopping experience by allowing your customers to save payment details for future purchases, you should use a reliable e-commerce platform and a secure payment processor. This will  help you detect and prevent potential cyberattacks.

Use data encryption

Data encryption is the key to keeping sensitive data private. It ensures integrity, authentication, and non-repudiation.

There are three main types of data encryption:

3DES (Triple Data Encryption Standard) — 3DES uses three 56-bit keys to encrypt data, but it takes a long time. Its predecessor, DES (Data Encryption Standard), is no longer secure  on its own.
AES (Advanced Encryption Standard) — AES is the best and most widely-used type which uses symmetric key encryption where only one key can encrypt and decrypt data. It’s the most secure method you can use.
RSA (Rivest-Shamir-Adleman) — RSA uses an asymmetric key encryption (one public key to encrypt data and one private key to decrypt). This is time-consuming but great for verifying digital signatures.

Consider tokenization

Tokenization involves replacing sensitive data, such as credit card numbers, with random strings of characters (tokens) that have no meaningful value. If a hacker were to steal tokenized data, they could not exploit it.

Furthermore, tokenization removes the original data from the system and serves only as a reference. That’s quite different from data encryption, where the data is preserved but can only be accessed with the right key.

Use electronic signatures

Like data encryption, electronic signatures ensure integrity, authentication, and unforgeability.

They also increase security and speed up transactions by enabling the authentication of  electronic documents and online forms in seconds.

Create a verification process

Verifying accounts, addresses, and transactions helps  you prevent identity theft and fraud.

An AVS (Address Verification Service) can help you verify your customers’ billing addresses. At the same time, a card security code (a CVV number) is the best way to verify bank accounts and transactions.

Don’t forget to enable 2FA (Two-Factor Authentication) and MFA (Multi-Factor Authentication), which are among the best ways to secure user authentication protocols. They provide additional protection for the login process, and effectively prevent fraudulent login attempts.

Conclusion

These are the most proven methods to keep your online transactions and company information private, but you should consider other security tips, too.

Don’t forget to comply with the PCI DSS before you start accepting online payments. This way you can eliminate any vulnerabilities beforehand and ensure that your customers’ data remains safe and secure.

Read More

Introduction

In February 2021, the company Dbappsecurity discovered a sample in the wild that exploited a zero-day vulnerability on Windows 10 x64.

The vulnerability, CVE-2021-1732, is a win32k window object type confusion leading to an OOB (out-of-bounds) write which can be used to create arbitrary memory read and write capabilities within the Windows kernel (local Elevation of Privilege (EoP)). Memory exploitation generally requires a read, write, and execute primitive to bypass modern exploit mitigations such as DEP, ASLR and CFG on hardened operating systems such as Windows 10. A data-only attack requires only a read and write primitive as it does not seek to execute malicious code in memory, but rather manipulates data structures used by the operating system to its advantage (i.e., to achieve elevated privileges).

Kernel exploits are usually the most sophisticated attack as they interact directly with the Windows kernel. When such attacks are successful, they are critical because they provide high privileges to the attacker, which can be used to increase the impact of the overall exploit chain. In this case the exploit is a Local Privilege Escalation (LPE) that targets 64-bit Windows 10 version 1909. The original sample discovered was compiled in May 2020 and reported to Microsoft in December 2020. While searching for additional findings we went through a public exploit published in March of 2021 by a researcher. Having this code publicly available may raise the potential for additional threat attackers. While we have not found clear evidence demonstrating malicious use of the proof-of-concept (POC), we did discover some variants being tested and uploaded to VirusTotal.

In this blog post, McAfee Advanced Threat Research (ATR) performed a deep dive into the analysis of the vulnerability, to identify the primitives for detection and protection. The exploit is novel in its use of a new win32k arbitrary kernel memory read primitive using the GetMenuBarInfo API, which to the best of our knowledge had not been previously known publicly.

CVE-2021-1732 Deep Dive

Exploitation of CVE-2021-1732 can be divided into six stages with the end goal of escalating a process’ privileges to System. The following diagram shows the stages.

Figure 1 – Six stages of CVE-2021-1732

Before we dive into the details, we must give some background to win32k exploitation primitives which are used in the exploitation of CVE-2021-1732.

Win32K Background

Win32k is a Graphical (GUI) component of the Microsoft Windows Subsystem, most of which exists in the kernel for performance reasons. It is used for graphical print of the Windows OS desktop. However, due to the win32k architecture, the kernel component of win32k still needs to be able to make calls to user mode through user-mode callback functions to facilitate window creation and management.

Kernel user-mode callbacks have been well researched as far back as 2008 and 2010, with a very comprehensive analysis in 2011 by Mandt. A win32k kernel function such as xxxCreateWindowEx will make a callback function such as xxxClientAllocWindowClassExtraBytes through the user process PEB KernelCallbackTable.

When the user-mode callback has completed, NtCallbackReturn executes and passes the expected return parameter back to the kernel. Due to the stateless nature of these callbacks, many vulnerabilities have been discovered related to the locking mechanisms on the objects leading to use-after-free (UAF) exploitation.

Win32k has been one of the most exploited components in the Windows kernel accounting for 63% of vulnerabilities from 2010 to 2018, due to its large attack surface of syscalls relative to ntdll syscalls. Win32k vulnerabilities are generally turned into data-only attacks using a read/write kernel primitive by using a desktop object known as a tagWND data structure.

There are two aspects to data-only attacks:

Discovering a vulnerability.
Leveraging existing or new read/write primitives using specific OS APIs on object fields such as tagWND.cbWndExtra.

The tagWND data structure has two fields which make it a prime target for reading/writing within kernel memory; tagWND.cbWndExtra and tagWND.ExtraBytes. When a window is created using CreateWindowEx, it is possible to request additional bytes of memory directly after the tagWND object in memory through the cbWndExtra field in the WNDCLASSEXA structure when registering the window class.

The number of extra bytes is controlled by the cbWndExtra field, and the allocated additional memory address is located at the ExtraBytes field. The read/write primitive is created as follows:

Discover a vulnerability such as a UAF, which will allow you to write to a tagWND object in memory called WND0.
Allocate another tagWND object called WND1 near the previously corrupted WND0 in memory.
Overwrite WND0.cbWndExtra to a large value such as 0xFFFFFFF.
Call an API such as SetWindowLongPtr on WND0 which will write OOB to fields within WND1.

Win32k kernel user-mode callbacks have been exploited many times by leveraging tagWND read/write capabilities within the Windows kernel for escalation of privileges such as CVE-2014-4113, CVE-2015-0057, MS15-061, CVE-2016-7255 and CVE-2019-0808.

Win32k Exploit Primitives

Several primitives have been observed in the CVE-2021-1732 exploit used by the attackers; additionally, it is worth mentioning that some of them are new and not previously seen in the wild.

Prior to Windows RS4 it was trivial to leak tagWND kernel addresses using multiple techniques, such as calling HMValidateHandle to copy tagWND objects from the kernel to user desktop heap. The latest version of Windows 10 has been hardened against such trivial techniques.

However, using the spmenu kernel address leak technique and relative tagWND desktop heap offsets, once a vulnerability is discovered to overwrite a tagWND.cbWndExtra field, it is possible to achieve kernel read/write capabilities without leaking the actual tagWND kernel addresses. The spmenu technique in this exploit was used here and here, but we are not aware of the GetMenuBarInfo API ever being used before in a win32k exploit.

The following diagram shows the primitives used in CVE-2021-1732.

Figure 2 – CVE-2021-1732 Primitives

Existing Windows OS Mitigations

Great work has been done to harden the security of win32k against EoP attacks with new and improved mitigations by the Microsoft OSR team, Mandt, Google Project Zero, Schenk and Dabah.  These mitigations include:

Type isolation (all same type objects tagWND being used).
Win32k filtering (limited to Edge browser and not process wide but since this research there have been many improvements on win32k API filtering capabilities such as the addition of _stub_UserSetWindowLong and _stub_UserSetWindowLongPtr _stub_UserGetMenuBarInfo in win32k.sys).
Fragmenting kernel desktop heap and removal of kernel addresses in the user desktop heap (can use relative offsets within user and desktop heaps described later in the blog).
Removal of data type symbols from win32k drivers (obfuscation rather than mitigation).

In the context of a malicious process exploiting CVE-2021-1732, the above mitigations provide no protection. However, it does not impact Google Chrome as it disallows win32k calls (Windows 8 and higher), or Microsoft Edge as it applies win32k filtering on the relevant APIs.

Triggering the Vulnerability and Patch Analysis

When a window is created using CreateWindowEx API, a tagWND object is created by the Windows operating system. This window, as explained above, can be created with a parameter to allocate extra memory using cbWndExtra.

During the windows creation process (CreateWindowEx API) a callback named xxxClientAllocWindowClassExtraBytes is triggered to allocate space in the user mode desktop heap for the tagWND.ExtraBytes (offset 0x128) per the tagWND.cbWndExtra (offset 0xc8) value size (see figure 3 and 4 below for WND1).

Figure 3 – WND1 Kernel tagWND – User mode copy located at offset 0x28
Figure 4 – WND1 User Mode tagWND

The location of this memory is stored as a user mode memory pointer to the desktop heap and placed at tagWND.ExtraBytes. It is then possible to convert the normal window to a console window using NtUserConsoleControl which will convert that user mode pointer at tagWND.ExtraBytes to an offset value which points into the kernel desktop heap (see figure 5 below for WND0). It is this change in value at tagWND.ExtraBytes (window type confusion) that can be exploited for an OOB write during the xxxClientAllocWindowClassExtraBytes callback window.

Figure 5 – WND0 User Mode tagWND
Figure 6 – Triggering the type confusion vulnerability within win32kfull!xxxCreateWindowEx

Per figure 6 above the following steps are required to trigger the vulnerability:

Get a pointer to the HMValidateHandle inline function within user32.dll.
Hook xxxClientAllocWindowClassExtraBytes within the PEB KernelCallBack table.
Create multiple windows (we will just use the first two WND0 and WND1 created), using the CreateWindowEx API, so that two windows are created in close memory proximity.
Call HMValidateHandle on WND0 and WND1 which will copy their objects from the kernel desktop heap to user desktop heap. At tagWND+0x8 an offset is stored into the desktop heap; this offset is the same for the user and kernel desktop heaps. The exploit uses these offset values to calculate the relative distance between WND0 and WND1 in the kernel desktop heap which is needed later for reading and writing OOB. Per table 1 below, by using these offsets there is no requirement to leak the actual WND0 and WND1 kernel addresses since read and writes can be done relative to the offsets (user and kernel desktop heaps have the same offsets).

Table 1 – User and Kernel Desktop heaps have the same offsets

5. WND0 is then converted to a console window by calling NtUserConsoleControl which converts WND0.ExtraBytes from a user desktop heap pointer to an offset within the kernel desktop heap. This is needed later so that WND0 can write OOB to WND1.

6. Create malicious window WND_Malicious using the CreateWindowEx API

During the window creation the callback xxxClientAllocWindowClassExtraBytes API is executed to request user mode to allocate memory for WND_Malicious.cbWndExtra and pass the user desktop heap pointer back to the kernel function win32kfull!xxxCreateWindowEx.
xxxClientAllocWindowClassExtraBytes has now been hooked and we do the following before returning to win32kfull!xxxCreateWindowEx:

Call NtUserConsoleControl to convert WND_Malicious to a console window so converting its WND_Malicious.cbWndExtra from a user desktop heap pointer to an offset within the kernel desktop heap.
Finally call NtCallbackReturn which completes the callback and returns a single value to xxxClientAllocWindowClassExtraBytes. Instead of passing the user desktop heap pointer as expected by xxxClientAllocWindowClassExtraBytes back to the kernel we pass the value at WND0+0x08 which is the kernel desktop heap offset to WND0 per figure 7 below. Now anytime we call SetWindowLongW on WND_Malicious we will be writing to WND0.

Figure 7 – WND_Malicious

Patch Analysis

The vulnerability lies in the fact that win32kfull!xxxCreateWindowEx does not check whether the window type has changed between the time it initiates the xxxClientAllocWindowClassExtraBytes and gets the response from NtCallbackReturn.

When we call NtUserConsoleControl with WND_Malicious in the hook above, xxxConsoleControl checks if tagWND+0xE8 flag has been set to 0x800 to indicate a console window per figure  below. As WND_Malicious was created as a normal window, xxxConsoleControl allocates memory at an offset within the kernel desktop heap and then frees the user desktop heap pointer existing at WND_Malicious.ExtraBytes (0ffset 0x128). It then places the offset to this new allocation in the kernel heap at WND_Malicious.ExtraBytes (0ffset 0x128) and sets the tagWND+0xE8 flag to 0x800 to indicate it’s a console window.

After returning from the callback when we issued NtCallbackReturn above, xxxCreateWindowEx does not check that the window type has changed and places the WND0+0x08 at WND_Malicious.ExtraBytes per figure 9 below. The RedirectFieldpExtraBytes checks the WND_Malicious.ExtraBytes initialized value but it is too late as WND0+0x08 has already been written to WND_Malicious.ExtraBytes (offset 0x128).

Figure 9 – win32kfull!xxxCreateWindowEx (vulnerable version)

The patched win32kfull.sys has updated xxxCreateWindowEx to now check the ExtraBytes initialized value before writing the returned value from user mode to tagWND. ExtraBytes (offset 0x128) per figure 10 below.

Figure 10 – win32kfull!xxxCreateWindowEx (patched version)

Figure 11 below shows that tagWND. ExtraBytes is initialized to zero within xxxCreateWindowEx during normal window creation.

Figure 11 – tagWND. ExtraBytes initialization for normal window

Figure 12 below shows that tagWND. ExtraBytes is initialized to the new offset value in the kernel desktop heap within xxxConsoleControl during console window creation. RedirectFieldpExtraBytes simply checks this initialized value to determine if the window type has changed. In addition, Microsoft have also added telemetry for detecting changes to the window type flag in the patched version.

Figure 12 – tagWND. ExtraBytes initialization for console window

tagWND OOB Write

The vulnerability within the xxxCreateWindowEx API allowed the WND_Malicious.ExtraBytes field be to set to a value of WND0 offset within the kernel desktop heap. Now any time SetWindowLongW is called on WND_Malicious it will write to WND0. By supplying an offset of 0xc8, the function will overwrite the WND0.cbWndExtra field to a large value of 0XFFFFFFF per figures 13 and 14 below.

This means it can write beyond its tagWND structure and ExtraBytes in kernel memory to fields within WND1. In addition, WND0.ExtraBytes is also overwritten with the offset to itself so calls to SetWindowLongPtrA on WND0 will write to an offset in kernel desktop heap relative to the start of WND0.

Figure 13 – OOB Write from WND_Malicious to WND0
Figure 14 – WND0 cbWndExtra overwritten with 0xFFFFFFF by WND_Malicious OOB write

Kernel Address Leak

Now that the WND0.cbWndExtra field has been set to a very large value (0xFFFFFFF), anytime SetWindowLongPtrA is called on WND0 it will write into the adjacent WND1 in kernel memory per figure 15 below. By writing to specific fields in WND1 we can create a kernel address memory leak as follows:

Write a value of 0x400000000000000 to WND1 style field to temporarily change it to a child window per figures 15 and 16 below.
Calling SetWindowLongPtrA API on WND0 with a value of -12 (GWLP_ID) now allows the spmenu field (type tagMENU) of WND1 to be overwritten with a fake spmenu data structure since we have changed it to be a child window per figure 15 and 17 below.
Per SetWindowLongPtrA API documentation, the return value will give us the original value at the offset overwritten, i.e., the spmenu data structure pointer which is a kernel memory address. So, we now have leaked a pointer to a spmenu (type tagMENU) data structure in kernel memory and replaced the pointer in WND1.spmenu with a fake spmenu data structure within user desktop heap per figure 17 below.

Figure 15 – OOB Write from WND0 to WND1 to Leak Kernel Address
Figure 16 – WND1 Style field before and after writing 0x4000000000000000
Figure 17 – spmenu kernel memory address pointer leaked and subsequently replaced by a user mode address pointing to a fake spmenu data structure

Kernel Arbitrary Read

Using the spmenu data structure kernel pointer leaked previously we can use the layout of this data structure and the GetMenuBarInfo API logic to turn it into an arbitrary kernel memory read per figures 18,19 and 20 below.

Figure 18 – Kernel Arbitrary Read using fake spmenu and GetMenuBarInfo
Figure 19 – Fake spmenu data structure in user desktop heap with original spmenu leaked kernel pointer at crafted location to enable arbitrary read using GetMenuBarInfo API
Figure 20 – WinDbg command to show location within spmneu data structure that is deferenced by xxGetMenuBarInfo

As you can see from the xxxGetMenuBarInfo function in figures 21 and 22 below, by placing our leaked kernel address at the right location in our fake spmenu data structure we can create an arbitrary kernel memory read when calling GetMenuBarInfo.

Figure 21 – win32kfull!xxxGetMenuBarInfo
Figure 22 – GetMenuBarInfo data structure populated return values per normal spmenu and fake spmenu (leaks kernel address)

Kernel Arbitrary Write

An arbitrary kernel write primitive can be easily achieved now by writing our destination address to WND1.ExtraBytes field by calling SetWindowLongPtrA on WND0 which will write OOB to WND1 relative to the offset we specify per figure 23 below

In this case the offset is 0x128 which is ExtraBytes. Then simply calling SetWindowLongPtrA on WND1 will write a specified value at the address placed in the WND1.ExtraBytes field. The arbitrary write is achieved because WND1 is a normal window (has not been converted to a console window like WND0 and WND_Malicious) and so will write to whatever address we place in WND1.ExtraBytes.

Figure 23– Kernel Arbitrary Write for What-Write-Where (WWW)

Data Only Attack

The arbitrary kernel read and write primitives can be combined to perform a data-only attack to overwrite a malicious process EPROCESS token with that of PID 4 which is System for an escalation of privilege (EoP).

The original spmenu kernel address leaked previously has a pointer to WND1 at offset 0x50 per figures 24 and 25 below. Through multiple arbitrary reads using the GetMenuBarInfo on our fake spmenu data structure with this WND1 kernel address we can eventually read the PID 4 System EPROCESS token.

Figure 24 – Combining fake spmenu with GetMenuBarInfo arbitrary read to get PID 4 token
Figure 25– Original spmenu with WND1 kernel address pointer at offset 0x50

By placing the destination address (malicious process EPROCESS token) at WND1.ExtraBytes then the subsequent call to SetWindowLongPtrA will write the value (PID 4 – System EPROCESS token) to that address per figures 26 and 27 below.

Figure 26 – EPROCESS Token swap
Figure 27 – Overwriting WND1.ExtraBytes with address of EPROCESS token

The exploit then restores overwritten data structure values once the EoP is complete to prevent a BSOD (Blue Screen of Death).

Conclusion

In this report, we undertook a deep analysis of CVE-2021-1732 which is a Local Privilege Escalation on Windows 10. Windows kernel data-only attacks are difficult to defend against, as once a vulnerability is discovered they use legitimate and trusted code through specific APIs to manipulate data structures in kernel memory.

The win32k component has been hardened through great work by Microsoft against read/write primitives, but there are still opportunities for exploitation due to its large attack surface (syscalls and callbacks) and lack of win32k filtering on a process-wide basis. It would also be great to see a system wide win32k filtering policy capability within Windows 10.

Patching is always the best solution for vulnerabilities, but a strong defense strategy such as threat hunting is also required where patching may not be possible, and to detect variants of vulnerabilities/exploits being used by campaigns.

The post Technical Analysis of CVE-2021-1732 appeared first on McAfee Blogs.

Read More