Tag: feedburner
2011
01.10

Summary

Feedburner accounts were vulnerable to a CSRF attack against certain services (MyBrand and FeedBulletin). An attacker could cause a user to enable or disable these services (potentially disrupting end-user access to content, in the case of MyBrand).

How Did It Work?

This vulnerability was fairly straightforward. To activate/deactivate MyBrand/FeedBulletin, you sent a simple POST request (to http://feedburner.google.com/fb/a/mybrandSubmit for MyBrand and to http://feedburner.google.com/fb/a/feedbulletinSubmit for FeedBulletin). Neither of those requests required a CSRF token to be processed. Accordingly, an attacker could trick a user into submitting a request without their consent.

Consider a possible attack. The target, Alice, owns a blog located at AliceAppSec.org. Alice provides an RSS feed for her blog (http://feeds.aliceappsec.org/AliceAppSec) using FeedBurner’s MyBrand service. The attacker, Marvin, is a jealous competitor; he wants to disrupt Alice’s RSS feed. To do so, he crafts a page that automatically submits a malicious MyBrand-disabling POST request to FeedBurner. Once that’s done, all he needs to do is convince Alice to look at the page: if she’s signed in to FeedBurner, the POST request will disable MyBrand for her account, causing her feed to return a 404.

Since the vulnerability is now patched, the proof of concept I sent to Google no longer functions. However, I’ve made the code (a simple HTML page) available for anyone who wants to check it out.

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills (and for responding to my many emails, even late at night on Sundays). :-)

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.