Hackers robaron tokens de acceso del equipo de soporte de Okta
(krebsonsecurity.com)- Una brecha en el sistema de soporte al cliente de Okta expuso archivos que algunos clientes habían subido a casos de soporte, y parece que los atacantes accedieron a la plataforma de soporte durante al menos dos semanas antes de ser bloqueados
- Los atacantes entraron al sistema de gestión de casos de soporte con credenciales robadas y pudieron ver archivos HAR enviados por clientes para resolver problemas
- Los archivos HAR pueden contener cookies y tokens de sesión, por lo que, si se roban, existe el riesgo de que un atacante reutilice la sesión como si fuera un usuario válido
- BeyondTrust detectó el 2 de octubre un intento de crear una cuenta administrativa en su entorno de Okta, y 30 minutos antes había compartido con Okta un archivo HAR que contenía un token de sesión de Okta válido
- Okta notificó a alrededor de 170 organizaciones, cerca del 1% de sus más de 18,000 clientes, y 1Password y Cloudflare también revelaron que sus plataformas de autenticación de Okta fueron comprometidas, aunque afirmaron que no hubo impacto en datos de clientes ni en sus sistemas
Archivos de clientes expuestos en el sistema de gestión de casos de soporte
- Okta es una empresa que ofrece herramientas de identidad como autenticación multifactor e inicio de sesión único a miles de compañías, y este incidente comenzó con una intrusión en su equipo de soporte al cliente
- En un aviso enviado a algunos clientes el 19 de octubre, informó que credenciales robadas se usaron para acceder al sistema de gestión de casos de soporte
- Los atacantes pudieron ver archivos subidos recientemente por algunos clientes de Okta en casos de soporte
- Al principio el alcance fue descrito como “una cantidad muy pequeña”, y después se confirmó que se notificó a unas 170 organizaciones, cerca del 1% de la base de clientes
Por qué los archivos HAR se volvieron un riesgo
- Okta a veces solicita archivos HTTP Archive (HAR), que son registros de sesión del navegador web, cuando resuelve problemas de clientes
- Los archivos HAR son sensibles porque pueden incluir cookies y tokens de sesión del cliente
- Un atacante puede hacerse pasar por un usuario válido usando cookies o tokens dentro del archivo
- Okta dijo que está investigando junto con los clientes afectados y tomando medidas de protección, como invalidar los tokens de sesión integrados
- Antes de compartir un archivo HAR, deben eliminarse todas las credenciales, cookies y tokens de sesión
El flujo del ataque detectado por BeyondTrust
- La empresa de seguridad BeyondTrust fue uno de los clientes que recibió la notificación de Okta del 19 de octubre
- El CTO de BeyondTrust, Marc Maiffret, dijo que esa notificación llegó más de dos semanas después de que BeyondTrust alertara a Okta sobre un posible problema
- El equipo de seguridad de BeyondTrust detectó el 2 de octubre que alguien intentó crear una cuenta administrativa con altos privilegios dentro de su entorno de Okta usando una cuenta de Okta asignada a uno de sus ingenieros
- Al revisar la actividad de esa cuenta de empleado, descubrieron que 30 minutos antes de la actividad no autorizada, el ingeniero de soporte había compartido con Okta, a solicitud de la empresa, un archivo HAR que contenía un token de sesión de Okta válido
- Los atacantes intentaron usar las cookies del registro del navegador para realizar secuestro de sesión y actuar en nombre de ese usuario
- BeyondTrust informó el 3 de octubre a Okta que era muy probable que hubiera sufrido una intrusión, y transmitió la misma evaluación en llamadas del 11 y 13 de octubre
- BeyondTrust afirmó que detectó el ataque mientras estaba en curso y que sus clientes no se vieron afectados
La respuesta de Okta y las dudas que siguen abiertas
- La Deputy CISO de Okta, Charlotte Wylie, dijo que al principio no consideró que la alerta de BeyondTrust del 2 de octubre fuera resultado de una intrusión en sus sistemas
- Para el 17 de octubre, Okta había identificado y contenido el incidente, desactivando la cuenta comprometida de gestión de casos de clientes e invalidando los tokens de acceso de Okta relacionados
- Wylie no reveló el número exacto de clientes que recibieron la alerta de posible problema de seguridad, pero lo describió como “una porción muy, muy pequeña” de sus más de 18,000 clientes
- No se informó cuánto tiempo tuvo el intruso acceso a la cuenta de gestión de casos de la empresa ni quién estuvo detrás del ataque
- Wylie dijo que el atacante era un actor de amenazas conocido que ya había apuntado antes a Okta y a clientes específicos de Okta
Brechas relacionadas y divulgaciones posteriores
- La divulgación de Okta llegó semanas después de los hackeos a Caesar’s Entertainment y MGM Resorts
- En los incidentes de ambas empresas de casinos, los atacantes engañaron a empleados mediante ingeniería social para que restablecieran los requisitos de inicio de sesión con autenticación multifactor de una cuenta administrativa de Okta
- En marzo de 2022, Okta reveló una intrusión vinculada al grupo de hacking LAPSUS$, especializado en ataques de ingeniería social
- Según el informe posterior al incidente de Okta, LAPSUS$ obtuvo acceso mediante ingeniería social a la estación de trabajo de un ingeniero de soporte de Sitel, un proveedor externo de outsourcing que tenía acceso a recursos de Okta
- Okta publicó después una entrada de blog sobre el incidente que incluye indicadores de compromiso para que los clientes verifiquen si fueron afectados
- Dijo que notificó a todos los clientes afectados
- Enfatizó que los entornos o tickets de soporte de clientes de Okta que no recibieron contacto por separado no fueron afectados
- BeyondTrust también publicó los resultados de su propia investigación
- En una actualización del 24 de octubre, 1Password y Cloudflare revelaron que sus plataformas de autenticación de Okta se vieron comprometidas como resultado de la brecha de Okta
- Ambas compañías dijeron que, según sus investigaciones, ni la información de clientes ni sus sistemas fueron afectados
- Un vocero de Okta dijo a TechCrunch que se notificó a cerca del 1% de la base de clientes, unas 170 organizaciones
1 comentarios
Opiniones de Hacker News
Lo gracioso de este artículo es que Okta recibió de un tercero una notificación sobre actividad sospechosa en un tenant y, al principio, no encontró evidencia de una intrusión; recién después de que BeyondTrust siguiera insistiendo volvió a investigar y confirmó la brecha.
Okta publicó esta entrada en su blog: https://sec.okta.com/harfiles
La frase inicial es “Okta Security has identified adversarial activity”, pero no menciona la notificación de un tercero. Qué buena transparencia
El título es horrible, y no es ni transparente ni directo. Que Okta ni siquiera mencione que BeyondTrust les avisó el 2 de octubre, 30 minutos después de subir un archivo HAR a Okta Support, es realmente pésimo
“Charlotte Wylie, vice-CISO de Okta, dijo que Okta inicialmente consideró que la alerta de BeyondTrust del 2 de octubre no era resultado de una intrusión en sus sistemas. Pero dijo que para el 17 de octubre la empresa había identificado y bloqueado el incidente”
O sea, a una empresa que se supone experta en ciberseguridad y autenticación le avisaron en menos de 30 minutos que había sido hackeada, esa empresa dijo que estaban equivocados y no lo reconoció durante 15 días mientras el atacante actuaba a sus anchas
Wylie, hay que hacerlo mejor
Conviene leer esta entrada de blog enlazada en el artículo original. Una empresa de seguridad que era cliente de Okta compartió un archivo HAR con Okta y, justo después, detectó actividad sospechosa en su propia red y notificó a Okta sobre la intrusión
https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...
Probablemente sea una forma complicada de decir que la IP cambió después del inicio de sesión. Por supuesto, la solución más fácil es no compartir voluntariamente archivos HAR de sesiones activas
Esto no va a ser popular, pero creo que las puertas de entrada centrales de SSO con OAuth, SAML y 2FA deberían operarse on-premise en vez de apretar el “botón fácil” de SaaS
Esto incluye no solo a Okta, sino también a Auth0 (adquirida por Okta), Authy y Duo
Todo software tiene bugs de seguridad, y el software on-premise no es la excepción. Muchas organizaciones de IT no tienen la experiencia para operar y proteger directorios. No se trata de instalar software, crear unas cuentas y dejarlo arrumbado en una esquina; es una tarea muy difícil que incluye recuperación ante desastres, pruebas de backups y determinar si hubo una intrusión
Nadie ha demostrado que la seguridad de IT on-premise sea mejor que la de los proveedores cloud. Entre los departamentos de IT on-premise que vi personalmente, algunos tenían una seguridad muy mala: lugares que entre 2010 y 2020 seguían operando VPN con certificados MD5; lugares que desplegaron servicios web donde usuarios no autenticados podían acceder a datos personales como números de identificación/tributarios, direcciones, nombres y teléfonos; lugares que les dieron a enfermeras un editor de texto con publicidad para escribir notas de pacientes; lugares que no actualizaban una versión de Redcap sin soporte y con bugs de seguridad conocidos, etc.
Según entiendo, Redcap es software que almacena información usada en investigación médica y cálculos de estadísticas de salud pública, y contiene muchos datos sensibles
La idea central es que mover algo de la nube a on-premise puede mejorar la seguridad, o puede no hacerlo. Depende de la capacidad de cada organización de IT, y muchas organizaciones no tienen la capacidad de operar un servicio de identidad como Okta. Además, los proveedores cloud normalmente tienen presupuestos mucho más grandes y pueden distribuir los costos entre muchos clientes, así que pueden invertir más en expertos de seguridad, protección de sistemas y detección de intrusiones
A esos gerentes y ejecutivos no les hacen ninguna pregunta
De hecho, se puede escribir y probar software en sistemas que nunca se conectan. Sorprendente, pero cierto
Los proveedores de identidad, administradores de contraseñas y empresas de VPN jamás deberían ser hackeados. Son compañías que ganan dinero con productos de seguridad, y no usaría una que haya sido vulnerada. Es muy probable que haya problemas más profundos
La suposición básica es que todos pueden ser vulnerados, y la carga de demostrar que no lo serán recae en ellos. En vez de darles el beneficio de la duda a quienes han demostrado incompetencia repetidamente, parece más prudente esperar evidencia positiva que respalde la afirmación extraordinaria de que no los hackean
Si son lo bastante competentes y responsables, lo detectarán y lo divulgarán, pero sospecho que la mayoría no lo hará. Precisamente porque personas como tú dejarían de usarlos. Por eso, cualquiera que esté mínimamente preocupado debería usar alternativas offline, autohospedadas o hechas por cuenta propia
Desafío de Okta de pasar un mes sin ser hackeada: dificultad imposible
Bromas aparte, parece que a Okta le gusta que la comprometan. Uno esperaría que, si este tipo de incidentes hace que sus acciones sigan cayendo, hubiera algún cambio, pero parece que no
El diablo está en los detalles. Probablemente operaban con zero trust
Por un lado, no fue una vulneración del producto principal. Por otro, toda vulneración de un producto principal viene acompañada de una vulneración indirecta de algo no principal
Menos mal que les permitieron adquirir a su competidor Auth0
Algún día, en una charla de conferencia, haré un experimento: pagar para infiltrar personas en puestos de soporte de varias empresas y luego vulnerar esas empresas usando los accesos a sistemas que les dieron
Al final del correo decía esto
“Esta información es confidencial de Okta y no debe compartirse fuera de su organización”
Sinceramente, es bastante gracioso