|
If you think that ensuring one’s Internet privacy is the only mean of the Tor
software then you are wrong twice. First off, its suballocated network can be
used for different purposes. And secondly, it’s not as safe as it’s painted.
Alas.
This wonderful tool for ensuring the anonymity and security of Internet data
is good for many reasons. Any sniffer just stays out of work (including Internet
router’s built-in ones) because all traffic passes through a chain of nodes only
in encrypted form. It’s extremely difficult or (in case of giving implicit
confidence to what developers say) even impossible to trace the data source due
to the ever-changing chains of special intermediary units through which the data
is transmitted. Who hasn’t tried using Tor for a trivial IP change? At first
glance, the speed is the only one drawback. Each node within the chain makes a
serious delay, both in response time and in bandwidth. The result is an
anonymous connection. Anonymous and dial-up :). But that dial-up connection is
not the main problem of Tor active users. There’s a thing they should worry
about much stronger - any data can be intercepted and, hell, that can be done
easily!
Where all that nodes come from?
In order to let the application traffic go through Tor it’ll be enough to
specify the local SOCKS-server address in the application’s proxy settings. If
this option isn’t available you can use some socks manage software (e.g. Sockcap),
but at the same time you should remember that socks allow TCP traffic only.
However, most users are much more interested in ready-to-use software builds (so-called
Bundles) that include Tor itself, as well as reconfigured Firefox browser and
Pidgin IM-client. You just install it and that’s it! Incidentally, there’s a
Torbutton Firefox plugin. You just click the button and all the traffic starts a
secure transmitting through a chain of intermediate nodes. What are these nodes,
and how, in principle, is Tor designed? Let’s try to get it.
So-called nodes (between which the encrypted data is transferred) underlie
the suballocated nodes system. Three servers which form a temporary chain are
normally used for connection. Each server is chosen randomly. It knows only from
what segment the data was received and whom it intends to. Moreover, the chain
is constantly changing. Tracking the full packets path (including their sender)
is not possible even in the case of data interception from one server. The
package is encrypted with three keys before sending and sequentially they are:
the key for the third node, then for the second and, eventually, for the first
one. When the first node receives a packet, it decrypts the "upper" layer of
encryption and finds out where the packet should be sent next. The second and
the third servers do likewise.
So what’s the catch?
Thus, the path is constantly changing, the data transfers through
intermediate nodes in the form of some shitty code, i.e. in the encrypted form.
The question is “where’s the catch”? It has to be somewhere. You know, no matter
how seriously the data is protected, and no matter how sophisticated and tangled
the route is, all the data still needs to be deciphered somewhere at the exit.
After all, only this way it can be delivered to a destination server. This
operation comes at the last node of the chain - the so-called Exit Node. If you
set up a sniffer on such a node, then the data will remain nothing but getting
straight into your logs :).
You may think that the system excludes that circumstances and setting up the
Tor as the exit node is impossible? No kidding! The entire system is built on a
large number of involved enthusiasts who provide their home computers as nodes,
including exit ones. A few lines of code in the config file will serve as a
ticket to their ranks.
Hurray for the Exit Node!
Well, let’s do it. For this experiment you’ll need any *NIX distribution.
It’s absolutely unimportant whether it’ll be a Backtrack launched on a flash
drive, or some Ubuntu launched on a virtual machine. Next thing you’ll need is
the latest version of Tor (at the time of publication it’s v. 0.2.1.19). GUI
lovers can also download and install the Vidalia but we're going to work in the
console mode. So now you download the packages, unpack ‘em and install. I think
there should be no problems at this stage.
Tor requires the clock to be set correctly. Otherwise you should synchronize
your clock with public time servers. Looking ahead, I have to say that it’s
better to create a separate user before starting the Tor (You can do this by
running “adduser”). I’ve created a “toruser” user by: “uid = 111 (toruser) gid =
10 (wheel) groups = 0 (wheel), 10 (wheel)”. Now you need to create a
configuration file. Tor uses the .tor folder in its user's home directory (/
home/toruser) to store the data. You should create a .tor folder and a “torrc”
file in it. Then open it in some text editor.
Now we are interested in several parameters:
ControlPort - at this port Tor will receive the connections to control
a Tor-server (i.e. you can remotely connect to the Tor configuration. This
option is important for those who use the desktop environments such as Vidalia
or Tork). Set it in 9051.
DirPort – through this port Tor will receive the data from the
directories server. Set in 9030.
ControlPort 9051
DirPort 9030
ExitPolicy - determines what kind of traffic will Tor receive and then
forward. It has the following format: "ExitPolicy Accept | reject address: port".
By default, the policy is as follows:
reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:563
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*
It means that all the traffic destined to the above ports will be cut and the
rest of it will be allowed. Basically, it can be left default. Well, that's for
you to choose. I used the following:
ExitPolicy accept *:80, accept *:443, accept *:110, accept *:143,
accept *:993, accept *:995, reject *:*
HashedControlPassword - hash of the password to access and configure
the Tor-server (hackers won’t be able to reconfigure your server) is created
with the command: tor - hash-password.
Nickname - the name of your server.
ORPort - the port, which waits for connections from other nodes.
SocksListenAddress - the address that all applications running through
SOCKS will connect to. Format: SocksListenAddress IP [: PORT]. Set the IP to
127.0.0.1, and leave the default port (9050). You’ll need this if you’ll want to
use Tor in tandem with Privoxy or some other proxy software.
HashedControlPassword
16:91495A0B7CBC41C76073E1EC00A5CF1510D41462884391CCB24BF489F1
Log notice stdout – put message in to console
Nickname HelloXakep
ORPort 9001
SocksListenAddress 127.0.0.1
Save the changes and close the file. Now you’re ready to launch. Open the
console, login and run the Tor as “trouser”, passing the path to the config file
as a parameter:
$ tor -f /home/toruser/.tor/torrc
And look at the error messages. Once the server will be able to connect to
the network, it will check the availability of its ports from the outside. It
may take up to 20 minutes. It logs messages like "Self-testing indicates your
ORPort is reachable from the outside. Excellent". If not, it means that the
server is not reachable from the outside and you should double-check the
firewall.
As soon as the server determines the ports availability, it will upload its
descriptor on the directory server (node database). This will allow customers to
know the address, ports, keys and other information about our server. To make
sure that server is on the list you can go to
http://moria.seul.org:9032/tor/status/authority and check your server’s
nickname. However, it’s not updated immediately. Sometimes it may take some time
to have that information refreshed in the database.
So we have our server in the list. Let's look at the line below HelloHacker.
You can see the “s Exit Fast Running V2Dir Valid” phrase. Exit - means your
computer is an Exit Node!
Let’s sniff it
Thus, the output node is set upped, launched and added to the database. No
doubt someone must take advantage of it in the very near future. Well, I can
only run my favorite Wireshark sniffer, select the Interface which will be
sniffing the external network and enable the packets capturing. And then just
wait. In most cases full soon packages start crumbling to the logs :))
Then you can disable the capture and analyze the resulting dump (e.g. search
the packets for a “pass” strings). As you know, HTTP-protocol transmits
everything without any encryption, so it can swallow something interesting (I
caught login details for 2 tracker account’s in 40 minutes of sniffer work).
That’s not so bad, admit it. But the most delicious things just past through us
(actually they stay with us, but they’re encrypted). But even in this case there
is a way out. In the May edition of TOOLS we’ve already mentioned about
“sslstrip” - a tool that intercepts the SSL-connections data. Moxie Marlinspike
unreleased the new version of this remarkable tool at the BlackHat2009
conference that was held in August (by the way, I advise you to read his report.
We added all the BlackHat materials on the September DVD). Download the sslstrip
tool from the author’s website and try it (see the May issue for details on how
to use the sslstrip).
Run the next thing:
$ Python sslstrip.py-a-l 8080-w today.log
Since you are the last node then all the traffic from the previous node is
transmitted in encrypted form. Then it’s decrypted on our server and after it’s
sent to the final destination. So, you need to get the outgoing http traffic
through the sslstrip. To do this, let’s add an iptables rule:
$ iptables -t nat -I OUTPUT -p tcp -m owner -uid-owner 111 --dport 80 -j
DNAT --to-destination 127.0.0.1:8080
Where the “111” is a “trouser” id. In other words, you’ll forward all
outgoing HTTP-traffic of the “trouser” to go through “sslstrip”. Now
everything’s completely automated and the only thing you can do is wait and
check the logs :).
Anonymous scanning
You’ve learned about how to intercept someone’s logins and passwords. But
there’s much more interesting task. Have you ever been in such situation when
you are in some internal network and there’s some server that interests you in
some way but you can’t scan it because that’ll immediately attract the IDS and
respectively admin’s attention? Or here's another option: imagine you’re
scanning the remote host but it recognizes the scan and blocks your IP. What an
adversity. But there’s a way out! The Tor will help us again because it can be
used as a scan intermediary. After all, who said that this system can be used
only for anonymous surfing? :)
What’s the advantage of such kind of scan? In our first case, scanning the
server will take place from Internet but not from the local network, and in
second one - even if you’re blocked you can always let the traffic go through
another Tor-server (the wheal is that there’s lots of ‘em). So, for our
experiments you’ll need the following stuff:
- Tor (which is already installed and configured)
- Privoxy (www.privoxy.org)
- proxychains (proxychains.sourceforge.net)
- tortunnel (www.thoughtcrime.org/software/tortunnel)
- Nmap (nmap.org)
Install everything except of tortunnel tool. Config the proxychains to let
the traffic go through Tor just by taking off the commenting signs from the
following line:
Socks4 127.0.0.1 9050
Now you save the configuration and launch the scan (the address is
92.241.175.142 - IP of xakep.ru server): "proxychains nmap-PN
92.241.175.142". At first glance this way of scan seems like the most
quick and efficient one, but it’s not. The packages won’t go through Tor while
the default SYN-scanning is used. If you’d scan the server that way (directly),
you would probably be nicked down. Now let's see what other options are offered
in Nmap: "SCAN TECHNIQUES: -sS/sT/sA/sW/sM: TCP SYN / Connect () / ACK / Window
/ Maimon scans".
Now set the “complete connection” as the Nmap scanning mode: "proxychains
nmap -sT -PN 92.241.175.142"
Congratulations! Now you're scanning through the Tor-network. To say true
it’s pretty slow because our packages go through the three nodes before reaching
the target server and these nodes may not be the fastest on the planet. In the
case of scanning an entire subnet, the process can drag on for hours or even
days. Moreover, such scanning is still not anonymous, cause the Nmap sends icmp
requests (coming directly from our computer) to check the remote machine
availability before scanning. You’ll have to use the firewall for cutting all
outbound traffic going to that computer and by-passing the Tor or simply specify
the -PN option for Nmap (it wouldn’t check the remote machine availability then):
"iptables-A OUTPUT-dest 92.241.175.142-j DROP" . As for me, I use
the -PN option everywhere because the xakep.ru server’s firewall cuts the
ICMP_traffic. So I manually specify that the host is alive.
Increasing the speed
So what about speed? Having speed that low won’t let us do the things we want
to. The torrtunnel tool will help us in this case. It serves to forward the
traffic directly through the exit node, bypassing the previous two one’s. So in
this case, the scanning speed depends only on the last node you’ll choose. This
tool requires some additional boost libraries. You can download the latest
version of the libraries from
www.boost.org. Unpack ‘em, enter the folder and execute like this:
$ bootstrap.sh --libdir=/usr/lib --includedir=/usr/include
$ ./bjam --prefix=/usr
$ ./bjam install
As a result you’ll have all your header files in /us /include/boost and
libraries in /usr/lib folder. Now you should manually create a symbolic link to
the libboost_system.so.1.40.0 library:
$ ln -s /usr/lib/libboost_system.so.1.40.0 /usr/lib/libboost_system-mt.so
After that you can compile and install the tortunnel tool. Launch the
torproxy. It’ll give the “torproxy <torExitNodeHost>” message. Now you need to
choose an appropriate exit node. To do this, go here
http://128.31.0.34:9031/tor/status/all or here
http://moria.seul.org:9032/tor/status/authority and find the node with a
following description: "Exit, Fast, Stable, Valid ". All reliable and fast nodes
are indicated that way and that’s the one’s we need. Then copy the IP address
and execute: ". / Torproxy [ExitNodeIP]".
Now, to make things work you’ll need to configure the proxychains tool to use
socks5 in order. Thus, let’s comment the “Socks4 127.0.0.1 9050”
line in /etc/proxychains.conf and add the “socks5 127.0.0.1 5060”
(5060 - the port, which will be listened by tortunnel).
Then you can run the Nmap:
@ proxychains nmap-sT-p 80,443,21,23 92.241.175.142
As you see, the scanning speed has increased (if not - try another node). You
can even scan your own computer. Let’s teach Privoxy to work through tortunnel
tool to top it. You’ll weaken the anonymity (one intermediate node instead of
three), but you’ll get the faster surfing instead. Go to the configuration file
and add the line:
forward-socks5 / 127.0.0.1:5060
Now open the Fox and configure the http-proxy on 127.0.0.1:8118. Then go to
http://torcheck.xenobite.eu/index.php and check whether you’re surfing
through Tor. If everything’s OK you’ll get the "Your IP is identified to be a
Tor-EXIT." notification. That's all, now you can make even a manual audit of the
remote system.
Tor Scanner
Well, you’ve forced the Tor to work for you. You can scan through Tor and
intercept other people's passwords. But what if you’ll need to use Tor to, for
example, log in to your Gmail account? How not to get in the sslstrip's logs?
There’s the way out! There’s a torscanner utility in the tortunnel package.
Torscanner is designed to search for Exit Node's which use the sslstrip. It
works as follows: we give the utility some URL that contains the https link (s)
and it connects directly to all Exit Node's and requests the specified page. The
data is displayed in the console, but you can redirect the output to a file for
some further study. Here’s the launch syntax: "torscanner destinationHost
destinationPort request".
E.g.
$ torscanner www.google.ru 80 / > 1.txt
If you’ll find the HTTPS to HTTP substitution in the server responses after
analyzing the 1.txt file, it’ll definitely mean that the server has the sslstrip
utility launched.
Torscanner scans all exit nodes, so it can take a long time. But I think you’ll
be able to modify the program so that it checks only a certain range or a
specific server and uses it as an exit node (Tor can be configured to use some
certain exit nodes).
Wait for a spoof :-)
There’s only one conclusion - be careful using Tor. Yes, the system provides
a nice level of anonymity, but it cannot protect your data from interception.
And even after you’ve checked the last node is not running sslstrip, still no
one can guarantee that the packets aren’t sniffed ‘n dumped. On the other hand
Tor shouldn’t be considered only as an anonymous surfing tool. I think a couple
of showed examples had confirmed it.
Being an Exit Node server is a tough guy’s job
You have to understand that users are out on limb while being an Exit
Node. After all, your IP will be spotted during some hacking, etc. In the
process of writing the article some people have tried to make the
SQL-injection attacks through my server, twice. So keep your eyes open
because you can easily get in trouble with some law enforcement authorities
or with your provider as a minimum. Here are some examples:
In 2006, Germany's intelligence services have carried out the seizure of
six computers running as the Tor network nodes, having based on the fact
that they were illegally used to access the child pornography.
In 2007 National Swedish police arrested a well-known expert on computer
security Dehn Egerstada on charges of unauthorized access to computer
information. 22-year Deranged Security employee had published the passwords
to e-mails of embassies’, NGOs, commercial firms and government agencies of
different countries on his work site. According to him, as an experiment, he
created 5 Exit Tor-servers and just intercepted the unencrypted traffic.
In 2007 German police arrested the Alexander Janssen as his Tor computer
server was used by some unknown person to send a false report on terror
attack. Despite the fact that soon Mr. Janssen was released, he decided not
to use his computer as a Tor exit node anymore.
Tor’s hidden services
Tor has another interesting feature – the hidden services. Tor users can
provide various services such as web access or server instant messaging
without opening their true location. Hidden services are available through
special pseudo-top-level domains called .onion. The Tor network knows these
domains and anonymously sends the information to the hidden services. Then
hidden service processes it through the standard software, which is
configured to listen only for non-public (closed to external access)
interfaces. This functionality could be used to accommodate the site without
worrying about the censorship. Nobody will be able to determine the site
owner and the owner of the site will not be able to find out who used the
site.
Specialized OS
WWW
Tor + Vidalia + Proxomitron + Freecap –
http://wsnow.net/my_soft/41-narushaya-zaprety.html
OperaTor - Opera + Tor + Polipo –
http://archetwist.com/en/opera/operator
Portable Tor is a portable Tor package. It doesn’t require installation on
your computer –
http://portabletor.sourceforge.net
Torbutton - Firefox Extension. Adds the on and off Tor button. Also provides
enhanced privacy protection and browser isolation –http://addons.mozilla.org/ru/firefox/addon/2275
Vuze – a client for file sharing BitTorrent network with a built-in Tor
support –
http://azureus.sourceforge.net
A good manual to configure Tor -
www.torproject.org/docs/tor-doc-relay.html.ru
Full list of supported options --
www.torproject.org/tor-manual.html
Configuring the Hidden Services -
www.torproject.org/docs/tor-hidden-service.html.ru
WARNING
This article is not an instruction or a call to some action. It is intended
only to show that even those programs that are created for some good purposes
can be used for some evil one’s either.
|
