Many Internet-Exposed Servers Affected by Exploited Redis Vulnerability
Rapid7 security researchers have identified 2,000 internet-exposed Linux servers that appear to be impacted by a Redis vulnerability that has been exploited in attacks.
Tracked as CVE-2022-0543, the security hole has a CVSS score of 10 and is described as an insufficient sanitization in Lua. While Redis statically links the Lua Library, some Debian/Ubuntu packages dynamically link it, leading to a sandbox escape that can be exploited to achieve remote code execution.
Both Debian and Ubuntu announced patches for the bug on February 18. On March 8, however, Brazilian security researcher Reginaldo Silva, who was credited for finding the issue, released proof-of-concept code targeting it.
In-the-wild exploitation of this vulnerability started days later, and the US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities Catalog in late March.
Now, Rapid7 says a Metasploit module was made available on April 26 and warns that “attackers will continue to opportunistically exploit this vulnerability as long as there are internet facing targets to exploit.”
According to Rapid7, there are roughly 2,000 potentially exploitable targets out there, namely Ubuntu/Debian instances that have Redis configured in a dangerous, non-default state, and which are exposed to the internet.
However, the researchers also note that there are roughly 33,000 Redis servers that allow unauthenticated access from the internet, along with others that are publicly accessible but require authentication.
“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,” Rapid7 notes.
The researchers believe some of these servers might be honeypots, but point out that, overall, the number of targets vulnerable to CVE-2022-0543 appears higher than initially 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,” Rapid7 concludes.