# Hack The Box - Player

## Quick Summary

Hey guys, today Player retired and here’s my write-up about it. It was a relatively hard CTF-style machine with a lot of enumeration and a couple of interesting exploits. It’s a Linux box and its ip is 10.10.10.145, I added it to /etc/hosts as player.htb. Let’s jump right in !

## Nmap

As always we will start with nmap to scan for open ports and services:

We got http on port 80 and ssh on port 22.

## Web Enumeration

I got a 403 response when I went to http://player.htb/:

I used wfuzz with subdomains-top1mil-5000.txt from seclists to enumerate virtual hosts and got these results:

I added them to my hosts file and started checking each one of them.
On dev there was an application that needed credentials so we’ll skip that one until we find some credentials:

staging was kinda empty but there was an interesting contact form:

The form was interesting because when I attempted to submit it I got a weird error for a second then I got redirected to /501.php:

I intercepted the request with burp to read the error.
Request:

Response:

The error exposed some filenames like /var/www/backup/service_config, /var/www/staging/fix.php and /var/www/staging/contact.php. That will be helpful later.
chat was a static page that simulated a chat application:

I took a quick look at the chat history between Olla and Vincent, Olla asked him about some pentest reports and he replied with 2 interesting things :

1. Staging exposing sensitive files.
2. Main domain exposing source code allowing to access the product before release.

We already saw that staging was exposing files, I ran gobuster on the main domain and found /launcher:

http://player.htb/launcher:

I tried to submit that form but it did nothing, I just got redirected to /launcher again:
Request:

Response:

We know from the chat that the source code is exposed somewhere, I wanted to read the source of /launcher/dee8dc8a47256c64630d803a4c40786c.php so I tried some basic stuff like adding .swp, .bak and ~ after the file name. ~ worked (check this out):

It decodes the JWT token from the cookie access and redirects us to a redacted path if the value of access_code was 0E76658526655756207688271159624026011393, otherwise it will assign an access cookie for us with C0B137FE2D792459F26FF763CCE44574A5B5AB03 as the value of access_code and redirect us to index.html.
We have the secret _S0_R@nd0m_P@ss_ so we can easily craft a valid cookie. I used jwt.io to edit my token.

I used the cookie and got redirected to /7F2dcsSdZo6nj3SNMTQ1:
Request:

Response:

## FFmpeg HLS Vulnerability –> Arbitrary File Read

I uploaded a test txt file:

I got an avi file as a result which was weird:

I tried some other file formats and I also got an avi file.
So I tried the ffmpeg HLS exploit, I created a test avi to read /etc/passwd and it worked:

I created 3 more avis to read the files we got earlier from the error message from staging:

contact.php didn’t have anything interesting and the avi for fix.php was empty for some reason. In service_config there were some credentials for a user called telegen:

I tried these credentials with ssh and with dev.player.htb and they didn’t work. I ran a quick full port scan with masscan and turns out that there was another open port:

I scanned that port with nmap but it couldn’t identify the service:

However when I connected to the port with nc the banner indicated that it was an ssh server:

I could login to that ssh server with the credentials, but unfortunately I was in a restricted environment:

## OpenSSH 7.2p1 xauth Command Injection –> User Flag

When I searched for exploits for that version of openssh I found this exploit.

I tried to use .writefile to write a php file and get a reverse shell but I couldn’t do that. But anyway I was finally able to read the user flag:

## Credentials in fix.php –> RCE –> Shell as www-data

Earlier I couldn’t read fix.php through the ffmpeg exploit, I was able to read it as telegen and I found credentials for a user called peter:

These credentials (peter : CQXpm\z)G5D#%S\$y=) worked with dev.player.htb:

I tried to create a new project in /var/www/html:

But I got an error saying that I was only allowed to create projects in /var/www/demo/home so I created a project there:

When I ran gobuster on http://dev.player.htb/ there was a directory called home:

I wanted to see if that was related to /var/www/demo/home so I created a file called test.php that echoed test and I tried to access it through /home:

It worked so I edited my test file and added the php-simple-backdoor code and got a reverse shell:

## Root Flag

when I ran pspy to monitor the processes I noticed that /var/lib/playbuff/buff.php got executed as root periodically:

I couldn’t write to it but it included another php file which I could write to (/var/www/html/launcher/dee8dc8a47256c64630d803a4c40786g.php):

I put my reverse shell payload in /tmp and added a line to /var/www/html/launcher/dee8dc8a47256c64630d803a4c40786g.php that executed it:

And we owned root !
That’s it , Feedback is appreciated !
Don’t forget to read the previous write-ups , Tweet about the write-up if you liked it , follow on twitter @Ahm3d_H3sham
Thanks for reading.

Previous Hack The Box write-up : Hack The Box - Bitlab
Next Hack The Box write-up : Hack The Box - AI