Research from security firm Incapsula has found somestartling Redis security issues that should concern everyone who uses the popular open source database platform: 75% of public-facing servers are infected with malware.
In order to gain an understanding of the scope of the problem Incapsula set up a public-facing Redis honeypot, and in less than 24 hours it had been scanned and infected with malware that used the server to mine cryptocurrency.
Incapsula queried all publicly accessible Redis servers it could find, and of the ones that responded it found that more than two-thirds were infected with malicious keys, and 75% were infected with malicious values.
“The attacks included SQL injection, cross-site scripting, malicious file uploads, remote code executions etc. These numbers suggest that attackers are harnessing vulnerable Redis servers to mount further attacks on the attacker’s behalf,” Incapsula said.
Those using Redis servers are right to be concerned about the incredibly high infection rate among those with public-facing IP addresses, but there’s more going on than just a simple software vulnerability: Redis servers aren’t designed to be public-facing at all.
Why public-facing Redis servers are a malware mess
Incapsula’s post on Redis vulnerabilities is clear on one central issue: Redis servers are not meant to be publicly exposed, something that Redis says itself on its Security page.
“Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket,” Redis’ website states.
SEE: Network security policy (Tech Pro Research)
Redis’ security page adds that “Redis is not optimized for maximum security but for maximum performance and simplicity.” Given that, along with Incapsula’s mention that Redis does not support encryption, has no access control, and stores data in plain text, the answer to “why are so many Redis servers infected” is clear: They shouldn’t be accessible outside a local network.
Incapsula also found that public-facing Redis servers, infected or not, contain “private SSH keys that can be used to access servers, certificates that can be used to decrypt network traffic, PII, and more sensitive data,” all of which are unencrypted and accessible by remote users.
How to protect your Redis server
The simplest, most obvious, and most effective thing to do to your public-facing Redis server is to take it offline. That is an important first step, but Redis gives other security suggestions on the page linked above, all of which should be considered.
- Access control doesn’t truly exist in Redis, but a “tiny layer” of authentication can be turned on in the redis.conf file. A Redis administrator sets a password in redis.conf, which users have to use when attempting a Redis query by typing AUTH followed by the password.
- “In order to implement setups where trusted parties can access a Redis instance over the internet or other untrusted networks, an additional layer of protection should be implemented, such as an SSL proxy. We recommend spiped.”
- Redis commands can be renamed, which Redis recommends doing in order to prevent unauthorized users from tampering with a server. Administrators can rename commands inside the redis.conf file by using the statement “rename-command (ORIGINAL COMMAND NAME) (NEW NAME).” Commands can also be disabled using the same rename-command argument with “” in place of the new name.
- Monitor your Redis server for irregular CPU consumption and other suspicious-looking changes.
- Run Redis with as few permissions as possible to prevent an unauthorized user from making changes. Redis recommends creating an unprivileged user specifically for that purpose.
Update 6/1/18: Redis Labs CTO Yiftach Shoolman told TechRepublic that “Redis will only be open to the public if someone specifically disabled the protected-mode and allows binding to public interface without setting a password,” and both options are enabled by default. Redis creator Salvatore Sanfillipo added that many third-party Redis VM images have been created with those default security tools disabled, and are distributed in a vulnerable state, something that Redis Labs has no control over.
The big takeaways for tech leaders:
- 75% of Redis database servers with a public-facing IP address are infected by malware, research from security firm Incapsula found.
- Redis servers are light on security in order to increase performance and aren’t designed to be accessible outside of a LAN. Those with public-facing Redis servers should remove them from the internet, check them for malware, and implement other security practices recommended by Redis.
- Special report: A winning strategy for cybersecurity (free PDF) (TechRepublic)
- Cloud vulnerabilities are being ignored by the enterprise (ZDNet)
- Why enterprises are finally paying up for big data security (TechRepublic)
- Open-source software management fails to meet security concerns (ZDNet)
- 2016 was a bad year for NoSQL databases, and the cloud is to blame (TechRepublic)
- SQL injection attacks: A cheat sheet for business pros (TechRepublic)