La autenticación en las API es un tema complejo, y los ingenieros de software y seguridad a menudo tienen conceptos erróneos sobre cuáles son sus límites y cómo implementarla correctamente. Para complicar aún más las cosas, solicitar credenciales y factores de autenticación adicionales a usuarios o máquinas no siempre es posible en la comunicación directa por API, y los mecanismos de autenticación son objetivos fáciles para los atacantes, especialmente si están totalmente expuestos o son públicos. Estos dos puntos hacen que el componente de autenticación sea potencialmente vulnerable a ataques avanzados que incluyen fuerza bruta de autenticación, relleno de credenciales y descifrado de credenciales.
Los problemas con la autenticación en las API suelen derivar de dos cuestiones:
- Falta de mecanismos de protección: los puntos finales de API responsables de la autenticación deben tratarse de forma diferente a los puntos finales normales y contar con capas adicionales de protección.
- Implementación incorrecta del mecanismo: el mecanismo se utiliza o implementa sin considerar los vectores de ataque, o el mecanismo no es apropiado para el caso de uso. Por ejemplo, un mecanismo de autenticación diseñado para dispositivos IoT normalmente no es la opción correcta para una aplicación web como un sitio de comercio electrónico.
También existen varios factores técnicos que conducen a una autenticación rota en las API. Estos son los más comunes:
- Complejidad de contraseña débil.
- Historial de contraseñas corto o inexistente.
- Umbrales de bloqueo de cuenta excesivamente altos o inexistentes.
- Fallo al aprovisionar certificados únicos por dispositivo en la autenticación basada en certificados.
- Duraciones excesivamente largas para las rotaciones de contraseñas y certificados.
- Material de autenticación expuesto en URL y solicitudes GET.
- Tokens de autenticación con entropía insuficiente.
- Uso de claves de API como único material de autenticación.
- Fallo al validar la autenticidad del material de autenticación.
- Configuración insegura de JSON Web Token (JWT), como el uso de algoritmos de firma digital débiles o la falta de firmas.
- Uso de tamaños de clave pequeños en algoritmos de cifrado o hash.
- Uso de cifrados débiles o rotos.
- Uso de algoritmos inadecuados para el caso de uso, como el empleo de algoritmos de hash en lugar de funciones de derivación de claves basadas en contraseñas (PBKDF).
- Falta de escalado en la autenticación cuando los flujos de acceso son objeto de ataques, como la ausencia de desafíos dinámicos mediante CAPTCHA o factores de autenticación adicionales (2FA).
Impacto potencial de un ataque de autenticación rota
Un atacante que logra explotar vulnerabilidades en los mecanismos de autenticación puede tomar el control de cuentas de usuario, obtener acceso no autorizado a los datos de otro usuario o realizar transacciones no autorizadas en nombre de otro usuario.
Las API pueden estar diseñadas explícitamente para la comunicación entre máquinas o para la comunicación directa. Un atacante que comprometa ese mecanismo de autenticación o la sesión autenticada puede obtener acceso a todos los datos a los que tiene derecho esa identidad de máquina. También existen variantes de este tipo de ataque en diseños nativos de la nube, mediante el compromiso de la autenticación de cargas de trabajo y los servicios de metadatos de API del lado del servidor.
¿Cómo es un ataque de autenticación rota?
La autenticación rota es la segunda amenaza de seguridad de API más crítica listada en el OWASP API Security Top 10. Los ejemplos comunes de ataques dirigidos a la autenticación rota incluyen la enumeración de API y los ataques de fuerza bruta que realizan grandes volúmenes de solicitudes a la API con cambios mínimos. Estos ataques también pueden dirigirse a una autenticación débil o defectuosa.
Por ejemplo, los mecanismos de recuperación de contraseñas suelen enviar un SMS al teléfono del usuario con un token de restablecimiento compuesto por una serie de números. Un atacante puede iniciar un restablecimiento de contraseña y, si la API no implementa límites de tasa, puede enumerar (o "adivinar") el token hasta obtener una respuesta exitosa. Dependiendo del rendimiento del endpoint de la API objetivo, un atacante podría probar miles o millones de combinaciones diferentes en pocos minutos.
Por ejemplo, los mecanismos de recuperación de contraseñas suelen enviar un SMS al teléfono del usuario con un token de restablecimiento compuesto por una serie de números. Un atacante puede iniciar un restablecimiento de contraseña y, si la API no implementa límites de tasa, puede enumerar (o "adivinar") el token hasta obtener una respuesta exitosa. Dependiendo del rendimiento del endpoint de la API objetivo, un atacante podría probar miles o millones de combinaciones diferentes en pocos minutos.
Ejemplo real: La brecha de datos de Parler
En 2021, el análisis de Salt sobre la brecha de datos de Parler reveló que la autenticación de la plataforma de redes sociales estaba, al menos parcialmente, ausente, lo que respaldaba el consenso general entre hacktivistas y medios de comunicación. Este fallo, junto con otras vulnerabilidades de seguridad en la plataforma Parler, permitió la extracción de al menos 70 TB de datos antes de que la plataforma fuera cerrada el 11 de enero de 2021, al quedar claro que los participantes en el asalto al Capitolio seis días antes la habían utilizado para coordinar sus actividades.
Los hacktivistas descubrieron que al menos un endpoint de la API estaba disponible sin ningún requisito de autenticación y que varias API permitían el acceso directo a la información del perfil de usuario y al contenido de Parler, incluyendo publicaciones, imágenes y vídeos. Es poco probable que Parler hubiera tenido la intención de configurar estas API y páginas para que fueran accesibles sin autenticación.
Algunos informes indicaron que hubo una configuración de seguridad incorrecta debido a una integración con Twilio que posteriormente fue retirada. Supuestamente, algunos de los hacktivistas que participaron en la extracción de datos de la plataforma utilizaron esto para eludir la autenticación multifactor (MFA) durante la creación de cuentas y extraer información. Esto fue posteriormente refutado por los hacktivistas, y los representantes de Twilio también han declarado que es falso. Una configuración incorrecta de MFA avivaría aún más el debate sobre si los datos de Parler eran verdaderamente públicos, pero no hay suficiente evidencia forense para respaldar ninguna de las dos afirmaciones.
La mayoría de los medios de comunicación han considerado que los problemas de seguridad de Parler fueron el resultado de una mala programación. Aunque es muy probable que las malas decisiones de diseño y los patrones de codificación hayan desempeñado un papel, descartar los tipos de problemas que llevaron a la brecha de Parler simplemente como "mala programación" perpetúa la fricción entre desarrolladores, ingenieros y profesionales de la seguridad.
El desarrollo de aplicaciones modernas y el diseño de sistemas son increíblemente complejos, y requieren que muchas personas, tanto en roles de seguridad como ajenos a ella, trabajen en sincronía para que una aplicación a gran escala funcione sin problemas. El problema empeora cuando se considera la cadena de suministro digital moderna y cómo las organizaciones subcontratan elementos de TI al por mayor o por proyecto. Los errores y las vulnerabilidades son inevitables. Sin embargo, podemos seguir aprendiendo de estos errores para mejorar el estado de la seguridad de las aplicaciones y de las API.
Por qué las herramientas existentes no logran proteger las API contra la autenticación rota
Los controles de seguridad tradicionales, como los WAF, normalmente no aplican la autenticación a un nivel granular y es posible que solo verifiquen la presencia de un identificador de sesión o un token de autenticación en una solicitud determinada. Las puertas de enlace (gateways) de API pueden aplicar la autenticación como parte de las políticas de control de acceso de gestión de API, pero eso supone que los equipos responsables han definido la política de manera adecuada.
A menudo existe una ruptura operativa entre los equipos que crean las API, los equipos que publican las API y los equipos que aseguran las API. Aun así, las puertas de enlace de API carecen de comprensión sobre qué autenticación es la adecuada para una API en un caso de uso determinado.
Los controles de seguridad tradicionales también carecen de capacidades para rastrear el tráfico de ataques a lo largo del tiempo, lo cual es necesario para descifrar las diferentes formas de ataques avanzados dirigidos a la autenticación, como el relleno de credenciales (credential stuffing) y el descifrado de credenciales. A menudo dependerán de tasas excesivas de consumo de API para identificar intentos básicos de ataques de fuerza bruta.
Cómo proteger sus API contra ataques de autenticación rota
Para protegerse contra los ataques de autenticación rota, una solución de seguridad de API debe ser capaz de perfilar la secuencia de autenticación típica para cada flujo de API. La solución puede entonces detectar comportamientos anormales, como credenciales faltantes, factores de autenticación faltantes o llamadas de autenticación que están fuera de secuencia. Determinar la línea base e identificar comportamientos anormales solo puede hacerse analizando grandes cantidades de tráfico de API en producción. Esta forma de análisis es fundamental para mitigar ataques avanzados que se dirigen a la autenticación, como el relleno de credenciales y el descifrado de credenciales.
Para obtener más información sobre cómo Salt puede ayudar a defender a su organización de los riesgos de las API, puede contactar a un representante o programar una demostración personalizada.