I am new to tor network and I am not pentester. But I though it is good to know a bit about these tools because they can be useful on some situations when you are reversing malware and you want to gather information about CnCs, for example. But as I said, I’m not an expert on this, my apologies if you find something wrong in this blog post. Any suggestion, advice or correction will be welcome.
Setting Up The Environment
It is possible to set up different environments that would let us to work through tor network.
You can configure your current machine with tor and proxychains. For example for nmap, you would call it through proxychains in this way: proxychains nmap -Pn -sT -p <ports> <target>. In this way you won’t need additional hardware. Here it is a nice tutorial about this.
Other option is to configure a tor proxy on additional machine and configure a wifi ap that will redirect all the traffic from the ap to the tor network. I liked this option because, probably, it is harder to make a mistake and reveal your ip address if you are using multiple tools for gathering information (in this way you know all the tcp traffic from your machine connected to the wifi ap is going to be routed through tor).
The wifi ap can be created with hostapd linux application. Here it is a good article explaining how to make this configuration. You can find a lot of articles on internet about this.
Having the wifi ap configured, you only need to install tor (sudo apt-get install tor) and redirect the traffic from wlan0 to tor port (sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp –syn -j REDIRECT –to-ports 9040). Here it is a great article about configuring raspberry pi in this way.
Finally I configured a raspberry pi with a wifi ap redirected to tor, and additionally I installed proxychains into raspberry pi for performing port scans, because I found a problem while using nmap through the wifi ap, as I will explain later.
Port Scanning Through Wifi AP Redirected To TOR Network
When I started to use nmap with this configuration, I noticed it was not working as expected. When I scanned a remote ip with -sT option (don’t forget to specify the -Pn option too, or a icmp packet will be sent and ip address will be revealed), all the ports of the remote machine was being reported as open ports.
I scanned an open port and a closed port, capturing with wireshark, and it captured the same packets:
Scanning closed port 6666 through tor, option -sT:
Scanning closed port 6666 through tor, option -sT:
Scanning open port 80 through TOR, option -sT:
When I use the wifi ap, the full tcp connection is always established in spite of the fact the target port is closed, and, after the connection is established, if the remote server (the target)’s port is closed, a fin/ack is sent to us to close the established tcp connection. But the connection is always established, and for this reason, nmap is reporting all the ports open.
With .onion servers it happened exactly the same behavior:
As we can see in the previous capture, with the open port 80, all it is as expected, the connection is performed and remote server answers bad request. With closed port 6666, if we only see nc results, it seems we were not able to connect to port 6666, but really the tcp connection was established, and it was closed later with fin/ack:
I wrote a tiny script for nmap. It reports open ports only that ports answering any data. The script connects to the target machine:port, it sends some data, and wait for a response with data. However, it is not a very good solution, because we are loosing services that don’t any data.
Tcp-waitdata-scan.nse:
Tcp-waitdata-scan.nse:
An example:local nmap = require "nmap" local stdnse = require "stdnse" portrule = function(host, port) return true end action = function (host, port) stdnse.debug1("start") local status = false local soc = nmap.new_socket("tcp", "inet") stdnse.debug1("new_socket executed") if soc then stdnse.debug1("socket open") soc:set_timeout(5000) status, error = soc:connect(host, port, "tcp") if status then stdnse.debug1("connected, sending data") soc:send("...data...\r\n\r\n\n\n\0\0") stdnse.sleep(5) status, data = soc:receive() if status then stdnse.debug1("data received") nmap.set_port_state (host, port, "open") else nmap.set_port_state (host, port, "closed") end return status end end return false end
Portscanning Through Proxychains
Nmap seems not work as expected through the wifi ap redirected to tor, so I tried with nmap + proxychains. It is quite slow, but it worked fine for me:
Other Tools
However, other tools for gathering information like burpsuite, nikto, dirbuster, etc… it could be harder to redirect all the traffic with proxychains. If you are connected to the wifi ap and you know all the tcp traffic of the wifi ap is redirected to tor, it’s more comfortable to work and to keep anonymity.
Anonymity Test
I wanted to be sure all the packets to any tcp port was being routed through tor. I configured an environment where I could capture traffic before and after tor network:
Machine 1 —– Wireshark 1 —–> TOR Network —— Wireshark 2 ——> Machine 2
Machine 1 is connected to my wifi ap that redirect all the traffic through tor. On the other hand, my router is redirecting all the traffic from wan interface to machine 2.
From machine 1 I launched a portscan to my public ip through tor with -sT option, to capture tcp/syn packets at wireshark 2:
Wireshark 2 (receiver):
Source ip addresses of the tcp/syn packets are tor exit nodes. My ip is not revealed. In addition, we can see some packets are coming from an exit node and other packets are coming from other exit node, because each connection is router through different tor network paths.
References
- Configure Proxychains + Tortunnel: https://www.aldeid.com/wiki/Tor/Usage/Nmap-scan-through-tor
- Configure Raspberry Pi as AP: http://itsacleanmachine.blogspot.com.es/2013/02/wifi-access-point-with-raspberry-pi.html
- Configure Raspberry Pi AP to TOR proxy: https://learn.adafruit.com/onion-pi/preparation
No comments:
Post a Comment