Ataques por SQLInjection, un clásico

Afortunadamente, cada vez es más difícil encontrar una web vulnerable a un ataque por SQLInjection, en realidad solo es cuestión de aplicar buenas prácticas en el desarrollo. Algo tan sencillo como hacer convenientemente un parseo previo de los datos introducidos en nuestra web, nos puede evitar sobresaltos por ataques como SQLInjection o XSS, por ejemplo.

Aunque por lo general, protegerse ante este tipo de ataques es una práctica habitual, como tan habitual es protegerse ante un fallo inesperado de tu programa, sencillamente con instrucciones Try/Catch, por ejemplo, la verdad es que aún podemos encontrar "descuidos". Estos descuidos son muy fáciles de corregir, pero de no hacerlo a tiempo, si los "señores del sombrero negro" lo descubren, a buen seguro lo van a aprovechar, o sencillamente se van a divertir borrando o manipulando nuestros datos.

De vez en cuando, navegando por la red, cuando accedo a un formulario de Usuario/Contraseña, suelo tener la tentación de comprobar si han sido cuidadosos o no, con la diferencia de que cuando lo encuentro; yo, que soy un caballero :-); aviso de la desprotección.

Por lo general, cuando un formulario de Usuario/Contraseña está un poco descuidado de aspecto, es probable que también esté descuidado en protección.

Algo tan sencillo como introducir una comilla [ ' ] en el campo del Usuario y si al Aceptar tenemos algo así como:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Comilla no cerrada antes de la cadena de caracteres '' AND CLAVE=''.

/xxxx/yyy/login.asp, línea zz

estamos ante uno de estos "descuidos". Ya solo es cuestión de seguir poco a poco para "colarse hasta la cocina". 

En realidad, todo se basa en hacer fallar el procesamiento del formulario y que la información de fallo que nos muestre, nos vaya dando pistas acerca de nombre de tabla, nombres de campos o los propios datos en sí.

No hace falta buscar con demasiado ahínco en la red, para encontrar auténticos manuales de como hacer un SQLInjection. Con esto y unos conocimientos básicos de SQL, en muchos casos es suficiente para colarse en una web, modificar datos o directamente borrarlos, dependiendo de "la mala leche" del que lo encuentre.

No pretendo hacer apología del SQLInjection, ni mucho menos. Cualquiera que tenga el más mínimo interés en el tema, encontrará en la red, información más detallada y precisa de lo que yo pueda mostrar, a modo de ilustración, en este post.  

Como indicaba anteriormente, el proceso consiste en ir provocando sucesivos fallos en cada paso, de forma que cada uno, nos aporte información adicional a usar en los pasos sucesivos.

Veamos un ejemplo:

Para empezar, un primer dato...

Introduciendo como Usuario:  ' HAVING 1=1 -- , el error que se nos muestra, es la punta del ovillo que estábamos buscando:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.IDCLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado y no hay cláusula GROUP BY. 

ya tenemos dos datos, el nombre de la tabla y el primero de sus campos. Ahora a por los siguientes...

Introduciendo como Usuario:  ' GROUP BY CLIENTES.IDCLIENTE HAVING 1=1-- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]La columna 'CLIENTES.NOMBRECLIENTE' de la lista de selección no es válida, porque no está contenida en una función de agregado ni en la cláusula GROUP BY.

... y así campo por campo hasta conocer la estructura de toda la tabla.

El siguiente paso es hacer fallar el sistema en la conversión de un tipo de dato, para que nos muestre el valor del dato que no se puede convertir.

Introduciendo como Usuario: ' AND CLIENTES.IDCLIENTE IN (SELECT TOP 1 CLIENTES.NOMBRECLIENTE FROM CLIENTES WHERE CLIENTES.NOMBRECLIENTE LIKE '%A%') -- , tenemos el siguiente dato:

[Microsoft][ODBC SQL Server Driver][SQL Server]Error de sintaxis al convertir el valor varchar 'Mi Nombre de Cliente' para una columna de tipo de datos int.

Este es solamente un ejemplo; que por prudencia no he querido mostrar completo, para ilustrar lo simple que puede ser acceder a unos datos en una web vulnerable a este tipo de ataque. 

Como se puede ver, no hace falta ser un avezado hacker, para realizar este tipo de intrusiones, aunque evidentemente, no todos los casos son tan sencillos como este.

En casa de herrero, cuchillo de palo

Últimamente se ve con demasiada frecuencia que empresas de seguridad son atacadas o tienen algún tipo de problema relacionado, precisamente, con la seguridad.

Hay otros casos, como el de McAfee, en los que teniendo problemas de seguridad y siendo conscientes de ello, hacen oídos sordos incluso cuando desde fuera de la organización, se les advierte de tales carencias.

Un grupo de “hackers éticos” denominado YGN Ethical Hacker Group, descubrió que la algunos sitios web de McAfee presentaba algunas vulnerabilidades y que estas podrían ser explotadas a través de ataques del tipo XSS (Cross-site scripting), utilizados habitualmente en phising e inyección de código de scripting como javascript, VBScript, PHP,etc.

YGN advirtió a McAfee de tales vulnerabilidades el 10 de febrero y dos días más tarde McAfee respondió diciendo que ya conocían el problema y que estaban trabajando el ello para resolver la incidencia lo antes posible, pero el día 27 de marzo, mes y medio después, una nueva comprobación de YGN demuestra que aún no han sido solucionados dichos problemas. El mismo día 27, YGN decide publicar la información acerca de las vulnerabilidades descubiertas. Que descuido!.

La vulnerabilidad podría haber sido usada, entre otros en download.mcafee.com, para provocar que sus usuarios se descargaran, por ejemplo, una demo o una beta de sus productos infectada, evidentemente desde otro sitio y sin saberlo.

La compañía ha respondido diciendo que estas vulnerabilidades no exponen información alguna de clientes, partners o de la misma compañía, que por supuesto no afecta a sus productos de seguridad y que además, tampoco han observado que se hayan explotado estas vulnerabilidades. Quizá piensen que así sus clientes se quedan más tranquilos!.

McAfee ya tuvo problemas de este tipo en el pasado, en 2008, 2009 y 2010, pero parece que no han aprendido la lección.

Lo que realmente me llama la atención, no es que tengan este tipo de vulnerabilidades, que cualquiera las puede tener, sino que después de ser notificados, no hayan hecho nada al respecto, sobre todo sabiendo que si no se corrige, la información se va a hacer pública y eso cuando menos, no es beneficioso para su imagen.

Si McAfee tiene un servicio orientado a empresas, que se dedica a identificar problemas de seguridad en sus sites, solo se me ocurre un corolario para el post: En casa de herrero, cuchillo de palo.