Security concerns/help me understand tor

[Ruben Garcia]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Williams escribió:
> On Nov 7, 2007 8:52 AM, Roger Dingledine <arma at mit.edu> 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-----