The Feeling of Safety

Read Time:2 Minute, 12 Second

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

Endangered data in online transactions and how to safeguard company information

Read Time:5 Minute, 29 Second

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

[R1] Nessus Network Monitor 6.0.0 Fixes Multiple Third-party Vulnerabilities

Read Time:24 Second
Nessus Network Monitor leverages third-party software to help provide underlying functionality. One of the third-party components (OpenSSL) was found to contain vulnerabilities, and updated versions have been made available by the providers.

Out of caution and in line with best practice, Tenable opted to upgrade the bundled OpenSSL components to address the potential impact of these issues. Nessus Network Monitor 6.0.0 updates OpenSSL to version 1.1.1l to address the identified vulnerabilities.

Read More

Technical Analysis of CVE-2021-1732

Read Time:15 Minute, 29 Second

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

The Bug Report – December 2021

Read Time:8 Minute, 58 Second

Your Cybersecurity Comic Relief 

Why am I here? 

If you’re reading these words, CONGRATULATIONS! You’ve made it to 2022! And even better, you found your way to ATR’s monthly security digest where we discuss our favorite vulnerabilities of the last 30 days. Feel free to pat yourself on the back, get yourself a nice cup of coffee, tea, LaCroix (you fancy!) or if you’d rather choose violence, you can go straight for the energy drink. And now that we are comfortable and energized, let’s get rolling!  

CVE-2021-43798: Grafana path traversal

What is it? 

Per its Wikipedia entry, Grafana is a multi-platform open-source analytics and interactive visualization web application that is widely used in the industry, with paying customers such as Bloomberg, eBay, PayPal, etc. It was revealed in early December that a path traversal vulnerability allowed an attacker to access local files due to an improper sanitization of “../../../” in its plugin path.  

It also showcases one of the tightest disclosure timelines known to man:  

Who cares? 

Ok, we can hardly blame you for hearing about ANY vulnerabilities except for Log4Shell in the last 30 days.  However, if your organization is using this software, you probably should have followed the disclosure last month, lest your “/etc/passwd” files are now known to the whole internet. Beyond that, there are two interesting points you can ponder while swirling your eggnog in its glass (side-rant on the disgustingness of eggnog redacted). Given how easy it is to exploit, the mere fact of the vendor fixing the bug via their public GitHub seems to have been enough to bring attention to it and get public working POCs for this vulnerability in less than 3 days following the fix. If you’re curious about how more mature open-source code bases deal with this risk, projects like Chromium rely on a separate bug tracking infrastructure that can restrict who can access the bug reports (that will spell out the security risks and test cases) combined with public commit messages with simple phrasing meant to avoid attracting the attention on the security commits.  

Another interesting tidbit, the root cause of this bug is the misuse of a Go API to sanitize paths as discussed in this Twitter thread. It turns out the filepath.Clean function used to sanitize the input processed by the vulnerable code only removes excessive “../../” if the path is absolute. This is a common case of an API behaving as expected but leading to dangerous consequences. Do you know for sure the codebase of your organization is free of these problems? The impact of unpatched vulnerabilities here could be the accessing or leaking of extremely sensitive data.  *pondering becomes frantic*  

What can I do? 

Obviously update the software if you’re using it, and you can also use Sigma rules to detect attack attempts. In an ideal world, your analytics platform should not be exposed to the wide internetunlike these 87k instances, among whose 16k are still vulnerable according to Shodan. At minimum make sure your Grafana instance is behind a .htaccess prompt or similar. From a development perspective, security testing and unit tests should be leveraged to ensure the filtering you are putting in place is working the way it is intended to. And in the grand scheme of things, if you are going to process untrusted user input, don’t wing the filtering and apply thoroughly audited code patterns rather than disabling the warnings of your security tool…  

 

The Gold standard 

Does the walker choose the path, or the path the walker?” may have mused Garth Nix in his novel Sabriel. One thing is certain though, the path described above won’t be “walked” nor traversed by an attacker for the McAfee Network Security Platform (NSP) customers. These lucky fellows are already protected against path traversal attacks via a generic rule and can even be bestowed further protection with the creation of “custom attack” rules.  

CVE 2021-44228: Log4Shell 

What is it? 

Who could have known that parsing—and sometimes even executing—untrusted input was a bad idea? Well it turns out that Apache’s log4j logging code does exactly that, and if the logged string contains the magic characters $(jdni:…) it may even fetch and execute untrusted Java code. Iterations on this attack have also highlighted the possibility to leak local secrets stored in environment variables—such as AWS keys—and given the recursiveness of the processing, it also offers many ways to evade pattern-matching detection. 

Who cares? 

Pretty much everyone. You write Java and are into logging things? Yep, you should be on top of this. You use Java based applications/servlets? Well, there’s probably some logging of untrusted user input in there. Your corporate employer uses Java based appliances or services? Pour one for your SOC and IT folks who are probably having a blast over their holiday “break”. You get it, this problem impacts the whole industry, and in all likelihood, its effects will probably keep rippling out for the years to come. To make things worse, the bug is really easy to exploit. From pen testers to SOC analysts, “script-kiddies” to nation state actors, nearly everyone has begun to explore this attack vector and we have observed massive on-going attacks with a wide gamut of payloads, ranging from cryptominers to “rm -rf /* payloads and even a broken attempt to spread the Mirai worm. The worst is likely yet to come.  

What can I do? 

“Stranger Things” taught us that “You can’t spell America without Erica.” Similarly, you can’t spell Apache without Patch. Sort of.  Upgrade! Micro-patch. Monitor traffic. Hint: if you’re internal-only application suddenly makes LDAP requests towards a remote server in a country you have no operations in, maybe something fishy is going on…  

If you like chaos and and/or you are having a hard time convincing IT of the importance of this bug, get permission to demonstrate it for them! Then, set strings you can control (user-agent, twitter name, wifi SSID, …) to this $(jdni:ldap…) magic value and make it point to an IP:Port you control (or a third party service like Canarytoken if you trust them). If you detect hits on that address, you can start having a fun conversation about the necessity of upgrading their tech stack with the owners of the incoming addresses. This is where asking for permission first becomes extremely important, as if you indiscriminately put the magic string all over the places to see what happens (as you may have seen on various social media platforms), it’s likely that eventually someone will reach out to have a “fun” conversation with you and ask about that funky user-agent of yours. Obviously, before pulling a stunt like this consider that the last thing you want for Christmas is a CFAA (Computer Fraud and Abuse Act) complaint delivered right to your doorstep.  

The Gold standard 

McAfee Enterprise customers are protected from many different angles (for the specifics, please visit this Knowledge Base article):  

Expert Rules on Endpoint Security (ENS) can pick-up dangerous patterns in memory as described in this blog 

Endpoint Security (ENS), VirusScan Enterprise (VSE), McAfee Web Gateway (MWG) can provide generic detection under the tile Exploit-CVE-2021-44228.C via a “Potentially Unwanted Software” detection. This detection is also augmented by a list of hashes of samples related to in-the-wild campaigns exploiting this vulnerability.   
Network Security Platform (NSP) can also detect the attack via User-Defined signature (provided in the KB article linked previously) 
MVISION Endpoint Detection and Response (EDR), McAfee Active Response (MAR) can also be used to look for vulnerable systems with Real-Time Search (RTS) queries 
McAfee SIEM got an update (Exploit Content Pack version 4.1.0) that will raise an alarm on potential exploit attempts. MVISION Insights is also providing valuable information under the Threat Campaign “Log4Shell – A Log4j Vulnerability – CVE-2021-44228”. See Insight Preview. 

CVE-2021-43527: Big Sig 

What is it? 

Big Sig sounds like the nickname Freud’s mother gave him. This bug is no less compelling. Early this December, Google Project Zero blogged about a vulnerability they found in Mozilla’s Network Security Services (NSS) with a CVSS score of 9.8, according to NIST’s National vulnerability database page. There is a heap overflow in the processing of certain signatures (DER-encoded DSA and RSA-PSS signatures). To put it simply, the NSS is a collection of cryptographic libraries that enable developers to use safer/heavily tested implementations of cryptographic primitives and standards (for encryption of communication, verification of the authenticity of data, and so on). The feature where the bug was found is responsible for the verification of signatures that prove the authenticity of data using various public cryptography schemes. This type of function is typically used to sign emails or documents to confirm their actual authors. Something really interesting about this bug is its relative simplicity but also its long existence; according to Project Zero’s blog, this bug was exploitable going all the back to 2012. The vulnerable code path just happened to fall between the cracks where various fuzzers used by Mozilla overlap. 

Who cares? 

If you like your signatures to be verified, and rely on the NSS library to do so, you should definitely have a look at the advisory and use the latest version of the software (NSS version 3.73/3.681 ESR or later). Firefox seems unaffected, but other software that parses signatures might be impacted (Thunderbird, LibreOffice, Evolution, Evince and more).  

What can I do? 

As usual, you want to make sure any software you are using that might be vulnerable is updated to its latest version. The patch was released on December 1st so, for starters, you’d want to make sure potential vulnerable software received an update after this date. It would also help to know which software relies on this library; while there is no magic bullet, references to files such as nss3.dll on Windows or libnss3.so on Linux are a good starting point. Beyond that, the best call is to look at release notes and potential list of third-party libraries used in any given application you may use. If you use the vulnerable library in in your own product, update the code or backport the patch. 

The Gold standard 

Have you checked out our bulletins? They’re a great source of information for the critical vulnerabilities you may have missed! This may include applications that will be deploying fixes for CVE-2021-43527. 

The post The Bug Report – December 2021 appeared first on McAfee Blogs.

Read More

[R1] Tenable.sc 5.20.0 Fixes Multiple Vulnerabilities

Read Time:28 Second
Tenable.sc versions 5.14.0 through 5.19.1 were found to contain a remote code execution vulnerability which could allow a remote, unauthenticated attacker to execute code under special circumstances. An attacker would first have to stage a specific file type in the web server root of the Tenable.sc host prior to remote exploitation.

Also, Tenable.sc leverages third-party software to help provide underlying functionality. One of the third-party components (Apache) was found to contain vulnerabilities, and updated versions have been made available by the providers.

Read More

Welcome McAfee Forward—the Future of Online Protection Today

Read Time:1 Minute, 47 Second

With digital life-changing so rapidly, it’s time for a new way to protect it. Welcome to McAfee Forward—the future of online protection today. 

As all that change reshapes how we spend our time online, we believe that one thing remains constant: meaningful protection is a personal right. Your right. That’s how we see it here at McAfee, and we want you to go forward and enjoy your digital life with confidence. Confident that you’re safe as you bank and shop online, sure. Yet also confident as you consult your doctor online, track your fitness routines, order a pizza with the sound of your voice, start your car with your smartphone, and simply do what’s next—the umpteen other innovations yet imagined, all thanks to the internet.  

So what does the future of online protection look like? You. While different technologies may come and go, the one thing that won’t change is you. The person using them. That’s why our focus is on you, your privacy, identity, and overall security, no matter what device, app, or platform you’re doing or what you’re doing it on. 

No doubt about it, life online will continue to change how we go about our day in lively and unexpected ways. You have a right to enjoy it all. And you can leave that to us. We thrive on what’s new and different—and then protecting it so you can get the most out of it.  

That future of online protection is indeed here today. We’ve already rolled out major updates and industry firsts that look out for you online, particularly your privacy and identity. There’s much more to come in the weeks and months ahead. Because you have a right to a life that’s always safe and enjoyable online, whatever shape it takes in the days to come.  

Here’s to living that life with confidence, and to what’s on the horizon. Through it all, we have your back. 

The post Welcome McAfee Forward—the Future of Online Protection Today appeared first on McAfee Blogs.

Read More