Instagram iOS session hijack | Hacker News Reader

Instagram iOS session hijack

gist.github.com

132 pointssjtgraham49 comments

OP here. I discovered this years ago. I suspect it has been extant for as long as Instagram itself. I actually posted a comment about this 216 days ago! (https://news.ycombinator.com/item?id=6959472). When I checked again on Saturday, I couldn't believe my eyes when it I saw it still hadn't been fixed. I reported it to FB immediately, to which they responded it's been reported "some" times and the Instagram team were working on moving all endpoints to HTTPS and they closed the ticket without further discussion. I was incensed that such a fundamental and critical flaw was allowed to exist for so long. Because of this I decided public disclosure was justified.

The reply from Facebook:

"Hi Stevie,

This issue has been reported some already so unfortunately cannot reward you, instagram is working to get https for all endpoints. Its a pretty high barrier to exploitation to already sniffing someones traffic however.

Thanks,

name removed

Security

Facebook"

And here I am sitting in the Apple Store around the corner from my apartment watching various cookies whizz past my screen.

I don't agree the barrier to exploit is high. All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it. At that point Pandora's Box has been blown apart. The obvious precedent for this is Firesheep (now sadly not functional) from back in 2010.

>>"All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it"

And that's why this was made :-)... http://en.wikipedia.org/wiki/Firesheep

Maybe you should contribute instagram-sniffing to it :) https://github.com/codebutler/firesheep

Thanks, I referenced Firesheep in the grandparent. FS is currently very broken. I still couldn't get it to work after downloading the source and making some changes. The OS X API used by FS has long been deprecated and simply doesn't work on Mavericks. If there is enough interest I will write "Instasheep" this evening.

Oh wow, yeah my bad... totally missed your reference. I fully support the creation of tools like firesheep to help/nudge companies into SSL.

Hi, I'm the author of Firesheep. The code in git master should work with recent versions of Firefox, but there is an issue when running on recent versions of OS X related to elevating privileges. If you manually setuid the firesheep-backend binary, it might work. Let me know if you're interested in helping to fix this! Writing a handler for this Instagram vulnerability should be trivial.

Got the instasheep domain name if you want me to point it at a github repo.

#1380asal

salam

#1380asal #pinar_mg

Mike (co-founder) from Instagram here. Thank you for raising the issue; it's an important one.

We've been steadily increasing our HTTPS coverage--Instagram Direct, for example, which we launched in late 2013, is 100% HTTPS. For the remainder of the app, especially latency-sensitive read endpoints like the main feed and other browsing experiences, we're actively working on rolling out HTTPS while making sure we don't regress on performance, stability, and user experience. This is a project we're hoping to complete soon, and we'll share our experiences in our eng blog so other companies can learn from it as well.

Relevant comment:

@wodim I adhered to the FB responsible disclosure procedure. FB replied saying they're already aware of the issue and closed the ticket.

"Closed the ticket" as what, though? "Duplicate, working on fixing" or "won't fix"? Because those are pretty different...

Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered.

An unfixed security vulnerability is still an unfixed security vulnerability, no matter how many people discover it in the interim. By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure.

The one case where refusing to coordinate with the new submitter is reasonable is when the new submitter learned about the vulnerability from the original submitter, which means that the original submitter has violated responsible disclosure. In that case, nobody would deserve a reward.

> Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered.

This is rare for bug bounty rewards. All the programs I am aware of only reward the first reporter.

> By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure.

That's kind of what I'm pointing out here. We are missing information about what Facebook actually said and when it was said. The "we already know about it" response could mean "we know about it and are working on fixing it" or it could mean "we know about it and we don't care". In the former case, it is not responsible to publicly disclose the issue until it is fixed. In the later, it is.

A separate scenario is if the company is taking a long time to fix the issue. This is obviously subjective, but in my opinion it is understandable for a reporter to publicly disclose a long-standing issue in an attempt to force the company to act.

Yes, rewards to every submitter basically lead to the first guy telling N of his friends to all claim the bounty, too. It sucks to work for dozens of hours on something and then find out they already know about it, but the other option just leads to there being no bounties at all.

So if it's marked as a duplicate, the original submitter loses visibility and is not even followed up with on whether there was a resolution? Is there a way to include an outside submitter on an original ticket or bug filed internally? I am pretty much clueless on the standard procedure of most big tech companies when it comes to these things.

As example, HackerOne allows you to link duplicate reports to the original, and all reporters are "thanked" when the issue is resolved. But I think in many cases reporters of duplicate issues do not get any follow up.

Full and public disclosure is always responsible.

STOP USING THE TERM RESPONSIBLE DISCLOSURE. It serves only to frame full, public disclosure as "irresponsible disclosure", which is false.

agreed

No it is not in different situation. If I tell you your social security number is now accidentally written in your HTML file (probably because you copied and pasted the wrong thing), and now I tell the world "hey come look at sneak's SSN" instead of waiting for you to resolve is wrong.

Now back to this gist.

Is he responsible? It depends on how the situation was played out.

Based on what OP said:

* He found this 216 days ago and wrote about it as a comment on HN

* He didn't say whether he reported that day but he recalled Instagram was making HTTP request a year prior to that day he wrote the comment

* He didn't tell us when he report this issue to FB. Yesterday? Last week?

* FB said they are aware of this situation and closed the ticket. Like someone else said here, "closing" has different meanings. I've never reported any vuln to FB so I don't know how that works. But on HackOne, particpating program can close a ticket and set the ticket to "Not Applicable" meaning someone else has already reported.

So the decision factor is:

* when was the first report submitted by OP? Yesterday? Last week? 3 months ago? 216 days ago?

* if it was very recent, OP doesn't know the exact time the last duplicate report was sent out. Give FB a little more time and ask FB again in a week or so.

I did say in my other comment fixing this issue should be pretty trivia for Instagram as an outsider, but I also should acknowledge any major change to infrastructure should have a proper audit and roll out.

edit:

One last point. If OP thinks he's doing the right thing, let it be. There are too many things unknown to me so I am just listing all the possible consideration. I have tons of bug bounty reports unfixed for 3 months on various sites and I still email those sec teams back and forth to look at progress. It's an individual decision and with every decision comes a consequence to bear.

> If I tell you your social security number is now accidentally written in your HTML file (probably because you copied and pasted the wrong thing), and now I tell the world "hey come look at sneak's SSN" instead of waiting for you to resolve is wrong.

No, sharing links to published data on the public, unauthenticated web is not wrong.

How so?

People accidentally leak password in source code. Instead of telling HN everyone come look at this embarrassing source code, first thing to do is to contact source owner to remove it. Yes, there is cache and Internet archive, but don't publish that until resolved is the proper interpretation of responsible disclosure.

What if I discover a way to make ambulances explode by making a specially-crafted HTTP request? Is it OK for me to announce this to the world?

I reported this issue a long time ago. Got the same messages back from facebook as everyone else in the thread. I've reported other issues and always get the same thing back.

It sounds like Facebook Security gets a lot of pushback from the developers. Certain things like coffee shop attacks and a lot of other REAL ISSUES get no notice for a long time. It took up until last year to get a damn HSTS header.

I actually reported an issue today about a security practice they implemented completely incorrectly. I got a response back that it was not meant for any actual security.

In theory it's unacceptable, but in practice this is a big company with thousands of employees and a lot of moving parts. Small changes can be hard to make....which to get back to my original point is why facebook seems to just ignore a lot issues but keep the pipes open for the occasional big one.

I remember when back in the day Facebook didn't default to HTTPS. You could just put your 802.11 card to monitor mode, power up ettercap in an area where there are a lot of unencrypted WiFi packets flying around, and easily you have dozens of session cookies. Script-kiddie level.

More interesting would be to take over a network (MITM style) and set up iptables to route all connections to Facebook IP's to a local webserver (DNAT target helps). Then you host a phishing FB page and soon you have logged emails and passwords from unsuspecting users. I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself.

"I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself."

The certificate won't match. I don't know how many users will click past the big red warning page most browsers show, but I don't have much sympathy for them if they do.

I was referring to serving an ordinary HTTP page on port 80. Most people type facebook.com into the address bar and hit Enter (and don't have HTTPSEverywhere). In normal circumstances, Facebook would issue a redirect to https://facebook.com, but if you're controlling the network you just serve the front page via HTTP.

Yes, I suppose that might work at least some of the time. Most browsers these days, however, would send you to the https site simply because you had visited it more frequently unless you typed out the full url and managed not to select the offered completion.

> Most browsers these days, however, would send you to the https site simply because you had visited it more frequently

Actually, in that case, modern browsers would completely refuse to send you to the http site, even if you typed it in explicitly. All thanks to Facebook's 90 day HSTS header [0].

They could improve their security further by getting Facebook into the Chromium preload list. That list, which is shared with Firefox, eliminates the need for an initial, clear connection.

[0]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[1]: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...

You should have lots of sympathy for them, though. They're not on their guard about MITM attacks, so they deserve to have their data stolen?

I do have sympathy for them usually, just not when I wrote that. ;)

Remember Firesheep? http://en.wikipedia.org/wiki/Firesheep This addon was just more fuel to the fire to coax sites to move to ssl only.

Now even youtube uses SSL.

> I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself.

If the user has successfully reached Facebook in the past 90 days, then their browser will have seen FB's HSTS header, and refuse to connect without TLS... provided they're not browsing with IE. :(

I recently found that a very popular web-service serves its api console over HTTP, rendering all API keys vulnerable to MITM. I sent over a mail to their security issues mail address. Still waiting for a response.

Step 1 of securing an API: Use SSL.

So let me get this straight: this is just the classic non-HTTPS traffic sniffing.

I am not sure why Instagram isn't moving all calls to HTTPS. Instagram itself is not as complicated as Facebook and shouldn't really be bounded to HTTP so badly.

They can easily do 301/302 redirect to HTTPS, then perform HSTS (for browser, not for API calls) in addition and let the proxy like nginx handles it to their usual port 80 requests. Problem solved.

How much more work do they need to do to shift from HTTP to HTTPS? I just don't get it.

Instagram run on Amazon AWS, though Facebook finally moved Instagram to their own datacenters (as of June 2014) where FB use SSL hardware cards (cheaper than CPU and ELB for SSL on AWS).

We also terminate our SSL at the ELB level, which lessens the CPU load on nginx. -- http://instagram-engineering.tumblr.com/post/13649370142/wha...

http://www.zdnet.com/instagram-finally-picked-up-and-moved-f...

http://instagram-engineering.tumblr.com/post/89992572022/mig...

I'm trying to reproduce this on a macbook. I'm a developer, not a networks guy so please excuse me for not knowing the basics!

After doing `sudo tcpdump -In -i en0 -s 2048 -A dst i.instagram.com`, and using every instagram feature from my iPhone, nothing happens in the terminal.

```

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 2048 bytes

```

I try running with -v and -vv, but no difference (except it doesn't suggest running in verbose more).

After hitting C-c to stop the program, it outputs

```

0 packets captured

29816 packets received by filter

0 packets dropped by kernel

```

So there's a lot of things being captured, but the filter does not catch my Instagram activity. I'm logged in there, refreshing, getting images, getting followers/following, etc.

EDIT: oh shit, HN doenst do markdown. That sucks.

Same exact thing happening to me. I'm loading friends pages, liking photographs, and getting nothing.

HN does some minimal formatting. You can add emphasis to text with asterisks

You can also prepend your lines with two spaces for pre-formatted text/code

The gist doesn't show how to get your network card into monitor/promiscuous mode.

EDIT: I'm not sure -In work with default drivers, but I'll test with my private Mac at home later.

Well, are you connected to the same open wireless network as the iPhone, and are within close range of it? This isn't going to work on an WPA network. Try taking off your "dst i.instagram.com" filter and see what you're actually capturing.

Monitor/promiscuous mode only works on WEP and open wifi networks. I assume you have a WAP network so this isn't working. As a POC you can add your phone as a network interface. To do that:

     1. Plug in your iPhone/iPad into your computer via USB cable
     2. Go into Xcode Organizer and find your iDevice's UID
     3. Hop over to terminal and type 'rvictl -s <UID>'
     4. Type 'sudo tcpdump -n -i rvi0 -s 2048 -A dst i.instagram.com'
     5. Open Instagram on the device, and the packet info should appear in terminal. The rest is the same
     6. When you're done you can type 'rvictl -x <UID>'

Same goes for Android http://thehackernews.com/2014/07/instagram-mobile-app-issue-...

I found a way to hijack someone's instagram account by accident. All it took was signing up for Facebook.

Never could get any traction with Instagram to look into the issue.

Maybe try FB's bug bounty program?

https://www.facebook.com/whitehat

Websites need to start taking more responsibility with HTTPS. Reddit, and a few other popular sites can also have their sessions hijacked.

reddit was quick to patch the heartbleed bug, but I got downvoted when I put forward that it wasn't a big deal as HTTP is probably 99.99% of traffic.

Every couple of months one of my friends insists that she's "quitting Instagram" because of how often things go wrong on the platform. Several times a month she gets logged into someone else's account with full read/write/update access and I believe even gets access to their Facebook. Between the above, the 4+ accounts she's has deleted for no reason, and the bugginess of often having a blank UI, it's becoming harder and harder to enjoy browsing on Instagram.

Reply on news.ycombinator.com