Note: This issue is being discussed about a year late, as it was sitting forgotten in my blog post queue for some time. However, I have decided to post it now as it is still very much relevant. The attack explained below appears to still work on version 3.2.1 of Redis (tested on OS X and installed via brew). If the PoC fails and your inputrc file isn’t written to, it’s likely a directory permissions issue. Perhaps Redis is running as its own user, as it should?

The moral of the story is that even services on your own laptop that only listen on the loopback interface still need to be locked down.


I’ve developed a somewhat new proof of concept for a client-side attack on Redis. I say somewhat new because the concept of executing Redis commands via JavaScript is nothing new. However, the original lua exploit detailed by benmmurphy has been patched and the question has become “so what’s the threat now?”

Well, I don’t have a lua sandbox escape 0day. And developer machines don’t typically run SSH exposed to the Internet, so dropping keys into a user’s authorized_keys file like antirez explains in his post isn’t all that relevant.

Am I out of luck?

The Readline Init File

When I think back to the attack on users’ authorized_keys files, I am reminded that there may be other sensitive files on Linux filesystems which can be abused. An ideal file would be parsed by a service which doesn’t care if 99% of the file is garbage. This is important because rdb files contain a bunch of data at the beginning of the file we don’t care about.

The readline init file comes to mind. Programs which use readline can be customized with keybindings. Bash uses readline. Hey, maybe there’s something there! Now this isn’t nearly as cool as benmmurphy’s lua PoC, and it requires that whatever user Redis is running as have write permissions to your home directory. However, the readline init file parser does seems to ignore lines that aren’t valid entries, and if it works I could use keybindings to force you to execute malicious code when you type something in your terminal.

This means that if you’re a developer and you have Redis running in protected mode, as your own user or root (or some other user which has write permissions to your home directory), I can still own you through your browser. I can use JavaScript to craft an HTTP POST request to port 6379 and abuse Redis commands in such a way that I can write data to an arbitrary file. I can use this to write data to your user’s .inputrc file and mess with you.

Proof of Concept

Click here for a proof of concept. Note that the source must be HTTP for this to work, due to issues with mixed content.

Screen-Shot-2016-07-18-at-5-06-12-PM-1

Screen-Shot-2016-07-18-at-5-06-34-PM

Screen-Shot-2016-07-18-at-5-06-57-PM

Typing z triggers the payload in the terminal. It even includes a new line at the end so the command automatically executes.

Screen-Shot-2016-07-18-at-1-29-57-PM-1

Client-Side Redis Attack Proof of Concept

One thought on “Client-Side Redis Attack Proof of Concept

Leave a Reply

Your email address will not be published. Required fields are marked *