Cómo lidiar con el Errcode 13 de MySQL cuando se intenta escribir un shell

4

Mi máquina de ataque ejecuta Kali y el servidor ejecuta CentOS 6.4 con DVWA.

Estoy tratando de escribir un shell a través de una inyección SQL. La carga útil es

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

Al enviar me aparece el siguiente error:

  

No se puede crear / escribir en el archivo 'var / www / html / dvwa / shell.php' (Errcode13)

La búsqueda del problema parece ser un problema de privilegios o SELinux. He observado que si cambio el destino a './shell.php' , el archivo se guarda en el servidor en /var/lib/mysql , cuyo propietario es mysql (el propietario de /var/www/html/* es apache ).

Suponiendo que este es un servidor remoto al que no tengo acceso, ¿cómo podría manejar esta situación para escribir correctamente el shell en /var/www/html/dvwa/ ?

    
pregunta yzT 29.06.2013 - 19:53
fuente

2 respuestas

3

Este error se produce porque MySQL no tiene privilegios de escritura en este directorio: /var/www/html/dvwa/ .

La mayoría de las distribuciones modernas de Linux usan AppArmor o SELinux para aislar los procesos del demonio. Es probable que /var/www/ no pueda escribirse con MySQL. Sin embargo, es posible que MySQL pueda leer desde este directorio. Esta declaración es válida para los conjuntos de reglas de AppArmor de Ubuntu en el momento de esta publicación.

Pasé por alto esta limitación en Ubuntu al escribir mi carga útil de PHP en /tmp , y luego usé una vulnerabilidad de inclusión de archivo local para ejecutar la carga útil. Esto me permitió escribir un hazaña de ejecución remota de código para PHP-Nuke .

    
respondido por el rook 30.06.2013 - 03:28
fuente
0

Idealmente (si usted es el administrador del servidor) las ubicaciones de archivos accesibles por MySQL en comparación con aquellas a las que Apache y PHP pueden acceder no se intersectan. Por lo general, todos pueden acceder a /tmp , pero un sistema bien diseñado utilizará directorios temporales separados para cada servicio que niegue explícitamente el acceso a /tmp .

En otras palabras, idealmente, una explotación de este tipo es imposible (eso es lo que "idealmente significa"), pero en la práctica encuentras un agujero, algo de supervisión, que te permite atravesar. Es posible que esto deba hacerse sistema por sistema.

    
respondido por el tylerl 30.06.2013 - 22:42
fuente

Lea otras preguntas en las etiquetas