Humans love anything that helps us save steps and time. The development of the OAuth framework does just that for those of us using cloud applications and web services. It allows users to login to one system and then access others without the need to login to each one separately. This single sign-on (SSO) solution works very well and has become the industry standard. However, you do need to understand and address OAuth risks to ensure that your district’s information systems and data remain secure.
OAuth is an open-standard authorization framework. In 2010, a group of internet gurus released OAuth as the answer to the common problem of users wasting time by logging in to multiple computer systems. Twitter, Google and others were strong supporters of the project. The developers made significant revisions over the next two years and they released version 2.0 of OAuth in 2012.
OAuth has evolved into a popular standard. It allows unrelated servers to authenticate a user’s access to its data without needing access to the single sign-on credentials, it uses access tokens to verify a user. Internet giants such as Facebook, Amazon, Microsoft, PayPal, and a host of others have adopted it as a de facto standard.
You have likely seen OAuth in action. When you go to sign on to a new application, you see the option to use your login credentials from another system. For example, you can choose to use your Google or Facebook login credentials.
It’s also commonly used to send files stored in a cloud application as attachments to an email. If the email client and the cloud storage application support OAuth, you can find the right files and attach them to the email without logging in to the cloud storage application. This type of operation can work between Gmail and Microsoft OneDrive, for example.
Unfortunately, hackers have found ways to abuse OAuth. It’s simple for an attacker to create an application to get access tokens from unsuspecting users. As a result, while the attacker doesn’t have access to the user’s password, they can use the access token to access email and files. All while bypassing password and two-factor authentication enforcement.
A common example is one in which a hacker creates a “look alike” application that looks much like a trusted app and requires email read, write, and send permissions. Once they are able to trick a user into allowing those permissions, the attacker has unfettered access to their email account. From here, lateral phishing attacks often ensue. Sending phishing links from an internal email account provides the hacker with two advantages. The email is unlikely to be quarantined by phishing filters or MTAs because it is sent from a trusted (internal) domain. Second, recipients are more likely to open the email and click on the link, because there is no reason for them to believe that person would send them malicious content.
Identifying an OAuth attack is notoriously difficult for a few reasons. First, the unsuspecting user may not recall that they’ve allowed access to a 3rd party application, because all of the interaction with the malicious application happens on trusted apps such as Microsoft 365 or Google. Second, traditional cybersecurity infrastructure, such as firewalls and MTAs, are technologically unable to detect the attack. This is because they focus only on securing the perimeter of the network, not the behavior within a cloud application. Finally, few system admins in school districts have access to the visibility and control required to detect and quickly fix OAuth risks in school cloud apps.
It’s likely that OAuth abuse happens more often than we know. The first reported incidents of OAuth abuse occurred during the 2016 election. A hostile espionage group initiated OAuth phishing attacks against political parties in the U.S., Germany, Turkey, and in many other organizations.
School data systems are increasingly under attack. District IT teams must be vigilant to guard against all types of cybersecurity risks. As you’ve likely experienced yourself, the explosion of EdTech tools and apps have made managing these risks even more difficult.
This is because SaaS infrastructure security is just as critical as any security measures you have in place, but you have much less control over it. EdTech developers that do not take their own infrastructure security seriously, or do not understand the unique needs of data collection and storage in the K-12 environment, place your students’ and district data at risk.
Attackers can use lax EdTech security to gain access to district information. In some cases, they can even gain access to your district’s cloud environment itself using OAuth connections.
In September 2018, the FBI posted a public service announcement related to the risks posed by education technologies. The announcement noted the increase in the use of EdTech in the K-12 environment, and the amount of student data that those systems collect.
Part of the FBI’s concern could be linked to the faulty data configuration settings found in Schoolzilla’s system that was reported in EdSurge. Schoolzilla backed up sensitive data to a public location on Amazon S3. One expert estimated that over one million student records might have been involved.
Schoolzilla responded immediately by securing the data and contacting customers to explain the problem and the solutions Schoolzilla implemented to prevent a recurrence.
EdSurge also reported on the attack on Edmodo that resulted in the theft of over 70 million usernames, email addresses and hashed passwords. They also reported that the data was probably for sale on the dark web.
When you consider these types of breaches, along with phishing attacks, it’s possible that one security breach can lead to a widespread disaster.
OAuth, or something similar to it, is undoubtedly here to stay. Users are demanding easy access and OAuth provides it. However, the K-12 community can take action to protect itself against OAuth risks.
A cloud security platform tailored to K-12 IT security needs is the most effective way to accomplish the monitoring and control requirements noted above.
K-12 school districts have a unique duty to safeguard confidential information in order to protect student safety and privacy. If you’re not sure how secure your cloud systems are now, run a cloud security audit. Then, complete the same type of audit on a regular basis to identify potential problem areas and safety issues.