CONTACT US
forrester wave report 2023

Close your ransomware case with Open NDR

SEE HOW

ad-nav-crowdstrike

Corelight now powers CrowdStrike solutions and services

READ MORE

ad-images-nav_0013_IDS

Alerts, meet evidence.

LEARN MORE ABOUT OUR IDS SOLUTION

ad-images-nav_white-paper

5 Ways Corelight Data Helps Investigators Win

READ WHITE PAPER

glossary-icon

10 Considerations for Implementing an XDR Strategy

READ NOW

ad-images-nav_0006_Blog

Don't trust. Verify with evidence

READ BLOG

video

The Power of Open-Source Tools for Network Detection and Response

WATCH THE WEBCAST

ad-nav-ESG

The Evolving Role of NDR

DOWNLOAD THE REPORT

ad-images-nav_0006_Blog

Detecting 5 Current APTs without heavy lifting

READ BLOG

g2-medal-best-support-spring-2024

Network Detection and Response

SUPPORT OVERVIEW

 

Detecting ​​CVE-2021-38647 OMIGOD

Researchers at wiz.io recently found a series of vulnerabilities in Windows Open Management Infrastructure (OMI) software, which is widely installed on cloud-based Azure Linux Agents. We have open-sourced a Zeek package for the most severe of these vulnerabilities, which we’ll discuss later in this blog. You can access the repo here: https://github.com/corelight/CVE-2021-38647

One of the four vulnerabilities found is a trivially exploitable unauthenticated remote code execution (RCE). At the heart of the vulnerability is a simple bug in the authorization checking code whereby these checks are effectively bypassed by sending a request without an authorization header.

The researchers dubbed this bug “OMIGOD” and it received CVE-2021-38647 which has a CVSS score of 9.8 out of 10. If in doubt as to your exposure, you can check Microsoft’s advisory, which explains the issue in detail, including mitigating factors, notably that OMI is not always exposed on the network by default. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-38647

The table below shows the effects of the removal of the authorization header:

Screen Shot 2021-09-21 at 11.05.28 AM

To illustrate this vulnerability in a more visual network-centric manner, these screenshots show the same three scenarios.

scenario1

Figure 1: Scenario 1. Correct behavior with a proper authorization token

scenario2

Figure 2: Scenario 2, Correct behavior with incorrect authorization token

scenario3

Figure 3: Scenario 3, Incorrect behaviour with no authorization header

When we set about creating a Zeek package we found that the exploit itself was quite trivial to reproduce and proof of concept (POC) code was also readily circulating. We set up a lab to attain pcaps and quickly developed an initial package. One might initially think that looking for this exploit should be as simple as looking for connections to the default OMI ports without an authorization header, however there are almost always unexpected edge cases in real world traffic. An example of an edge case are Layer 7 Keep-alive packets with Zero content length; these don’t have authorization headers, but do not represent an attack. Performance issues are also often critical, particularly for high volume events like HTTP at busy sites. The code in the repo is commented to highlight some of these factors - and a tip of hat to our Justin Azoff for helping out yet again with performance suggestions. All of these issues often arise for detection algorithms that seem like they should be trivial, but actually can get complicated quite quickly. Thankfully we have access to at-scale real-world traffic, as this highlights these issues and is vital for increasing the performance and fidelity of packages like this.

As we continued tuning the package to cater for these cases, we noticed that the exploit was being actively used to install the Mirai botnet, as also described in this useful and timely OMI hunting guide released by Microsoft. In one of the Mirai cases, we observed the payload was a base64-encoded instruction to fetch and run the malicious code. As shown in the screenshot, by design the notice produced by our package provides the data that an IR analyst or threat hunter would be interested in, all without having to pivot to a pcap. 

mirai

   Figure 4: Notice showing exploit payload and decode of same

In other notices we found various payloads with instructions to wget content from an Indonesian IP address.

other_payloads

Figure 5: Additional payloads observed

In another case, we saw an IP from Russia spoofing a browser user agent, presumably to avoid detection. We had predicted this may occur, and designed the package so as not to rely on brittle indicators. Interesting, it’s also evident in the notice the lineage of POC exploit they copied from was https://attackerkb.com/topics/08O94gYdF1/cve-2021-38647 because the MessageID was originally used in the attackerKB payload. The following screenshot shows the three notices that the package raised when this scan occured, highlighting useful IR triage information in the notice itself. 

spoofed_browser_UA

Figure 6: Spoofed Browser User Agent 

This is a good opportunity to discuss the value of generalizing detection algorithms. In this case, a curl or python user agent connecting to your OMI may be highly unusual - and therefore a valid detection algorithm depending on your use case, however it can also be very brittle as the user agent can easily be spoofed, as shown above. Similarly, detections looking for highly specific indicators used by a particular proof of concept payload (for example the MessageID uuid as described above) can also be quite brittle as these don’t take much effort for an attacker to change. These highly specific styles of detections may work on a particular POC, but when the POC is amended by a concerted attacker, or another POC is released, these detections can fail because the highly specific indicator is no longer present. This is where more general indicators (like the ones used in our package are useful) that detect the underlying vulnerability being exploited are required. Generalizing detection algorithms almost always means more time and effort is needed to ensure that no (or not too many) False Positives are introduced, and this balancing act is where the art of performant and effective detection engineering comes into play. In practice, all detection algorithms live on a spectrum between highly specific and highly generalized, the challenge is to decide where on that spectrum is acceptable for your threat model. 

In summary, here we have the following elements:

  1. A Cloud based vulnerability
  2. Unauthenticated Remote Code Execution
  3. Trivially Exploitable
  4. Multiple POC exploits in circulation
  5. Actively being exploited in the wild
  6. A Zeek detection package 

By Ben Reardon, Senior Security Researcher, Corelight Labs

 






 

 

Recent Posts