There’s a fine line between an unintended use and a bug; this was my conclusion after taking a look at Auth0, an identity-as-a-service offering with 2000 enterprise customers – more or less the size of Schneider Electric, Atlassian, Dow Jones, Nvidia, and Mozilla, among others – and 42 million logins a day.
In this post I’ll explain how this “unintended use” could let someone execute a phishing attack by utilizing cross-site scripting to inject code and using phishing techniques to steal credentials from authorized users. Pretty scary considering Auth0’s main purpose is to confirm users’ identities.
I don’t like long stories, so I’ll try to get straight to the point. While doing some research on auth0 (since we thought about using it as one of our product’s authentication mechanisms), I came across the following:
- There are three different subdomains under auth0:
- Auth0.com, which hosts all sites from the Americas
- Eu.auth0.com, which hosts all sites from the European Union and probably Middle-East
- Au.auth0.com, for Asia Pacific (APAC) access.
- Each subdomain is 100% independent of the other, meaning that if company A registered their domain under auth0.com but not under eu/au.auth0.com, then someone else could do it.
- Auth0 also provides users with enough flexibility to customize the login and forgot password pages (for their site, of course). This “flexibility” includes the capability of writing/embedding JavaScript code within the custom pages.
So far so good, right? Not quite
As you know, attackers are getting smarter (not to mention younger, with a lot of time to play around). So, trying to emulate this behavior, I came up with the wild idea of registering under eu.auth0.com and au.auth0.com sites with the same name as the one registered by my teammates on the product side (let’s call it Product).
So, we ended up having:
- auth0.com à the real product
- eu.auth0.com à first fake site
- au.auth0.com à second fake site
Ok, sure, there are slight differences in the name. The question here is whether someone will pick up on the differences (since the site certificate is the same for all and is a trusted one) or just skip over them.
In addition, I created the same landing page for the fake sites as their real counterparts, with one small difference. A JavaScript was written within the landing page code that harvests users’ credentials (username and password), sends them to me via AJAX and later redirects to the real login page, authenticating users. This step is fairly straight-forward, and any moderately skilled hacker could do it within a short amount of time.
So, what’s the big deal? Well, having the ability to write JavaScript code within a massive product used for Single Sign-On, what could go wrong? Not even mentioning the possibility of harvesting cryptocurrency with the victim’s own computer (sounds legit no?)
Let’s just think about some previous attacks against big companies like Target and Home Depot. They relied a lot on suppliers and vendors, who had access to their systems. A single mistake on one of their suppliers led to some of the biggest data breaches in history. Now imagine how easy I could compromise a vendor of one of these big companies if they use an SSO platform that lacks basic security controls?
Responding to our research, Auth0 added that they provide additional security checks like:
“We also provide our users with an option to enable multi-factor authentication through Duo Security, Google Auth or our Guardian application. Enabling mentioned controls in place like MFA would increase the security of users accounts significantly. That’s something we always recommend.”
How was this addressed by auth0? We reached out to them and they mentioned that:
- They can’t disable the javascript coding, as it’s a feature for customers’ landing pages.
- They are actively looking for malicious kind of scripting within the landing pages as a preventive measure.
- They will enhance their security policy to prevent potential misuse of the service.
Auth0 added that as thing currently stand, they are working on getting rid of the ability to register the same account name in different regions.
Also read: 2018 Cyberthreat Defense Report: Where IT Security Is Going
