Many offices are operating with a hybrid of remote and in-person workspaces as the COVID-19 pandemic continues and evolves. Wherever your team is located, security continues to be everyone’s responsibility. A refresher course in cybersecurity is a great way to help employees get back in the swing, and re-establish security best practices they may have forgotten.

This is the third article in this series by Kathleen Moriarty, CIS Chief Technology Officer.

In this article, Moriarty interviews Justin Richer, an internet security expert with over two decades of experience, and author of “OAuth2 In Action,” as well as many OAuth (Open Authorization) extensions. Together they take a deep dive into authentication, authorization, federation, and related technologies.

Related articles in this series:

Why Are Authentication and Authorization So Difficult?
Authentication and Authorization Using Single Sign-On

Moriarty: Strong authentication and dynamic authentication are intrinsic to a zero trust architecture as these measures reduce the chance of an attacker gaining a foothold on your network, moving laterally, or surviving a reauthentication request. It’s not as simple to just deploy these technologies as there are many to choose from and there are lots of deployment considerations to ensure the expected security gains are met. Let’s say an organization has selected a multi-factor authentication (MFA) solution that meets their needs (). They are considering an authorization framework.

What are the high-level considerations for an organization considering OAuth?

Richer: OAuth is a powerful security framework that allows software to act on the behalf of users without exposing their credentials to the software. OAuth is a fairly loose collection of related protocols that are applicable in different environments, and the first choice to be made is which pieces to deploy. The OAuth working group is currently drafting OAuth 2.1 that pulls together many of the best practices from the last decade of experience with this protocol family. In OAuth 2.1, if there is a user involved in the delegation process, the recommendation is to use the Authorization Code Grant with the Proof Key for Code Exchange extension (PKCE). If there is no user involved with the delegation process, the recommendation is to use the Client Credentials Grant. Other grant types and extensions are available for specific applications and use cases, but these two cover the majority of cases.

What security considerations should organizations keep in mind for deployments?

Richer: The OAuth Authorization Server (AS) is the key point for an OAuth system. Since the AS issues access tokens and authorizes the client software, if the AS is compromised, then an attacker could act with impunity on the network by impersonating anyone. This is the core issue behind the Golden SAML attack at the center of the Solar Winds breach. The SAML equivalent of the AS was attacked and its signing keys were stolen, allowing attackers to bypass all the security and authentication requirements in the system by acting as their own AS. Therefore, protection of the AS, its keys, and its storage are of the utmost importance.

Ultimately, the trust model of an OAuth system is a combination of trusting the AS, the client software, and the end users. In a functioning delegation, the end user delegates their access rights to the client software using the AS as a means for accomplishing this. An OAuth deployment needs to be able to answer key questions such as who is allowed to delegate authority, to whom, and for what. These questions will guide deployers in determining how to build and configure their OAuth systems.

The OAuth working group learned quite a bit from a security protocol proofing performed by researchers a few years back. Have the gaps been addressed in available libraries and products?

The OAuth ecosystem is continuously evolving. These days, most libraries support PKCE and related projects, however some naive but well-meaning implementations skip important checks like randomizing and validating the “state” parameter or sharing client identifiers between different pieces of software. It is possible to build out a very secure OAuth ecosystem, but it’s still up to the deployer and developer to implement all the appropriate checks.

What is OpenID Connect and how does OAuth fit into it?

OpenID Connect is an identity protocol built on top of OAuth 2.0. Where OAuth provides software a way to access something on a user’s behalf, OpenID Connect extends this by saying that the software is asking for access to the identity of the end user. In this way, OpenID Connect can leverage all the power and flexibility of OAuth and deliver an authentication technology on top of an authorization technology. OpenID Connect accomplishes all of this by adding several important constructs to OAuth, including an identity assertion (called an ID Token) separate from the access token, as well as a standardized identity API (the UserInfo Endpoint) that is protected by OAuth. The OAuth portions of OpenID Connect can simultaneously be used to grant access to other resources, in addition to the user’s identity, at the same time. In this way, a user can log into a piece of software and let that software access protected functionality on their behalf.

Moriarty: OWASP Top 10 Web Application Security Risks highlights key recommendations to protect against common application vulnerabilities and includes recommendations for OpenID Connect and OAuth, such as the use of a JSON Web Token for cryptographic protection on authorization tokens.

Are these recommendations baked into products and libraries or are there certain actions implementers need to be keenly aware of?

Access tokens need to be constructed in such a way that an attacker can’t generate or modify the token and what it’s good for. The use of JWT as an access token format is one approach that is commonly supported, and another is to use cryptographically random reference tokens that contain no information in them. These tokens can be used with OAuth Token Introspection to look up token information in real time from the AS. Furthermore, key-bound access tokens like OAuth mutual transport layer security (MTLS), OAuth Demonstration of Proof of Possession (DPoP), and the newly-proposed OAuth HTTP Signature binding all make it more difficult for an attacker to steal and use access tokens by tying the token to a key.

The key itself is not sent over the wire with the access token, so theft of both would require a much more advanced attack than simply stealing a valid token in flight from a poorly-configured client or resource. We are seeing an increase in software that supports these more advanced token formats, though bearer tokens (OAuth’s default, which requires no such key) are far and away still the most common.

Moriarty: As mentioned earlier in the blog series, the Security Assertion Markup Language (SAML) vulnerability led to attackers being able to bypass multi-factor authentication in the SolarWinds attack. The only recommendation I’ve seen to avoid this exploit, dubbed a golden SAML attack, is to correlate logs for authorizations back to authentication.

Are there other well-known vulnerabilities in SAML?

Richer: In the SolarWinds attack, the attackers were not only able to create valid assertions that looked just like they had come from the identity provider (IdP) but  they were also able to inject those assertions into waiting applications. SAML’s WebSSO profile is built around the application waiting for such an assertion to be injected from the web browser, which allowed attackers to create active sessions for arbitrary users. The applications being attacked made no difference between waiting for a response to a login request and receiving a request unbidden. SAML does have an Artifact Binding extension that would prevent this, but that extension is largely unused in the wild.

Why might an organization use SAML versus other available federation technologies?

Richer: Federation technologies are often chosen as the least common denominator among the parties who want to federate. Therefore, if both sides speak SAML and not something else, then SAML is the sensible choice because it’s what’s available.

While OAuth is an authorization technology and SAML is a federation technology, might OpenID Connect that includes OAuth be a better option than SAML today?

Richer: OpenID Connect is greatly superior to SAML from a technology standpoint in most measurable ways, especially when used with OAuth 2.0’s best security practices (such as not using the Implicit Grant Type). OpenID Connect also separates the assertion carrying the authentication event (the ID Token) from the conveyance of user account attributes (from the UserInfo Endpoint). SAML combines these both into a single assertion, and also encourages the use of this assertion to access additional resources beyond logging in. The separation of concerns allows for better privacy practices and better efficiency, as attributes don’t need to be passed around all the time. It also enables better security, as selective discloser can be used to limit what attributes are sent for a given transaction. Furthermore, OpenID Connect can be deployed more readily for non-web applications, such as mobile applications.

OpenID Connect also encourages short-lived assertions and the use of proper session management at client applications, as opposed to a single assertion that lives long and should be used at multiple different applications for login. Finally, OpenID Connect’s use of OAuth allows the client application to access additional services and APIs with the same access token, making for a better user and developer experience.

When might you use both OpenID Connect and SAML?

Richer: One would use multiple types of federation technology when the endpoints and environments that they need to connect to already speak those types. It is not uncommon for an organization to expose their identity infrastructure with multiple protocols in parallel to fit these cases. From a user’s perspective, SSO is still achieved as one account allows them to log into multiple applications. There are some cases where an identity proxy is used to translate between one federation protocol and another, allowing two groups to connect to each other that otherwise would be technologically limited. Such situations come with their own risks, such as the proxy being attacked directly or actions being tracked.

Moriarty: You [Richer] havebeen active in the Grant Negotiation and Authorization Protocol (GNAP) working group of the IETF as an author of this new proposed standard. Having been involved in the effort for the design team, the working group has been considering these types of attacks.

What measures are being baked into the Security Considerations for GNAP to prevent attacks like golden SAML?

Richer: The golden SAML attack counts on the attacker being able to create a signed artifact just like the AS and having that artifact accepted by the target to effect a log in or resource access. If the AS’s keys are stolen and those keys are used for things like generating signed access tokens to be trusted by resource servers, then an attacker would be able to create their own trusted access tokens. Technologies like token introspection, which is a built-in option for GNAP, can help this with liveness detection. Additionally, all access tokens in GNAP are, by default, bound to keys associated with client instances. If the resource server is able to validate the identifier for the key in addition to the access token itself, it will be able to further protect itself against accepting bad tokens. Finally, a resource server is going to want to analyze how and where access tokens are being presented. If the same token is rapidly being presented from different parts of the world, for example, that raises suspicion. These are approaches that can be used with OAuth but are more naturally fit for GNAP.

Fundamentally however, the access token is not used to log in a user to an application. That job is given to the assertion next to the access token. The assertion is directed at the client application, not the resource server. While an attacker who steals the AS’s keys would be able to generate a signed assertion, it would be more difficult to insert that assertion into the client application because of how GNAP is designed. Assertions that would constitute a login are only ever passed as a response to a direct HTTP call to the AS, never injected from an untrusted context like a web browser. In order to inject a fraudulent assertion, an attacker would need to impersonate the target AS enough that the client instance would be talking directly to the attacker. This would require things like DNS and certificate poisoning attacks on top of the signing key theft.

Additionally, GNAP is being designed in a dynamic-first mindset, where the relationships between all parties are not necessarily known ahead of time. OAuth and SAML assume that all parties have made agreements to behave nicely ahead of time, and the trust of the network relies on those agreements. While GNAP allows such agreements, they are an optimization on top of a protocol that assumes a dynamic introduction of all actors and components. This dynamic trust model puts less trust into any individual component and more into the overall holistic process. An attacker then has to attack the process itself in order to execute successfully.

We have a number of authorization protocols, why is GNAP important?

GNAP is building on what came before it, in the same way that OAuth 2.0 built on OAuth 1.0, AuthSub, and BBAuth, and the way that OpenID Connect built on OpenID 2.0 and SAML. GNAP is being designed in a forward-facing way that embraces security and privacy in ways we now know are important, and its design takes into account the kinds of applications and deployments you see around the internet today. For example, single-page applications and mobile applications are currently much more common than server-side web applications on a dedicated server, and GNAP’s core design assumptions take that into account. We’re also seeing a push against OAuth’s assumption of the user always being in a web browser, and GNAP accounts for this by having an abstracted and extensible interaction phase. None of this is being built in a vacuum, and all the best aspects of things that have come before are being incorporated. Instead of patching together spot-fixes that often conflict, GNAP is letting us design a better foundation.

Moriarty: From my perspective, it seems that adding another authorization protocol could be confusing to industry.

Would GNAP replace OAuth 2.0 for some implementations and why?

For many systems, GNAP would replace OAuth 2.0 as it can solve the same core problems in a very similar fashion. Where GNAP really shines is the spaces where OAuth is awkward or lacking. In much the same way that OpenID Connect took over the use cases where SAML began to fail – mobile applications and API access, for instance – GNAP can take over in cases where OAuth starts to fall apart, such as cross-application delegation, multi-user and multi-stage access rights, and complex API access. And GNAP is able to do this all with a simplified and clean protocol that fits modern environments.

I’d like to thank Justin Richer for his time and valuable insights!

About the Author

We are pleased to announce the release of the Azure Security Benchmark (ASB) v3 with mappings to the CIS Critical Security Controls (CIS Controls) v8. The ASB includes high-impact security guidance to mitigate against high priority threats. While the ASB is specific to Azure, this mapping shows the applicability of CIS Controls v8 to an enterprise’s cybersecurity program regardless of architecture. If your architecture is cloud-based, on-premise or hybrid, the CIS Controls will work for you!

The Controls v8 update was released this past May. It includes technologies such as cloud and mobile which given the pandemic, proved to be timely as we saw wholesale movement to cloud and work-at-home. And since networks are borderless, we chose to organize v8 by activity instead of by who manages the devices. So, you’ll see some consolidation of Controls like “Secure Configuration of Enterprise Assets and Software.” Also, we added a whole new Control on “Service Provider Management” because so many of you rely on third-party service providers for infrastructure or applications.

The Microsoft Benchmark focuses on cloud-centric control areas with 12 different ASB Control Domains. The CIS Controls provide coverage across all of the domains.  In fact, for several of the domains, such as Network Security and Asset Management, every ASB control maps to one or more CIS safeguards. We also map strongly to new ASB Control Domains such as DevOps Security, confirming the importance of our updates in version 8 to keep up with new threats, technologies (such as cloud), and security-related processes.

Not only can the CIS Controls help an enterprise secure their cloud deployments, but it is equally effective in securing your on-prem deployment. Microsoft’s mapping of ASB v3 to the CIS Controls is yet another example of how CIS security best practices work alongside other frameworks as part of an effective cybersecurity program.

By: Kathleen M. Moriarty, CIS Chief Technology Officer

In order to prevent credential theft from phishing attacks, there is a push for multi-factor authentication (MFA). This is a very important step and should be considered if your organization has not yet made the transition. While MFA adds important protections, how you implement single sign-on, authorization, and/or federation also requires consideration.

The SolarWinds attack bypassed MFA through the use of a vulnerability in a federation technology, Security Assertion Markup Language (SAML), that allowed attackers to bypass end-user credentials entirely. Vulnerabilities in authorization frameworks like OAuth have led to compromise in the past as well. In the first blog of this series, we explored multi-factor authentication and a move away from credentials that can be stolen, as motivated by recent attacks. This blog will dive into authorization and single sign-on to aid in technology selection and deployment considerations. It provides a foundation for the following blog post that introduces emerging standards that have taken into account learnings from the challenges of past protocols, reducing points of vulnerability where possible..

Using Single Sign-on for Simple Authentication

Users want authentication to be simple, requiring less for them to remember and manage. But they also want it to be more secure, in order to protect both their own and their organization’s assets, including data. Environments where users have individual logins to each application are not only more difficult for the end user, but also add complexity when it comes to onboarding new employees, moving employees into new roles, and terminations. A system that unifies logins to a single-sign on, or one that ties the various accounts into an overarching access control system, eases the employee workflow processing. If an employee leaves the organization, the process to remove all account access is greatly simplified with some single sign-on methods.

Single sign-on or reduced sign-on is possible through several models where the user perception is the use of a single or reduced set of authentication methods to access applications:

Stored credentials are accessed using authentication to a cryptographic key or password store (e.g. WebAuthn or password containers). The credentials are then used to authenticate to the appropriate application or service.
Credentials are synchronized across platforms using Lightweight Directory Access Protocol (LDAP) servers.
In the case of public key infrastructure (PKI), an authorized authentication key and certificate are associated to individual services, where the public key is published in a directory service to validate use of the associated private key. For each application, the user account is associated to the appropriate user key and associated certificate.
One-time passwords (OTP) may be used in conjunction with password storage applications that proxy authentication for the user, providing the perception of single or reduced sign-on capabilities.

There are multiple methods that can be used to achieve single or reduced sign-on, with some methods being easier for an environment due to the set of applications and authentication technologies currently in play.

Authorization and Authentication

Authorization is used to grant access to resources. It is often coupled with authentication: in many systems, you must first prove who you are (authenticate) to gain access to capabilities (authorization).  Authorization is the access a user or role is granted to, or within, an application tied to access control models. Stated simply, authorization is about what you can do.

How is authorization to resources accomplished?

In the case of OAuth, a user may authenticate to an application and a second application may accept an authorization credential or token for that user from the first application. You’ve used OAuth if you have granted permissions for one application to ‘authenticate’ using your authorized login to another application such as from Facebook, Gmail, or other services.

Guidance on Authentication and Authorization

Authorization may tie to a more complex access control model where users could be assigned to roles and specific permissions are granted to particular roles.

Federation

Federation grants access across administrative domains. In other words, organizations or separated groups within an organization. An example of this is the use of the federation technology, Shibboleth, across university networks. This Federation technology allows students to use resources, such as library access, at other universities using their credentials from their own school. Federation bridges access across domains, where authentication and authorization are based on the originating organization’s policies. The Shibboleth federation uses the SAML standard to accomplish this today.

Other federation technologies include OpenID Connect, which is built on top of the OAuth authorization framework. Directory Services such as the Lightweight Directory Access Protocol (LDAP) and X.500 are supporting technologies to authentication and authorization frameworks, but are not in themselves authentication, authorization, or federation technologies. They are directory services capable of managing password authentication stores for services as well as synchronization of passwords across services. They are also necessary to enable access to public certificates and certificate revocation lists used in public key infrastructure (PKI).

Directory services enable access to information associated to an index. In the PKI example, properties of the issued certificate, such as the “common name” for a user, enable access to a user’s public encryption key. The functionality of a directory service is to provide an index to information made available publically, or to an access controlled set of data. The access controls could be a combination of users, roles, as well as parts of the directory structure. This distinction is important for understanding the supporting infrastructure and components in an identity and access management framework.

NIST Special Publication 800-63C

NIST Special Publication 800-63C provides detailed and technical explanations on Federation and assurance. This blog is intended to introduce the topics and current considerations at a higher level. In teaching Security Architecture and Design at Georgetown University, it has become apparent that more accessible documentation would be helpful as an introduction to these complex topics.

About the Author

CIS-CAT Pro is a tool used to evaluate the cybersecurity posture of a system against the recommended policy settings outlined in the CIS Benchmarks. Following the release of CIS-CAT Pro Assessor v4, the Center for Internet Security (CIS) will cease support for CIS-CAT Pro Assessor v3. Its final release will occur in November 2021.

What End of Life Means for Assessor v3

CIS will stop delivering and supporting CIS-CAT Pro Assessor v3. Version 3.0.76 will mark the final delivery of this tool. This release also contains updated third-party dependencies to resolve security vulnerabilities. See our knowledge base article for more information on security risk.

Changes in the Final Release

This final release of CIS-CAT Pro Assessor v3 requires a Java Runtime Environment (JRE), Java Development Kit (JDK), or open JDK versions of Java 8. We have updated third party libraries that support assessor activities in this release. These new updates require Java 8, at a minimum.

The Assessor v3 dissolvable version has been updated to operate with Java 8.

Still Need Assessor v3?

CIS-CAT Pro Assessor v3 will remain available until November 2022.

The CIS Support Team will assist CIS SecureSuite Members with questions regarding the availability of the tool, but will no longer offer support on the function of the tool.

Read about Assessor v3’s limited use guidelines in our knowledge article.

Assessor v3 and CIS Benchmarks

Assessor v3 will include CIS Benchmarks officially supported for use with this final version. Future and past CIS Benchmark versions for the technologies supported by Assessor v3 may work with the final tool version, but are not guaranteed and should be used at the Member’s discretion.

Members requiring the ability to assess against older Benchmarks that aren’t supported in Assessor v4 can continue to utilize v3 until the Benchmark is supported in v4 or reaches its end of life (HP UX, Cisco ASA Firewall, Oracle Solaris OS, IBM AIX). If Member demand supports the need for the tool to support these CIS Benchmarks after November 2022, CIS will evaluate extending the availability date.

Other Assessor v3 Functions

Members are advised to no longer utilize Assessor v3 for vulnerability assessments. Since Assessor v3 will not be updated monthly with new CVE information, the vulnerabilities will quickly go out-of-date. Members are encouraged to utilize Assessor v4 for vulnerability assessments going forward.

CIS-CAT Pro Assessor v3 is a Security Content Automation Protocol (SCAP) validated tool. Members requiring some use of a NIST validated tool can continue to use Assessor v3 when necessary. CIS-CAT Pro Assessor v4 is architected in compliance with SCAP, but has not yet been formally SCAP validated. CIS currently plans to pursue SCAP 1.3 validation for CIS-CAT Pro Assessor v4 in 2022.

The Assessor v3 dissolvable bundle includes Java version 8 in this final release. With CIS-CAT Pro Assessor v4, we plan to offer an embedded Java for command line activities in 2022.

Still have questions?

Join the CIS-CAT Discussion Community on CIS WorkBench and start a discussion! Reach out to CIS Support and ask for the feedback ticket to be directed to the CIS-CAT Product Owner.

Where to Get CIS-CAT Pro Assessor

CIS-CAT Pro Assessor and Dashboard save you hours of configuration review by scanning against a target system’s configuration settings and reporting the system’s compliance to the corresponding CIS Benchmark. These tools are available as part of a CIS SecureSuite Membership. Members can download these tools and other resources on CIS WorkBench.

Not a Member yet? Learn more about CIS-CAT Pro Assessor at one of our free webinars.

You can also try CIS-CAT Lite v4 at no cost.