
How to steal a developer's local database - chachram
http://bouk.co/blog/hacking-developers/
======
andrewstuart2
These have a fairly simple fix that you can implement yourself as a developer.
Don't let your services listen on (AKA bind to) 0.0.0.0 or 127.0.0.1.

The entire 127.0.0.0/8 block is dedicated to the loopback interface [1].
That's 2^24 - 2 unique IP addresses you can choose at random. This basically
eliminates the feasibility of the DNS rebinding component, as it would take
prohibitively long to find the actual loopback address that your services have
bound to.

It's important to note that this is much more effective than not using the
default port. It's _much_ faster to iterate all 2^16 ports on the same IP
address than it is to wait for DNS TTL to expire so you can rebind to another
IP address.

As a bonus, you don't have to worry about port collisions when nobody's
allowed to listen on 0.0.0.0. Everybody can use 8080 if they want.

[1]
[https://tools.ietf.org/html/rfc5735#section-3](https://tools.ietf.org/html/rfc5735#section-3)

~~~
jlgaddis
I'll point out for the benefit of others that not all operating systems treat
127.0.0.0/8 as belonging to the loopback interface.

Linux does, so this will probably work for the majority of users here, but, I
believe, it will not work for FreeBSD, for example (I'm on an iPad and don't
have an SSH client at the moment so I can't verify). In those cases, however,
you can add "aliases" to the loopback interface, with specific IP addresses in
the 127/8 subnet, and then use them.

~~~
JonathonW
On OSX (and, I suspect, vanilla FreeBSD), this looks like (replacing 127.1.2.3
with the address you want to use; 0xff000000 must stay the same, since
netmasks of all addresses on an interface must not confict if they're on the
same subnet):

    
    
        sudo ifconfig lo0 alias 127.1.2.3 0xff000000
    

And then, when you're done:

    
    
        sudo ifconfig lo0 -alias 127.1.2.3
    

to tear it back down.

~~~
X-Istence
Recommendation for aliases on an interface is to use 255.255.255.255 as the
netmask on FreeBSD.

For example to add extra interfaces to lo0 on FreeBSD you may use:

    
    
      ipv4_addrs_lo0="127.0.0.2-5/8"
    

in rc.conf

And now those addresses are automatically assigned to lo0, the netmask will be
set to 255.255.255.255 automatically for all but the first in that range (.2).
Since 127.0.0.1 is unconditionally assigned to lo0, you could also use:

    
    
      ipv4_addrs_lo0="127.0.0.2-5/32"
    

This is what I do on FreeBSD.

~~~
JonathonW
The ifconfig man page just says the netmask must be "non-conflicting" if on
the same subnet as the first network address for the interface (that'd be
127.0.0.1/8 for lo0). I'm presuming the narrower netmask qualifies as non-
conflicting?

~~~
X-Istence
Yes indeed!

------
digitalsushi
In a past life I had to write some DNS rebind attacks for some CPE testsuite
software that is out there.

It was very easy to write some javascript that hangs out in the browser, gets
the updated DNS host as the 192.168.0.1 address (sure sure, you can go crazy
guessing other addresses) and then about 60% of everyone was on admin:admin or
something as common; the first 12 or so bits of an ethernet address are the
vendor identifier, which makes the process even easier to assume. Then you
just start posting data to well-known web admin interfaces and update the
router password.

I have no idea how well this works, three or four years later...

~~~
richardwhiuk
I wonder there's a solution by requiring a PTR record pointing at each A
record which should have Same Origin Policy applied.

~~~
linkregister
This would break shared hosting, load balancers, or any other architecture
without a unique IP address per hostname. I don't think this is feasible
unless it's applied to IPv6 only due to IPv4 scarcity.

~~~
richardwhiuk
You can have multiple PTR records.

------
nothrabannosir
_> 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._

I'm sorry, but I disagree. A browser allowing externally loaded scripts to
access private ip ranges is not a reasonable decision.

PSA: To protect yourself from this, and some more bad browser defaults, use
NoScript with "allow all scripts globally." Keep the JS, but filter out some
bad stuff. Also enable ABE (application boundaries enforcer, made to solve
exactly this problem) for good measure.

~~~
CWuestefeld
_A browser allowing externally loaded scripts to access private ip ranges_

There are plenty of legitimate systems in the ecommerce world that rely on
doing this.

Take Ariba Punchout, for example. The idea is for the store to pass the user's
shopping cart back into the customer's internal ERP system to be turned into a
purchase order and sent for approval. The way this is handled is that the
initial request sets up a session including a URL to a customer-internal
service that's intended to handle the transaction. When the user completes
checkout, a page is returned to the user containing an XML payload, and script
to submit that XML to the specified internal service URL. That way, the store
is able to provide the PO data to what is otherwise a completely internal
system.

~~~
nothrabannosir
Which can all be handled using an (automated) whitelist, à la CORS.

Too many things run on localhost (or intranet) and assume that localhost=safe.
I know, "that's wrong" and "don't listen on 127.0.0.1" and all that, but that
horse has left the barn, emigrated, founded a family and died happy. We can't
put the 127/192/10 genie back in the bottle.

Prevent access to all private resources from the outside and whitelist on a
need-to-access basis. Or be ready to keep monkey patching your system against
these exploits forever.

------
corecoder
Now I'm a little scared.

A few months ago there was a post [0] by antirez about how dangerous it is to
leave a redis instance open to the world, in that an attacker could, for
instance, authorize an SSH key on your machine and gain remote connectivity.

While the average workstation is not usually reachable from the outside
network, you could probably combine some variant of that attack (the first
thing that comes to mind: overwrite .bash_profile) with the attack of this
article, causing a lot of fun.

[0] [http://antirez.com/news/96](http://antirez.com/news/96)

------
bm98
Running your browser in Red Hat's SELinux sandbox [1] [2] limits the ports you
can connect to and thus limits this type of attack to those ports (80, 81,
443, 488, 8008, 8009, 8443, and 9000 in the default configuration).

[1]
[http://danwalsh.livejournal.com/31146.html](http://danwalsh.livejournal.com/31146.html)
[2] [http://www.bress.net/blog/archives/195-Firefox-in-a-
sandbox-...](http://www.bress.net/blog/archives/195-Firefox-in-a-sandbox-with-
Fedora.html)

~~~
eeZi
This is the only advice in this threads that actually solves the issue.

Doesn't have to be SELinux, any of the frameworks will do. Or run it in a new
network namespace.

~~~
semi
Sort of. It solves this specific attack.

If you were attacking a local webapp interface instead of a non-http daemon
like redis, you would need your browser to be able to access the web service.
At that point, this kind of attack would still allow an attacker to also
access that web service.

------
cpcallen
I have seen this story posted and discussed in several locations. It boggles
my mind that everyone is talking about DNS filtering and/or browser security
models, when it's painfully obvious that the actual problem is the fact that
the targeted services (redis, memcached, elasticsearch, etc.) apparently do
nothing whatsoever to authenticate incoming connections (at least in their
default configuration).

Yes: remote DNS servers have no business serving up loopback addresses. Yes:
browsers shouldn't let remote scripts access resources on the local network.

But WTF are you guys doing running services bound to network ports (even if
only accessible from the local machine) that apparently have no authentication
whatsoever? Have none of you ever used a multi-user machine?

When I was in university we had just three SunOS boxen shared amongst all
undergrads in my faculty, and all three were directly accessible from the
whole of the internet - there was no firewall of any kind. Even back in those
rather more innocent days you learned real quick not to put up services which
didn't authenticate every incoming connection.

A good firewall is not a substitute for having individual machines be secure.

A machine having only one (intended) user is not an excuse to run services
that are not secure against local users.

------
orf
Interesting attack. A far more feasible one is just to throw nmap around your
next conferences WiFi network and try common postgres/mysql combinations.
You'd be surprised how many developers have such services exposed, often with
'developer passwords' and production dumps loaded.

~~~
mfenniak
I think it'd be very common to "protect" these services by making them bound
only to localhost. The fact that this attack bypasses that protection is
pretty interesting.

~~~
cleaver
It's also common to open these up so that team members can grab a copy of your
database. I haven't done that, but I can think of a case in the past few
months where a developer had done so.

Edit: Now that I think of it and especially with containerized dev
environments and VMs, I'd bet it quite common. I'm sure I've opened up a DB or
search container more than I needed to just because I couldn't get the damn
things to talk. I still would have a firewall, but not everyone does.

~~~
thirstytho
Yeah, I'm pretty sure I've bound services to 0.0.0.0 just to avoid the trivial
annoyance of checking an IP.

------
nbadg
Question: could DNS rebinding be used to tap into 1Password inter-process
communication? They use localhost websockets for IPC; it's authenticated
through the request origin and then through verifying the PID is in fact the
browser [1].

DNS rebinding could definitely get around the PID check, but could it spoof an
origin to something like "safari-
extension://com.agilebits.onepassword4-safari-2bua8c4s2c"?

[1] [https://support.1password.com/mini-extension-
security/](https://support.1password.com/mini-extension-security/)

~~~
foota
I don't see how this would work, seeing as the safari-extension protocol
doesn't get the location to go to based on DNS.

~~~
nbadg
Well first off, I honestly don't know if it's possible; if I knew, I'd just
shoot an email off to 1password.

That being said, I don't think we're suggesting the same thing. I'm saying one
could write a webpage that uses DNS rebinding to make requests on localhost,
like OP. Then, the webpage, completely bypassing the browser's built-in
extension system, makes a request to 1password over localhost (which they're
already using for IPC).

The reason that DNS rebinding is relevant is twofold; first, you need the
request to hijack existing IPC between the browser extension and the
standalone desktop app, and two, because you need to have the request come
from the browser's PID. That should all work.

The question here revolves around 1password's verification that the origin is
coming from, for example, something similar to

> safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c

So then your webpage would also need to be able to spoof the origin of your
localhost requests to look like they were coming from that origin. I don't
know if that's possible or not, but if it is, it would imply that this
technique could get you illegitimate access to 1password.

------
xenadu02
Browsers could pin DNS responses when a page finishes loading so any further
requests for that domain will use the cached IP instead of doing name lookups
but that would be a PITA because they generally rely on the OS DNS subsystem.
It might also break long-running pages that won't failover anymore.

It would probably be easier to simply keep a IS_LOOPBACK flag for every DNS
name resolved and kill any connection attempts if the flag changes while the
page is loaded. Then you can keep using the OS DNS resolver logic.

DNS might legitimately return a different CDN but it sure as hell won't flip
between private IP spaces and the public internet.

~~~
nneonneo
Captive portals [0] often return short-lived DNS responses to private IP space
until you pay or login, at which point their DNS servers start returning
proper responses (and stop intercepting DNS requests). Although not "legit",
this is a case which is very common - you wouldn't want your browser to
suddenly stop working because you connected to a captive portal that started
modifying DNS responses.

[0]
[https://en.wikipedia.org/wiki/Captive_portal#Redirection_by_...](https://en.wikipedia.org/wiki/Captive_portal#Redirection_by_DNS)

~~~
dividuum
You're both correct. I hope they find a solution to fix the utterly broken
garbage that captive portals are: Every "portal" is different and complete
prevents automated internet access. I hope this gets fixed somehow, although I
don't have high hopes:
[https://datatracker.ietf.org/wg/capport/charter/](https://datatracker.ietf.org/wg/capport/charter/)

------
antirez
Recently Redis aliased POST and Host: to QUIT for this reason.

~~~
powercf
It seems to me that they should quit on reading any input that they can't
parse. At best silently ignoring bad input leads to software not doing what
it's supposed to do. At worst it leads to attacks like this.

I realize this is contrary to "be conservative in what you do, be liberal in
what you accept from others", but I never thought that was a good way to write
software.

~~~
cbr
That's at the very least a much harder change to roll out, since if things are
broken after a new version of Redis comes out people will blame Redis for
breaking things.

~~~
powercf
I'm not very familiar with Redis, so I might be missing something here.

But if the choice, after a Redis update, is between: a) my software breaking
and, hopefully, an error message saying "redis failure parsing 'XYZ'" or b) my
software /maybe/ continuing to function, while passing commands to Redis that
it's ignoring

I would always pick (a), and I think most programmers would think likewise.

~~~
cbr
Let's say you're using a cache server as a best-effort cache, and you take
advantage of its ability to store complicated data structures. Your client
implementation has a small bug with one of them, and ~1% of the time it sends
something to the server that's not to spec. Right now, the server returns an
error for that specific request, but doesn't drop the connection and continues
processing later requests on the connection. You know about the errors, but
they're not worth fixing.

Now the cache server has a security update, so you apply it right away. But
now when it gets your invalid command it not only returns an error but it
drops the connection. Your client doesn't handle this well, and now your
caching is fully broken and your server falls over from the load.

~~~
antirez
That's exactly my point of view on the matter.

------
Puts
When you hear about someone jail breaking an iphone trough the browser, this
is how. The fact that the browser works as a window to all tcp-sockets running
on a device, it's the perfect way to exploit buffert overflows on a device
that lacks a terminal.

Also remember this with all your IoT appliances running on your local network.
Even if it has a local IP-address, as long as you have a computer with a
browser on the same network, you might as well consider your devices being
publicly accessible from the rest of the internet.

~~~
pomfpomfpomf3
what? I haven't heard of a single jailbreak that worked like that. You got
some links?

edit: to people linking me safari CVEs (can't reply to you all) - these are
memory corruptions. Not accessing ports on localhost.

~~~
iLoch
Since no one has provided you with a link, here's one such approach:
[http://www.redmondpie.com/how-to-jailbreak-
ios-9.3.3-using-s...](http://www.redmondpie.com/how-to-jailbreak-
ios-9.3.3-using-safari-no-computer-required/)

I think one of the first sites to do it was this one:
[https://jailbreakme.qoid.us/](https://jailbreakme.qoid.us/)

~~~
nneonneo
Your first link appears to require the installation of an app on the phone
(after installing a dev certificate). The app, running arbitrary native code,
performs the actual jailbreak (most likely using a chain of kernel exploits).

The devs seem to have gotten around the App Store by using an approach like
TestFlight, which allows apps to be deployed for development and wider testing
purposes without going through the App Store.

------
rhodey_orbits
Cool to see DNS Rebinding getting more attention lately :D just a couple
months ago I used DNS Rebinding to attack Ethereum wallets:
[https://medium.com/@rhodey/walking-past-same-origin-
policy-n...](https://medium.com/@rhodey/walking-past-same-origin-policy-nat-
and-firewall-for-ethereum-wallet-control-30c29b73a057#.ew1ir61kg)

~~~
bouk
Nice one! Not surprising to see cryptocoin implementers make all the classic
security mistakes

------
jasonkester
Do developers often run things on localhost? I mean sure, you'll have things
running on your dev machine, but for me at least,
[http://127.0.0.1/](http://127.0.0.1/) will just show the default webroot,
with its placeholder index.html. All my actual sites listen for custom
hostnames (since otherwise you only get one site per machine or have to do
silly things with port numbers on the url).

So unless somebody has crafted a page specifically targeting me and my naming
convention for local sites, this wouldn't be an issue. And of course, once you
hit a site, you'd still need to deal with the same security that the public
facing version sees. You certainly wouldn't go out of your way to disable that
on your local machine.

Databases are named, and often live within named database server instances, so
they'd need to be specifically targeted as well. And, again, they have
authorization to deal with. It's not like you'd leave that open either.

Is it common to do it any other way?

~~~
flukus
Yes, I've always run everything on localhost and use different ports, I think
most devs are the same. I've never even thought of doing anything else

> All my actual sites listen for custom hostnames (since otherwise you only
> get one site per machine or have to do silly things with port numbers on the
> url).

It's not just web servers though, every from databases to caches servers.

>Databases are named, and often live within named database server instances,
so they'd need to be specifically targeted as well

I think most would stick with the defaults. With mssql server it's "." or
"sqlexpress" or whatever.

>And, again, they have authorization to deal with.

I've always used windows authentication, but that now seems like a terrible
idea.

------
EdSharkey
In what universe does it make sense for a DNS server to serve records that
point to 127.0.0.1??

This DNS Rebinding hack should be easy to eliminate: only etc/hosts can make
records that point to localhost.

I don't care if a HUGE swath of applications are broken by this, DNS just
seems broken to allow remote DNS servers to make localhost records.

Please excuse my awkward use of words, I am a combination of sick and
delightfully ignorant about DNS.

~~~
nneonneo
DNS rebinding can also be used to attack private addresses, for which it would
be perfectly legal to have real DNS names (think DNS entries for a company's
intranet). Blacklisting localhost only offers a bit of security against silly
devs, but arguably pivoting an attack from a public server to a private
network is much more valuable and harder to stop.

~~~
EdSharkey
Well, that sounds super bad too!

There should be some central network policy in the enterprise that says a DNS
record coming from outside the company can't point to addresses on the
10.xx.xx.xx or 192.168.xx.xx spaces. I'm surprised that isn't already the
common configuration.

~~~
X-Istence
Unbound has that as a possibility in the recursive DNS resolver.

Super simple to set up too:

    
    
            # Enforce privacy of these addresses. Strips them away from answers.
            # It may cause DNSSEC validation to additionally mark it as bogus.
            # Protects against 'DNS Rebinding' (uses browser as network proxy).
            # Only 'private-domain' and 'local-data' names are allowed to have
            # these private addresses. No default.
            private-address: 10.0.0.0/8
            private-address: 172.16.0.0/12
            private-address: 192.168.0.0/16
            private-address: 169.254.0.0/16
            private-address: fd00::/8
            private-address: fe80::/10
            private-address: 127.0.0.0/8

------
parenthephobia
This problem doesn't just apply to localhost, although it's most
straightfoward to exploit that way. You could also use this technique to scan
the user's LAN or, in a more targeted attack, bypass IP address restrictions
on specific servers.

Scripts from the public Internet shouldn't be able to access private or local
networks as a matter of policy.

Similarly, in a high-security environment, scripts from a private network
shouldn't be able to access the public Internet - to help prevent exfiltration
of private data.

~~~
snuxoll
> Scripts from the public Internet shouldn't be able to access private or
> local networks as a matter of policy.

I agree, and it's encouraged some pretty stupid practices where it is used for
things _other_ than espionage or malicious intent.

Lenovo has a driver detection / update tool on their website, to run it you
download a helper application that opens up a HTTP endpoint on localhost, then
their website uses it to scan your system and (hopefully) shuts it down
afterward. Why was this done in the first place, forcing users to download and
run an executable (which has to be restarted each time you scan) that has no
UI except for the web browser tab you already have open is dumb.

------
thirstytho
I always kinda wondered when the other shoe was gonna drop on "why do
databases even have passwords"...

~~~
kuschku
I prefer key-based auth or local user based auth.

------
kevinbowman
I'm sure I've seen browsers (maybe Opera?) which wouldn't let a website on a
"routable" IP address make any requests at all to anything on a "non-routable"
IP address; I assume that 127/8 is included in the latter range. That approach
basically eliminates the DNS rebinding attack, I assumed that was normal
practice in all browsers - obviously not, though.

------
tapvt
Another good reason to develop w/in a virtualized server on your dev machine?

~~~
ars
No.

If you are going to go to that much effort, better to just spend a little bit
of time on security.

~~~
spdionis
The gain by using VMs and provisioning sofware is not limited to security.
There are a lot of good reasons to do that.

~~~
teilo
Correct. Like developing to a common deployment target, provisioning a
development VM with the same toolchain you use to provision production VMs,
isolating your VM from the system state of your development machine. I cannot
imagine developing any other way.

~~~
jacobsenscott
I did this for a while, but it falls apart with constant care and feeding. I
had a vagrant box that could be fully provisioned with Ansible, and checked
everything in to the repo. I paid for Parallels because virtualbox is too slow
to do any real work (unit tests take 2x or 3x longer to run for example).

I couldn't convince anyone else to use this stuff. They were happy to just run
some homebrew commands every now and then.

I was away from the project for about six months. When I got back I thought
"great, I'll just `vagrant up` and be back in business."

Parallels had upgraded itself to some version that wasn't compatible with
vagrant. I was eventually able to find an old parallels installer and
downgraded.

My laptop had a newer version of ansible, and it couldn't run the old ansible
scripts. There was no easy fix to something that should be easy (ansible could
no longer create postgres users when ansible was running through a non-root
account. With vagrant you log in as the `vagrant` user and that user has
sudo).

I deleted all that stuff, and now I do all my development locally. I do run my
DB's in docker containers, but that's it. Now it is super easy to add any
version of any database to any project. Just a few lines in docker-
compose.yml. But my docker-compose.yml was written for an older version of
docker-compose. I tried to upgrade it to the latest syntax and nothing worked.
I reverted that and things are still running. It is only a matter of time
before some docker update renders my db and redis useless.

At that point I'll just `brew install redis` and `brew install postgres` and
be done with it. Everything will run, and run at native speeds. Yay!

~~~
teilo
I think this is overstated. This only falls apart if you cannot get buy-in
from your development team, and are not applying proper version management to
your tool chain.

First, we use Ansible, not just for development, but for deployment. Because
of this, if the time comes to upgrade Ansible, everybody upgrades, and any
incompatible playbooks are immediately addressed.

Second, Parallels is a bad choice. They do not have a sufficient enterprise
focus, and their product is updated too often. It's great for desktop
virtualization, but not for much else.

We use VMWare Fusion, have no performance issues, and have never experienced
the issue of hypervisor bit rot. On the one occasion when we upgraded VMWare,
we also upgraded the corresponding Vagrant plugin, and everything worked fine.

~~~
jlgaddis
At least we won't have to worry about any future VMware Fusion upgrades
breaking anything, since there quite possibly won't _be_ any future upgrades.

------
csense
My takeaway from this is that binding to localhost doesn't give you as much
security as you think.

------
gschrader
Looks like the best way to protect against this is filtering private IP
addresses from DNS responses. Is there a reason why ISP DNS servers in general
would ever need to serve out a private IP?

~~~
extrapickles
The only problem with that is all ISPs will have to configure their DNS
systems to do so (not going to happen soon). The only reasonable fix would be
applied at the browser level as they are updated reasonably often.

A better mitigation than that mentioned in the article is that browsers should
ignore a DNS update if it goes from a public IP to a private IP range. DNS
pinning as suggested would cause havoc with most wifi captive portals,
especially for those not computer savvy or the badly configured/implemented
captive portals.

~~~
tener
I think you may be able to discover actual IP addresses with WebRTC. If the
host is on IPv6 then it may well be a public adress. Hence it would be
impossible to define "local" in this setup.

~~~
extrapickles
As far as I'm aware[0] there are private IPv6 addresses that should be treated
the same as 169.254 and 10/172/192 in IPv4. It shouldn't matter what IP the
host has, just what IP the address of the site you are communicating with goes
from the public range to private range.

[0]:
[https://tools.ietf.org/html/rfc4291#section-2.5.6](https://tools.ietf.org/html/rfc4291#section-2.5.6)

------
nneonneo
This is an interesting, albeit well-known attack vector. A similar attack was
used to attack Avast [0].

The author notes that write access could be used to inject dangerous objects
(e.g. malicious pickles) into the database. This is arguably a much more
serious bug because it does not require DNS rebinding (such a request can be
performed cross-origin) nor can it be mitigated by refusing to read the
response (as Chrome is proposing to do).

In short: the database modification attack is potentially much more severe,
but as of yet no precise attack chain has been identified. However, I think
it's very likely that some server software uses e.g. pickles in the database.

[0] [https://bugs.chromium.org/p/project-
zero/issues/detail?id=67...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=679&redir=1)

------
f055
Hmm, Little Snitch, if configured properly (ie. you allow the browser to only
connect to ports 80 and 443) will alert you if a site wants to connect to
something weird like 3306, 9000 etc. Then you can kill the packet and nothing
happens. Like on OPs PoC. Still, it's super interesting PoC.

~~~
lh7777
This kind of thing is exactly why I put up with the hassles of running Little
Snitch.

------
optimuspaul
I run my real databases on non-standard ports in docker and put honey pots on
the standard ports. In those I fill it with dialog from love scenes in popular
movies, it's not a ton of data but it's certainly interesting.

~~~
amazingman
That's cute. Do you happen to have it on GitHub? Would love to see what comes
through.

------
yarper
similar problem with intellij:
[https://news.ycombinator.com/item?id=12292148](https://news.ycombinator.com/item?id=12292148)

------
Mizza
I love this class of attack. I wonder if you could use a similar technique to
get German Trasmission users to download fine-inducing torrents, etc..

------
bahjoite
I've become increasingly complacent and often allow NoScript to "temporarily
allow all javascript on this page", but will stop doing it, having just tried
the PoC. It found Redis (which runs in a container, but with the port
exposed).

The PoC failed to work when using TorBrowser (with the security slider set to
High) and letting NoScript temporarily allow.

------
hrjet
We are designing a solution in gngr here:
[https://github.com/UprootLabs/gngr/issues/219](https://github.com/UprootLabs/gngr/issues/219)

In essence, the resolved address of a request will be checked if it lies in a
reserved block. If so, further policy checks will be made for the resolved
address, and the IP address will be pinned for that HTTP request.

Would appreciate feedback here, or on the issue.

------
runin2k1
"How to steal some developer's local database"

------
jkarneges
This reminds me of a similar vulnerability in webhooks [1]. I never thought of
throwing a POST request at Redis to muck with keys but I tried it just now and
it totally works. Geez.

[1] [http://blog.fanout.io/2014/01/27/how-to-safely-invoke-
webhoo...](http://blog.fanout.io/2014/01/27/how-to-safely-invoke-webhooks/)

------
edwinjm
Routers like Fritzbox also protects agains DNS Rebinding:
[https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-b...](https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-
base/publication/show/663_No-DNS-resolution-of-private-IP-addresses/)

------
tener
With WebRTC local ip discovery [1] it can be easily extended to work against a
whole local subnet. Looks very dangerous.

Probably best to attack this on the DNS rebind level. Encapsulating the
browser network context somehow and firewalling this might help mitigating
this attack too.

[1] [https://www.browserleaks.com/webrtc](https://www.browserleaks.com/webrtc)

------
amazingman
Seems to me that containerizing your dev environment with something like a
well-constructed _docker-compose_ YAML should mitigate this.

By "well-constructed" I mean that the backend services for a given project
should only be available on the container network, and not be exposed to the
host network.

------
thebeardedone
Out of curiosity, what data do you have in your development databases that
this becomes such a grave concern? I mean I'm all for security and love to see
how creative people can get but we are talking about dev environments and not
some part of the infrastructure (automated test machines, production, etc).

~~~
giosch
If you had read the whole article, you would have the answer to your question.
Es. It can get you to code execution if you poison python pickled data. Ecc..

~~~
collyw
I actually thought the opposite. Surely the database is more valuable than the
ability to execute code. Assuming its a copy of the production database.

------
ddalex
The crazy thing to me is that people here look for solutions at lower OSI
level (DNS, interfaces, IP address,) where to me the problem is that there are
these services that run with zero security.

Fix the services, require authentication and permission enforcement and the
problem is gone.

~~~
flukus
>Fix the services, require authentication and permission enforcement and the
problem is gone.

If the attack is coming from a browser it would authenticate with the users
credentials.

------
quickquest57
I noticed that I am running redis-server in the background on my mac...but I
have no idea what started it. I'm not doing any relevant development at the
moment, and haven't in months.

How can I trace the source and ensure it doesn't restart on reboot?

------
rbanffy
It's very concerning considering Homebrew's popularity and its habit of
running stuff as your local user. Compromising any application that runs as
you with as much access to your computer as yourself is pretty bad.

------
oandrei
Perhaps a server, when running in development mode, should require a custom
HTTP header? This would be a non-simple request, and the browser will refuse.
Would this be a reasonable counter-measure?

~~~
niftich
A secret value, whether it's called a 'password', a 'key', a 'token', or comes
in an 'Authorization' header or 'X-CustomHeader' is always a good
countermeasure.

~~~
oandrei
Right, but a custom HTTP header does not even have to contain a secret. I just
has to have a non-standard name. Firefox will refuse setting it, right?

------
knocte
Can this be solved by configuring the local system (e.g. Debian?) to blacklist
any DNS resolution that ends up being a private IP address? Is this is
possible to configure at the firewall level?

~~~
tener
How about local IPv6 addresses? I can easily see this being left out due to
sheer complexity.

~~~
knocte
I'm guessing that even in a future in which we have 100% of IPv6 deployment,
we would still run our loopback/LAN interfaces with IPv4 for simplicity...

~~~
nitrogen
It's too late. I have already run into issues on Linux distros with some
daemons binding to 127.0.0.1, but localhost resolving to ::1.

------
chx
Create a docker container, mount -v /tmp/.X11-unix:/tmp/.X11-unix in there and
run your browser that way. It's VM lite and mitigates this attack.

------
RussianCow
This is why I use Vagrant whenever I can. All my services live within a VM and
are only accessible via a specific hostname.

------
therealmarv
The PoC website works on my redis even when using Chrome canary 55 which
should have removed HTTP 0.9.

------
teilo
This is a non-issue for those of us who are using Vagrant or similar
development VM technologies.

~~~
michaelmior
Not necessarily since it's not that uncommon to expose the ports from the VM.
Not saying that's a good idea, but it happens fairly often.

~~~
teilo
These exploits rely upon the ports being exposed on localhost. Even if you are
not (as you should) using ssh tunneling to the VM, any exposed ports are on a
separate IP address, not localhost. However, if one is forwarding ports to the
host machine, that's obviously a problem.

~~~
Dylan16807
These exploits rely upon the ports being exposed _on a predictable IP_. A lot
of setups are going to give you very predictable IPs for the virtual machines.

~~~
lima
Thanks to WebRTC, it's even easier - you can enumerate all local IP addresses
and then you only have to scan one or two subnets.

Local VMs are _definitely_ vulnerable to this as well.

~~~
uniclaude
Not if you actually work in the VM, and do not expose database ports to the
host (why in hell would you do this anyway). No amount of ip scanning is going
to open ports.

~~~
estefan
> why in hell would you do this anyway

Integration with IDEs.

~~~
uniclaude
> _Integration with IDEs._

That's a fair point, but Rsync or shared folders should have you covered for
this.

~~~
estefan
Actually I meant something like how Intellij has DB integration, so you could
put in your host & port and connect to the DB to help you write queries etc.

------
snowmaker
Is there any similar attack for data in postgres / mysql local databases?

------
ex3ndr
Looks like Qubes OS is the only ultimate solution.

------
totony
The DNS rebind seems weird, any sensible DNS forwarder should ignore local ip
(127.0.01/8, 192.168.0.1, etc). This attack doesn't seem feasible if you can't
hinack local adresses.

------
govindpatel
I think that running elastic search on a different port (other than 9200) will
go undetected? (just a thought)

------
beeperless
If the box doesn't beep any longer - how can I find where I stored my speaker-
less server?

------
jbob2000
Oh no, my development database! What ever will I do if 10,000 entries of Lorem
Ipsum get leaked!? In the wrong hands, all of my bunk data from trying to get
a PUT right could be really dangerous.

~~~
CaptSpify
you joke, but I have to _constantly_ tell our devs "no, you can't have actual
prod data to test your queries against"

~~~
groue
Fine, as long as you can produce replacement data with the desired qualities.

~~~
talaketu
it's called a test fixture.

~~~
solidninja
Frequently data produced by hand (by developers writing the tests) or randomly
generated (by something like quickcheck) does not have all the edge cases you
would encounter in real data.

So there is some justification to having real data available - this is why in
the finance space at least developer machines have relatively stringent
restrictions placed on them compared to a lot of other organisations.

