PKCE: What can(not) be protected

This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.

At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation“ attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.

In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.

EsPReSSO - A good morning starts with coffee!

In this posts I describe the tool, I wrote for my Bachelor thesis at the Chair for Network and Data Security, with support of Context Information Security Ltd.. EsPReSSO is a apronym for "Extension for Recognition and Processing of Single Sing on Protocols". The basic idea behind EsPReSSO is to automate standard tasks to detect and classify the Single Sign-On (SSO) Protocols OpenID, BrowserID, SAML, OAuth, OpenID-Connect, Facebook Connect and Microsoft Account. The tool is integrate with PortSwigger's HTTP Proxy, Burp Suite. Furthermore EsPReSSO integrates the WS-Attacker, to attack SAML services semi-automated or manually.

Attacking OpenID Connect 1.0 - Malicious Endpoints Attack

In this post we show a novel attack on OpenID Connect 1.0, which compromises the security of the entire protocol - the Malicious Endpoints attack. The idea behind the attack is to influence the information flow in the Discovery and Dynamic Registration Phase in such a way that the attacker gains access to sensitive information.

On the Security of SAML-based Identity Providers

In previous posts we described Single Sign-On (SSO) and the messages within the authentication flow in detail. Additionally, we showed implementation pitfalls on the Service Provider (SP) side resulting in critical vulnerabilities.

In 2012 we started a study about the security of SAML based Identity Provider (IdP). The motivation to make this study was very simple – if the Identity Provider is vulnerable, all Service Providers are affected. In other words – even if the Service Provider is implemented correctly, an attacker can successfully get illegitimate access to restricted resources, e.g. victim's account.

Attacking SSO Part 2: Breaking OpenID in Drupal with Key Confusion

In this Post, we will describe a vulnerability in Drupal's OpenID SSO module that was shipped with Drupal Core prior Versions 6.30 and 7.26. The attack allows an attacker to login as an arbitrary user (even as an Admin), but does not require any interaction with the victim. The vulnerability was reported to the Drupal Security Team and they fixed it at the beginning of 2014 (SA-CORE-2014-001).
To detect the vulnerability, we developed a novel SSO attack technique called Key Confusion. We discovered the attack by setting up our own IdP for analyzing and attacking SSO, see Part 1 of our SSO attack series.

Attacking SSO Part 1: ID Spoofing

In 2013 we started a security study on one of the most widespread SSO protocols: OpenID. As described in previous posts, OpenID is a decentralized protocol, which provides a way to prove that a user controls an Identifier – URL.ID_C. Additionally, OpenID is designed to support the usage of arbitrary IdPs: “An end user can freely choose which OpenID Provider to use ...“.

Considering the properties of OpenID, we came up with the idea to study the relation between the IdP, generating the authentication token, and the Identifier URL.Idc contained in the token. In other words – is this relation critical regarding the security of OpenID implementations deployed on the SPs.

Single Sign-On

Single Sign-On

Using authentication via Single Sign-On (SSO) has many advantages over simple Username/Password mechanisms. Whereas for the latter, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with SSO. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but SSO allows for the adoption of several technical measures to further enhance the security of the login procedure.

Verification of SAML Tokens - Traps and Pitfalls

Verification of SAML Tokens - Traps and Pitfalls

This post will describe some findings in Single Sign-On area and problems related to the security of SAML-based authentication interfaces.

We will describe 6 attacks: Replay Attack, Token Recipient Confusion, Signature Exclusion, XML Signature Wrapping, Certificate Faking and Certificate Injection.

All 6 attacks are related to the SAML SSO interface and are high critical regarding the security.