Vulnerability: Unprivileged Linux users can execute any command

January 8, 2019
Phishing and Fraud Opportunities on the Vulnerability

Phishing and Fraud Opportunities on the Vulnerability:

Root access on most devices is severe to the point that everything on your machine can be copied and sniffed out to a hacker’s computer. Search for malware alone won’t suffice, because vulnerabilities cannot be simply scanned through normal malware protection, so much for malware detection alone too. Below article will explain the technical aspect on how a Linux system can be taken over through this specific vulnerability.

An unprivileged user account on most Linux working frameworks with UID value anything greater than 2147483647 can execute any systemctl command unauthorizedly- on recently confirmed discovery of this vulnerability.

systemd version the issue has been seen with
$ systemctl –version
systemd 239
+PAM +AUDIT -SELINUX +IMA +APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

The reported vulnerability actually reside in PolicyKit (otherwise called polkit)— an application-level toolkit for Unix-like working frameworks that defines policies, handles system-wide privileges and gives an approach to non-favored procedures to speak with privileges ones, for example, “sudo,” that does not concede root authorization to a whole procedure.

pkttyagent –version
pkttyagent version 0.115

The issue, followed as CVE-2018-19788, impacts PolicyKit variant 0.115 which comes pre-introduced on most mainstream Linux flavor, including Red Hat, Debian, Ubuntu, and CentOS.

$ id
uid=4000000000(someuser) gid=100(users) groups=100(users)
$ systemctl stop sshd.service
Failed to stop sshd.service: Interactive authentication required.
See system logs and ‘systemctl status sshd.service’ for details.
$ systemctl is-active sshd.service
active

The vulnerability exists because of PolicyKit’s inappropriate approval of authorization request for any low-privilege client with UID more greater than INT_MAX.

$ id
uid=4000000000(someuser) gid=100(users) groups=100(users)
$ systemctl stop sshd.service

(pkttyagent:3342): GLib-GObject-WARNING **: 13:28:53.802: value “-294967296” of type ‘gint’ is invalid or out of range for property ‘uid’ of type ‘gint’
**
ERROR:pkttyagent.c:156:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
$ systemctl is-active sshd.service
inactive

Where, INT_MAX is a steady in computer programming that characterizes what most maximum value a integer variable can store, which equivalents to 2147483647 (in hexadecimal 0x7FFFFFFF).

Case replication:

This created priv (user) with UID 4000000001 and uses systemctl ufw.service, there is no issue at this stage as seen below uses typical account UID

Phishing and Fraud Opportunities on the Vulnerability


This replicated priv (user account) trying to stop ufw.service and it did.

So it implies, in the event that you make a client account on affected Linux systems with any UID greater than INT_MAX esteem, the PolicyKit component will enable you to execute any systemctl command succesfully.

 At this point the bug has been fixed and, fixes will be implemented we’re just waiting for policykit -1 packages to be added to the various Linux distribution.

 

What are the possible risks?

Once data is exposed, it can go to anywhere as long as the internet can reach it, whether it be a private storage of some group of people or an unsecured file download site. What is worse is personal information will be turned into FULLZ or Dumps to be on sale within the Darkweb.
Dark web marketplace is a real threat, how are you planning to recover and validate data from the Dark web with all these leaks due to vulnerabilities?
Does every company who has high value data have a current Dark Web Monitoring routine? It’s time to think about securing data way beyond the intra network.

 

About the author

Leave a Reply