4 ms·

I still can't quite put my finger on the security risk for others, can you help explain what makes it one? Here's the only scenario I can think of: Say you ar

by jonpugh 10y ago

I still can't quite put my finger on the security risk for others, can you help explain what makes it one? Here's the only scenario I can think of: Say you are a web developer and you use mybusiness.local.computer for developing your client's website. You use it every day, you are used to loading up the URL and seeing your website. One day I, owner of local.computer turn the dark side. I decide that I want to attack you, this one person who I know uses mybusiness.local.computer, and change mybusiness.local.computer to redirect to my nefarious server. When I do that, when you come to work, you load up mybusiness.local.computer and expect to see the site you've been working on. Because I know my victim, I know exactly what website to spoof, so I have my spoof up and running on my nefarious server. Then, when the victim goes to visit mybusiness.local.computer, thinking they are visiting a copy of their website, it's actually being served from my server. Hopefully, you then input some information, like their username and password, which I then capture in my spoof website. This is the only way I can imagine using this domain against someone. It involves quite a few assumptions: - The one in control of DNS is the attacker. - The attacker has one specific victim in mind, because they can only spoof one website. - The attacker already knows what site the victim is expecting to load at a .local.computer domain. This requires personal knowledge of the victim's site because the DNS for .local.computer goes straight to 127.0.0.1. Requests are not proxied or logged. (Ok, after writing this, I realize I could change the local.computer to go through my servers then redirect the user to 127.0.0.1 enabling me to at least learn what subdomains are being requested. Still, I have no idea what that site is supposed to be.) - The attacker is able to spoof that website well enough that the victim (a developer of the website) is able to be fooled into giving up information. Is there another way this could be abused? I seriously would like to know. Thanks!

smt88 10y ago
As the owner of local.computer, you are in a position to intercept anything a developer is sending to her server via HTTP request. This could be username/password, yes. You also then know the public IP address and public domain of a development server, which may allow you to access the server and learn secrets, steal stack traces, etc. It's a small security risk, but it's a non-zero risk with zero benefit. Just use fake, never-to-be-public domains. There's no downside. If you need to interact with something like Twilio (which you never need to do while developing), you can wait until you're ready to push to staging.
- jonpugh 10y ago
  The benefit is not zero, it is having unlimited domains pointed to local without having to ever mess with DNS or /etc/hosts.
  - smt88 10y ago
    You can do this using dnsmasq[1] on Linux or OS X and Acrylic DNS on Windows[2]. I guess if someone wanted to do more work, they could also just register their own random domain and point it to 127.0.0.1. We're also talking about maybe 30 seconds of work per project to edit a hosts file. Someone who knows their command line will be able to do it in 5 seconds. Multiplied by 20 projects, that's still only 2 to 10 minutes of work every year. I personally use localhost for everything and just work on one thing at a time. I never mess with hosts. 1. https://davejamesmiller.com/blog/installing-dnsmasq-wildcard-local-domains-debian https://davejamesmiller.com/blog/installing-dnsmasq-wildcard... 2. http://mayakron.altervista.org/wikibase/show.php?id=AcrylicHome http://mayakron.altervista.org/wikibase/show.php?id=AcrylicH...
    - jonpugh 10y ago
      I build systems (devshop/aegir) that create and destroy websites on the fly. If I'm working on a feature related to that process I could create and delete a dozen or more arbitrary domains in a day. I also know plenty of web development teams that are less technical and could deal without manual hosts file tweaking on a daily basis. I also use multiple computers. With this domain, I never have setup Dnsmasq, never have to edit a hosts file, never have to edit DNS. Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will.
      - MaulingMonkey 10y ago
        > Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will. I just make my CLI tools update my hosts file. *.local.computer all points to 127.0.0.1 - when I want localhost subdomains, I want unique IPs too (so e.g. I could bind different httpds to 127.0.0.1:80 and 127.0.0.2:80, or other evil thing I've thought up)
smt88 10y ago
Actually, let me put it another way. Public DNS records are intended to allow other people to easily locate and network with your server. You never want people to do that with a development server.
- jonpugh 10y ago
  Sure, but this record goes to 127.0.0.1. How would I get the IP of your development server other than 127.0.0.1? When you request local.computer, it's not sending me your IP, it's requesting one. Right? Public DNS for a private IP doesn't get me anything I don't already know, right?
  - smt88 10y ago
    I'm not a security expert, so my answers are not going to be exhaustive and may be incorrect. The bottom line is that trusting someone else with the DNS records for a development server is pointless and comes with some risk. Use it yourself if you want, but there's no reason other people should trust their security to a stranger who may have poor security practices (insecure password for registrar's website, for example). I mentioned that public DNS is for networking only to point out that there's a mismatch here between the problem and the solution, but there are still attack vectors here. One vector would be your ability to intercept anything that's being sent to the development server by a browser or IDE, which could include debug information, API keys, fragments of the stack, or even chunks of source code. It depends on the tools the developer is using. > How would I get the IP of your development server other than 127.0.0.1? The client IP. Many default configurations of local servers will use or bridge port 80, which means external requests will be routed to the local development server. The client IP, as well as permissive firewall settings, would allow an attacker to access the development server. > When you request local.computer, it's not sending me your IP, it's requesting one. With a very low TTL, you could still get the client IP pretty reliably. This is how DNS rebinding attacks work.
    - jonpugh 10y ago
      I never suggested using the domain for anything but web browser requests, not sure why anyone would need to use it to connect in any other way. So as long as users don't use it for connecting to their local server are they safe? Don't most people connect to local servers via Vagrant or docker shared volumes, anyway? Not sure why anyone would use it for accessing their local machine when there are existing methods for that. Thanks for the details.
MaulingMonkey 10y ago
> I still can't quite put my finger on the security risk for others, can you help explain what makes it one? FWIW, here's the way I see this actually going down: 1) Within a decade or two, you forget or are unavailable to renew. 2) Domain squatter takes over and spams ads. 3) It's 2036 and we still have 0-days and browser exploits.

by jonpugh 10y ago

smt88 10y ago

As the owner of local.computer, you are in a position to intercept anything a developer is sending to her server via HTTP request. This could be username/password, yes. You also then know the public IP address and public domain of a development server, which may allow you to access the server and learn secrets, steal stack traces, etc. It's a small security risk, but it's a non-zero risk with zero benefit. Just use fake, never-to-be-public domains. There's no downside. If you need to interact with something like Twilio (which you never need to do while developing), you can wait until you're ready to push to staging.

jonpugh 10y ago
The benefit is not zero, it is having unlimited domains pointed to local without having to ever mess with DNS or /etc/hosts.
- smt88 10y ago
  You can do this using dnsmasq[1] on Linux or OS X and Acrylic DNS on Windows[2]. I guess if someone wanted to do more work, they could also just register their own random domain and point it to 127.0.0.1. We're also talking about maybe 30 seconds of work per project to edit a hosts file. Someone who knows their command line will be able to do it in 5 seconds. Multiplied by 20 projects, that's still only 2 to 10 minutes of work every year. I personally use localhost for everything and just work on one thing at a time. I never mess with hosts. 1. https://davejamesmiller.com/blog/installing-dnsmasq-wildcard-local-domains-debian https://davejamesmiller.com/blog/installing-dnsmasq-wildcard... 2. http://mayakron.altervista.org/wikibase/show.php?id=AcrylicHome http://mayakron.altervista.org/wikibase/show.php?id=AcrylicH...
  - jonpugh 10y ago
    I build systems (devshop/aegir) that create and destroy websites on the fly. If I'm working on a feature related to that process I could create and delete a dozen or more arbitrary domains in a day. I also know plenty of web development teams that are less technical and could deal without manual hosts file tweaking on a daily basis. I also use multiple computers. With this domain, I never have setup Dnsmasq, never have to edit a hosts file, never have to edit DNS. Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will.
    - MaulingMonkey 10y ago
      > Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will. I just make my CLI tools update my hosts file. *.local.computer all points to 127.0.0.1 - when I want localhost subdomains, I want unique IPs too (so e.g. I could bind different httpds to 127.0.0.1:80 and 127.0.0.2:80, or other evil thing I've thought up)

smt88 10y ago

Actually, let me put it another way. Public DNS records are intended to allow other people to easily locate and network with your server. You never want people to do that with a development server.

jonpugh 10y ago
Sure, but this record goes to 127.0.0.1. How would I get the IP of your development server other than 127.0.0.1? When you request local.computer, it's not sending me your IP, it's requesting one. Right? Public DNS for a private IP doesn't get me anything I don't already know, right?
- smt88 10y ago
  I'm not a security expert, so my answers are not going to be exhaustive and may be incorrect. The bottom line is that trusting someone else with the DNS records for a development server is pointless and comes with some risk. Use it yourself if you want, but there's no reason other people should trust their security to a stranger who may have poor security practices (insecure password for registrar's website, for example). I mentioned that public DNS is for networking only to point out that there's a mismatch here between the problem and the solution, but there are still attack vectors here. One vector would be your ability to intercept anything that's being sent to the development server by a browser or IDE, which could include debug information, API keys, fragments of the stack, or even chunks of source code. It depends on the tools the developer is using. > How would I get the IP of your development server other than 127.0.0.1? The client IP. Many default configurations of local servers will use or bridge port 80, which means external requests will be routed to the local development server. The client IP, as well as permissive firewall settings, would allow an attacker to access the development server. > When you request local.computer, it's not sending me your IP, it's requesting one. With a very low TTL, you could still get the client IP pretty reliably. This is how DNS rebinding attacks work.
  - jonpugh 10y ago
    I never suggested using the domain for anything but web browser requests, not sure why anyone would need to use it to connect in any other way. So as long as users don't use it for connecting to their local server are they safe? Don't most people connect to local servers via Vagrant or docker shared volumes, anyway? Not sure why anyone would use it for accessing their local machine when there are existing methods for that. Thanks for the details.

MaulingMonkey 10y ago

> I still can't quite put my finger on the security risk for others, can you help explain what makes it one? FWIW, here's the way I see this actually going down: 1) Within a decade or two, you forget or are unavailable to renew. 2) Domain squatter takes over and spams ads. 3) It's 2036 and we still have 0-days and browser exploits.