Microsoft warns that with the shift to remote working, customers are exposed to additional security threats such as consent phishing, besides conventional credential theft and email phishing attacks. Consent phishing is a variant of application-based attack where the targets are tricked into providing malicious Office 365 OAuth applications (web apps registered by the attackers with an OAuth 2.0 provider) access to their Office 365 accounts. Once the victims grant the malicious apps permissions to their account data, the threat actors get their hands on access and refresh tokens that allow them to take control of the targets’ Microsoft accounts and make API calls on their behalf through the attacker-controlled app. After the victims’ Office 365 accounts get compromised, the attackers can obtain access to their mail, files, contacts, notes, profiles, as well as sensitive information and resources stored on their corporate SharePoint document management/storage system and OneDrive for Business cloud storage space.
OAuth has been abused since it was first deployed and its abuse is only accelerating now that it is being widely deployed. Overall, it’s just hackers abusing a single point of failure. It’s not unexpected. It’s the opposite. Whenever users use a single-sign-on technology, attackers are going to abuse it. Now that hundreds of millions of users use it without really knowing what it is, it makes it easier to abuse. Part of the problem is that most users don’t understand what is happening. They don’t know that a sign-on that they’ve used with Gmail, Facebook, Twitter, or some other OAuth provider is now automatically being called and used or abused by another person. They don’t understand the permission prompts either. All they know is they clicked on an email link or an attachment and now their computer system is asking them to confirm some action that they really don’t understand. It’s like if a person was flying in an airplane to go to another city and the pilot came up to the passenger and asked them if it was okay if they, the pilot, flew using visual flight rules while headed into an unexpected storm. Most passengers would not know enough about what VFR is and the risks of using it while flying into a storm. But that’s exactly what we are asking users to do with OAuth. Have you seen the OAuth permission prompts? To a computer security geek, they look perfectly reasonable and immediately understandable. We computer security geeks can’t figure out why all the non-computer geeks out there don’t know what they are saying okay too. But from the user’s perspective, all they want to do is see the content they’ve been promised and if clicking okay one more time to a pop-up permission prompt is the price to pay to see that content, they will do it. They assume the system is going to protect them against making a bad risk decision. But it isn’t. Most of the time, OAuth users have received zero real training. You can’t skip the training and expect people to make the right choices every time.
Even worse, many times, the malicious OAuth prompts ask not only for full permissions to the victim’s files, but to everything they can see. So, if someone else gave them access to a file or folder, say inside their organisation or to a trusted business partner, the hacker gets access to that…usually full control access. The hacker can steal content, delete files and folders, and even manipulate existing shared documents so when everyone else opens them up, everyone gets exploited. It’s really potentially devious access.
The only way to fix the system is to do either one of three things: 1) Make the permission prompts far more understandable to the casual end-user. For instance, include a message that says, “If you say okay, you are giving this third party full control over all documents you can see, so make sure you trust the person asking. The request might be malicious.” Or 2) Somehow make the system intelligent enough (maybe using AI or machine learning) to make the risk decision on behalf of the user so a user not trained in computer security doesn’t have to make computer security decisions. Or 3) Don’t allow high-risk decisions to be made, especially by default and so easily. The system should default to the least permissive permission and make the user go out of their way to give away the keys to the kingdom. Don’t let giving the keys away be as simple as clicking on one okay message. If you can’t do one of these three things, you’re never going to stop QAuth attacks.