El 5 de enero de 2016, hemos emitió un restablecimiento de la contraseña para todos los clientes de Linode durante nuestra investigación sobre el acceso no autorizado a tres cuentas de clientes. Hemos estado trabajando con las autoridades federales en estos asuntos y sus investigaciones penales están en curso. Hoy compartimos nuestras conclusiones y las de la empresa de seguridad externa que contratamos para que nos ayudara en esta investigación.
Antes de entrar en materia, nos gustaría asegurarle que los datos de su cuenta están seguros. Solo hemos encontrado tres clientes afectados por este incidente y hemos resuelto estos problemas con ellos directamente.
Lo que pasó
Se trata de una compleja retrospectiva de dos investigaciones distintas, una en julio y otra en diciembre. Aunque los casos comparten similitudes, no tenemos pruebas que demuestren que ambos estén relacionados. No obstante, a continuación se presenta una cronología completa de los hechos tal y como hemos llegado a entenderlos.
El 9 de julio un cliente nos notificó un acceso no autorizado a su cuenta de Linode . El cliente se enteró de que un intruso había obtenido acceso a su cuenta después de recibir una notificación por correo electrónico que confirmaba el restablecimiento de la contraseña de root para uno de sus Linodes. Nuestra investigación inicial mostró que el inicio de sesión no autorizado tuvo éxito en el primer intento y se parecía a la actividad normal.
El 12 de julio, en previsión de la implicación de las fuerzas del orden, el cliente solicitó la conservación de un Linode correspondiente a una dirección IP que se creía implicada en el acceso no autorizado. Atendimos la solicitud y pedimos al cliente que nos proporcionara cualquier prueba adicional (por ejemplo, archivos de registro) que corroborara que el Linode era el origen de la actividad maliciosa. Ni el cliente ni las fuerzas del orden hicieron un seguimiento y, como no examinamos los datos de los clientes sin una causa probable, no analizamos la imagen conservada.
Ese mismo día, el cliente informó de que el usuario a cuya cuenta se había accedido había perdido varias semanas antes un dispositivo móvil que contenía las credenciales 2FA necesarias para acceder a la cuenta, y explicó que el propietario intentó borrar el dispositivo a distancia algún tiempo después. Además, este usuario empleaba una contraseña débil. A la luz de esta información, y sin pruebas que respalden que las credenciales se obtuvieron de Linode, no investigamos más.
El 9 de diciembre, un investigador de seguridad independiente se puso en contacto con nosotros. El investigador afirmaba estar siguiendo a un individuo que había robado credenciales de numerosos proveedores de servicios. El investigador quería hacernos saber que el individuo podría haber hecho intentos de utilizar estas credenciales robadas para iniciar sesión en algunas de las cuentas de nuestros clientes.
Nuestra investigación inicial concluyó que las IPs proporcionadas, de hecho, habían sido utilizadas para iniciar sesión en tres cuentas en el primer intento. En otras palabras, el usuario llegó a la página de inicio de sesión de Linode Manager con las credenciales necesarias para iniciar sesión, como lo haría cualquier usuario normal. Ese mismo día nos pusimos en contacto con los clientes y recibimos la confirmación de cada uno de ellos de que las actividades eran sospechosas. También confirmamos que ninguna de estas cuentas tenía activada la autenticación multifactor y que todas habían empleado contraseñas débiles.
El 13 de diciembre iniciamos el necesario mantenimiento de Xen Security Advisory (XSA) en toda la flota, reiniciando los servidores en su horario nocturno local las 24 horas del día. Aunque no está relacionado con la investigación, este mantenimiento continuó hasta el 18 de diciembre y supuso una importante limitación de recursos.
El 14 de diciembre, aunque no habíamos descubierto ninguna prueba de una intrusión en nuestra infraestructura, empezamos a entrevistar a empresas de seguridad de terceros y nos pusimos en contacto con varios organismos de seguridad. También dedicamos todos los recursos internos disponibles al esfuerzo y comenzamos a escudriñar nuestro entorno para identificar cualquier evidencia de abuso o mal uso.
El 17 de diciembre, debido a las similitudes entre este caso y el de julio, reabrimos el caso de julio y concluimos que ahora teníamos motivos suficientes para examinar la imagen retenida de esa investigación.
Linode utiliza TOTP para proporcionar autenticación de dos factores. Se trata de un algoritmo que utiliza una clave secreta almacenada y compartida entre nuestro servidor y la aplicación de autenticación de dos factores del cliente (como Google Authenticator). El algoritmo genera un código sensible al tiempo que el usuario proporciona durante el inicio de sesión como un componente de autenticación adicional. Ciframos estas claves secretas cuando las almacenamos en nuestra base de datos.
Tras examinar la imagen de nuestra investigación de julio, descubrimos un software capaz de generar códigos TOTP si se le proporciona una clave TOTP. Encontramos software que implementa el método de descifrado que utilizamos para asegurar las claves TOTP, junto con la clave secreta que utilizamos para cifrarlas. También encontramos comandos en el historial de bash que generaban con éxito un código de un solo uso. Aunque las credenciales encontradas no estaban relacionadas con ninguno de los inicios de sesión no autorizados de Linode Manager realizados en diciembre, el descubrimiento de esta información cambió significativamente la gravedad de nuestra investigación.
El 21 de diciembre, nuestro socio de seguridad externo se unió a la investigación. Este equipo procedió a un análisis forense para identificar cualquier actividad no autorizada a nivel del sistema que pudiera haber permitido a un intruso acceder a las credenciales de los clientes contenidas en nuestra base de datos. El equipo también buscó pruebas de un uso indebido de la aplicación web que hubiera permitido el movimiento lateral de una cuenta de Linode Manager a otra. Además, el equipo inició una evaluación de vulnerabilidad dirigida con el objetivo de identificar un posible vector de ataque para obtener acceso a la base de datos Linode .
El 25 de diciembre comenzaron los ataques DDoS contra nuestra infraestructura. Aunque no tenemos ninguna prueba que demuestre que estos ataques estén relacionados con los incidentes de acceso no autorizado, los ataques obligaron a retirar recursos de nuestra investigación. Esto, combinado con el hecho de que los empleados estuvieran fuera por las vacaciones, creó desafíos adicionales para nuestros equipos de soporte y operaciones.
El 5 de enero, nuestro socio de seguridad concluyó su investigación y emitimos el restablecimiento de la contraseña. Nuestro equipo de seguridad interno continuó revisando nuestra infraestructura durante las siguientes semanas y desarrolló un plan detallado para mejorar nuestra seguridad general.
Hallazgos
Los resultados de la investigación de nuestro socio de seguridad concluyeron que no había pruebas de abuso o uso indebido de la infraestructura de Linodeque hubiera dado lugar a la divulgación de las credenciales de los clientes. Además, la evaluación de nuestra infraestructura y aplicaciones por parte del socio de seguridad no arrojó un vector que hubiera proporcionado este nivel de acceso.
El equipo de seguridad deLinodedescubrió una vulnerabilidad en la puerta de enlace SSH de Lish que potencialmente podría haber sido utilizada para obtener información descubierta el 17 de diciembre, aunque no tenemos pruebas que apoyen esta suposición. Hemos corregido inmediatamente la vulnerabilidad.
Otras teorías consideradas que podrían explicar el acceso no autorizado incluyen un compromiso externo, como las contraseñas débiles mencionadas anteriormente que se utilizan con otros servicios en línea, o ataques de phishing contra esos usuarios.
Qué hacemos al respecto
Estamos utilizando lo que hemos aprendido para realizar mejoras integrales en nuestra infraestructura, incluyendo áreas no relacionadas con el incidente. He aquí algunas de las cosas en las que hemos estado trabajando:
Microservicio de autenticación: Varias de nuestras aplicaciones (como Linode Manager y Lish) realizan la autenticación de usuarios. Anteriormente, estas aplicaciones realizaban esta función teniendo acceso a la información de las credenciales directamente dentro de nuestra base de datos, y luego realizaban ellos mismos las comparaciones. Hemos desarrollado un nuevo enfoque que implica un microservicio cuidadosamente protegido y supervisado que mantiene la propiedad de todas las credenciales de los clientes. Con este método, cuando una aplicación requiere la autenticación del usuario, el microservicio es capaz de validar las credenciales devolviendo un simple "sí" o "no". Las aplicaciones no tendrán acceso a la información de las credenciales. De hecho, las bases de datos que alimentan nuestra infraestructura no contendrán información de credenciales en absoluto cuando se haya completado el despliegue de este microservicio. Además, las contraseñas de los clientes, que antes se almacenaban como hashes SHA-256 con sal con miles de rondas, se almacenarán utilizando bcrypt y se actualizarán sin problemas en un inicio de sesión posterior.
Linode Notificaciones del gestor: Vamos a trabajar para mejorar las notificaciones que reciben nuestros clientes sobre la actividad de sus respectivas cuentas, incluyendo alertas de intentos de inicio de sesión desde nuevas direcciones IP e inicios de sesión fallidos.
Tokenización de CC: Aunque nuestra investigación no arrojó pruebas de que se haya accedido a la información de las tarjetas de crédito, estamos aprovechando la función de tokenización de nuestro procesador de pagos para eliminar el riesgo asociado al almacenamiento de la información de las tarjetas de crédito.
Políticas: Hemos desarrollado múltiples políticas derivadas del marco del NIST sobre temas que van desde la limpieza del escritorio hasta los estándares de las contraseñas. Una nueva política importante es la creación de "zonas de seguridad" para elementos sensibles de la infraestructura, como nuestra base de datos y servidores de autenticación. Los resultados de estos esfuerzos han reducido en gran medida el número de empleados que tienen acceso a sistemas y datos sensibles.
Contratación: Además de los cambios mencionados anteriormente, estamos contratando a un experto en seguridad de alto nivel para que se una a nuestra empresa y dirija un equipo más amplio de ingenieros centrados a tiempo completo en la seguridad. Este equipo no solo se asegurará de que seguimos las mejores prácticas actuales, sino que también ampliará nuestras políticas escritas, formalizará nuestros procedimientos de aprovisionamiento y garantizará fundamentalmente que nuestras políticas estén respaldadas por el proceso y la responsabilidad.
Un nuevo Linode API : Nuestra estrategia más importante a largo plazo es una reescritura de nuestra base de código ColdFusion heredada que nos da la oportunidad de empezar de nuevo y aplicar las lecciones que hemos aprendido en los últimos 13 años. Para ello, hemos estado construyendo un nuevo Linode API sin estado, RESTful, e implementado en Python. Hemos estado trabajando en ello durante los últimos meses y anunciaremos una versión alfa pública del nuevo API en las próximas semanas.
Gestor de código abierto Linode : Este nuevo API será la base de todo lo que vendrá en el futuro, incluyendo un gestor de código abierto Linode que sustituirá al gestor actual.
Mirando al futuro
Reconocemos que tenemos margen de mejora en materia de comunicación y transparencia. A pesar de los XSA y de los persistentes ataques DDoS a lo largo de diciembre, deberíamos haber comunicado antes a nuestros clientes la naturaleza y el alcance de los ataques DDoS y de este incidente de seguridad. Decir que teníamos recursos limitados en ese momento sería una valoración justa. Aun así, podríamos haberlo hecho mejor y, desde entonces, hemos introducido cambios de procedimiento para garantizar que en el futuro se designe a un miembro del equipo para eventos importantes como este, con el fin de facilitar una comunicación frecuente y transparente con nuestros clientes.
Estamos increíblemente agradecidos a los clientes que nos han apoyado a lo largo de estos acontecimientos. Hemos escuchado sus recomendaciones y sentido el apoyo que nos han brindado en los últimos meses. Sabed que seguimos escuchando y actuando en función de vuestros comentarios.
Concluimos diciendo que sentimos mucho si le hemos defraudado. Valoramos la confianza que ha depositado en nosotros como su proveedor de alojamiento y nos comprometemos a ganarnos esa confianza cada día. Esperamos que los detalles proporcionados aquí aclaren algunas informaciones erróneas y demuestren nuestra voluntad de abordar las oportunidades de mejora, hacer lo correcto y aumentar la comunicación y la transparencia con ustedes, nuestros clientes.
Comentarios (17)
*”…we are incredibly grateful for the customers who have supported us throughout these events… [we] felt the support you’ve provided over the past few months… We value the trust you’ve placed in us…”*
Nice sentiments, but words are cheap. You could have shown your appreciation by giving people some money off their bill for the period in question
If there is to be a new Linode Manager, please please PLEASE do not try and “modernize” or “streamline” the interface like Namecheap did. I like my utilitarian and functional Manager.
“We found software implementing the decryption method we use to secure TOTP keys, along with the secret key we use to encrypt them. We also found commands in the bash history that successfully generated a one-time code.”
How do you explain the presence of software using the decryption method you use to secure TOTP keys, along with the secret key you use to encrypt them?
There are always some bumps on the road, sometimes these are big and hard to pass thru, but I think that you’re on the right track.
Keep up the good work 🙂
The most significant take away for me is that Linode is becoming more transparent. Please continue down this path.
Good news for the new Linode manager, is there any ETA?
Long-term customer here. I appreciate all the effort made during the difficult time over the holidays. However, I have asked for 2FA by SMS rather than google authenticator (or in addition to), and was told it will not be happening. It seems that this breach could have been avoided at least in part if 2FA by SMS had been used. The user who lost his phone would have moved his phone number to his new phone as soon as it was replaced. The entire compromise of the TOTP algorithm would not have been possible. So my request, and recommendation still stands; give us 2FA by SMS if we want it.
I know how difficult these situations can be and wish you all the best in your continued growth and improvements. Unfortunately, I’ll be switching to another provider after reading this. I stuck around waiting for an explanation that I hoped would satisfy my concerns and this certainly doesn’t do that… There is reasonable evidence that your story regarding the cell phone is incorrect. In my opinion you should have had a senior security director years ago. Given the nature of the July incident, that image going unexamined is mind boggling and no explanation is given about how the 2FA crypto keys could have ended up on that system. It sounds entirely plausible your infrastructure got breached in July or earlier by a skilled attacker and the evidence is simply not there months later.
It sounds like you’re moving in the right direction, but those are some seriously poor decisions by those in charge and I’ve lost confidence that further mistakes won’t be made.
I like the current Linode manager. It’s simple and fast and clean. Please don’t change it too much. (Don’t go all Namecheap on us)
I’m a longtime Linode customer as well. After reading up on this latest incident I am seriously considering moving my infrastructure to another provider. I’ve been through a number of these cases with Linode and so far have been unaffected and given them the benefit of the doubt. I completely understand that threats are uncovered and exploited and that’s a risk you take with any provider. This isn’t about me taking a knee jerk reaction. I’m fully aware that other providers have been exploited as well but Linode have had multiple exploits and that is reason for concern.
In this post you state that you found software on a client’s VPS generating login credentials using a very private piece of your data and a piece of data that can be used to decrypt other customers data and you have no idea how it arrived on a clients machine and you don’t really seem bothered by that or at the very least you gloss over it. Have you audited every other instance to ensure they’re not also capable of generating keys/decrypting data? From my knowledge of this, the client in question was PagerDuty who alerted you after their own intrusion detection system picked up on the login. By your own account the initial illegal access looked like a legitimate login to your systems and didn’t raise any alarms. You also state that you don’t inspect customers instances without probable cause. So we have to assume that there might be other malicious software running in your infrastructure that you are not aware of and it’s allowing access that isn’t raising alerts.
You say that only three customers were accessed under suspicious circumstances. On that face of it that looks like a small number, considering you have a large client base. However, from what I can gather these were large and notable customers PagerDuty and WPEngine, I believe. That, to me sounds less like a percentage risk and more like plucking high value targets. I’m only a small customer so it’s probably more out of luck that I haven’t been affected rather than my details not actually being available.
Linode has offered a product that’s very valuable to me and my business. It’s provided reliable hosting and features. I chose them because I felt they would be able to support any application that I need to grow without the fuss of moving providers. I no longer have that confidence. The previous attack against Linode resulted in credit card loss and it’s only now that you are looking at tokenizing credit cards and moving to bcrypt for hashing?
I do appreciate that resources get stretched and trying to pick out relevant data and act on it is really difficult in a growing business. But the lack of security awareness at Linode has got to a point not where I feel I can’t trust it with my business which is sad because my experience with them has been positive, well if you put aside data breaches, credit card loss and their private keys ending up on clients’ VPSs and inability to communicate.
“We also found commands in the bash history that successfully generated a one-time code”
I don’t get how you saw this and the investigation concluded that “the security partner’s assessment of our infrastructure and applications did not yield a vector that would have provided this level of access.”
I mean, I don’t understand why someone have a bash on your systems, how he achieved that and what changed so he can’t do it in the future
Just FYI, I’ve been forced to spend considerable ongoing time and money investigating other services and finally choosing a viable non-Linode. This is money that could have been spent on better things, even if it had just been more Linode servers. Outside 3-4 work weeks redirected, my computing budget doubled even after whittling down my 4 Linodes to two.
You might consider joining forces with a cooperative and reputable industry counterpart in an effort to provide more viable business recovery scenarios for your mutual customers. In my case, now I have both a dedicated server vendor and Linode, a solution that is not neither pleasant nor economical. Each has complementary benefits.
I hope that your security efforts prove successful and I concur with the comments that should you change the inside workings of the Linode manager, it should remain simple and shun any feature that is only cosmetic.
I agree with the poster above that Linode appears to be going down a path of greater transparency. I’m extremely happy to see this.
I also believe that full disclosure and admitting fault where necessary is a very honorable thing, and you are to be commended for what you’ve said here.
Odd, all this transparency is making some people think there is a lack of security knowledge at Linode. Guys, you’d have this or worse at practically any other company.
Sounds like almost this entire thing boiled down to a few customers who have no clue about security to begin with. Weak passwords and a mobile device that doesn’t have a screen code to lock the phone. Sigh, sorry Linode had to go through all of that because of a few lazy people, but it does look like they’ve learned a lot and are improving and moving forward.
Kneejerk reacting will only put you with someone else, that probably isn’t doing the same thing as Linode.
Keep up the great works guys and I’m glad to see the improvements.
Well done, Linode!
If you are going to update the Linode Manager API, *please, please, please* give us the ability to do programmatic snapshots.
Thank you.
I greatly appreciate the explanation and transparency. So very different than other companies. This is the kind of thing that creates customer loyalty.