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 

Command Injection Vulnerability in Hostinger

Hello!

This is my first blog post in English, and probably next blog posts will be written in English too :)

Today I am going to speak about a vulnerability I recently found in Hostinger. As the title says, I found a Command Injection vulneravility in Hostinger. This kind of vulnerabilities allow an attacker to execute remote OS commands on the machine.

I realized that Hostinger has a GIT repository feature which allows you clone a GIT repo and deploy your website using that repo. And yes, here we find the vulnerability. As you should know, you can clone a repository using the following command:

git clone http://domain/path/to/repo folder

Their feature uses this command in order to clone the repo, they allow you to provide 3 elements:

- Repo URL
- Repo branch to be cloned
- folder in which the repo will be cloned

An attacker was able to use the "folder" input to inject OS commands. By using ";" we were able to close the "git clone" command and inject other commands to be executed. In the following picture you can see the UI of the feature in the Hostinger CPanel, which will break the "git clone" command to finally execute "wget".

I used "wget" to see if the command was being executed by receiving the GET request in http://requestb.in/. Then I realized that you can see a log output of the deployment and you can see the output of the command execution on it (see picture 2).

As you can see in the picture, we have a command execution with root permissions... No need to use any other exploit to obtain root permissions. An attacker have all he need in order to use Hostinger server, for example to do DDoS attacks. Or maybe to delete all the data of other clients in the same server (remember that Hostinger is a shared web hosting service ;))

The vulnerability was reported to Hostinger and fixed in less than 48 hours (good job).
Anyway, I have to say that I did not received any response to my report, so once I realized that the vulnerability was fixed, I wrote another email to ask if the vulnerability was finally fixed and if my vulnerability was elegible for a reward (supposedly they have a bug bounty reward program: https://www.hostinger.es/politica-divulgacion-responsable).

Finally I received a response, they appreciate my help but they said "after analyzing the impact of it and we confirmed that a bonus cannot be provided this time."

So they analyzed the impact of the vulnerability and is not elegible for a reward, OK. I understand that they are the ones who must decide if a vulnerability is or not elegible for a reward, and I accept their decision. But if a vulnerability which allows a malicious user take total control of their servers with root permissions to do whatever he want with the server and the clients data is not elegible for a reward, I don’t know what kind of vulnerability could be more dangerous in order to be elegible for a reward.

If you have reported some vulnerability to Hostinger, tell us your experience on the comments!

I hope you like this blog post! :)
I will try to write more frequently here, because I have not written a blog post since September 2016 :S

You can also follow me on Twitter: http://twitter.com/alberto__segura


UPDATE (13-02-2017):

Today the Customer Success manager at Hostinger has written an email saying he has reviewed my case. He has explained why they did not provide a reward for the bug. The git command was running in a Docker container which is created in order to do the deploy and destroyed after that. Even so, they have finally rewarded me with a bounty because they had to fix other issue to prevent additional errors.

Hostinger, thank you very much for the reward! :)

And thanks to all who have read and shared this blog post!