Estos últimos días he estado jugando con el comodín del %, un viejo conocido de las técnicas de SQL Injection, ya que permite utilizarse para buscar una cadena sustituyendo uno o varios caracteres por ese carácter de %. Este comodín solo se usa en comparaciones basadas en LIKE, por lo que en una búsqueda de una cadena "a%" debería ser para buscar cosas como "albaca", "alacena" o "administrador". Una utilidad fantástica en bases de datos relacionales y consultas SQL.
Curiosamente, jugando con las recuperaciones de contraseñas, me encontré con dos curiosidades en algunos sitios, que os quería compartir por aquí, y que afectó a una de nuestras webs internas, pero que me ha sorprendido ver lo común que es, y que os la dejo por aquí, ya que es un pequeño truco para hacer Hacking de Web Technologies.
Figura 2: Libro de Hacking Web Technologies en 0xWord de los autores: Amador Aparicio, Chema Alonso, Pablo González, Enrique Rando y Ricardo Martín. |
La primera es una curiosidad en el filtrado de datos de entrada en las direcciones de correo electrónico y los procesos de recuperación de contraseñas - que tienen que ver con lo que os publiqué ayer para recuperar una password con una dirección de e-mail que no es tuya. La segunda es ver cómo se puede utilizar ese comodín para extraer mediante enumeración todos los usuarios de una base de datos. Vamos a verlo.
Un comodín no filtrado en las direcciones de e-mail
Este es una curiosidad que me he encontrado en muchos filtros de protección frente a ataques de inyección, y se trata simplemente de que el carácter comodín está prohibido en los dominios de las direcciones de e-mail, pero no en los usuarios. Este es solo un ejemplo de los muchos donde, probando una dirección con % en el dominio da error el filtro, y en el usuario no lo da.
Tener un % como parte de un usuario, aunque se pueda utilizar en el Identity Provider que utilices, es una muy mala idea siempre, por ser un carácter reservado en otros motores, así que no debería poder suceder lo que aparece ahí.
Esto no es un fallo en sí mismo, pero sí una muy mala idea. La web de AirBnB, por ejemplo, permite utilizar ese carácter comodín en las direcciones durante el proceso de recuperación de la contraseña, lo que no parece una buena idea. De cualquier forma, insisto, no es un bug porque no permite usar ese carácter como un comodín, ya que aunque parece que existe la dirección lucas@gmail.com, no reconoce la dirección l%@gmail.com. Así que solo es eso, una pequeña mala idea.
Figura 6: El % no funciona como "comodín" porque lucas existe y l% no.
Sin embargo, te dice cuando una dirección de e-mail tiene cuenta (lucas)
y cuando una no "fasfas....." lo que es un "leak del login" en AirBnB.
Eso sí, el proceso de recuperación de contraseñas de AirBnB es "verbose" y tiene el "leak del login", ya que permite saber si la cuenta de e-mail está dada de alta o no en su base de datos, lo que permite saber si tú te has creado una cuenta su base de datos. Perfecta para nuestro proyecto de "Dirty Business Card".
El comodín % en el nombre de usuario como comodín
La curiosidad anterior es solo eso, una curiosidad - y para mí una pequeña debilidad -, pero lo peor es que se convierta en un bug de enumeración de usuarios, ya que, si ese % funciona como un comodín, la cosa es más peliaguda. Para ello solo hay que probar a ver si se puede saber si está funcionando o no con unas sencillas pruebas.
En la imagen anterior se puede ver que, introduciendo una dirección de e-mail sin poner ningún carácter % y que no existe en esta web, sale un mensaje de error que informa de que no hay ningún usuario con esa dirección de e-mail.
En la Figura 8 se puede ver que el carácter % no genera ningún error de formato en la dirección de e-mail, como sucedía en el caso anterior con la web de AirBnB. El comodín % pasa el filtro. Lo que no tenemos aún es la garantía de que funcione realmente como un comodín. Sin embargo, probando una dirección común de gmail comenzando por "a", vemos que da un mensaje correcto.
Esto quiere decir que el carácter % está funcionando. Hay algún correo que comienza por "a" y tiene el dominio @gmail.com. El resto es hacer un árbol de despliegue como en el ejemplo de Blind LDAP Injection, e ir desplegando las direcciones que dan positivo, en este caso... la segunda letra que funcionaba era la "l", así que existe alguna dirección comenzando por "al" en el dominio @gmail.com.
Figura 10: Se despliega el username carácter a carácter
(con el % en lugar del * que se usa en Blind LDAP Injection)
Esta situación es un tanto curiosa, ya que índica que el programador a utilizado una claúsula LIKE en la búsqueda y verificación de los usuarios o direcciones de e-mail completas, lo que no parece lo más correcto y seguro en ninguna aplicación.
Si estás haciendo tu propio sistema de gestión de usuarios, intenta no recrear procesos que son conocidos y estudiados ya hace muchos años, porque puedes acabar creando problemas de seguridad que se conocen desde hace veinte años.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
Para que narices un desarrollador utiliza el like a la hora de buscar en una consulta por algo que debería ser exacto y devolver sólo un registro.
ResponderEliminarQue se utilice en buscadores de "items/productos/artículos" lo veo normal, ¿pero a la hora de buscar un mail o un usuario?