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

[George Shaffer]

Fabian, there is no point in any further response to most of what you
are saying. We seem to be going in circles.

On Mon, 2006-10-23 at 08:22, Fabian Keil wrote:
> George Shaffer <George.Shaffer at comcast.net> wrote:
> 
> > > The risks of JavaScript, Flash and friends are mentioned
> > > several times in the docs.
> > 
> > Haven't the authors of the report that you seem to object to so much
> > made a dramatic demonstration of this. The products you mention are used
> > by many content providers, and 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.

> It was already a well known and documented fact that Tor exit
> nodes can alter unencrypted traffic. And even if this wasn't documented,
> just thinking about it would make it clear. . .

That would depend on how well you understood how Tor works, and more
generally your understanding of computers, which to most people are
pretty much a mystery.

> > There is another reason for not running a Tor server even if my ISP
> > allowed it. I have a dedicated "stealth" firewall (protecting a personal
> > desktop with little of intrinsic value). There is no chance I would poke
> > holes in its configuration. . .
> 
> 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 a firewall that drops packets on
blocked ports (and ICMP) and returns no packets, regardless of whether
probing packets are properly formed or deliberately misformed. A scanner
(at least theoretically) gets exactly the same response as from a
computer that is turned off. This only works if every single port and
ICMP are blocked (stealth). A single open, or closed port, will reveal
unequivocally to a port scan that there is a working computer at the
target IP address. No sane attacker will devote additional resources to
an IP that appears to be off or disconnected, unless they have
independent reason to believe a working computer is actually at the
probed IP.

> 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.

It's not that I don't trust my firewall, I just don't want to invite
random attacks, because a broad probe of many port 80s, happens to find
an open one on my machine. I hope you're not suggesting Packet Filter on
OpenBSD does not work.

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. Just contact me out of this list,
and I'll work out terms (e.g., no deliberate destruction, one month
limit). If you succeed, I'll admit it publicly in this list. 

I would not dream of making such a challenge if I were running a Tor
node, because that would mean at least one open port, to a piece of
software running in the background, of which I have no internal
understanding. A minimal Tor node configuration would require allowing
inbound traffic on port 80. I do know such a port shows as open on an
exit node (and likely all active nodes). 

(Recently when I again got unexpected content as was discussed in a
recent thread, 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, even though the incoming packet is not a Tor packet.
Other explanations? I did not write down the IP, and have no knowledge
of the OS or firewall in use on that exit node.) 

Either way though, packets are now sent from the Tor node system that
can be fingerprinted to determine the OS, version, and some other facts
about the OS running the Tor node and possibly firewall. A port scanner
will quickly show other ports as blocked. The attacker can't immediately
know if the open service is on the firewall machine or being passed to a
machine behind the firewall. A careful packet analysis may reveal this.
>From this the attacker can look to see if there are any known bugs for
the probable firewall running on that system, and if so possibly launch
a focused attack. Alternatively, the attacker can focus directly on the
open port 80.

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.

There is also the Tor directory which I had not thought about
previously. This also announces the presence of tor nodes when before
these nodes were private, and depending on their local security, more or
less, well hidden. 

Does Tor have any buffer overflows that can be exploited? I surely don't
know. And no, I am not running Tor as root, but that still does not mean
someone could not make a nuisance of themselves. Perhaps Tor can be
crashed remotely. If so, an attacker might arbitrarily crash Tor every
one to six hours. This could be automated. Every so often I'd have to
troubleshoot to figure out why I could not connect with Tor. Any circuit
passing through the node would be disrupted.

I could put Tor on an individual client rather than the firewall. Then I
have to set up Tor on each client I might want to use. With port 80 (and
maybe 443) open on the firewall, then malicious traffic can go right to
my client computer. Of course I have to also open these ports on the
local computer firewall as well, if it's to serve as a Tor node. All
this is avoided if I don't run a server, but only a client. Then both
firewalls can allow only outgoing packets with stateful inspection, and
block all incoming traffic not in response to an outgoing request.

The simple fact is that anyplace you have no public (accessible by the
outside) services, your security must be weakened, if you add a Tor node
anywhere in your local computing environment. This is especially true
since Tor is developmental software. It's not like core pieces of the
open source OSs, or big projects like Perl or Apache, where many pairs
of knowledgeable eyes are likely to have reviewed the code over years.
TOR as a server runs on hundreds, rather than tens of thousands to
millions of computers, so it is not likely to have (yet) attracted much
malicious scrutiny. 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.

I happen to know a little about computers, security, and firewalls. If
you doubt it see http://geodsoft.com/ This has not been actively
maintained recently, but the Hardening OpenBSD and Password areas still
get a good bit of traffic. The firewall section in Hardening OpenBSD
should answer if I understand firewalls, and how to configure them. When
I say "know a little" I mean that literally. There are thousands of
books in print (just in English) on computers, many highly technical.
Those who can honestly claim to know a lot about computers are rare.

Fabian, there is something unpleasant in your attitude: those who make
different choices than you, are not as smart or knowledgeable, or simply
write something you think you can ridicule ("get what they deserve",
"just thinking about it would make it clear", "if you can't trust your
firewall", "get a firewall that actually works") all suffer your scorn.
Just because you apparently know something about Tor, and maybe
networking and cryptography, is no excuse to put down those who may know
less.

George Shaffer