Beyond Memory Corruption Vulnerabilities – A Security Extinction and Future of Exploitation

By Chintan Shah · January 24, 2022

Modern exploitation techniques have changed how adversaries execute their attack strategies and how defenders analyze paths from vulnerability to exploitation. Over the past decade, we have seen rock solid focus on hardening security at both the overall Operating System and applications, which has resulted in remarkable progress being made on introducing several exploit mitigations. This progress has been gradually eliminating entire classes of memory corruption vulnerabilities in some cases. The Use-after-free (UAF) is a class of vulnerabilities, for example, which is very common in large complex code bases such as web browsers. Due to ease of exploitation, Microsoft introduced an isolated heap and delayed free of objects in its browser engine (mshtml.dll), breaking the UAF exploitation chain and making adversaries to address those barriers requiring them to re-engineer the exploits. Figure 1 below shows the part of the code where it was introduced to mitigate UAF vulnerabilities.

We can notice the different between the protected and unprotected code. While this was just the tip of the iceberg, it made exploiting UAF vulnerabilities extremely challenging since it required the attackers to address specific timing constraints and memory thresholds as well. Figure 2 below is the simple visualization of Windows OS memory exploit mitigations introduced over the past decade or so.

However, time and again, we have seen these exploit mitigations being bypassed within a short period after they were introduced, primarily because either all the code including dependent, and third party code was not compatible with or not compiled with those mitigation switched on in the compiler. This essentially meant that the exploit mitigation was not enforced on every part of the code, or the mitigation itself was not completely implemented, leaving multiple loopholes which in turn could be exploited . For instance, it can be noted from the above visualization that ASLR was not implemented in initially in its entirety but rather in stages, thereby leaving much of the code still vulnerable to bypasses.

Memory Corruption vulnerabilities – Will it become a thing of the past?

While memory corruption vulnerabilities continue to be the most widely reported class of bugs , converting them into full-fledged weaponized exploits has become a challenge over the recent years owing to the exploit mitigations introduced at the OS as well as the client side application (For e.g., scripting engines). Translating memory corruption vulnerabilities into full blown exploits leading into arbitrary code execution, requires bypassing multiple mitigations without triggering any endpoint security solution protection or detection. This now means significant invest in effort, time and cost is required by adversaries to research exploit mitigation bypasses. On several occasions, adversaries may also need to chain multiple vulnerabilities to be able execute a working exploit on the target system which also significantly increases the development cost , raising the bar of exploitation.

We believe that this exploitation mitigations evolution is going to be crucial in shaping the nature of vulnerability classes of interested to adversaries in the future. The question : “Will memory corruption vulnerabilities become extinct ?” is debatable and requires some introspection.

Exploitation Strategies of the Future - What lies ahead?

Memory corruption vulnerabilities will continue to exist in the applications as long as there is some code in the application that handles memory incorrectly, but the intensity and frequency of exploitation of this class of vulnerabilities will eventually fade out. We had witnessed multiple instances of exploitation techniques in the past where attackers achieved arbitrary memory Read/Write (R/W),by exploiting a memory corruption flaw and using that primitive to change certain flags or data in the application memory leading to code execution. These set of methods codenamed “data only attacks” were relatively easier strategies seen in many exploits. Eventually randomizing certain critical data structures locations in memory reduced this nature of attacks over time.

With feature rich applications, attackers will always be on a lookout for the easier strategies to achieve code execution on the target system. There are always legacy systems around exposed to the internet which will offer the path of least resistance to the attackers since they lack the mitigations introduced. However, one of the ways forward in this direction is to abuse the feature or design flaws in the application or in the network protocol. If adversaries can determine the way to abuse the inherent design or feature of the target application, for instance, making the application or a service connect to the attacker controlled machine without orchestrating the memory explicitly, it becomes relatively easier to achieve remote code execution and at the same time, causing havoc on the target machine since the functionality of the arbitrary code executed by the exploited process is completely on the imagination of the attacker. Figure 3 below is a simplistic view on the progression of exploitation strategies over the last few years.

We have witnessed data only attacks and abuse of application features/design flaws several times over the last few years. They offer multiple advantages over the traditional memory corruption exploits, and some of the reasons we believe this is going to be the exploitation strategy of the future are:

• It has the potential to bypass exploit mitigations in place and hence adversaries do not have to engineer the exploit specifically to address those barriers.
• Arbitrary code is executed with the privileges of the exploited process and hence helps elevate the privileges.
• Exploits taking advantage of application’s inbuilt feature or design flaws does not have to deal with the explicit memory manipulation and space constraints before the vulnerability is exploited. Consequently, getting rid of injecting the shellcodes in the memory and the older stack pivoting techniques.
• Relatively easier to exploit with lesser development / maintenance cost and time to weaponize it.

Retrospection of critical vulnerabilities over the last couple of quarters can give us the definite clue on how the future attacks will take shape. In the following sections, we take a look at some of the more recent high impact vulnerabilities and check how features or design flaws in the service or application were abused to achieve code execution or sensitive information leak with minimum resistance.

CVE-2021-44228 – Apache Log4J2 Logging Library Vulnerability Leading to Remote Code Execution

This RCE vulnerability reported in Apache’s Log4j Logging library is one of the most critical flaws reported in the recent years, allowing attackers to execute arbitrary code on the vulnerable server that uses Log4J logging library to log text messages. In our previous blog, we discussed at great length on how open source softwares serves as the building blocks of modern software development and how critical it is to audit them as any vulnerability will have a significant impact on the product using it.

The vulnerability lies in the “Lookup” method of “jndimanager” class. When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. This allows the attacker controlled server to send the malicious JNDI reference in the response leading to the execution of arbitrary code on the vulnerable server.

This RCE was made possible because Java implements a variety of JNDI ( Java Naming and Directory Services) service providers like LDAP, DNS, RMI and CORBA; loading remote classes was also possible, depending on the default system properties set.

CVE-2021-44228 is a classic example of feature exploitation. The feature abused here was the lookup substitution which supports Lookups. Lookups are way to add values to the log messages which are typically variable names resolved using a defined map or at the runtime via implemented interfaces like StrSubstitutor and StrLookup classes.

Log4j supports the property syntax “${prefix:name}” where prefix indicates the Log4j that the variable name should be evaluated in the specific context. JNDI context is built into Log4J as shown below.

Since JNDI lookups was enabled by default in Log4J version 2.14.1 and prior (see figure 6 above), the library could identify the JNDI references passed as the parameter value in the HTTP request headers logged on the server , consequently allowing attackers to inject malicious JNDI references in the HTTP request parameters leading to remote Java code execution.

CVE-2021-34527 – Windows Print Spooler Service Vulnerability Leading to Remote Code Execution

Privileged remote code execution vulnerability in spoolsv.exe i.e., PrintNightmare was another critical vulnerability reported last year and serves as good illustration of how a design flaw in the protocol can be abused to execute arbitrary code on the target machine without having to operate on the memory.

The vulnerability was exploited over Print System Remote Protocol (MS-RPRN) and Print System Asynchronous Remote (MS-PAR) protocol, by making RPC calls over SMB. The exploit takes advantage of a classic design flaw in the implementation of the print server component in the spooler service, when RPC requests are made to MS-RPRN and MS-PAR interfaces to install the printer drivers on the target system. Making the RPC call to RpcAddPrinterDriverEx (MS-RPRN Opnum 89) or RpcAsyncAddPrinterDriver (MS-PAR Opnum 39) requires a DRIVER_CONTAINER structure to be passed as an argument.

As indicated in the above structure details, DRIVER_CONTAINER contains pDriverPath and pConfigFile, which are the full path of the filename containing the printer driver and configuration module respectively. Both pDriverPath and pConfigFile are checked for the UNC path to prevent arbitrary code from loading.

The design or logic flaw in the code here is that same UNC path check is not applied to pDataFile, which is the full path of the file containing printer data. An adversary could make multiple calls to RpcAddPrinterDriverEx with:

1. pDataFile as the UNC path of the malicious DLL accessible to the target machine which when successful will copy the malicious DLL to the target machine locally.
2. Same API with the copied file name assigned to the pConfigFile (this time the malicious DLL becomes the local path) , leading to loading of malicious code by print spooler service.

CVE-2021-36942 – LSA Spoofing Vulnerability in Windows Leading to Credential Leaks

RPC over SMB had always been on the forefront of many exploitation methods. This vulnerability could be exploited by again abusing MS-EFSRPC protocol, which is used in windows to manage the files on the remote system and encrypted using Encrypting File System ( EFS ).

By making specific RPC calls like EfsRpcOpenFileRaw over LSARPC interface attacker can make one windows host authenticate to another server; essentially meaning that a target server can be made to authenticate to an adversary controlled server via NTLM authentication. More importantly, LSARPC can be issued using RPC calls without any prior authentication and if this target server is Active Directory (AD), then adversary can make AD connect to the arbitrary server using the machine account for NTLM authentication. This EFSRPC protocol can be abused to chain multiple vulnerabilities within the enterprise network to relay NTLM credentials to an attacker controlled server which could be used to perform lateral movement, eventually leading to complete domain compromise.

If the adversary is controlling an IIS web server with the Active Directory Certificate Services ( AD CS ) feature installed and is configured to use NTLM over HTTP authentication, making an Active Directory authenticate to IIS will result into leaking the NTLM credentials to the adversary, resulting in complete domain compromise. While NTML relay attacks aren’t new, it is recommended to use more secure authentication mechanism like Kerberos to prevent protocol abuse like this.

In summary, being able to abuse a protocol or a feature to make a critical asset connect to an externally owned adversary server comes with a dangerous consequence as demonstrated by the CVE-2021-44228 Log4J vulnerability.

CVE-2021-40444 – Windows MSHTML Vulnerability Leading to Remote Code Execution

This was yet another critical vulnerability exploited last year and is a great example of how a simple feature abuse can be chained with a logic flaw to achieve arbitrary code execution. First, Object Linking and Embedding (OLE) was used to link the document to the external OLE object. Historically, OLE has played a significant role in building weaponized office exploits and this will continue to happen as it is one of the core features of MS-Office file format designed specifically to address interoperability.

MS Office Open XML specifications allows a document to embed or link to internal or external objects and in particular link to the external OLE object is specified via relationships . As shown in the crafted exploit document below, the document.xml.rels file with Type attribute as “oleObject”, Target attribute set to the OLE object link and TargetMode set as external. This allows the crafted document to link to the externally hosted malicious object and invoke the respective protocol / resource handlers for rendering the object, to exploit a potential logic / design flaw in the handler. This is typical OOXML template injection techniques used in many OOXML exploits in the past. We had an in depth look on OLE exploits in our previous blog post.

HTML code processing is done in mshtml.dll while HTTP protocol and MSHTML downloads are verified for trust and handled in urlmon.dll. The design flaw in the urlmon.dll code was in relation to the extraction and the trust verification of the downloaded CAB file. The CAB file was downloaded via Javascript (JS) code embedded within the side.html page as in figure 11 above. Because of the missing path escape checks during the extraction of the CAB file, it allowed the exploit to extract the file contained within the CAB with the relative path per figure 12 below. This resulted into dropping of the malicious payload outside of the created TEMP directory, eventually allowing the dropped payload to be executed.

Conclusion

There has been a trend in the past few years of vulnerabilities like CVE-2021-44228, CVE-2021-34527, CVE-2021-36942 and CVE-2021-40444 described above which take advantage of inherent processing flaws and are predominantly feature abuse. While memory corruption flaws will continue to proliferate as long as insecure code exists in non-memory safe languages other than Rust, we certainly expect to see the exploitation trend moving more towards exploiting design or logic flaws and protocol abuses. Consumers as well as the developers of open source software need to be more vigilant as these flaws will allow adversaries to achieve their initial system level objective of moving laterally within the network ,without worrying about the defense in depth of recently matured memory exploit mitigations.