Hack of Buffer Should Raise Security Concerns For All API Providers

Proving how security vulnerabilities can lead to highly undesirable downstream effects for API providers, today's hack of the social content management and scheduling service Buffer resulted in a flood of unauthorized posts to user accounts for both Twitter and Facebook. Buffer is a Hootsuite-like offering that helps users manage and schedule posts to social networks such a Facebook and Twitter. Though it is not clear how many accounts were impacted across Facebook and Twitter, the net result was a slew of weight-loss spam. The posts offered a link which can be seen in the post pictured below.

Buffer is a relative newcomer to the social space. ProgrammableWeb has been using Buffer recently to schedule some of its posts and we've been relatively satisfied with the service. The service is very scalable. It can act on behalf of millions of customers, publishing orders of magnitude more tweets and posts to Twitter and Facebook thus making it a highly desirable target for hackers with nefarious intent. At the time this story was published, Buffer's home page boasted of 1.08 million users having published nearly 100 million updates through the service.

While the hacker(s) in this situation didn't hack Twitter or Facebook directly, they used Buffer's access like a back door to post to both social networks en masse.

About an hour after the service was hacked, Buffer CEO Joel Gascoigne broadcast an apologetic email to users:

I wanted to get in touch to apologize for the awful experience we've caused many of you on your weekend. Buffer was hacked around 1 hour ago, and many of you may have experienced spam posts sent from you via Buffer. I can only understand how angry and disappointed you must be right now….

The email went on to offer a series of steps and precautions that users should take next and then came another apology:

….I am incredibly sorry this has happened and affected you and your company. We're working around the clock right now to get this resolved and we'll continue to post updates on Facebook and Twitter.

Eventually, Buffer had to suspend its services until the problem was fully-remedied.

The incursion is no doubt a major black-eye for the upstart Buffer. Gascoigne has entered the dreaded damage-control zone that no start-up CEO wants to be a part of. But beyond Buffer lies the closely guarded brands of Twitter and Facebook who, in accepting the risk of running public application programming interfaces (APIs), put their own reputations in the hands of developers over whom they have very little control; especially over their security practices.

For Twitter and Facebook, transgressions like this comes with the territory of running public APIs. Both companies will brush this weekend's hack off as though it were a pesky mosquito. But that doesn't mean this weekend's hack shouldn't be instructive to the many other providers of open APIs who may not be able to so easily absorb such damage.

To be clear, while security should never be overlooked, there are simply more risks associated with APIs that accept inputs (e.g.: the POST method to a RESTful API) like those of Twitter and Facebook than there are with query-only APIs for retrieving data. What should current and future providers of such APIs do about it? Perhaps there's something to learn from the proactive measures that Twitter currently takes.

For example, Twitter publishes special guidelines to developers regarding abuse prevention and security. Demonstrative of how proactive Twitter is being when it comes to the security best practices of its developers, those guidelines state the following:

We assume you don't want your application used for abuse, and we're here to work with developers to prevent spammers from targeting your application. If we start to notice (or receive user reports) of spam coming from your program, we'll reach out to you to try and remedy the situation. Often, developers are able to make minor changes to a feature that will make their service less attractive to hackers or spammers, without impacting their legitimate users.

If you're unwilling or unable to control the abuse coming into the Twitter system, or are disingenuous in your attempts to make a more secure application, we may request specific feature changes. If you can't, or are unwilling, to make feature adjustments to prevent abuse on Twitter, we reserve the right to revoke your OAuth token or ban your application from the Twitter ecosystem. Developers can appeal revocation of OAuth tokens; please see this help page for more information.

We absolutely want to work with authentic developers to find a solution to prevent abuse and spam without impacting the legitimate users of their applications. If you've disabled a feature in the past because of abuse, and would like to help finding ways to reintroduce the feature without attracting spammers, please contact us via our support forms: https://support.twitter.com/forms/platform.

In the eyes of Twitter, for better or worse, developers are innocent until proven guilty. Even better for developers like Buffer who's intentions are noble, Twitter is pretty lenient. Whereas it could easily revoke a developer's license upon the first transgression, Twitter seems to prefer a more constructive relationship aimed at preserving developer access to its APIs while collaboratively remedying the problem. At the time of this post on Saturday evening, Twitter had not yet responded to ProgrammableWeb's inquiries. But one obvious question would deal with the scalability and cost of such an approach. Not every API provider has the resources to send reinforcements off to developers with security issues. Even Twitter must be limited to the extent it can do this.

Though we won't know until Twitter officially comments on the matter, Twitter may have also taken the additional step of zapping the offending posts. A search of Twitter revealed that many of the offending posts have yet to be unpublished. But that doesn't mean that the special forces at Twitter HQ aren't already busy neutralizing the spam (a best practice that other API providers could lock and load as a part of their own preparedness for such incidents).

As for Facebook, its developer terms of service --- at least the ones that ProgrammableWeb could find --- were less explicit about the extent to which the company wants to work with developers on the security front (though spam is clearly discouraged in writing).

Through services like Buffer, Twitter and Facebook are huge targets. But, that doesn't mean that smaller API providers shouldn't be equally if not more pro-active with developers through their policies, outreach, and incident preparedness.