[03/08/2020] La reciente vulnerabilidad "Iniciar sesión con Apple" le valió a un investigador 100 mil dólares como parte del programa de recompensas por errores de Apple. La falla surgió de una implementación al estilo de OAuth que no validaba correctamente la autenticación de JSON Web Token (JWT) entre las solicitudes. Esto habría permitido a un actor malintencionado "Iniciar sesión con Apple" utilizando el ID de Apple de cualquiera.
La gravedad de la falla, la sencillez con la que fue causada y la facilidad con la que se podría haber evitado sugieren que debería revisar las implementaciones del sistema de inicio de sesión único (SSO, single sign-on) utilizadas por los sistemas de su empresa para ver cómo protegerlos mejor. El SSO es un enfoque centralizado de la autenticación y la autorización, que mejora la seguridad general y la experiencia del usuario (UX) al evitar que el usuario final se registre o acceda repetidamente a un servicio.
Por lo general, las fallas de autenticación como ésta pueden ocurrir debido a la falta de una auditoría de seguridad adecuada del flujo de trabajo. Además, cuando se adquieren productos de gestión de la identidad de los proveedores, sin verificar si se ajustan estrictamente a las especificaciones de la industria, pueden producirse errores garrafales como éste. Estas son las medidas de seguridad que necesita tener en su lugar:
Realice auditorías de seguridad durante la adquisición del SSO
Aaron Zander, jefe de TI en HackerOne, señala que como OAuth es un estándar abierto, todos tienen la responsabilidad de mejorarlo. "Para el mundo empresarial, la mayoría utiliza herramientas como Okta, Azure AD SSO, las ofertas de Google o, cualquiera de la otra media docena o más de los principales proveedores. Todos están construidos aprovechando OAuth, Lenguaje de Marcado para Confirmaciones de Seguridad (SAML, por sus siglas en inglés) o el Sistema de Gestión de Identidad de Dominio Cruzado (SCIM), todos ellos son lenguajes abiertos que dependen de otras técnicas de endurecimiento, como los certificados X.509 [de cifrado], para mantenerse seguros".
Las empresas no se centran lo suficiente en las normas de adquisición como para garantizar que las herramientas tengan SSO y, aprovisionamiento y desaprovisionamiento, indica Zander. "A menudo se consulta demasiado tarde a las áreas de TI y seguridad en el proceso de selección de herramientas, lo que significa que ya se han hecho elecciones, se ha gastado dinero y las herramientas adquiridas no utilizan SSO. El poder de este se basa en el hecho de que cuantas más herramientas lo utilicen, más fuerte serás", explica Zander.
Autenticación multifactor (MFA) obligatorio
Como ocurre con cualquier sistema de autenticación basado en contraseñas, el hecho de tener un segundo factor de autenticación puede no garantizar la seguridad total, pero impide incidentes de compromiso a largo plazo. "Una de las partes más olvidadas y débiles de cualquier herramienta SSO es la forma en que la gente se conecta a ella. Demasiadas organizaciones siguen confiando en contraseñas demasiado cortas, que se rotan con demasiada frecuencia y no requieren MFA para todo", señala Zander.
Zander recomienda fortalecer los vínculos más débiles en un flujo de trabajo de SSO, lo que incluye políticas sobre la selección y rotación de contraseñas. Los usuarios deberían emplear contraseñas fuertes (de al menos 32 caracteres de longitud con caracteres aleatorios) que necesiten ser rotadas con menos frecuencia, y las organizaciones deberían utilizar el MFA en sus implementaciones de SSO.
Evaluar la colocación arquitectónica y los protocolos en uso
Su solución SSO puede cumplir con las especificaciones de la industria y ser segura. Sin embargo, el lugar donde se encuentra en la arquitectura de TI de su organización puede marcar una gran diferencia. Por ejemplo, ciertos arreglos arquitectónicos pueden enmascarar las direcciones IP de origen, lo que supone un desafío.
"La colocación arquitectónica de una solución SSO u OAuth en su modelo de autenticación es muy importante", anota Morey Haber, CTO y CISO de BeyondTrust. Si depende de un proxy web, en un filtro de contenido web basado en agentes, en una VPN u otra tecnología de tunelización, la colocación de la solución SSO puede silenciar la dirección IP real del usuario de origen. Esto se debe a que la tunelización podría ser solicitada primero y la fuente de todo el tráfico podría provenir de la misma ubicación".
Muchas estrategias de seguridad se basan en la inclusión automática de las direcciones IP maliciosas en una lista negra para evitar el acceso a un sistema o permitir que solo una subred IP específica se conecte a uno. Si no puede analizar las IPs de origen antes de que el tráfico sea tunelizado al sistema SSO, se convierte en un reto limitar la exposición del sistema solo a sus usuarios previstos.
"Asegúrese de que la tecnología sea correctamente colocada en su pila de autenticación para que pueda ver la verdadera fuente de la dirección IP del usuario para brindar conocimiento de la situación con base en la geolocalización", sugiere Haber.
En el caso de las implementaciones de SAML, la identificación de pares y la verificación criptográfica pueden aumentar en gran medida la confianza en el sistema "basado en la confianza". Pascal Geenens, director de inteligencia de amenazas de Radware, señala, "En mi experiencia con [SAML], el mejor consejo que puedo ofrecer a las empresas es asegurar la identificación y validación de pares mediante certificados, ya que todo el SSO depende de la confianza entre los pares del sistema".
Los consejos prácticos aplicables al entorno de su empresa variarán en función de los protocolos que se utilicen y del contexto (local, por Internet, etc.). Las repercusiones en materia de seguridad serán diferentes para cada tipo de sistema, lo que requerirá diferentes enfoques de reparación, dado el modelo arquitectónico general.
Geenens sugiere que se consideren las diferencias entre las tecnologías. JWT, utilizada por Sign in with Apple, es una especificación para JSON Web Token que puede ser utilizada directamente por las aplicaciones o, para construir protocolos personalizados de autenticación o autorización. OAuth y SAML son protocolos de autenticación y autorización estandarizados. Kerberos SSO, Microsoft SSO y AD/LDAP están diseñados para ser utilizados dentro de la empresa (LAN), mientras que SAML y OAuth están construidos para el uso de Internet".
Considere la posibilidad de utilizar alternativas seguras
Así como hay HTTPS para asegurar HTTP y, FTPS y SFTP para FTP, hay protocolos más seguros para su configuración SSO existente. "LDAPS es una configuración de LDAP que hace que su conexión entre el directorio activo y otras conexiones externas sea aún más segura", explica Jeff Roscher, presidente de eWorkOrders. "Añada una capa extra de protección usando TLS con certificados y claves de seguridad. En eWorkOrders, utilizamos LDAPS para permitir a los clientes utilizar sus propias contraseñas cuando se conecten al CMMS en lugar de crear, rastrear y administrar diferentes credenciales de inicio de sesión para diferentes sistemas".
El LDAP seguro (LDAPS) es una configuración personalizada de "LDAP sobre TLS" y no una parte del estándar real de LDAP. Por lo tanto, se recomienda llevar a cabo algunos pasos de verificación adicionales. Compruebe si la biblioteca LDAPS que está utilizando está implementando correctamente la SSL en lo que respecta a las validaciones de nombres de host y certificados.
Limite la exposición total y la validez de la sesión
Su solución SSO podría venir con una validez de sesión preconfigurada y una configuración predeterminada. Revíselos y ajústelos con un enfoque en la seguridad. Por ejemplo, ¿qué sucede cuando un usuario inicia sesión en una aplicación a través de una cuenta de Facebook? ¿La aplicación debe ser autorizada indefinidamente a través de sus credenciales de Facebook, o hay un límite en la validez de esta autorización? Pedir a los usuarios que vuelvan a autorizar servicios y aplicaciones a través de su sistema SSO de vez en cuando puede ser de gran ayuda para la seguridad, ya que disuade a las aplicaciones fraudulentas con acceso ilimitado y no controlado.
"Para el tránsito recomendamos usar HTTPS, no HTTP, y el cifrado de la afirmación SAML para asegurar la confidencialidad", anota Piyush Pandey, CEO de Appsian. "La implementación de la firma de la solicitud SAML/SAML request signature es importante para asegurar la integridad del mensaje también. Otras recomendaciones de verificación son la validación del tiempo de caducidad de la afirmación, la verificación cruzada del ID de la entidad IdP y el ID de la entidad [proveedora de servicios], [y] asegurarse de que las afirmaciones no puedan ser reutilizadas." Por último, utilice la validación 'InResponseTo' para evitar ataques de repetición".
Las validaciones que recomienda Pandey, especialmente las que tratan sobre el tiempo de caducidad de la afirmación y las respuestas, son fundamentales para prevenir los ataques de repetición.
Seguir todas las estrategias mencionadas, y realizar regularmente exámenes de penetración de seguridad y auditorías, puede ayudar enormemente a aumentar la seguridad en torno a su infraestructura de gestión de la identidad corporativa.
Ax Sharma, CSO (EE.UU.)