[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Security concerns/help me understand tor





On Nov 7, 2007 8:52 AM, Roger Dingledine <arma@xxxxxxx> 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