Detecting Dirty_Sock Privilege Escalation Vulnerability with Osquery

You may have heard about “Dirty Sock”, a recently discovered vulnerability targeting snapd sockets, playing on the name of a previous vulnerability called “Dirty Cow”. Snapd allows for the execution of packaged snaps, which are a mechanism to distribute and update applications in a standard format.

The details of the vulnerability are not overly important, as it was fixed in all supported versions of snapd already, and the exploitation of it required specific conditions, such as the ability for a user to access the system with lower privileges, or the ability to load a snap.

What is important, however, is to realize that proof of concept (PoC) exploit code may be leveraged by malicious actors looking for a quick way to exploit a system. This practice is not specific to Dirty Sock, as we’ve seen the same conditions present in many proof of concept exploits for different vulnerabilities. It can be easy to disregard a PoC exploit under the guise that no “serious” attacker would ever use it. While you probably won’t see a state-sponsored attacker leveraging an unmodified PoC, you may find a malicious user with access to specific systems attempting to elevate privileges with PoC exploit code, especially in environments where computers are shared between users (shared hosting, education, etc.).

For these reasons, and because osquery makes it so quick and easy, verifying you have no current risk or artifacts of historical compromise from the dirty_sockv1 and dirty_sockv2 PoCs makes good sense.

Step 1) Verify Non-Vulnerable Snapd Version 2.37.1 is Installed

Using osquery, lets first verify that all of your systems have the updated version of the Ubuntu package with the snapd vulnerability fixed. Note: this requires you to have osquery installed. See here for a starter guide. For some more high-level information on osquery, check out this introductory blog post.

Let’s get started by first launching osqueryi and checking the Ubuntu distribution version we are currently using. Based on the Ubuntu website, we want to see version 2.37.1 on Ubuntu 18.10.

“On Ubuntu systems with snaps installed, snapd typically will have already automatically refreshed itself to snapd 2.37.1 which is unaffected.”

- Public statement from Ubuntu

To do that, enter the command:

SELECT * FROM os_version;

 Then, query the deb_packages table to see what snapd version is currently installed by entering this SQL command:

SELECT * FROM deb_packages WHERE name=’snapd’; 

We can now see that this system is running the 2.37.1 version, packaged for Ubuntu 18.10, and therefore is no longer vulnerable to Dirty_Sock. If you were shipping data from deb_packages to a centralized repository for osquery data (see here for open source tooling options), or using Uptycs to gather that information historically and in real time, you could check your entire environment instantly, as well as know for what period of time you had a vulnerable version running after the PoC was published. Uptycs also includes vulnerability data, so you can perform an instant vulnerability check.

Step 2) Check for Any Historical Dirty Sock Vulnerability Presence or PoC Execution

Now that we’ve verified there is no longer active vulnerability in our environment, we can check for historical artifacts to see if Dirty_Sock had been used to compromise any of our systems before snapd was updated.

The PoC for Dirty Sock reveals that it performs actions that are quite noisy and easy to detect, giving us a view into what artifacts to search for.

The first version, dirty_sockv1.py, attempts to exploit the /v2/create-user API of snapd to create a new user with the ability to elevate privileges via sudo.

The second version, dirty_sockv2.py, attempts to sideload a snap, which is a universal package for Linux applications that runs via snapd. That snap, while empty, attempts to create a new local user via the vulnerability. As you can see in the PoC code, the user created would be named dirty_sock, which you can easily check for using osquery as well. You could query for it directly, or look for any user with the name starting with dirty, which is unlikely in production environments:

select * from users where username LIKE 'dirty%';

With Uptycs, you can also look at the historical presence of software packages by leveraging our historical database. Performing this sample query, for example, as a global query, would return timestamps in fields such as upt_time.

select * from deb_packages where name='snapd' and version NOT LIKE '2.37%';

In a targeted attack, it is unlikely someone would use such a noisy method. That being said, in environments where many users share Linux systems (workstations or servers) or where exposure in general is high, such as in education environments, it is quite possible someone may attempt to run the PoC code directly. In these environments, monitoring the creation of users and sudoers will always be worth it.

And, if nothing else, it will force your penetration testers to be more subtle when doing offensive security testing on your systems!

For now, I'm off to BsidesSF and RSA. My first order of business is hosting a sold-out osquery workshop on Saturday March 2nd.  For those that were not able to make the cut, feel free to check out our free and on-demand osquery online course.

If you would like to attend BSidesSF, you can throw your hat in the ring by entering into our raffle for free tickets! Winners are selected and announced on Friday 3/1.

See you there!

Related osquery resources:

• Osquery: What it is, how it works, and how to use it