Lecciones del caso Uber 2022: un token hardcodeado y acceso total

En septiembre de 2022, Uber sufrió uno de los incidentes de seguridad más comentados de los últimos años. Lo interesante no es solo cómo entró el atacante, sino qué se encontró una vez dentro: un script con credenciales de administrador hardcodeadas que le dio acceso prácticamente total a la infraestructura interna de la empresa.

Es un caso de estudio perfecto porque separa dos problemas distintos que solemos mezclar: el vector de entrada (ingeniería social) y la causa raíz que amplificó el daño (un secreto expuesto en texto plano). Este segundo punto es el que casi nunca se corrige.

Qué pasó, en resumen

Según la información pública sobre el incidente, la secuencia fue aproximadamente esta:

1. Un atacante obtuvo las credenciales de un contratista, probablemente compradas en foros clandestinos.
2. Como la cuenta tenía MFA, el atacante bombardeó al contratista con notificaciones push de autenticación ("MFA fatigue") y, haciéndose pasar por soporte de IT, le convenció de aprobar una de ellas.
3. Con esa aprobación, el atacante entró a la VPN corporativa y desde ahí a la red interna.
4. Una vez dentro, encontró un recurso compartido de red con un script de PowerShell. Ese script contenía, hardcodeadas, las credenciales de administrador de una herramienta de gestión de accesos privilegiados (PAM).
5. Con esas credenciales de PAM, el atacante pudo acceder a secretos de sistemas críticos: proveedores cloud, herramientas internas, Slack, y más.

El phishing abrió la puerta de entrada. El token hardcodeado le dio las llaves de todo el edificio.

La causa raíz real: un secreto en texto plano, no solo el phishing

Es tentador leer este caso como "otro ataque de ingeniería social más" y centrar toda la respuesta en formación de empleados y políticas de MFA resistentes a phishing (claves de seguridad físicas, por ejemplo). Eso es necesario, pero incompleto.

La parte que de verdad amplificó el daño fue el diseño de la infraestructura interna: un script que necesitaba autenticarse contra un sistema PAM lo hacía con una credencial escrita directamente en el archivo, sin cifrar, accesible para cualquiera con acceso de lectura al recurso compartido. No hacía falta comprometer ese sistema PAM directamente: bastaba con encontrar el script.

Este patrón se repite constantemente en incidentes de seguridad: el atacante rara vez necesita romper el cifrado o encontrar un exploit de día cero. Le basta con encontrar un secreto que alguien dejó donde no debía — en un script, en un repositorio, en un canal de Slack, en las variables de entorno de un README.

Por qué este patrón se está agravando con código generado por IA

En 2022, encontrar ese script requería moverse manualmente por la red. Hoy, con asistentes de código generando configuraciones, scripts de despliegue y integraciones a gran velocidad, el hábito de escribir const token = "sk-..." directamente en el código es todavía más común, no menos. Un asistente de IA no tiene contexto sobre políticas de seguridad internas; sugiere la solución más simple, que casi siempre es hardcodear el valor para que "funcione".

Hemos escrito sobre esto en detalle en /ai-security: el volumen de código generado automáticamente ha multiplicado el número de lugares donde un secreto puede filtrarse por descuido, no por sofisticación del atacante.

Qué habría limitado el daño

Si la credencial de PAM hubiera estado gestionada como un secreto cifrado en lugar de texto plano en un script, el incidente habría tenido un techo mucho más bajo:

• Ningún secreto en texto plano en disco. El script solo debería referenciar el nombre del secreto, nunca su valor.
• Verificación de quién puede descifrar. No basta con "tener acceso a la red"; el dispositivo o proceso que pide el secreto debería demostrar que es quien dice ser.
• Rotación y revocación rápidas. Si una credencial se sospecha comprometida, poder invalidarla en segundos, no en días.
• Trazabilidad. Saber qué dispositivo o servicio accedió a qué secreto y cuándo.

Ninguna de estas medidas hubiera evitado el phishing inicial. Pero sí habrían evitado que ese phishing se convirtiera en un compromiso total de la infraestructura.

Cómo aborda Koove este problema específico

Koove no es una solución de MFA ni sustituye la formación en ingeniería social. Es un gestor de secretos de conocimiento cero: el servidor solo almacena ciphertext, y los secretos se cifran extremo a extremo con X25519 y AES-256-GCM sobre un esquema de envelope encryption.

En la práctica, para un flujo como el del caso Uber, esto cambia el escenario:

# En vez de escribir la credencial en un script
koove set PAM_ADMIN_TOKEN "xxxxx" --env prod

El código o el script de automatización solo referencia PAM_ADMIN_TOKEN por nombre. El valor real nunca se escribe en disco en texto plano, ni queda expuesto en un recurso compartido de red ni en un repositorio.

Además, en los consumidores móviles, el descifrado solo ocurre en dispositivos verificados con atestación nativa — Apple App Attest o Google Play Integrity — combinada con biometría, verificado extremo a extremo sobre hardware físico real, sin bypass de desarrollador. Si un atacante roba una sesión o un token de acceso a la app pero no controla un dispositivo atestado y verificado biométricamente, no puede descifrar el secreto.

Si una credencial se sospecha comprometida, se puede revocar el acceso de un dispositivo y forzar rewrap de los secretos afectados desde la CLI, documentado en /docs/sdk.

Los límites que hay que decir en voz alta

Koove reduce drásticamente la superficie de secretos expuestos en texto plano, pero no es magia:

• No sustituye una buena política de MFA resistente a phishing para el acceso de empleados a sistemas internos.
• La revocación de un dispositivo impide accesos futuros, pero no puede "deshacer" un secreto que ya fue descargado y descifrado antes de la revocación.
• El esquema no tiene forward secrecy tipo ratchet; es cifrado envelope robusto, no un protocolo de mensajería.
• Koove no elimina la necesidad de segmentar redes internas ni de aplicar el principio de mínimo privilegio en sistemas PAM.

Puedes ver el detalle completo de la arquitectura y el modelo de confianza en /security, y resolver dudas comunes en /faq.

La lección que se queda

El caso Uber 2022 no se recuerda por lo sofisticado del ataque inicial, sino por lo simple que fue escalar de "un empleado aprobó una notificación" a "acceso a toda la infraestructura". Esa distancia la marca la gestión de secretos, no el perímetro.

Si tu equipo todavía tiene tokens escritos en scripts, archivos .env compartidos por Slack o variables hardcodeadas en el código que genera tu asistente de IA, ese es el punto de mayor riesgo real, no el próximo exploit de día cero.

Revisa /plans y da el primer paso hoy en /register: mueve tus secretos a un almacén cifrado antes de que un script olvidado se convierta en tu propio caso de estudio.