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.

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

Los 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“.

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.

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.

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”

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)

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

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

Aú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 🙂