You will find them on millions of websites, including many of the most popular sites on the internet. These little buttons make it much faster for customers to sign up for a web application or service and dramatically boost conversion rates for site owners: I’m talking about the ubiquitous social login buttons from Facebook, Google and others.
Unfortunately, social logins are a growing source of abuse and fraud as sophisticated attackers and botnet operators have figured out ways to hack these authentication mechanisms and wreak havoc. This column will give you an overview of how social logins abuse happens and basic steps site operators can take to prevent it.
It’s easy to see why social logins are so popular. For users, it’s a much easier mechanism. With a social login they control one trusted identity and use it to log into other places in a trustworthy way. For site owners, it reduces friction in the signup process and feels more secure as they don’t need to manage user passwords or store their credentials and they know that a user’s email will be valid and won’t bounce.
Sounds good, right? Recently a customer called us and showed a strange graph of new account creations on their site. The line on the graph rose steeply in a very short period.
The customer was experiencing roughly a 9X increase in new account creation for no apparent reason. They believed it was an automated attack on their login page aimed at hacking into existing user accounts or creating fake new accounts on the application. We looked into their claim and quickly realized that the automated attack was a centrally controlled botnet of tens of thousands of malware infected browsers targeting the application’s social login flow.
In many cases, the way social login abuse happens starts by enticing a user to install a malicious browser extension. That extension will request your permission to read and change all data on all websites you visit, and a week or so from install date, will download in the background some Javascript malware from its command and control site to run on the user’s browser, and from that point can practically control your browser. The major browser makers cannot adequately police their stores due to the sheer volume of extensions uploaded.
These malicious extensions wait in the background and watch until a user logs into Facebook, Google or some other service. Once the user is logged in, the extension then will use the access tokens or credentials, and will attempt to sign the user up for other services supporting said social login without approval or permission, taking advantage of the logged in social account.
Some of the bot extension makers will actually take an extra step and use this tactic to game its rankings on the extension store using the user’s credentials to upvote the score, and will use the social networks to further distribute the malware to friends, allowing them to get thousands of more downloads.
Because social logins will generally keep a user logged in for 30 days without requiring an additional log in, bot makers and botnet operators have a considerable window of time in which to either perpetrate online fraud or spread their malware widely, all while piggybacking on the browsers of legitimate users.
What good is a hacked social login on a site? For one thing, it can be used to rack up affiliate fees through fake account signups at dating sites or other applications using hijacked social credentials. Botnet operators can also use social logins to propagate their malware by storing the malware on these sites as well as spreading it to friends or contacts and create a broader network of bots. For example, a hacked social login on a major file transfer site could be used as a powerful propagation mechanism for malware. Marketing fraud is another way that bot operators use social logins to make money or punish competitors.
Here are some basic steps to take that will make it harder for social login fraud to happen on a web application.
- Use social login credentials as credentials and nothing more. When a user logs in with social logins, site operators should always enforce the same type of controls, logic and protection that you would do when a user is logging in for the first time. Operators also may want to limit actions they can do to those available when the account was created. You can require a CAPTCHA as part of the social login flow. But above all, do not conflate a successful social login with a trusted user.
- Look at the origin of the login request. Check to make sure the origin of the request makes sense. It should come from the right domain and have the right headers. This should be possible and not hard to do by applying access rules on your server, or monitoring such access with a robust log file analysis tool.
- Prevent your login page from running in an iFrame. iFrames forms are a favorite attack vector for Bot makers. There are a number of simple mechanism to wall off the iFrame threat. Using X--Frame options can stop most forms from loading in a separate iFrame.
Over the longer term, the social login providers could dramatically improve security for themselves and site operators by applying for social logins the same security and validation tools they apply on their own login pages and account creations. This means allowing site operators to force two-factor authentication flows for social logins that they think need to be protected. If enough voices raised up, it’s possible Google, Facebook and others would accede to this request.
Social logins are not going away. The users have voted for them loud and clear. At the same time, social login abuse is a problem that deserves more attention as malicious Bot makers piggyback on social to spread their destructive payloads.
We hope that site operators can take the three steps above - and generally use their common sense. Even by slightly hardening their site, they make it far less attractive to attackers. That’s a simple, cheap and important step in the right direction.