Atacando sistemas legacy: FONASA y SAG

gobcl-data-leak

Los sistemas legado o legacy siempre son un dolor de cabeza, más aún cuando se trata de seguridad. Por lo general, este tipo de sistemas fueron desarrollados hace más de 5 años y no Sitienen ningún tipo de soporte. El problema es que los siguen utilizando, incluso para el manejo de información sensible y confidencial. Cuando estos sistemas estan publicados en internet, sin ningun tipo de protección ni filtro, el riesgo de sufrir un ataque es aún mayor.
Utilizando simplemente los motores de búsqueda, en chile se pueden enumerar cientos de sistemas legacy a nivel de gobierno, incluso algunos que ya han sido intervenidos y los encargados no se han dado cuenta. Una mala práctica muy común es restaurar los sistemas y bases de datos una vez que fueron intervenidos y “hackeados“, pero no se realiza ningún tipo de análisis de intrusión para determinar el impacto del ataque; simplemente los restauran. ¿Cual es el problema? Que los restauran con los mismos bugs incluso con el mismo backdoor que se utilizo para el ataque.

oldcomputer674

El gobierno ha puesto en marcha desde hace varios meses una especie de programa de reporte responsable de vulnerabilidades, orientado a que newbies, scriptkiddiez, lammers, investigadores, hackers y toda la especie existente, puedan reportar a un punto único.  En lo personal llevo varios años reportando incidentes o vulnerabilidades, sin ánimos de lucro y sólo con el fin de colaborar, pero el problema es que es como el SERNAC: No tiene facultades. Frente a una institución afectada, ellos no pueden hacer nada para obligarlos a responder correctamente los incidentes, entonces yo me pregunto… Si no existe una “respuesta responsable” por parte de los afectados, tiene sentido que exista el “reporte responsable“? Yo creo que cada uno tiene su opinión. Por mi lado, siempre intentaré avisar y enviar todos los antecedentes necesarios antes de realizar una publicación.

En esta ocasión, pondré como ejemplo dos instituciones públicas conocidas por todos, el Servicio Agrícola y Ganadero (SAG) y el Fondo Nacional de Salud (FONASA). La idea de este post no es publicar las vulnerabilidades ni mucho menos la información que se puede obtener una vez que son explotadas, mas que dar a conocer el impacto real de un ataque que a una persona con poca experiencia podría tomarle simplemente 5 minutos.

La forma de detectar las vulnerabilidades para ambas instituciones son similares:

  1. Se selecciona el objetivo (en este caso SAG y FONASA).
  2. Enumeración de subdominios (AXFR, fuerza bruta, motores de busqueda, etc).
  3. Enumeración e identificación de sistemas web.
  4. Se selecciona uno al azar de todos los que parezcan “vulnerables” y “antiguos”.
  5. Se identifican los posible puntos vulnerables (login, sistemas de administración, carga y descarga de archivos)
  6. Prueba de Concepto

Estas tareas pueden ser realizadas en 5 minutos, una vez descubierta y verificada la vulnerabilidad, solo basta que alguien con imaginación pueda utilizarla indebidamente y acceder a datos que supuestamente son confidenciales y estan protegidos por la institución.

Servicio Agrícola y Ganadero (SAG) – HTTP Form Login SQL Injection

El sistema se llama SISVEG y se accede mediante la URL sisveg.sag.gob.cl. Al ingresar, vemos la pantalla de login

sisveg_01Los parametros “txt_clave” y “txt_rut” son enviados mediante POST para realizar la autenticación del usuario. En el campo “Nombre de usuario” ingresamos un string al azar, por ejemplo “asdfg” y en el campo password ingresamos cualquier string que nos ayude a romper la consulta SQL, con el fin de obtener algún error. En resumen, jugando y jugando con las variables, cantidad de tablas, columnas, etc finalmente se realiza una inyección con éxito permitiendo enumerar las bases de datos y tablas a las que se tiene acceso y tambien sus registros. Explotando esta vulnerabilidad es posible acceder a mas de 10 bases de datos y más de 50 tablas. Lo que me interesa a mi es la base de datos del sistema SISVEG, llamada SISVEG. La base de datos contiene cerca de 55 tablas, la que me importa a mi es la que tenga algo relacionada con “usuarios“.

sag_mantenedor_usuarios_protected

Revisando el contenido de esa base de datos me di cuenta de otras malas prácticas a nivel de desarrollo seguro: password en texto plano, password por defecto en el 90% de sus usuarios, password fácil de adivinar.

Apenas descubrí la vulnerabilidad y terminé de verificarla, envié el reporte al CSIRT del Ministerio del Interior, con el fin de canalizar de forma rápida el incidente indicando todo el detalle de la vulnerabilidad, incluso con recomendaciones inmediatas y a largo plazo.

En este punto me gustaría mencionar que el SAG reaccionó rápidamente y dio de baja el sistema de forma temporal, mientras encontraban una forma de proteger el sistema y luego poder buscar una solución definitiva. Las personas responsable del SAG atendieron el incidente de muy buena manera y gracias a esto en menos de 24 horas el incidente ya se encontraba controlado. Actualmente, el sistema pide una contraseña HTTP adicional para poder ingresar al portal.

sisveghtpass

Fondo Nacion al de Salud (FONASA) — HTTP Form “old shcool” SQL Injection

El sistema de FONASA se alojaba  bajo el subdominio va.fonasa.cl y básicamente permitía ingresar al sistema de forma arbitraria con cualquier usuario del sistema, obviamente sin conocer su password.

login
La forma de vulnerar este sistema corresponde al payload sql-i mas antiguo y mas violado de todos los tiempos: ‘ or ‘1’=’1. Presionamos el botón mágico “Aceptar” y Booom! Aparecemos con la sesión iniciada. Dependiendo la condición WHERE que utilicemos en la inyección, podemos ir iniciando sesión con todos los usuarios de la base de datos, uno por uno. El primer usuario de la base de datos y con el cual se ingresa sin la condición WHERE, es “S.S Arica

sistema

Lo peligroso de esta vulnerabilidad, es que FONASA deja expuestos datos sensibles respecto a la salud de los chilenos. Por ejemplo, era posible acceder a este tipo de archivos (solo con el nombre sabrán que se trata de algo crítico)

sistema2Por ejemplo, dentro del archivo “*-GES.xlsx”, vemos una planilla de datos con las siguientes columnas

xls_cols1xls_cols2xls_cols3

Y los archivos contienen más de 5 mil registros.

Este incidente tambien lo reporté mediante el CSIRT del Ministerio del Interior, quienes me respondieron rapidamente y derivaron la información a quien correspondía. FONASA tambien dio de baja el sistema en menos de 24 horas, de hecho aún se encuentra abajo. Actualmente, aparece un mensaje de que el sistema está en mantención

fonasa_mantenAún considerando la rápida respuesta y reacción por parte de FONASA, aun existe un problema. Cuando reporté el incidente no solo mencioné el SQL Injection, sino que los archivos XLS que les acabo de mencionar se encuentran disponible desde descarga directa, si bien el sistema está en mantención aún es posible acceder a los documentos ya que son enlazados de forma insegura utilizando algo como “https://sistema.fonasa.cl/directorio1/archivos/GES.xlsx”, por lo tanto, no validan sesiones, tampoco verifica quien está accediendo a dicho archivo, simplemente lo descarga.

Una pregunta abierta para FONASA: ¿Cuantas personas en estos ultimos 2 años han accedido a información sensible debido a fallas de seguridad en sus sistemas?.

Todo lo que he expuesto refleja cosas positivas y negativas

Positivo

  • CSIRT está actuando de manera eficiente, aun sin facultades y con la limitante de “solo reportar”.
  • Las instituciones afectadas están considerando las recomendaciones inmediatas que, dependiendo de la criticidad, corresponden a dar de baja el sistema de forma temporal.
  • Si bien hace unos meses existía nula respuesta por parte de los afectados, en la actualidad se puede ver cierta preocupación.

Negativo

  • Si se revisan las licitaciones y los presupuestos asignados a informática y seguridad; se puede ver que aun se gastan millones y millones en soluciones de hardware y análisis de vulnerabilidades que no estan dando resultado.
  • No se está cumpliendo con el mínimo de seguridad de acuerdo a la Guia Web de la Unidad de Modernización del Gobierno de Chile.
  • El PMG de Seguridad de la Información no asegura la información 🙂

Para finalizar y a modo de recomendación, en lugar de comprar WAF y appliance de altos costos que al final nadie sabe administrarlos o quedan mal implementados, porque no optar por una solución eficiente y real, como por ejemplo montar un par de nodos nginx (tambien puede ser apache) como proxy reverso que realicen filtro de parametros y asi poder evitar por lo menos los xss y las inyecciones de comandos y código sql ? Una máquina fisica o virtual con 4 Gb de disco, 1Gb de RAM y un núcleo es suficiente para soportar alta demanda de peticiones, si se requiere más esfuerzo entonces se duplican los recursos o bien se monta un cluster de nginx.
Ojo, que si el problema no es el legacy software, sino que el legacy developer… no hay nada que hacer 🙂

7 comentarios

  1. Si por cada medida contra ataques e ingresos no autorizado que se toman, aparece una forma de vulnerarlo. ¿Cómo se podría equilibrar un poco esta carrera cuando está tan desigual el número entre quienes quieren proteger un S.I. y miles de internautas con acceso a muchísima información de vulnerabilidades posibles y herramientas que hacen las travesura por uno?

  2. @MelodyRomero para tratar de remediar un poco este tipo de situaciones, se piensa o trabaja en una auditoria – Pentesting. cuesta creer que un gobierno o departamento gubernamental no invierta en tercerizar al menos estos servicios, si es que no cuenta con gente capacitada

  3. @MelodyRomero, sumando a lo que dice @relampago, todos podemos entender que los ataques muchas veces avanzan mucho mas rapido que las protecciones, sin embargo, no podemos darnos el “lujo” de caer en cosas tan BASICAS.

    Si bien el desarrollo seguro o bien tener un sistema bien configurado no te garantiza el 100% de la seguridad, si te ayuda a mitigar al maximo el riesgo.

    Es entendible que sistemas complejos como el de FONASA tenga vulnerabilidades, pero no es aceptable que tenga vulnerabilidades desde hace mas de 5 años y tan basicas…

  4. No me extraña que instituciones de este calibre tengan este tipo de vulnerabilidades, lamentablemente la cultura de hacer las cosas bien y a la primera no es ley a seguir, ni tampoco en la mayoría de estas instituciones está la cultura de tener un equipo encargada del riesgo tecnológico (en estos casos es mejor asumir que no existen.. )
    Estamos en cl y las cosas son como son.. Es como la sensación de inseguridad que te da cuando vas a un restorant y el dueño tiene puesto un cartel que dice “no se responde por daños o robos ocurridos al interior del local”

    Excelente artículo.

  5. Creo que con el software legacy nada que hacer, es demasiado complejo y caro poder entregar una respuesta eficaz ahora con lo que respecta a si se están adoptando medidas, creo que habría que revisar las actuales aplicaciones.

    salu2

  6. @Felipe: Montar un nginx como proxy reverso (o bien con apache) y aplicar filtros GET/POST mitiga todas estas cosas de forma rapida y te da tiempo para resolver los problemas de reaiz. Claramente este proxy no te soluciona el 100% de los problemas, pero ayuda bastante por ejemplo a filtrar cosas tan simples como un “alert()” o como un “‘ or ‘1’=’1”

  7. Cuenta la historia que hay un hospital con este tipo de vulnerabilidades, llegando hasta poder subir muertos, me pregunto ahora cuando en chile pagaran por servicios de expertos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esto sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.