-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kyle Williams escribió: > On Nov 7, 2007 8:52 AM, Roger Dingledine <[EMAIL PROTECTED]> wrote: > >> On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin Fick wrote: >>> My home router offers an http administration console >>> on port 80 which for obvious security reasons is >>> normally only accessible from the internal facing side >>> of the router. While many of these home routers >>> typically have an internal private IP such as >>> 192.168.1.1 and an external public IP, they sometimes >>> respond to both IPs from the inside and sometimes they >>> even allow access to the administration console on the >>> external IP if it is accessed from the internal side >>> of the router (mine does). This would not normally be >>> a problem, but add a tor exit server to the inside of >>> a home network serviced by such a router and ...you >>> can probably guess where I am going with this. >> Yep. That's why Tor has a notion of exit policies: >> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut >> If you really want to restrict connections to sensitive local resources, >> you should reject connections to them in your exit policy. >> >> The default exit policy rejects internal addresses like 10.*, 192.168.*, >> etc, but as you say there may be other sensitive resources depending on >> your situation. >> >> The other half of the answer is that you shouldn't be relying on network >> location for authorization. You should, for example, use a password. >> >> The third half of the answer is that running a web browser and interacting >> with strange websites creates an excellent opportunity already for dns >> rebinding attacks, cross-site foo attacks, etc. See for example the >> "drive-by pharming" report from some folks I've been working with at IU, >> summarized by Bruce Schneier here: >> http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html >> It's pretty darn scary what bad guys can do to access local resources >> by tricking your browser. >> >> In short, you'd better think harder if you want to both a) run complex >> programs that can act as proxies, such as a web browser and such as Tor, >> and b) do any sort of trust-by-network-location. >> >>> This, of course, should only happen if Alice's tor >>> client chooses Bob's tor server as the exit node. >>> But, if I understand the tor documentation correctly, >>> this would in fact be the preferred way for tor >>> client's to access Bob's website since they should be >>> able to detect that Bob's website and his tor exit >>> server are in fact both (NATed to) the same public >>> IP!!!! >> Yes. If you're visiting Bob's website, Tor can provide end-to-end >> authentication and end-to-end encryption without the need for SSL. >> This is a great potential feature. But you're right, Bob had better not >> allow additional access to sensitive resources for people connecting >> from his Tor relay. >> >>> If I am correct about this possibility, and without >>> arguing the virtues of whether these routers are doing >>> the right thing by providing access to the admin >>> console from the external IP from their inward facing >>> interface, I think that tor relay providers should be >>> strongly warned about this possibility in the tor >>> documentation! I am not sure that there is a good >>> default (out of the box) way to prevent this from >>> happening with tor, but I suspect that if Bob sets an >>> exit policy explicitly rejecting his own IP that he >>> would be safe from this sort of compromise? >> Yes, except in cases where a) he doesn't know the extent to which local >> services trust his IP address, and b) he is on a dynamic IP address. >> Unfortunately, I suspect these are exactly the contexts where it's most >> important for users to understand what's going on, *and* exactly the >> contexts where the users will be most ignorant about the issues. >> >> Where do you suggest we put the warnings, and can you suggest some >> sample phrasings? >> >> We could e.g. add a note to step 9 on >> https://www.torproject.org/docs/tor-doc-relay#after >> but I fear that most users can't (won't) count to 9. >> >> Another option is to assume that most home users will be configuring >> relaying via Vidalia, so we should concentrate on explaining all the >> various issues there. (In fact, Vidalia doesn't currently have a good >> interface for letting people tweak their exit policy by *addresses* >> as well as ports.) >> >> Another thought is that Tor relays already know their public IP address, >> since after all they have to advertise it. Perhaps the default exit >> policy should reject connections to that IP address, unless the operator >> explicitly allows them? See also the "ExitPolicyRejectPrivate" entry >> in the man page. This would be a shame to set up by default, but maybe >> secure-by-default-for-end-users is a trend we should embrace. >> >> And lastly, just to cover all bases: is there any point to this additional >> complexity given that the attacks can already be done just fine via a >> web browser? I guess it depends what assumptions we want to make about >> the users. My instinct would be 'yes'. >> >>> All this leads to another question I have about tor >>> which will probably really show how ignorant I am. >>> What prevents tor exit nodes from spoofing any IP that >>> they want and easily setting up phishing attacks?? >> The same thing that prevents bad people from doing it in airports, >> local coffeeshop wifi, and so on: users should use SSL if they want to >> be sure they're talking to the right destination. >> >> See e.g. point #4 at https://www.torproject.org/download#Warning >> >>> A new excited but confused/concerned tor user, ;) >> Welcome. Hope that helps to explain a bit. >> --Roger >> >> > I mentioned this before to you (Roger) in IRC, but now might be a good time > to bring this up again. > If anyone is concerned about this, and you should be add the following to > your torrc. > > ExitPolicy reject <YOUR_EXTERNAL_IP>:* > > Obviously replacing <YOUR_EXTERNAL_IP> with your real IP address...not your > internal (LAN) IP address. > > I've been scanning the Tor network for a couple of months now looking at > this. > The results have been interesting. Some have port 80 open on there external > IP's already. Some don't. I've focused on those that don't have port 80 > open on there external IP, but may have it open to there internal LAN. > > There is a quick way to test this. If your routers web interface is on > 192.168.1.1 (or whatever it may be), then try it with your routers EXTERNAL > IP. If you find yourself looking at the same web interface as you would see > at 192.168.1.1, then you will have a problem. The reason this happens is > because your router, even though you specify it's external IP, still thinks > it is OK for you to view the web interface because you are coming from the > LAN, not the WAN (ie. Internet). Even if you have disabled remote > administrator on your router, you're still exposed because Tor is coming > from inside your network, not the outside. > > So if someone were to exit from Tor on your PC, going to your external IP > address, they could see your admin web interface to your router which > normally they wouldn't have access to from the Internet. > > Here is a real example (sorry to the owner, hope you're reading this). > http://59.173.180.189.b8b0eaad48c917fe2340556ec6cbc92748aef502.exit/ > is open. > > http://59.173.180.189 > is closed. > > So I am telling that exit node to go to it's own external IP, and poof, you > have the admin web interface to that persons router (which is usually a > login page). > So if anyone has a web interface to their router and is running Tor, you > would be well advised to add that ExitPolicy rule to your torrc and make > sure you changed the default admin/password on your router. > > I don't want to post all the results of my research, for fear that truly > evil Torrorist would go crazy with this. Let's just say that this could be > very, very bad. Trust me, Roger, this isn't something that should be taken > lightly. The moment Tor knows it's own external IP, and is operating as an > exit node, it should (in code) automatically disallow connections to it's > own external IP. Unless someone has a really good reason why you would need > access to your external IP address from inside your LAN. > > BTW, I tried the 'responsible discloser' once already in IRC, remember > Roger? > So I don't feel bad one bit for talking about this with others. > At least I included a temporary solution to the problem. > > > Best Regards, > Your friendly Torrorist >
Perhaps it might be possible to tell tor about the router's nat policy so that if the router is supposed to port forward the external request to <ipA>:<portA>, tor does it itself. That way, the problematic host->tor->tor->your host tor->router->your host web can become host->tor->tor->your host tor->your host web (This requires some changes to the torrc and tor source, so I'd like to add it to the feature request list in case somebody has free time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMu+njJvgg3iy84QRAgbTAJ4yp6chYO351PUNcTmdnWSXFgwOEQCdFVC2 6QozRO8xqGtUUSxRwxh3l4c= =Hs2k -----END PGP SIGNATURE-----
