Social media logins are popping up all over the place nowadays. Why register for a website when you can click one button and Facebook/Google will do all of the hard work for you?
Well, if it’s not implemented correctly, you could end up with a serious security issue. The social login frameworks themselves have the benefit of Facebook, LinkedIn et al’s security team and budget (not that this necessarily guarantees anything…) - the host website does not, and this lack of security knowledge came back to bite Spiceworks recently.
Spiceworks makes software that aims to ease the lives of hard-working IT professionals across the world; this includes help desk software, network monitoring and even purchasing software. During a short time window following a code deployment anyone logging in using their Facebook account to Spiceworks Version 7.4.00065 was automatically created their own administrator account and logged in. To reiterate, Spiceworks promoted anyone to administrator status if they used Facebook to log in.
This was disclosed on the Spiceworks forum by a (deservedly) concerned user who had just noticed a disconcerting number of new administrator accounts being created.
Spiceworks response was as follows:
The series of events required for this to happen is very small and the amount of people exposed to this is even smaller, so hopefully the vulnerability isn’t too major; however, this is a security issue that requires immediate attention and we will be putting out a fix later this week.
Oh Dear.
Spiceworks later revised its official stance after a number of users pointed out that this probably fit the definition of ‘major’.
So what’s the take home message?
A core information security principle is that of ’least privilege’ - a user should have sufficient permissions to perform their role, and no more. This means that if something happens (the user’s password is stolen, their computer is hacked or stolen) then the amount of damage an attacker could do is reduced.
In practice this is hard - often our applications need to perform privileged operations, so the temptation to permanently run them as ‘root’ (or in high-privileged mode) is high. However, the potential for damage is much greater. The ShellShock vulnerability last year allowed arbitrary commands to be run on Linux systems that used Bash to process certain requests; if the web daemons involved had been running with high privilege (i.e. as root), then this vulnerability would have allowed immediate and complete compromise and takeover of most websites on the internet.
Shellshock - Allowed arbitrary command execution on systems using BASH
How does this relate to Spiceworks? It underlines the importance of ensuring that we’re handing out the correct privilege at all points in the chain, from log-in through to back-end APIs. This requires diligence and sometimes, unconventional approaches. For example, your users are unlikely to use obscure HTTP methods to access your API, but an attacker will almost certainly try. How will your application react? Will it react the same way after each incremental software update?
This highlights the benefits of regular, long-term testing. A penetration test or vulnerability assessment is a snapshot, demonstrating that at one particular moment in time certain flaws exist. Who knows what flaws the next release will introduce, or the one after that? To guarantee that you fully understand the risks associated with software, you need continual assessment. These don’t need to be full blown State Actor Simulation affairs; in the case of Spiceworks, a simple check could have prevented this particular issue.
Having specialists security experts in your development team during the development cycle can also dramatically reduce the overall life-cycle costs of a product. Back in 2004, NASA commissioned a report into the extra costs of fixing software issues at various design stages.
Their findings indicated that the extra cost to fix an error once it was deployed to production could be between 40-1000 times the costs of catching the error during the requirements phase. This means that the earlier you catch that SQL Injection flaw, or the sooner faulty designs are corrected, the cheaper they will be to fix. That has to be a good thing.
