Having fun with symlinks in Hostinger

Hello!!

Since my last blog post I have been looking for new vulnerabilities in Hostinger in my spare time (I have not had too much :P).

In this blog post I will speak about two vulnerabilities I found in Hostinger. Both are exploited by using symbolic links.
As you know, symbolic links (symlinks) are files which points to another files, I mean, you can create a symbolic link called “hello” which points to “/etc/passwd”. So, when you try to write in “hello” you are writing to “/etc/passwd”.

In order to create a symlink in the server I used the “Import Site” feature. It allows to the user to upload a Zip file and it automatically decompress the file in “public_html” directory. I created a symlink in my computer using the command: ln -s /path/to/file symlinkname
And then, I added the symlink to a Zip file using: zip -y data.zip symlinkname.

The first vulnerability is related to a bad configuration in the server. By using symlinks we are able to read other files in the server, outside of our user home directory (remember that hostinger offers shared hosting plans; multiple users share the same server but using different Linux users with different permissions). We were able to create a symlink to “/“ and use it over FTP in order to browse the server files. One of the most important directories is “/backup”, which stores all the backup files in the server (other clients backups).
I tried to browse “/backup” over FTP, but my user did not have the permissions to do that :)
But, I created the symlink on the “public_html” directory, so I was able to browse the filesystem by using a web browser. Using a web browser I was able to read files that I did not have permission by using FTP, and “/bakcup” and all their files was one of the affected directories I was able to read if I used the web browser. It seems that the Apache user had privileges to read those files.

I reported this issue and Hostinger solved it. They also rewarded me with a bounty :)

After that, I thought that maybe there was a vulnerability which could allow me to write files I did not have permissions to write (like /etc/passwd or similar).

I used the PHP configuration file “/opt/php.conf.d/USER.ini”, where “USER” is the name of my user in the Linux server. In this configuration file, PHP functions such as “system”, “exec” or “shell_exec” were disabled for security reasons. My objective was to find a way to edit that file and enable these functions. To do that, I tried different tools available on the client area. But only one of them worked fine.

One of the functions allows to the user to set a password for a directory in the website. It is done by creating/writing a “.htpasswd” file in that folder and writing the password selected by the user. I was able to write any file in the server by using this feature.

In order to exploit it to write any file in the server, firstly, I created a symlink to the file I wanted to overwrite. The name of the symlink should be “.htpasswd”. And then, as you are thinking, you have to set a password for the directory by using the “Password Protect dirs” feature. This feature seems to execute as root, so it will write in the file pointed by the symlink without problems. After this tool writes on the file, it set proper permissions for the file, so the original file will be readable and writable by our user after that. 

We only have to access by FTP or create a PHP script in order to write whatever we want to the file. 

I reported this vulnerability and they rewarded me with a bounty :)

If you want to read more about vulnerabilities on shared hosting servers based on symlinks, you can read this blog post written by @alvaroh5 in fwhibbit: https://www.fwhibbit.es/symlink-hacking-shared-hosting