Linux Privilege Escalation via snapd using dirty_sock exploit and demonstration of CVE-2019–7304

In January 2019, researchers discovered a privilege escalation vulnerability in default installations of Ubuntu Linux. This was due to a bug in the snapd API, a default service. Any local user could exploit this vulnerability to obtain immediate root access to the system (Linux Privilege Escalation via snapd, n.d.). In this post, I am going to exploit one of the affected Ubuntu 16.04 using dirty_sock exploit via snapd which created by security researcher. Moreover, snapd serves up a REST API attached to a local AF_UNIX socket. Access control to restricted API functions is accomplished by querying the UID associated with any connections made to that socket. User-controlled socket peer data can be affected to overwrite a UID variable during string parsing in a for-loop. This allows any user to access any API function.

Background

What is Snap?

In an attempt to simplify packaging applications on Linux systems, various new competing standards are emerging. Canonical, the makers of Ubuntu Linux, are promoting their “Snap” packages. This is a way to roll all application dependencies into a single binary — similar to Windows applications.

The Snap ecosystem includes an “app store” where developers can contribute and maintain ready-to-go packages.

Management of locally installed Snaps and communication with this online store are partially handled by a systemd service called “snapd”. This service is installed automatically in Ubuntu and runs under the context of the “root” user. Snapd is evolving into a vital component of the Ubuntu OS, particularly in the leaner spins like “Snappy Ubuntu Core” for cloud and IoT.

What Is Privilege Escalation?

Privilege escalation is the result of actions that allows an adversary to obtain a higher level of permissions on a system or network. Certain tools or actions require a higher level of privilege to work and are likely necessary at many points throughout an operation. Adversaries can enter a system with unprivileged access and must take advantage of a system weakness to obtain local administrator or SYSTEM/root level privileges. A user account with administrator-like access can also be used. User accounts with permissions to access specific systems or perform specific functions necessary for adversaries to achieve their objective may also be considered an escalation of privilege (Privilege Escalation, n.d.).

Vulnerability Overview

Vulnerability details

Chris Moberly discovered that snapd versions till 2.37 incorrectly validated and parsed the remote socket address when performing access controls on its UNIX socket. A local attacker could use this to access privileged socket APIs and obtain administrator privileges. On Ubuntu systems with snaps installed, snapd typically will have already automatically refreshed itself to snapd 2.37.1 which is unaffected.

On the NVD, we can see that CVSS Severity was extremely higher and critical (CVE-2019–7304, n.d.).

As well as, it was published on the Exploit Database on 13 thFebruary 2019 (snapd < 2.37 (Ubuntu) — ‘dirty_sock’ Local Privilege Escalation (1) , n.d.).

Exploit details

The exploit itself is written in python and does the following:

1. Creates a random file with the string ‘;uid=0;’ in the name

2. Binds a socket to this file

3. Connects to the snapd API

4. Deletes the trojan snap (if it was left over from a previous aborted run)

5. Installs the trojan snap (at which point the install hook will run)

6. Deletes the trojan snap

7. Deletes the temporary socket file

8. Congratulates researcher about exploit success

This exploit bypasses access control checks to use a restricted API function (POST /v2/snaps) of the local snapd service. This allows the installation of arbitrary snaps. Snaps in “devmode” bypass the sandbox and may include an “install hook” that is run in the context of root at install time.

dirty_sockv2 leverages the vulnerability to install an empty “devmode” snap including a hook that adds a new user to the local system. This user will have permissions to execute sudo commands.

This exploit can also be effective on non-Ubuntu systems that have installed snapd but that do not support the “create-user” API due to incompatible Linux shell syntax.

Some older Ubuntu systems (like 16.04) may not have the snapd components installed that are required for sideloading. If this is the case, this version of the exploit may trigger it to install those dependencies. During that installation, snapd may upgrade itself to a non-vulnerable version.

Demonstration

First of all, we are checking that snap version whether it is vulnerable or not (USN-3887–1: snapd vulnerability, n.d.). Hence, canonical snapd before version 2.37.1 incorrectly performed socket owner validation, allowing an attacker to run arbitrary commands as root. This issue affects: Canonical snap versions prior to 2.37.1. As we see, our snap version is 2.21 and was affected by this exploitation (CVE-2019–7304 (retired), n.d.). Fig.1

# snap version

Then we are looking what is our ubuntu lsb-release. A security issue affects these releases of Ubuntu and its derivatives:

# cat /etc/lsb-release

Here, we are checking the information on the current computer and operating system, by using the uname command. Now, it is clear that, our OS among the affected versions of Ubuntu.

Now are going to get list of users that has access to a system. This file is used to keep track of every registered user. As we see, last user is “ramil” which we created during installation process.

In this section, we are going to check sudoers file which sudoers file is a file Linux and Unix administrators use to allocate system rights to system users. This allows the administrator to control who does what. We can see that “ramil” user does not have a right to access this file.

# cat /etc/sudoers

In order to exploit this vulnerability, we will use diry_sock exploit which written by security researcher (Linux privilege escalation exploit via snapd, n.d.).

# python3 dirty_sockv2.py

After successfully running, dirty_sock exploit, we can see that dirty_sock with the same password account was created automatically by script. Again, we are looking the /etc/passwd users list and can see that dirty_sock was created successfully.

Finally, we are going to test this user.

# su dirty_sock

Checking with id command, we can see that dirty_sock is in the sudo groups as well. Then, we are checking the sudoers and getting permission easily, at the last line we can see dirty_sock can run any command because was set ALL.

Remediation

The main solution is patching affected system! The snapd team fixed this right away after this disclosure (Local privilege escalation via snapd socket, n.d.). On Ubuntu systems with snaps installed, snapd typically will have already automatically refreshed itself to snapd 2.37.1 which is unaffected.

For prevent given vulnerability users should periodically update snapd and OS. Due to this problem is new and relevant; the developers began to release new programs to ensure security from different packages. For instance, “Automox” platform to discover and detect quickly the level of the vulnerabilities in your system. It also can help to prevent risks such as snapd issue in a timely manner. Given platform help to recognize and sort security level such as Critical, High, Medium, Low, etc. Registered users are able to create own policies for security patches and apply them to the current system.

These solutions can be useful for commercials, which use Linux based servers with private information and big data for preventing data leakage, social threat, and infrastructure gaps and so on.

In conclusion, we can see that attackers try to find new gaps in systems and complicate the work of ordinary users with their own hands. Given problem are suitable for any type of system regardless types of technologies, devices, operating system and so on. Since Linux is open source system, it allows changing the system for hackers and finding minor vulnerabilities.

We learnt that we always should check new updates of systems; never ignore the newest patches and packages. Whenever possible, should track new vulnerabilities and bugs of systems from news, research blogs, and official sites.

Keeping usual rules and policies of information security as least privileges, scanning, CIA basics, etc. can help us to protect ourselves, do not face cyber-attacks and save private data as reliable as possible.

CVE-2019–7304. (n.d.). Retrieved from CVE-2019–7304: https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=CVE+2019-7304&search_type=all

CVE-2019–7304 (retired). (n.d.). Retrieved from CVE-2019–7304 (retired): https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-7304.html?_ga=2.171854953.858649686.1556965498-816269924.1556965498

Linux privilege escalation exploit via snapd. (n.d.). Retrieved from Linux privilege escalation exploit via snapd: https://github.com/initstring/dirty_sock

Local privilege escalation via snapd socket. (n.d.). Retrieved from Local privilege escalation via snapd socket: https://bugs.launchpad.net/snapd/+bug/1813365

Privilege Escalation. (n.d.). Retrieved from Privilege Escalation: https://attack.mitre.org/tactics/TA0004/

snapd < 2.37 (Ubuntu) — ‘dirty_sock’ Local Privilege Escalation (1) . (n.d.). Retrieved from snapd < 2.37 (Ubuntu) — ‘dirty_sock’ Local Privilege Escalation (1) : https://www.exploit-db.com/exploits/46361

USN-3887–1: snapd vulnerability. (n.d.). Retrieved from https://usn.ubuntu.com/3887-1/