14

I found this website which talks about fixing a Redis vulnerability by exploiting that same vulnerability.

The website in question has a "patch me" button, and if you have a password-less Redis server running on your machine, it will patch it.

In other words, the website itself connects to the Redis Server in your computer and executes some commands.

If you look into the website code you find, predictably, this:

    var text = "the code to run";
    var bad = "EVAL "  + JSON.stringify(text) + " 0\r\n";
    var x = new XMLHttpRequest();
    x.open("POST", "http://localhost:6379");
    x.send(bad);

To my surprise, this works!

I thought the Cross-Domain Policy would stop this from running, but it doesn't.

Why does this work, and how can I now not be paranoid that every website I go into is reading the entire contents of my Redis server?

It is because it's only writing but not reading? Still, any website in the world could empty my local Redis server / write to anything else listening to a port in my machine without authentication.

Am I missing anything here?

  • 2
    Do you mean Same-Origin Policy? That only applies to reading data from another origin, not sending it. – Neil McGuigan Jun 19 '15 at 16:06
  • BTW: if origin website is https this doesn't work anymore, as http AJAX to localhost is not allowed. (and localhost can't have a globally valid SSL certificate) – lapo May 31 '18 at 7:45
4

To answer the question: Yes a website can make an HTTP request to localhost. It will not break cross domain policy, because the request will not cross domains. It will stay local. One way to avoid cross domain policies, is to get the target victim to make the HTTP request themselves. Thus the request never crosses domains.

To help you understand the issue you described:

The attack is not sending any data out, nor is it making a connection to anywhere other than the local Redis machine. It's not the website itself connecting to your Redis machine. It's you connecting to your Redis machine, executing client side code/scripts that you ran by clicking the link. Basically: You click link > Link downloaded and executes some code -> code generates an http request -> http request goes from your machine, to your machine.

The vulnerability of the Redis server in this situation is Cross Site Request Forgery. The attacker leverages the victims (in this case, the owner of the server) authentication to execute the attack.

The attacker doesn't have full control over the process. They rely on the owner of the Redis server to execute the code. Only the owner (or someone else local to the Redis server) has the visibility (and perhaps the permission and trust relationship) to access 127.0.0.1 (Localhost)

All that the code can do is execute commands that the local user can execute, but it's not the attacker that executes them, it's the owner, and so no Cross Domain Policies are violated.

The only people affected by links like that would be people running Redis servers. If you don't have one, the link won't do anything. Also, it will only run on the local Redis server. The attacker can't really choose where the exploit will happen.

Look up Cross Site Request Forgery. https://en.wikipedia.org/wiki/Cross-site_request_forgery

  • I understand this, but... a) Me clicking the link was optional, he could've run the AJAX request onload. b) Even without a vulnerability in Redis, he could've happily had run FLUSHALL, for example. c) with the vulnerability, he can probably escape sandboxes and do nasty stuff. Again, with a piece of JS that could run onload on any website... But that's not my point, the point is writing to local ports on my machine... Most developers have local Redis without passwords, and I'm sure they don't know browsing the web could clear their Redis DBs... I wonder how many other things like this I have – Daniel Magliola Jun 19 '15 at 14:11
  • 1
    There is a reason websites are not allowed to do stuff, like, for example, writing to your hard drive, or deleting files. It wouldn't be the website, it'd be you, running the code in the website, with your priviledges, so they could only access files you can access, but that doesn't quite mitigate it. In this case, "all they can do" is clean / write to my local Redis server. That sounds pretty bad on its own, but I wonder what other services I have running that you could write to and harm me in some way... – Daniel Magliola Jun 19 '15 at 14:13
  • I'm not sure what your question is then... You are correct, Cross Site Request Forgery could be a vulnerability in other services you run. – meltdownmonk Jun 19 '15 at 14:16
  • There are things Redis could do that would ensure their server can't be cleaned or written to. Usually using nonces (random one time use numbers) that are required for each request/command to the server. The attacker won't be able to supply these from their script. – meltdownmonk Jun 19 '15 at 14:18
  • This could also apply to an unsecured, local MySQL server, couldn't it? Couldn't someone write commands to MySQL using this same technique? (just using MySQL as an example) – Daniel Magliola Jun 19 '15 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.