Penetration Test Report (Cure53): pentest report fxa

Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Pentest-Report Mozilla FxA 09.2016
Cure53, Dr. M. Heiderich, T. C. Hong, A. Inführ, M. Kinugawa, D. Weißer,
N. Hippert, Dr. J. Magazinius
Index
Introduction
Scope
Identified Vulnerabilities
FXA-01-001 HTML injection via unsanitized FxA relier Name (Critical)
FXA-01-003 XSS via unsanitized URI Scheme of redirect_uri of FxA relier (Medium)
FXA-01-004 XSS via unsanitized Output on JSON Endpoints (High)
FXA-01-008 Missing Access Revocation of authorized FxA relier (Medium)
FXA-01-011 Refresh Token & Auth Code not invalidated after Revocation (Medium)
FXA-01-014 Weak client-side Key Stretching (High)
Miscellaneous Issues
FXA-01-002 Sensitive Information in localStorage not cleared after Sign-Out (Low)
FXA-01-005 Unexpected Sign In via Password Reset (Medium)
FXA-01-006 Missing Security Headers on OAuth APIs (Info)
FXA-01-007 Reusable Authorization Code on OAuth Server (Low)
FXA-01-009 Parameter ttl not effective on Token Endpoint (Low)
FXA-01-010 Possible RCE if Application is run in a malicious Path (High)
FXA-01-012 Query Results exposed in client token delete Endpoint (Low)
FXA-01-013 Insecure Property Access / Method Calls on Content Server (Info)
FXA-01-015 Session Tokens do not expire (Low)
Conclusion
Cure53, Berlin · 10/10/16 1/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Introduction
“Firefox Accounts (FxA) is an identity provider that provides authentication and user
profile data for Mozilla cloud services. We are also exploring the possibility of allowing
non-Mozilla services to delegate authentication to Firefox Accounts.
Creating a Firefox Account requires a user to give us a pre-existing email address and
choose a password. The user must verify their email address via an email link sent to
the email address she provided. The user will not be able to login to attached services
prior to verifying her email address. To login to an existing Firefox Account, the user
must provide the email address and password given during account creation. If the user
forgets her password, she can reset via an email link sent to the email address given
during account creation.
All new relying services should integrate with Firefox Accounts via the OAuth 2.0 API.
There is also a legacy API based on the BrowserID protocol, which is available only in
some Firefox user agents and is not recommended for new applications.”
From https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Firefox_Accounts/Introduction
This penetration test and source code audit against the Mozilla FxA was carried out by
Cure53 in September and October of 2016. The test was conducted by seven members
of the Cure53 team over a period of 30 days. The investigations, which have yielded a
total of fifteen findings, pertained to the source code of a variety of involved backend
applications and front-end applications, as well as other tools that are part of the Mozilla
FxA ecosystem.
The main goal of this test was to find out whether the code, the infrastructure and
processes defining the Mozilla FxA ecosystem are secure or if they perhaps expose a
sizable, exploitable attack surface. In order to asses that, Cure53 made use of test- and
staging-servers maintained and ran by Mozilla. In addition, the testing team set up a
separate FxA infrastructure of their own to test the system in a more isolated and
customizable manner. As the tests progressed, the spotted issues were filed directly into
a private GitHub repository to give Mozilla the possibility to directly comment on all
findings. This setup made it possible for the findings not only to be addressed quickly,
but also to obtain fix verification from the Cure53 testers when the assessment was still
ongoing. A dedicated password-protected IRC channel was a further facilitator of the
communication between the Cure53 and Mozilla’s in-house team. It has been used to
discuss the results in detail and let Cure53 ask urgent questions and receive prompt
feedback.
Cure53, Berlin · 10/10/16 2/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Needless to say, the combination of live-reporting into GitHub and the chat channel
made this test a very efficient experience. As a consequence, the Cure53 was able to
finalize the test and acquire full coverage in fewer days than the number agreed upon.
Moving on to the test results, the first important impression is about the quality of the
code, which appears well-written and easy to read. In addition the Mozilla FxA team was
highly knowledgeable about their product, so all technical queries were professionally
and precisely answered. The actual fifteen findings of the test could be categorized into
two groups of issues: six security vulnerabilities and nine general weaknesses. Only one
of the discoveries has received a “Critical” ranking due to its severity. More specifically,
as described in FXA-01-001, it would have been possible for an evil “relier” to cause
Cross-Site-Scripting (XSS), and thereby get illegitimate access to heavily sensitive
authentication data. Additional two issues were flagged as “High” and all these three
issues warranted immediate attention. The remaining findings were considered to be of
Medium-to-Low impact, ultimately signaling a positive result of this assessment.
Scope
• The scope of work mainly encompasses the FxA Authentication service, that is an HTTP
API authenticating the user, enabling the user to authenticate to other services via
BrowserID assertions, as well as making the password operations (change/reset)
possible. The sources were made available for the test via GitHub repository; the
production system to test against was also provided.
◦ Source: https://github.com/mozilla/fxa-auth-server
• Further included in the scope was the OAuth Service: an HTTP API that implements a
standard OAuth2 grant flow and accepts BrowserID assertions from the auth-server as
authentication.
◦ Source: https://github.com/mozilla/fxa-oauth-server
• Another component of the work scope was the Profile Service: an HTTP API
authenticated via OAuth2 which manages user profile information such as display-name
and profile picture
◦ Source: https://github.com/mozilla/fxa-profile-server
• The scope of this project also entailed the Content Service: a static assets (HTML,
JavaScript, CSS, etc.) hosting service that supports user-interactions with FxA. The
responsibilities of the Content Server include:
◦ Hosting a JavaScript library that supports interactions with the Auth and OAuth
◦ Hosting login and create account pages
◦ Hosting password reset pages
◦ Hosting landing pages for email verification links
◦ Hosting UI pages for the OAuth login flow
Cure53, Berlin · 10/10/16 3/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
◦ Sources:
▪ https://github.com/mozilla/fxa-content-server
▪ https://github.com/mozilla/fxa-js-client (JavaScript client)
• Last scope item pertains to the Customs Server: a rate limiting and fraud detection
service that integrates with the authentication service.
◦ Source: https://github.com/mozilla/fxa-customs-server
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. FXA-01-001) for the purpose of facilitating any
future follow-up correspondence.
FXA-01-001 HTML injection via unsanitized FxA relier Name (Critical)
It was found that the name of a FxA relier is directly showed without any sanitization.
This means that the attackers have the opportunity to inject arbitr