Bugging a network: Reverse VPN over Tor

network-bugging.md

Network Bug: Reverse VPN over Tor

I would like to build a network bugging device that can be connected to any Ethernet network and grants the attacker access through a reverse VPN.

Since we don't want to go to jail the attacker's VPN server would be a Tor hidden service and the buggin device would perform a reverse connection over Tor. No direct connection to the attacker's IP address will ever be made.

All traffic between the attacker and the device will be encrypted by both Tor and the VPN.

It must be trivial for the attacker to route traffic from nmap, w3af, OpenVAS, metasploit and any other security tools through the VPN tunnel. Extra points if the VPN is Layer 2 and allows the attacker to run ARP-spoofing attacks (ssh layer 2 VPN?)

The device would be built on top of Raspberry Pi or any other "disposable" micro-computer.

Similar projects

• http://hackaday.com/2013/03/24/rogue-pi-a-rpi-pentesting-dropbox/
• http://securityaffairs.co/wordpress/15471/hacking/raspberry-pi-as-physical-backdoor.html
• http://www.tunnelsup.com/raspberry-pi-phoning-home-using-a-reverse-remote-ssh-tunnel

What's missing from the other projects

• Tor hidden service
• Detailed build and usage instructions

Deliverables

• A docker image for the server, which starts the Tor service and VPN server: docker run bug-server

• A docker image which can be run in the rasperry pi: docker run network-bug --server=<hidden-tor-domain>

FAQ

• Why? For fun. Looks like a nice 2-3 day project to learn about Tor hidden services, raspberry pi and reverse VPNs.
• You working for CIA? Nope.

Questions

• Anyone built a similar device/software which uses Tor hidden services?
• Recommendations for VPN software to use?
• Want to help me build and test?

The attacker ip will be in the devise memory, right? It that's true it can be retrieved by someone with access to the device?

The attacker ip will be in the devise memory, right?

No, that's handled by Tor hidden services. Even if the bug is found, there is no way to know who's the attacker. (well, not with network traffic analysis at least)

Shutting some options, this could be invalidated due the nature of TOR hidden services (didnt read in depth)

Options:

A) VPNless If an actual vpn isnt a requirement (like ipsec, etc):

• Use poor man vpn https://github.com/apenwarr/sshuttle
• Use this as reverse, connecting to a TOR hidden service
• Connect to the raspberry using the reverse vpn just created

B) Raspberry acts as a vpn client using OpenVPN

• Use OpenVPN client on Raspberry to connect to a TOR hidden service intermediate
• Use this as a gateway intermediate
• Connect to this service and access the raspberry routed through this gateway

Some issues can appear behind several NATed devices

@leandroreox thanks for the ideas and potential vpn options!

An awesome addition would be this https://www.kickstarter.com/projects/pisupply/pi-poe-switch-hat-power-over-ethernet-for-raspberr

So you don't need USB which can be disabled in some servers

@gutes: That would be awesome!

Hi ,
I am also doing similar project with raspberry pi and i thought of using openvpn...and all we need a vps...and we can connect to our pi from any where...And BOOM we own their network...and can run tests!