Se han descubierto diversas vulnerabilidades que afectan al sistema web para seguimiento y control de PMG de Seguridad de la Información. Estas vulnerabilidades ponen en riesgo la confidencialidad de la información que se administra.

DISCLAIMER: La vulnerabilidad ha sido reportada al CSIRT del Ministerio del Interior, quienes han realizado las gestiones necesarias y han solicitado la baja del sistema mientras se investiga y solucionan los problemas detectados.

El Gobierno de Chile cuenta con varios programas de mejormiento de la gestión los cuales sirven de apoyo para las instituciones públicas. Estos programas de mejoramiento a la gestión se conocen como “PMG“.  Desde el punto de vista de seguridad, existe un Sistema de Seguridad de la Información, cuyo objetivo es contar con un sistema de gestión de seguridad de la información que permita lograr niveles adecuados de integridad, confidencialidad y disponibilidad para todos los activos de información institucional considerados relevantes, de manera tal que se asegure la continuidad operacional de los procesos institucionales y la entrega de productos y servicios a los usuarios / clientes / beneficiarios.

Con el fin de dar apoyo al cumplimiento de este PMG, se ha desarrollado, bajo la modalidad de “software publico”, un sistema web que permite realizar un seguimiento e informar acerca del cumplimiento. Este sistema se encuentra publicado abiertamente en un repositorio Github.

En el siguiente artículo, se detalla un análisis al código fuente realizado a este sistema.

El sistema es accesible desde http://ssi.digital.gob.cl y el código fuente se puede ver en https://github.com/e-gob/pmg-seguridad junto a otros recursos.

En primer lugar, según se puede ver en el README, está desarrollado en Laravel

Por lo tanto, iremos directo al directorio app/. Se puede ver que el último commit se realizó el 5 de enero de 2018

De acuerdo al funcionamiento del sistema, al ingresar a la URL nos pide inmediatamente inicia sesión con nuestra Clave Única. Probé ingresar com mis credenciales, sin embaro, no fiue posible. Esto me hace pensar que tienen algún tipo de perfilamiento para poder ingresar. En el archivo controllers/ClaveUnicaController.php podemos ver la lógica de la autenticación.

Primero, la implementación de Clave Única:

Segundo, la autorización del usuario previa autenticación contra Clave Única:

En simples palabras, en las lineas, el sistema va a consultar información del usuario  en una base de datos propia, previamente autenticado con Clave Única. Si la información existe, entonces se configuran los parametros de sesión y posteriormente se redirecciona a “historial”. De lo contrario, se redirecciona a la raíz, mostrando nuevamente el login. Por lo tanto, si tenemos Clave Única, pero no existimos en su base de datos propia, no podemos acceder.

Dado el análisis realizado, podemos decudi que toda la información existente dentro del sistema es de caracter privado, ya que requiere cierto tipo de autorización o enrolamiento previo para poder acceder.

El siguiente paso es conocer como funciona el sistema, para esto analizaremos el resto del código fuente.

Para entender la lógica del sistema, logré determinar un patrón de búsqueda que me permita identicar los perfiles existente. Para esto, hice una búsqueda por “Auth::user()->perfil===“, ya que es la validación utilizada para verificar si el usuario autenticado corresponde a un perfil.

De acuerdo a esta información, se puede determinar la existencia de los siguientes perfiles:

• validador
• experto
• evaluador

Existen funcionalidades que identifican el perfil y/o sesión del usuario antes de ejecutar cualquier acción, pero tambien existen funcionalidades que no son verificadas de forma correcta, permitiendo que cualquier usuario pueda acceder.

Para encontrar estas funcionalidades vulnerables, vamos a centrarnos en dos aspectos importantes:

1. Buscar archivos que puedan ser accedidos de forma directa.
2. Buscar archivos que puedan ser accedidos mediante un controlador (indirectamente).

Según el archivo controllers/RiesgoController.php, existe un directorio llamado “uploads”

Sería un error que el directorio “uploads” se encontrara dentro del directorio público, ya que cualquier persona podría acceder saltandose la capa de la aplicación .. Pero asi es! Es posible acceder a uploads directamente dede la URL, como por ejemplo: http://ssi.digital.gob.cl/uploads/[…]. Esto es posible verlo gracias al .gitignore.

Ahora buscaremos los directorios que se encuentren dentro de uploads/.

En este archivo se puede ver la existencia de uploads/documentos/ y en la que sigue, uploads/cierre y uploads/riesgos.

Como pueden ver, en cada llamada a este directorio, se concatena con el valor de “Auth::user()->institucion_id“, por lo tanto, es posible acceder a los archivos desde URLs como por ejemplo

• http://ssi.digital.gob.cl/uploads/cierre/certificado-cierre-XXX.pdf

Para comprobarlo, ingresamos un ID cualquiera, por ejemplo 33

Tambien podemos ver el mismo problema para el directorio “uploads/reportes/reporte-red-XXX.pdf”

Probando con otro ID, podemos ver información acerca de los controles y análisis de riesgo.

Como se puede ver, en este archivo se ve información sensible, ya que es posible conocer que debilidades o falencias en temas de seguridad tienen las instituciones.

Podemos iterar el ID de institución hasta descargar todos los archivos, sin embargo, el código tiene una sorpresa para nosotros ¡en ZIP, todos juntos!

Para finalizar, los archivos XLS que se pueden descargar vienen “protegidos” para no poder editados, sin embargo, todo indica que los archivos son protegidos con la misma contraseña la cual se encuentra codificada en duro en el código fuente. De acuerdo al archivo controllers/InstitucionController.php:

Luego podemos comprobar que este mismo mecanismo de “protección” lo aplican a otros documentos

Como se puede ver en el código, para crear las planillas utilizan “PHPExcel” y para configurar una clave de protección realizan una llamada a setPassword(). De acuerdo a PHPExcel, el argumento que se entrega a setPassword() corresponde a un String, el cual es utilizado para configurar la clave. A simple vista podría parecer un hash MD5, sin embago, es exactamente esa la clave que tienen los archivos.

El sistema ha sido dado de baja temporalmente y se está trabajando en mitigar las vulnerabilidades reportadas.

Espero que este tipo de publicaciones no los haga tomar la decisión incorrecta de “esconder” el código y quitarlo de Github o de cualquier reposiorio, ya que son estas instancias las que permiten que la comunidad “audite” de cierta forma los sistemas y de esta manera poder contribuir.

Por último, si la información está catalogada como sensible o confidencial, se recomienda realizar una revisión que permita determinar si hay mas personas que hayan descargado esta información.