Un empleado de Okta que inició sesión en su cuenta personal de Google en un dispositivo propiedad de la empresa parece haber sido la fuente de una infracción que ahora se sabe que afectó a un total de 134 clientes intermedios, incluidos varios otros proveedores de servicios de autenticación.

La infracción, que comenzó el 28 de septiembre y duró hasta el 17 de octubre, vio a un actor de amenazas no revelado obtener acceso no autorizado al sistema de atención al cliente de Okta, donde pudieron secuestrar archivos que contenían tokens de sesión que luego podrían usarse para realizar ataques de secuestro de sesión.

El actor de amenazas pudo atacar a cinco de los 134 clientes, tres de los cuales (1Password, BeyondTrust y Cloudflare) hablaron públicamente sobre el incidente.

El CISO de Okta, David Bradbury, dijo: “El acceso no autorizado al sistema de atención al cliente de Okta aprovechó una cuenta de servicio almacenada en el propio sistema. A esta cuenta de servicio se le otorgaron permisos para ver y actualizar casos de atención al cliente.

“Durante nuestra investigación sobre el uso sospechoso de esta cuenta, Okta Security identificó que un empleado había iniciado sesión en su perfil personal de Google en el navegador Chrome de su computadora portátil administrada por Okta.

“El nombre de usuario y la contraseña de la cuenta de servicio se guardaron en la cuenta personal de Google del empleado. La vía más probable para la exposición de esta credencial es el compromiso de la cuenta personal de Google o del dispositivo personal del empleado”, dijo.

Bradbury agregó: “Ofrecemos nuestras disculpas a los clientes afectados y, en general, a todos nuestros clientes que confían en Okta como su proveedor de identidad. Estamos profundamente comprometidos a proporcionar información actualizada a todos nuestros clientes”.

Okta dijo que su investigación se había complicado por no identificar las descargas de archivos en los registros de proveedores de atención al cliente. Esto se debe a que cuando un usuario abre y ve archivos de soporte, el sistema genera un evento de registro específico y un ID de registro y lo vincula al archivo, pero si el usuario navega directamente a la pestaña Archivos en el sistema de soporte al cliente (lo que hizo el actor de la amenaza). hacerlo) generan un evento de registro diferente y una ID de registro diferente.

Debido a que sus investigaciones al principio se centraron en casos de acceso a soporte, lo que significa que evaluó los registros vinculados a estos casos, fue necesario hasta el 13 de octubre (cuando BeyondTrust proporcionó a Okta una dirección IP sospechosa que había podido atribuir al atacante) para que Okta identifique los eventos de acceso a archivos adicionales y vincúlelos a la cuenta del empleado comprometida.

De hecho, durante algún tiempo, Okta dijo que sospechaba que 1Password, el primer cliente que se puso en contacto con él, había sido víctima de un ataque de malware o phishing.

Esto puede explicar en cierta medida por qué BeyondTrust, que informó por primera vez sobre actividad sospechosa en su inquilino Okta el 2 de octubre, se había quejado de que la respuesta de Okta había sido más lenta de lo ideal, y su director de tecnología (CTO) dijo que había luchado por convencer a Okta de que el incidente se había originado a través de sus sistemas.

Okta ha publicado ahora detalles de lo que ha hecho para remediar la situación. La cuenta de servicio al cliente comprometida se deshabilitó y se implementó una opción de configuración específica dentro de Chrome Enterprise que impide que los empleados inicien sesión en Chrome en una computadora portátil ejecutada por Okta con un perfil personal. También ha implementado reglas adicionales de detección y monitoreo en todo su sistema de atención al cliente.

Como paso adicional para los clientes, ha lanzado la vinculación de tokens de sesión basada en la ubicación de la red como una mejora del producto para ayudar a mitigar la amenaza del robo de tokens de sesión contra los administradores de Okta, quienes ahora deberán volver a autenticarse si se detecta un cambio en la red. Esta función no se implementa de forma predeterminada, pero deberá habilitarse en la sección de acceso temprano del portal de administración de Okta.