domingo, 13 de junio de 2010

XSS en DragonJAR

¿Qué es DragonJAR? Cómo dice en su sitio web (www.dragonjar.org):

"DragonJAR.org es una comunidad de investigadores, estudiantes, profesionales y entusiastas de la Seguridad Informática..."

Personalmente considero que es uno de los mejores sitios web de seguridad informática en español. Tanto así que esta en mis marcadores y la reviso periódicamente sobre todo para leer noticias sobre seguridad.

Hace ya mucho tiempo me cree una cuenta el el foro de DragonJAR sin embargo no había participado activamente hasta hace unos días. Entonces creí conveniente arreglar un poco mi perfil y fue así que mientras editaba mi firma encontré accidentalmente una vulnerabilidad XSS en el foro.
Sucede que trataba de incluir en mi firma mi dirección de correo con el formato que se usa en el protocolo SMTP es decir entre los signos "<" y ">". Algo así:

Alguien <csaralg@gmail.com>
http://alguienenlafisi.blogspot.com
Root-Node

Pero cuando le di a previsualizar mi dirección de correo no aparecía. Se me ocurrió revisar el código fuente y encontré esto:

<csaralg@gmail.com></csaralg@gmail.com>

Entendí entonces que mi correo había sido interpretado como una etiqueta HTML e incluso ¡se había autocompletado la etiqueta de cierre! Inmediatamente una perversa idea abordo mi cabeza y aunque incrédulo comencé a escribir el script en mi firma.

<script>alert('xss');</script>

Otro clic en previsualizar y un par de segundos después ahí estaba, en medio de la pantalla, desafiando mi escepticismo la alerta mas temida de todas.


Bueno, tal vez exagero un poquito... pero estaba emocionado, no todos los días encuentras un XSS en un foro como DragonJAR y no es un XSS cualquiera sino que es persistente, uno de los mas peligrosos. Solo para que entiendan la gravedad de este bug imaginen que en lugar del mensaje de alerta pongo un script que obtenga la cookie de sesión del usuario que visite un post infectado y que la envie a un servidor externo donde yo la pueda ver. Luego puedo usar las cookies para acceder al foro como si fuera otro usuario y si la cookie es de un administrador accedería con todos sus privilegios. Otra forma de explotar el XSS es crear un gusano al mismo estilo de Samy Kamkar y su gusano para MySpace, en este caso cuando un usuario visite un post infectado automáticamente incrementaría mis puntos de reputación, me daría las gracias y se infectaría con el gusano. También se podrían incluir scripts que exploten vulnerabilidades del navegador como el ie_aurora para controlar la PC del usuario. Otras opciones son hacer redirecciones quizá buscando hacer phishing o infectar al usuario con un virus y en el caso menos creativo provocar un DoS y colgar la PC del usuario.

Sí, todo eso se puede hacer, con mas o menos complicaciones pero la posibilidad existe... o bueno, existía. Y es que... en el fondo tengo mi corazoncito white hat, además los administradores del foro son muy capaces y no tardarían mucho en darse cuenta que algo raro pasa. Por eso decidí reportar el error inmediatamente para que fuese corregido y así fue.

El error se debía a que estaba habilitado usar HTML para dar formato a la firma y no se filtraban las etiquetas <script>. Fue un simple error de configuración, no implicaba mayores problemas en el CMS del foro. A la fecha el error ya está corregido, se deshabilitó el HTML en la firma y se agrego mas seguridad implementando CAPTCHAs para disminuir el impacto de posibles ataques XSS/CSRF automatizados como el gusano del que les hablaba.

Como recuerdo de ese día tengo un vídeo que dejo aquí:



Bueno, eso es todo por hoy. Hasta pronto. Saludos.

martes, 1 de junio de 2010

Nueva solucion al error del SCU

Hola, ya habiamos hablado en los post anteriores sobre un error en el portal del SCU (Sistema de Control de Usuarios (de la biblioteca)) que permitia que cualquier usuario que haya iniciado sesion pueda consultar y modificar los datos de cualquier otro usuario. Vease:

http://alguienenlafisi.blogspot.com/2010/04/el-cambio-de-sexo-de-salomon.html

Tambien se comentó la eficaz "solucion" que puso el equipo de informatica de la biblioteca una semana despues de reportado el error. Vease:

http://alguienenlafisi.blogspot.com/2010/05/error-en-el-scu-corregido.html

Pero hace un tiempo volvieron a activar el sistema y el error seguia presente. Sin embargo hoy revise nuevamente el portal y me di con la sorpresa de que habian adoptado una nueva solucion y quize comentarla en el blog.

La solucion consiste en encriptar el codigo de usuario cuando se lo envia en la consulta. Es decir si antes en la URL aparecía:

/scu/Usuarios/ResultadosCon.asp?cor=08200090

Ahora aparece algo asi:

/scu/Usuarios/ResultadosCon.asp?cor=A55E33BE219A8420

Entonces si queremos consultar los datos de Salomon primero debemos encriptar su codigo (08200111) y luego reemplazar el criptograma en la variable "cor". Pero como desconocemos el algoritmo de encriptacion que se esta usando no podemos encriptar nada ni consultar los datos de nadie.

Este es un caso de seguridad por oscuridad. Es decir mientras nadie sepa como se esta encriptando el codigo podemos estar tranquilos. Pero si alguien se pone a recolectar datos y a analizarlos podria llegar a romper la encriptacion y el problema aparecera nuevamente. Con esto quiero decir que aun no se ha arreglado el problema en si pero su explotacion se ha vuelto mas complicada.

Bien, el reto criptografico del SCU queda propuesto. No parece muy complicado pero voy a dejar eso para otro post ahora estamos a una semana de los parciales y no queda mucho tiempo para "webear" :P

Es todo por ahora, hasta la proxima. Saludos.