Lab 7.1 ‐ Exploiting Pippin ‐ JM - Jacob-Mayotte/SEC335_Tech_Journal GitHub Wiki

Deliv 1:

Deliv 2:

Services:

ftp:

http

Deliv 3: Services of interest:

Since I knew that ports 21,22,80 were open I ran the following to learn more about these services on the ports: sudo nmap -p 21,22,80 -A 10.0.5.25

which revealed:

As you can read; "ftp-anon: Anonymous FTP login allowed (FTP code 230)" above is saying that there is an anon login. I looked up the version of the FTP server and was able to find a noted vulnerability too: https://www.cvedetails.com/cve/CVE-2015-1419/

It seems that this ftp server is poorly configured or there is a very easy access point, which I tested with: ftp [email protected] Which by surprise worked - nice job admin!

Remote Code Execution:

Deliv 4:

Knowing that we can connect to the ftp server, I created a test.txt file on my local machine. This was just so I could see if I could even transfer a file.

I ran ftp [email protected] to connect to the machine then the following highlighted commands:

Moved to directory with cd upload (This is a directory for the remote MediaWiki Website too), then set it to my local sec335-01 journal: lcd ~/home/champuser/SEC335-01/SEC335-Tech-Journal/Week07/homework, then I ran: put test.txt which moved the test file to the remote server. Once It finished it displayed 100% upload completion, so I ran, ls and found my file.

Deliv 5:

Leveraging mayotte_backdoor.php (created in assignment 7.1) I sent used the same strategy as above with the put cmd. I was on the sftp server and changed my local directory to webshell then used put mayotte_backdoor.php which moved the file to the sftp server.

Once this file was on the host I tried to execute remote code:

From the terminal:

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

or from the browser:

Take note of peregrin.took's account & mysql user.

Deliv 6:

When I take a look at the /etc/passwd file on the remote server target, I see the peregrin.took file and the mysql file. I decided to elevate our webshell and run the following URL search: 10.0.5.25/upload/mayotte_backdoor.php?cmd=ls+/bin

Inside the bin directory I was able to see what services were being run. Knowing that this is a media wiki, there must be some db connected to it, which was confirmed when I saw mysql installed, and the mysql user in /etc/passwd.

I also saw the "MediaWiki has been installed." On the main page:

I decided to take a deep dive into Media wiki and was able to find the following info from their documentation Source

"The LocalSettings.php file is not a wiki page, and you cannot access it with your web browser. Instead, it is a file in the file system of the server. Its contents are generated during the initial setup of the wiki, and the resulting file must be copied to the server manually." - From the link above. Knowing this, I went back to the terminal and ran the following:

ftp [email protected]
ls

get LocalSettings.php

Now I went back to my host machine and ran ls:

sudo cat LocalSettings.php and was able to find creds in the file!

Since I found a password and had knowledge of peregrin.took (from the etc/passwd file dump earlier) I tried to ssh into the target machine, which was successful:

User: [email protected]
PW: 1Tookie

Deliv 7:

Deliv 8:

Since we know that the internal database is a mysql db (As found in LocalSettings.php), and we know that the user is root, I tried to access the the mariaDB, fork of MYSQL.

Access mysql: /bin/mysql -u root -p
show databases; // will show all databases on machine
use mediawiki; // set the db to be searched to mediawiki
show tables // I see the user table which is what I serached through for a new credential
SELECT user_name, user_password FROM user;

Which provided a username and hashed SHA-512 hash!

Source: https://www.mysqltutorial.org/mysql-cheat-sheet.aspx for mysql commands

Deliv 9:

Provided Info that helped: Source direct from lab for this deliv

I used this source to restructure the hash I received from the last deliverable for Pippin.

Orginal Hash: :pbkdf2:sha512:30000:64:7zMbdjXKrFDDq4CRF5q9ow==:49ImFWdWRVz2dCDsJPj+P0Xovz153VenjKk7npuK7u5xgo21IUh+eY0QH8fQxdH/Cjx3zxZyQcfNChAnP11GNg==

After Revisions: sha512:30000:7zMbdjXKrFDDq4CRF5q9ow==:49ImFWdWRVz2dCDsJPj+P0Xovz153VenjKk7npuK7u5xgo21IUh+eY0QH8fQxdH/Cjx3zxZyQcfNChAnP11GNg== // NOTE THE LACK OF THE : at the start, had that included and it wouldn't detect hashes. I then took this hash and made placed it into 7.1_hash.txt

Then I followed the password high that were provided:

Password starts with a lowercase 'p' and is in the rockyou.txt wordlist

Since I had rockyou.txt on my desktop anyway, I ran the folllowing to create a new wordlist that hashcat could go through faster:

egrep '^p' /home/champuser/Desktop/rockyou.txt > p_rockyou.txt

Then I tried my hashcat password cracker:

hashcat -m12100 7.1_hash.txt -w4 -a0 p_rockyou.txt

hashcat is the password tool i used
hashcat flags were sued here
passed in new hash file and new rockyou wordlist

Final cracked PW: palentir

Reflect

This lab was once again extremely informative and was a nice way to reinforce hash cracking. I also really liked doing the webshell stuff, I was really joyous when I could run commands to the target via the url field on a browser. I noticed that I took my time with this lab and really ensured that I understood what was happening under the hood, which I am happy about, especially with the last deliverable. I was just using hashcat, and it was nice to be able to know what tool to use and have a preference because of my pre-existing knowledge on said tool. I also really loved the lab hints throughout the way, in all seriousness I thought it was a nice balance between learning and having guidance. The only negative I can identify is the amount of time needed for this password lists to fully run, it is time consuming.

In regard to the mistakes made by Pippen's sys admin... well there was alot. Below is a list of issues I could identify with remediations:

Password re-use. Pippin's sys admin had 1Tookie as the password for multiple logins. This is generally a terrible practice when it comes to password health. To remedy this, sys admins should be using complex, unique, and long password for different services. User and root should NEVER be resued ANYWHERE in the system. These accounts have different levels of privileges for a reason.
vssftp anon FTP login: If this was just disabled on the FTP service none of this breach would have occured. This is the initial attack vector, the low hanging fruit that will be exposed. Didabling this feature in the FTP config file is a best practice.
Lastly, removing ssh root access. Sys admins are generally taught that disabling root remote connections is the best security practice. All a person must do is access /etc/sshd/sshd_config (PermitRootLogin no) and set that value to no