Three-quarters of open Redis servers are infected with malware, according to new research.
In a recent blog post by security researchers at Imperva, a Redis server was set up as a honeypot in order to understand the magnitude of the problem. Within less than 24 hours, the servers started to register attacks.
Researchers said that attackers set a key/ value pair in the memory and then saves it to a file in the disk in a location that will force the file to run (e.g /etc/crontabs, /var/spool/cron/crontab etc.). Attackers usually set values that include commands to download external remote resource and run it. Another popular type of command is adding SSH keys, so the attacker can remotely access the machine and take it over, according to researchers.
Imperva then took the attacks keys and scanned 72k publicly available Redis servers to see if they were hosting any of the attacks registered by the honeypots.
It found that more than two-thirds of the open Redis servers contained malicious keys and three-quarters of the servers contained malicious values, suggesting that the server is infected. Also, according to Imperva's honeypot data, the infected servers with “backup” keys were attacked from a medium-sized botnet (610 IPs) located in China (86 percent of IPs).
Researchers said that the firm's customers were attacked more than 75k times, by 295 IPs that run publicly available Redis servers. The attacks included SQL injection, cross-site scripting, malicious file uploads, remote code executions etc. Researchers said the numbers suggest that attackers are harnessing vulnerable Redis servers to mount further attacks on the attacker's behalf.
Nadav Avital, security research team leader at Imperva, said that the reason why 75 percent of open Redis servers are infected with malware was most likely because they are being directly exposed to the internet.
“However, this is highly unrecommended and creates huge security risks. To help protect Redis servers from falling victim to these infections, they should never be connected to the internet and, because Redis does not use encryption and stores data in plain text, no sensitive data should ever be stored on the servers,” said Avital.
Broderick Perelli-Harris, senior director of Professional Services at Venafi, told SC Media UK that the most concerning aspect of this research is the use of SSH keys as part of the attack chain.
“If the attackers have placed SSH keys onto the vulnerable Redis servers, it is almost certain that the attackers have now moved onto other targets within the infected environment,” said Perelli.
“Control, detection and remediation of rogue SSH keys is critical to protecting enterprises. Organisations lacking controls around SSH keys are leaving a gaping hole in their cyber-security armour which, as shown by this research, is increasingly being used for attacks. Any organisation that has unprotected Redis servers in “hot” Internet facing network zones should immediately review their SSH keys and machine identities. It is entirely possible that attackers are using these servers as a base from which to launch further probes and attacks.”
Joseph Carson, chief security scientist at Thycotic, told SC Media that organisations should detect which systems they have Redis installed by running a small script that will output the service running along with version. Once detected, you then want to check for indicators of compromise.
“There are a few steps organisations can take: make sure servers aren't directly facing the public internet and harden them by ensuring they have limited privileges, strong access controls and authentication protocols in place. Additionally, do not use the server for any sensitive information as it is only stored in clear text,” he said.
