Okta dice que no ha sido hackeado, mientras que LAPSUS$ dice que mienten

David Bradbury, Director de Seguridad de Okta, anunció en la web oficial que la compañía no había sufrido ninguna brecha de seguridad, y que por ende, sus clientes no debían tomar ninguna acción. Este anuncio tuvo lugar esta misma madrugada, cuando el grupo de hackers dijo haber accedido a sus sistemas como super usuario/administrador.

Todo muy normal, hasta que recordamos que hablamos que las declaraciones de vulnerabilidad vinieron del grupo de hackers LAPSUS$, que ha conseguido robar información confidencial a compañías como Nvidia, Samsung, LG, Microsoft o Vodafone, por lo que el propio grupo de hackers respondió a la compañía indicando que la seguridad realmente ha fallado y que deberían dejar de mentir.

Antes que nada, mejor hay que leer la nota de prensa publicada por Okta:

"El servicio de Okta no ha sido vulnerado y sigue siendo plenamente operativo. No hay acciones correctivas que deban ser tomadas por nuestros clientes.

En enero de 2022, Okta detectó un intento fallido de comprometer la cuenta de un ingeniero de soporte al cliente que trabajaba para un proveedor externo. Como parte de nuestros procedimientos habituales, alertamos al proveedor de la situación, a la vez que terminamos las sesiones activas de Okta del usuario y suspendimos la cuenta de la persona. Tras estas acciones, compartimos la información pertinente (incluidas las direcciones IP sospechosas) para complementar su investigación, que fue apoyada por una empresa forense externa.

Tras la finalización de la investigación del proveedor de servicios, recibimos un informe de la empresa forense esta semana. El informe destacaba que hubo una ventana de tiempo de cinco días entre el 16 y el 21 de enero de 2022, en la que un atacante tuvo acceso al portátil de un ingeniero de soporte. Esto coincide con las capturas de pantalla de las que tuvimos conocimiento ayer.

El impacto potencial para los clientes de Okta se limita al acceso que tienen los ingenieros de soporte. Estos ingenieros no pueden crear o eliminar usuarios, ni descargar bases de datos de clientes. Los ingenieros de soporte sí tienen acceso a datos limitados -por ejemplo, tickets de Jira y listas de usuarios- que se vieron en las capturas de pantalla. Los ingenieros de soporte también pueden facilitar el restablecimiento de las contraseñas y los factores de autentificación multifactoriales de los usuarios, pero no pueden obtener esas contraseñas.

Seguimos investigando activamente, incluyendo la identificación y el contacto con los clientes que pueden haberse visto afectados. No hay impacto para los clientes de Auth0, y no hay impacto para los clientes de HIPAA y FedRAMP.

Nos tomamos muy en serio nuestra responsabilidad de proteger y asegurar la información de nuestros clientes. Estamos profundamente comprometidos con la transparencia y comunicaremos actualizaciones adicionales cuando estén disponibles".

Tras la nota de prensa, el grupo de hackers respondió lo siguiente:

Me gustan las mentiras que da Okta.

1. ¿No comprometimos ningún portátil? Era un portátil delgado.

2. "Okta detectó un intento infructuoso de comprometer la cuenta de un ingeniero de soporte al cliente que trabaja para un proveedor externo". -Todavía no estoy seguro de cómo es un intento fallido-.

3. ¿Iniciar sesión en el portal de superusuario con la capacidad de restablecer la contraseña y MFA de ~95% de los clientes no tiene éxito?

4. Para una empresa que soporta Zero-Trust. *Los ingenieros de soporte* parecen tener un acceso excesivo a Slack? ¿8,6k canales? (Puede que quieras buscar AKIA* en tu Slack, más bien es una mala práctica de seguridad almacenar las claves de AWS en los canales de Slack 😉)

5. Los ingenieros de soporte también pueden facilitar el restablecimiento de las contraseñas y los factores MFA de los usuarios, pero no pueden obtener esas contraseñas. -¿Uhm? Espero que nadie pueda leer las contraseñas... no sólo los ingenieros de soporte, LOL. - ¿Insinúas que las contraseñas se almacenan en texto plano?-

6. ¿Afirmas que un portátil fue comprometido? En ese caso, ¿de qué *direcciones IP sospechosas* dispones para informar?

7. El impacto potencial para los clientes de Okta NO es limitado, estoy bastante seguro de que el restablecimiento de las contraseñas y MFA resultaría en un compromiso completo de los sistemas de muchos clientes.

8. Si estáis comprometidos con la transparencia, ¿qué tal si contratáis a una empresa como Mandiant y publicáis su informe? Estoy seguro de que sería muy diferente a su informe 🙂

_________________________________________________________________________________________________________________________________________________________________________________________________________
https://www.okta.com/sites/default/files/2021-12/okta-security-privacy-documentation.pdf

*21. Gestión de las violaciones de la seguridad.

a) Notificación: En el caso de una Brecha de Seguridad, Okta notifica a los clientes afectados de dicha Brecha de Seguridad. Okta coopera con la solicitud razonable de un cliente afectado para obtener información sobre dicha violación de la seguridad, y Okta proporciona actualizaciones periódicas sobre cualquier Brecha de Seguridad y la acción de investigación y acción(es) correctiva(s) tomada(s).

¿Pero los clientes se han enterado hoy? ¿Por qué esperar tanto tiempo?

9. Controles de acceso. Okta cuenta con políticas, procedimientos y controles lógicos diseñados:

b. Controles para garantizar que todo el personal de Okta al que se le conceda acceso a cualquier Dato del Cliente se base en los principios de mínimo privilegio;

kkkkkkkkkkkkk

1. Normas de seguridad. El ISMP de Okta incluye el cumplimiento y la comprobación periódica de los controles, sistemas y procedimientos clave de su ISMP para validar que están correctamente implementados y que son eficaces a la hora de abordar las amenazas y los riesgos identificados.

Dicha pruebas incluyen:
a) Evaluaciones internas de riesgos;
b) Certificaciones ISO 27001, 27002, 27017 y 27018;
c) las directrices del NIST; y...
d) Auditorías SOC2 Tipo II (o norma sucesora) realizadas anualmente por auditores externos acreditados ("Informe de auditoría Report").

¿No creo que almacenar las claves de AWS dentro de Slack cumpla con alguna de estas normas?