La brecha de Salesloft y cómo PKI reduce el riesgo de secuestro de tokens OAuth

Introducción

Los certificados, en particular los certificados mTLS (Mutual TLS), son un mecanismo eficaz para limitar el riesgo de robo de tokens OAuth. No impiden que roben el token, pero reducen considerablemente su utilidad para un atacante.

La idea consiste en vincular el token OAuth a un cliente específico mediante una clave criptográfica, de modo que el token robado no pueda utilizarse desde otro cliente.

El problema principal: robo de tokens OAuth

1. Robo: un atacante roba un token de acceso, por ejemplo mediante un ataque de intermediario, registros expuestos, una caché de navegador comprometida o una extensión maliciosa.
2. Reutilización: presenta el token robado a un servidor de recursos (por ejemplo, una API).
3. Acceso concedido: el servidor valida la firma y caducidad del token, pero no puede saber si lo presentó el cliente legítimo. El atacante obtiene acceso no autorizado.

Solución: autenticación de cliente basada en certificados (mTLS)

Este método utiliza las especificaciones OAuth 2.0 Mutual-TLS Client Authentication y Certificate-Bound Access Tokens. El proceso consta de dos partes.

Parte 1: autenticar al cliente con un certificado

Al solicitar un token, el cliente demuestra su identidad con un certificado TLS, en lugar de hacerlo únicamente con client_id y client_secret.

1. Aprovisionamiento del cliente: la aplicación legítima recibe un certificado X.509 único y su clave privada. En entornos empresariales, este aprovisionamiento puede ser dinámico.
2. Negociación TLS: cuando el cliente se conecta al servidor de autorización para solicitar un token, se realiza una negociación mTLS. El servidor se autentica ante el cliente como en TLS estándar, y el cliente también debe demostrar su identidad presentando el certificado y firmando datos con su clave privada.
3. Solicitud del token: el cliente realiza una solicitud estándar (por ejemplo, mediante la concesión client_credentials o el código de autorización). El servidor de autorización valida la identidad del cliente tras la negociación mTLS, no mediante un secreto compartido.

Parte 2: vincular el token al certificado (paso clave)

1. Calcular la huella: el servidor de autorización calcula una huella digital del certificado presentado durante la negociación mTLS. Un método habitual es el hash SHA-256 de la codificación DER del certificado.
2. Incluirla en el token: el servidor incorpora la huella del certificado (x5t#S256) directamente en el token de acceso, por ejemplo como una JWT claim.
3. Usar el token: al llamar a la API (servidor de recursos), el cliente debe volver a realizar una negociación mTLS y presentar el mismo certificado que utilizó para obtener el token.
4. Validar el token: el servidor de recursos valida la firma y caducidad del token, extrae la huella incluida en él, calcula la huella del certificado presentado en la negociación TLS y compara ambas. Si coinciden, permite la solicitud; si no, la rechaza.

Cómo limita el robo

1. El atacante roba un token e intenta usarlo contra el servidor de recursos desde su propio equipo.
2. El servidor exige una negociación mTLS, pero el atacante no dispone de la clave privada correspondiente al certificado del cliente legítimo.
3. El atacante no puede completar la negociación mTLS; la conexión se cierra en la capa TLS antes de enviar el token.
4. Aunque lograra enviar el token, el servidor observaría que no se presentó ningún certificado de cliente o que la huella del certificado no coincide con la incluida en el token.
5. La solicitud se rechaza. El token robado no basta sin el certificado y la clave privada correspondientes.

Estándares y perfiles

Este mecanismo está definido en estándares del IETF; no es una solución propietaria:

• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens: especificación principal.
• FAPI 2.0 Security Profile: recomienda y utiliza autenticación de cliente mTLS y vinculación de tokens para escenarios de alta seguridad.

Ventajas

1. Autenticación sólida: sustituye el client_secret estático por una prueba criptográfica sólida.
2. Mitiga la repetición de tokens: el token solo puede utilizarlo el cliente que posee el certificado al que está vinculado.
3. Defensa en profundidad: protege incluso si fallan otras medidas, como el almacenamiento seguro de tokens.

Retos y consideraciones

1. Complejidad: gestionar la emisión, rotación y revocación de certificados de cliente es más complejo que gestionar secretos. La infraestructura de clave pública (PKI), con soluciones CLM como PKI Trust Manager, puede simplificar la gestión de certificados mTLS.
2. Compatibilidad de clientes: no todas las bibliotecas y aplicaciones OAuth admiten mTLS y presentación de certificados de forma nativa.
3. Trabajo de despliegue: hay que configurar el servidor de autorización, el servidor de recursos y todos los clientes.

Resumen

En conclusión, usar certificados mTLS para autenticar clientes y vincular tokens es una estrategia eficaz para mitigar el robo de tokens OAuth. Cambia el modelo de seguridad de “poseer el token” a “poseer el token y la clave criptográfica correspondiente”, lo que eleva considerablemente la dificultad para los atacantes. Es una opción recomendable para proteger comunicaciones máquina a máquina (M2M) y API de alto valor, incluidos los agentes de IA.