Snap-labs (Entry Level Pentesting)

After we have downloaded our vpn file we can vpn into the network

First i want to scan the Esge network and see if i can gain a foothold on one of the edge machines

results

10.10.0.4

  • Ubuntu machine

  • HTTP and HTTPS web server Apache 2.4.41

  • SSH

10.10.0.103

  • FTP (anonymous access allowed

  • SSH

  • HTTP and HTTPS

  • we can see the robots.txt

10.10.0.181

  • SSH

  • HTTP web server

Letts scan all ports on targets to see if we are missing anything

the only new Ports we have found was for host 10.10.0.103

results

10.10.0.103

Looking through the output we can see machine 10.10.0.103 allows for anonymous FTP access, seems like a good place to start

listing the contents we can find the following

  • include in report, anonymous access via FTP

  • we can see we have read access to the index.html

  • and we have rwx privileges within the temp directory

Looking in the directory we can see anything

Lets checkout the webserver and see if it is connected in some way to the ftp server

  • we can the default Apache installation page

  • we can confirm this is indeed ubuntu

  • this is concerning, we have anonymous access to the root directory of the web server via FTP

Lets checkout HTTPS

we can see a Gitlab application

  • Not much here

I want to test, if we can upload a php reverse-shell to the ftp's temp directory and trigger it in the url

  1. copy our php reverse-shell into our working directory

  1. add your IP and port for connection

  2. login into the FTP server

  1. change into the temp directory

  2. upload our rev.php shell

  1. start a nc listener

  1. navigate to http://10.10.0.103/temp/rev.php , if we look back at our listener we should have a shell on 10.10.0.103

we have our 1st shell woohooo

Lets enumerate the other web server and come back

HOST 10.10.0.181

when we click on "show me the goods" we can see the following

Looks like PHP syntax (given the get_repos.php?), it is an array with the following key-value pairs

Lets check this url out and see if we can find anything interesting

Looks like we access to that gitlab server we found earlier

  • Add to report (Sensitive information expsoure)

  • noothing interesting in these files lets check the commit history

Checking through the commits we do find something interesting

Looks like we have a set of creds, for the host 10.10.1.111 Database gitlab, could be reusable

  • sensitive information exposure

  • within the internal subnet

  • try anywhere we can

host 10.10.0.103

Lets see if we can access the gitlab server using these credentials

  • No luck

host 10.10.0.103 WEB-2 shell as www-data

Alright now we have our initial foothold within one of the external servers, lets get to know our landscape

Lets upgrade our current shell, since this is an ubuntu server python3 should already be installed so

first i want to find any creds, keys anything to up escalate our privileges

  1. we need to find what users are on the system

we do find one user on the system

  1. Lets see if we can find anything within the user brandon's home directory

  • we do see a .ssh directory, lets see if we can find any private keys

  • we do not have permission yet, Lets see if we can su users and use the credentails we found ealier during the git commits

  • no luck

Lets download linpeas.sh onto WEB2 and see if we can find anything interesting

  1. copy linpeas to working directory

  1. start a python3 server

  1. from our shell on WEB2 lets download the script within the /tmp directory

  1. lets run the script

  • i personally like saving linpeas to a output file, easier to reference later on

  1. Lets start a python http server on WEB2 so we can download our linpeas.output file

  1. Lets download it to our local host

we do find something interesting happening in the cron.d directory

we can see a cron job that isnt defualt

  • we can see the user brandon is executing the /etc/log-time.sh script, lets see what permissions we have on the script

  • we can see the permissions for everyone is read, write, execute, meaning we should be able to drop a bash reverse-shell in the script, and when executed we should gain a shell as the user brandon

  1. Lets reuse our rev.php script, we will change the port number to another in my case port 9010

  2. start a python server

  1. download our rev1.php to our /tmp directory

  1. now we want to append the the log-time.sh script, to run our PHP script

  1. now we just need to wait for the cronjob to execute and we should have a hit on our listener

Note i was having problems executing our rev1.php so i decided to reuse the rev.php we place in the /var/www/html/temp/ directory

  1. modify the log-time.sh script

  1. start a listener on port 9001

  1. we get a hit after the cronjob executes

  • we know have a shell as brandon

Lets look through brandon's .ssh directory and see what we can find

we do find brandons private key

Lets copy this to our nlocal hosts and ssh into the machine

  1. give it the neccasary permissions

  1. Lets see if we can authenticate to WEB2

we now have SSH access to WEB2 machine

Lets start branching out to other devices on the network

checking the networking interface within WEB2

HOST 10.10.0.181 WEB1

Lets see if we can SSH into 10.10.0.181 using brandon's private key

  • woohoo we can

Lets check if there are any other users on the box

  • no other users

Lets run linpeas and see if we can find anything

we should still have our python server up so we can

Lets downbload the linpeas output file

  1. start a python server on WEB1

  1. download the output file to our local machine

  • not alot to go with will review later

Now we have access to both WEB1 and WEB2 external servers, we need to find a way to start pivoting into the internal servers located in the 10.10.1.0/24 subnet

  1. we need to find the IP address of the internal hosts (if we are not looking in our snap lab)

  • we can write a quick bash script to scan the internal subnet

  1. save this to a .sh file and upload it to the WEB1 host using a python server and wget

  1. Now lets execute the script

we can see we have two IP addresses

i want to perform some port scanning on the internal servers, or atleast identify any open ports

Lets utilze chisel

  1. clone the repo

  1. within the chisel directory we want to run go build

  2. within /chisel/executables/linux we will find the executable, i like to change the file name for ease of typing

  1. Lets upload it to WEB1, your python server should still be up and running

  1. First we want to set up the chisel server on our local machine

  • -p: allows us to specify what port chisel listens on

  • --reverse: tell the server (us) that we want clients connecting in to be allowed to define reverse tunnels, essentially meaning clients connecting can open listening ports on our local machine

  1. Now the client (WEB1) since we have already transfered the ch.sh (chisel) the basic syntax includes

  1. looking back at our local machine we should see a connection

Now we can configure our proxychaines file to route through chisel

  1. We need to configure our proxychains.conf file

  1. we need to create an entry pointing to our local host and port 9010

Now we should be able to proxy our nmap scan through proxychaines and chisel

we should be able to scan the internal network

- hmm it didnt work

lets try sshuttleinstead

we will target WEB2 (10.10.0.181), if we remeber this was the web server that is connected to a Database

for reference

to initiate sshuttle we can

Now we should be able to run nmap scan's (on particular ports), since we know the there is a connection to a database, and we know there is a windows Domain Controller most likely mssql which the default port is 1433

  • we are having problems with nmap going through sshuttle

we know it is connected to the database, we should be able to connect

for this we will use impackets mssqlclient,py

Lets try chisel again

Lets create a socks proxy to we can proxy through 10.10.0.181 into the internal subnet of 10.10.1.0/16

  1. target server 10.10.0.181

  1. local machine

  1. Scanning 10.10.1.111

  • -q: quiet

  • -sT: Syn scans wont work through our pivot, we have to specify a full tcp connection

  • -F: switch for fast scan

Last updated