- Pen Testing Through the Tor Network
Original Post by: John Strand on PaulDotCom
Updated by Qjax – 1/1/2011
Tested on Ubuntu 10.10 Maverick
One of the issues that comes up on regular basis when I talk with a group of penetration testers is how to approach scanning. Some would argue that a penetration test should not include scanning of the target network. The reason given is external attackers would seldom perform these activities as it would give away their position and the target environment may shun the attacking IP address.
On the other hand, there is a group of testers who would argue that we are hired to evaluate risk. As part of this task we need to take a wider view of our customers networks and include scanning with tools such as Nessus and Nmap.
As a good penetration tester, you should consider hiding your IP address after it has been determined that the target utilizes dynamic shunning to block the attackers’ source IP address. Then you can report “good job detecting and blocking our attacks, however, just like a real hacker I simply used another IP”.
What if we had a number of “disposable” IP addresses we could use when we get shunned? Turns out we do. In order to follow the instructions on how to set this up, you will need to have the following software installed on your Ubuntu box:
echo "deb http://deb.torproject.org/torproject.org experimental-lucid main" | sudo tee -a /etc/apt/sources.list sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 886DDD89
sudo apt-get install vidalia privoxy tor
Edit the Privoxy config file:
sudo gedit /etc/privoxy/configAnd paste into file:
forward-socks5 / 127.0.0.1:9050 .Yes, there's a space and a dot at the end.
sudo apt-get install libboost-system1.42
sudo apt-get install proxychains
sudo apt-get install nmap
Warning: About DNS Leakage
The biggest problem with many applications is that they leak DNS requests. That is, although they use Tor to anonymize the traffic, they first send a DNS request untorified in order to get the IP address of the target system. Then they communicate “anonymously” with that target. The problem: any eavesdropper with more than two brain cells can conclude what website you visited, if they see that you sent a DNS request for SecurityStreetKnowledge.com, followed by some “anonymous” Tor traffic. The solution: use Tor together with Privoxy, that prevents DNS leaks. Many non-HTTP-based applications are usually torified using a small tool called
torify, but often this approach has DNS leaking problems.
- $ /usr/bin/torify nmap -P0 -sT -p 80 18.104.22.168(-P0 is to avoid ICMP leak)
- $ /usr/bin/tor-resolve SecurityStreetKnowledge.com(lookup host by IP address)
Firefox: Send DNS via SOCKS5 & Disable Google’s Safebrowsing
For a long time Firefox did not send DNS queries through the SOCKS5 proxy so often people had to use the Privoxy – SOCKS4a proxy server with it. Today it is no longer needed and you can avoid Privoxy (assuming you don’t want to use it for its ad filtering or caching abilities). However the option to send DNS queries through the proxy is not enabled by default in Firefox. To enable it type about:config in the Firefox URL dialog, find the item network.proxy.socks_remote_dns and set it to true, also find browser.safebrowsing.enabled and browser.safebrowsing.malware.enabled and set it to disable. (NOTE: Researcher RSnake has discovered that Google’s anti-malware and anti-phishing features tracks information about a user’s browsing habits)
When you have all of the above software installed we are ready to start scanning through a Tor network. The video below uses Ubuntu 9.04 Jaunty and demonstrates how to configure the tools listed above to scan through Tor:
Lets review the commands and configuration associated with running a portscan through the Tor network:
# proxychains nmap [TargetIP]
At first glance it looks like this is a fast and efficient way to run a scan. Unfortunately, it does not work. For the default SYN Scan you are not scanning through your Tor nodes.
Rather, try this:
# proxychains nmap -sT [TargetIP]
Now you are scanning through the Tor network. Painful, huh? The issue is all of your packets are going through three Tor nodes. Further, these nodes may not be the fastest nodes on the planet. This reduces a full nmap scan to something that will take hours, if not days for a larger network.
In addition, there is the little issue that you are not completely anonymous in your scanning. I have seen a few sites that reference the exact same scan I just ran above and say it is “safe”. Not true! Nmap by default “pings” the remote host as part of its detection of which host are alive and which are not by sending ICMP packets to the target system(s). Lets fix this:
# iptables -A OUTPUT –dest [TargetIP or range] -j DROP
The above iptables rule will cause packets sent to the target environment that are not going through the Tor network to be dropped.
How to Speed up the Tor Network
Want to speed up TOR and make the TOR network and PRIVOXY run faster? First, make sure you have the Vidalia bundled installed. Find the file Tor config file called torrc. With the torrc config file open, copy and paste the following into the file:
# Try for at most NUM seconds when building circuits. If the circuit isn’t
# open in that time, give up on it. (Default: 1 minute.)
# Send a padding cell every N seconds to keep firewalls from closing our
# connections while Tor is not in use.
# Force Tor to consider whether to build a new circuit every NUM seconds.
# How many entry guards should we keep at a time?
With that done, save the file and go back to the Vidalia control panel. Stop and start Tor, this will load the changes you just made to the torrc file. The above changes should help speed up your TOR connections a little.
Speeding up NMAP with TorTunnel (Torproxy)
Lets address the issue of speed with tortunnel by Moxie Marlinspike. Moxie wrote this program so your Tor activity goes directly to an exit node. This bypasses two of the three hops, thereby greatly improving the overall speed of your scans.
To get tortunnel up and running you will need to edit your proxychains.conf file to use socks5. Also note that tortunnel listens on TCP port 5060. Below is the config line I have in my/etc/proxychains.conffile.
socks5 127.0.0.1 5060
Now we have to look up some fast, stable exit nodes to scan through. A complete list can be found at this URL. Next, we can start tortunnel:
# sudo ./torproxy [ExitNodeIP]
I used the following ExitNodeIP (sudo required): # sudo ./torproxy 22.214.171.124
The above command will set up the torproxy connection. Next, re-run your Nmap scan as follows:
#proxychains nmap -P0 -sT -p 80,443,21,23 [targetIPAddress]
Depending on the speed of the ExitNode you choose, it should now be faster. The exit node I used had a bandwidth of 575.13 KB/s. Now my 4 port scan was reduced from 75 secs down to 31 secs. Want to go faster? Try a different ExitNode but remember you MUST choose an ExitNode not just a Tor OnionRouter or your scans will fail. We can also surf to our target IP address through this node. But first we need to set up Privoxy to work through tortunnel. I edited my /etc/privoxy/config file to reflect the port and socks5 changes required to make the scan work. The privoxy config should look like this when you are done:
forward-socks5 / 127.0.0.1:5060 .
Now you can start firefox, enable Tor and you can do your manual checks.
Test with Site: http://www.whatsmyip.org/
Use SSL while Running Web Attacks
Some would argue that scanning through a Tor network has more than a few problems. First, it is not completely anonymous. Someone can sniff your traffic on the exit nodes (Moxie’s excellent tool SSLstrip will allow you to do that). This may have implications in regards to your contract scope and rules of engagement. It is possible that you could launch a successful SQL Injection attack and now some evil-doer running the exit node gets the SQL results, too !
In closing, most Network Intrusion Prevention Systems and Web Application Firewalls do not shun right away. It takes a certain threshold of activity to get them to block you. In any case, dynamic shunning should not stop your testing and shunning is certainly not a 100% effective attack deterrent. Also, the mere threat of a upcoming penetration test can travel around an IT staff like the plague. Eventually, you will run up against Infrastructure Managers or Network Administrators trying to cover their a$$ by setting up a firewall rule to block your authorized test IP. If so, you now have a slick way around it!
Some companies might decide to frequently monitor TOR server Exit Nodes and consider adding them to the firewall blocking policy. [Tor DNS Blacklists HERE] One could argue privacy implications but the question to ask yourself is “should you allow a customer or business partner connection to your website anonymously“?
- Comments: Off Category: Uncategorized