Security Analysis in an OpenID Connect Lab Environment

In this post, Christian Fries shows an approach to unveil security flaws in OpenID Connect Certified implementations with well-known attack methods. One goal of the master's thesis Security Analysis of Real-Life OpenID Connect Implementations was to provide a platform for developers and security researchers to test implementations in a reproducible and maintainable OIDC lab environment.

We included six OpenID Provider (OP) and eight Relying Party (RP) services in the lab environment. For the comprehensive security analysis, we tested the implementations against eleven Relying Party attacks and seven OpenID Provider attacks in different variations with our tool PrOfESSOS. In addition, we carried out manual tests as well. We have disclosed twelve implementation flaws and reported them to the developers in a responsible disclosure process.

Two developer teams fixed (✔) the vulnerabilities before the deadline of the master's thesis. One Redirect URI Manipulation vulnerability was rejected (✖). This particular case can be permissible for only one registered URI for reasons of interoperability and fault tolerance. We informed three further development teams (✦).

Name	Vulnerability	Fixed	CVE
MITREid Connect	PKCE Downgrade Attack	✦
mod auth openidc	ID Spoofing, JWKS Spoofing	✔
node oidc-provider	Redirect URI Manipulation	✖
OidcRP	Replay Attack	✦
phpOIDC	Message Flow Confusion, ID Spoofing, Key Confusion	✦
pyoidc	Replay Attack, Signature Manipulation, Token Recipient Confusion	✔	CVE-2020-26244

We explain the method of how we have archived this result in the following sections.

Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations

This is a guest blogpost by Lauritz Holtmann. He wrote his master thesis:

"Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations"

Lauritz summarizes his exciting results in the following. The thesis was supervised by Vladislav Mladenov, Christian Mainka, and Jörg Schwenk. You can read find his full thesis here.

OpenID Connect 1.0 and OAuth 2.0 are the Single Sign-On Protocols that are implemented in modern web applications. In this post, we outline common issue patterns that were discovered in popular OpenID Connect implementations, give concrete examples of vulnerabilities, and give recommendations for adjustments to the OpenID Connect specification.

Not so Smart: On Smart TV Apps

One of the main characteristics of Smart TVs are apps. Apps extend the Smart TV behavior with various functionalities, ranging from usage of social networks or payed streaming services, to buying articles on Ebay. These actions demand usage of critical data like authentication tokens and passwords, and thus raise a question on new attack scenarios and general security of Smart TV apps.

These reasons make it interesting enough to do some research on smart TVs. We wrote a paper with the title "Not so Smart: On Smart TV Apps", which will be presented in a few days at the "International Workshop on Secure Internet of Things" (SIoT 2015). In this paper, we investigate attack models for Smart TVs and their apps, and systematically analyze security of Smart TV devices. We point out that some popular apps, including Facebook, Ebay or Watchever, send login data over unencrypted channels. Even worse, we show that an arbitrary app installed on devices of the market share leader Samsung can gain access to the credentials of a Samsung Single Sign-On account. Therefore, such an app can hijack a complete user account including all his devices like smartphones and tablets connected with it. Based on our findings, we provide recommendations that are of general importance and applicable to areas beyond Smart TVs.

Single Sign-On: The OpenID Protocol

In one of the previous posts, we explained SSO on the example of SAML.In this post, we will introduce another popular and widely deployed SSO Protocol: OpenID (if you are not familiar with SSO, we recommend you to read SSO on the example of SAML first).

Detecting and exploiting XXE in SAML Interfaces

This post will describe some findings, problems and inisghts regarding XML External Entity Attacks (XXEA) that we gathered during a large-scale security analysis of several SAML interfaces.
XXEA has been a popular attack class in the last months, see for example

• How we got read access on Google’s production servers
• XXE in OpenID: one bug to rule them all, or how I found a Remote Code Execution flaw affecting Facebook's servers

This post will explain the basics of XXEA and how to adopt them to SAML, including some special problems you have to cope with.

First, we introduce the concept of Document Type Definition (DTD) and XML External Entity (XXE), and afterwards some basics on SAML. If you are fimiliar with these concepts, you may want to skip these sections and go to the last section XXEA on SAML.

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.