¿Alguna pregunta?   971.31.13.31   info@faseconsulting.es

Otro error en la seguridad alrededor de Lexnet: un servidor dio acceso a ficheros a cualquiera

Como ya indiqué anteriormente, una vez se ha detectado un error básico en una parte de un sistema informático como es el caso de Lexnet, es más posible que se produzca un efecto llamada que busque errores similares tanto en el servicio concreto como en el resto de la infraestructura cercana a éste. Con el caso de Lexnet, esto además puede venir reforzado por el tipo de información con el que se trabaja, lo cual puede convertirlo en un objetivo mucho más atractivo para los atacantes.

Esto ha llevado a que, poco después, se haga pública una nueva vulnerabilidad, en esta ocasión relacionada no con Lexnet (al menos no directamente) sino con un servidor cercano y que, de acuerdo con el contenido al que se ha tenido acceso, tiene relación con el ejercicio de competencias de Justicia. Bajo el titular “nuevo fiasco informático en Justicia: 11.000 documentos internos al descubierto” se nos indica que en el servidor se encontraban almacenados una serie de archivos, que han podido ser descargados.

Antes de entrar más en profundidad, un par de respuestas sobre los aspectos esenciales del tema

¿Podía acceder cualquiera a estos archivos?

Sí, cualquier persona con conexión a Internet puede haberse descargado dichos archivos

¿Habrá quedado constancia de quién se ha descargado los ficheros?

Sí, este servidor seguramente contará con un historial de accesos, con lo cual puede analizarse la gravedad del asunto por alcance

¿Cómo podría haberse mitigado este riesgo?

Para empezar, verificando qué servidores son visibles desde fuera de la red interna (este servidor permitía acceso público). Además, los documentos deberían estar cifrados, lo cual habría supuesto que una persona solo habría tenido acceso a metadatos (como la fecha de creación), pero no a su contenido.

El efecto llamada

Debemos tener claras un par de cosas antes de empezar a analizar las consecuencias de este último caso.

El viernes se detectó una vulnerabilidad, y al afectar al sistema de control de accesos se trata de una vulnerabilidad grave. Es cierto que en algunos foros no se han explicado adecuadamente las limitaciones de esta vulnerabilidad (en particular la necesidad de contar con acceso a Lexnet para poder explotarla), pero lo más relevante es que efectivamente se produjo.

Era de esperar que tras una vulnerabilidad se realizara un escaneo no tan solo del servidor de Lexnet, sino (como mínimo) del resto de direcciones IP dentro de su mismo rango. Es por esto que deberían haberse asegurado de que no existía ningún servicio accesible desde el exterior que no fuera estrictamente necesario. Lexnet puede utilizar multitud de servidores intermedios, para almacenar ficheros, como servidores de bases de datos… pero al final, para el usuario, el único servicio que debería mostrarse es el de entrada a Lexnet. Tal y como mencioné al hablar de las notas de prensa, el primer recurso necesario es tiempo y, tal vez por las fechas en que nos encontrábamos, se ha contado con incluso menos tiempo para solucionar problemas del que normalmente se asignaría (por eso, además, habría que ver que no era el momento más adecuado para introducir una nueva versión, que podía presentar fallos como los que efectivamente se produjeron).

Estamos hablando de un servicio relacionado con Justicia, con documentación que puede ser interesante para partes maliciosas, con lo que estaba claro que debía darse la importancia necesaria a los servicios que se iban a llevar a cabo.

En este caso concreto no sabemos las intenciones de la persona que ha realizado el escaneo del servidor, y posteriormente se ha descargado los contenidos, pero si un usuario lo ha podido hacer, lo han podido hacer cientos.

¿Tan grave es lo que se ha podido obtener?

De nuevo, es complejo saber la gravedad real del asunto sin tener acceso al contenido completo, del que solo tenemos conocimiento parcial, pero sí que se ha hecho pública su naturaleza. Se habla de documentación relacionada con la infraestructura de Lexnet y (al menos parte) del código fuente de la aplicación. Información que se había solicitado en ocasiones anteriores, y que no se había facilitado. Documentación que, sin que normalmente pueda facilitar ataques, puede facilitar el conocimiento de qué hay detrás de Lexnet, y estudiar la existencia de otras posibles vulnerabilidades. Esto rompería una de las técnicas de seguridad que se estaban utilizando aquí, la seguridad por oscuridad, el no facilitar información sobre el sistema a quien es ajeno a él (de lo que hablaré a continuación).

Visto lo anterior, sí, es un suceso potencialmente grave y, sobre todo, requiere de actuaciones rápidas con tal de auditar los posibles vectores de ataque que puedan detectarse gracias a contar con este código (entre otros factores). Por esta misma razón, a mi parecer es un buen momento para que los representantes de los diversos operadores jurídicos requieran con mayor fuerza si cabe el conocer qué contenido ha sido filtrado, y la gravedad real del asunto (incluyendo cuánta gente ha podido acceder a los archivos en los servidores de acuerdo con el historial de accesos), más allá de una nota de prensa genérica, o comunicaciones abstractas sobre posibles actuaciones a llevar a cabo. Esto es incluso más importante cuando tenemos en cuenta que se trata de un servidor al que ha tenido acceso cualquier persona sin necesidad de contar con identificación, a diferencia de lo que sucedía con la primera vulnerabilidad (que permitía controlar, o debería, quién hace qué al requerir previamente la identificación mediante certificados).

Además, no se trata de un servidor que costara mucho de encontrar. De hecho, de acuerdo con la noticia, se localizó utilizando el buscador Shodan

Me metí en Shodan y encontré una IP de Justicia no securizada

Esta herramienta, al alcance de cualquiera, es la prueba de que puede tratarse de un servidor que facilitaba el acceso al público desde hacía tiempo, y cuya localización no resultaba complicada.

Por lo tanto, recapitulando

  1. Un servidor relacionado con Justicia mostraba archivos de manera pública a través de Internet
  2. El acceso al servidor no requería de identificación alguna
  3. El acceso no contaba con ninguna medida restrictiva de seguridad
  4. Los documentos no estaban cifrados

Respecto al contenido en sí, no solo hablamos de código relacionado con Lexnet, pero de esta aplicación se tenían multitud de datos (incluyendo los certificados del Ministerio), sino que también había información sobre Orfila,  el sistema que conecta a los Juzgados, Tribunales, Fiscalías y Oficinas del Registro Civil con los Institutos de Medicina Legal de España.

Además, se nos habla de Visor, el sistema de monitorización en tiempo real de LexNet y Orfila, y al que solo debería tener acceso el administrador.

Lo hicieron probablemente para que los técnicos tuvieran acceso remoto desde el móvil y vieran incidencias, tráfico, peticiones etc… El problema es que lo configuraron mal. Se cargaban las ‘cookies’ de permisos de administrador de forma automática y al volver a iniciar la página no te pedía contraseñas. Podías ver en tiempo real qué le pasaba al sistema y hasta modificar ciertos parámetros

Todo ello nos debe dar a entender que nos encontramos (ya con la información que se ha hecho pública) ante un problema realmente grave. Y, lo que es peor, no conocemos desde cuándo se podía realizar dicho acceso, dado que no va vinculado a una nueva funcionalidad (como al menos así se afirmaba en las notas de prensa del ministerio en el caso del control de accesos).

La seguridad por oscuridad

Un primer acercamiento lo podemos encontrar en la web de Microsoft, en el artículo titulado “El gran debate: la seguridad por oscuridad”. En este artículo, se define este concepto de la siguiente manera

La seguridad por oscuridad es, en pocas palabras, una infracción del principio de Kerckhoffs, que afirma que un sistema debe ser seguro por su diseño, no porque un adversario no conozca su diseño. La premisa básica del principio de Kerckhoffs es que los secretos dejan de serlo en poco tiempo.

Por lo tanto, al final este concepto se basa en que nuestro sistema será seguro mientras nadie de fuera del grupo que se encuentre implementándolo conozca los mecanismos internos de este.

Podemos discutir sobre si la seguridad por oscuridad es eficaz en un supuesto con características concretas, o si al menos añadir un mayor esfuerzo al atacante es positivo. Lo que debemos tener claro es que, sea de una manera u otra (que podría ser objeto de un extenso debate más allá del espacio que puede permitir un artículo simplificado como este), basar nuestra estrategia de manera principal o exclusiva en esta seguridad por oscuridad es un error. Ahora que la información puede haberse obtenido, los posibles errores en el diseño podrían salir a la luz y ser explotados.

En este caso, habría que ver exactamente el contenido completo de la información a la que se ha tenido acceso, pero conocer la infraestructura completa, los servicios que se están utilizando (tal vez incluso los procedimientos establecidos para ello), así como el código fuente de Lexnet puede abrir la puerta a ataques mucho más preparados de lo que podíamos esperar.

Esto es preocupante especialmente por las siguientes razones:

  1. La existencia de un error como fue el existente inicialmente en el control de accesos demuestra que hay un problema con el proceso que se sigue desde el desarrollo de las nuevas funcionalidades hasta la entrada en producción de las mismas. Esto puede facilitar que haya otras vulnerabilidades profundas que pueden explotarse.
  2. El código fuente no era libre, y de hecho se denegó anteriormente el acceso al mismo. Que un atacante pueda haber tenido acceso al mismo le puede facilitar el detectar errores a la hora de trabajar con variables o excepciones que le permitan escalar privilegios, o incluso un acceso sin contar con autorización previa. Lo más grave de esto es que es posible que se trate de errores que podrían haber sido detectados si se hubiera permitido a terceros realizar auditorías de seguridad (tanto a través de ataques directos, como de análisis del código).

Ahora es el momento de ver qué actuaciones se llevan a cabo para mitigar riesgos y solucionar, de una vez, la cuestión de la seguridad alrededor de Lexnet. Lo malo es que es posible que el Ministerio se centre más en perseguir a quien pueda haber filtrado esta vulnerabilidad a los medios más que en solucionarla. Sin perjuicio de que están plenamente legitimados a actuar en defensa de los derechos que corresponden al Ministerio de Justicia, simultáneamente hay que tener una escala de prioridades, y hay que buscar una solución a un problema grave y real. Como indica la noticia de El Confidencial

un portavoz del mismo confirmó la presentación de una denuncia a uno de los supuestos responsables del acceso. Se formalizó pasadas las 21:00 horas de ayer martes 1 de agosto ante la Brigada de Investigación Tecnológica de la Policía Nacional en la Comisaria de Canillas

Lo más grave como digo no es esta actuación, discutible, sino la posterior explicación que también se menciona

Consideramos que no ha habido ningún fallo por nuestra parte, sino un delito de acceso ilícito a una web interna destinada a intercambio de datos dentro de la admnistración pública.

El fallo es efectivo y real, se ha producido una clara negligencia al permitir el acceso (recordemos, sin control de ningún tipo) y sin ninguna medida de seguridad, con lo cual no es admisible esta afirmación de que no se ha producido fallo alguno por su parte. El servidor ya aparecía en Shodan, y en este caso la persona que accedió a los documentos optó por hacerlo público, pero ¿desde cuándo se podía acceder al mismo? Se ha detectado ahora por culpa del problema en el control de acceso, pero desconocemos si alguna parte maliciosa puede haber tenido acceso a toda esta información anteriormente, habiendo optado por ocultar su existencia porque le resultaba más interesante mantener la posibilidad de acceder.

Como ya he repetido en múltiples ocasiones, puede haber incluso más vulnerabilidades que aún no se hayan detectado. Debe realizarse una auditoría en profundidad, y con el tiempo que sea necesario para realmente garantizar la seguridad.

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

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

Ú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