A estas alturas, seguramente hayáis leído el tweet del Excelentísimo Señor Rafael Català Polo. En caso de no haber podido hacerlo, os lo cito aquí:
#LexNET es un sistema cerrado y seguro.Si se utiliza d forma legal y ética es imposible acceder a información ajena al usuario @Congreso_Es
En este post vamos a hablar de LexNET y de por qué el Excelentísimo Señor Rafael Català Polo está equivocado al considerarlo un sistema cerrado.
Contexto
Empecemos por el contexto de todo esto, LexNET es un sistema destinado a mejorar las comunicaciones entre las distintas parte del sistema judicial, tanto los jueces, los secretarios, los letrados y fiscales e incluso las fuerzas de seguridad del estado. A grandes rasgos, es un sistema similar al correo electrónico que permite enviar documentos legales entre las distintas partes implicadas en un caso.
A finales de Julio, se hizo pública una vulnerabilidad que permitía el acceso a los documentos de otras personas en LexNET, poco después aparecieron otras, incluyendo un servidor con copias de seguridad accesible desde Internet y la posibilidad de averiguar información personal de otros usuarios del sistema. También se descubrió que los metadatos de los manuales accesibles públicamente en Internet también contenían información de los usuarios que los publicaron que podría ser utilizada por un atacante.
A causa del primero de estos fallos LexNET sufrió una parada de emergencia durante la que se arregló dicho problema.
He estado bastante desconectado estos meses así que seguramente me deje cosas aquí, sentíos libres de escribir un comentario completando esta información.
Análisis del problema
Aunque el cierre de LexNET es lo que más revuelo causó, realmente no es una metodología muy diferente de la que he visto seguir a otras empresas a las que se les ha reportado un fallo de seguridad crítico, especialmente teniendo en cuenta que la vulnerabilidad era pública y el riesgo de explotación alto. Además hay que tener en cuenta el cambio de responsabilidades, una vez la vulnerabilidad fue conocida por los administradores del sistema, estos podrían ser considerados responsables de cualquier daño ocurrido posteriormente.
Sin embargo, las vulnerabilidad que provocó el cierre de LexNET es muy bien conocida, hasta el punto de que el listado de vulnerabilidades comunes en sistemas web conocido como OWASP Top 10 la marca como la segunda en base a su puntuación de riesgo y facilidad de detección y explotación y prevalencia.
Si bien es imposible descartar un fallo humano o la falta de experiencia del auditor, normalmente la presencia de semejantes vulnerabilidades suelen ser un síntoma claro de falta de controles de calidad y seguridad adecuados para garantizar el correcto funcionamiento del código. Este tipo de problemas podría haberse detectado fácilmente con los tests adecuados y sería extraño que un pentester con experiencia no lo reportara. Sin embargo analizar la verdadera causa del problema queda fuera del ámbito de este blogpost.
LexNET no es un sistema cerrado
La afirmación de que LexNET es un sistema cerrado tiene cierto mérito pues el acceso normal al sistema se realiza mediante certificados de cliente en dispositivos hardware lo que limita la exposición pública del sistema.
Sin embargo, la única forma de que un sistema se pueda considerar cerrado es si este está totalmente aislado de otros sistemas, cosa que no es del todo cierta en LexNET. Por un lado, sus sistemas son accesibles desde Internet por lo que cualquier vulnerabilidad en su infraestructura expuesta podría ser explotada por un atacante. Además, los sistemas con los que se accede a LexNET suelen estar conectados a Internet por lo que un sistema de uno de los usuarios troyanizado, es suficiente para que el atacante pueda tener acceso a todas las funciones de LexNET expuestas a dicho usuario mientras que este use el sistema.
LexNET posiblemente no sea un sistema seguro
Las vulnerabilidades que se han expuesto demuestran que las metodologías de desarrollo usadas en LexNET no son suficientes para minimizar las posibilidades de que errores críticos acaben en los sistemas de producción. Aunque se han arreglado lagunas de las vulnerabilidades conocidas, sería un fallo bastante serio asumir que esto resuelve los problemas de seguridad pues en realidad simplemente se ataca los síntomas y no las causas. Es decir, asumir que LexNET es seguro porque se han arreglado los fallos que se han hecho públicos es como decir que un paciente de cancer está curado porque se le ha extirpado un tumor. Igual que el tumor puede haber provocado metástasis que le permitan reproducirse, los problemas con los controles de calidad y seguridad de LexNet pueden hacer que aparezcan nuevas vulnerabilidades en futuras iteraciones o que haya vulnerabilidades no conocidas que aún estén sin parchear.
No se puede garantizar un uso legal y ético de LexNET
Como ya he comentado anteriormente es difícil garantizar que todos los usuarios de LexNET van a comportarse de la forma esperado. Por un lado el riesgo de que un usuario malicioso abuse del sistema es un riesgo que siempre debe tenerse en cuenta al analizar los riesgos del mismo, igual que se debe tener en cuenta posibles fallos de hardware y de suministros o el de ataques externos. Por otro, aunque todos los usuarios del sistema se comportaran de la forma esperada, hay que tener en cuenta que un atacante aún puede utilizar las credenciales de dicho usuario sin su consentimiento para realizar sus ataques contra el sistema.
Es por esta razón por la que suele ser habitual que los sistemas de cierta importancia para los negocios suelan ser auditados regularmente y tener controles de calidad más estrictos para así detectar los riesgos, sus probabilidades y daños y poder resolverlos.
La solución
Como he ido comentando a lo largo de este artículo, la forma de minimizar las probabilidades de que este tipo de problemas ocurran de nuevo requiere tres pasos principales. Primero se debería realizar un análisis de riesgos para detectar que posibles problemas pueden afectar al sistema y tener planes de acción preparados contra los mismos, especialmente para aquellos en los que la probabilidad multiplicado por el daño causado sea alta. Segundo, se deberían de mejorar los controles de calidad del código para minimizar las probabilidades de que fallos serios del sistema pasen inadvertidos. Finalmente se debería hacer una auditoría del sistema para intentar detectar el mayor número de vulnerabilidades posibles y así poder arreglarlas antes de que sean explotadas. Dado que cambios en el código pueden hacer que aparezcan nuevos problemas, suele ser habitual en bastantes empresas integrar dichas auditorías en la fase de pruebas de sus ciclos de desarrollo.
Cierre y despedida
La seguridad de sistemas como LexNET nos concierne a todos los ciudadanos pues son nuestros datos los que se manejan con los mismos y que se pueden filtrar. Normalmente, la empresa dónde trabajo cobraría unos cuantos miles de Euros por un informe como el que acabo de compartir con usted, Excelentísimo Señor Rafael Català Polo, sin embargo he decidido hacer este público de forma gratuita no con la intención de atacarle sino con la esperanza de que tanto usted como muchos otros Españoles con responsabilidad sobre sistemas informáticos que nos afectan a todos o a muchos de los ciudadanos sean conscientes de que existen metodologías que permiten minimizar los riesgos de seguridad aunque tienen un precio.
Quedo a su disposición si tiene cualquier consulta al respecto.