Cloud SSO implementations, and how to reduce attack risks
Credentials leaks are still among attackers’ most-used penetration techniques. In 2023 Kaspersky Digital Footprint Intelligence experts found on the darknet more than 3100 ads offering access to corporate resources – some of them owned by Fortune 500 companies. To more effectively manage associated risks, minimize the number of vulnerable accounts, and detect and block unauthorized access attempts quicker, companies are adopting identity management systems, which we covered in detail previously. However, an effective identity management process isn’t feasible until most corporate systems support unified authentication. Internal systems usually depend on a centralized catalog – such as Active Directory – for unified authentication, whereas external SaaS systems talk to the corporate identity catalog via a single sign-on (SSO) platform, which can be located externally or hosted in the company’s infrastructure (such as ADFS).
For employees, it makes the log-in process as user-friendly as it gets. To sign in to an external system – such as Salesforce or Concur – the employee completes the standard authentication procedure, which includes entering a password and submitting a second authentication factor: a one-time password, USB token, or something else – depending on the company’s policy. No other logins or passwords are needed. Moreover, after you sign in to one of the systems in the morning, you’ll be authenticated in the others by default. In theory the process is secure, as the IT and infosec teams have full centralized control over accounts, password policies, MFA methods, and logs. In real life however, the standard of security implemented by external systems that support SSO may prove not so high.
SSO pitfalls
When the user signs in to a software-as-a-service (SaaS) system, the system server, the user’s client device, and the SSO platform go through a series of handshakes as the platform validates the user and issues the SaaS and the device with authentication tokens that confirm the user’s permissions. The token can get a range of attributes from the platform that have a bearing on security. These may include the following:
Token (and session) expiration, which requires the user to get authenticated again
Reference to a specific browser or mobile device
Specific IP addresses or IP range limits, which enable things like geographic restrictions
Extra conditions for session expiration, such as closing the browser or signing out of the SSO platform
The main challenge is that some cloud providers misinterpret or even ignore these restrictions, thus undermining the security model built by the infosec team. On top of that, some SaaS platforms have inadequate token validity controls, which leaves room for forgery.
How SSO implementation flaws are exploited by malicious actors
The most common scenario is some form of a token theft. This can be stealing cookies from the user’s computer, intercepting traffic, or capturing HAR files (traffic archives). The same token being used on a different device and from a different IP address is generally an urgent-enough signal for the SaaS platform that calls for revalidation and possibly, reauthentication. In the real world though, malicious actors often successfully use stolen tokens to sign in to the system on behalf of the legitimate user, while circumventing passwords, one-time codes, and other infosec protections.
Another frequent scenario is targeted phishing that relies on fake corporate websites and, if required, a reverse proxy like evilginx2, which steals passwords, MFA codes, and tokens too.
Improving SSO security
Examine your SaaS vendors. The infosec team can add SSO implementation of the SaaS provider to the list of questions that vendors are required to respond to when submitting their proposals. In particular, these are questions about observing various token restrictions, validation, expiration, and revocation. Further examination steps can include application code audits, integration testing, vulnerability analysis, and pentesting.
Plan compensatory measures. There’s a variety of methods to prevent token manipulation and theft. For example, the use of EDR on all computers significantly lowers the risk of being infected with malware, or redirected to a phishing site. Management of mobile devices (EMM/UEM) can sort out mobile access to corporate resources. In certain cases, we recommend barring unmanaged devices from corporate services.
Configure your traffic analysis and identity management systems to look at SSO requests and responses, so that they can identify suspicious requests that originate from unusual client applications or non-typical users, in unexpected IP address zones, and so on. Tokens that have excessively long lifetimes can be addressed with traffic control as well.
Insist on better SSO implementation. Many SaaS providers view SSO as a customer amenity, and a reason for offering a more expensive “enterprise” plan, whereas information security takes a back seat. You can partner with your procurement team to get some leverage over this, but things will change rather slowly. While talking to SaaS providers, it’s never a bad idea to ask about their plans for upgrading the SSO feature – such as support for the token restrictions mentioned above (geoblocking, expiration, and so on), or any plans to transition to using newer, better-standardized token exchange protocols – such as JWT or CAEP.
Kaspersky official blog – Read More