A recent flaw, CVE-2019-14287, has been found in sudo. In this blogpost, we are going to show you how to use Falco or Sysdig Secure, to detect any exploit attempts against this vulnerability.
sudo allows users to run commands with other user privileges. It is typically used to allow unprivileged users to execute commands as root. The issue exists in the way sudo has implemented running commands with an arbitrary user ID in versions earlier than 1.8.28. The CVSS v3 score is 7.8, so we are talking about a high severity vulnerability, easy to exploit, although the attack vector is local and requires a non-default configuration.
Exploiting this bug requires the malicious user having privileges that allow running commands as any user (except root). If the sudoers file has an entry with the special value ALL in the Runas parameter, the conditions will be met.
Exploiting sudo CVE-2019-14287
Invoking sudo with -u#-1 or -u#4294967295 specified in the sudo command, the malicious user can run arbitrary commands as root, as long as the sudoers meets the previously described conditions.
In addition to that, the malicious sudo operation will not log correctly through the syslog facility. It supposed to be logged as root, however, it turned out to be -1 or 4294967295.
Let’s create a test user and write the following configuration in the /etc/sudoers file.
# User privilege specification root ALL=(ALL:ALL) ALL test ALL=(ALL, !root) /usr/bin/id
In theory, this test user is allowed to execute the id command as any user, except root, which is explicitly disallowed.
We can test the sudoers access:
test@1425485fcefd:/$ sudo -u root id Sorry, user test is not allowed to execute '/usr/bin/id' as root on 1425485fcefd.
Directly impersonating the root user is disallowed, as expected.
test@1425485fcefd:/$ sudo -u#1000 id uid=1000(test) gid=1000(test) groups=1000(test)
You can impersonate another (regular) user and run id with its identity, this is expected as well, according to our configuration.
Let’s try this now:
test@1425485fcefd:/$ sudo -u#-1 id uid=0(root) gid=0(root) groups=0(root)
Bingo! We have been able to execute a command as root when the sudoers configuration didn’t allow us to do that.
Now, the log entry that we will find in our syslog can look like this:
Oct 15 10:51:02 1425485fcefd sudo: test : TTY=console ; PWD=/ ; USER=#-1 ; COMMAND=/usr/bin/id
Detecting CVE-2019-14287
Detecting exploitation attempts of this vulnerability is fundamental. If you cannot patch your systems immediately you can detect and potentially prevent the attack. If you have already upgraded your system and containers affected by the vulnerability, it is still extremely interesting to detect any attempt so we can catch malicious activity in our environment.
Falco is the CNCF open source project for intrusion and abnormality detection for containers and cloud-native apps. It secures Kubernetes at runtime, and we can use it for detecting this activity both at the host and at the container level. Falco will generate security events when it finds abnormal behaviours, which are defined by a customizable set of rules.
One of the benefits of Falco is in leveraging its powerful and flexible rules language. We can quickly and easily write rules to filter this kind of behavior, so we can detect when someone is trying to exploit sudo CVE-2019-14287.
The following is a rule created to detect sudo CVE-2019-14287:
- rule: Sudo Potential bypass of Runas user restrictions (CVE-2019-14287)
desc: When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295. This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification
condition: >
spawned_process and
proc.name="sudo" and
(proc.cmdline contains "-u#-1" or proc.cmdline contains "-u#4294967295")
output: "Detect sudo exploit (CVE-2019-14287) (user=%user.name command=%proc.cmdline container=%container.info)"
priority: CRITICAL
tags: [filesystem, mitre_privilege_escalation]
When the rule detects the exploit attempt, Falco will trigger a notification like this:
00:51:26.935975300: Critical Detect sudo exploit (CVE-2019-14287) (user=ubuntu command=sudo -u#4294967295 id -u container=host (id=host))
Falco notifications can be forwarded to your logging system, your SIEM of choice or other multiple destinations.
Sysdig Secure extends the open-source Falco detection engine to provide comprehensive security across the Kubernetes workloads lifecycle. The very same rule can be used within Sysdig:
In addition, Sysdig Secure will allow you to:
- Block threats by extending Falco’s detection capabilities with prevention and response
- Ease the burden of creating and updating runtime Falco policies with automated profiling, a flexible policy editor and centralized management
- Embed security across the DevOps process with image scanning, forensics/incident response and audit, in additional to security monitoring
- Validate compliance using out-of-the-box checks and runtime policies that that map to compliance standards
So, you can detect sudo packages vulnerable to CVE-2019-14287, block any new container affected in your CI/CD pipeline or registry before a new deployment and react to exploitation attempts of this vulnerability across already running containers in production blocking the malicious containers in your Kubernetes cluster.
Conclusions
CVE-2019-14287 vulnerability allows malicious users to exploit locally certain sudoers configurations that allow to run commands as other unprivileged users to run any command as root.
Falco allows users to filter and detect this kind of activity by writing a custom rule to match the exploit behaviour pattern, to then alert regarding the malicious activity across our hosts and containers. Sysdig Secure takes this functionality a step further, being able to react to these attacks, block them and report on any affected running containers with the sudo vulnerability.