Usted implementó OAuth, ¿está protegido?
OAuth es una opción conveniente para las organizaciones a medida que se alejan de las contraseñas. El estándar OAuth es bastante fácil de implementar, y debido a que elimina la contraseña, OAuth parece resolver gran parte del dilema de Ingeniería Social que está plagando a organizaciones de todos los tamaños. Si parece que estoy preparando un problema, lo estoy. Entonces, ¿cuál es el problema? Bueno, antes de explorar las preocupaciones con OAuth, vamos a ver rápidamente exactamente lo que OAuth es.
¿Qué es OAuth, una breve historia
En el nivel más alto, OAuth es un estándar abierto para la autorización. Específicamente, OAuth se utiliza generalmente para proporcionar acceso delegado seguro y reemplazar el mecanismo de autenticación de nombre de usuario/ contraseña con tokens de acceso. OAuth es ideal para su uso previsto, ya que resuelve una serie de problemas inherentes a proporcionar capacidades de Single Sign On (SSO) entre aplicaciones, como eliminar el nombre de usuario y la contraseña de la ecuación. Similar a cómo funcionan los permisos de archivo en carpetas; OAuth también permite controles de grano multado para el acceso compartimentado a los datos que el usuario desea compartir. OAuth puede estar sonando bastante bien sobre ahora, y en realidad es un gran estándar. No es infalible.
¿Cómo OAuth es vulnerable?
Una de las grandes vulnerabilidades inherentes a OAuth es que permite a los usuarios la posibilidad de conceder permisos a elementos de sus datos a aplicaciones de terceros. En un mundo perfecto, esta es una gran característica que permite a los usuarios tener la flexibilidad para conceder acceso granular a sus datos. Desafortunadamente, en el caso del phishing de consentimiento, a menudo se trata de proporcionar acceso a entidades maliciosas y, en el peor de los casos, proporcionar también datos organizativos a esas entidades.
Microsoft detalla los siguientes pasos:
Un atacante registra una aplicación con un proveedor OAuth 2.0, como Azure Active Directory
La aplicación está configurada de una manera que hace que parezca confiable, como usar el nombre de un producto popular utilizado en el mismo ecosistema
El atacante obtiene un enlace delante de los usuarios, que puede ser hecho a través de phishing convencional basado en el correo electrónico, al comprometer un sitio web no malicioso, u otras técnicas
El usuario hace clic en el enlace y se muestra una solicitud de consentimiento auténtico pidiéndoles que concedan los permisos de la aplicación maliciosa a los datos
Si un usuario hace clic en aceptar, le concederá a la aplicación permisos para acceder a datos confidenciales
La aplicación obtiene un código de autorización que canjea por un token de acceso, y potencialmente un token de actualización
El token de acceso se utiliza para hacer llamadas API en nombre del usuario.
Si el usuario acepta, el atacante puede obtener acceso a su correo, reglas de reenvío, archivos, contactos, notas, perfil y otros datos y recursos sensibles.
Un ejemplo específico de phishing de consentimiento OAuth se puede ver en TA2552. Este actor llamado ha estado perpetrando supuestamente ataques O365 desde agosto 2019. Los clientes fueron dirigidos con enlaces que los llevaron a páginas de consentimiento de aplicaciones de terceros legítimos Microsoft. Una vez iniciado el proceso, los usuarios continuaron con el actual proceso de consentimiento O365 concediendo permisos de solo lectura de la aplicación maliciosa a sus datos, específicamente los contactos y el correo del usuario. Como se ve a continuación, las víctimas pueden ser retardadas varias veces durante el mismo intento de phishing de consentimiento.
Fluye desde Proofpoint y más detalles.
Pasos para proteger su organización
No lo deje al usuario
La capacitación en materia de seguridad debe formar parte de la estrategia general de mitigación de riesgos de cada organización. Sin embargo, las pocas horas al año dedicadas a la tarea no están a la altura de la experiencia de toda la vida de la mayoría de los atacantes. Dicho esto, incluso los profesionales de seguridad más experimentados han sido víctimas del phishing y de la suplantación de páginas web. Saque todo lo que pueda de las manos de los usuarios. Implementar autenticación protegida por Full Duplex Authentication® (FDA) lo que hace que sea inviable para el usuario conceder acceso inadvertidamente a las aplicaciones maliciosas. Para obtener más información sobre FDA, lea nuestro libro blanco aquí.
Usar autenticación “Segura por diseño”
Las fortalezas de OAuth también pueden ser debilidades importantes. OAuth fue concebido para ser flexible, y aunque puede ser adecuadamente seguro con el cuidado y la alimentación de un equipo de desarrollo excepcional que se centra en la seguridad, como a menudo puede ser mal implementado y dejado con vulnerabilidades evidentes. En su lugar, implementar la autenticación como NoPass™, que fue construido desde el principio para ser seguro.