Local privilege escalation vulnerability in polkit's pkexec (CVE-2021-4034)
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[6999]: 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.
Emotet Stops Using 0.0.0.0 in Spambot Traffic
Introduction
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.
Details
During a recent Emotet infection on Tuesday 2022-01-24, my infected Windows host was using 173.66.46.112 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.
Shown above: Possibly spam blocklist check by my Emotet-infected host on Tuesday 2022-01-24.
As seen in the above image, the following DNS queries were made:
- 173.66.46.112spam.abuse.ch
- 173.66.46.112.b.barracudacentral.org
- 173.66.46.112.bl.mailspike.net
- 173.66.46.112.spam.dnsbl.sorbs.net
- 173.66.46.112.zen.spamhaus.org
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 [112.46.66.173] as shown below.
Shown above: Victim IP address in Emotet spambot traffic on Tuesday 2022-01-24.
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.
Final words
You can find up-to-date indicators for Emotet malware samples, URLs, and C2 IP addresses at:
- https://urlhaus.abuse.ch/browse/tag/emotet/
- https://feodotracker.abuse.ch/browse/emotet/
- https://bazaar.abuse.ch/browse/tag/Emotet/
- https://threatfox.abuse.ch/browse/malware/win.emotet/
---
Brad Duncan
brad [at] malware-traffic-analysis.net
Comments
www
Nov 17th 2022
6 months ago
EEW
Nov 17th 2022
6 months ago
qwq
Nov 17th 2022
6 months ago
mashood
Nov 17th 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
5 months ago
isc.sans.edu
Dec 26th 2022
5 months ago