Hello, I am currently pen testing a web application and I am stuck in the middle of a vulnerability. I am looking for tips or idea to move on in my exploitation.

I can upload any files on the web server in a writable directory (including .phps) and run them. This allowed me to get a reverse shell on the web server, but it runs with the rights of the web server. The thing I want to do is turn off the magic_quotes_gpc flag from php, because i am sure it hides some SQL injection flaws.

I need to accomplish 2 steps to do that:
1- modify php.ini
2- restart the apache server

The current rights I have are not enough to do either of those steps. The only vulnerability I found on the server that could be used for my purpose is this one CVE-2009-1195, however the web server does not seem to allow .htaccess files so right now I am out of ideas. Anyone has an idea of what I could try ?

Thanks,

Yes, I did find the DB cred and while I can use them to get or insert data, I still want to exploit the SQL injection (if any). The reason is that I want to be thorough in my pen testing. magic_quotes_gpc is a deprecated flag so even if the SQLi are not exploitable right now they might be in the near future. I consider this a vulnerability and I'ld like to prove to the client that it is dangerous. He might not see the need to fix it if I cannot exploit them, hence the reason I'm asking for help. So far I've been unsuccessful with everything I tried.

For PHP there's a default configuration (if an entry is not defined), the php.ini file, and the runtime configuration. You can't edit the php.ini file and restart the server without usually being root or a similar privileged user. You can however individually for each script unless disabled, set whether magic_quotes should be enabled for that particular script. (See php.net for more information.)

What I recommend is that you download a copy of the web application to your local machine and review the source code, as reviewing it on the server may be a bit complicated though far from impossible. (Avoid using editors like nano and vim, use cat to read, or cp to move.)

Look for database credentials in the configuration file for the web application you're exploiting, read /etc/passwd if you can and attempt to guess the passwords for user accounts that seems allowed to log in. (This depends on the SSH and / or FTP config, depending on what you're trying to log into.) Use the most common passwords, but only do this if you're allowed to.

But your next step is to dive into the database if it uses that, as the credentials will have to be stored somewhere unless everyone is allowed to connect. If you're lucky, the application runs as root and you can use load_file() or INTO OUTFILE and other commands on the system. (I assume it's a MySQL database in this case.)

Look for vulnerabilities in all services running, both those that have networking enabled, but also those that runs in local sockets, and so forth. Kernel vulnerabilities are often the first thing script kiddies and blackhats try to exploit if the application is configured correct. If you need to compile a binary, but can't on the target system, compile it on your own identical operating system and upload it to the target host. If only a perl script is available for a particular vulnerability, convert it manually to e.g. python in case perl is not available. (Or use a wrapper in case that's available.)

That's pretty much some of the best advice I can give, but if you got remote code execution you can inject backdoors into the web application and perform man in the middle attacks, serve malware from their domain, and much more, so compromising the web application alone and getting remote code execution is pretty serious already. 

FYI - Hot off the press http://www.exploit-db.com/exploits/19033/