How to Audit and Test for Sudo’s CVE-2021-3156 with LogRhythm
TL/DR
Qualys has reported that Sudo, before 1.9.4p2, has a heap-based buffer overflow vulnerability that allows privileged escalation to root via “sudoedit -s” and a command-line argument that ends with a single backslash character. Detecting a successful exploit of the critical vulnerability, CVE-2021-3156, is very difficult and will greatly depend on your audit capabilities. Detecting this type of malicious activity is greatly improved by using software designed to perform detailed process monitoring — such as LogRhythm SysMon agent. With a configured LogRhythm SysMon agent and our out-of-the-box UEBAAI Engine rule, “Compromise: Unusual Auth then Unusual Process,” an analyst would have been able to detect the attempted exploit of this vulnerability even prior to the details becoming public knowledge. I was able to successfully run and detect a working exploit by Rajvardhan Agarwal r4j0x00. In most environments, “Sudoedit” should be used rarely, and analysts should consider searching for the historical use of “Sudoedit” in their environment to find any indicators of possible compromise.
CVE-2021-3156: Heap-Based Buffer Overflow in Sudo
On January 26th, 2021, Qualys released a blog discussing their finding of CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit). This vulnerability affects a wide range of Unix distros, including Mac. I welcome you to peruse the references provided throughout this blog to further your education on this vulnerability and learn ways to test the exploit as I did. In this journey, I will demonstrate that even with additional audit policies in place, detecting the actual exploit is very difficult and will likely require additional process monitoring software like LogRhythm SysMon for Linux. In this test, I was able to successfully detect the exploit through our AI Engine rule named “Compromise: Unusual Auth then Unusual Process”, which is part of LogRhythm’s out-of-the-box UEBA content module. The testing was focused solely on the known tests with references in this blog, and Ubuntu 18.04.3 LTS.
Getting Ready to Test: Building and Configuring the Test VM
I choose to build a quick test infrastructure on my workstation using Hyper-V. Here is how I went about building the test VMs using Hyper-V “Quick Create” function and selecting the Ubuntu 18.04.3 LTS image.
Creating the Ubuntu 18 Instance: Hyper-V
Select “Quick Create”.
Select “Ubuntu 18.04.3 LTS”.
Under “More options”, feel free to change the name of the VM.
Click on “Create Virtual Machine”.
Once done, you’ll see a screen like this:
Click on Edit settings, and modify the number of processors from six (or however many you may have listed) to two.
Click “OK” when done modifying settings.
Click on “Connect”.
Click on “Start” to start the VM.
Walk through the first-time setup screens:
Configure Ubuntu
Disable Auto Updates
In Terminal and as root, enter the following command: nano /etc/apt/apt.conf.d/20auto-upgrades
Change both values from 1 (enabled) to 0 (disabled).
Configure Syslog
Edit /etc/rsyslog.conf.
Change the permissions to “adm” and enter the Syslog Server information. The “adm” group has access to most of the log files in /var/log.
Although you could restart services at this point, I just rebooted, so I recommend doing the same.
Configure LogRhythm Syslog Acceptance
Note: Configuring a Syslog listener is not covered in this blog. Please refer to LogRhythm documentation on how to configure a Syslog listener in your environment.
In Deployment Manager, select the “Log Sources” tab and you should see your new Syslog log source ready.
Resolve Log Source Host.
Change Log Source Type to Syslog – Linux Host.
Select “Accept” and “Customize”.
Select which Entity to place the system in if different than the Syslog Receiver.
Configure AuditD in Ubuntu
Install AuditD:
sudo apt-get update
sudo apt-get install auditd audispd-plugins -y
cd /etc/audit/rules.d/
In this next step, we’re using an AuditD config provided by someone that has taken the time to compile a rules config based on the DISA.
File Path (verify on your deployment): /var/log/syslog.
Date Parsing Format (verify on your deployment): Linux Host Secure Log ( ::).
Click OK.
New Log Message Source Type: Flat File – Linux Audit Log.
Configure the rest as appropriate.
On the Flat File Settings:
File Path (verify on your deployment): /var/log/audit/audit.log.
Date Parsing Format (verify on your deployment): Linux Audit Log (Epoch time) (msg=audit\().
Click OK.
Click OK when done adding additional log sources.
Verify logs are being collected by looking at the Last Log Message time for the log sources in the Log Sources tab.
Testing CVE-2021-3156
Now that I have the test environment fully configured, I can go ahead with the test to detect if Sudo is in fact vulnerable. I’ll take a look at what logs are generated both by the LogRhythm Process Monitor and by the native Linux host logging.
No AIE rule was triggered in this test. We could write a detection rule for sudoedit since it should be used rarely, but in this case we will instead perform a threat hunt on “sudoedit”.
Using the WebUI, perform a search going back at least 1 month. The use of “sudoedit” should be very rare and of interest when it’s used in your environment.
Perform a LogMessage search sudoedit.
In the test environment, the search returns results from multiple sources, including process monitoring, error logging, and general operations, providing multiple insights into the activity.
LogRhythm Process Monitor (Linux) captures this attempt.
Linux Auditd captures the segmentation fault generated by the unpatched Sudo version.
Note the ID contained in the “Group” field above is that of the user group attempting the exploit.
Syslog – Linux Host captures General Operations and Error logs.
Search for Classification: “Error”, Common Event: “Segmentation Fault”, and Process Name: “sudoedit”.
Running the Exploit
I will now run the actual exploit and look at how the LogRhythm Process monitor captures the activity. Then I will show how the LogRhythm out-of-the-box detection rules pick up the unusual behavior enabling the analyst to be proactively alerted to the activity.
In our test, I am looking for the execution of the exploit where the log message contains “./exploit”. You may not know this information when starting your investigation with “sudoedit”, but you will likely come across the execution in your investigation. You can follow this example by using your known execution name to search for.
Search for Log Message contains “Exploit”.
First, bring back the log messages that match the execution name.
Use Lucene Filter on results: logMessage:*.\/exploit*
In the results, you will want to filter the dashboard to show where something was executed by looking for “./” preceding the name.
Log Source Type LogRhythm Process Monitor (Linux) detects this activity.
Detection of a Successful Exploit
This exploit can be detected by an analytics rule looking for Unusual Authentications followed by an unusual process. A rule for this purpose is provided in the LogRhythm UEBA module. Identification of a successful exploit will focus mostly around the user being “root”, and the process containing “sudoedit -s”. The output of the AIE rule “Compromise: Unusual Auth then Unusual Process” contains all the relevant information an analyst would need.
Details
The following are details that an analyst would likely see when performing an investigation starting with the AIE event “Compromise: Unusual Auth then Unusual Process”. There will likely be several logs returned in the drill down. In this example, only a couple of the drill down logs are shown for reference.
AIE detection where the exploit was successful. Notice the user is “root”. AIE: Compromise: Unusual Auth then Unusual Process.
AIE Drilldown results in observations from LogRhythm User Activity Monitor (Linux), Syslog – Linux Host, and LogRhythm Process Monitor (Linux).
Raw Log: 02 03 2021 12:43:00 xxx.xxx.xxx.xxx Feb 3 12:43:00 hostName su[5902]: Successful su for root by root.
AIE Event detection where the exploit was not successful. Notice the user is not the root. Like before, the AIE event “Compromise: Unusual Auth then Unusual Process” has all the relevant information an analyst would need to determine that the exploit was not successful in this example.
Miscellaneous Commands
The following are some miscellaneous commands I issued on the test system to demonstrate the version of the OS, and whether or not Sudo was vulnerable. You can use these commands too on your test system.
Demonstrate versions of the software
lsb_release –a
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic
sudo –V
Sudo version 1.8.21p2
Demonstrate user permissions (user in Sudoers has no effect on test outcome):
Demonstrate normal user
In Sudoers on systemName
b@systemName:~$ sudo -l -U alice
[sudo] password for b:
Matching Defaults entries for alice on systemName:
User alice may run the following commands on systemName:
(ALL) ALL
b@systemName:~$ ^C
Not in Sudoers on systemName
b@systemName:/etc$ sudo -l -U alice
[sudo] password for b:
User alice is not allowed to run sudo on systemName.
Conclusion
Although this vulnerability has been around for around 10 years in many flavors of Unix, detection methodology remains the same. By looking for unusual processes and unusual authentication activity, an analyst is able to quickly spot when something isn’t right, and detect a potential attempt, or successful attempt at exploiting CVE-2021-3156.