I lost all my email, even with MFA enabled
David Hazar
Certified SANS Instructor | IANS Faculty Member | Consultant | Founder | Public Speaker
I am human enough to admit that I made a huge mistake which in all likelihood caused me to lose all my emails from the last 12 years. As a security professional, this should shame me more than the average user, but I figured my mistakes could save someone else from similar pain in the future so I decided to share what happened.
I recently moved my personal email from one email provider to another since my "old provider" decided to start charging me for using a custom domain. My "new provider" also charges, but the cost to value made a bit more sense for me and my family so I decided to move to the new provider. To protect the names of the mostly innocent, I will continue to use old provider and new provider in this article.
So, what happened? Well to sum it up, I was lazy and made a bad assumption when I moved from my old provider to my new provider. You see, I already had an account at my new provider and I didn't change the password even though I knew the password had been lost in multiple breaches over the years. My assumption was that since I had passcode-based, multi-factor authentication (MFA) enabled I would be protected. I considered changing it but, due to the MFA, I decided I could wait and change the password later after I finished the migration and determined if the new service would fulfill all my needs. I hadn't changed it previously because I didn't really use that account for much and had already enabled MFA. Big mistake!
After I migrated all my email from the old provider, I received a notice from my new provider about some suspicious activity associated with the account. As I reviewed the activity, I noticed that IP addresses from both India and Ukraine successfully synchronized the emails from my account. Now why any provider would allow connections from Ukraine right now for a typical user that has never visited Ukraine before or without a bunch of additional verification does not compute, but I have traveled internationally quite a bit for work and visited India many times so I can't necessarily fault them. Either way at least one of the syncs would probably have been successful. There were many, many attempts at synchronization, but only these two succeeded. It is still not clear to me how they bypassed the MFA requirement, but let's explore some possibilities.
The first possibility is that malware was present on my phone or laptop and was able to steal a code I was entering and re-use it. The code could also have been gathered via a targeted phishing (spear phishing) or smishing attack. However, I am pretty careful when it comes to phishing/smishing and the fact that the suspicious attempts happened over a 19 hour time frame leads me to believe it was something else. Another possibility would be that the attackers got a hold of an application-specific passcode. These are passcodes that are created to support applications that do not support MFA and are stored in your account profile. It is possible that one of these application passcodes was somehow generated or exposed, but if this was the case, I would not have expected to see so many attempts to access my account as the application passcode would have worked and continued to work. Another explanation could be that an automated process attempted to provide random, 6-digit passcodes to the MFA post-authentication, but then I would have expected to see even more attempts to sign-in (although the provider may not be displaying all the attempts in my activity history). Plus, it is not completely clear how they connected, but if synchronization was involved, it is more likely they used a protocol that does not support MFA with leads me back to my theory on an application-specific passcode.
I could probably come up with a few more ideas on how the attackers could have bypassed the MFA requirement, but ultimately it won't claw my emails back from whoever successfully synchronized my account. So, how might I prevent this in the future? Well, the obvious answer is to not be dumb/lazy and change my password when I know it was lost in a breach. I could have also had a longer, more random password like I do for most of my other accounts, but if even one of the breaches had plain-text passwords, passwords stored with reversible encryption instead of hashes, or weak hashes, it is possible the password would still have been known. What else?
I could rotate my passwords more often, but this is kind of a pain for email as then I need to go through a number of devices to update the passwords used to access my email. Multiply this by a lot of other accounts that I might need to do this for and it gets even more painful. I am not saying don't do this, as it is a great recommendation, but just saying that I am not a fan of password rotation, long-random passwords, and password managers in general even though I know they are a necessary evil.
Ok, so what about passwordless? There has been a lot of hype about passwordless lately and who doesn't dream of a day when we no longer have to do all of the things I just mentioned? Well, in my mind how is it that we go from preaching that multiple factors are required for security over the last decade to now saying "nah, one is OK". The passwordless advocates will say that the new peer-reviewed FIDO standard is a lot more secure than previous forms of authentication that relied on biometrics or tokens. I am not arguing with that and agree that the standard is definitely more secure. But, for me, I am not sure that I am OK going from something only I know (combined with another factor) to only something I have or only something I am no matter how much more secure it supposedly is than it was before (Technically there are private keys involved and possibly Bluetooth so it is something I have plus something else I have or something I am plus something I have and possibly someplace I am. More on this later.). Plus, if passwordless does take off, my guess is that we will see even better ways of fooling fingerprint and face identification technologies.
This doesn't necessarily mean that with that fingerprint or face identification someone will be able to immediately log into all your accounts as there are other cryptographic keys and enrollment processes involved. However, those keys are backed up to the cloud for recovery and the loss of a phone would become a much more risky event. Because of what I do for a living, I probably rate a little higher on the skepticism/conspiracy theorist scale so when I hear my private keys are being backed up to the cloud and could potentially be accessed or requested by others, I lose a little bit of confidence in those keys protecting my information. To be fair, there are ways of adding passphrases to keys so that they can't be used in the event that someone else has access, but then we are back to passwords. Aren't we?
领英推荐
Finally, since when is it OK to assume that all users have or can afford to purchase and maintain a phone with biometrics or an acceptable token? Will providers and manufacturers truly agree upon a standard in practice and not just in theory? Will users be required to upgrade their phones and tokens more frequently to stay secure? Some of the biggest proponents of passwordless stand to make lots of money if that is the case. Lots of questions.
All that being said, maybe passwordless will be the future and maybe attackers won't be able to exploit our passwordless technologies as easily as current authentication mechanisms, but if you think this transition is going to successfully happen in the next 1-2 years, to quote George Strait, "I've got some ocean front property in Arizona" that I would love to unload.
Now, what if I could lock my credentials for the application or service used to access my emails so that those credentials could only be used when I know I am going to be logging into that account? How might this have prevented the attack against my email? Well, let's explore this a bit.
If this capability of locking/unlocking credentials was offered broadly across my many accounts/applications and I lost a password in a breach, how would a potential attacker validate they had successfully decrpyted or cracked my password? They would have to find an account/application that is currently unlocked and it's possible that after trying a few different accounts/applications they may give up and move on to the next credential in the set. This would also make online attacks against passwords (e.g. password spraying) and usernames (e.g. username enumeration) more difficult. Ok, so validating credentials would become harder, but that doesn't necessarily prevent the attack. What other protection could locking accounts provide?
Well, let's say the attacker somehow knows they have valid credentials. Maybe they performed some sort of phishing attack and were able to log in immediately while the account/application combination was unlocked. This would allow the attacker to access that one account, but only for the current session. Once the session has ended, if the account is locked, the attacker cannot continue to use the credentials for that application even if they remain valid. Also, if, heaven forbid, those credentials are also valid for other applications, they would not be able to use those valid credentials for any other application that shares those credentials and is in a locked state.
What if the technology that allowed to you lock and unlock your account also provided visibility into any attempts to use your credentials? While this doesn't do anything to prevent someone from accessing your accounts when they are unlocked, it gives you more context about what is happening with credentials across the many applications and services you use. Maybe you will see attempts to authenticate against locked accounts before the attacker is able to identify unlocked accounts. If not, at least you will have visibility into when and where an attempt to authenticate to an unlocked account/application was made so you can respond and see what additional details you can get from that application or service. If supported by the application or service, you can check whether or not the attacker was able to provide a valid username/password combination and respond to any of the other factors of authentication required for that application or service.
Currently, some applications and services will notify you of specific unusual activity for your account, but the problem is that the people maintaining these applications and services do not have the appropriate context to quickly and/or accurately determine what is suspicious vs. legitimate. Therefore, there is always a "dwell time" between when the suspicious activity occurs and when someone is notified of that suspicious activity. Any SOC analyst will be familiar with this dwell time as they are typically responding to alerts that are minutes to hours or even days old. In the case of my email incident, the dwell time was almost 22 hours. If the dwell time had been 12 hours or less, I might have been able to prevent the successful synchronization of my email. You can't necessarily fault my new provider for this long dwell time. They may not have enough confidence in the context they are receiving for each attempt to determine whether or not the attempts are legitimate and they are getting thousands if not millions of login attempts every minute. That is a lot of data to analyze to detect these anomalies.
How do you decrease dwell time? You increase context which allows you to make a better or quicker decision. Who has the most context as to whether or not an attempt to authenticate to a locked account was valid? Obviously, the answer is the user themselves. Either they will see the attempt and be like "duh, I forgot to unlock my account!" or they will know that someone else is trying to log in and that knowledge allows them to act even if they don't always choose to act.
These benefits are what led to me join my former colleague Steve Sholtis and a few others in designing and developing the Next Level3 Account Protection Service to provide lock/unlock capabilities and more for integrated applications. Maybe it could have prevented the loss of my emails. At a minimum, it would have allowed me to respond much more quickly.
security engineering & operations
2 年Thanks for sharing your story!
Chief Information Security Officer
2 年Brutal experience, and great article! Thanks for posting.