Detecting the Exploitation of “Baron SamEdit” (CVE-2021–3156)

A recent heap-based buffer overflow vulnerability (CVE-2021–3156) in sudo was discovered with a high CVSS score of 7.8 dubbed “Baron SamEdit”. The proper exploitation of the Baron allows for any unprivileged local user to immediately escalate to root without additional authentication and affects the following sudo versions:

  • Legacy versions of: 1.8.2–1.8.31p2
  • Stable versions of: 1.9.0–1.9.5p1

This poses a serious threat to most organizations, especially those that are primarily a Linux-based infrastructure, and detecting this kind of threat is critical. Most vulnerability scanners are now updated with the means of detecting whether one of your systems are vulnerable but if you want to make an extra check there is a reliable means by running the following command on any system in question:

sudoedit -s ‘\’ `perl -e ‘print “A” x 65536’`

This will provide one of two outputs determining whether the system is vulnerable. If the system contains a response with an error containing:

  • “Segmentation fault” or “malloc(): corrupted top size” then the system is vulnerable.
  • “usage” then the system is not vulnerable.

Developing Detection

There have been many PoC variants for this vulnerability that have been released since initial documentation with the most reliable exploits being:

If you are looking to perform your own simulations to create a detection, the above is a good place to start but do know that all available PoC’s are based on similar techniques where the sudoedit command is invoked either through the -s option, which sets sudo’s MODE_SHELL flag or through the -i option, which sets sudo’s MODE_SHELL and MODE_LOGIN_SHELL

flags. Below is a sample output from a successful and failed exploitation, respectively:

Given the way sudoedit needs to be invoked, the most common method of creating a detection would be to look for usage of the sudoedit command utilizing the “-i” or “-s” options with your Linux command line auditing. A very simplistic piece of logic for this detection is as follows:

(“Sudoedit” AND (“-i” OR “-s”))

In our testing, this kind of detection also triggered when the exploitation was unsuccessful or if normal sysadmin activity was occurring. In order to better fine-tune the detection, there needs to be more than just looking for a common option that is passed with sudoedit.

In order for the exploitation to work, a C compiler must be installed on the system as it is required to compile the code that crafts the necessary EXECVE call for exploitation. GCC is the most common C compiler as it is natively installed on most Linux operating systems and is widely utilized which enables us to write a supplemental detection.

As stated, GCC is commonly installed, and trying to alert on GCC use on .c files is going to inundate a Security Operations Center with alerts but we are not looking to bubble up an alert, just to supplement or previous detection to increase the validity of a true positive while reducing the extra noise your sysadmins are causing.

Looking for a sequence of detections, the first being GCC crafting the EXECVE call followed by the sudoedit detection will grant the ability to have a high-efficacy detection that should naturally filter out any common sysadmin activity happening within your infrastructure allowing Security Operations Centers to effectively handle a single trusted alert.

If you are already using Anvilogic, doing this kind of sequencing can easily be done via our Code-less Threat Scenario Builder by tying the two detections together with a time-lapse between detection triggers and deploying the auto-generated code, along with the underlying vetted detections directly into your SIEM.

The Anvilogic platform is primed to help Security Operations Centers improve their capabilities by enabling analysts to quickly identify relevant threat detections via machine learning recommendations, deploy those detections into their SIEM via automated workflows, and allow for any analyst to create complex detections via the use of our code-less threat scenario builder. All of our detections are developed utilizing live exploits, tagged with threat enrichment details, and vetted by our security threat research team.

To learn more about Anvilogic please visit www.anvilogic.com and request a demo of our product.

About the Authors

Kevin Gonzalez is currently the Director of Security at Anvilogic where he is responsible for the threat detection lifecycle and corporate security.

Prior to Anvilogic, Kevin led cyber security operations, engineering, and architectural practices at Lennar Corporation and Cubic Corporation while consulting for several organizations to help build security analytic programs and architect security solutions.

Kevin is from Miami, Florida. He holds a master’s degree from Florida International University in Management Information Systems along with several cybersecurity certifications.

Eric Hines is currently a Detection Engineer at Anvilogic where he is responsible for threat detection analysis and intelligence.

Prior to Anvilogic, Eric was an Information Security Analyst with a diverse background in various cyber operations for the U.S. Navy.

Eric currently resides in Chattanooga, Tennessee. He holds a Bachelor’s degree from the University of Maryland Global Campus in Computer Network Infrastructure and Cyber Security along with several cybersecurity certifications.

Anvilogic is a collaborative, no-code Automated Detection Engineering platform that helps SOC teams quickly deploy high-efficacy attack-pattern detection code.