原文链接: http://bouk.co/blog/hacking-developers/
If you’re reading this and you’re a software developer, you’re probably running some services locally. Redis, Memcached, and Elasticsearch are software products that many rely on. What you might not know, is that these locally running services are accessible by any website you visit, making it possible for bad guys to steal the data you have locally!
How it works
While I am not presenting anything new in this post, I have never see anyone put together this attack as complete as I’ll be showing here. I combined two different attack approaches, namely ‘cross protocol scripting’ and ‘DNS rebinding’.
Talking to Redis, Memcached, and Elasticsearch
The first technique is an old one sometimes called ‘cross protocol scripting’. A paperwas published in 2001 detailing this attack, but the gist is that both Redis and Memcached have a simple line-based protocol that ignores any invalid commands. This means that if a browser sends the following HTTP request to localhost:6379(where Redis usually runs), Redis will happily execute the SET command.
POST / HTTP/1.1 Host: localhost:6379 SET abc 123 QUIT
We can send a request like this by submitting the following form:
<form enctype="text/plain" method="POST" action="http://localhost:6379"> <textarea name="abc"> SET abc 123 QUIT </textarea> <input type="submit" value="Submit" /> </form>
Elasticsearch’s protocol is fully HTTP-based so there are no tricks needed to communicate with it.
While we can execute any command, we can’t actually retrieve the result. This is because of the browser’s same-origin policy, which ensures that reading data from a request to another domain is not possible. That’s where the second technique comes in!
DNS Rebinding
To get around the origin protection we can use a technique called DNS rebinding. DNS rebinding involves having a server accessible through a public domain with a very low TTL. Once a browser connects to the site, the site will immediately change the DNS record to point to a different IP address (like 127.0.0.1). This leads to a situation where the site runs the attackers’ code, in the context of a private IP address. This site can then go ahead and steal any data that is available on a service, that was set up with the assumption of only being available through authorized clients.
PoC
I have created a proof of concept of this attack on extractdata.club. The site will attempt to connect to Redis, Memcached and Elasticsearch running on their default ports on localhost.
After about a minute that link should display something similar to the following:
While my PoC only retrieves the version information of each service, it can’t be hard to imagine building a sort of scraper that goes through the whole database and extracts all of the data. The code is available here.
Mitigation
Unfortunately, there is no easy way for the databases to structurally fix the issues shown here. You could set up your services with passwords, but as long as the default state is vulnerable, lots of people will keep being susceptible. The only thing that I can come up with is for Redis and Memcached to add Host: as an alias to QUIT, so the connection is immediately aborted as soon as it is identified as being a HTTP request.
The other place this could be fixed is in the browser. Browser vendors could implement a ‘DNS pinning’ of sorts, which makes it ignore DNS changes that are made after the site is done loading.
Alternatively browser vendors could add the Redis and Memcached ports to their list of blocked ports, which already contains common protocols like SMTP and IRC. This would be not a structural fix however, and new services could pop up that are vulnerable.
Edit – The Chromium developers are working on removing HTTP/0.9 support, which will make the browser unable to read the response from Redis and Memcached. This is great progress, but still leaves the possibility for any page to execute commands.
Building on this attack
For some people it might not be a big deal to have data stolen from their development database, but read and write access could potentially lead to remote code execution. As an example, an attacker could overwrite anything that looks like Ruby marshalled or Python pickled data with their own payload, leading to a compromise of the developer’s computer.
Conclusion
This proof of concept shows why computer security is incredibly hard to get right. The attack depends on multiple software products all making very reasonable decisions about how they should work, but the way they interact with each other leads to a vulnerability.