Even developers who make the conscious decision to use secure software development practices can make mistakes...
that cause their security planning to look like it was for nothing. For example, Duo Labs recently discovered that the Redis open source tool appears to suffer from the same errors that software developers made over 40 years ago.
In this tip, we'll take a closer look at the Redis tool vulnerability and what organizations should do to prevent attacks.
The Redis vulnerability
Redis is an open source, in-memory, key-value NoSQL database frequently used for caching data. Many times, it is used to provide high-performance access to frequently used data that is part of a larger data set stored in a more traditional database. Since it stores its data in memory, Redis can be used to achieve a higher performance level of data caching. It also has functionality to write data to disks to maintain the data stored in the database if the server is restarted. The Redis project claims it uses secure software development practices for writing code to prevent buffer overflows, format bugs and other memory corruption issues, and that it isn't vulnerable to SQL injection-like attacks.
With that said, Redis made the mistake of assuming its software was only going to run in trusted environments. For example, Redis allows configuration changes to be made remotely, which carries enormous risk. Many enterprises are moving toward a zero-trust network environment, so Redis' security design decisions are flawed.
This was clearly demonstrated by a December 2015 attack, in which someone was setting passwords on Redis systems that did not use passwords, causing a denial of service on the server. The recent Redis tool flaw, discovered by Duo, was used to gain shell access to vulnerable Linux servers.
In the attack, the insecure Redis configuration let an unauthenticated user make changes to the configuration and write data of the root user's SSH authorized key file, allowing the attacker to log in as the root user. Duo Lab researcher Jordan Wright further investigated the attack and determined that the attacker had deleted data and notified the system users that their data was being held for ransom. This appears to be the same attack methodology used in the Fairware ransomware attack, and it was potentially carried out by the same attackers.
What organizations should do to prevent attacks
The simple nature of the Redis tool vulnerability and the Fairware ransomware attack makes it easier for an enterprise to protect itself from future attacks, so long as it takes the correct manual steps. Duo recommends setting a password, removing unnecessary functionality (such as renaming the config command), keeping the software updated and using the new protect mode to limit network access to Redis. This is sound advice for practically any piece of software, and has been for a long time.
Redis also has security recommendations, but it is unclear why the default settings are so insecure and allow for these types of attacks.
There are a couple of additional steps enterprises can take to protect their Redis software systems:
- Scan your systems to identify those running the Redis tool and the version in use. Enterprises should also be aware of when Redis is distributed bundled with an application or through a Docker container used in their environment.
- Firewall Redis servers to only allow access from approved systems.
- Monitor the network for external connections to Redis servers and place alerts on external connections for additional investigation.
- Run the Redis tool as a nonprivileged user and do not run Redis as root. This way, Redis can't write to the root SSH keys.
The Redis vulnerability clearly illustrates the sorry state of software security and the security awareness of software developers. It also demonstrates a lack of knowledge on the part of organizations; as Duo points out in its blog, there were more than 18,000 instances of Redis tools exposed on the internet, and the overwhelming majority were out of date versions of the software.
Knowing a little bit of software security history can be very useful for software developers, so that they don't repeat the mistakes of the past, as well as for developers who need to know basic secure software development practices.
Most enterprises and individual information security professionals have benefited from open source software, and those who want to contribute the community should volunteer their time to help open source projects incorporate security to prevent simple mistakes.
Learn about the effects of Open Sourced Vulnerability Database's closure on open source security
Find out if the open source model has more benefits or drawbacks
Discover five ways to improve network security and prevent ransomware