PHP file_get_contents vulnerability

Question

I'm assessing security of a webportal for a client and I found a vulnerability.

This is the PHP code:

echo(file_get_contents("template/data/" $_GET['id']));

I was able to successfully read ../../../index.php, config.php etc.

But I just want to be able to prove that this bug is more critical than reading configs. I read the MySQL user/pass, but I can't connect to it since its listening on localhost only. All other codes I read, didn't lead to anything. So basically all I got was just some source code which was kinda no secret.

I can't do php filter stuff because it has "template/data/" in the beginning of string.

What else can be done with this vulnerable piece of code? Any ideas?

Answer 1

Hector's answer has some great examples, but I'd like to emphasize one other very important point:

This is not a small vulnerability

You seem to be under the impression that if "all" you can do is read arbitrary files on their system, then the vulnerability isn't really a vulnerability. I'd argue the exact opposite. You have to realize that security is best approached from the perspective of defense-in-depth. It can be virtually impossible to have a vulnerability-free system, so the goal is to have as many layers of defense as possible in as many areas as possible, so that if a malicious actor finds a weakness in one area, defenses throughout the system will prevent them from causing any real damage. Many real world breaches happen, not because there was a vulnerability someone took advantage of, but because there was a vulnerability that let them take advantage of another vulnerability, that let them do something else, until they found something really dangerous.

This little vulnerability is giving malicious actors full read access to your system. This is further compounded by the fact that this was a fairly obvious security blunder. If the company in question had well trained developers and were doing regular code reviews, it is (IMO) very unlikely that such code would make it to a production system. The significance of this fact is that it suggests this won't be the only security vulnerability present. The fact that you now have a way to directly view the system's source code means that finding further security vulnerabilities is substantially easier. Quite possibly game over. Were I a malicious actor and I found this I would:

1. Download the entire system's source code (might take a day, but is almost certainly possible)
2. Look for any SQLi vulnerabilities (there are probably plenty), and use those to download their entire database. I'd say there are good odds they aren't using proper password security. It would be obvious from their source code, which means that if they aren't properly securing their passwords, an SQLi vulnerability will allow me to:
3. Brute force the administrator passwords. Now I'm in your web portal. But guess what? I'm not done
4. Most business user's reuse passwords all the time. So now I'm going to take the admin password and see if I can login to their own email account. From there, with a little luck, I may be able to get into their hosting account management. Or maybe payroll or bank accounts. The sky is the limit once I have your email password, especially for an administrator account. It's even better if the companies email is hosted by a cloud-hosting provider (office 365 or the like), and the admin password that I cracked gave me access to the email hosting provider. That gives me access to every single email address in the company.
5. Maybe though I found an SQLi vulnerability and downloaded the database, but they had good password security and I couldn't crack anything. Now I start looking for XSS vulnerabilities in your source code. A few easy social engineering emails and I use XSS to gain access to an admin account on the system without knowing their password. What now?
6. I bet there are areas of the system that an administrator can use to update the system. Do they have a CMS? Does it have capabilities like wordpress, etc, which allow admins to edit templates from the web portal? Because if so I've used it to install a backdoor on the machine to directly access the underlying system. I'll be stuck with the permissions of whoever the web server is executing as. Hopefully the server is not running as root. If nothing else I'll install a Monero mining bot that won't start for a couple months, a well hidden back door, and then just start spending your CPU time and money making me money. Unless they have a clean copy of the system outside of the live server (many small companies don't), they'll never get me out. They will burn countless amounts of time and money trying to get this mystery virus out of their system that keeps returning no matter how often they start clean.
7. While I'm at it, I'll install some code that will automatically send me the email addresses and passwords of everyone who logs in to the web portal. Return to step #4 above.
8. Heaven help them if they have something valuable in its own right inside the system. Social security numbers? Credit cards? If they are keeping any such information for their employees or customers it is mine now.

This is not an isolated security problem. Such things never exist in practice.

Answer 2

Is the MySQL database on the same machine? If so can you just pull the database files and reconstruct the DB on your machine?

As others have stated you can pull /etc/passwd which contains a lot of information about the user layout. If you can access /etc/shadow you can attempt to offline crack passwords.

If the web application has a login portal attempt the mysql credentials as well as "admin", "root" etc. with the password.

Does the source code or config files contain any other access credentials / API keys? Is the sites SSL certificate readable - if so you can Man In the Middle connections?

You can also pull details from /proc/version, /etc/issue etc. and the webserver versions to look for other known vulnerabilities.

Finally is the source supposed to be public? If not source code is often viewed as valuable. And you can inspect that for further vulnerabilities.

Answer 3

Lots of good info in the other answers which include a lot of could happen reality and should be taken serious.

Not sure of your hosting setup, but let's say you're on whm server with other accounts and the function is used to get the content of /etc/passwd which includes lines like this for users on the system:

username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
etc...

You could then for each username pass:

/home/username/public_html/wp-config.php 

And end up with the config file of every wp site. This is just an example... ultimately, you should do your best to secure things higher up than the code - as another layer.

What should happen if a local path like /etc/passwd is provided to the function:

<br />
<b>Warning</b>:  file_get_contents(): open_basedir restriction in effect. File(/etc/passwd) is not within the allowed path(s): (/home/uservalue/public_html) in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />
<br />
<b>Warning</b>:  file_get_contents(/etc/passwd): failed to open stream: Operation not permitted in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />

"open_basedir restriction in effect."