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 usuari os 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 e s "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 gene ra 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 a ACCC4CF8.asc AptCmds bin cert2.sh certbot.log cert.sh cloudflare.dns config_winmgr dck dead.letter debug.log Descargas Documentos dups-g dups_google.txt dups-i dups_img-google.txt dups_imgs.txt duptype_results.txt error.log ErrorSubidas Escritorio etc eternal eternal_history feeds.txt Grabaciones grub.out history Imágenes index.html.1 index.html.2 ip linux_signing_key.pub Mail mbox mp3.sh Música oracle_vbox_2016.asc Plantillas pos t pre Público Restore_Debian.sh root.war shellinabox Shotwell Import Log.txt sources.list speedtest-cli Steam subefl.log sw.txt T-ContentTmp1 Team Drives tg thinclient_drives ttrss-20181011.opml TwitterAPI.txt usr Vídeos VirtualBox VMs vlc-log.txt Webcam_Pictures 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)
☞ El artículo completo original de noreply@blogger.com (Chema Alonso) lo puedes ver aquí



No hay comentarios.:
Publicar un comentario