Is SeamlessAccess Secure Enough?
SAML can be compromised, and critics of IP addresses may have done lasting harm
SeamlessAccess — the main result of the work around RA21 — is currently in beta. The goal of SeamlessAccess is to allow people to log in to content purchased by their employer or institution no matter where they are, using a technology stack that achieves “an optimal balance between security and usability.” A big part of this is a reliance on the Security Assertion Markup Language (SAML).
In the promotional messaging for an upcoming webinar about SeamlessAccess, the security is touted as follows:
The service promotes digital authentication leveraging an existing single sign-on infrastructure through one’s home institution while maintaining an environment that protects personal data and privacy.
SAML improves security over basic username and password authentication, for a variety of technical reasons. However, it is not bulletproof, and its security claims may need to be re-examined in the wake of the recent and reverberating SolarWinds attack.
The SolarWinds attack on US infrastructure was in high gear between March and June 2020, with thousands of companies affected. Russia has been identified as the perpetrator. The amount of information exfiltrated — or systems infiltrated — is unknown.
On December 17, 2020, the US Cybersecurity and Infrastructure Security Agency (CISA) released an alert about the SolarWinds attack, noting specifically that:
. . . one of the principal ways the adversary is accomplishing this objective is by compromising the Security Assertion Markup Language (SAML) signing certificate using their escalated Active Directory privileges. Once this is accomplished, the adversary creates unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via authorized application programming interfaces (APIs).
Updates to this go into further detail about how SAML was exploited.
While username and password access controls can be easily defeated, the access gained is relatively narrow in most cases — unless an administrator’s credentials are stolen. With SAML, one of the big risks is that if the system is compromised at all, the entire structure could be considered compromised — the technology can create an “all or nothing” situation, with CISA writing:
. . . if organizations identify SAML abuse in the environment, simply mitigating individual issues, systems, servers, or specific user accounts will likely not lead to the adversary’s removal from the network. In such cases, organizations should consider the entire identity trust store as compromised. In the event of a total identity compromise, a full reconstitution of identity and trust services is required to successfully remediate. In this reconstitution, it bears repeating that this threat actor is among the most capable, and in many cases, a full rebuild of the environment is the safest action.
If you want to read more about this is generally done, there is a decent outline here.
Late last week, the NSA, CISA, and the FBI issued a more updated and detailed warning, again noting that Russian hackers are:
Forging web credentials: SAML tokens. An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token-signing certificate.
In the midst of this, it’s becoming clearer with each passing day that Sci-Hub has been a front for Russian hackers seeking to gain access to academic institutions, research labs, and researcher accounts in general. With academia and research centers in the crosshairs, the security of SAML-based authentication becomes more and more of a central concern.
In the push to roll out SeamlessAccess, traditional IP-based access controls have been disparaged in order to push traditional access controls aside. These disparagements have been a little head-scratching, and employ three basic techniques:
- Dismiss. In some presentations and communications about SeamlessAccess, project managers and others have simply dismissed IP-based access as outdated, outmoded, or odious to the extreme, despite its general success and popularity with users.
- Double-talk. There is occasionally some double-talk about imaginary security holes in IP authentication, conflated at times with talk about the inconvenience of administering large IP-based access portfolios.
- Doubt. Then, there is just the rhetoric of doubt use, which conflates the two above — it’s old, that means it has to be rickety, so better to use this shiny new technology, SAML.
A few years of loose talk fostering unwarranted doubts about IP access may have done lasting harm to perceptions, and that would be a shame. In the struggle for safety and security online, we need to have sober assessments of options.
Where SeamlessAccess makes its best points is around convenience — there is no doubt that for off-campus access, SeamlessAccess can be easier for the user. But VPNs have become more common, and convenience (or salesmanship) is no reason to brush the potential security limitations of SAML under the rug, or to denigrate other options that may be more secure, especially given the rash of cybercrime we’re experiencing.
The stakeholders for SeamlessAccess have also made its source code available, linking right into an Atlassian page and posting source code on Github. After reading “This Is How They Tell Me the World Ends: The Cyberweapons Arms Race” by Nicole Perlroth, I’m wondering if this is such a good idea. Providing the source code to people seeking to exploit holes in security may not be the wisest of moves.
If there is a balance of “security and usability,” the world may be turning more toward “security.” And if IP-based access has been wrongly slandered as insecure, it may seem to some there are no useful alternatives — which would leave Russian hackers with a landscape they know how to work, the source code to SeamlessAccess, and a lot of practice exploiting SAML vulnerabilities.
I sense some potential problems we might want to avoid.