"Practical onion hacking: finding the real address of Tor clients"

[George Shaffer]

On Thu, 2006-10-26 at 15:05, Fabian Keil wrote:
> George Shaffer <George.Shaffer at comcast.net> wrote:
> > On Mon, 2006-10-23 at 08:22, Fabian Keil wrote:
> > > George Shaffer <George.Shaffer at comcast.net> wrote:
> > > 
> > > > . . . many web surfers, even
> > > > knowledgeable ones, like the "rich" experience and are willing to
> > > > sacrifice security and privacy for it.
> > > 
> > > And they constantly get what they deserve. . .
> > 
> > If a member of your family is sick with a contagious disease, and you
> > tend to them, do you "deserve" to get the disease? It might be smarter
> > to stay away and call a doctor, but perhaps you get infected before you
> > knew a doctor was needed, or while waiting for the doctor, or can't
> > afford a doctor.
> 
> I fail to see the similarities between willingly sacrificing
> security and privacy for '"rich" experience' and caring about
> ones family.

It may have been a poor analogy (I was thinking of computer viruses
which suggested disease) but my objection is to the use of the word
"deserve."  Let's try a different one: people who leave their house
doors unlocked don't deserve to be robbed or raped and people who leave
their cars unlocked don't deserve to have their cars stolen. In each
case the poor security increases the risk of the undesired results, but
does not make these results likely.

Failure to take good browser and system security precautions does not
result in "constant" adverse results. I know two computer professionals,
both of whom use Windows and have had high speed Internet connections
for the past five years. The only precaution either takes is they are
behind a NAT router (and may run an antivirus program). They have
everything enabled in their IE browsers. Neither has ever experienced
any disruptive experience, thought they may well have some adware or
innocuous virus on their system.

What is so often forgotten about malicious web attacks is that nearly
all web operators have a large investment in their sites and malicious
software hurts them as much or more as victim client computers. To go to
a malicious site you need to encounter a site whose security has been
compromised, be tricked into going to a site, be the victim of poisoned
DNS, receive an email with a macro based Outlook virus that uses IE
functionality, or deliberately browse fringe web sites. All can and do
have adverse consequences, but are not a common part of most surfer's
experiences. 

People who deserve to have bad things happen to them are criminals who
are justly convicted.
  
> > > Anyone interested whether or not your IP address is currently in use
> > > only needs to do a port scan. 
> > 
> > Are you sure? By "stealth" I mean . . .
> 
> If the target IP address is unused, the scanner gets an error
> message send from the router located one hop before the target.
> If the scanner doesn't get this error message, it's safe to
> assume that the target system is running.

By unused to you mean unassigned or will simply turned off result in
such a message? I don't have enough computers to test this and know of
no legal way to do so. I guess I have to take your word, though I've
never heard this before. Perhaps someone could provide a URL that
describes this.

> > > And if you can't trust your firewall
> > > enough to work in cases where someone knows that your IP address is
> > > in use, you should get a firewall that actually works anyway.
> > 
> > One might conclude, if one assumed these couple smart alec remarks
> > represented your entire knowledge of firewalls, that you don't seem to
> > know that once you open a port in a firewall to a server, e.g., Tor and
> > port 80, that the firewall cannot protect that server.
> 
> The packet filter can still protect all other ports and
> increase the chances that the packets arriving at the Tor
> running server are valid. The Tor server's host system can make sure
> that a compromised Tor server doesn't cause too much damage.
> As a OpenBSD user you will be aware of systrace,
> other systems have similar tools.

While I'm generally familiar with most of your points, and the one about
a firewall only allowing valid packets is a good one, in the context of
this discussion, your final sentence grates. Perhaps this comes from the
way German translates to English, but it would be much easier to read
"If you are not familiar with, then you should look up systrace" rather
than saying "you will be aware of." If I ever knew it I've completely
forgotten it. Looking at man, it does appear that it would be useful for
controlling "developmental" software on a very secure OpenBSD system.

The last time I checked, my recollection is that there are more than 600
commands on a minimal OpenBSD install, i.e., without misc, games or any
of the X window components. Very few people will know all of them. The
man pages are mostly quite good if you know the name of a command (or
can find it with "-k") but there is no overview how-to documentation
with OpenBSD that ties things together into logical task groups. My
phrasing is a helpful suggestion whether or not I know systrace, where
yours becomes an insult if I do not, by implying that I ought to know
it.

> > Now that I've already told you something about my system, if you think
> > you are smart or knowledgeable enough to get past my firewall, I'll be
> > glad to give you permission to try.
> 
> I didn't claim that.

No but you did say "get a firewall that actually works anyway." I
thought perhaps if you thought my firewall didn't work, that you might
think I had an easy system to crack.

> > (Recently . . . I scanned the Tor exit node from grc.com, and both 80 and
> > 443 showed as open, where the others showed as stealth. This means Tor
> > is responding, . . Other explanations? 
> 
> Depending on your scan it probably wasn't Tor, but the underlying
> OS which answered your scan. Of course this doesn't change the
> fact that Tor doesn't operate invisible, but this shouldn't
> be a major problem.

You are right about the OS. Opening port 80 when no web or other server
is running still shows the port as open. Still, I don't care about
"major" problems, I don't want any additional problems, even what you
might think are minor ones.

> > All this from someone doing random scans for an open port 80. Before the
> > scan they probably would have not known the IP was in use. Now they have
> > much of what they need to try to attack the system.
> 
> So they should see that you don't run a system with known vulnerabilities
> and the best they can do is to run a DoS attack to clog your Internet
> connection.

I'm not saying I expect any attack to succeed. The point I've tried to
make more than once, that you seem to disagree with to the point that
you basically ignore it, is that I do not want to do anything to attract
any random or anonymous attack. I think I have an unusually high degree
of security relative to what I have to protect, but I don't wish to find
out that I'm wrong. My OpenBSD firewall is not current, but I don't
believe there are any kernel or firewall bugs relevant to my
configuration. My Linux desktop is up-to-date with patches.

Not all bugs are found first by the good guys. Occasionally bugs are not
revealed until systems are successfully compromised; with proprietary
systems this is normally the case. Even when the good guys find the bugs
first, which is most often the case with open source systems, there is
some lag between discovery, which usually but not always means the bug
has become public knowledge, and the time it takes for the developers to
find, fix, and make available patches. Then depending on your update
practices you may introduce additional delays.

The best that you can possibly be is fully up-to-date with your system's
patch level. If you are, you will be much better off than most
computers, including many commercial servers. This does not mean your
system has no exploitable vulnerabilities, but hopefully any crackers
with the skill to find and exploit such vulnerabilities will focus on
systems where there will be some real reward and not on individual home
systems.

> As mentioned before, if you think the risks for your local network are
> too high, you can always get a dedicated server for Tor.

And as I said before, if I had the funds to run a dedicated server, I'd
contribute them directly to tor.eff.org, where I think they would do
more good. I'd never go the expense and time of running a dedicated Tor
server. Second, I doubt that less than 1% of the existing Tor servers
are dedicated Tor servers run by individuals. I expect that nearly all
Tor servers fall into one of two groups: 1) organizations that have
excess bandwidth and server capacity, or an older unused PC that could
be set up as a dedicated server, and believe that Tor is simply worth
supporting, or might provide value to the organization. One of the great
things about all the open source systems is that the life of a PC can be
extended by several years as a dedicated server, for modest demand
applications. 2) Individuals with good bandwidth connections, who feel a
desire or obligation to support Tor with a server, and can do so by
simply changing one or more configuration options. Here their interest
in Tor overrides any security concerns they may have, or they may not be
aware of any security issues, or consider them insignificant.

I've spent far more time with Tor than I ever expected to when I
started. If I considered only cost benefit, I'd conclude my best course
would be to remove or disable Tor and forget it. I've used it very
little after I got it to work, because it is simply too slow most of the
time (though sometimes it's quite reasonable). I've seen someone on this
list say this is a minor issue; I'd strongly disagree. I'd expect for
the average non technical user it is the single most important Tor
issue, after installation and setup issues.

I'm sticking with it because it is intellectually one of the most
interesting software projects I've encountered in a long time. In theory
at least it is a very elegant solution to an important network need. I
think with the direction governments and businesses are going, the need
for Tor or a comparable product will only grow. I don't think the single
server commercial services are an adequate answer. So I really hope Tor
succeeds, but I expect to stay mostly on the sidelines as a watcher and
occasionally a user.

Fabian, please make this the last time you suggest that I run a Tor
server whether locally or hosted. This is the third time you've
suggested that I run a server and the third time I said I'm not going
to.

> > Once a single malicious attacker decides to focus on
> > Tor, he can get the source code to help him, but the Tor community does
> > not have the resources to find a quick solution, the way the large open
> > source communities do.
> 
> Even if this was true, this should only affect your decision to
> use Tor at all and isn't specific to running Tor as a server.
> 
> And looking at larger open source projects I fail to see the
> correlation between community size and security. Just have a look
> at how long it takes for the average remote exploitable flaw in
> PHP or Firefox  to get fixed.

Coderman raised the last point two days before you did, and after I
reconsidered what I wrote, I agreed with him 10 hours before you posted
this. How about reading the current posts before responding?

I disagree with the previous point. The ONLY attacks the firewall does
NOT protect the client from are man in the middle attacks, where the
attacker is able to alter the Tor packets so that they remain valid IP
packets and the packet "state" is maintained, i.e., that the firewall
sees the altered packet as a response to a previously sent request. In
contrast, unless the firewall rules are regularly manually updated to
restrict incoming packets to all valid Tor nodes, the ONLY attacks the
firewall CAN protect a Tor server from are malformed TCP packets.
Firewalls generally don't, and none that I've used, assure valid packets
for specific applications or protocols. This may be true sometime in the
future, but to-date, to the best of my knowledge, only specialized
proxies provide application level packet integrity checking. 

In other words, only computers on the Tor packets path, or with access
to the cable over which the packets are being passed, can launch a very
specific type of attack on a Tor client behind one or more stateful
firewalls. Without a large amount of ongoing administrative work, any
computer on the Internet can exploit any vulnerability which may be
found in the Tor software when it runs in server mode and the
firewall(s) allow access to it.

George Shaffer