Recent Webinar: Building an Adaptive Cyber Resilient Cloud
arrow-white arrow-white Watch now
close

Technical Analysis: CVE-2024-30103

Posted by Arnold Osipov & Michael Gorelik on August 12, 2024

Recently, Morphisec researchers discovered a vulnerability in Microsoft Outlook, which highlights the potential for remote code execution within the context of the Outlook application. This newly identified vulnerability, CVE-2024-30103, allows remote execution through malicious injected Outlook Forms, posing a significant threat as it executes as soon as an email is opened. 

In this blog post, we will delve into the technical details on CVE-2024-30103. Our investigation reveals how this vulnerability can be exploited and the potential impact it can have on your systems. 

 

Outlook CVE-2024-30103 Technical Analysis

Discovery background

Earlier this year, Netspi published technical details regarding a vulnerability they had discovered in Microsoft Outlook. This vulnerability, CVE-2024-21378, revealed that Outlook was susceptible to authenticated remote code execution via synced form objects. Netspi discovered that it's possible to trigger an automatic registration and instantiation of a synchronized custom form by leveraging a special documented configuration file which represents the properties of the form.

 

One of the form properties points to a file path which represents a form server executable — the executable is responsible for the form rendering actions. NetSPI showed that it's possible to bypass a built-in faulty allow-listing security mechanism which is responsible for a validation of the form server property.

 

Platform.NTx86Code from CVE-2024-21378

The allow-listing mechanism verifies that the form server registry key property does not include COM properties which allow an auto-instantiation of synchronized COM form server executables.

Microsoft documentation states that it's possible to utilize a relative registry path for the instantiation of the form server executable.

Microsoft documentation on backslashes

Unfortunately, as was discovered by Netspi, the allow-listing validation algorithm fails twice when such a relative path is given:

  1. The search for a forbidden registry key value fails due to a faulty matching algorithm. Instead of searching for a risky substring key value indicator, the algorithm searches for an exact match – which fails if additional characters are introduced to the property key value (in this case, a relative path).
  2. A different control flow by design within the instantiation procedure can process a relative registry path, therefore leading to an automatic registration and instantiation of the form server executable.

Microsoft's patch has remediated this vulnerability by mitigating the second failure and blocked the designed control flow which allows the registration of a relative registry path (the documentation has yet to be updated).

Code from CVE-2024-21378

For more detailed information about this vulnerability, you can refer to the Netspi blog post.

 

CVE-2024-30103 technical details

As a reader might have already guessed, to prove that the matching algorithm must be addressed, Morphisec researchers have been searching for a working control flow that can compromise both the allow-listing exact matching algorithm while triggering the instantiation of the “modified” registry path.

As the “exact” matching allow-listing algorithm hasn’t changed, and we could NOT use the original relative path, we have been searching for other special characters that can be introduced to the registry path while leading to a successful instantiation of the form server.

We quickly identified that the form registration process uses a known RegCreateKeyExA Windows API. This API is a core Windows function and is utilized by almost every existing Windows application.

This function is also extremely interesting as it hides a complex implementation that is capable of expanding the path according to the relevant user registry hive path sid. One of the most interesting properties of this function is how it handles the backslash ‘\’ character.

According to the Microsoft documentation, key names cannot include backslash characters — so how does the RegCreateKeyExA function handle backslash?

Registry structure documentation from Microsoft

To support consistency across the different utilizations of this function, a trailing backslash is removed if passed as a parameter and will be treated the same as a parameter without a trailing backslash.

Backslash removal code

Of special note: if a backslash appears in the middle of the key, the key is treated as a nested list of keys that needs to be automatically generated. The depth of such nesting can get to 32 keys generated in one call.

So, what happens if our registry key has a trailing backslash? As expected, the matching algorithm will fail as “InprocServer32\” is not equal to “InprocServer32”, while the real key that will be written to the registry is “InprocServer32” that will then point to our expanded malicious form server executable, which was conveniently synced by the exchange server.

Platform.NTx86

The file is stored in a well-defined AppData local Forms folder, under a custom-defined message class that identifies the form. Any message sent to the victim with the given message class will automatically trigger the instantiation of the form server.

AppData folder where messages sent to victims trigger instantiation of the form server

Note: the evil.dll in our example will be loaded in the context of the Outlook process. Nevertheless, we could easily use other COM auto instantiation properties, such as LocalServer32, that can trigger external process applications.

 

CVE-2024-30103 patch details

Microsoft decided to update the allow listing matching algorithm, this time instead of searching for a substring, Microsoft stripped the trailing backslashes from the subkey just before the exact matching starts. This patch provides a solution to the vulnerability; however, time will tell if this becomes a foolproof solution.

Allow listing algorithm updates

In addition to this fix, Microsoft has updated the denylist, which introduces additional techniques that could have be leveraged to achieve a similar remote code execution impact through the manipulation of the subkey.

 

Deny list

 

On-Demand Outlook RCE Webinar

The Morphisec Threat Labs team presented their technical findings about CVE-2024-30103 and CVE-2024-38021 on the main stage at DEF CON 32. If you weren't able to attend in person, watch the on-demand webinar to hear directly from those that discovered these vulnerabilities and to learn more about the vulnerabilities. Watch now. 

 

New call-to-action

 

In conclusion 

This blog post discloses a significant issue in Outlook Forms and its patch. Despite measures taken, Microsoft did not adequately address the vulnerability in the denylist function, therefore leaving it vulnerable to exploitation. 

Morphisec provides protection against this vulnerability, ensuring that our customers remain secure from such threats. At Morphisec, we utilize Automated Moving Target Defense (AMTD) techniques to significantly reduce the risk of exploitation from vulnerabilities like CVE-2024-30103. By continuously and dynamically altering the attack surface, Morphisec AMTD creates a highly challenging environment for potential attackers. This innovative and preventative approach strengthens the protection of our clients against a broad spectrum of sophisticated cyber threats.  

Additionally, Morphisec’s AMTD technology acts as a virtual patch and compensating control for unpatched vulnerabilities. It proactively thwarts attacks on unpatched operating systems and application vulnerabilities by disrupting attack pathways, effectively dismantling an attacker’s framework.   

Experience Morphisec firsthand — schedule a demo today. 

Schedule a Demo with Morphisec