Unrestricted File Upload - Possible exploits

Question

During a penetration test‎ (exercise) on a IIS web server + MYSQL DBMS, I have found an Unrestricted File Upload vulnerability for which I can upload a .php file.

So I have tried to upload a php shell using a passthru or an exec command but I have received the famous response "Unable to fork..." because, as far as I understand, the folder where I upload the file has some kind of security protection avoiding commands' execution.

Nevertheless I have upload a .php file in order to read a sample file using fopen, fread, etc command and I have done it successfully.

So my question is: what specific files could I read in order to grab sensitive informations of any kind? In other words: I can upload a php file that can display a content of a file, but I don't know what files should I look.

Ending question: do you know other exploitation methods for the unrestricted file upload vulnerability if uploading a shell like above is not permitted?

Answer 1

The specific files I would go after would be:

1. php.ini
2. PHP pages
   • These are very likely to have credentials embedded for database access or will give you clues as to where to look next.
3. my.cnf
   • MySQL configuration file
4. web.config
   • There may be some useful settings in IIS that can be retrieved by reviewing this file.
5. machine.config
   • Same as web.config but at the machine level.
6. Cache files
   • There could be some interesting data in the temp folder.

Those are the ones I can think of - once you start digging in these files, other ideas will probably emerge.

Ending question: do you know other exploitation methods for the unrestricted file upload vulnerability if uploading a shell like above is not permitted?

1. You could try to upload a file that will be executed on next reboot or put it in a location that an admin may accidentally run the file.
2. You could perform a DOS attack by exhausting the disk space on the box.

Answer 2

There are a few possible attack scenarios that I can think of..

Attacking the server:

As already mentioned, you can use PHP to open/read other files on the system that may give credentials, or lead you in the direction of other attack vectors.

Even though the upload vulnerability places the malicious file in a specific directory that may contain certain security features, this does not always prevent the malicious script from writing a new file into the parent directory.

You can use the script to see who it is being executed as, check the permissions of other folders on the system to see if they are writable by that user.

Another obvious attack would be accessing the database by method of scanning scripts and configuration files for credentials. With this database you may be able to crack the password, or compare it to a rainbow table if not salted.

If you are able to read and write to other scripts on the webserver, you could backdoor the code in hopes to gather the admin password in plain text instead of having to brute force the hashed passwords in the database.

Attacking the user:

One of the biggest concerns with this type of vulnerability is that you are able to execute code on the server as the server. This gives you access to the users cookies for that site, which can contain valuable information, possibly leading to a hijacked session.

There is also the threat of malware being spread by the site, phishing attacks, and any other sort of attack that targets the users trust in the site being legitimate.

There are obviously more ways in which you can attack the system with this sort of vulnerability. Much of the next phase in the attack will depend on the results of the information gathering you do at this point.

While not always true, its generally safe to say that if a script can be uploaded by an untrusted third party...the system is compromised. What you do at this point is just a matter of intent.