17 ms·

How to steal a developer's local database

• runin2k1 10y ago
  "How to steal some developer's local database"
• orf 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        Yeah, I'm pretty sure I've bound services to 0.0.0.0 just to avoid the trivial annoyance of checking an IP.
  • falcolas 10y ago
    Of course, this can be done against anybody who hits a web page, instead of just against machines on your local network. But yeah, binding services to 0.0.0.0 on your machine is a recipe for disaster too.
    • hansjorg 10y ago
      Usually you're behind either NAT or a firewall though.
      • falcolas 10y ago
        So long as you have a DNS resolver which respects TTLs, you could be behind anything - they're dynamically changing DNS to point at your localhost. It's not the remote server making the connections, it's your web browser. At which point, it can be exfiltrated, thanks for the DNS tricks which get around CORS.
        • Randgalt 10y ago
          That doesn't make sense. A web browser is just a TCP connection after all. If the port isn't open on the server there's no way to connect to it.
• tapvt 10y ago
  Another good reason to develop w/in a virtualized server on your dev machine?
  • ars 10y ago
    No. If you are going to go to that much effort, better to just spend a little bit of time on security.
    • spdionis 10y ago
      The gain by using VMs and provisioning sofware is not limited to security. There are a lot of good reasons to do that.
      • teilo 10y ago
        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 10y ago
          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 10y ago
  This is a non-issue for those of us who are using Vagrant or similar development VM technologies.
  • michaelmior 10y ago
    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.
    • abricot 10y ago
      The few guides I've seen on setting up virtual servers as devlopment environments have all recommended setting networks as bridged instead of NAT'ed.
      • sbarre 10y ago
        That is the best approach, but a lot of people change it to NAT for testing purposes, like connecting to the VM from mobile devices, and other operating systems, etc.. I know there are ways to do that as well, but this is the easiest and so it's most often the way it's done.
    • spdionis 10y ago
      Usually I access databases in my VMs by ssh tunneling. I have no databse server software on my computer. I thought most people work like that.
      • cmdrfred 10y ago
        Most skilled developers probably. The rest can't figure out why the computer next to theirs can't connect to the test database and after googling a stackoverflow anwser have it listen on 0.0.0.0 forever.
        • jlgaddis 10y ago
          Indeed. Turn off SELinux and disable the firewall too! And just leave the password for the MySQL root user blank since it's too much trouble keeping track of them.
• yarper 10y ago
  similar problem with intellij: https://news.ycombinator.com/item?id=12292148 https://news.ycombinator.com/item?id=12292148
• digitalsushi 10y ago
  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...
  • nathan_f77 10y ago
    WOW. That's just... wow. You might even be to upload new firmware. And you could do all of that inside a hidden iframe with it's own domain, so the parent page DNS never needs to change.
  • jacobsenscott 10y ago
    Pretty sure it still works just fine.
  • richardwhiuk 10y ago
    I wonder there's a solution by requiring a PTR record pointing at each A record which should have Same Origin Policy applied.
    • linkregister 10y ago
      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 10y ago
        You can have multiple PTR records.
  • 10y ago
• deleted 10y ago
  [deleted]
• csense 10y ago
  My takeaway from this is that binding to localhost doesn't give you as much security as you think.
• thirstytho 10y ago
  I always kinda wondered when the other shoe was gonna drop on "why do databases even have passwords"...
  • kuschku 10y ago
    I prefer key-based auth or local user based auth.
• parenthephobia 10y ago
  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 10y ago
    > 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.
• antirez 10y ago
  Recently Redis aliased POST and Host: to QUIT for this reason.
  • powercf 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
          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.
• gschrader 10y ago
  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?
  • Wilya 10y ago
    I know at least one large ISP that does exactly that, so I guess there's not much preventing everyone from doing it.
  • extrapickles 10y ago
    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 10y ago
      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 10y ago
        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
    • marcosdumay 10y ago
      > DNS pinning as suggested would cause havoc with most wifi captive portals It will require extra page reloads. Everybody is used to reload pages for any random reason by now (and you can reload by javascript too). I don't think it would cause much havoc.
• thebeardedone 10y ago
  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).
  • granos 10y ago
    I once requested sample data to work against while triaging/fixing a production issue and was given an unredacted copy of the production database. Lots of customer names/addresses/phone numbers/emails in there. I nuked it from orbit when I was done.
  • sbarre 10y ago
    People work in development with copies of production databases all the time.. They absolutely should not, but I've seen it at companies I've worked at, at clients, and I'll admit I've done it at least a few times myself over the years.
  • giosch 10y ago
    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..
    • thebeardedone 10y ago
      I give you that; I stopped reading it just before he mentioned that point. Thanks for pointing it out, very creative vulnerability.
    • collyw 10y ago
      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.
  • lagadu 10y ago
    You generally work with copies of production databases. Hell I have prod copies of a couple banks' databases on my machine at work which I'm pretty sure violates some data protection law somewhere, despite us being (I assume) legally bound to keep the data secret. AFAIK we're only allowed to have them on our work machines and we encourage clients to sanitize them before handing them over but not many do.
• optimuspaul 10y ago
  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 10y ago
    That's cute. Do you happen to have it on GitHub? Would love to see what comes through.
• knocte 10y ago
  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 10y ago
    How about local IPv6 addresses? I can easily see this being left out due to sheer complexity.
    • knocte 10y ago
      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 10y ago
        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.
    • X-Istence 10y ago
      There is only one local IPv6 address: ::1/128 Unlike IPv4 there is not an entire /8.
      • Ded7xSEoPKYNsDd 10y ago
        IPv6 still has the whole IPv4-mapped range at ::ffff:127.0.0.0/104
  • jfroma 10y ago
    You can run a dnsmasq locally with "--stop-dns-rebind". I have this enabled on my router.
    • solidninja 10y ago
• bahjoite 10y ago
  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.
• tener 10y ago
  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
• andrewstuart2 10y ago
  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
  • an_ko 10y ago
    > Don't let your services listen on (AKA bind to) 0.0.0.0 or 127.0.0.1. How do I do that? Iptables? (Sorry if this is a dumb question.)
    • baby 10y ago
      he means make them listen for 3.3.99.8 for example
      • thewhitetulip 10y ago
        3.0.0.0/8 isn't loopback. Or did I miss something? I thought he said use 127.3.99.7 or something of that sort to avoid using the default localhost
        • andrewstuart2 10y ago
          Right, and furthermore an address in 3.0.0.0/8 isn't likely to be added on any of your interfaces, so attempting to bind/listen on that will just fail. Even if you add it yourself, there's a tiny chance you might start redirecting some traffic you care about (say, facebook) to a local interface where facebook services are definitely not running. :-P Fortunately, the whole 127.0.0.0/8 block is automatically added to the loopback interface (edit: on Linux at least), so you can bind away to your heart's content.
• totony 10y ago
  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.
• jbob2000 10y ago
  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 10y ago
    you joke, but I have to constantly tell our devs "no, you can't have actual prod data to test your queries against"
    • groue 10y ago
      Fine, as long as you can produce replacement data with the desired qualities.
      • talaketu 10y ago
        it's called a test fixture.
        • solidninja 10y ago
          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.
        • flukus 10y ago
          It must be a big test fixture to contain all the data of a production database.
  • jlgaddis 10y ago
    Perhaps you don't have anything confidential on your development machine -- and hopefully you don't! -- but plenty of people do, unfortunately, use real data. :(
• beeperless 10y ago
  If the box doesn't beep any longer - how can I find where I stored my speaker-less server?
• nbadg 10y ago
  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 10y ago
    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 10y ago
      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.
• Mizza 10y ago
  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..
• jkarneges 10y ago
  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-webhooks/ http://blog.fanout.io/2014/01/27/how-to-safely-invoke-webhoo...
• Puts 10y ago
  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.
  • 0x0 10y ago
    Did you just make that up?
  • andrewstuart2 10y ago
    Remember, kids: a firewall is only one layer of your security. Make sure you always implement proper access control and guide users through changing the defaults.
    • deleted 10y ago
      [deleted]
  • pomfpomfpomf3 10y ago
    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.
    • lcmatt 10y ago
      jailbreakme took advantage of a Safari bug. All you needed to do was go to the website, hit a button and wait a few minutes.
      • phpnode 10y ago
        That's a very different attack vector to the one in this post - buffer overflow vs legit service running on open ports unbeknownst to the user
• rhodey_orbits 10y ago
  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-nat-and-firewall-for-ethereum-wallet-control-30c29b73a057#.ew1ir61kg https://medium.com/@rhodey/walking-past-same-origin-policy-n...
  • bouk 10y ago
    Nice one! Not surprising to see cryptocoin implementers make all the classic security mistakes
• corecoder 10y ago
  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
• xenadu02 10y ago
  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 10y ago
    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_DNS https://en.wikipedia.org/wiki/Captive_portal#Redirection_by_...
    • dividuum 10y ago
      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/
  • X-Istence 10y ago
    Certain recursive resolvers, like unbound, have protections you can enable that disallow remote hosts to return private address space. xip.io is one of those services that doesn't work on my home network because I have unbound block all RFC1918 space. # 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
• nneonneo 10y ago
  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=679&redir=1 https://bugs.chromium.org/p/project-zero/issues/detail?id=67...
• f055 10y ago
  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 10y ago
    This kind of thing is exactly why I put up with the hassles of running Little Snitch.
• kevinbowman 10y ago
  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.
• bm98 10y ago
  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-with-Fedora.html http://www.bress.net/blog/archives/195-Firefox-in-a-sandbox-...
  • deleted 10y ago
    [deleted]
  • deleted 10y ago
    [deleted]
  • eeZi 10y ago
    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 10y ago
      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.
• jasonkester 10y ago
  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?
  • hatsix 10y ago
    Yes, When you're generally running one application server, and your other services all use specific ports by default, it's VERY common. In fact, I've not worked at a company (in 12 years of web-app dev) that used different domain names on dev machines until very recently, when it became a requirement of the software itself to have subdomain-per-client code.
  • flukus 10y ago
    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 10y ago
  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.
  • k2xl 10y ago
    I could imagine there may be systems that don't connect to the internet but maybe want to use DNS protocol to coordinate to other systems.
    • EdSharkey 10y ago
      Then for that oddball one-off system, there's a kernel compilation flag that is impossible to find in obfuscated C and assembler that you can set named UNSAFE_ALLOW_REMOTE_DNS_RECORDS_DRAGONS = true where the default setting is always FALSE. Can someone who does kernel or DNS client development in operating systems comment? Am I nuts or is DNS nuts?
  • nneonneo 10y ago
    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 10y ago
      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.
• nothrabannosir 10y ago
  > 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.
  • hueving 10y ago
    >A browser allowing externally loaded scripts to access private ip ranges is not a reasonable decision. So you think a browser should pin IP addresses to DNS names and not follow DNS updates? That's what you're implying.
    • reissbaker 10y ago
      No. What the parent is saying is that: if the script was loaded from an external IP address, it should be blocked from talking to an internal IP address. The browser knows whether it loaded a script from an external IP address, and it knows what the internal IP addresses are, so it can just ban something loaded from elsewhere from talking to ports on your local machine.
  • CWuestefeld 10y ago
    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.
• therealmarv 10y ago
  The PoC website works on my redis even when using Chrome canary 55 which should have removed HTTP 0.9.
• ddalex 10y ago
  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 10y ago
    >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 10y ago
  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?
• RussianCow 10y ago
  This is why I use Vagrant whenever I can. All my services live within a VM and are only accessible via a specific hostname.
• oandrei 10y ago
  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 10y ago
    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 10y ago
      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?
  • manarth 10y ago
    The services discussed - memcached, redis, etc - don't use HTTP. The attack is successful because the protocols follow the robustness principle of 'be liberal in what you accept', and simply ignore the HTTP cruft, but still process the command. For example: POST / HTTP/1.1 << Ignored Host: localhost:6379 << Ignored SET abc 123 << Processed QUIT << Processed
• hrjet 10y ago
  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.
• chx 10y ago
  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.
• rbanffy 10y ago
  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.
• govindpatel 10y ago
  I think that running elastic search on a different port (other than 9200) will go undetected? (just a thought)
• cpcallen 10y ago
  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.
• ex3ndr 10y ago
  Looks like Qubes OS is the only ultimate solution.
• edwinjm 10y ago
  Routers like Fritzbox also protects agains DNS Rebinding: https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-base/publication/show/663_No-DNS-resolution-of-private-IP-addresses/ https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-b...
• snowmaker 10y ago
  Is there any similar attack for data in postgres / mysql local databases?
• amazingman 10y ago
  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.