Book just retired on Hackthebox. It was made by MrR3boot, one of my favorite box maker.
This box didn’t break the rule and was really well designed. While rated Medium difficulty, the foothold and user gave me more trouble than some Hard rated box. For once you have to think way more in real life scenarios than in CTF-like style. Still super interesting and I recommend it if you are comfortable with medium and hard boxes. Place to the write-up now!
Tl;Dr: The user flag required you to exploit two parts of the “Book” website. First you had to exploit a MySQL truncation misconfiguration to login as
admin to the admin panel. Then you login as normal user to the user interface of the website. From there you exploit a local file read vulnerability via XSS in a dynamically generated PDF visible from the admin interface you accessed earlier. Using this vulnerability you can access the user
reader SSH key and use it to grab the flag.
The root part consisted in exploited a vulnerability (CVE-2019-10143) in the
logrotate utility running allowing running arbitrary binary as
Alright! Let’s get into the details now!
First thing first, let’s add the box IP to the host file:
[[email protected] ~]$ echo "10.10.10.176 book.htb" >> /etc/hosts
and let’s start!
Let’s start with the classic
nmap scan to see which ports are open on the box:
[[email protected] ~]$ nmap -sV -sT -sC book.htb
We have a classical web app running on port 80 and the SSH port 22 open.
http://book.htb display a following page:
We have a sign-up/login form. Before anything else let’s run
gobuster to see if we can find anything else valuable:
[[email protected] ~]$ gobuster dir -u "http://book.htb/" -w ~/SecLists/Discovery/Web-Content/big.txt -x php
We do have plenty of pages, once login we will be able to check all of them in more details. First thing that catch the eye is the
/admin endpoint. Opening it display almost the exact same login page, expect that it’s only possible to login:
Since we don’t have enough information to try anything on this admin page let’s go back to the normal login form.
From here let’s create a user account and use it to login. Once done we get welcomed to the following panel:
From here we can see we have access to most pages that were returned by
The most interesting part seems to be the
/collections one where it’s possible to upload your own books:
When facing a file upload form it’s always good to try uploading a web shell right ? Unfortunately, no matter what is being uploaded, the form returns the following message:
Thanks for the submission. We will evaluate and update the list
The problem here is that we have no confirmations if the file got uploaded successfully and no idea where it got uploaded. Yet we notice the “We will evaluate and update the list“. This probably means that from the admin panel we found early it should be possible to see the “pending” upload ? Let’s keep the that in mind.
Our next step here is to find a way to enter the admin panel to see if we can get access to additional informations and maybe to the uploaded files in any way.
While looking around we stumble across another useful piece of informations in the
We now know the admin email is
[email protected] (even though we could have guessed it). We only need to find its password now. Brute-forcing is never the way to go on web app and will just risk to break the box for other users so let’s find another method.
In the same idea of the ForwardSlash box maybe we can Sign up using
[email protected] as email and get the account password overwritten ? Unfortunately trying so simply returns the following error message:
To be honest I got a bit short on ideas at this point until I noticed something interesting in my user account. We have the possibility to edit our username, but it gets truncated after 10 chars:
Changing my username to
abcdefghijqlmnopqrstuv will return as follow:
Signed in as abcdefghij
Spaces seems to be removed aswell, so changing my username to
hg8 a returns:
Signed in as hg8
This made us wonder if the same happen on account creation ? What would happen if we try to create an account with
[email protected]··············a as email (
· being a space) ? Maybe you could overwrite the admin password this way ?
Let’s go to back to the Sign Up form and launch the following request:
[[email protected] ~]$ curl 'http://book.htb/' -i \
302 Found and a redirect to
index.php. Looks like we are on the right tracks! Let’s now try to login using those credentials and bingo!
From there we have access to various moderation tools. We do have access to the
Collections part we were looking at in the user panel:
On this page it is possible to download a PDF of the users list and the book collections. The PDF content is a simple table and available through a random filename:
At first look this table looks like a simple HTML table converted to PDF. Here is the HTML Table example available at W3School:
This puts us on the right tracks, the PDF is very probably dynamically generated from a page of this admin panel with a tool like PhantomJS or so… Let’s dig into this idea.
So our starting point is a guess that the
collections PDF is generated from an HTML page. Knowing we can control some of the values that end end in the PDF (using the user panel) maybe we can inject something in the final PDF ?
First let’s try to inject HTML to see if we can validate our idea. Going back to the user panel let’s enter HTLM tag in the
Let’s send it and go back to the admin panel to generate the
Going back to the admin panel we can find our PDF have been fully replaced with our “Test” string:
We can come up with the following payload:
First the payload will open the local file
/etc/passwd then write its content to the document root. Let’s send it on the user panel and observe the results on admin panel generated PDF:
Neat, thanks to file informations we know the user we are after:
If we are lucky enough maybe we can use the local file read vulnerability to access
reader SSH key. We should be able to do so using the following payload:
Again let’s send this payload and access the generated PDF:
Using this key we can connect to
reader and grab the user flag:
[[email protected] ~]$ ssh -i id_rsa [email protected]
Looking around we quickly notice an usual folder in the
reader home directory:
[email protected]:~$ ls
These two files are Apache access logs. It’s usually found in
/var/log/apache2/ directory. Seems like some task is backing up those access log files in
reader home directory.
Before searching further, let’s focus on this unusual backup task. As every unusual items on a box it’s often the way to privilege escalation.
To do so let’s explore running processes to see if we can find anything related to Apache access log. For monitoring processes I always use
pspy which is a really great tool and helps a lot during CTF:
First let’s download and push
pspy to the server:
[[email protected] ~]$ wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.0/pspy64
Then we can run
pspy and quickly enough a interesting process popup:
[email protected]:/tmp/.hg8$ ./pspy64
We have a
logrotate process running as root. Having never used it before let’s check it’s manual:
Logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large.
Let’s find out the arguments used in the command
/usr/sbin/logrotate -f /root/log.cfg:
[email protected]:/$ man logrotate | grep -A 5 "\-f"
/root/log.cfg probably contains the configuration to copy
access.log files to
reader home directory.
After looking at the documentation for a while it didn’t seem this process can be abused to achieve privilege escalation on the box.
Since the process is running as root maybe we can check if the version running have any public vulnerability allowing us to privilege escalation. The version on the box is
[email protected]:/$ logrotate --version
A quick Google search yield an interesting result:
Exploit Title: logrotten 3.15.1 - Privilege Escalation
logrotate is prone to a race condition after renaming the logfile.
logrotateis executed as root, with option that creates a
file ( like create, copy, compress, etc.) and the user is in control
of the logfile path, it is possible to abuse a race-condition to write
files in ANY directories.
An attacker could elevate his privileges by writing reverse-shells into
directories like “/etc/bash_completition.d/“.
Looks exactly what we need right ? Since the
/home/reader/backups directory is under our control it seems like we have all the elements to successfully use this exploit.
Let’s follow the exploit page to setup everything properly.
- Let’s compile the exploit file. After reviewing the code it seems like no changes are required in order to work properly on our box:
[email protected]:/tmp/.hg8$ vi logrotten.c
- Then let’s create our payload. The payload I will use consist in adding my SSH public key in the
[email protected]:/tmp/.hg8$ cat payload
- Next step is to run the exploit with our payload and the log file to watch for:
[email protected]:/tmp/.hg8$ ./logrotten -p /tmp/.hg8/payload /home/reader/backups/access.log
Let’s append content to our log file to trigger the log rotation:
[email protected]:/$ echo "test" > backup/access.log
Our payload should now have been written to
[email protected]:~$ cat /etc/bash_completion.d/access.log
After waiting a little we should be able to be able to connect to the
root account trough SSH:
[[email protected] ~]$ ssh -i id_rsa_htb [email protected]
As always do not hesitate to contact me for any questions or feedbacks.
See you next time !