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.
En primer lugar explicamos quiénes eran los afectados, el propio control que tenían ellos mismos sobre la plataforma y como todo parecía tan normal. Posteriormente MERCA2 relató de manera técnica lo que había sucedido, qué datos quedaron comprometidos y, de nuevo, como todo parecía tan normal. Por último, llega la hora de conocer qué hizo Nalanda al respecto o, mejor dicho, como no hizo casi nada hasta que todo le explotó en la cara.
Lo que se pudo arreglar en días… tardó semanas en solucionarse
En primer lugar, cabe señalar que las vulnerabilidades existen porque el software existe. No hay software infalible a fallos o vulnerabilidades que puedan ser explotadas. Por eso, lo más importante, según cuenta a este medio el analista de seguridad que ha descubierto todo, YellowSub, es ser capaz de reaccionar de la manera más diligente y correcta posible cuando se es informado de la existencia de una vulnerabilidad en el software desarrollado por la empresa.
De igual manera que reaccionamos rápidamente cuando un vecino nos avisa de que nos hemos dejado la ventanilla del coche bajada, o cuando un vecino nos avisa de que hemos dejado la puerta abierta, las empresas deben contar con mecanismos ágiles de acción cuando un analista de seguridad externo contacta para avisarles de una vulnerabilidad que puede convertirse (o que ya se ha convertido) en una brecha de seguridad por donde los datos están, o podrían estar, comenzando a filtrarse.
CÓMO EMPEZÓ TODO
Para entender esta historia primero hay que tener en cuenta los tipos de situaciones que se pueden dar. Un analista de seguridad externo, ajeno a la empresa, tiene dos opciones. La primera de ella se denomina Full Disclosure; es decir, publicar de manera anónima la vulnerabilidad en internet de manera que la empresa se entera del fallo de su software al mismo tiempo que el resto del mundo. Este Full Disclosure es un problema para la empresa pues no le da tiempo de reacción y suele ser habitual que otros hackers al enterarse del fallo comiencen a «atacarlo». Sin embargo el Full Disclosure es la forma más cómoda para un analista de seguridad externo, o Gray Hat, pues tiene menos riesgos de exponer su verdadera identidad.
El tipo de hacker que se topa con la vulnerabilidad es clave para la empresa
La otra opción, la Responsible Disclosure, fue la elegida por YellowSub en este caso. La Responsible Disclosure consiste en contactar directamente con la empresa, Obralia en este caso, y permitir que la compañía conozca los detalles de la vulnerabilidad, y darle un tiempo razonable para que la solucione.
Bajo este escenario, YellowSub decide utilizar este sistema por la sensibilidad de los datos comprometidos (datos principalmente de trabajadores), ya que publicar la vulnerabilidad provocaría ataques contra la misma y la posibilidad de que se filtraran una cantidad de datos aún mayor.
MENSAJES DE IDA Y VUELTA
Durante semanas, YellowSub ha intentado tener una comunicación normalizada con la empresa, pero ésta ha puesto pocas facilidades. Todo ello desde que descubre una vulnerabilidad en Obralia que permite el filtrado de información sensible de sus servidores. El analista de seguridad busca una dirección de email específica donde reportar la vulnerabilidad. A partir de ahí nunca ha habido normalidad.
¿Qué puede ser más importante que atender una vulnerabilidad que afecta a tus clientes?
Se puso en contacto con la empresa, pero no había respuesta. Es habitual en una Responsible Disclosure dar una semana para que la empresa conteste al email, y, a juicio del analista, una posible prórroga. La razón tras esto es que, y sobre todo cuando no existe una dirección específica para reportar vulnerabilidades, podría estar ocurriendo que el email no estuviese llegando ni al director general, Juan Gil; ni al responsable de tecnología, Abraham Carrero, porque se perdiese entre cientos de emails o terminara en una carpeta de spam.
¿Qué puede ser más importante que atender una vulnerabilidad que afecta a tus clientes? Pero desde Nalanda dieron algunas largas al analista. Algo extraño cuando todo parecía apuntar hacía un importante problema informático.
Y LLEGÓ EL CONTACTO
Finalmente, el 17 de enero tiene lugar la reunión. YellowSub tiene dos ideas en mente; la primera es tranquilizar a Obralia. La segunda es obtener el compromiso de la empresa para que le firmen un Acuerdo de Confidencialidad tipo. De ahí la necesidad de que no solo acuda Abraham como responsable técnico, sino también Juan Gil, como director de la empresa.
«Respecto al NDA. En Europa tomo muchas menos medidas de seguridad. Pero en España la cosa cambia. En Europa, avisar a una empresa de que les has descubierto una vulnerabilidad es casi hacerte un amigo. Aquí lo que encuentras es un enemigo en gran parte de las ocasiones». Aunque esta actitud, reconoce YellowSub a MERCA2, está cambiando.
Antes de terminar la reunión, Obralia pregunta a YellowSub «si una vez firmado el Acuerdo de Confidencialidad podría ayudarles a resolver el problema y si ofrece servicios de seguridad a empresas».
YellowSub tiene las cosas claras, y les dice, «la reunión es para firmar el NDA y que podamos hablar sin problemas entre las partes. Mi objetivo es daros, una vez firmado el NDA, todos los detalles de la vulnerabilidad y que desde Obralia podáis resolverla. Si luego posteriormente queréis servicios míos adicionales, ya es otra historia a hablar en otro momento. Para daros todos los detalles de la vulnerabilidad, solo pido un NDA, nada más». Dejando bastante claro que no está solicitando ningún tipo de contraprestación por la información.
«¿Es fácil de resolver?», preguntaba Obralia. «Con los detalles de la vulnerabilidad tendréis todos los datos para resolverla. De eso no tengo duda. Os mando inmediatamente el NDA nada más terminar la reunión para empezar cuanto antes», les respondió YellowSub.
EL TIEMPO DE ESPERA
Los días comienzan a pasar, y ya es 24 de enero de 2019. Puede llegar a ser comprensible que una empresa consulte con su equipo legal sobre el NDA, pero la empresa parece estarse tomando las cosas de todo menos con urgencia teniendo en cuenta que se están filtrando datos de sus trabajadores.
Llegados a este punto el analista se pregunta que por qué se he tomado la molestia ni de avisarles. “Estoy comprometido con la seguridad y sobre todo con las negligencias. Y esta actitud negligente no me la he encontrado en mis más de 15 años de experiencia«, asegura el analista.
El analista de seguridad confiesa no haber visto algo similar a lo de Nalanda en muchos años
La sensación que tiene YellowSub es que, o algo está yendo mal o que están intentando dilatar plazos y ganar tiempo. Ya es 26 de enero y ha pasado casi un mes desde que YellowSub contactara con Obralia. Solo se han acumulado retrasos y la vulnerabilidad sigue ahí exponiendo datos de los clientes de Obralia.
Por otra parte, Obralia se niega a firmar el NDA si antes no se les «dice un importe de la consultoría previamente a la firma».
«Fui bastante claro al respecto durante la reunión. Lo dejé muy claro. El NDA es para libremente hablar de la vulnerabilidad, no quiero ningún importe o dinero por ella. Llevo muchos años en este mundo y hay cosas que no se deben hacer: La primera es pedir una contraprestación por contar información por una vulnerabilidad, para empezar eso es legalmente un chantaje y además no casa con mi ética. La segunda es mezclar vulnerabilidades y auditorías. Ya se lo dije en la reunión. Tú me firmas el NDA y yo te digo los detalles. No necesito nada más a cambio. Si luego tú quieres contratar servicios porque quieres auditarte externamente de verdad esa ya es otra historia», declara a este medio el analista
LA VULNERABILIDAD QUE SIEMPRE ESTUVO AHÍ
En más de 15 años de experiencia comentando vulnerabilidades con empresas extranjeras y españolas, YellowSub confiesa que nunca se ha visto en un caso similar. «Podrán tener todos los certificados que quieran en su página web respecto a seguridad, pero está claro que no tienen ni una política interna efectiva de gestión de incidentes ni compromiso con los datos de sus clientes”.
Asevera el analista que “los errores detectados en la aplicación móvil no pasarían la mínima auditoría de seguridad. Si para esto sirven los certificados, no son más que papel comprado. Ni tienen planes de identificación de vulnerabilidades efectivas, ni tienen planes de actuaciones definidos, ni han sabido contener el incidente”.
Por este motivo, el analista espera que “al menos hayan seguido las directrices mínimas obligatorias marcadas por la Agencia Española de Protección de Datos, en los que deben comunicar la vulnerabilidad en menos de 72 horas, y notificar a los clientes (de haberlos) cuyos datos hayan sido filtrados, entre otras cosas».
Pero solo cuando Obralia se ha enterado de que MERCA2 iba a publicar un Full Disclosure, ha sido cuando de manera apresurada han contenido la vulnerabilidad. Podían haberlo hecho hace tres meses.
