Researcher’s Footnote: Security does not start at MFA. Be password savvy.
Hello folks, the next topic we’ve been taking a look at has to do with MultiFactor Authentication or MFA for short.
Recently CISA has added single factor authentication to its list of account provisioning that should never take place. This is a major step forward for getting MFA rolling across the industry. However, some consumer awareness still needs to be maintained on keeping each part of the MFA scheme secure. https://us-cert.cisa.gov/ncas/current-activity/2021/08/30/cisa-adds-single-factor-authentication-list-bad-practices
I intended to make this a long and investigative blog, but I’m releasing it as a footnote due to this decision and some attitudes about “password-free” login.
Everyone has accounts tied to MFA these days, be it a to a phone number, a token from an app, or a fancy yubikey securing the application you’re using. MFA is here to stay, but the authentication that happens on your computer might actually not be fully secure the whole way through.
This research dive happened accidentally, I have an app that shut down recently. This app had access to my info through more means that I realized. I was wondering how this was being secured post-mortem, so I googled around for some information. I found out that the app, had been purchased and shut down by Stripe, whom has their own VDP program on hackerone. I took a look at the resources available to test if they had the API endpoints still up, but thankfully it’s looking pretty desolate.
I got to thinking though, Some of these authentication protocols for token-based MFA are a little different than each other. Some use 7 digits while others use 6. There’s probably a good reason for this. Well there it, and it’s something I’m frantically looking around at as much info as possible to understand at the moment.
Typical apps that use these rotating timed passwords. They use keys of the TOTP variety, or Timed One Time Password. https://datatracker.ietf.org/doc/html/rfc6238
So with TOTP, it’s outlined how authentication should take place as dictated by it’s very own RFC. So the user’s machine doesn’t necessarily make any requests, but the client machine handles the session and database for all the OTP devices.
Now the year is a little ahead of 2021 at this point, and we’re in the age of cloud computing. Devices have all sorts of fancy authentication mechanisms protecting us, such as OAUTH, XML security templating, SAML, and JWT’s. I’m mentioning these 4 as they essentially overlap in some areas in order to provide enhanced security, but really they just increase attack surface area. They’re also among the weakest and most well known and exploited protocols out there.
What else increases attack surface is putting an API atop these already complicated mechanisms. There is a vendor who I will not name, that is in charge of a specialty secure token tool that has made a proprietary version. While they also support traditional TOTP, they’re pushing an API which enforces secret key usage in order to protect their own database of users and their tokens. Well guess what, it also uses JWT’s atop of all that, and those JWT’s are then forward from device to server and it’s a whole tangled mess of authentication from here down.
This confusion has led to some poor implementation of this API. In my research, user account and names are being leaked, which can be put together into PII with some amount of data exposure. The cause of this is from developers assuming that the forwarded JWT is secure by nature, and that the information within is good enough without hiding in an RSA cert. Wow is this wrong, and the attack surface area here is worth an eagle eyed investigation.
To describe this issue in a way which is less technical, lets say a user doesn’t bother protecting their username or password to an account because they have the key needed to access. “How is anyone going to get that” They may ask. Well what if that key is tied to an account with an ID and a few other pieces of PII. If an attacker got that username and password, what would they see from any identity pieces before and after 2fa? What if all it takes to get that number is a shady customer support call with all that info the token is giving out? And finally, what if this was the same case for every single app that used this API?
There’s a lot of what ifs and not a lot of practice here. Needless to say I’m looking more into this issue right now. The depth and breadth of malpractice by devs here is both mesmerizing and varied. I can say that leaving keys up to the developers has caused a wide range of how they’re being handled. Some secure, others not as well. The concern here is that if one key falls, the whole tower crumbles.
Thankfully, the team centered in this also has a VDP. I’ll be looking into my options to cooperate on resolving the underlying issues with this, if there are any. If you need a takeaway from this blog, don’t get lazy because MFA is here to stay, keep your passwords safe and secure, use a password manager, and be mindful of what type of authentication methods your work is using.
Stay safe!
