Security researchers from the University of Trier have discovered a couple of vulnerabilities in the OAuth 2.0 authentication protocol that could enable hackers to subvert single sign-on systems. The protocol is widely used on social networking sites, such as Facebook and Google+, to authenticate users.
According to researchers Daniel Fett, Ralf Küsters and Guido Schmitz two previously unknown attacks on OAuth, which both break authorisation and authentication in OAuth were found and these vulnerabilities were also present in the new OpenID Connect standard and can be exploited in practice. The exploits could be used capture credentials to impersonate a user or access user data.
In a PDF submission to Arxiv, the researchers said in the first attack (known as an HTTP 307 Temporary Redirect), identity providers (IdP) inadvertently forward user credentials (ie, username and password) to the relying party (RP) or the attacker. In the second attack, a network attacker can impersonate any victim.
“This severe attack is caused by a logical flaw in the OAuth 2.0 protocol and depends on the presence of malicious identity provider,” the researchers said.
“In this attack, the attacker (running a malicious RP) learns the user's credentials when the user logs in at an IdP that uses the wrong HTTP redirection status code.”
The researchers said that in order to fix this problem, only HTTP 303 codes should be permitted in OAuth, since “the 303 redirect is defined unambiguously to drop the body of an HTTP POST request”.
The second flaw involves an attack on the RP website: “The attacker confuses an RP about which IdP the user chose at the beginning of the login/authorisation process in order to acquire an authentication code or access token which can be used to impersonate the user or access user data.”
The man-in-the-middle (MitM) attack enables a hacker to change user data and fool the RP into treating it as the IdP the user wants.
“As a result, the RP sends the authorisation code or the access token (depending on the OAuth mode) issued by the honest IdP to the attacker, who then can use these values to login at the RP under the user's identity (managed by the honest IdP) or access the user's protected resources at the honest IdP.”
The researchers said to fix this, OAuth should include the identity of the IdP in the redirect in some form. “More specifically, we propose that RPs provide a unique redirection endpoint for each IdP. Hence, the information which IdP redirected the browser to the RP is encoded in the request and the RP can detect a mismatch.”
Ian Muscat, product communications manager at Acunetix, told SCMagazineUK.com that in hardening OAuth authentication processes against attacks, “When it comes to authentication and authorisation processes within a web application, unless you have a profound understanding of the technology, and a specific, justifiable, carefully considered reason, do not roll your own authentication implementation.”
“Instead try to pick a library or framework which has received public scrutiny and has an active, community around it that treat security as a high-priority goal,” he said.
Conor O Neill, managing consultant at Espion, told SC that there is a built-in protection mechanism in OAuth 2.0, the ‘state' parameter, which is a unique synchroniser token. “Organisations should ensure this is submitted with each OAuth request,” he said.
Liviu Itoafa, security researcher at Kaspersky Lab, told SC that attacking the relying party website is dependent on the culprit needing to be in the same network as the user in order to manipulate the initial request and the traffic, something which is possible within internal networks.
“This issue implies there must be an issue on the relying party side – for example not requiring HTTPS for the initial request to the user,” said Itoafa.