Ya han sido varias las vulnerabilidades que han afectado a este sistema, como pueden ver en Secureless, se han reportado vulnerabilidades correspondientes a redirección de URL abierta, es decir, el usuario podía ser redireccionado a cualquier URL externa sin su autorización y otras del tipo Cross-Site Scripting, que permite al atacante incrustar código html/javascript arbitrariamente y aprovecharse de la confianza que el usuario tiene sobre el sitio para robar información, suplantar su identidad mediante el robo de cookies o bien incrustando un formulario falso para que el usuario entregue sus datos de autentificación (rut, password) al atacante.

Esta es una demostración de que tener un sitio con SSL o HTTPS no significa que sea “seguro”.

DISCLAIMER: Antes que todo, me gustaría aclarar los motivos de hacer pública esta demostración. Hace varios meses intenté reportar la vulnerabilidad de Redirección de URL que afectaba al momento de iniciar sesión pero no obtuve respuesta y luego de haberla hecho publica, apareció solucionada. La última vulnerabilidad XSS que encontré logré reportarla al encargado de seguridad de la institución (gracias a un contacto que no tenía antes), la respuesta que obtuve fue:

Escalé al Area de Mantención , para que mitigue la vulnerabilidad, te enviaré e-mail cuando esté mitigada.

Muchas gracias por la información

1 mes despues de este correo, no he recibido ninguna notificación. Luego de haber dicho lo siguiente, hace 3 dias:

La vulnerabilidad apareció corregida.

Esta vez avisaré a los responsables pero no esperaré a que lo solucionen para hacer público este artículo. Creo que los usuarios del Servicio de Impuestos Internos debe conocer los riesgos de realizar trámites online con una plataforma que no brinda la suficiente seguridad.

Y dice así …

Las nuevas vulnerabilidades descubiertas son 2 que van de la mano, son explotables en conjunto y en un sistema como el del S.I.I puede ser bastante peligroso para los usuarios. Se trata de una vulnerabilidad Cross-Site Scripting (XSS) y otra Cross-Site Request Forgery (CSRF). Explotando estas dos vulnerabilidades, la víctima puede ser redireccionada desde cualquier sitio hacia el sitio del S.I.I y obligarla a ejecutar código javascript en su navegador, permitiendo enviar los datos de sesión a un servidor remoto. En un ataque un poco más elaborado el atacante podría obligar al usuario a ejecutar acciones sobre el sistema afectado.

La URL afectada corresponde a https://alerce.sii.cl/dior_cgi/ren_mp/REN_CalculosAcciones.cgi, como pueden ver se trata de un sitio con “https”. Este script cgi recibe mediante POST 3 variables, las cuales pueden ser modificadas mediante un formulario falso. Al no tener tokens de seguridad (csrf tokens), el sistema permite realizar request desde sitios remotos, permitiendo al atacante forzar al usuario a realizar un POST (envío de formulario) desde cualquier sitio externo y obligandolo a ejecutar cualquier código javascript, como por ejemplo acceder a la información de la cookie y enviarla a cualquier servidor.

Para explotar esta vulnerabilidad, no es necesario que la víctima tenga la sesión iniciada, pero es mucho más peligrosa si es que lo está.

Por ejemplo, si nuestra víctima no tiene la sesión iniciada, la información de la cookie aparecerá en blanco

Sin embargo, si la víctima ya ha iniciado sesión, la información que podríamos obtener sería:

Podemos ver la información de la sesión (cookie) y lo que aparece borroso corresponde a mi RUT.

Esta información puede ser enviada a un servidor remoto y ser usada por el atacante para clonar la cookie y suplantar la identidad del usuario. Un uso un poco menos ofensivo, sería que el atacante quiera recopilar información sobre la víctima (por ejemplo en un ataque dirigido), mediante este ataque se puede obtener fácilmente información sobre algun usuario.

Para esta prueba de concepto lo único que utilicé fue un formulario html básico, que envía el request mediante POST a la URL afectada:

En el campo “opcion” va el código malicioso, en este caso un simple “alert(document.cookie)” que nos muestra una alerta con la información de la cookie, pero el atacante podría incrustar código html con un iframe externo, o bien enviar request GET o POST a sitios remotos pasando como parámetros la información de la cookie u algún otro dato relevant del usuario logueado.

El ataque se automatiza haciendo que todos los campos sean del tipo “hidden” (ocultos) y que al momento de cargar el sitio, automáticamente se haga un submit del formulario, sin que el usuario se entere. De esta forma, el robo de información mediante un sitio remoto es transparente para el usuario.

ACTUALIZADO: (20 de Febrero 15:30hrs)

La vulnerabilidad Cross-Site Scripting ya ha sido corregida. La falta de uso de CSRF Tokens en los formularios aún afecta al sistema, permitiendo enviar request remotas (CSRF), pero con el XSS parcheado la vulnerabilidad ya no es tan peligrosa.