In order to answer any questions you may have related to the Public Disclosure on 4 April 2018, we have assembled a list of common questions.
FAQ Table of Contents
- Q: What is the CVE for Audience vulnerability?
- Q: What is the CVE for the CSRF vulnerability?
- Q: Is this related to the CVE posted at the end of February?
- Q: How is Auth0 monitoring the CSRF vulnerability?
- Q: How can I, as customer, monitor the CSRF vulnerability?
- Q: Why was I not informed about the vulnerability before public disclosure?
- Q: Is there any action that we need to take now that the vulnerability is public?
- Q: I’m on the latest version of Auth0.js 9 and/or Lock 11, is there any action that we need to take when the vulnerability is made public?
- Q: Will Auth0 be providing an official notification that we are no longer vulnerable to attacks associated with the disclosed CVEs?
- Q: Am I vulnerable? What do I have to do?
- Q: Auth0 said that the other deprecations (/tokeninfo, /delegation, /oauth/ro, /oauth/access_token, usage of id_token on Management API) were delayed. Am I vulnerable if I didn’t do them yet?
- Q: If Auth0 fixed this, do I still need to upgrade to Lock11/auth0.js v9?
- Q: What is Auth0 doing to ensure this doesn’t happen again?
- Q: My security dept requires that we fill out an RCA and mitigation report (or other corporate procedures for outages, vulnerabilities, risks, etc). Will Auth0 provide those?
- Q: This sounds serious - why should I trust Auth0 after this?
- Q: What happens on July 16, 2018?
Q: What is the CVE for Audience vulnerability?
CVE-2018-6873 - The Audience vulnerability was discovered by Cinta Infinita in October 2017. This was fully patched within four hours for cloud customers and within two weeks for Private SaaS Appliance customers (see blog post).
Q: What is the CVE for the CSRF vulnerability?
CVE-2018-6874 - The CSRF vulnerability was discovered by Auth0 during the course of investigating the Audience vulnerability. This was the impetus behind the Responsible Disclosure program and the deprecation of affected endpoints (usernamepassword/login, /ssodata). The severity of this vulnerability has been significantly reduced - not eliminated - due to the implementation of the server side mitigation on April 3, 2018 (see blog post).
Q: Is this related to the CVE posted at the end of February i.e. [CVE-2018-7307](https://auth0.com/docs/security/bulletins/cve-2018-7307)?
No. This was an unrelated vulnerability.
Q: How is Auth0 monitoring the CSRF vulnerability?
Due to the nature of the vulnerability, it is not possible to monitor for signs of exploitation.
Q: How can I, as customer, monitor the CSRF vulnerability?
Due to the nature of the vulnerability, it is not possible to monitor for signs of exploitation.
Q: Why was I not informed about the vulnerability before public disclosure?
Throughout this coordinated disclosure effort, we have been as transparent as the situation allowed given the sensitivity of the vulnerabilities in question. We were able to disclose the vulnerability confidentially to customers with a signed Non-Disclosure Agreement (NDA) in place; unfortunately, this limited our outreach to customers with enterprise plans only.
At the same time, however, we made several efforts to urge customers to migrate before the original April 1, 2018, deadline. These efforts included multiple Account Center notifications as well as a public-facing announcement and FAQ on our Community site. In addition, we’ve ensured that all customers will benefit from the server side mitigation described in the blog post. Given the reduced severity, we believe that the extension to July 16, 2018, will give all customers ample time to migrate to Lock 11 and/or Auth0.js 9.
Q: Is there any action that we need to take now that the vulnerability is public?
We have automatically enabled the mitigation for all Cloud customers, so there is nothing you need to do to benefit from this enhanced protection. However, it is critical that you continue your migration efforts and update your application(s) before the Removal of Service deadline on July 16, 2018. The mitigation patch does not eliminate the CSRF vulnerability; the most secure option for all customers is still to disable the ‘Legacy Lock API’ as instructed.
Q: I’m on the latest version of Auth0.js 9 and/or Lock 11, is there any action that we need to take when the vulnerability is made public?
If you have already upgraded to the most secure version of Auth0.js and/or Lock, so no further action is needed from you at this time. But, be sure you have disable the ‘Legacy Lock API’ as instructed.
Q: Will Auth0 be providing an official notification that we are no longer vulnerable to attacks associated with the disclosed CVEs?
Our published CVE confirms which versions of Auth0 are secure; this can be shared with internal and external stakeholders as further validation. We will not be issuing a separate notification at this time.
Q: Am I vulnerable? What do I have to do?
Please refer to our Community announcement and FAQ for more information.
Q: Auth0 said that the other deprecations (/tokeninfo, /delegation, /oauth/ro, /oauth/access_token, usage of id_token on Management API) were delayed. Am I vulnerable if I didn’t do them yet?
No. As stated in previous communications as well as our updated Community announcement, we have adjusted our plans and will continue to maintain and support the endpoints described. In the event that we do need to make security enhancements to any of those endpoints, we will announce timeframes and guidelines for any required changes at that time.
Q: If Auth0 fixed this, do I still need to upgrade to Lock11/auth0.js v9?
Yes! While the server side mitigation that Auth0 has developed will reduce the severity of the vulnerability, it does NOT eliminate the vulnerability. *Migrating to Lock 11 and auth0.js 9 is still the most secure option for customers who are using embedded login. *If you’re currently using our Hosted Login Page (aka, Universal Login), you do not need to upgrade; however, we still recommend that you migrate to the latest version of Lock (11.3+) when possible.
Q: What is Auth0 doing to ensure this doesn’t happen again?
Although vulnerabilities are a part of life in software development, security is one of our top priorities at Auth0 and we have invested heavily in increasing our internal capacity and resources over the previous year. As stated in our blog post, Joan Pepin joined Auth0 last year as our Chief Information Security Officer, and we have introduced several new controls to make the introduction of vulnerabilities even more difficult in the future:
-
Implemented a new Secure Software Development Lifecycle process that encompasses all new development efforts.
-
All developers take part in regular secure development training.
-
Embedded Product Security engineers into the various engineering teams to focus on the internal code and processes, while building out our Application Security team to focus on external interfaces and component security.
-
Perform regular penetration tests and code reviews by industry-leading third parties, and automated vulnerability and component security scans.
We encourage anyone to report a potential vulnerability to us through our Whitehat responsible disclosure program. We take all such reports very seriously as part of our commitment to providing the best security for our customers.
Q: My security dept requires that we fill out an RCA and mitigation report (or other corporate procedures for outages, vulnerabilities, risks, etc). Will Auth0 provide those?
Please see our published CVE for the information you will need to complete those requirements.
Q: This sounds serious - why should I trust Auth0 after this?
Security vulnerabilities, like other bugs, are inevitable in any sophisticated software. Auth0 has responded to a complex issue in a responsible manner, and our customers’ security has been the highest priority for us throughout the entirety of this coordinated disclosure. We have been as transparent as the situation allowed given the sensitivity of the vulnerabilities in question. We stand by the actions we have taken
Q: What happens on July 16, 2018?
We will remove service to the deprecated endpoints (usernamepassword/login and /ssodata) to eliminate the CSRF vulnerability. Any requests to these endpoints will fail as of that date, so please ensure all of your applications are updated by July 16. Based on customer feedback so far, we highly recommend that you begin your migration efforts now so you have plenty of time for testing and troubleshooting if needed!