¿Puede la inyección de SQL conducir a la ejecución remota de código?

Los sistemas de bases de datos SQL normalmente tienen un mecanismo de exportación que puede escribir archivos arbitrarios en el servidor, e. sol. SELECT ... INTO OUTFILE en MySQL. Si un atacante es capaz de ensamblar una consulta de este tipo y no es detenido por permisos restrictivos, de hecho puede crear scripts PHP. Ahora todavía necesitan que el servidor ejecute el script. En el caso más sencillo, tienen acceso de escritura a un directorio web. Si solicitan el script, el servidor web lo ejecutará con gusto.

Depende del tipo de base de datos (MySQL, Postgres, Oracle, etc.) y los privilegios del usuario de la base de datos.

Si la aplicación se conecta a la base de datos utilizando una cuenta de administrador, generalmente es posible la ejecución del código. Es sencillo en SQL Server, usando xp_cmdshell. Otras bases de datos requieren técnicas más involucradas. SQLmap , la herramienta de explotación de SQL más popular, menciona esto:

Support to execute arbitrary commands and retrieve their standard output 
on the database server underlying operating system when the database software 
is MySQL, PostgreSQL or Microsoft SQL Server.

Al menos para MySQL, creo que utiliza el truco de escribir en un archivo PHP mencionado por Fleche.

Desde el punto de vista de la defensa, esta es la razón por la que nunca debes tener tu aplicación conectada como administrador.

Además de las cosas ya mencionadas, algunas bases de datos se basan en el código; por ejemplo, la parte más grande de Oracle se escribe en oracle, es decir, PL / SQL, que se ejecuta dentro del servidor de la base de datos. Si recibe una inyección de SQL, puede hacer muy bien las cosas para alterar el estado del sistema, a veces más allá de lo que permite la cuenta de usuario de la base de datos, especialmente si tiene la oportunidad de combinarla con una escalada de privilegios locales.

Oracle, al menos, también permite ejecutar código Java ™ en el servidor de base de datos de forma predeterminada. Y tal vez un par de cosas más ...

PostgreSQL también es extensible. Puede ejecutar cosas como scripts Perl, no solo PL / pgSQL ...

Muchas aplicaciones no triviales almacenan objetos en la base de datos. Un atacante con acceso a la base de datos (como el obtenido por una inyección de SQL) podría modificarlos de tal manera que cuando estén sin ser serializados , ejecutan el código deseado.

Esto depende de la aplicación php para tener una clase con un __wakeup ()

(También vale la pena señalar el problema SELECT INTO OUTFILE señalado por Fleche, aunque los servidores * nix mysql generalmente se configuran con su propio usuario, y este ataque no es posible)

Otro posible vector de ataque sería si en algún punto el contenido de la base de datos se ejecuta como código.

Un ejemplo de pseudocódigo en PHP:

$dbstring = some_db_query('SELECT some_code from some_table ...');
eval( $dbstring );

Afortunadamente, tal cosa no sería común, pero si a los usuarios de confianza se les permitiera agregar código a una base de datos, la inyección de SQL podría sobrescribirlo con código malicioso.

Creo que el CMS Drupal tiene una característica para el contenido creado por usuarios de confianza (a menos que ya lo hayan eliminado).

Lo que su descripción sería muy posible si el sitio web ejecuta código PHP que se almacena en la base de datos y se ejecuta con eval (). La inyección SQL se usaría para modificar el contenido de PHP que se almacena en la tabla para que el código de los atacantes se ejecute en lugar del contenido original.

Otra posibilidad sería que un archivo remoto incluya un ataque en un nombre de archivo que se obtiene de la base de datos.

El servidor Microsoft SQL tiene un procedimiento almacenado llamado xp_cmdshell , que le permitirá ejecutar de forma arbitraria Aplicaciones de línea de comandos. Esto es comúnmente utilizado por los hackers para cargar puertas traseras o modificaciones de aplicaciones web a través de FTP.