Until last week, some parts of the API that Instagram uses were vulnerable to a cross-site request forgery (CSRF) attack, something that could have put photos users thought were private, out in the open.
It took almost six months but Facebook, the photo sharing application’s parent company, patched the flaw last Tuesday.
Barcelona-based security researcher Christian Lopez Martin, who found the vulnerability last August and detailed the vulnerability on his personal blog yesterday, claims he almost didn’t catch it at first.
Martin initially scoured the application’s website looking for bugs but couldn’t find a vector that allowed him to inject code. It wasn’t until Martin started to root around the app’s mobile versions that he realized a big difference between the way the two handle privacy. The Android and iOS apps allow users to select whether or not their images are kept private while the website does not.
Martin, who spent most of his time trying to break the Android version of the popular app, discovered that when a person goes to change their privacy settings on Instagram, its API doesn’t control the user agent of the user’s request. Requests like setting a user’s profile to public (set_public) or private (set_private) did not use a security token.
Of course, when sites use security measures like secret, user-specific tokens, it can usually help thwart attacks, especially those of the CSRF variety.
To test, Martin wrote a simple CSRF proof of concept to exploit the weakness on the web. By simply getting a user who was logged in via a browser whose profile was private to click on a payload, Martin could make that user’s profile public. Martin claims he “wanted more” though and with an easy tweak was able to reverse his code, replacing “set_public” to “set_private,” making it so he could set any users’ profile that was public to private.
It took a lengthy e-mail chain between Martin and officials at Facebook and Instagram but the matter was finally resolved on February 4 last week.
Facebook has made it so that going forward any attempts to use this attack vector will result in “Fail, Login_Required,” according to the researcher.
“All new sessions are differentiated between mobile and web at login time so the web-based sessions have full CSRF protection enabled using secret security tokens and the mobile-based sessions have CSRF protection using user-agent control and a reCAPTCHA that forces the user (victim) to interacting with the mobile user interface.”
While Martin received a bug bounty from Facebook for his troubles in December, he discovered a potential way to bypass Facebook’s fix in January. Having obviously formed a rapport with the researcher, a week and a half later, Facebook wrote Martin back, confirming the hole had finally been patched, closing his report.
