How Facebook & Google Website Logins Can Lead To Data Theft
Login with Facebook. Login with Google. Websites regularly leverage our desire to sign in with ease to ensure we visit, and to ensure they grab a slice of the personal data pie. But at what cost? A security researcher recently discovered a vulnerability in the Login with Facebook feature found on many thousands of sites. Similarly, a bug within the Google App domain name interface exposed hundreds of thousands of individuals private data to the public.
These are serious issues facing two of the biggest household tech-names. Whilst these issues will be treated with appropriate unease and the vulnerabilities patched, is enough awareness given to the public? Let’s look at each case, and what it means for your web security.
Case 1: Login with Facebook
The Login with Facebook vulnerability exposes your accounts – but not your actual Facebook password – and the third-party applications you have installed, such as Bit.ly, Mashable, Vimeo, About.me, and host of others.
The critical flaw, discovered by Egor Homakov, security researcher for Sakurity, allows hackers to abuse an oversight in the Facebook code. The flaw stems from a lack of appropriate Cross-Site Request Forgery (CSFR) protection for three different processes: Facebook Login, Facebook Logout, and Third-Party Account Connection. The vulnerability essentially allows an unwanted party to perform actions within an authenticated account. You can see why this would be a significant issue.
Yet Facebook have, as yet, elected to do very little to address the issue as it would compromise their own compatibility with a vast number of sites. The third issue can be fixed by any concerned website owner, but the first two lie exclusively at the Facebook door.
To further exemplify the lack of action made by Facebook, Homakov has pushed the issue further by releasing a hackers tool named RECONNECT. This exploits the bug, letting hackers create and insert custom URLs used to hijack accounts on third-party sites. Homakov could be called irresponsible for releasing the tool , but the blame lies squarely with Facebook’s refusal to patch the vulnerability brought to light over a year ago.
In the meantime, remain vigilant. Don’t click untrusted links from spammy-looking pages, or accept friend requests from people you don’t know. Facebook have also released a statement saying:
“This is a well-understood behaviour. Site developers using Login can prevent this issue by following our best practices and using the ‘state’ parameter we provide for OAuth Login.”
Case 1a: Who Unfriended Me?
Other Facebook users are falling prey for another “service” preying on third-party OAuth login credential theft. The OAuth login is designed to stop users entering their password to any third-party application or service, maintaining the wall of security.
Services such as UnfriendAlert prey on individuals attempting to discover who has relinquished their online friendship, asking individuals to enter their login credentials – then sending them straight to malicious site yougotunfriended.com. UnfriendAlert is classified as a Potentially Unwanted Program (PUP), intentionally installing adware and malware.
Unfortunately, Facebook cannot entirely stop services like this, so the onus is on the service users to remain vigilant and not fall for things that seem to good to be true.
Case 2: Google Apps Bug
Our second vulnerability stems from a flaw in Google Apps handling of domain name registrations. If you’ve ever registered a website, you’ll know provision of your name, address, email address, and other important private information is essential to the process. Following registration, anyone with enough time can run a Whois to find this public information, unless you place a request during registration to keep your personal data private. This feature usually comes at a cost, and is entirely optional.
Those individuals registering sites through eNom and requesting a private Whois found their data had slowly been leaked over an 18-month-or-so period. The software defect, discovered on February 19th and plugged five days later, leaked private data each time a registration was renewed, potentially exposing private individuals to any number of data protection issues.
Accessing the 282,000 bulk record release isn’t easy. You won’t stumble across it on the web. But it is now an indelible blemish on Google’s track record, and is equally indelible from the vast swathes of the Internet. And if even 5%, 10%, or 15% of the individuals begin receiving highly targeted, malicious spear phishing emails, this issues balloons into a major data headache for both Google and eNom.
Case 3: Spoofed Me
This is a multiple network vulnerability allowing a hacker to again exploit the third-party sign in systems leveraged by so many popular sites. The hacker places a request with an identified vulnerable service using the victim’s email address, one that is previously known to the vulnerable service. The hacker can then spoof the user’s details with the fake account, gaining access to the social account complete with confirmed email verification.
For this hack to work, the third-party site must support at least one other social network sign-in using another identity provider, or the ability to use local personal website credentials. It is similar to the Facebook hack, but has been seen across a wider-range of websites, including Amazon, LinkedIn, and MYDIGIPASS amongst others, and could potentially be used to sign into sensitive services with malicious intent.
It’s Not a Flaw, It’s a Feature
Some of the sites implicated in this mode of attack haven’t actually let a critical vulnerability fly under the radar: they are built directly into the system . One example is Twitter. Vanilla Twitter is good, if you have one account. Once you’re managing multiple accounts, for different industries, approaching a range of audiences, you need an application like Hootsuite, or TweetDeck .
These applications communicate with Twitter using a very similar login procedure as they too need direct access to your social network, and users are asked to provide the same permissions. It creates a difficult scenario for many social network providers as third-party apps bring so much to the social sphere, yet clearly create security inconveniences for both user and provider.
We have identified three-and-a-bit social sign-in vulnerabilities you should now be able to identify and hopefully avoid. Social sign-in hacks aren’t going to dry up overnight. The potential payoff for hackers is too great, and when massive technologies companies such as Facebook refuse to act in the best interests of their users, it is basically opening the door and letting them wipe their feet on the data privacy doormat.
Has your social account been compromised by a third-party? What happened? How did you recover?