Análisis del aviso de violación de datos de LastPass • TechCrunch

Hace dos semanasEl gigante del administrador de contraseñas LastPass anunció que sus sistemas se han visto comprometidos por segunda vez este año.

En agosto, LastPass descubrió que la cuenta de trabajo de un empleado se había visto comprometida para obtener acceso no autorizado al entorno de desarrollo de la empresa, que alberga parte del código fuente de LastPass. El CEO de LastPass, Karim Toubba, dijo que las actividades del pirata informático eran limitadas y contenidas, y les dijo a los clientes que no necesitaban 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 los datos del cliente.

En una breve publicación de blog, Toubba dijo que la información obtenida en 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 no hemos sabido nada desde entonces de LastPass o GoTo, cuyo director ejecutivo, Paddy Srinivasan, emitió una declaración aún más vaga, diciendo solo que estaban investigando el incidente, pero se olvidaron de indicar 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. TechCrunch se ha distinguido con esto y comentó sobre la violación de datos de LastPass 🖍️ con nuestro análisis de lo que significa y lo que LastPass omitió, tal como lo hicimos con la brecha aún sin resolver 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 de las principales razones por las que 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 Amazon Web Services, el brazo de computación en la nube de Amazon, ya que una publicación de blog de Amazon de 2020 describió cómo GoTo, entonces conocido como LogMeIn, vendió más de mil millones de conjuntos de datos migrados 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 esta razón, es importante implementar controles de acceso apropiados y segmentar los datos de los clientes para que, si se roba un conjunto de claves de acceso o credenciales, no se pueda acceder a todo el inventario de datos de clientes de una organización.

Si la cuenta de almacenamiento en la nube compartida por LastPass y GoTo se vio comprometida, es probable que la parte no autorizada obtuviera claves que permitieran un acceso amplio, si no ilimitado, a los datos de la nube de la organización, encriptados o de otro modo.

LastPass aún no sabe a qué se accedió o si se extrajo algún dato

En su publicación de blog, LastPass dijo que estaba "trabajando diligentemente" para comprender qué información específica 🖍️ ha sido accedido por la parte no autorizada. En otras palabras, en el momento de esta publicación de blog, LastPass aún no sabe a qué datos del cliente se ha accedido o si se ha extraído algún dato de su almacenamiento en la nube.

Es una situación difícil para una empresa. Algunos se están moviendo hacia el anuncio rápido de incidentes de seguridad, particularmente en jurisdicciones que requieren una pronta divulgación, incluso cuando la organización tiene poco o nada que decir sobre lo que realmente sucedió.

LastPass estará en una posición mucho mejor para investigar si tiene registros para analizar, lo que puede ayudar a los respondedores a saber a qué datos se accedió y si se exfiltró algo. Es una pregunta que solemos hacer las empresas, y LastPass no es diferente. Cuando las organizaciones dicen que "no tienen evidencia" de acceso o compromiso, es posible que carezcan de los medios técnicos, como el registro, para saber qué estaba pasando.

Un actor malicioso probablemente esté detrás del robo.

La redacción de la publicación de blog de agosto de LastPass planteó la posibilidad de que la "parte no autorizada" no pudiera haber actuado de mala fe.

Es posible obtener acceso no autorizado a un sistema (violando la ley en el proceso) y actuar de buena fe cuando el objetivo final es informar el problema a la empresa y solucionarlo. Es posible que no lo exonere 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 pirata informático o un investigador de seguridad de buena fe está trabajando para solucionar un problema de seguridad y no lo está causando.

En este punto, es bastante seguro asumir que el No autorizado 🖍️ Un actor malintencionado está detrás del ataque, aunque aún se desconoce el motivo del hacker, o los hackers.

La publicación del blog de LastPass establece que la parte no autorizada Obtén información usada 🖍️ durante la pausa de agosto para comprometer LastPass por segunda vez. LastPass no dice cuál es esta información. Podrían ser claves de acceso o credenciales obtenidas por la parte no autorizada durante su incursión de agosto en el entorno de desarrollo de LastPass, pero LasPass nunca las revocó.

Lo que LastPass no dijo en su violación de datos

No sabemos cuándo ocurrió realmente la ruptura.

LastPass no dijo cuándo ocurrió la segunda violación, solo que lo hizo "recientemente descubierto" 🖍️que se relaciona con el descubrimiento de la violación por parte de la empresa y no necesariamente con la interferencia en sí misma.

No hay razón para que LastPass o cualquier otra compañía retenga la fecha de la intrusión si supieran cuándo fue. Si se detecta lo suficientemente rápido, esperaría que se mencionara como un motivo de orgullo.

Pero las empresas a veces usan términos vagos como "reciente" (o "avanzado"), que en realidad no significan nada sin el contexto necesario. Podría ser que LastPass solo descubriera su segunda vulnerabilidad después de que el intruso obtuviera acceso.

LastPass no dice qué tipo de información del cliente podría verse comprometida

Una pregunta obvia es qué información del cliente almacenan LastPass y GoTo en su almacenamiento compartido en la nube. LastPass solo lo dice "ciertos elementos" de los datos del cliente 🖍️ fueron accedidos. Esto puede ser tan completo como la información personal que los clientes proporcionaron a LastPass durante el registro, como el nombre y la dirección de correo electrónico, la información financiera o de facturación confidencial de los clientes y las bóvedas de contraseñas cifradas.

LastPass otorga gran importancia a mantener seguras las contraseñas de los clientes, ya que la empresa ha desarrollado su arquitectura de conocimiento cero. Zero Knowledge es un principio de seguridad que permite a las empresas almacenar los datos cifrados de sus clientes de manera 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 cifradas de los clientes se almacenan en el mismo almacenamiento en la nube compartido que se vio comprometido. LastPass solo dice que las contraseñas de los clientes "mantente encriptado" 🖍️ Esto aún puede ser cierto incluso si la parte no autorizada ha accedido o exfiltrado las bóvedas cifradas de los clientes, ya que aún se necesita la contraseña maestra del cliente para desbloquear sus contraseñas.

Si sucede que los clientes exponen las bóvedas de contraseñas encriptadas o las filtran posteriormente, se eliminaría una barrera importante para acceder a las contraseñas de alguien, ya que todo lo que necesitan 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 cifrarla.

LastPass no dijo cuántos clientes se ven afectados

Si el intruso accedió a una cuenta de almacenamiento en la nube compartida que almacena datos de clientes, se puede suponer que tenía un acceso significativo, si no ilimitado, a los datos de clientes almacenados.

En el mejor de los casos, LastPass segmenta o subdivide la información del cliente para evitar un escenario como el robo catastrófico de datos.

LastPass dice que su entorno de desarrollo, que originalmente se vio 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 utilizan activamente para manejar y procesar la información del usuario, está físicamente separado de su entorno de desarrollo. Usando esta lógica, parece que el intruso pudo haber obtenido acceso al entorno de producción en la nube de LastPass, aunque LastPass dijo en su encuesta post-mortem inicial en agosto que "no había evidencia" de acceso no autorizado a su entorno de producción. Nuevamente, solicitamos registros.

Suponiendo lo peor, LastPass tiene alrededor de 33 millones de clientes. GoTo tiene 66 millones de clientes según los últimos resultados de junio.

¿Por qué GoTo ocultó su violación de datos?

Si pensaba que la publicación del blog de LastPass carecía de detalles, la empresa matriz GoTo dijo que era aún más ligera. Más extraño fue por qué si buscaba la declaración de GoTo, no la encontraría al principio. 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 lo omitan y no cataloguen la página como parte de sus resultados de búsqueda, para asegurarse de 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, a la que representa GoTo, le dijo a TechCrunch que GoTo había eliminado el código "noindex" que impide que los motores de búsqueda notifiquen violaciones de privacidad, pero se negó a decir por qué la publicación se bloqueó inicialmente.

Algunos misterios que quizás nunca resolvamos.