El equipo de CyberArk Red Team deconstruye el ataque a Uber

Después de conocerse el ciberataque sufrido por Uber a su infraestructura de TI y el acceso a datos confidenciales de sus clientes, el elemento humano de esta historia está cobrando fuerza, por lo que las miradas se centran en la autenticación multifactor (MFA) y otros problemas de mejores prácticas de la Seguridad de las Identidades. Por ello, a medida que se conocen más detalles de la historia es inevitable preguntarnos: “¿Realmente importa quién fue el atacante o cómo entró?» Porque una vez asumido este ataque por parte de Uber, lo que lo hace tan notorio es lo que sucedió después.

En base al análisis y los informes disponibles, CyberArk Red Team ha deconstruido el ataque a Uber con un enfoque en las credenciales “hardcodeadas”, el verdadero punto crítico del ataque, ya que supuestamente se usaron para obtener acceso administrativo a la gestión de acceso privilegiado de la organización (PAM), proporcionada por otro proveedor, lo que desbloqueó otros accesos de alto riesgo. En este sentido, Shay Nahari, VP, Red-Team Services de CyberArk, ha comentado. “Gran parte del análisis del ataque cibernético a Uber se ha centrado en la ingeniería social y múltiples vectores de ataque MFA, pero el verdadero punto de inflexión para el ataque ocurrió después del acceso inicial. La presencia de credenciales embebidas en un recurso compartido de red mal configurado es fundamental para deconstruir este ataque. Fueron las credenciales de acceso a una solución PAM integrada en el script de PowerShell lo que permitió al atacante obtener acceso de alto nivel, escalar privilegios y acceder a los sistemas de TI de Uber. La protección proactiva se basa en la implementación de múltiples capas de seguridad, pero a medida que este ataque se refuerza, la lección más importante es asumir una brecha de seguridad”.

Deconstruyendo el ataque de Uber, paso a paso: lo que supuestamente sabemos

Fase 1: Acceso Inicial. El atacante penetró en el entorno de TI de Uber al obtener acceso a las credenciales de la infraestructura VPN de la compañía.

Fase 2: Descubrimiento. Lo más probable es que el proveedor no tuviera privilegios especiales o elevados para recursos confidenciales, pero sí tenía acceso a una unidad red compartida, al igual que otros trabajadores de Uber. Este recurso compartido de red estaba abierto o mal configurado para permitir una ACL (lista de control de acceso) de lectura amplia. Dentro del recurso compartido de red, el atacante descubrió un script de PowerShell que contenía credenciales privilegiadas embebidas para la solución PAM de Uber.

En la brecha de Uber, las credenciales “hardcodeadas” otorgaron acceso administrativo a una solución de administración de acceso privilegiado. Además, parece que estas credenciales no se habían cambiado desde hacía tiempo, por lo que eran mucho más fáciles de explotar.

Fase 3: Escalado de Privilegios, acceder al Sistema PAM. Al recopilar las credenciales de administrador para la solución de administración de acceso privilegiado, el atacante pudo escalar aún más los privilegios.

Fase 4: Acceder a los secretos del sistema PAM, llegar a los sistemas críticos de la empresa. Según la última actualización de Uber, el atacante obtuvo “permisos elevados para varias herramientas”. Al acceder a los secretos de la solución de administración de acceso privilegiado, el atacante, supuestamente, comprometió el acceso al SSO y las consolas, así como a la consola de administración en la nube donde Uber almacena datos confidenciales (financieros y de sus clientes).

Fase 5: Exfiltración de datos. Uber sigue investigando el incidente, pero ha confirmado que el atacante “descargó algunos mensajes internos de Slack y accedió o descargó información de una herramienta interna que nuestro equipo de finanzas usa para gestionar algunas facturas”.

La protección proactiva requiere una defensa en profundidad, una combinación de capas de seguridad complementarias que respalden una estrategia Zero Trust que utilice fuertes controles de privilegios mínimos. Por ello, para reducir el riesgo cibernético, desde CyberArk recomendamos centrarse en hacer un inventario del entorno para encontrar y eliminar las credenciales embebidas que existen en el código, las configuraciones de PaaS, las herramientas DevOps y las aplicaciones desarrolladas internamente.