<br><br><div class="gmail_quote">On Nov 7, 2007 8:52 AM, Roger Dingledine <<a href="mailto:arma@mit.edu">arma@mit.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin Fick wrote:<br>> My home router offers an http administration console<br>> on port 80 which for obvious security reasons is<br>> normally only accessible from the internal facing side
<br>> of the router. While many of these home routers<br>> typically have an internal private IP such as<br>> <a href="http://192.168.1.1" target="_blank">192.168.1.1</a> and an external public IP, they sometimes
<br>> respond to both IPs from the inside and sometimes they<br>> even allow access to the administration console on the<br>> external IP if it is accessed from the internal side<br>> of the router (mine does). This would not normally be
<br>> a problem, but add a tor exit server to the inside of<br>> a home network serviced by such a router and ...you<br>> can probably guess where I am going with this.<br><br></div>Yep. That's why Tor has a notion of exit policies:
<br><a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut" target="_blank">http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut</a><br>If you really want to restrict connections to sensitive local resources,
<br>you should reject connections to them in your exit policy.<br><br>The default exit policy rejects internal addresses like 10.*, 192.168.*,<br>etc, but as you say there may be other sensitive resources depending on<br>
your situation.<br><br>The other half of the answer is that you shouldn't be relying on network<br>location for authorization. You should, for example, use a password.<br><br>The third half of the answer is that running a web browser and interacting
<br>with strange websites creates an excellent opportunity already for dns<br>rebinding attacks, cross-site foo attacks, etc. See for example the<br>"drive-by pharming" report from some folks I've been working with at IU,
<br>summarized by Bruce Schneier here:<br><a href="http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html" target="_blank">http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html</a><br>It's pretty darn scary what bad guys can do to access local resources
<br>by tricking your browser.<br><br>In short, you'd better think harder if you want to both a) run complex<br>programs that can act as proxies, such as a web browser and such as Tor,<br>and b) do any sort of trust-by-network-location.
<br><div class="Ih2E3d"><br>> This, of course, should only happen if Alice's tor<br>> client chooses Bob's tor server as the exit node.<br>> But, if I understand the tor documentation correctly,<br>> this would in fact be the preferred way for tor
<br>> client's to access Bob's website since they should be<br>> able to detect that Bob's website and his tor exit<br>> server are in fact both (NATed to) the same public<br>> IP!!!!<br><br></div>
Yes. If you're visiting Bob's website, Tor can provide end-to-end<br>authentication and end-to-end encryption without the need for SSL.<br>This is a great potential feature. But you're right, Bob had better not
<br>allow additional access to sensitive resources for people connecting<br>from his Tor relay.<br><div class="Ih2E3d"><br>> If I am correct about this possibility, and without<br>> arguing the virtues of whether these routers are doing
<br>> the right thing by providing access to the admin<br>> console from the external IP from their inward facing<br>> interface, I think that tor relay providers should be<br>> strongly warned about this possibility in the tor
<br>> documentation! I am not sure that there is a good<br>> default (out of the box) way to prevent this from<br>> happening with tor, but I suspect that if Bob sets an<br>> exit policy explicitly rejecting his own IP that he
<br>> would be safe from this sort of compromise?<br><br></div>Yes, except in cases where a) he doesn't know the extent to which local<br>services trust his IP address, and b) he is on a dynamic IP address.<br>Unfortunately, I suspect these are exactly the contexts where it's most
<br>important for users to understand what's going on, *and* exactly the<br>contexts where the users will be most ignorant about the issues.<br><br>Where do you suggest we put the warnings, and can you suggest some<br>
sample phrasings?<br><br>We could e.g. add a note to step 9 on<br><a href="https://www.torproject.org/docs/tor-doc-relay#after" target="_blank">https://www.torproject.org/docs/tor-doc-relay#after</a><br>but I fear that most users can't (won't) count to 9.
<br><br>Another option is to assume that most home users will be configuring<br>relaying via Vidalia, so we should concentrate on explaining all the<br>various issues there. (In fact, Vidalia doesn't currently have a good
<br>interface for letting people tweak their exit policy by *addresses*<br>as well as ports.)<br><br>Another thought is that Tor relays already know their public IP address,<br>since after all they have to advertise it. Perhaps the default exit
<br>policy should reject connections to that IP address, unless the operator<br>explicitly allows them? See also the "ExitPolicyRejectPrivate" entry<br>in the man page. This would be a shame to set up by default, but maybe
<br>secure-by-default-for-end-users is a trend we should embrace.<br><br>And lastly, just to cover all bases: is there any point to this additional<br>complexity given that the attacks can already be done just fine via a<br>
web browser? I guess it depends what assumptions we want to make about<br>the users. My instinct would be 'yes'.<br><div class="Ih2E3d"><br>> All this leads to another question I have about tor<br>> which will probably really show how ignorant I am.
<br>> What prevents tor exit nodes from spoofing any IP that<br>> they want and easily setting up phishing attacks??<br><br></div>The same thing that prevents bad people from doing it in airports,<br>local coffeeshop wifi, and so on: users should use SSL if they want to
<br>be sure they're talking to the right destination.<br><br>See e.g. point #4 at <a href="https://www.torproject.org/download#Warning" target="_blank">https://www.torproject.org/download#Warning</a><br><div class="Ih2E3d">
<br>> A new excited but confused/concerned tor user, ;)<br><br></div>Welcome. Hope that helps to explain a bit.<br><font color="#888888">--Roger<br><br></font></blockquote></div><br>I mentioned this before to you (Roger) in IRC, but now might be a good time to bring this up again.
<br>
If anyone is concerned about this, and you should be add the following to your torrc.<br>
<br>
ExitPolicy reject <YOUR_EXTERNAL_IP>:*<br>
<br>
Obviously replacing <YOUR_EXTERNAL_IP> with your real IP address...not your internal (LAN) IP address.<br>
<br>
I've been scanning the Tor network for a couple of months now looking at this.<br>
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.<br>
<br>
There is a quick way to test this. If your routers web interface is on
<a href="http://192.168.1.1">192.168.1.1</a> (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 <a href="http://192.168.1.1">192.168.1.1</a>, 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.<br>
<br>
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.<br>
<br>
Here is a real example (sorry to the owner, hope you're reading this).<br>
<a href="http://59.173.180.189.b8b0eaad48c917fe2340556ec6cbc92748aef502.exit/">http://59.173.180.189.b8b0eaad48c917fe2340556ec6cbc92748aef502.exit/</a><br>
is open.<br>
<br>
<a href="http://59.173.180.189">http://59.173.180.189</a><br>
is closed.<br>
<br>
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). <br>
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.<br>
<br>
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.<br>
<br>
BTW, I tried the 'responsible discloser' once already in IRC, remember Roger? <br>
So I don't feel bad one bit for talking about this with
others. <br>
At least I included a temporary solution to the problem. <br>
<br>
<br>
Best Regards,<br>Your friendly Torrorist<br>