[Editor's Note: In this article, Chris Crowley provides some really useful tips for using Tor to anonymize your penetration testing. He provides details on strategy and tactics, along with some helpful configuration settings and scripts. His discussion of Privoxy is especially useful. Thanks, Chris! -Ed.]
Pen testing derives its value from being able to emulate the behavior of real world attackers. We pen testers need to train ourselves to behave like those with malicious intent, but simultaneously maintain appropriate decorum and sensitivity to the operations of the networks we're trying to improve. Malicious attackers have no such restrictions.
This post is to share a method I use for obscuring the source IP address of my computer. Pen testers have two basic reasons for obscuring their source IP address. First, is to connect to malicious (or suspected malicious) resources when we perform research. Second, is to obscure the source of our pen testing recon or attack activities.
In order to study the behaviors of a malicious attacker, or a piece of malware, we might want to connect to an attacker controlled resource. Here's one common scenario for this: Users are being compromised via a social media link that is making the rounds on facebook or a similar social media site. We're not certain how the attacker is successfully compromising the end point system. The initial page has a lot of additional links and javascript. Since we plan to utilize a similar technique for an upcoming pen test, we would like to browse through the experience in the same way that a user would. Of course, we don't want to be identified by the bad guy.
Connecting to known malicious sites from our own IP address is not advisable. Reaching out to the attacker's resource divulges the source IP of our systems, notifying them that we're interested in their host. Further, if we were to send the sort of requests that a compromised system would send, (such as beaconing or some other call back mechanism) this would indicate to the bad guy that the system we're connecting from is compromised. This invites unwanted connections back to us, so it is useful to obfuscate the source IP of the traffic we generate.
Sometimes malware only runs when it can reach out to its command and control (c2) channel. We could spend a lot of time setting up our lab to provide the c2 with the malware expects, but it would be much faster to let the malware run so it can connect to the real c2. But, we don't want the residual attention that would come from the attacker attempting to utilize this compromised host for some subsequent activity. We want the information. We want to profile the attack methodology. We want to see the action of the attack. But, we want that connection to be severed as soon as we've gathered the information we're after.
Attackers have disposable systems. They don't identify themselves by IP address. During a pen test (with appropriate approval from the customer, of course) using an IP address that is unexpected or unattributable is desirable and is an effective emulation of a real world attacker. Here are a few scenarios that come to mind for this. First is website recon. A malicious party probably isn't going to use the same IP address for the initial web app scanning as the ultimate attacks on the web app. Second scenario is service scanning. If you've looked at firewall logs for an ISP facing firewall lately, you know that there is incessant scanning for most ports on your network. A few ports are the highest priority, but the scans come from all over. Attackers use throw away IP addresses to perform the initial identification of targets, then use other IP addresses to actually perform the exploitation. The real bad guy steals sensitive information. That's the ultimate goal of his efforts. Is he going to provide his own name and address on that return package? Not if he is smart! He'll use a series of systems to make it difficult to provide attribution. Fourth, is something that will be more common for pen testers over the coming years. Pen testers will more frequently be tasked to identify the risk associated with applications deployed on mobile devices. Mobile or legacy (yes, I just called laptops and workstations legacy compute devices) application assessments can be performed using anonymized network connectivity.
The process outlined below can be performed in a number of different ways. I'll outline one method that will work, and you can adjust as needed, to suit your needs.
There's been a lot of attention in the news about government agencies taking advantage of flaws in implementations of Tor (for example see https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable and https://www.mozilla.org/security/announce/2013/mfsa2013-53.html). Basically, for our purposes Tor is good enough. If you're looking for an article on how to evade nation states monitoring Tor traffic, I'm afraid you're going to have to look elsewhere.
Here are the basic steps:
1. Install and Set up Privoxy.
2. Install and Set up Tor.
3. Configure Privoxy to chain to Tor.
4. Get the traffic to go into the proxy.
Although I use this set up on a linux system, you can adjust the instructions to whatever OS you want to use. It will work for Windows or OS X, as well. Privoxy and Tor are going to provide a transport that facilitates communication from an "exit node" from the tor network that is different than your IP address. If someone had access to observe your network traffic enter the tor network, it is possible that party could watch where you communicated to. But, that's not our concern in the scenarios I'm addressing here. What we're concerned about is the termination of the communication from our system so it does not know the source of the IP traffic.
1) Install and Set up Privoxy
According to the Privoxy website (http://www.privoxy.org/), "Privoxy is a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk. Privoxy has a flexible configuration and can be customized to suit individual needs and tastes. It has application for both stand-alone systems and multi-user networks."
It is very straightforward to install. Use the directions provided at http://www.privoxy.org/user-manual/index.html for your operating system. Or in my case, I used the built-in repos on Fedora to install it:
yum -y install privoxy
You could choose to run polipo, or another HTTP proxy instead.
2) Install and Set up Tor
According to the Tor project page (https://www.torproject.org/), "Tor was originally designed, implemented, and deployed as a third-generation onion routing project of the U.S. Naval Research Laboratory. It was originally developed with the U.S. Navy in mind, for the primary purpose of protecting government communications. Today, it is used every day for a wide variety of purposes by normal people, the military, journalists, law enforcement officers, activists, and many others."
If you're looking for background on how tor works, read this page:
https://www.torproject.org/about/overview.html.en#thesolution
Once your curiosity is sated, or patience exhausted, download and install the program per the instructions here:
https://www.torproject.org/docs/documentation.html.en
Now read the warnings about the limitations of Tor:
https://www.torproject.org/download/download-easy.html.en#warning
This isn't necessary, but if you're more than a bit paranoid about this, or suspect that the connection isn't working because your ISP blocks connections to the tor network, look at establishing connections to a tor bridge first:
https://www.torproject.org/docs/bridges.html.en
3) Configure Privoxy to chain to Tor
DNS is the primary reason I choose to utilize Privoxy in conjunction with Tor. If I want to manage the DNS requests associated with the hosts I'm attempting to connect to, so that the information about the source of the requests isn't provided to the target, I can approach this from a different perspective, and utilize an alternate, public, DNS server (such as 8.8.8.8). But privoxy also gives us some added capability for blocking types of requests. It also attempts to prohibit requests that might divulge our IP address or location.
The configuration is relatively straightforward. In Linux, you simply configure the chained proxy setting, and privoxy will redirect the DNS and HTTP requests it needs to perform into the Tor network.
This is the privoxy config line for forwarding to tor:
forward-socks5 / 127.0.0.1:9050 .
Here's my whole privoxy config file settings, without the comments. This is basically plain, except listening on all interfaces and enabling the tor forwarding.
$ grep -v "^#" /etc/privoxy/config confdir /etc/privoxy logdir /var/log/privoxy actionsfile match-all.action # Actions that are applied to all sites and maybe overruled later on. actionsfile default.action # Main actions file actionsfile user.action # User customizations filterfile default.filter logfile logfile listen-address :8123 toggle 1 enable-remote-toggle 0 enable-remote-http-toggle 0 enable-edit-actions 0 enforce-blocks 0 buffer-limit 4096 forward-socks5 / 127.0.0.1:9050 . forwarded-connect-retries 0 accept-intercepted-requests 0 allow-cgi-request-crunching 0 split-large-forms 0 keep-alive-timeout 5 socket-timeout 300 handle-as-empty-doc-returns-ok
4) Get the traffic to go into the proxy
a) Configure a command line environment variable (http_proxy, https_proxy, ftp_proxy), and command line tools will use the proxy.f
For example, wget: wget is a command line web browser. It is able to make requests, recursively and across domains too, for pages that you specify. For example:
$ export http_proxy=127.0.0.1:8123 $ wget -nc -nd http://www.willhackforsushi.com/subscriptions.xml
In this case, I want to get Josh's subscription list for RSS feeds, but I don't want him to realize it is me. I do this via a cron job every minute or so from most of my computers ( * * * * * wget -nc -nd http://www.willhackforsushi.com/subscriptions.xml ) just in case something changes on that page.
Now, wget is a well behaved webbot. It will first request the robots.txt file from the website that you direct it to, and abide by any specifications within that file. Also, wget has the -nc option that I used in the previous example. That means "no-clobber" or don't overwrite any files I've already downloaded. In fact, it downloads it and doesn't keep it, which is the same net affect. How does wget know which files have already been downloaded? It looks at the filesystem, of course. So, "touch robots.txt; wget -nc -nd http://www.willhackforsushi.com/subscriptions.xml" will tell wget not to retain the robots.txt from willhackforsushi.com, but to use the one that's already on the file system that is blank. I'm just saying.
b) Start your android emulator with the -http-proxy option.
Having a fully functional android emulator capable of running the actual apps that you need to assess as part of a software assessment pen test engagement is a nice shortcut. When you launch the android emulator using the emulator command, one of the many options is "-http-proxy ipaddr:port".
Make sure you have the privoxy running first. If the android emulator can't access the proxy port, it will disregard the setting. It says so in a warning, but that command line window is overwhelmed with the graphical depiction of the emulator.
For example:
emulator -avd IceCreamSandwich -partition-size 256 -qemu -http-proxy 127.0.0.1:8123
Now, all traffic originating from the emulator will be automatically redirected into my privoxy->tor arrangement.
One critically important note for this: have your privoxy listener up and running prior to launching the emulator. If the emulator is unable to connect to the proxy port at launch, it ignores the proxy option, and the emulator will use the system's native stack for communication, potentially exposing the source IP address.
c) Configure an application (or device) to use the proxy.
The http_proxy (et al) environment variable is very useful for command line based tools. Most tools will honor that variable. But, graphical tools likely have their own proxy settings and don't look at the BASH environment variables. So, you can use the configuration of that application to connect into the proxy. Chrome for example:
- Open chrome, enter "chrome://settings/" in the URL bar
- Select "Show advanced settings?"
- Under the Network section, click the "Change proxy settings..." button
- Configure the HTTP and HTTPS sections as manual proxies to 127.0.0.1:8123
(There are analogous settings in all major web browsers.)
d) Snarf the traffic using iptables rules.
If your app doesn't honor the command line proxy environment variables, and you don't have a way to change the configuration within the application itself, you can potentially manipulate the network traffic via the iptables utility within linux to forcibly rewrite the traffic using NAT rules.
Here's a BASH script that I use for things like this.
#!/bin/bash
## CHECK FOR ROOT
wai=`whoami`
if [[ "$wai" != "root" ]]
then
echo "
You need to be uid 0. Re-run as:
sudo $0
"
exit
fi
## SET SYSTEM TO PREROUTING IP PACKETS
echo "1" > /proc/sys/net/ipv4/ip_forward
## HTTP TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8123
## HTTPS TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-port 8123
## CHECK FOR BURP
pgrep -fl privoxy 2>&1 > /dev/null || echo "Are you sure privoxy is running?\nOr maybe you intend to use something else I didn't check for."
After I think I am set up, I test first to be sure that it is working. A simple "wget http://www.google.com" will suffice. I run "tcpdump -Xnnv -i eth0 port 80 or port 443 or port 53" to monitor because there should be no traffic on those ports if my proxy config is working properly.
Note that my request (which actually originates from a bunker somewhere beneath the frozen mid-west) redirects to google.fr because of the exit node in use with tor.
Now go do your evil thing, my penetration testing friend! Make sure you have permission to assess whatever it is you're assessing. For example, you might want to inspect the interoperability of a prospective piece of software with your home network.
And now that you have some degree of anonymity (and appropriate permission to perform your assessment), you might: spider or scan a target web server; download malware you're interested in learning about; or run the application you're assessing for a client and not divulge the source of the inspection.
-Chris Crowley
chris@montance.com