Esta semana MERCA2 está informando sobre cómo Nalanda, una empresa especializada en la gestión documental de servicios relacionados con las construcción, ha comprometido los datos privados de los trabajadores de sus clientes. Se trata de grandes constructoras como FCC, Ferrovial o Acciona que, curiosamente, también son los accionistas de la empresa.
Aunque también hay otros clientes que se han vistos afectados por esta vulnerabilidad en la plataforma como Mercadona, Endesa, la hotelera RIU, la promotora Vía Célere o el club Atlético de Madrid.
Pero antes de nada, vamos al principio: ¿Qué es una vulnerabilidad? Se trata, simplemente, de un fallo de seguridad que puede ser explotado para obtener información por otras personas que no deberían tener acceso a ella. Eso es lo que ha sucedido. ¿Pero cómo se ha llegado a este punto?
Nalanda ha compremetido los datos privados de cientos de trabajadores de sus clientes
Según cuenta a MERCA2 el analista de seguridad YellowSub, persona que ha detectado la vulnerabilidad, la clave para explicar la situación residen en el Token. Y es que al igual que para sacar dinero de un cajero es necesario un PIN y que éste sea correcto, o de lo contrario te rechaza la operación, para acceder a datos privados en la plataforma de Nalanda es necesario que las peticiones lleven asociado un PIN (o propiamente dicho, un Token). El servidor, al igual que el cajero, comprueba que el Token es correcto, y si lo es, te da el dinero, o en este caso, los datos. Si no es correcto, al igual que un cajero, la petición de datos privados es rechazada.
Por lo tanto, con descubrir el Token sería suficiente para acceder a los datos que guarda Obralia, que es la antigua denominación de Nalanda, en esa “tarjeta de crédito”. Normalmente no es tan sencillo. Por ejemplo, cuando se inicia sesión en Facebook o se entra a Gmail, se genera un Token para que las peticiones sean válidas y el servidor devuelva los datos necesarios para pintarlos en la pantalla. Los Tokens de Facebook o Gmail tienen dos características: la primera es que el Token tiene fecha de caducidad (es decir, deja de ser válido tras un periodo de tiempo), y además el Token es personal, es lo que permite al servidor saber qué usuario está haciendo la petición y qué información devolverle.
¿QUÉ HA SUCEDIDO EN NALANDA?
Según ha podido conocer MERCA2 con la documentación aportada por parte del analista de seguridad, en el mes de diciembre, viendo aplicaciones en la Google Play Store, según explica a MERCA2 el analista de seguridad -persona que ha detectado la vulnerabilidad-, la clave para explicar la situación residen en el Token, se topa con una aplicación móvil creada por Nalanda. La aplicación se llama Control de Acceso.
Se trata de la aplicación de control de acceso a obras y proyectos que reparte Nalanda a los vigilantes de seguridad para controlar el acceso de cada trabajador.
Lo curioso, según indica el analista a este medio, es que al instalar la versión disponible en esas fechas no le pide que se dé de alta o que inicie sesión de ningún tipo, solo dice: “Escanea el código del trabajador”. (Esto ha cambiado en la última versión).
El proceso para alguien con altos conocimientos resulta bastante sencillo
¿Pero significa eso que cualquiera con acceso a un código de trabajador y que se baje la aplicación puede fichar para entrar y salir? No. Esto no es posible. Porque las peticiones sí que tienen un Token. ¿Pero? ¿Y el Token? Si no se ha solicitado que inicie sesión, ¿cómo se genera o dónde está el Token para hacer las peticiones?
Los Gray Hats, caso del analista que ha descubierto la vulnerabilidad, son “perros viejos”, y olfatean la carnaza a la legua. Y entonces comienza el análisis forense.
Probablemente este es el ejemplo más básico de análisis forense de una aplicación. Lo primero es forzar a que el móvil pase las peticiones a través del ordenador, para capturarlas todas las peticiones y entender qué está pasando. Se lanza la aplicación, no ocurre nada. Lo que esperaba el analista es que el servidor mandase un Token que se almacenase en el móvil para luego al hacer peticiones enviase ese Token con el fin de decir: «Oye, que soy una petición válida». Pero no. El silencio.
Solo queda una opción, si el Token no lo manda el servidor al arrancar la aplicación, pero la aplicación hace una petición con Token. ¿Dónde está el Token?
Respuesta: Dentro de la aplicación. Según cuenta el analista de seguridad a MERCA2, esto es igual que si se guarda el PIN en la misma cartera que tienes la tarjeta. Poner un Token en la aplicación es tan seguro como si se publicara en el muro de Facebook.
El problema de un Token que está guardado en la propia aplicación («hardcodeado» se dice en el argot) es que pierde dos características fundamentales: es un Token que no puede expirar. Y es un Token que no sabe qué usuario está realizando la petición.
QUÉ PASA CON UN TOKEN EN MANOS AJENAS
Después de esto, el analista ya tenía en su poder el Token. Y aquí es la diferencia entre los distintos tipos de hackers. Los Gray Hats que solo detectan vulnerabilidades y avisan de las mismas, como es el caso del analista YellowSub. Y los Black Hats, cuyo objetivo es robar toda la información posible mientras la empresa no se dé cuenta de que tienen una vulnerabilidad en su plataforma. Un Black Hat, gracias al Token, podría hacerse pasar por la aplicación oficial y el servidor no sería capaz de distinguir una petición creada por la aplicación o una petición proveniente de un atacante.
Cuando la aplicación lee la información de la tarjeta del trabajador, lee tres campos. El «idC» que es el «identificador de la contrata», el «codT» que es básicamente el DNI del trabajador y el «est» que identifica el Estado del trabajador.
En la petición, además, se añaden varios campos de información adicionales que pueden tener cualquier valor porque no afecta en esta vulnerabilidad, que son: un campo «est», un «idDispositivo», que es el número de identificación interna del dispositivo móvil, una «acción» cuyos valores pueden ser entrada o salida (que determina si el vigilante está fichando la entrada o salida del trabajador), y la «fecha» del fichaje.
Los datos enviados quedarían de la siguiente forma:
Aquí se puede ver como el token es enviado en el campo «authToken».
QUÉ EXPONE EL SERVIDOR DE OBRALIA
Un ataque a esta vulnerabilidad solo necesita un «idC» (identificador de contrata) válido, y un «codT» (Dni del trabajador) y el TOKEN que nos abre las puertas del servidor. Si se pasa un valor válido de «idC» y de «codT» la respuesta que se obtendría sería algo parecido del tipo a la siguiente imagen.
Esto es una segunda vulnerabilidad. Es decir, primero Obralia guarda un Token a plena vista dentro de su aplicación, pero es que ahora encima al hacer una petición con un dispositivo no válido (el «idDispositivo» pusimos cualquiera) me devuelve información personal del trabajador. Esto se llama «(leakear) o filtrar» información.
Por un lado confirma que el DNI que se ha probado es válido, y no solo eso, sino que nos dice dónde trabaja «contrataNombre», cuéles son sus nombres y apellidos, y un link ‘img’ para ver la foto del trabajador.
En cuanto a la tercera vulnerabilidad. ¿Qué ocurre si a ese link se antepone www.obralia.com?
Además se filtran otra serie de datos, que no son muy comprometedores pero son cuanto menos interesantes. Aparece cual es la constructora «descConstructora» para la que trabaja la contrata y sus CIFs. Esto último no es relevante, pero lo anterior, quién sabe.
Ejemplo con 4 lineas de Python de cómo hacer esta petición:
ATACANDO EL SERVIDOR DE OBRALIA
Como el Token no caduca nunca, solo hay que montar un script, basado en el anterior, que vaya probando un identificador de contrata y dnis. En cuanto se detecte un DNI válido en una «idC» válida, solo habría que mantener fija esa «idC» e iterar para sacar todos los DNIs asociados.
Una Botnet puede hacer miles de peticiones por segundo solo hay que contratar un par de decenas de máquinas zombies en la Dark Web.
Lanzar miles de peticiones falsas por segundo probablemente bloquearía el servicio de Obralia, entretenido contestando a decenas de miles de peticiones falsas creadas por el script, impidiendo el correcto funcionamiento del sistema e impidiendo que pueda contestar a las que realmente los vigilantes están intentando. Habrían sufrido un pequeño, o gran caos, si este ataque se realizara durante las horas punta de entrada y salida de trabajadores puesto que tardaría en responder, o estaría inoperativo, bloqueando el acceso a los trabajadores.
HACIENDO UN ATAQUE TELEDIRIGIDO
Alquilar unas decenas en la Dark Web por un par de horas es extremadamente barato. Pero, ¿y si, además, quisiéramos obtener únicamente los datos de todos los trabajadores de una empresa en particular, por ejemplo, Endesa?
Una opción fácil es utilizar la ingeniería social. Solo habría sido necesario acercarse a un trabajador de Endesa, sacarle con disimulo una foto de su Tarjeta de Trabajador, obtener el «idC» del mismo y con ese «identificador de Contrata», que es el identificador de Endesa, ir variando el «codT» (que son los DNIs) dejando el «idC» fijo. Así se iría obteniendo los datos de los trabajadores de Endesa uno tras otro.
Todo esto ha estado comprometido durante muchas semanas
Y es que el lujo de cualquier trabajador sería el de fichar desde casa la entrada y no pisar el trabajo para nada. Y tras 8 horas fichar, desde su sofá, la salida. Recordando, a la hora de hacer la petición se puede pasar algo que se denomina «idDispositivo». El «idDispositivo» es un conjunto de números y letras que se puede ver en el apartado Ajustes de la aplicación. Para fichar una entrada y una salida el trabajador solo tiene que bajarse la aplicación de Obralia, convencer al vigilante que le ficha las entradas para que le deje el móvil (o aprovechar el mínimo descuido), copiarle el «idDispositivo» que tiene el vigilante en los Ajustes, ponerlo en su propia aplicación (o en el script anterior ajustando la «fecha» del fichaje) y listo. Ya puede irse a su casa, lanzar la aplicación, escanear su tarjeta (y/o ejecutar el script) y fichar las «Entradas» y «Salidas». Todos los partes de fichaje habrían quedado comprometidos.
SOBRE LAS VERSIONES
Según explica el analista, durante estos dos meses Obralia ha intentado buscar por su cuenta y riesgo la solución a la vulnerabilidad, exponiendo negligentemente los datos de sus trabajadores y contratas de manera innecesaria.
Así, en diciembre se solicita una reunión urgente con Obralia por parte del analista que no llega hasta el 16 de enero. En esa fecha, de haberlo deseado, la empresa podría haber tenido todos los detalles siempre que hubiesen firmado un Acuerdo de Confidencialidad entre las partes. No se solicita contraprestación económica alguna por la información. A la espera de la firma, que nunca llegaría, intentan solucionarlo por su cuenta y riesgo, sin informar, pero manteniendo el contacto.
Apenas un par de días después, y sin haber compartido información de la vulnerabilidad con ellos, lanzan una nueva versión de la aplicación, demostrando que tenían conocimiento de que la misma podría ser vulnerable a ataques. Sin embargo desconocen que esta versión no arregla realmente la vulnerabilidad. Siguen utilizando el mismo Token, y la vulnerabilidad sigue activa. En un claro ejemplo de no transparencia no avisan de este nuevo lanzamiento ni intentan confirmar con el analista si la nueva versión arregla la vulnerabilidad.
Así, llegamos al momento actual. El 8 de marzo, cuando se filtra que MERCA2 va en breve a publicar una historia sobre la vulnerabilidad y su gestión, entienden que algo no marcha bien. De esta manera, el 11 de marzo lanzan una nueva versión de su aplicación in extremis. Por fin, esta vez sí, consiguen reparar el conjunto de vulnerabilidades expuestas en este artículo.
Aunque el daño está hecho, ya que la gestión de esta vulnerabilidad, de manera negligente, ha estado exponiendo los datos de sus clientes durante dos meses y medio adicionales sin necesidad.
La vulnerabilidad ha estado activa desde el 27 de septiembre de 2017 hasta el 11 de Marzo de 2019 permitiendo un potencial acceso a datos personales por parte de personas no autorizadas y poniendo en compromiso las funcionalidades de fichaje de la plataforma.
