Estos últimos días se ha detectado una vulnerabilidad importante a la hora de controlar los accesos a documentos existenes en LexNet, el sistema telemático del Ministerio de Justicia para intercambiar información de casos entre juzgados, abogados, procuradores y otros colectivos.

Se han publicado artículos como el de El Confidencial, bajo el titular “La gran “chapuza” informática de LexNet en Justicia que ha costado más de 7 millones“, informando de lo sucedido en la plataforma de Lexnet.

Pero vayamos por partes para ver si realmente es un error grave.

¿Puede acceder cualquiera al contenido existente en Lexnet?

No, al menos no a través de esta vulnerabilidad. El acceso requiere en primer lugar estar identificado dentro del sistema.

¿Se muestran directamente todos los expedientes a cualquier usuario?

No, en principio tras acceder con tu certificado se mostraban únicamente aquellos expedientes asociados al usuario.

¿Cuál es el problema?

Es sencillo. Bastaba utilizar el código Id de un compañero para poder acceder a su contenido, aunque no hubieras sido autorizado para ello.

¿Entonces sólo usuarios autorizados del sistema podían utilizar esta vulnerabilidad?

Sí, no se trataba de un posible acceso por parte de terceros que no contaran previamente con acceso a Lexnet por formar parte de los colectivos autorizados. Era necesario contar con autorización para acceder a la plataforma y, una vez identificado, era posible aprovecharla.

La identificación en el sistema

La identificación para acceder al servicio de Lexnet se basa en una infraestructura de clave pública. Los usuarios cuentan con certificados que, una vez seleccionados en el navegador o app, les identifica y les permite acceder al sistema (además de firmar los contenidos cuando corresponda).

Como he indicado antes, el problema de seguridad denunciado no alcanza a esta identificación inicial para acceder al sistema, aunque ello no quiere decir que no existan problemas ya de base. En especial en la transmisión de datos que se produce entre el equipo del abogado u otro usuario de Lexnet y los servidores en el Ministerio de Justicia.

De hecho, basta con realizar un scan rápido a través de SSLLabs para ver que se le asigna la puntuación más baja

Esta puntuación viene provocada por ser vulnerable al ataque Poodle. Este ataque permite aprovecharse de un error en la negociación de protocolo para forzar el uso de SSL 3.0 en vez de protocolos más seguros, para posteriormente explotar esta vulnerabilidad e ir descifrando el contenido que (en apariencia) se encuentra cifrado entre el cliente y el servidor. A esto deberíamos sumar problemas con los protocolos que admite, como muy bien señala el escáner.

Una vulnerabilidad de este tipo es grave, pero esto resulta aún más crítico cuando recordamos la naturaleza del servicio ante el que nos encontramos. No se trata del blog de un particular, sino de la plataforma a través de la cual se realizan comunicaciones relacionadas con el derecho de defensa. Y en estos casos resulta incluso más importante el prestar atención a la seguridad.

Podríamos añadir que resultaría recomendable contar con Forward Secrecy, o con HSTS, pero lo esencial es solucionar los errores de base.

Los errores de permisos

Uno de los elementos básicos a la hora de diseñar una solución informática es establecer cómo vamos a gestionar los permisos a la hora de acceder a los contenidos de nuestra aplicación. Ya no hablamos de una mera identificación, sino de a qué debe tener acceso cada usuario.

En ocasiones, el problema aparece cuando determinados documentos son generados a petición de usuarios, pero posteriormente son almacenados en carpetas accesibles desde el exterior, como sucedió hace unos años en el Ayuntamiento de Eivissa.

el Ayuntamiento de Eivissa está mostrando a cualquier persona en Internet por un nuevo fallo en su servicio de expedición de certificados de residencia.

Al menos son cinco las personas de las que noudiari.es ha podido consultar toda su filiación completa con una simple búsqueda en Google.

Estos supuestos son especialmente graves, porque el sistema no ha realizado ninguna comprobación previa antes de permitir acceso, con lo cual resulta especialmente complejo saber quién ha accedido al contenido (sin perjuicio de contar con direcciones IP)

Este no es el caso de Lexnet porque

  1. El sistema sí que pedía identificación a la hora de acceder
  2. Los logs del sistema almacenan (o deberían almacenar) la actividad de los usuarios dentro del sistema, a los efectos de posteriores auditorías. Así lo indica la nota de prensa del Ministerio de Justicia al respecto de la vulnerabilidad en Lexnet:

Dichos sistemas dejan constancia de accesos indebidos por lo que de haberse producido llevaría consigo la exigencia de responsabilidades legales por un acceso no autorizado.

  1. En el caso del acceso a una carpeta que no corresponde al usuario, un análisis posterior permitiría identificar a la persona que lo ha realizado, dado que se requiere una identificación previa para obtener los certificados necesarios para el acceso a Lexnet

Entonces, y visto lo anterior, ¿cuál es el problema? Pues que, una vez habías accedido al sistema, no se comprobaban adecuadamente los permisos a la hora de acceder a otros buzones

Este tipo de errores suelen tener, principalmente, su origen en alguna de las siguientes posibilidades:

  • El código de búsqueda de contenido no realiza comprobación alguna del usuario en relación con el contenido, únicamente si cuenta con una sesión válida abierta con el servidor.
  • El sistema no comprueba que la Id de usuario que se facilita como parámetro en la dirección se corresponde con la Id del usuario que ha accedido.
  • El Id de usuario queda almacenado en una variable accesible para el usuario.

En el primero de los casos, el código de búsqueda no realiza comprobaciones de permiso. No se comprueba la propiedad de los documentos a que se quiere tener acceso, o la autorización para ello. Se realiza un algoritmo de búsqueda, en base a los parámetros que pueda facilitar el usuario, se comprueba que haya accedido al sistema con un usuario válido, y se muestra sin más.

En el segundo de los casos, tenemos un acceso rápido e inmediato a una variable esencial para el sistema, y cuyos cambios deben ser detectados por el servidor, impidiendo aquellos que puedan poner en peligro la funcionalidad del servicio. Pongamos un ejemplo: imaginemos un servicio que incluye una dirección mientras estamos en el sistema similar a la siguiente:

Tenemos un servicio seguro, con un sistema de identificación aparentemente sin vulnerabilidades, y con un parámetro en la barra de direcciones que indica el usuario que ha accedido. En principio, si modifico la barra de direcciones, podía acabar con algo como lo siguiente

Este cambio de parámetro en el equipo del cliente debería ser detectado y, por tanto, no admitirme el cambio de usuario. En cambio, podemos encontrar plataformas donde resulta posible realizar una actuación así, y que el sistema me permita actuar como si fuera el usuario cuyo parámetro he facilitado.

Lo mismo podríamos decir respecto del tercer supuesto, sea tanto en una variable, en una cookie o en otro mecanismo al alcance directo del usuario. He encontrado sistemas que almacenaban en una variable la identificación del usuario, que se mandaba como parte de la información necesaria a través del frontend de la aplicación, y sin que el servicio de backend realizara comprobación alguna antes de procesarla.

De acuerdo con la Nota del Ministerio, la vulnerabilidad ha aparecido al introducir una nueva funcionalidad en el sistema

ha puesto en funcionamiento una nueva versión que entre otras cuestiones, atiende a las peticiones
que los profesionales han realizado para disponer de acceso multibuzón y la práctica de sustituciones. Esto significa que todos los profesionales colegiados registrados en el sistema pueden disponer de un acceso único a todos sus buzones.

[…]

Con la puesta en marcha de esta nueva versión se ha identificado un defecto en el control de accesos al sistema ocasionado por un error en la programación del código.

En este caso, afortunadamente, se ha optado por notificar esta vulnerabilidad, en vez de explotarla. Ahora bien, se trata únicamente de una vulnerabilidad de rápida detección, pero nada podemos saber ahora mismo respecto a la existencia de otras similares en el código, y esto viene provocado por dos factores

  1. El realizar un “análisis de seguridad profundo” seguramente no sería visto con buenos ojos por parte de los responsables de la plataforma, y muchísimo menos si al final se tuviera efectivamente acceso a información que no correspondería.
  2. A diferencia de lo recomendable, no contamos con acceso al código fuente para poder ser auditado por terceras personas. Eso facilitaría la detección temprana de vulnerabilidades y su corrección. Creer que la seguridad por ocultación de código es el camino a seguir, o que realmente protege a los usuarios, es pecar de inocentes.

Por otro lado, la propia Nota de prensa incluye una mención a Wannacry y Petya que, dadas las características de estos ataques (especialmente el tipo de equipos que han resultado esencialmente afectados), así como las de la vulnerabilidad que ha afectado a Lexnet, me parece que no resulta apropiada en este momento

Por último, el sistema de comunicaciones electrónicas del Ministerio de Justicia cuenta con un sistema de seguridad robusto y contrastado que ha permitido, por ejemplo, que en el último ataque a nivel mundial de los virus conocidos como Wanna Cry y Petya no se haya visto afectado.

¿Y el cifrado?

Se ha preguntado también por cómo puede ser que se haya accedido a contenido de terceros si se utiliza cifrado en la plataforma. La realidad es que existe un cifrado en las comunicaciones con el servidor (deficiente, como ya hemos indicado antes), pero no en los documentos que se encuentran almacenados en el servidor. Esto supone que cualquier usuario que acceda a través de una de estas vulnerabilidades, o un administrador del servicio, puede acceder al contenido íntegro de los documentos almacenados en Lexnet.

Resumiendo, el cifrado en este caso nos protege (o debería, en el caso de haber sido implementado correctamente) por la parte de la conexión con el servidor, pero no se utiliza para los documentos almacenados en la plataforma.

A mi parecer, un sistema tan sensible como el presente debería utilizar claves de cifrado (con las que en realidad ya contamos en un sistema PKI como Lexnet) para cifrar todos los contenidos de tal manera que únicamente las partes del proceso puedan tener acceso.

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
2 Comments
  1. Según hackers en Twitter ya han accedido a LexNet a través de vulnerabilidades más complejas.

Deja un comentario

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