Tips for an Information Security Analyst/Pentester career - Ep. 77- Stay current (no.2 -CVE-2019-14287)

Over my episode no. 75, I mentioned how important it is for security professionals to stay current and demoed a recent PoC exploit released for the BlueKeep vulnerability.

This time I want to elaborate on that by talking about another vulnerability (CVE-2019-14287), recently discovered for versions of the sudo command earlier than 1.8.28.

This vulnerability implies what follows, based on the official source: "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.

Log entries for commands run this way will list the target user as 4294967295 instead of root. In addition, PAM session modules will not be run for the command".

Based on the explanations provided in the above-indicated page, when sudo is run with the -u switch and -1 is indicated as a user ID, sudo doesn't recognize it and behaves as if we indicated id 0, which is the root user's uid.

So, even though we indicate in /etc/sudoers that a user can't use sudo to run a specific command as root, this restriction can be eluded.

DEMO

I created a non-root user on my Kali VM and I changed /etc/sudoers as follows.

This configuration prevents user matt  from running the id command as root, as shown below.

Now, if we run sudo as user id -1, we're able to circumvent this restriction, because sudo wrongly considers -1 id as 0, which is the uid for root.

IMPACT

The impact from this vulnerability is worrying but surely not as devastating as ETERNALBLUE was in the Windows world, for example.

First, sudo can only be run from interactive terminals, which can not always be the case over penetration testing engagements and you need anyway to have valid login credentials to the box.

Secondly, this configuration in /etc/sudoers isn't so common and the bug can have a real impact only if those settings are in place.

However, you want to surely be aware of this bug as red teamer or blue teamer, because that adds value to your customers, and this reiterates once more that is paramount for security professionals to keep up with the latest exploits and developments in the industry.