Last Updated: 2022-01-25 21:47:44 UTC
by Bojan Zdrnja (Version: 1)
Researchers from Qualys today published an advisory about a local privilege escalation vulnerability in the pkexec tool, that is installed as part of the Polkit (formerly PolicyKit) package.
This package is used for controlling system-wide privileges. The pkexec tool, which is a command line tool, is used to define which authorized user can execute a program as another user. As such, this is a critical tool and, due to requirement to control such privileges is installed as a SUID binary, as shown below:
$ ls -l /usr/bin/pkexec
-rwsr-xr-x 1 root root 31032 May 26 2021 /usr/bin/pkexec
As such, this is, of course, a prime target for an attacker. Qualys researchers posted a detailed blog post at https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034
Now, there are three scary things about this vulnerability:
- It has been around for 12+ years (!!!) since it was introduced in a commit to pkexec in May 2009
- The affected version of pkexec is installed with all popular Linux distributions: Ubuntu, Debian, Fedora and CentOS
- It is very simple to create the exploit, and it works 100% reliable
Did I say it’s simple to create the exploit? I successfully recreated it, as shown in the figure below, where it is executed on a fully patched Ubuntu 20.04 system – before the polkit patches being installed (which are luckily already out):
We expect that the exploit will become public soon and that attackers will start exploiting it – this is especially dangerous for any multi-user system that allows shell access to users.
Since most major distributions already released patches, the best option now is to install the patches. Of course, you’ll need to do it on all systems. If you cannot, or if there are no patches available, you can prevent the vulnerability from being exploited by removing the SUID bit from the pkexec tool; just make sure that you are not breaking anything.
Finally, for those blue teamers, the exploit will create the following system log, which was on my Ubuntu box in the auth.log file:
Jan 25 21:53:27 ubuntu pkexec: infigo: The value for the SHELL variable was not found the /etc/shells file [USER=root] [TTY=/dev/pts/1] [CWD=/home/infigo/exploit] [COMMAND=<redacted>]
As Qualys also noted, the first part (highlighted above) can be used for alerting, but keep in mind that it is possible to exploit the vulnerability without the log above being generated.
Last Updated: 2022-01-25 03:36:04 UTC
by Brad Duncan (Version: 1)
Last week, I wrote a diary about Emotet using 0.0.0.0 in its spambot traffic instead of the actual IP address of the infected Windows host (link).
Shortly after that diary, Emotet changed from using 0.0.0.0 to using the victim's IP address, but with the octet values listed in reverse order.
During a recent Emotet infection on Tuesday 2022-01-24, my infected Windows host was using 188.8.131.52 as its source IP. Note that my source IP has been edited for this diary to sanitize/disguise the actual IP address. See the image below for DNS traffic representing a possible spam blocklist check by my infected Windows host. In other malware families like Trickbot, the octet order is reversed. But order is not reversed for this Emotet infection.
As seen in the above image, the following DNS queries were made:
Again, I normally see the octet order reversed with other malware like Trickbot. This reversed order also appeared during SMTP traffic with the command ELHO [184.108.40.206] as shown below.
Twitter discussion for last week's diary indicates Emotet developers may have broken something in the spambot module to produce the previous 0.0.0.0 traffic. I'm not sure if this new traffic--the reversed order of the victim's IP address--is intentional or not.
You can find up-to-date indicators for Emotet malware samples, URLs, and C2 IP addresses at:
brad [at] malware-traffic-analysis.net