Akamai’s Perspective on March’s Patch Tuesday 2023
Grab your sporks and prepare your plates, we’re slicing into some fresh PT (peach tarts, obviously.) As we do every month, Akamai Security Intelligence Group set out to look at the more intriguing vulnerabilities that were patched — and this month was full of treats.
There are approximately 80 patched CVEs this month, seven of them critical and five with a high CVSS score of 9.8. Two of the patched CVEs are also said to have been used in the wild, designating them as patched zero-day vulnerabilities. There are also three patches for CVEs reported by our very own Ben Barnea; more to come on that in the future.
In this report, we’ll assess how critical the vulnerabilities really are and how commonplace the affected applications and services are, and we’ll provide a realistic perspective on the bugs that were fixed. Be on the lookout for these insights in the days after every Patch Tuesday. You can also see a quick real-time overview on the day of the patch on our Twitter account.
This is an updating report and we’ll add more information to it as our research progresses — stay tuned!
In this report, we’re focusing on the following areas in which bugs were patched:
Vulnerabilities exploited in the wild
CVE-2023-23397
This is a critical vulnerability in Microsoft Outlook that was detected by CERT-UA. Microsoft assessed that it was used by a Russian-based threat actor in attacks across Europe. The vulnerability allows attackers to send a specifically crafted email, which will cause an outgoing authentication attempt to an attacker-controlled IP, leaking the recipient’s Net-NTLMv2 hash (which can then be used in NTLM relay attacks.) MDSec has a nice write-up about the vulnerability.
The vulnerability is quite major, as it is triggered the moment the mail client retrieves the email, prior to the preview panel or any other user interaction. As such, we recommend patching your Outlook clients as soon as possible.
An additional mitigation that was recommended by Microsoft is to add users to the Protected Users Security Group, as it prevents NTLM authentication entirely. This can impact other applications and services in the domain, so beware. Microsoft also released a script to check if your organization was targeted using the vulnerability.
In addition, we recommend segmentation as another form of possible mitigation. You can restrict users from authenticating (using Netlogon or SMB) to unknown servers (especially on the internet) and restrict the outgoing traffic to the machines and servers that should handle it inside your network. Network visibility is crucial for this, so don’t try to segment without it; you might impact your network negatively.
CVE-2023-24880
A vulnerability in Windows SmartScreen, allowing bypass of the SmartScreen warning on files downloaded from the internet. According to Google TAG, they’ve seen this vulnerability abused in the wild by Magniber ransomware. Google TAG also provides a root cause analysis of the code that creates the vulnerability. Basically, attackers can add a malformed Authenticode signature to executables, causing an error during its parsing. The default behavior in Windows Explorer is to ignore the errors and proceed to running the executable, without displaying a SmartScreen warning.
Remote Procedure Call Runtime
There is one critical vulnerability in the Remote Procedure Call (RPC) runtime CVE-2023-21708. The vulnerability seems to be in the OSF_CASSOCIATION::ProcessBindAckOrNak, which is also the vulnerable function from CVE-2022-26809. We assume that the patch for CVE-2022-26809 was incomplete. To trigger the vulnerability, the attacker must be able to force the server to send an RPC request to the attacker as the vulnerability is located in the client-side code of the RPC runtime.
MSRC also recommend blocking TCP port 135 (the endpoint mapper’s TCP endpoint) at the network’s perimeter firewall as a possible mitigation to the vulnerability. Since the vulnerability is in RPC, blocking just that port may not be enough (in fact, the FAQ for CVE-2022-26809 mentions that the proof of concept for the CVE was implemented using RPC over SMB). Therefore, we also recommend blocking other ports that can serve RPC — as a rule of thumb, that would be TCP port 445 for SMB, and port 135 for the RPC endpoint mapper and any ephemeral port, which are often used as dynamic RPC endpoints.
We also recommend restricting the outgoing ports from the network, as the attack is on the client side of the RPC runtime. Having network visibility is crucial for this, as you do not want to block something that is necessary for normal operations.
In case you have to leave those ports open for certain servers, we recommend employing ringfencing/DMZ policies internally on those servers, so they can’t be used to spread inside the network if they do get breached somehow.
Vulnerabilities reported by Akamai
In addition to the critical RCE vulnerability, there are three new RPC runtime vulnerabilities that were discovered by our team — CVE-2023-24908, CVE-2023-24869, and CVE-2023-23405.
The vulnerabilities can be used to achieve remote code execution (RCE) against all Windows machines. The vulnerabilities received lower scores as they require sending multiple packets over a long period. Following responsible disclosure guidelines, we will share technical information next month.
Internet Control Message Protocol (ICMP)
There’s a critical RCE vulnerability in the code that handles ICMP packets — CVE-2023-23415. Although it sounds major (because of how widespread ICMP is), Microsoft’s FAQ says that a raw socket must be bound to ICMP in order for the CVE to be exploitable. Since raw sockets can only be created by users with high privileges, it might be more rare than it seems at first glance. It is currently unclear whether the vulnerability affects Windows machines’ built-in ICMP handler, but because of the score and severity of the CVE, we believe it might.
Microsoft categorized this vulnerability as “more likely” to be exploited.
HTTP Protocol Stack
There are two vulnerabilities related to HTTP this month. CVE-2023-23392 is a critical vulnerability in the HTTP protocol stack that could be exploited for an RCE. The new vulnerability is in newly added code related to HTTP/3 implemented in HTTP.sys. HTTP/3 uses QUIC as a transport layer protocol. Microsoft uses MS-QUIC. HTTP/3 is relatively new and is only available in Windows Server 2022, so the number of machines that are vulnerable is much lower compared with normal IIS servers. Using Shodan, we scanned for HTTP servers running on Windows and serving HTTP/3 (Figure).
Figure: Shodan search of machines with HTTP/3
There is another CVE, CVE-2023-23410, in the http.sys driver. Although It is “only” an elevation-of-privilege (EoP) vulnerability that can grant SYSTEM privileges if exploited, it is also more widespread and affects most Windows versions.
Windows Cryptographic Services
There is one critical vulnerability in the Windows Cryptographic Services this month — CVE-2023-23416. Although the vulnerability is categorized as an RCE vulnerability, it is actually an arbitrary code execution (ACE) vulnerability, which means that an attacker can’t trigger the attack remotely; instead, the victim must do something for exploitation to start.
In this case, the vulnerability revolves around importing certificates. By analyzing the patch itself, we can tell that the bug is somewhere in an internal function called by NCryptUnprotectSecret, which is called as part of the certificate import event chain.
To abuse the vulnerability, an attacker can craft a malicious certificate that (once imported) will trigger the vulnerable code path in the Windows Cryptographic Services, and cause malicious code execution.
Microsoft categorized this vulnerability as “more likely” to be exploited.
Trusted Platform Module (TPM) 2.0
There are two vulnerabilities in the reference implementation code: CVE-2023-1017 provides an out-of-bounds write, while CVE-2023-1018 is an out-of-bounds read. These vulnerabilities don’t only affect Microsoft, but actually affect many products that rely on the TPM 2.0 reference code. The vulnerabilities were found by Quarkslab researcher Francisco Falcon, and he authored a nice write-up to explain them.
The affected Microsoft products are Hyper-V, Azure (that provides virtual TPMs), and their open source implementation of the TPM 2.0 reference.
Microsoft PostScript and PCL6 Class Printer Driver
Although we already covered PostScript in last month’s advisory, there are 20(!) new CVEs this month, so we can’t really ignore them with a clear conscience. This time, in addition to PostScript, PCL6 is also mentioned. Both are page description languages, used to tell the printer how to print the requested document.
In this case, it seems that there are a few classes of attacks.
RCE against shared printer drivers by sending a malicious document to the machine sharing the printer
ACE against local machines by sending the victim a specially crafted file to print (some of the CVE FAQs mention XPS files, specifically)
EoP to SYSTEM privileges by sending a maliciously crafted XPS file to print
Heap memory information leak
Since the network attacks are aimed at machines with printer sharing enabled, the attack surface should be fairly limited. As such, we recommend mapping those printer shares and limiting access from them to the rest of the network (if they’re just sharing a printer, they should only be able to access that printer). From our observations, approximately 66% of networks had machines with printer sharing.
To help map printer shares, you can use the following osquery:
select name, description, path, type from shared_resources where type=1 or type=2147483649
Previously covered services
Many CVEs in this month’s Patch Tuesday are for systems that we already covered in the past. If you’re interested in our analysis of, or general recommendations for, those services, we encourage you to look at our previous posts.
Service |
CVE number |
Effect |
Required access |
|---|---|---|---|
Remote code execution |
Network access, no authentication required. |
||
Spoofing |
User has to access malicious website. |
||
Information Disclosure |
Network, attacker has to be authenticated. |
||
Spoofing |
XSS attack. Attacker has to be authenticated and the user has to open the injected link. |
||
This summary provides an overview of our current understanding and our recommendations given the information available. Our review is ongoing and any information herein is subject to change. You can also visit our Twitter account for real-time updates.