Splunk : SUDO/BARON SAMEDIT

Share:

By Ryan Kovar January 28, 2021

On January 26th, 2021, Qualys reported that many versions of SUDO (1.8.2 to 1.8.31p2 and 1.9.0 to 1.9.5p1) are vulnerable (CVE-2021-3156) to a buffer overflow attack dubbed Baron Samedit that can result in privilege escalations. Qualys was able to use this vulnerability to gain root on at least Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2), some of the most modern and widely used Linux operating systems. This means that if you have Linux or Unix machines in your network (you do) and those machines have the sudo command (they most likely do), this vulnerability affects you.

Now, of course, privilege escalation requires an adversary to have access to the machine to start with, but that's why lateral movement is so popular. :-) As SolarWinds recently showed the world, you may have your network compromised from unexpected areas of attack, and then your defense-in-depth security strategy comes into play. Thankfully if you are ingesting *nix logs with Splunk and using the Universal Forwarder to do so, we have some great options!

The Baron Samedit Vulnerability and Attack

We will not go into too much detail because the Qualys blog reviews this in-depth. The basic idea is that an adversary with access to a *nix server could run a binary that exploits a vulnerability in the sudo package to cause a heap-based buffer overflow and cause a segfault. The ELI5 is that using the sudo command in unusual ways will cause the system to bypass standard protections and could allow attackers to escalate their permissions.

Active Detection of Vulnerable Servers

My wonderful colleague James Brodsky wrote a quick Technical Add-on (TA) to perform active detection for this sudo 'Baron Sameedit' vulnerability. It takes the Qualys report's detection method and converts it into a scripted input for any Splunk Universal Forwarder running on a Linux server or endpoint. This detection method is not foolproof but parses the output of stderror from a sudoedit command. If that output contains 'sudoedit:' then the version of sudo is vulnerable.

Simply drop it into the /etc/apps directory on a Universal Forwarder (or use deployment server or your favorite distribution method to get it there). By default, it runs once an hour and outputs key/value pairs 'samedit_status' and 'finding' to tell you if that particular Linux host is potentially vulnerable. It also outputs the sudo version found. This is a great way to map your patch status progress! Make a quick rule in Splunk Enterprise Security or a dashboard to find anything that shows the execution of sourcetype='script::samedit' as seen below:

If you happen to be running the Splunk Technical Add-On for *nix then the TA comes standard with a 'package.sh' script which retrieves all packages installed on common Linux distros. This is a less efficient way of finding potentially vulnerable sudo versions, but you may already have this TA deployed. The data retrieved from the package.sh script looks like this:

Suppose you happen to have a vulnerability management capability (like Qualys), especially one that is doing credentialed scans of your server (and workstation! This is, after all, the year of Linux on the Desktop!) estate. In that case, you can use it to find version numbers of sudo present and plan for mitigation. Or, if you have any attack surface management capabilities, like those from our good friends at RiskIQ, you can determine what Unix resources are 'outside your firewall' but on your network. RiskIQ can tell you what versions of Linux or Unix it finds, which will help you prioritize your patching once you cross-map those to versions shipped with vulnerable sudo versions. Whether you're doing internal or external scanning, you can always ingest and report on the results in Splunk and perhaps take automated action upon these results as well.

Passive Detection of Vulnerable Servers

Now… maybe you are saying to yourself, 'Those TAs look great, but it's gonna be a couple of days before my change control board approves a TA deployed to 90k servers!' Well, that's where the power of Splunk search comes in hand. We haven't had time to replicate the privilege escalation POCs for this vulnerability. Still, if you are ingesting your *nix /var/logs into Splunk, you should be able to find when the heap-based buffer overflow happens and causes a segfault. The good news is, this should be the most simple search we've ever given you!

'sudoedit -s \'

Thanks to Shannon Davis for running this to the ground and submitting an analytic story into Splunk ES Content Update (ESCU) that should be released shortly.

Generate Endpoint Data with Osquery

Now we are big fans of Osquery at Splunk for generating endpoint data from *nix and MacOS systems. Assuming you are bringing the Osquery logs in via the Splunk TA, you should also be able to find this evil Baron if he pops up. Please note, to get this to work, you may need to update the Osquery TA props.conf with this line 'FIELDALIAS-process = columns.cmdline as process':

eventtype='osquery-process'
| search process='sudoedit -s \*'

Conclusion

Was this an end of times vulnerability? No, absolutely not. Could some unpatched servers cause you a massive issue? Absolutely. We've given you a proactive way to interrogate your servers and make a data-driven response to manage your threat surface while also showing you several examples of how to detect this vulnerability best if an adversary ends up taking advantage of some of those servers that 'you just haven't quite gotten to yet.'

Happy Hunting :-)

Huge thanks to James Brodsky and Shannon Davis for their collaboration, data generation, and work. As always, these blogs are a team effort.