Re: Security concerns/help me understand tor

[Roger Dingledine <arma@xxxxxxx>]

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