¿Alguna pregunta?   971.31.13.31   info@faseconsulting.es

Lexnet tras la parada: ¿Se han solucionado los problemas de seguridad?

Ayer, 30 de julio, se anunció el restablecimiento del servicio de Lexnet, incluyendo la Nota de Prensa los siguientes términos

Esta suspensión se realizó con un mínimo preaviso dada la necesidad de realizar determinadas actuaciones con la máxima agilidad y que el servicio estuviese disponible lo antes posible para los usuarios. El Ministerio antepuso reforzar los principios de autenticidad, confidencialidad e integridad de los datos a la disponibilidad del sistema.

Esta nota de prensa afirma que se han realizado determinados trabajos para aumentar la seguridad del servicio de Lexnet.

Tras los trabajos desarrollados en las últimas horas se ha certificado la seguridad y calidad del sistema de comunicaciones LexNET y, por ello, se ha vuelto a poner en funcionamiento y operación.

Ahora bien, ¿realmente es así y se ha mejorado la seguridad del servicio?

La conexión segura con el servidor

Como ya mencioné en mi post anterior, solo podemos analizar este servicio a base de prueba y error, y únicamente he realizado comprobaciones en superficie dada la naturaleza del servicio prestado y la titularidad del mismo.

Una de las primeras capas que hemos de tener en cuenta es la comunicación con el servidor, la seguridad del canal a través del cual los usuarios del servicio realizarán sus trámites. El viernes se realizó un escaneo del servicio, obteniendo la puntuación más baja al utilizar protocolos desfasados, y no contar con protección contra determinados ataques.

Tras la parada, podemos advertir un cambio en los resultados si realizamos un nuevo escaneo.

A tenor de la nota obtenida, y las características del mismo, podemos mencionar lo siguiente:

  • Se ha realizado un estudio y actualización del servicio aunque mínima.
  • La nota no ha subido, dado que no se ha solucionado el problema de base. Seguimos con un servidor vulnerable al ataque Poodle y utilizando protocolos antiguos
  • Se ha añadido HSTS (Http Strict Transport Security)

¿Qué es este HSTS que se ha añadido? Es un mecanismo de seguridad que “permite a un sitio web indicar a los navegadores que sólo se debe comunicar con HTTPS en lugar de usar HTTP“, como podéis ver en la web de Mozilla.

Por lo tanto, se trata de un mecanismo que intenta evitar los ataques Man-in-the-Middle obligando a los usuarios a acceder desde el principio a la versión segura de la página. El problema es que

  1. La vulnerabilidad más grave no se basaba en explotar comunicaciones no seguras con el servidor (que podría haberlo sido), sino en un tema de permisos una vez se había accedido a Lexnet
  2. Obligar a usuarios a comunicarse con la web a través de HTTPS no es la solución si la configuración del cifrado con el servidor es tan deficiente como lo que se nos ha mostrado aquí.

Esto no es más que poner una tirita encima de una herida realmente grave. Lo importante no es la puntuación que pueda obtener en un servicio determinado, por supuesto, sino las vulnerabilidades que se muestran a través de este servicio. Y no son tolerables en un servicio como Lexnet.

¿Se puede certificar la seguridad del servicio?

La respuesta corta sería no. La nota de prensa me parece excesivamente aventurada al hablar de que “se ha certificado la seguridad y calidad del sistema de comunicaciones LexNET”, dado que no ha existido tiempo material para una actuación de este calibre.

Como bien saben los profesionales que se dedican a actuaciones relacionadas con estándares de seguridad, una auditoría profunda requiere tanto medios personales capacitados para ello como contar con plazo suficiente para llevar a cabo dichas actuaciones. Es más, incluso contando con más personal, no se trata de una tarea en la que el plazo necesario se reduzca de manera proporcional al número de personas destinadas a este estudio.

¿Pero se ha solucionado el error que se había denunciado?

Sí, el error de permisos que permitía acceder a otros buzones se solucionó, pero sin necesidad de una parada definitiva tan larga como la que posteriormente ocurrió tras la primera suspensión del servicio. Es posible que se optara por realizar dicha parada para analizar los historiales de acceso antes de pronunciarse y, de hecho, la nota de prensa deja entrever que así ha sido (el menos en parte)

El sistema LexNET registró el pasado viernes 374.000 accesos, cifra similar a la de cualquier otro día laborable. La parada tuvo lugar a las 16:30 horas, momento en el cual sólo había 200 conexiones activas

Ahora bien, los errores de configuración de este tipo no suelen venir solos y, como ya he indicado, el tiempo utilizado no es suficiente para asegurar la total seguridad del sistema, más después de un problema grave como el que realmente se produjo.

También, como han indicado otros compañeros, ahora se filtran las peticiones web, no mostrando mensajes en el caso de páginas web inexistentes. Todo es un avance, pero hay que trabajar más a fondo.

¿Qué debería hacerse a partir de ahora?

En mi opinión, y como ya he mencionado en otros canales, no basta con realizar un parche que elimine un defecto concreto que era fácilmente detectable. Esto debe ser tomado como una muestra de lo que sucede con una incorrecta planificación tanto de la seguridad como de la cadena de desarrollo hasta la entrada en producción de una nueva versión.

Algunas de las posibilidades son:

  • Que se facilite el código fuente para su estudio y auditoría profundo, sin perjuicio de que se apliquen las licencias que corresponda. Lo perfecto sería contar con una solución de código abierto, pero incluso durante la transición debería poderse estudiar el código que se está utilizando.
  • Facilitar a terceros realizar auditorías de seguridad. Se trata de un servicio importante, parte del derecho a la Justicia y, como tal, resulta recomendable contar con una copia del sistema sobre el cual realizar las pruebas que se estimen oportunas, sin miedo a dejar el servicio inaccesible, y sin el temor de ser castigado por acceder a información sin autorización.
  • Informar de las diferentes versiones y actualizaciones de código a los operadores jurídicos con suficiente antelación para su estudio. Esto iría además en relación con el primer punto, porque lo ideal sería poder conocer los cambios concretos de código en cada versión, lo cual permitiría la trazabilidad de las vulnerabilidades que se pudieran detectar.
  • Debería empezarse a hablar de la necesidad de cifrar los contenidos entre las partes del proceso. No podemos limitarnos a securizar las conexiones con el servidor, sino que los contenidos hospedados en el servidor deberían también quedar cifrados en reposo.
Sergio Carrasco Mayans
Síguenos

Sergio Carrasco Mayans

Consultor at Fase Consulting
Sergio Carrasco Mayans es Ingeniero de Telecomunicaciones, Informático, politólogo y Licenciado en Derecho por la Universitat Oberta de Catalunya, especializado en Derecho de la Sociedad de la Información, Derecho Civil y Derecho Público.
Sergio Carrasco Mayans
Síguenos

Deja un comentario

Últimas publicaciones

En los medios

Dada nuestra especialización, participamos regularmente en artículos en medios de comunicación.
Voz Pópuli
El Español
Hipertextual
Crea Cultura
Xataka
Eldiario

Contáctanos

Calle des Cubells 33, Esc 3, 3A
Teléfono: 971.31.13.31
Móvil: 625.93.81.24
Website: https://www.faseconsulting.es
Email: info@faseconsulting.es