How to deal with MySQL's Errcode 13 when trying to write a shell

Question

My attack machine is running Kali and the server is running CentOS 6.4 with DVWA.

I'm trying to write a shell through an SQL injection. The payload is

' UNION SELECT '', '<?PHP system($_GET["cmd"]); ?>' INTO OUTFILE '/var/www/html/dvwa/shell.php';#

When submitting I get the following error:

Can't create/write to file 'var/www/html/dvwa/shell.php' (Errcode13)

Searching the problem seems to be either privileges issue or SELinux. I have noticed that if I change the destination to './shell.php', the file is saved in the server on /var/lib/mysql, whose owner is mysql (the owner of /var/www/html/* is apache).

Assuming this is a remote server which I don't have access, how could I deal with this situation for successfully write the shell to /var/www/html/dvwa/?

Answer 1

This error is happening because MySQL does not have write privileges to this directory: /var/www/html/dvwa/.

Most modern Linux distributions use AppArmor or SELinux to isolate daemon processes. It is likely that /var/www/ cannot be written to with MySQL. However, it maybe possible for MySQL to read from this directory. This statement holds true for Ubuntu's AppArmor rule-sets at the time of this post.

I bypassed this limitation under Ubuntu by writing my PHP payload to /tmp, and then used a Local File Include vulnerability to execute the payload. This enabled me to write a remote code execution exploit for PHP-Nuke.

Answer 2

Ideally (if you're the server administrator) the file locations accessible by MySQL versus those accessible by Apache and PHP do not intersect. Typically /tmp is accessible to all, but a well-designed system will use separate temporary directories for every service explicitly deny access to /tmp.

In other words, ideally such an exploit is impossible (that's what "ideally" means), but in practice you find some hole, some oversight, that allows you to get through. This may have to be done on a system-by-system basis.