Basic Pentesting: 1

This is a write-up of my first crack at some basic penetration testing. The VM I targeted was downloaded from https://www.vulnhub.com/entry/basic-pentesting-1,216/

Having briefly toyed with this target before, I knew that it would boot to a login prompt for a sudo-enabled user who’s password was the same as his username. Not wanting to get nothing out of it, I chose to ignore this information. For my setup the target VM was isolated to is own network, where the only other machine it could see was the kali VM.

First I ran ip address on the kali box in order to grab my current IP and see the network block, which showed 192.168.56.103/24.

In order to discover the address for the target machine, I then proceeded with a basic nmap scan: nmap 192.168.56.0/24

This revealed the IP for the target box (192.168.56.101). I saw some open ports and so performed a service scan of the target with: nmap -sV 192.168.56.101

This revealed listening ports for FTP, SSH, and an Apache web server. I decided to pursue the web server. An HTTP request to that IP showed a basic web page reporting successful Apache server installation. Figuring there was more, I pointed the dirb web enumeration tool at it:

This revealed what looked to be a WordPress blog, but the CSS links were broken. Inspecting the source code, I found that they were trying to call to a domain called vtcsec. I figured it was just supposed to be the target machine, so I added an entry to the kali hosts file to point reference to that domain to the target’s IP address. Everything looked fine after a reload.

Also of interest is that XML-RPC file. Apparently it’s some way of making remote procedure calls? It’s probably another attack vector. When I tried to access the page it said that only HTTP POST operations were permitted. Exploiting it would probably involve either hand crafting an HTTP request or see if there’s an existing XML-RPC tool that can handle that for me.

Regardless, I proceeded to scan the WordPress installation and enumerate the users.

I had some trouble here. WPScan couldn’t seem to find the installation unless I gave it both the WP root folder and the wp-content folder. I suspect my editing of the hosts file may have been the problem? Regardless, WPScan also seemed to alert on the XML-RPC access point. Going by the references listed alone, it looks very possible to do a lot of harm with that.

There’s a standard admin account. I figured the chances of using a default password here were high, so I tried logging into the installation with username admin, password admin. Worked perfectly.

WordPress installations use themes to configure their layout and look, in the form of .php files that are executed by the server and make the function calls to the CMS. It also has a theme editor where an admin can simply go in and modify those files. This can be dangerous, because php will allow the programmer to pass shell commands back to the server.

So that’s exactly what I did:

(Note that I first attempted to instead start a netcat instance that connected to the kali box so that I would have a reverse shell. I couldn’t seem to get netcat to really work on the target and got zero feedback on it. I’m sure I was doing it wrong)

The passwd and shadow files contain the users and password hashes for all the users on the system. By outputting them with cat and then telling php to echo that, you can post their contents to the webpage. I wrapped it in a

 element so that line breaks work properly.



This is just a snippet of the output where passwd ends and shadow begins. There were a lot of users. Also, this is extremely loud and would be blatantly obvious to anyone accessing the page. Some additional php code that only outputted when certain arguments were passed would be a better persistence solution.

Turns out that all of these various users (which hint at various roles) have their logins disabled, signified by the ! or * where the hash would go. All except marlinspike. I already know that password from blind guessing, but I wanna get it the “right” way. Since I had the passwd and shadow files, I figured I could probably crack them. I simply copy/pasted the output into new separate files on the kali box. Then I combined them into a normal passwd file:



My first go with John the Ripper (password cracking util) I used the built in dictionary only. This didn’t give me anything, and in retrospect I shouldn’t be surprised. Apparently if you don’t feed it a built in dictionary explicitly, it uses then then proceeds with more brute force techniques.



Bingo.



Even l33t haxx0rz fat finger passwords.



Netcat was indeed on the system, so who knows what was up with my reverse shell attempts.



A compromised account with sudo access might as well be root.