In my previous post “Pentestit Lab v10 - SSH Token (3/13)”, we leveraged newly found credentials for SSH Access on the gw machine, enumerated files and directories with a custom python script, extracted private data - such as private SSH Keys - and finally found our third token. Today we will leveraging the compromised gw machine to access the internal network and compromise the SSH-Test machine - which will include the following:
- Fingerprinting the SSH-Test Machine
- Pivoting into the SSH-Test Machine
- Finding the SSH-Test Token
Fingerprinting the SSH-Test Machine:
Since we were able to compromise the gw machine with e.lindsey’s credentials, let’s see if we can access any of the other machines - specifically the SSH-Test Machine!
If you forgot where the SSH-Test machine is located, then just consult our Network Map.
e.lindsey@tl10-ssh:/var/tmp$ ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_req=1 ttl=64 time=0.916 ms
64 bytes from 172.16.0.1: icmp_req=2 ttl=64 time=0.488 ms
64 bytes from 172.16.0.1: icmp_req=3 ttl=64 time=0.564 ms
64 bytes from 172.16.0.1: icmp_req=4 ttl=64 time=0.508 ms
^C
--- 172.16.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.488/0.619/0.916/0.173 ms
So we are able to successfully ping the machine and verify that it’s up and running. Our next steps would be to try and fingerprint the SSH-Test machine.
Unfortunately we don’t have any of our tools - but before we do anything - let’s check if the gw machine by any chance has Nmap installed.
e.lindsey@tl10-ssh:/var/tmp$ which nmap
/usr/bin/nmap
Awesome! Since we have Nmap installed on our compromised machine, we don’t have to do anything apart from just running the commands!
Thus, let’s run a Service Scan using the -sV option to check what ports/services are up and running on the SSH-Test Machine.
e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:16 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0010s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
25149/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.56 seconds
Pivoting into the SSH-Test Machine:
After our initial Nmap scan, we can see that there is only one custom SSH Port running.
I attempted to connect to the SSH Port with e.lindsey’s credentials, but for some reason I kept getting denied.
At this point I wondered if e.lindsey has any permissions on the SSH-Test machine - and its completely possible that she doesn’t!
Let’s think back for a minute…. Do you remember the Private SSH Keys that we were able to compromise from the gw machine? What? NO?! Then go back and read my previous post “Pentestit Lab v10 - SSH Token (3/13)”!
But if you do, good job!
I decided to try a.modlin’s private key and attempted an SSH connection to port 25419.
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 25149
ssh: connect to host 172.16.0.1 port 25149: Connection refused
Connection refused? What…. Maybe it’s the wrong port? Let’s run an Nmap scan to verify!
e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:16 MSK
Nmap scan report for 172.16.0.1
Host is up (0.00072s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
12957/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.15 seconds
Well that’s odd! It seems that the SSH port just changed from 25149 to 12957…. Maybe I should try connecting again?
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 12957
ssh: connect to host 172.16.0.1 port 12957: Connection refused
Failed again?! Did the port change again?
e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:22 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0019s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
8629/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.24 seconds
Port 8629 now? This machine is leading me on a while goose chase! Maybe this is the correct port, so let’s give it another shot.
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 8629
Could not create directory '/home/e.lindsey/.ssh'.
The authenticity of host '[172.16.0.1]:8629 ([172.16.0.1]:8629)' can't be established.
ECDSA key fingerprint is 2c:58:fd:06:ea:46:8e:f7:b5:28:58:58:06:fa:dc:38.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/e.lindsey/.ssh/known_hosts).
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'a.modlin.key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: a.modlin.key
Permission denied (publickey).
Oh, alright! It works! But it seems that our private key has too much permissions, so let’s change those permissions and try again.
e.lindsey@tl10-ssh:/var/tmp$ chmod 600 a.modlin.key
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 8629
ssh: connect to host 172.16.0.1 port 8629: Connection refused
OH COME ON! What is this?! Fine… one more time!
e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:25 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0019s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
26763/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.41 seconds
Again a new port… how surprising….
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 26763
Could not create directory '/home/e.lindsey/.ssh'.
The authenticity of host '[172.16.0.1]:26763 ([172.16.0.1]:26763)' can't be established.
ECDSA key fingerprint is 2c:58:fd:06:ea:46:8e:f7:b5:28:58:58:06:fa:dc:38.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/e.lindsey/.ssh/known_hosts).
Linux tl10-test-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.81-2 x86_64
Last login: Sun Nov 27 13:06:42 2016 from 172.16.0.8
a.modlin@tl10-test-ssh:~$
Finally! We got into the machine. At this point, let start some reconnaissance and find the key!
Finding the SSH-Test Token:
Since we are in the SSH-Test machine, let see what we have in our current present working directory.
a.modlin@tl10-test-ssh:~$ ls
token.txt
Wow… that was really convenient!
At this point I wondered if there was an easier method of compromising the machine since the SSH port kept changing, I was pretty lucky to be able to find a working port - otherwise it could have taken me ages.
If you already figured out what the method was for making it easier… good job! If you didn’t…. then that’s okay, just think back to the first Mail token that we compromised.
When we found a.modlin’s credentials from our SMTP brute force, we came across this email.
Unfortunately, I completely forgot about this app and the email! If I remembered it, then finding the port would have been pretty easy!
If you guys want, go ahead and try compromising the SSH-Test machine using this app - I won’t be doing a write up about it, so consider it as a learning experience!
But, this just goes to show - when pentesting - take good notes, and never leave any stone unturned, also always thoroughly look through a machine after compromising it to find valuable information that can help you in the future.
Token (4/13):
Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!
You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the SSH-Test Machine via SSH to get the token!
You learn by doing, so go through this walkthrough, and the lab - and learn something new!
That’s all for now, stay tuned for my next post as we compromise Token (5/13) - The Store Token!
Leave a Comment