The shared-login tokens and processes used by many web-based apps and services, as well as some web apps themselves, are fundamentally insecure and create a potential gold mine for hackers, three security researchers said at the Black Hat and DEF CON computer-security conferences here last week.
The problem is that today's online services are so complex and difficult to understand that hackers, phishers and other crooks have plenty of opportunities to steal files, implant malware and gain access to accounts.
- Millions of home Wi-Fi routers under attack by botnet malware
- The best antivirus software
- Your Wi-Fi router could tell everyone where you live — what to do
- Plus: Get ready for Zoom-based deepfake phishing attacks, expert warns
"Lots of bad assumptions were made when protecting these protocols," said Jenko Hwong, a researcher at Netskope whose DEF CON talk Saturday (Aug. 7) focused on glaring weaknesses in the OAuth open-authentication protocol used by Microsoft, Facebook, Google, Twitter and hundreds of other companies. "OAuth is a mess, and no one understands it all."
In the DEF CON presentation just before Hwong's, Snapchat researcher Matt Bryant showed how Google's own cloud-based Apps Script application-development platform makes it easy to hijack Google accounts and gain access to files, contacts and emails in the online Google Workspace environment.
And at Black Hat on Thursday (Aug. 5), Matthew Weeks of Deloitte showed how file-accessing web apps that are supposed to be restricted to specific directories can "escape" their confines and end up hacking desktop computers.
How you can protect yourself
To minimize the risks of phishing attacks that abuse OAuth and Google Workspace, you could in theory log out of each account when you're finished using it for the day, in order to kill the access tokens and session cookies, but you'd have to do so on each device on which you're logged in.
This creates tremendous inconvenience. Who really logs out of Twitter when they're done using it? Who's going to log out of Google every day on each PC, Mac or smartphone they own, only to log in again the next day? And furthermore, you're vulnerable again as soon as you log in.
To minimize the risks of file-altering web apps, be very alert when a website asks you to grant permission to a file or folder on your PC or Mac, and be sure that the files that you grant access to have specific names.
You'll also want to install and use one of the best Windows 10 antivirus or best Mac antivirus programs to catch anything malicious that might end up on your system — although some of the potential attacks using web apps can evade antivirus scans, at least upon installation.
Log in one place, get in everywhere
OAuth was developed by Twitter, Google and other companies and the first version was finalized in 2010. The now widely used protocol lets you log into one site or service. Then that site or service passes an access token to other sites saying that those sites can have access to the personal data that the first site or service, the one you logged into, has about you.
In that way, you can sign into Twitter and then be logged into TweetDeck too, or log into Gmail and find yourself logged into Google Drive, Google Calendar and the rest of the Google ecosystem.
However, the existence of that access token, and the fact that it's not "bound" to any specific online service, means that phishers who get the token can get into your account without your email address, username or password. Two-factor authentication (2FA), also known as multi-factor authentication (MFA) won't stop the attack.
"The target is no longer the username or password," said Hwong. "What you want is the session token. It's already been blessed Session tokens generally last an hour, but then you get a refresh token, so it lasts indefinitely. You basically have a permanent credential that has bypassed MFA."
'More complex, less useful and less secure'
The first version of OAuth contained many security safeguards. But in OAuth 2.0, finalized in 2012, many of those safeguards were removed in order to make the protocol easier to implement and use.
These changes led OAuth specification writer Eran Hammer to resign from the development team and write an angry blog post charging that "when compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure."
Hammer cited the unbinding of client information from access tokens that indicated token's origin, the removal of cryptographic signatures from the protocol, and what he saw as needless complexity introduced so that companies could tailor OAuth 2.0 towards mobile devices and smart-home devices, as well as to in-house enterprise deployment.
"We are ... likely to see major security failures [in OAuth] in the next couple of years," Hammer warned.
A widespread OAuth attack
Such a major security failure came to pass in May 2017, when an email "worm" tore through the Google app system, infecting Google accounts and gaining access to thousands of Google Docs in a few hours before Google shut it down.
"The worm affected more than 1 million Google users over a few hours before Google stopped the spread," Bryant said his DEF CON presentation, which focused on Google. "The coding was amateurish and only collected email addresses."
The rogue email, which did not come from a Gmail account, claimed that someone you knew had shared a Google Doc with you. If you clicked the button to "Open in Docs," then everyone in your Google address book would get the same phishing email, only with you as the sender.
What was significant, Bryant said, was that "this attack used no exploits or bugs, yet the impact was substantial." If you abuse OAuth and Google's sign-in system, "you don't need crazy zero-days to pull off big attacks."
"It is highly likely that the use of OAuth will be a common theme in future phishing campaigns," said SecurityScorecard researcher Alex Heid in the days after the Google Docs attack.
If no one can detect an attack, did it happen?
According to Bryant, that forecast is correct, but Google's universe of online apps and services is so complicated that it's hard to tell whether an attack has occurred at all.
Google tightened up the security of its online ecosystem within a couple of months of the attack, Bryant said, but it's still possible to hijack Google's document-ownership and document-sharing process like the 2017 Google worm.
The biggest threat comes from abuse of Apps Scripts, which are sort of like macros for Google online apps, including the enterprise-ready G Suite that competes with Microsoft Office, Bryant said.
Anyone can write an Apps Script, although Google scrutinizes those shared with more than 100 users and warns that those shared with fewer users are "unverified." However, if the script author uses the same G Suite domain as the user who tries to open it, no warning is given.
"Apps Script is an attractive option for phishing and backdooring G Suite accounts," said Bryant. "An implant can't be detected by antivirus ... or other one device scanning, and Will survive a device reboot."
Google's environment is more tightly controlled than the OAuth system as a whole, but it's still possible to get Google users to grant permissions to malicious attackers without them being aware of it, Bryant said.
For example, he said, you can attach an Apps Script to a Google Doc, Sheet to Slide, then send a copy link to another user. The file will be copied with the Apps Script, but the targeted user will need to manually trigger the Apps Script to run.
Bryant solved this problem by placing the trigger in an image that a user would click to remove in order to see what was behind it.
Each new Apps Script creates a new Google Project, Bryant said, and anyone who requests access to one of your Google documents, sheets or slides ends up being "bound" to your Project.
You're not supposed to be able to leverage that binding to then get access to another person's Google account, Bryant said, but he was able to edit his Google Project so exactly that happens.
"Whatever your user has access to, you can get access to as well," Bryant said.
Letting websites change files on a PC is now commonplace
A similar sort of oversharing creates serious security issues for web apps that are able to alter files on users' PCs, Deloitte researcher Matthew Weeks explained at Black Hat on Thursday.
You may not be completely familiar with the concept of a website that modifies the files on your PC, because that's not part of the traditional website-browser relationship. For nearly 20 years, browsers were mostly passive windows into what was presented on a website, and what happened in the browser wasn't supposed to affect the rest of the PC.
That's changed with web apps such as Microsoft Office 365, which can create and modify documents and spreadsheets on a user's PC, and with videoconferencing apps such as Zoom, Cisco WebEx or GoToMeeting, which will install client applications on the user's PC without having to get permission from the PC's administrator.
Each of these online services has a file-system-access application programming interface, or API, that interacts with the PC's operating system to be able to alter files.
"File-system-access APIs from the web are pretty commonplace," Weeks said. "They're already obvious for videoconferencing, but they're now also used to edit and modify very large files on a PC using web apps."
Giving away more than you want to
There are security limits built into web apps that have file-system access, Weeks said. Some file types are banned outright, the web apps aren't able to use full file paths that might grant them access to other directories, and the number of changes that a web app can make to a file is limited.
But, said Weeks, "if you give a web API access to a certain folder containing the files you want to upload or modify, you're granting it access to all the files in that folder. This is normal functionality," he added, "but not everyone may realize it."
Because of this, Weeks said, "if a website has been granted folder write access, then it can write a DLL" — a direct link library, or file that contains programming code that one or more applications can read and execute.
DLL "injection," in which malicious code is placed inside a DLL and then executed by an otherwise safe application, is a tried-and-true method of hacking both Windows and macOS.
Weeks ran a demonstration of a second type of attack in which a web app "popped a calc" on a PC, or forced the Calculator app to open, a traditional sign in proof-of-concept attacks that a Windows or Mac has been hijacked.
The trick in the second attack, Weeks explained, is to get the user to approve the download of a nameless file from a web app. This gives the web app permission to do much more than it's supposed to be able to, including altering the file after installation.
The user's system, Weeks said, routinely screens files created by web apps to make sure they're safe. Antivirus software does something similar. But the apps are not supposed to be able to alter the files after that safety screening.
However, the nameless-file check bypasses that safeguard, letting the website update the created file with malicious code, and the user's OS will be none the wiser. To prevent this, Weeks said, before examining the file, users should close the browser tab that contains the site from which the file was downloaded.
Phishing attacks controlled entirely by the attacker
OAuth 2.0 has been further refined to apply to devices that have limited input methods, Hwong explained. When you're logging into HBO Max or Showtime to Go on your smart TV, you're asked to log into those services on a separate device, such as a laptop or smartphone, and then input a temporary access code that appears on your TV screen.
"The app [on the smart TV] is totally in control of this process," Hwong said.
He then ran a demonstration showing how this app-driven process could be used to hijack a Microsoft Office 365 account, using a web app controlled by an attacker that sent an access code.
In Hwong's example, the successfully phished account happened to belong to a company's Microsoft Azure cloud-systems administrator, maximizing the potential harm.
"I didn't even need a Microsoft account to do this," Hwang said.
Unlike traditional phishing attacks, in this one "the attacker has no server infrastructure, no fake app, no fake site. There's no consent screen that the user has to authorize. And the pivot to Azure is not logged."
"Usability leads to insecurity," Hwong said. "A different authorization flow leads to opportunity for an attacker."
Hwong posted several diagrams that showed the evolution of OAuth processes, with three-way communication between the user, the site into which the user originally logged into, and the sites that receive and use the user's access token from the original login site.
But over time, the flow of information changes among all three parties, with the end user having less and less control — although the diagrams get so complex it's not always clear exactly what's going on.
"We're just scratching the surface," Hwong told the audience at the end of his DEF CON presentation. "I guarantee that in five minutes you're gonna flush this from your brain because your head hurts. My head hurts. But it's area that deserves a lot more research."
You can view Weeks' Black Hat presentation slides here, Bryant's DEF CON presentation slides here, and Hwong's DEF CON presentation slides here.
