Lab 7.1 Exploiting Pippin - Oliver-Mustoe/Oliver-Mustoe-Tech-Journal GitHub Wiki

In this lab, we used various techniques to exploit and gain user and root access in the host "Pippin"

Notes

First I ran a NMAP scan against the top 100 ports, which generated a list of 3 services/TCP ports (OpenSSH/22TCP,FTP/21/TCP,Apache/80TCP). After finding these, I ran a specific scan against all of them using the -A flag (more in-depth information for command syntax found in the Dedicated NMAP commands and techniques page):

In-depth command:

sudo nmap -p 21,22,80 -A 10.0.5.25

Screenshot of in-depth nmap scan:
D1 - Copy

2 things particularly interested me in the scan. First was the web service, which I tested and could access a MediaWiki service on the browser (I noted this for later and moved onto the FTP service.):

Screenshot of the MediaWiki in actions:
D2 4

Then I moved onto investigating the FTP service, particularly the anonymous login that nmap pointed out. Using this information, I researched and found that this is massively exploitable. This allows me to login to the FTP service (without authentication) and upload files onto the server. I then tested this by do the following (screenshot is the captured process with explanations of commands below):

Explanation:

FTP as anonymous : ftp [email protected]
Move into a directory : cd upload
Move into a local directory (where my test file was located) : lcd ~/Oliver-Mustoe-Tech-Journal/SEC-335/week7
Move test file onto server : put secretfile_secrets.txt
Check to ensure the file is there : ls

After testing, I would use this same process to put a simple webshell (the one found in /usr/share/webshells/php/simple-backdoor.php) which I named "donttouchme.php" onto the host. I could then execute remote code execution in the terminal with the following command:

curl http://10.0.5.25/upload/donttouchme.php?cmd=cat+/etc/passwd

OR in the web browser (see screenshot below.):

Then, I used my backdoor to navigate around the target and investigate a little. My investigation, primarily to find information that could provide the ability to SSH onto the system as a user, centered around the MediaWiki service. My reason for looking at MediaWiki is since I saw on it's homepage the ability to login. If you can login, usernames and passwords must be stored somewhere (possibly insecure.) I reported the following:

I found sensitive data on the target 10.0.5.25 by first researching the software “MediaWiki”. In my research, I found that the software has a basic configuration file “LoginSettings.php” that might contain valuable information. After finding and searching the file on the target, I found a database name and its root username and password. Researching further, MediaWiki uses this database to store a lot of information, such as user information, so this can be leveraged for later database exploitation. The password found in “LoginSettings.php”, “1Tookie”, can also be tried in other logins, such as SSH, to see if the creator was lazy with their credentials and used the same password.

TL;DR: Found username and password for a database in the MediaWiki config file "LoginSettings.php", password could be used for other exploitation.

Found credentials in "LoginSettings.php":

## Database settings
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "mediawiki";
$wgDBuser = "root";
$wgDBpassword = "1Tookie";

With my found creds, I tried to login as the peregrin.took user (found in my webshell command, screenshot of web and noted curl command above) with the password "1Tookie" and it was a SUCCESS (screenshot of login below):

With this user access, I logged into the MariaDB (a fork of MySQL) database using the database credientials found in "LocalSettings.php" and began to search. What I found was the database "mediawiki", same one from "LocalSettings.php", and its table "users". This contained a username "Pippin" and a hashed password, which I would transfer over to my Kali VM. There was another user, but this was a user I had created when I was testing the web server so I ignored it. Screenshot of this process in the command line below:

Explanation of MySQL commands:

Go into MySQL : /bin/mysql -u root -p
Use the mediawiki database : use mediawiki; (see all databases with show databases;)
Select certain fields from the user table and sort them by a certain column descending : SELECT user_name,user_password FROM user ORDER BY user_name DESC; (see all tables with show tables; and use the same use command from above to use a certain one. See all data in the table with SELECT * FROM {table};)

Really good resource for MySQL commands Link

With my hashed password, I used the lab provided resource and Google to find how to format my hash for hashcat.

I transformed the hash:

:pbkdf2:sha512:30000:64:7zMbdjXKrFDDq4CRF5q9ow==:49ImFWdWRVz2dCDsJPj+P0Xovz153VenjKk7npuK7u5xgo21IUh+eY0QH8fQxdH/Cjx3zxZyQcfNChAnP11GNg==
- Into
sha512:30000:7zMbdjXKrFDDq4CRF5q9ow==:49ImFWdWRVz2dCDsJPj+P0Xovz153VenjKk7npuK7u5xgo21IUh+eY0QH8fQxdH/Cjx3zxZyQcfNChAnP11GNg==
- To comply with the hashing rules:

I then used the password hints in the lab "tip: the password starts with a lowercase 'p'" & "it is also in rockyou" to generate a version of rockyou.txt starting with lowercase p's with the command:

egrep ‘^p’ rockyou.txt > p_rockyou.txt

With my password list and transformed hash, I ran hashcat. After a short time, the password was cracked!!! (hashcat command seen in screenshots below):

D9 1

I then tried this password to login to the target as root, and IT WORKED!!! (screenshot shows root SSH login below):
D10

Loot

Reflection

Personal

Always try the most simple option (particularly with passwords.)
- I made the mistake early on in the lab of not thinking that the systems administrator could be reusing the same password for multiple accounts. This caused me to have the credentials to the "peregrin.took" user for quite awhile until the professor let me know not to over think it. Going into future labs, I am going to try passwords and other info elsewhere to see if I get hits.
Having hacks on hand.
- As I did the Assign. 7.1 before this, I already knew about and had a simple webshell available for me to use. This was incredibly useful, and I made sure to include it in my Github for later re-use. With later hacks in this course, I plan to do the same so I can develop my own "list-of-hacks-that-work-well."
Regex for the win.
- Knowing how to make a smaller version of rockyou.txt (about 1.4 mill to a little under 500k) made the cracking process faster, making it a essential skill (when given hints, or knowing certain information.)

Mistakes by Pippin system admin

Enabling anonymous FTP login
- Without anonymous login being enabled on the FTP service, the entire attack of this lab would not have worked (a different vector for a initial foothold would have to be used.) Disabling this feature in the FTP configuration is generally a good move, or restricting anonymous login to download only at least. This Link is a guide on how to do this by Boston University.
Having root SSH enabled
- While root could have been achieved in different ways, just being able to SSH into root provided an easy and straight forward way to test passwords to see if it was the root password. Disabling this feature in /etc/ssh/sshd_config (PermitRootLogin yes #enabled > PermitRootLogin no #disabled, then restart ssh) is the remediation tactic that should be employed (according to IBM.)
Password re-use
- Without the reuse of passwords, this attack would have taken substantially longer and be more complex. To remedy this, the system admin would need to used unique passwords for their various services. Especially, user and root password should NOT be reused anywhere in the system.