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.
I would like to propose that a good attacker uses everything in their means to achieve their goals. In some situations they would focus on the social engineering aspect and in others they would use more traditional scanning techniques.
A good tester should be versed in both.
Valsmith and his crew gave an excellent presentation on client side attacks at Defcon 17 this year. There was a great section in their presentation on using Tor networks for scanning. I wanted to elaborate on scanning with Tor and find ways to do it faster and better as a professional tester. The reason is many environments utilize dynamic shunning to block attack IP addresses. Now for a picture of a bunny with a pancake on his head to demonstrate just how effective this defense is:
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:
When you have all of the above software installed we are ready to start scanning through a Tor network. The video below uses Ubuntu 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 126.96.36.199
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 188.8.131.52
Now you are scanning through the TorTor 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.
But 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 it sends 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.
Lets address the issue of speed with torrtunnel by Moxie. Moxie is quickly becoming my favorite security researcher. Moxie wrote this program so your Tor activity goes directly to an exit node. This bypasses two of the three hops, greatly improving the overall speed of your scans. It is still not great, but it is bearable.
Ti 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.conf file.
socks5 127.0.0.1 5060
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:
# ./torproxy [ExitNodeIP]
The above command will set up the torproxy connection. Next, re-run your Nmap scan as follows:
# proxychains nmap -sT -p 80,443,21,23 184.108.40.206
It should now be faster. If it is still slow, try a different exit node. We can also surf to our target IP addresses 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 like 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.
There are a couple of areas during a test where this works well. First, port scanning. Pick your ports wisely and scan. I see very little risk to the customer doing this. The second area where this rocks, is manual web checks over ssl. Just please verify that your session is ssl before you start launching attacks.
Some would argue that scanning through a Tor network has more then 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. Just spend a few seconds thinking of a SQL injection attack where some third party gets the data too.
In closing, I just want to say that shunning should not stop your testing. Further, shunning is not a 100% effective attack deterrent. Most IPS systems do not shun right away. It takes a certain threshold of scanning activity to get them to block you. But, they will block you. If they do, simply move on down the line to another node.
Remember, pancakes on ones head are not an effective deterrent.
-strandjs (Fr. John)