Así es, pareciera ser que los errores de programación (bug) que dejan expuestos a los usuarios mediante vulnerabilidades Cross-Site Scripting (XSS) estan de moda, es increible ver la cantidad de sistemas de todo tipo que tienen este tipo de vulnerabilidad. Desde un simple sitio web de noticias hasta un sistema bancario. La unica explicación que puedo encontrar es que al tratarse de una vulnerabilidad que afecta a los usuarios y no a las empresas, le bajan el perfil y no se preocupan en corregirla cuando son reportadas. Que sepan tu contraseña, que cambien tu información, que sepan información privada tuya o que puedan acceder a tu cuenta sin tu permisos solamente te afecta a ti, el dueño del sitio se puede lavar las manos.
La mayoría de los XSS se producen en buscadores y en mensajes de error.
Buscar"xss"
Parece que fuese una moda de las tiendas de computación el ser vulnerable a XSS. Conocimos el caso de WEI y de SYM, ahora es el turno de PCFactory.
Cuando descubrí el bug tenian una versión más antigua del sitio web, sin embargo, luego que la actualizaran a la version actual, me di cuenta que la misma url seguia funcionando con el mismo bug, es decir, sólo fue un cambio en el estilo visual del sitio web, no fue ninguna mejora en cuanto a lógica y código.
Para variar, el bug se encuentra en el buscador, donde nos da la autoridad para inyectar código html y código javascript para ser ejecutado en el navegador del cliente:
Hace un par de semanas reporté publicamente la existencia de una vulnerabilidad XSS y posible SQL Injection en el sitio web de SYM, https://www.sym.cl. Recibí una estupida respuesta por parte de una persona que se hace llamar “MadBox”, quien decia textualmente:
el sitio de sym es vulnerable a todo a proposito y les encuentro razón mi casa tiene las puertas abiertas pero si robas pagas.
En fín … Unos dias despues, se contacto conmigo Rodolfo Berrios, diseñador y encargado del sitio web, consultandome por las vulnerabilidades encontradas. Cuando intenté reproducir la vulnerabilidad XSS me encontré con la sorpresa de que ya estaba corregida! Sin embargo, no se corrigió del todo, ya que si bien no me dejaba inyectar código JavaScript, si me dejaba inyectar html
Tras el post anterior, la empresa afectada se ha comunicado conmigo vía correo electrónico agradeciendo y comunicando que solucionarán el problema lo antes posible
Estimado Fernando:
Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones, para comentarle algunos de los alcances que ha tenido para nosotros el reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada. Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.
Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.
Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.
Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.
El sitio web de WEI (una tienda de productos informáticos) presenta una vulnerabilidad XSS en su buscador, ésto podría permitir el robo de identidad y acceso a información confidencial de sus clientes.
La URL vulnerable es
https://www.wei.cl/catalogue/product_search.htm?ph=&query=
Podemos inyectar código javascript en el valor de la variable “ph” y con esto insertar un frame o algun elemento externo al sitio y hacelo parecer como si fuera del sitio usando la confianza que tienen los clientes, como por ejemplo un iframe o bien un javascript que nos envie la cookie de la sesion a otro sitio.
Prueba de Concepto (PoC)
En el sitio se pueden encontrar links de contacto y emails para escribir tipo info@wei.cl, ni los links ni los emails funcionan. Intenté reportar el problema pero el correo que envié al destinatario que en la misma página aparece, me rebotó.
Para complementar un poco lo que publicó d3m4s1@d0v1v0 en ITFreekZone sobre el Reflected XSS mediante SQL Injection, me gustaría demostrarles otra manera de realizar Cross-Site Scripting aprovechandose de una vulnerabilidad de inyección SQL.
La teoría es muy sencilla, basta con que encontremos un sitio vulnerable a inyección SQL, no importa que tenga protecciónes contra comillas simples o dobles, o similar, basta con que podamos generar un error por lado del servidor por ejemplo cambiando un número (id) por una letra (en el caso de oracle, sql server u otros que tengan problemas de compatibilidad por el tipo de dato pasado), agregas signos raros o una comilla obligando a que el servidor arroje un error de sintáxis, lo que vamos a hacer es insertar código javascript justo donde se genera el error sql.
© 2024 El rincón de Zerial
Tema por Anders Norén — Subir ↑
Comentarios recientes