SPICEWORKS FAIL: Are we ready for ‘social’ network administration?
Still more questions than answers
Analysis Yesterday, a security screw up with the Spiceworks application was noticed, and reported a little earlier by our good selves. Anyone with a Facebook or LinkedIn account could log in to Spiceworks installs running the latest version and it would create an administrative account for them.
This is not OK, not at all. Many Spiceworks users leave the Spiceworks helpdesk portal open to the net.
It is not uncommon to have employees or clients from all over that need to access the helpdesk. It's a nonstarter to have them VPNing into the network in order to access it.
This flaw allowed anyone with a Facebook or LinkedIn account to create an administrative account on a Spiceworks install, allowing all sorts of chaos to ensue.
Not only can helpdesk tickets and so forth be changed or deleted, but Spiceworks itself tends to know everything there is to know about a given network.
By default, Spiceworks performs regular scans, vacuuming up every iota of data it can find about the network on which it is installed, from the configuration of printers to the number of sticks of RAM installed in which slots, and on what PCs.
Spiceworks is frequently integrated into Active Directory, amongst many other management and control systems.
For now, in this instance, Spiceworks has disabled the feature that caused this flaw. The issue at hand, however, is so grievous that it should be triggering a very serious discussion amongst developers and systems administrators alike about the entire concept of social sign-on.
If not for Spicehead Darren Smith, this Spiceworks issue could have been a lot worse. But, it never should have happened in the first place. It is exactly the sort of thing that quality assurance teams are supposed to catch.
But the flaw did happen, and it should cause us to start asking questions, such as:
- What is the necessity of integrating any given application with services hosted on the internet?
- What must be best practices regarding this sort of implementation, both at a code level and at a systems administration level?
- How comfortable are any of us, really, with "hybrid cloud" applications such as Spiceworks?
Not only are cloud logons from social media networks directly responsible for this particular flaw, but Spiceworks mitigated the issue by flicking a switch on its end and disabling the feature for everyone across the board.
It should drive home to Spiceworks users – and any user of hybrid cloud applications – just how little control they have over this software they've installed in their data centre. So, how much control do we want to give up? To whom? And when?
Spiceworks is not the only hybrid cloud application on the market, and it sure won't be the last. What else can Spiceworks turn off at a whim? If it gets angry at me and completely nukes my account from the forums, how does that affect my ability to log-in to the application?
Spiceworks has ambitions to become a platform; a framework into which vendors will plug their offerings. Spiceworks views its application as the centerpiece of systems and network administration.
An administrator accepts that they could potentially pour a lot of time into customising the application, the plug-ins and add-ons. Years of work can go into such a management framework. Business processes and procedures, monitoring, incident response, vendor relationships, all varieties of end user support tools and the entire helpdesk history of a company – which frequently is that company's knowledge base for its industry specific software – can live in Spiceworks.
The idea that they can simply flick a switch and obliterate years of effort and accumulated knowledge is deeply unsettling.
How about the other applications that have hybrid could authentication or integration? How deep does the vendor's control go over the bits of data that your business absolutely depends upon?
How much damage could a vengeful employee at the vendor side do to operations for all clients? What security procedures exist on their side to prevent such things?
As we move into this brave new cloudy, interconnected world these are the kinds of questions that we must ask. As we put all of our data into public cloud software-as-a-service offerings, and rely ever more on cloud authentication or hybrid applications, we need to constantly ask ourselves how vulnerable are we to the human error – or maliciousness – of vendors?
It is up to us, as the customers and users of this growing category of cloud-integrated software, to agitate for security-first designs. Security that protects not only against malicious hackers and state actors but against the vagaries, incompetence and selfishness of the vendors themselves. ®