Hace dos semanasel gigante del administrador de contraseñas LastPass reveló que sus sistemas se vieron comprometidos por segunda vez este año.
En agosto, LastPass descubrió que la cuenta de trabajo de un empleado se vio comprometida para obtener acceso no autorizado al entorno de desarrollo de la empresa, que almacena parte del código fuente de LastPass. El CEO de LastPass, Karim Toubba, dijo que la actividad del pirata informático era limitada y contenida, y les dijo a los clientes que no había que tomar ninguna medida.
Avance rápido hasta finales de noviembre, y LastPass confirmó un segundo compromiso que, según dijo, estaba relacionado con el primero. Esta vez, LastPass no tuvo tanta suerte. El intruso había obtenido acceso a la información del cliente.
En una breve publicación de blog, Toubba dijo que la información obtenida en el incidente de agosto se usó para acceder a un servicio de almacenamiento en la nube de terceros que LastPass usa para almacenar datos de clientes, así como datos de clientes para su empresa matriz GoTo, que también es propietaria de LogMeIn y GoToMyPC. .
Pero desde entonces, no hemos escuchado nada nuevo de LastPass o GoTo, cuyo director ejecutivo, Paddy Srinivasan, publicó una declaración aún más vaga diciendo que solo estaba investigando el incidente, pero no especificó si sus clientes también se vieron afectados.
La portavoz de GoTo, Nikolett Bacso-Albaum, se negó a comentar.
A lo largo de los años, TechCrunch ha informado sobre innumerables violaciones de datos y qué buscar cuando las empresas revelan incidentes de seguridad. Con eso, TechCrunch ha marcado y aviso de violación de datos de LastPass anotado 🖍️ con nuestro análisis de lo que significa y lo que LastPass ha omitido, tal como lo hicimos con la brecha aún no resuelta de Samsung a principios de este año.
Lo que dijo LastPass en su aviso de violación de datos
LastPass y GoTo comparten su almacenamiento en la nube
Una parte clave de por qué tanto LastPass como GoTo notifican a sus respectivos clientes es que las dos empresas comparte el mismo almacenamiento en la nube 🖍️.
Ninguna de las compañías nombró el servicio de almacenamiento en la nube de terceros, pero es probable que sea Amazon Web Services, el brazo de computación en la nube de Amazon, dado que una publicación de blog de Amazon de 2020 describió cómo GoTo, conocido como LogMeIn en ese momento, migró más de un mil millones de registros de la nube de Oracle a AWS.
No es raro que las empresas almacenen sus datos, incluso de diferentes productos, en el mismo servicio de almacenamiento en la nube. Por eso es importante garantizar controles de acceso adecuados y segmentar los datos de los clientes, de modo que si se roban un conjunto de claves de acceso o credenciales, no se puedan usar para acceder a todos los datos de clientes de una empresa.
Si la cuenta de almacenamiento en la nube compartida por LastPass y GoTo se vio comprometida, es muy posible que la parte no autorizada obtuviera claves que permitieran un acceso amplio, si no ilimitado, a los datos en la nube de la empresa, encriptados o de otro modo.
LastPass aún no sabe a qué se accedió o si se tomaron datos
En su publicación de blog, LastPass dijo que estaba “trabajando diligentemente” para comprender qué información específica 🖍️ fue accedido por la parte no autorizada. En otras palabras, en el momento de su publicación en el blog, LastPass aún no sabe a qué datos del cliente se accedió o si los datos se extrajeron de su almacenamiento en la nube.
Es una posición difícil para una empresa. Algunos se mueven para anunciar incidentes de seguridad rápidamente, especialmente en jurisdicciones que exigen divulgaciones públicas inmediatas, incluso si la empresa tiene poco o nada que compartir sobre lo que realmente sucedió.
LastPass estará en una posición mucho mejor para investigar si tiene registros que pueda analizar, lo que puede ayudar a los que responden a incidentes a saber a qué datos se accedió y si se exfiltró algo. Es una pregunta que hacemos mucho a las empresas, y LastPass no es diferente. Cuando las empresas dicen que “no tienen evidencia” de acceso o compromiso, puede ser que carezcan de los medios técnicos, como iniciar sesión, para saber qué estaba pasando.
Un actor malicioso probablemente esté detrás de la violación.
La redacción de la publicación del blog de LastPass en agosto dejó abierta la posibilidad de que la “parte no autorizada” no haya actuado de mala fe.
Es posible obtener acceso no autorizado a un sistema (y violar la ley en el proceso) y aun así actuar de buena fe si el objetivo final es informar el problema a la empresa y solucionarlo. Es posible que no lo libere de un cargo de piratería si la empresa (o el gobierno) no está contenta con la intrusión. Pero el sentido común a menudo prevalece cuando está claro que un hacker de buena fe o un investigador de seguridad está trabajando para solucionar un problema de seguridad, no para causarlo.
En este punto, es bastante seguro asumir que el fiesta no autorizada 🖍️ detrás de la violación hay un actor malicioso en el trabajo, incluso si el motivo del pirata informático, o piratas informáticos, aún no se conoce.
La publicación de blog de LastPass dice que la parte no autorizada información usada obtenida 🖍️ durante la violación de agosto para comprometer LastPass por segunda vez. LastPass no dice cuál es esta información. Podría significar claves de acceso o credenciales que fueron obtenidas por la parte no autorizada durante su incursión en el entorno de desarrollo de LastPass en agosto, pero que LasPass nunca revocó.
Lo que LastPass no dijo en su violación de datos
No sabemos cuándo ocurrió realmente la brecha.
LastPass no dijo cuándo ocurrió la segunda violación, solo que fue “detectado recientemente” 🖍️que se refiere al descubrimiento de la violación por parte de la empresa y no necesariamente a la intrusión en sí.
No hay ninguna razón por la que LastPass, o cualquier otra empresa, retenga la fecha de la intrusión si supiera cuándo fue. Si se atrapó lo suficientemente rápido, esperaría que se mencionara como un motivo de orgullo.
Pero las empresas, en cambio, a veces usan términos vagos como “recientemente” (o “mejorado”), que en realidad no significan nada sin el contexto necesario. Podría ser que LastPass no descubriera su segunda brecha hasta mucho después de que el intruso obtuviera acceso.
LastPass no dirá qué tipo de información del cliente podría haber estado en riesgo
Una pregunta obvia es ¿qué información del cliente almacenan LastPass y GoTo en su almacenamiento compartido en la nube? LastPass solo dice eso “ciertos elementos” de los datos del cliente 🖍️ fueron accedidos. Eso podría ser tan amplio como la información personal que los clientes dieron a LastPass cuando se registraron, como su nombre y dirección de correo electrónico, hasta la información financiera o de facturación confidencial y las bóvedas de contraseñas encriptadas de los clientes.
LastPass insiste en que las contraseñas de los clientes son seguras debido a cómo la empresa diseñó su arquitectura de conocimiento cero. El conocimiento cero es un principio de seguridad que permite a las empresas almacenar los datos cifrados de sus clientes para que solo el cliente pueda acceder a ellos. En este caso, LastPass almacena la bóveda de contraseñas de cada cliente en su almacenamiento en la nube, pero solo el cliente tiene la contraseña maestra para desbloquear los datos, ni siquiera LastPass.
La redacción de la publicación del blog de LastPass es ambigua en cuanto a si las bóvedas de contraseñas encriptadas de los clientes se almacenan en el mismo almacenamiento compartido en la nube que fue comprometido. LastPass solo dice que las contraseñas de los clientes “permanecer encriptado de forma segura” 🖍️que aún puede ser cierto, incluso si la parte no autorizada accedió o exfiltró las bóvedas cifradas del cliente, ya que la contraseña maestra del cliente aún es necesaria para desbloquear sus contraseñas.
Si resulta que las bóvedas de contraseñas encriptadas de los clientes fueron expuestas o posteriormente exfiltradas, eso eliminaría un obstáculo importante en la forma de acceder a las contraseñas de una persona, ya que todo lo que necesitarían es la contraseña maestra de la víctima. Una bóveda de contraseñas expuesta o comprometida es tan fuerte como el cifrado utilizado para codificarla.
LastPass no ha dicho cuántos clientes se ven afectados
Si el intruso accedió a una cuenta de almacenamiento en la nube compartida que almacena información del cliente, es razonable suponer que tenía un acceso significativo, si no restringido, a los datos del cliente almacenados.
En el mejor de los casos, LastPass segmentó o compartimentó la información del cliente para evitar un escenario como un robo de datos catastrófico.
LastPass dice que su entorno de desarrollo, inicialmente comprometido en agosto, no almacena datos de clientes. LastPass también dice que su entorno de producción, un término para los servidores que se usan activamente para manejar y procesar la información del usuario, está físicamente separado de su entorno de desarrollo. Según esa lógica, parece que el intruso pudo haber obtenido acceso al entorno de producción en la nube de LastPass, a pesar de que LastPass dijo en su autopsia inicial de agosto que “no había evidencia” de acceso no autorizado a su entorno de producción. Nuevamente, es por eso que preguntamos sobre los registros.
Suponiendo lo peor, LastPass tiene alrededor de 33 millones de clientes. GoTo tiene 66 millones de clientes a partir de sus ganancias más recientes en junio.
¿Por qué GoTo ocultó su aviso de violación de datos?
Si pensó que la publicación de LastPass en el blog era ligera en detalles, la declaración de su empresa matriz GoTo fue aún más ligera. Lo que fue más curioso es por qué si buscaba la declaración de GoTo, inicialmente no la encontraría. Esto se debe a que GoTo usó el código “noindex” en la publicación del blog para decirles a los rastreadores de motores de búsqueda, como Google, que la omitan y no cataloguen la página como parte de sus resultados de búsqueda, asegurando que nadie pueda encontrarla a menos que sepa su dirección web específica.
Lydia Tsui, directora de la firma de comunicaciones de crisis Brunswick Group, que representa a GoTo, le dijo a TechCrunch que GoTo había eliminado el código “noindex” que bloqueaba el aviso de violación de datos de los motores de búsqueda, pero se negó a decir por qué razón se bloqueó la publicación para empezar. .
Algunos misterios que quizás nunca resolvamos.
