This post gives a deep dive into a critical security flaw that was present in Flickr’s login flow.
The authentication at identity.flickr.com is implemented using AWS Cognito. By exploiting configuration issues and violations of the OpenID Connect specification, it was possible to takeover any Flickr account without user interaction.
The issue was reported to Flickr via HackerOne on September 17th, the first preliminary fix was applied on that day.
Let us start by having a look at Flickr’s login. Flickr uses Amazon Cognito to implement its login functionality.
On a high level, the flow can be illustrated as follows:
The Amazon Cognito login implements a slightly modified variant of OpenID Connect. If you are familiar with this single sign-on protocol, you will recognize the following Auth. Request and Auth. Response:
Included within the Auth. Response is the access_token that should catch your attention.
Short research may lead to the realization, that this token can be directly used with the AWS Command Line Interface. But before we will have a look at the capabilities of this token, I would like to shame the AWS documentation on Cognito and User Pools. Or at least its German translation. It is simply not readable, after having a short glance into the localized version, I do not wonder anymore why developers tend to misconfigure or misuse these AWS APIs. 🙊
But now back to the topic: Flickr uses a user pool to organize their users. By using the access_token with the AWS CLI tool, we can test which actions are in the scope of our token.
Let us start with the simple GetUser action, which only requires an access_token:
Interestingly, we are able to write this claim. The only constraint appears to be that until the e-mail is verified using a sent code, the email_verified is set to false.
By chance, I tried to authenticate using my account at this time and noticed, that the login flow was broken. Sadly I have no good screenshots from this state. To conclude my observations, Flickr appeared to use the email claim for authentication, and even worse, completely ignored the email_verified claim. After login, I was sent to a page that told me there was no linked account for the given e-mail address. 😯
To understand why this might be an issue, let us have a look at the OpenID Connect Core 1.0 specification on the sub claim:
REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.
This rather short excerpt includes some really important guarantees an Authorization Server gives to its Relying Parties that can be summed up as: You - as a client - can trust the contents within the sub to identify your users.
Strikingly, this guarantee does not exist at all for other claims, like the email claim. For instance, the AWS Cognito user attribute email is case sensitive…
Making Wrong Assumptions
During the login via identity.flickr.com, Flickr normalizes entered e-mail addresses and sends the entirely lower case e-mail address to the backend. Server-side, the same normalization seems to take place before the email claim is interpreted. Therefore, Flickr seems to assume that there will not be any collisions regarding e-mail addresses (e.g. Lauritz.Holtmann@example.com vs. firstname.lastname@example.org).
But, as you already know, by directly tampering with the user attributes via AWS CLI, we could easily create such a situation. 😳
Assembling the Puzzle: Account Takeover
Now we have all information that we need to assemble the puzzle and to takeover any Flickr account (of course this issue was immediately resolved, for more information see Responsible Disclosure Timeline).
To complete the account takeover, login using the malicious, look-alike e-mail address and the attacker’s password.
In the following video, the complete process from the creation of an attacker account to login into the victim account is presented:
Thus, chained, as shown above, the aforementioned issues can be used to takeover a user’s account without any user interaction.
Hints for Developers
There are some takeaways and key issues identified in this post, that need to be considered if you use Amazon Cognito or similar (OAuth / OpenID Connect based) Identity Providers:
Do not rely on other claims than the sub (subject) claim.
If you use Amazon Cognito, evaluate if there is a need to enable users to directly fiddle around with their user attributes using the AWS API. If not, protect all other attributes.
If you use Amazon Cognito, keep in mind that the email claim may hold an unverified e-mail address. The verification status of this claim is reflected by the email_verified claim.
Hints for Security Researchers
Authentication, especially in case there are multiple entities like in single sign-on flows, is error-prone.
If you are interested in this kind of bug, besides having a detailed look at used primitives and technologies, always try to have an eye on the “high-level overview” of an authentication system. Especially where different products and software interact with each other, wrong assumptions are made and security-relevant bugs occur.