Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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/?

share|improve this question
    
Try to find a public directory with write permissions for everyone. If users can upload images or files on that site, you may be able to write in the folder where they are stored. –  Zzz Jun 30 '13 at 6:09
add comment

2 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.