Skip to content

MongoHQ was breached which resulted in Buffer being hacked —-> Perils of Cloud Computing

November 5, 2013


This post does not contain any new information. I have just read Buffer’s Blog and the blog at [1] and tried to put my thoughts down or rather tried to present in such a way that it would make sense to me. If you are looking for the original post, please refer to [1].


TL;DR version:

MongoHQ is breached -> Unencrypted OAuth Tokens stored in Buffer’s DB hosted on MongoHQ is stolen -> Spam Posts on Buffer users’ Twitter/Facebook account

The attackers were also able to steal Buffer’s source code from GitHub. This had unencrypted secret tokens hardcoded which made the Twitter spam posts possible (Details below).

Yes, they had their source on GitHub -> FAIL. Buffer suspects that the attackers were able to get access to their GitHub account by using the passwords leaked from Adobe’s breach for one of their employees -> Epic FAIL?


Full Version:

On October 26, 2013, Buffer was hacked.

Attackers stole OAuth tokens stored in Buffer’s database and posted spam posts on Buffer users’ Facebook and Twitter accounts.

This database was hosted on MongoHQ which made it all possible since MongoHQ was breached earlier.

Both Facebook (v 2.0) and Twitter (v1.0a) use OAuth to authorize 3rd party websites to post on user’s behalf once the user has granted access to the 3rd party website.

Buffer did some serious security mistakes on their part which made it possible:

  • Stored OAuth tokens unencrypted.
  • Did not use the optional feature of using app_secret for implementing Facebook integration. This app_secret is a token that works like an authentication token between Facebook and the developer (Buffer). So, in order to post something, the attacker would need both the OAuth tokens and this app_secret. Buffer developers did not utilize this setting. Only, the OAuth tokens were required to post.
  • Twitter by default makes it mandatory to use the above mentioned app_secret. So, the attackers had to use it in order to tweet on user’s behalf. So, how did the attackers gain access to it you ask? Buffer stored this unencrypted in their source code hosted on GitHub.


Buffer’s Response:

What Buffer basically said can be found here –

  • They revoked all pre-existing Twitter tokens.
  • OAuth tokens are now encrypted.

They never mentioned the following:

  • Is it HSM based?
  • Are layers of infrastructure partitioned? All encryption-related remedies are completely isolated from Buffer’s MongoHQ?


To this, NopSec CTO Michelangelo Sidagni said – “A one-time control fix is not usually enough to cover an entire security program. Instead of detailing just that aspect, [Buffer] should have talked about their renewed and revamped approach on their overall security program. Making a statement that this is going to fix all their problems without covering their entire security posture is just an invitation for the attacker to strike again….just for the sake of it.”  -> RIGHT!!


Recommended Way of implementing OAuth tokens:

  • Using Hardware Security Module (HSM). Developers are not going to do this. Too much work??
  • If the servers are hosted on a third party cloud, they can’t add HSM Module anywhere (It’s all in the cloud somewhere DUH). So, this introduces a Catch 22 situation. To address this, Amazon launched AWS CloudHSM. But, from what I have read, this is not feasible as its too expensive.
  • One approach to mitigate but not completely eradicate would be to store keys in files that are not accessible through the Web.
  • Encrypt at rest on Buffer’s servers, before it gets sent to MongoHQ.
  • Buffer has enabled 2 factor authN for their team now which is good and adds an additional layer. But, why wasn’t this done earlier??



  • Be cautious when authorizing 3rd party websites/apps to log us in by using our Facebook/Twitter credentials. We don’t know how they have implemented their OAuth.
  • Cloud Computing risks as mentioned earlier. You can never trust your data with a third party cloud. You need to do your due diligence.
  • OAuth faulty implementation. There seems to be a lot of different OAuth implementations out there. Some secure, some not. So, can we trust them?
  • API Security issues.
  • It is incredible to see how one breach in one company can cause multiple breaches.





From → Security

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: