Skip to content

sshuttle.md

Latest commit

 

History

History
82 lines (56 loc) · 2.56 KB

sshuttle.md

File metadata and controls

82 lines (56 loc) · 2.56 KB
Raw

SShuttle

Limitations

  • sshuttle only works on Linux targets.
  • It also requires access to the compromised server via SSH, and Python also needs to be installed on the server.
  • That said, with SSH access, it could theoretically be possible to upload a static copy of Python and work with that.
sudo apt install sshuttle
  • The base command for connecting to a server with sshuttle is as follows:
sshuttle -r username@address subnet
  • For example, in our fictional 172.16.0.x network with a compromised server at 172.16.0.5, the command may look something like this:
sshuttle -r user@172.16.0.5 172.16.0.0/24
  • We would then be asked for the user's password, and the proxy would be established.
  • The tool will then just sit passively in the background and forward relevant traffic into the target network.
  • Rather than specifying subnets, we could also use the -N option which attempts to determine them automatically based on the compromised server's own routing table:
sshuttle -r username@address -N
  • If this has worked, you should see the following line:
c : Connected to server.

Key Authentication

  • So, when using key-based authentication, the final command looks something like this:
sshuttle -r user@address --ssh-cmd "ssh -i KEYFILE" SUBNET

sshuttle -r user@172.16.0.5 --ssh-cmd "ssh -i private_key" 172.16.0.0/24

Errors

  • When using sshuttle, you may encounter an error that looks like this:
client: Connected.
client_loop: send disconnect: Broken pipe
client: fatal: server died with error code 255
  • This can occur when the compromised machine you're connecting to is part of the subnet you're attempting to gain access to.
  • For instance, if we were connecting to 172.16.0.5 and trying to forward 172.16.0.0/24, then we would be including the compromised server inside the newly forwarded subnet, thus disrupting the connection and causing the tool to die.
  • To get around this, we tell sshuttle to exclude the compromised server from the subnet range using the -x switch.
  • To use our earlier example:
sshuttle -r user@172.16.0.5 172.16.0.0/24 -x 172.16.0.5

Notes

  • Auto cleans up iptables rules on Ctrl+C — no manual cleanup needed

Connect to Target Network Through Pivot Host

sudo sshuttle -r megan@10.11.1.31 10.1.1.0/24 -v

sudo sshuttle -r hacker@10.1.1.1 10.3.3.0/24 -v -e 'ssh -oHostKeyAlgorithms=+ssh-rsa'

sudo sshuttle -r j0hn@10.11.1.252:22000 10.2.2.0/24 -v -e 'ssh -oKexAlgorithms=+diffie-hellman-group-exchange-sha1 -oHostKeyAlgorithms=+ssh-rsa'