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.
Etiquetavulnerabilidades
Como desarrollador y administrador de sistemas, he tenido varias experiencias y se como funciona esto de la asignación de contraseñas y de accesos por defecto, ya sea cuando el sistema lo usaran unas cuantas personas o varias. Me refiero tanto a los sitemas web como accesos por distintos servicios tales como ssh, ftp, correos electrónicos, etc.
Generalmente los criterios para asignar accesos a los distintos sistemas es los mismos, existen las que son aleatorias con y sin patrones, las típicas “dos letras iniciales del apellido seguido del año de nacimiento”, etc. Quizá el problema no está en asignarles claves por defecto fáciles a los usuarios, sino en los mismos usuarios que no las cambian o bien tardan una eternidad en ingresar por primera vez al sistema. Por esto mismo, pienso que la seguridad de los sistemas no debe depende de los usuarios, debe depender del sistema, a menos que tengamos muy acotado el tipo de usuarios que tendrá el sistema.
En este post hablaré sobre los tipicos accesos a universidades, cuentas de correo de empresas, cuentas de servidores ftp, ssh, web, etc.
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.
Los ataques XSS son cada día más frecuentes, pareciera ser que al desarrollador no le interesa o por desconocimiento no sabe a lo que se está exponiendo, pero por otro lado, los desarrolladores de los navegadores si están concientes y desarrollan técnicas anti XSS. La forma más común de realizar un ataque XSS es insertando tags cómo parámetor de URL o bien dentro de un campo del formulario, como por ejemplo el conocido:
<script>alert(‘this.cookie’)</script>
Cuando los ataques XSS mediante tags no son posibles, existe la posibilidad de realizar el ataque usando las propiedades de cada tag. Puede ser usando el atributo style, src o algúnos gatilladores de eventos como onMouseOver, etc. Para poder realizar el ataque es necesario usar comillas (simples o dobles), aunque tambien en algunos casos existe la posibilidad de no usarlas, para poder agregar una nueva propiedad al tag en el cual hemos conseguido insertar el código.
El sitio de Eduardo Frei está hecho en Drupal, un CMS (o CMF) libre que podemos descargar y examinarlo, para saber cómo trabaja, directorio de módulos o plugins, themes, etc. Pero basta con leer el código fuente del sitio para saber la ubicación de éstos.
Vamos a probar con las típicas rutas de Drupal para iniciar sesión, administrar el sistema, directorios de archivos subidos, themes, etc. A ver si encontramos algo interesante que nos pueda entregar información.
Si vemos el código fuente podemos deducir los siguientes paths:
modules/ Los módulos core de Drupal
sites/all
sites/all/modules Los módulos instalados manualmente
sites/default Directorio donde están los archivos subidos, configuraciones, etc
Como ya anuncié hace un rato, empezaré con el sitio https://marco2010.cl.
Cuando comencé a escribir sobre éste sitio web, existía una vulnerabilidad de descubrimiento del path (Full Path Disclosure) junto a un SQL Injection y un XSS, dentro de un “plugin” hecho para las votaciones lo que luego fue corregido, no logré sacar screenshot y ejemplos para demostrarlo. Que hayan corregido éstos errores es un punto a favor para la seguridad del sitio. Vamos a ver hasta qué punto podemos poner a prueba la seguridad.
© 2024 El rincón de Zerial
Tema por Anders Norén — Subir ↑
Comentarios recientes