
Instagram iOS session hijack - sjtgraham
https://gist.github.com/stevegraham/9a98627eebd6b09d4483?hn
======
sjtgraham
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](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.

~~~
sjtgraham
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.

~~~
smtddr
_> >"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](http://en.wikipedia.org/wiki/Firesheep)

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

~~~
sjtgraham
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.

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

~~~
tansou_471ss
#1380asal

~~~
tansou_471ss
salam

------
minimaxir
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._

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

~~~
Sephr
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.

~~~
InAnEmergency
> 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.

~~~
danielweber
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.

------
sneak
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.

~~~
yeukhon
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.

~~~
sneak
> 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.

~~~
yeukhon
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.

------
0xeeeeeeee
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.

------
thegeomaster
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.

~~~
aptwebapps
"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.

~~~
thegeomaster
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](https://facebook.com), but if you're controlling the
network you just serve the front page via HTTP.

~~~
aptwebapps
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.

~~~
callahad
> _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](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

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

------
captn3m0
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.

------
yeukhon
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.

~~~
frik
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://instagram-
engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-
instances-dozens-of)

[http://www.zdnet.com/instagram-finally-picked-up-and-
moved-f...](http://www.zdnet.com/instagram-finally-picked-up-and-moved-from-
aws-to-facebook-7000031014/)

[http://instagram-
engineering.tumblr.com/post/89992572022/mig...](http://instagram-
engineering.tumblr.com/post/89992572022/migrating-aws-fb)

------
fdsary
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

```

^C

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.

~~~
AmarJayR
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>'

------
NietTim
Same goes for Android [http://thehackernews.com/2014/07/instagram-mobile-app-
issue-...](http://thehackernews.com/2014/07/instagram-mobile-app-issue-leads-
to_27.html)

------
pgrote
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.

~~~
greggarious
Maybe try FB's bug bounty program?

[https://www.facebook.com/whitehat](https://www.facebook.com/whitehat)

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

~~~
skeletonjelly
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.

------
Ryel
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.

