
Flickr: Invitations disclosure (resend feature) - mathias
https://hackerone.com/reports/1533
======
secalex
Hey, HN, CISO of Yahoo here, typing on a phone at a kid's birthday, so excuse
the formatting.

We run a very progressive bug bounty program that allows bugs like this to be
posted publicly. Every once in a while we might miss something out of the
thousands of invalid reports we receive every month, and we made a mistake in
the triage of this bug. The bug is fixed and we won't make the same mistake
again. We definitely consider info disclosure to be a class of issue that
needs to be addressed and to infer otherwise from one mistake is incorrect.

There are a handful of companies experimenting with this kind of open bounty
model, and if we want it to survive (I certainly do) then we are going to all
have to be willing to iterate to fix the problem, and move on.

~~~
tomcorrigan
That's great, but you were aware of this issue for a month. If the whole point
of having a bug bounty program is that you benefit from the distributed
intelligence of the community you should perhaps place a bit more faith in
your unpaid and unrewarded labor. Do you really receive thousands of invalid
security reports every month or is user Schofield way out of their depth.

Why should another dev ever bother submitting a security issue to Yahoo if
they have to deal with such obstinate silliness?

~~~
epriest
> Do you really receive thousands of invalid security reports every month or
> is user Schofield way out of their depth.

Although our project is much smaller, we also run a bounty program through
HackerOne, and publish aggregate results every month. You can see them under
the "Security" headers of the changelog for the last few months to get a quick
sense of the overall composition of reports that come through a channel like
this, at least for our project:

[http://phabricator.org/changelog/](http://phabricator.org/changelog/)

For example, last month we received 49 reports, of which we believe 5 were
legitimate security issues which we fixed and awarded. Although the signal on
this channel is extremely valuable, it's embedded in a lot of noise, and
separating the two is often difficult and time consuming. It wouldn't surprise
me if we made mistakes with a few reports even at this relatively small scale,
and we have a much easier task than larger projects do.

I'm extremely supportive of HackerOne, but I'm always a little worried we'll
make a mistake and end up tried in the court of public opinion when we triaged
>99% of the reports correctly and the overall impact of the program is hugely
beneficial for researchers, for us, and for our users.

Of course, we should be aiming for 100%, and getting it right almost all the
time isn't a free pass for the cases when things go wrong, but seeing just the
cases where an issue wasn't handled correctly discards a lot of context.

~~~
collingreene
To echo this sentiment: In 2013 facebook received 14,763 submissions which
lead to 687 paid issues, 1 : 21 signal to noise. Facebook errs on the side of
paying out as often as possible even for lame bugs (apache shows its version
number in some talent acquisitions blog), code we didn't write, defense in
depth type stuff, instances where the reporter was wrong and there wasn't
actually a bug but in the process of investigating the non-bug we happened to
find a bug on our own etc. Given all that, I would (personal opinion) put the
number of useful, impactful security issues we received in 2013 at about 70.
If we use this guide its 1 : 211 signal to noise. In this sea of noise the
reports submitted are often in other languages or submitted by less clueful
people. This yahoo example the reporter explained the issue pretty well but in
my experience this is a rarity. A legit issue could come from anyone though,
even the guy who writes a sentence of Polish and sends you a 30sec youtube
video in 320x480.

Basically doing a bug bounty right is very hard.

Stuff like this will happen. By running a bug bounty at all you are opening
your company up to situations like this but the bigger picture is that you
care about security enough to still do it for the valid security issues bug
bounties find. It is a strong signal to me that a company actually cares about
security and we shouldn't lose focus of that in the midst of pitchfork-waving
"but yahoo was WRONG".

We recently released some stats that support all this here:
[https://www.facebook.com/notes/facebook-bug-bounty/bug-
bount...](https://www.facebook.com/notes/facebook-bug-bounty/bug-bounty-
highlights-and-updates/818902394790655)

~~~
secalex
Thank you for your data. I'm hoping to do a talk this fall with detailed stats
after we have a whole year on this platform, but to a first order
approximation your ratios do not look far off from our experience.

------
abalone
I love how publicly posting bugs shifts the balance of power. "schofield"
probably though it was just a conversation between Yahoo and the submitter.
Now it's a conversation between Yahoo and Hacker News.

Welp, the verdict is schofield is being dense. Of course user relationship
pairs are potentially sensitive. Therefore enabling attackers to discover them
by enumerating your tiny key space is an issue.

Either schofield needs to wisen up or Yahoo needs to put someone better in
charge of their security issues.

~~~
nknighthb
Companies need to send out an email to all employees every morning reminding
them of the most basic law of corporate communications:

"When you speak to a customer, reporter, friend, or any other person not
employed by $Company about $Company-related matters, you are acting as a
public representative of $Company.

Regardless of whom you speak to or in what context, you must assume your words
will be repeated to the entire world as $Company policy.

Your words will be read/heard and interpreted by people of every conceivable
level of intelligence and education, in every conceivable cultural context.
Even people who have never heard of $Company before and know absolutely
nothing about $Company or the matters you are discussing will form opinions
based on your words.

People more intelligent, better educated, and more experienced than you in the
matters you are speaking about will also read and interpret your words. Then
they will speak publicly about them, and further influence others' opinions of
$Company.

There are no exceptions."

~~~
6cxs2hd6
Also, maybe my time zones are wrong, but it seems like the engineer changed
the bug status to "disclosed" late in the day Friday?

A corollary: Don't do sh*t late Friday that will fester over the weekend.

It makes me mental when people want to "close their week" by deploying a
change to a public-facing system. Yes it feels great to check it off your list
and start your weekend. But unless you're prepared to deal with it over the
weekend -- and got buy-in from the rest of your team they're prepared to deal
with it -- please don't.

~~~
toomuchtodo
I run ops at my current ship, and my counterpart is our lead developer.

I'm not sure how it works elsewhere, but together we have a very strict "We DO
NOT deploy production changes on Friday". New chef script? Monday. Change to
how we're sending writes or reads to different DB clusters? Monday.

I do not know why this isn't the norm in more places.

~~~
toomuchtodo
s/ship/shop

~~~
lengads
I quite like the idea of calling one's workplace a ship. I'll take that
expression on board, sea if it floats.

~~~
lloyddobbler
Definitely. Ship that shit.

------
kintamanimatt
The response to this bug is atrocious and shameful. The developer that
responded to this did the same as putting on a blindfold and declaring that
because they could no longer see the bug, it must not exist.

Right from the get-go, schofield showed incompetence when they declared they
couldn't reproduce the bug, even though it was explained to them plainly and
thoroughly!

How do these inept developers get hired?

~~~
vidarh
Furthermore, Yahoo can not unilaterally choose to define what is "sensitive".
In the EU, many countries implementation of the Data Protection Directive
considers e-mail addresses personally identifiable information, which makes it
subject to the relevant laws.

Given that Yahoo operates in a number of European countries, and have offices
and legal entities in many of them, this potentially means they are _legally
liable_ for data protection breaches if they don't plug this hole.

~~~
omegote
Indeed. In Spain, the LOPD (Data Protection Law) states that the email is
personal information. Many companies have been fined for leaking emails,
specially when sending mass emails with all the addresses in the "To:" field
instead of BCC.

~~~
gaadd33
Are First/Last names personal information in Spain too? So a customer list
would also have the same protections?

------
jpalomaki
A simple fix seems to be to use longer random id for the invitation.

As d4d1a179c0f3 mentions, this kind of information could be useful for setting
up more targeted phishing attacks. "Hi John, remember the Flickr invite for
holiday photos I sent you two weeks ago? I moved my albums to new site, please
go to blackhat.org/malwaredl.."

~~~
crucio
Yeah it would be a fairly simple fix in code: they could hash some of the user
data (e.g. email + name) and then append the id to create a token that won't
ever collide and is always unique. e.g.
[http://www.flickr.com/invite/?resend=<hash>-<id>](http://www.flickr.com/invite/?resend=<hash>-<id>)

~~~
Sovietaced
Exactly what I was thinking, expiration isn't even necessary.

~~~
kngspook
Of course, hashing _and_ expiration would be best.

I'm not really seeing any good reason _not_ to expire them...

------
andrelaszlo
This bug was fixed just seconds ago. The power of HN :)

You can still load the invite/resend page, but you won't get any user info
from it.

------
chris_overseas
So I clicked on one of the example invite links listed in the bug report. I
was then prompted to log in to my Yahoo account. Hmm, OK... so I logged in, at
which point I was taken to a page with a form asking me to join Flickr. I did
NOT fill in or submit the form because I don't want a Flickr account, though
it was presented with defaults based on my Yahoo ID anyway. I closed that
window and tried clicking on an invite link again. Much to my surprise, the
link then worked and I received an email saying "Welcome to Flickr". What the
hell?

[edit: on the plus side, Flickr make it very easy to delete your account
entirely. The only obvious side effect is that the screen name you had is now
unavailable for any further users]

------
diziet
The collision rate seems pretty high and to someone with a bit of resources
(say 500 ips) to go through the ids would take 3~ days at 1 request per
second.

The party would have a list of of flickr users / email combinations.

The best way to fix this if they want to have the urls work for some backward
compatible reason is probably severe rate limiting after x requests if they do
not want to expire these requests -- right? Otherwise, something the size of
UUID will make the search space too large.

~~~
baby
This is not a collision rate. Collision is when two plain text gives the same
hash.

~~~
unreal37
No, collision is not exclusively for hashes. The term can be used for any area
where there's a high ability to encounter a value already in use. In this
case, by guessing or incrementing.

------
jcromartie
Isn't this basically how weev got sent to federal prison?

~~~
aw3c2
No, there is a difference between accessing things and publishing things with
malicious intent.

~~~
mukyu
Most people would not call only releasing the data to a journalist
"publishing", and much less "with malicious intent".

weev didn't put his dump up on the pirate bay, he sent it to Gawker.

------
markbnj
Can we not call this a "bug?" It's clearly a design weakness and "schofield"
said it was working as intended, ergo not a bug, but just a poor choice of
mechanism. Pretty humorous that "schofield" thought it was fine the way it is.
Guess that has been cleared up by the internet. It's pretty trivial to
generate a random, non-guessable, unique code to use as a lookup key for the
invitation, and I guess that's what they've done.

------
zhte415
Knowing an individual's network of names and email contacts in a highly
specific domain could be quite attractive for a phisher. This seems quite
different from viewing the contact list on, say, Twitter, where an individual
explicitly makes their contacts known to the world (and via synonym only).

The response surprises me.

------
e28eta
I saw a similar issue with a company that sold tickets to events several years
ago. They sent me an email with a link to my e-ticket. The URL had a
sequential id, and there was no auth/verification that I was the one who
purchased it.

So, I took a look at the person who ordered before me, and was able to view
their name/address, and could have printed their tickets to the event!

------
tszming
Actually the Yahoo! employee (schofield?) in the above link is right and you
cannot blame him for this - it is because Yahoo! really think first name +
last name + email are not private information AFAIK, not particularly to
Flickr, there are multiple ways to retrieve these information...

~~~
orblivion
Relations are another interesting thing. That would make phishing much more
effective. Though I suppose somebody's Yahoo profile page should get them
access to that as well.

~~~
alceufc
There was also the invitation text which might contain private messages.

------
vletmixutechre
Awe, I was in the middle of writing a scraper for this and it seems they have
now "fixed" it.

------
andenq
Well thats messed up... At least now I know how spammers get my email :D

~~~
dlss
As jpalomaki points out it's better than that... We are entering a brave new
world of spam that's "from" people you know.

~~~
ars
No, we've been there for a long long time now.

I use different email address for different people, and virtually every single
one of them has been harvested and used to send spam from that person.

At this point I don't expect email to be secure at all. You basically have to
expect that unless you are dealing with someone with IT skills their email
will inevitably get hacked.

The implication is that email is NOT a good way of doing password resets. The
problem is what's the alternative (that doesn't require specialized hardware,
like a 2nd auth token generator)?

~~~
mcintyre1994
You don't need to hack someone's account to send mail as them, you just need a
server that will get into the popular services. That's the reason social
graphs are sensitive, match up people who trust each other and send them
messages as each other.

Interesting point about password resets though, if you can read (have hacked)
the email you're into pretty much any account. BTW in case you're unaware any
Android/iOS device can run Google authenticator and generate 2FA tokens. Email
behind 2FA is probably the best security/friction tradeoff for that sort of
message, but not many people use it.

~~~
ars
> You don't need to hack someone's account to send mail as them, you just need
> a server that will get into the popular services.

They emailed me on an address only used by them in their email, and not in any
other service. That only way I could get spam on that address is if their
email was hacked. (Either remote, or locally via their desktop.)

~~~
fordh
What about spoofing?
[http://en.wikipedia.org/wiki/Email_spoofing](http://en.wikipedia.org/wiki/Email_spoofing)

~~~
jessaustin
I think 'ars is saying that these are "personalized" email addresses: there is
a separate one for each person from whom 'ars wants to receive email. Assuming
these addresses aren't easily guessable/enumerable, and aren't on any lists
stolen from or sold by service providers, the spammer must have have gotten
them _somewhere else_.

~~~
vidarh
The problem is that pretty much every one of them have probably given one or
more services access to download their contact data to connect them to their
friends, so any number of services other than their e-mail likely contains
these personalized e-mail addresses.

 _Someone_ has likely been hacked or sold/leaked data, but he should assume
that those addresses have been spread quite a bit voluntarily by his
friends/associates.

~~~
jessaustin
OK, that makes sense.

------
merijn481
Yahoo has fully embraced working with security researchers. For a company
their size (they're no. 1 in web traffic!) with that many different services,
they're doing an amazing job. No company that size has ever moved this fast.
Yes, they're catching up but they do it fast!

------
peterwwillis
Why the hell do companies think it's trivial to just give away data about huge
swaths of its user base? Is it some kind of ego thing, like, they aren't
willing to admit it's a security issue, so just pretend like this is a feature
and not a bug?

------
Joshu42
it's really easy to capture contacts this way. As Mathias said, they have to
limit the view of the saved form to the one who sent it in the first place...
and add an expiration for deleting such data.

So what's missing ? an ID for knowing the first sender, a timestamp, a
checking process and a garbage collector to delete the expired ones
periodically ? Ok, we don't add a column so easily in the big DB table here,
but they can add a sister table with both IDs, the timestamp and a "IsActive"
boolean... and start filling the new table with no reference ID, so only the
timestamp works for the existed ones. the system will repair itself at the end
of the expiration date.

~~~
mathias
Minor correction: it was “d4d1a179c0f3” who reported and suggested that
solution, not me (although I agree with their proposal). I’m just the guy who
posted this on Twitter
([https://twitter.com/mathias/status/452714683628527616](https://twitter.com/mathias/status/452714683628527616))
and Hacker News.

------
mathias
Looks like someone just changed the title of this HN submission. For the
record, it originally said: “Full name and email for every Flickr invite ever
sent can be viewed by anyone”, which was accurate at the time of posting.

~~~
dang
I changed the title in accordance with the HN guidelines.

~~~
mathias
Which guideline in particular? “Otherwise please use the original title,
unless it is misleading or linkbait”? The new title is definitely not as clear
IMHO.

~~~
dang
That's the one.

I agree that it isn't as clear, but (a) it isn't misleading, and (b) we use
the original title unless there's a strong reason to change it.

------
maouida
To fix,this, they should

\- make the link protected by login

\- accept only post requests

\- generate more complicated, hard to guess tokens

~~~
zero-error
Regarding your second suggestion, how would allowing only POST requests stop
this from being exploited?

POST requests aren't any more secure than GETs[0] in the context of this
exploit, so surely it would make no difference if the attacker was forced to
send one type instead of another?

It would also mean that the intended recipients of the Flickr invites would be
unable to accept them because you can't POST via links in emails.

[0] [https://stackoverflow.com/questions/198462/is-either-get-
or-...](https://stackoverflow.com/questions/198462/is-either-get-or-post-more-
secure-than-the-other)

~~~
jessaustin
Maybe this is a repetition of that old "POST-only prevents CSRF" myth?

------
mantrax4
Schofield, you're _fired_!

Maybe the incentives are wrong. Less bugs, less work for the dev.

Maybe the people processing bug submissions should be paid more per bug
submitted and should not be on the same team as the developers.

But there's ocean of incompetence out there, and clever processes can only get
you so far when you're dealing with incompetence.

------
pratnala
Shame on you, Yahoo!

------
nilved
I have no idea why anybody would do business with a company as awful as Yahoo
in 2014.

~~~
1945
Yahoo has roughly 12,000 employees, so you can imagine controlling what those
12k employees do on a daily basis is next to impossible.

Should this have never happened? Absolutely. Does it display that Yahoo is
"awful," absolutely not.

~~~
nilved
You're assuming that my comment was based on this incident alone.

------
yp_master
Anyone able to view this site without Javascript?

------
flylib
The propaganda completely unbacked license response by Yahoo to the
Openstack/MongoDB fiasco and now this are making me want to delete my account
on the site

------
ludicast
<paranoid>This is why the bitcoin thefts concern me. Now you have a bunch of
bad guys with battle-tested black-hat skills and plenty of millions at their
disposal.

So they can easily afford a giant cluster to throw up phantomjs instances to
scape this data in an easily throttleable way. Not that they would be
particularly interested in this case, but similar ones for sure.

I think we will see this WAY more in the future. If your email/name retrieval
is not an intractable problem, you might as well put up a spreadsheet with the
info.</paranoid>

