1Password detecta “actividad sospechosa” en su cuenta interna de Okta
(arstechnica.com)- 1Password detectó actividad sospechosa el 29 de septiembre en su instancia interna de Okta, usada para gestionar el acceso de los empleados a aplicaciones, y no encontró indicios de una intrusión en datos de usuarios ni en sistemas sensibles
- Este acceso estuvo vinculado a la brecha en el sistema de administración de soporte al cliente de Okta, y los atacantes pudieron obtener cookies de autenticación y tokens de sesión a partir de archivos HAR subidos por clientes
- Un informe interno de 1Password en Notion resume que los atacantes obtuvieron un archivo HAR creado por personal de TI mientras trabajaba con soporte de Okta, y que ese archivo contenía tráfico de Okta y cookies de sesión
- Los atacantes solicitaron un reporte de usuarios administradores en el tenant de Okta de 1Password y actualizaron y activaron un IDP para autenticar el entorno de producción de Google, pero un intento posterior de reutilizarlo falló porque el IDP fue eliminado
- La brecha de Okta se convirtió en un caso de ataque de seguimiento en el que una intrusión a un proveedor deriva en ataques contra clientes, y 1Password fue el segundo cliente de Okta conocido en ser objetivo
1Password detecta acceso interno a Okta
- 1Password es un gestor de contraseñas usado por millones de personas y más de 100 mil empresas
- La compañía confirmó actividad sospechosa el 29 de septiembre en la instancia de Okta que usa para gestionar aplicaciones internas de empleados
- El CTO Pedro Canahuati dijo que la actividad fue detenida de inmediato y se inició una investigación, sin encontrar evidencia de compromiso en datos de usuarios ni en sistemas sensibles internos o orientados a usuarios
- Después, 1Password investigó junto con Okta cómo un atacante desconocido logró acceder a la cuenta
Brecha en el sistema de soporte de Okta y riesgo de los archivos HAR
- Se confirmó que el incidente de 1Password se originó en la brecha del sistema de administración de soporte al cliente que Okta divulgó públicamente
- Okta indicó que un actor de amenazas obtuvo acceso no autorizado a su sistema de gestión de casos de soporte y pudo ver archivos subidos por algunos clientes de Okta
- Entre los archivos obtenidos había archivos HAR, usados por el personal de soporte de Okta para reproducir la actividad del navegador del cliente durante la resolución de problemas
- Los archivos HAR pueden almacenar información sensible como cookies de autenticación y tokens de sesión, lo que puede ser explotado por atacantes para hacerse pasar por usuarios legítimos
El segundo objetivo conocido después de BeyondTrust
- La empresa de seguridad BeyondTrust descubrió la intrusión después de que atacantes intentaran acceder a su cuenta de Okta usando cookies de autenticación válidas
- En el caso de BeyondTrust, los atacantes pudieron realizar “algunas acciones limitadas”, pero los controles de políticas de acceso bloquearon la actividad y el acceso a la cuenta
- 1Password se convirtió en el segundo cliente de Okta conocido en ser objetivo de un ataque de seguimiento tras la brecha de Okta
Secuencia del incidente en un informe interno de Notion
- Un informe fechado el 18 de octubre y compartido en el workspace interno de Notion de 1Password indica que los atacantes obtuvieron un archivo HAR creado por personal de TI de la empresa
- Ese empleado había creado el archivo recientemente mientras trabajaba con soporte de Okta
- El archivo incluía un registro completo del tráfico entre el navegador de un empleado de 1Password y los servidores de Okta, además de cookies de sesión
- 1Password no respondió a una solicitud de verificación de autenticidad del documento, proporcionado por un empleado anónimo en texto y capturas de pantalla
- Según el informe, los atacantes también accedieron al tenant de Okta de 1Password
- El tenant de Okta se usa para gestionar permisos y niveles de acceso a sistemas asignados a empleados, socios y clientes
- Los atacantes revisaron asignaciones de grupos y realizaron otras acciones, aunque algunas no quedaron registradas en los logs de eventos
- Durante el inicio de sesión, actualizaron el IDP (identity provider) usado para la autenticación del entorno de producción de Google
Acciones realizadas por los atacantes y reintento bloqueado
- El equipo de TI de 1Password se enteró del acceso el 29 de septiembre tras recibir un correo inesperado que sugería una solicitud de listado de usuarios de 1Password con privilegios administrativos
- Los miembros del equipo determinaron que ningún empleado autorizado había hecho esa solicitud y alertaron al equipo de respuesta de seguridad de la empresa
- Las acciones realizadas por los atacantes fueron las siguientes
- Intentaron acceder al panel de Okta de un empleado de TI, pero fueron bloqueados
- Actualizaron el IDP existente conectado al entorno de producción de Google de 1Password
- Activaron ese IDP
- Solicitaron un reporte de usuarios administradores
- El 2 de octubre, los atacantes volvieron a iniciar sesión en el tenant de Okta de 1Password e intentaron usar el IDP de Google que habían activado antes, pero fallaron porque el IDP había sido eliminado
- Ambos accesos se realizaron desde servidores de LeaseWeb, un proveedor de hosting en la nube en EE. UU., usando una versión de Chrome en una máquina con Windows
- Después del incidente, 1Password cambió la configuración de su tenant de Okta para rechazar inicios de sesión mediante proveedores de identidad que no fueran de Okta
Cómo una brecha en un proveedor deriva en ataques a clientes
- La brecha de Okta es uno de varios ataques de los últimos años dirigidos a proveedores de software y servicios con grandes bases de clientes
- Los atacantes comprometen al proveedor y luego usan esa posición para lanzar ataques de seguimiento contra sus clientes
- Es posible que en adelante se identifiquen más clientes de Okta afectados
1 comentarios
Opiniones de Hacker News
Delegar el SSO a un tercero no es solo cuestión de si técnicamente es más fácil o de si se tiene capacidad operativa. Un factor importante es que en los contratos con clientes puedes decir que usas un proveedor de SSO con buena reputación, y que ese proveedor también asume la responsabilidad de documentar cómo se gestionan las claves y cómo se protege el material criptográfico.
En el caso de 1Password es un poco particular, porque es muy probable que ya tenga ese tipo de estructura, pero normalmente es mucho más fácil decir “nadie dentro de la organización puede acceder a las claves” que “Bob es la única excepción: él opera el servidor SSO y confiamos en él”.
Es interesante que las vulnerabilidades de seguridad de memoria en C sean lo que más se comenta, pero muchas veces lo que realmente tiene más impacto es el llamado colapso de comprensión que surge por seguir diseños supuestamente ejemplares hasta caer en una complejidad excesiva.
Creo que la causa de fondo es la limitación humana para comprender una complejidad enorme.
Esto último probablemente sea complejo porque involucra a personas, y por eso es más fácil buscar la salvación en la tecnología.
Al ver la parte que dice “reemplazamos todas las credenciales de sistema del miembro del equipo de TI y cambiamos MFA para que use solo Yubikey”, ojalá esto sirva como motivo para que todo el personal use autenticación de dos factores basada en Yubikey. Todo lo que esté por debajo de FIDO2 es realmente débil.
Me pregunto por qué la gente sigue eligiendo Okta. Personalmente, me resulta mucho más cómodo usar GSuite como proveedor de identidad. Okta sufrió una brecha bastante grave y, francamente, incluso antes de eso no había escuchado cosas buenas sobre sus prácticas de seguridad.
Exigir MFA basado en hardware es una buena práctica y puede prevenir ataques futuros como spear phishing, pero no tiene relación con este incidente en sí.
La razón por la que la gente elige Okta se parece a “a nadie lo despidieron por comprar IBM”. Si opero mi propio Keycloak y me vulneran, es mi responsabilidad; con Okta, también pesa la estructura de outsourcing que hace que deje de ser mi problema.
Dudo que hayas usado Google Workspace en serio para un caso real. Es uno de los proveedores de identidad con menos funciones, mientras que Okta está entre los que tienen más. Es como comparar una bicicleta con una motocicleta solo porque ambas tienen dos ruedas.
No pensé que llegaría a ver en un foro técnico que recomendaran Google Workspace como proveedor de identidad.
Si usas Yubikey, el soporte al cliente para todos los problemas de contraseñas pasa a quedar a cargo del departamento interno de TI, no de un proveedor externo.
En MFA hay problemas técnicos y problemas sociales; el aspecto técnico de seguridad de implementaciones como llaves, tokens, teléfonos o SMS es casi trivial, y los problemas sociales —soporte al cliente, contraseñas perdidas, llaves que pasaron por la lavadora, imposibilidad de recibir correo— son abrumadoramente mayores.
Todos quieren tercerizar el enorme y tonto rol de soporte al cliente dentro de la seguridad, pero una vez que lo hacen, todos tienen incentivos para reducir costos. El resultado es Okta.
Por ejemplo, si en una organización todos los empleados están en GSuite y quieres dar acceso a una organización de AWS, el método recomendado es AWS SSO[1]. Si configuras la conexión, se puede acceder, pero quedan huecos.
No hay una función para aprovisionar o eliminar usuarios automáticamente en AWS SSO según grupos de usuarios de GSuite. Con el soporte de SCIM de SSO puedes escribir el código tú mismo, pero tienes que mantenerlo.
No hay forma de exigir una verificación de MFA al crear una sesión de SSO, ni del lado de GSuite ni del lado de AWS SSO. GSuite no puede requerir una verificación de MFA antes de autenticar una aplicación SAML, y AWS SSO tampoco puede exigir verificación de MFA cuando usa un proveedor de identidad, a diferencia de cuando usa su Directory interno.
Okta y productos similares hacen este tipo de cosas y, según dicen, también pueden exigir verificación de MFA según el endpoint en uso. No lo he probado directamente; me baso en materiales de marketing y explicaciones de ventas.
En resumen, Okta ofrece mucha más automatización y pegamento de seguridad entre el proveedor de identidad y las aplicaciones que se usan.
[1] Aquí AWS SSO significa el producto de AWS “AWS IAM Identity Center (Successor to AWS Single Sign-On)”.
La evidencia que vemos ahora es, más o menos, que Okta sufrió una brecha el año pasado, sufrió otra esta vez, y esta brecha ocurrió en el departamento o sistema de soporte al cliente. Puede que la divulgación de la brecha se haya demorado, pero también puede que hubiera muchos reportes falsos y no encontraran evidencia hasta hace poco. Puede que no le hayan dado crédito al cliente que la reportó primero, y puede que no se hayan comunicado bien con el cliente después del reporte.
Hay mucho más que no sabemos. No sabemos qué tan hábiles eran los atacantes, cuántas veces fue vulnerado cada proveedor de identidad, cuántas veces detectaron incidentes, si detectaron algo y lo ocultaron, cuántos bugs de seguridad tiene cada servicio, qué tan graves y fáciles de encontrar son, cuál es su capacidad de detección de brechas, qué tan bien capacitados están sus empleados, ni qué proporción de sus empleados realmente se preocupa por la seguridad.
No se puede concluir que el producto sea peor solo porque Okta reportó una brecha. No sabemos qué tan buenos son otros productos, y es posible que Okta sea mejor que algunos o todos sus competidores; por supuesto, también podría ser peor.
Antes compraba 1Password a precio completo, y el software funcionaba completamente offline, guardando la bóveda cifrada localmente o en Dropbox. Como no había nada online que robar, tampoco había que preocuparse por hackers.
Pero entonces alguien sacó la calculadora y decidió que la forma de aumentar la rentabilidad era mover los datos de todos a la nube y cobrar una suscripción. Y ahora estamos preocupados por si se filtraron los datos.
Y, hasta donde sabemos ahora, ¿qué tan distinto es de tener la bóveda en Dropbox? Dropbox también puede ser hackeado, y es famoso que esos datos no están cifrados. ¿No es cierto que todavía no conocemos ningún caso real en el que una bóveda de 1Password haya sido comprometida?
https://blog.1password.com/okta-incident/
Informe original del incidente: https://blog.1password.com/files/okta-incident/okta-incident...
Después, un actor desconocido accedió al portal de administración de Okta con la misma sesión de Okta que se había usado para crear ese archivo HAR.
Como siempre dicen los bancos, no debes darle tu contraseña al personal de soporte.
Esta vez la responsabilidad recae claramente en Okta. Para resolver el problema, está pidiendo sesiones HAR codificadas en texto plano y esperando que el usuario final las limpie correctamente.
¿No podrían limpiar los datos HAR al momento de subirlos, de modo que cuando entren al sistema y los técnicos de soporte, mal pagados y con poco personal, los vean, solo quede lo relevante y seguro?
HAR es datos estructurados, así que es muy fácil limpiarlo con un programa. No es ciencia de cohetes.
La gente sigue preguntando por qué alguien usaría un gestor de contraseñas autoalojado y autosincronizado en lugar de un servicio en línea supersencillo y superamigable, y la razón es la misma. Es como no tirar las llaves de tu departamento en la caja fuerte de la estación de tren del barrio.
Estas organizaciones corrigen los problemas semanas, a veces meses, antes de emitir un comunicado.
Si usas open source y se descubre un bug crítico, recibirás el parche junto con el comunicado de prensa, pero es muy probable que los grandes servicios ya hayan corregido ese problema. Para el usuario promedio, la relación riesgo-beneficio favorece a las soluciones como servicio.
También se puede usar en scripts.
No hay intrusión de servidor, ni vulnerabilidades de extensiones web, ni riesgo de perder todas las contraseñas por un error del servidor. Simplemente funciona bien.
La frase “1Password se convirtió en el segundo cliente conocido de Okta en ser blanco de ataques posteriores” suena rara. ¿Ars no sabe que Cloudflare también fue víctima?
https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...
Me interesa saber cuáles son las mejores prácticas para monitorear comportamiento sospechoso en una app. Conozco lo básico, como revisar la tasa de solicitudes o de errores a nivel de servicio, pero ¿qué tan sofisticado se vuelve en la práctica?
Me pregunto si hay herramientas inteligentes que, al recibir un stream de eventos, encuentren comportamientos anómalos, o si hay que pensar de antemano todo lo que se quiere monitorear y agregar reglas.
Una vez que tienes ese stream de eventos, puedes correr herramientas de análisis de datos. Con días, semanas o meses de actividad se puede crear una línea base normal, y comportamientos que se salgan de ella, como cambios masivos de contraseñas o de correos electrónicos, deberían disparar alertas.
Pero es solo una hipótesis de sillón, así que me gustaría saber si alguien ha trabajado realmente con logs de auditoría y su uso.
¿Lo detectaron otra vez?
https://news.ycombinator.com/item?id=37991863