Flickr: Invitations disclosure (resend feature)
hackerone.com
hackerone.com
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.
Why should another dev ever bother submitting a security issue to Yahoo if they have to deal with such obstinate silliness?
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/
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.
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...
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.
"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."
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.
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.
So maybe a feature-request for hackerone would be, don't auto-disclose on Fridays; instead bump to Monday. :)
My favorite is the deploy right before the vacation. The internal pressure is even higher in that case (the dev doesn't want anything on their mind during their vacation—totally understandable), but the outcome/cleanup is even worse—they're not there to fix their code (and possibly not even available since they might be on a plane).
I once worked in a company that had a manual for communications/dealing with the media, etc. And this was given to engineers.
(it was a company that did a product that was bought by governments and had an impact on people, so the chance of being interviewed by the press was higher than average)
Are the relationship pairs actually being exposed? All I can see are the email / name pairs - not who invited the user (and you have to be logged into a Yahoo account).
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?
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.
Edit: expiration would limit the scope of data leakage, and should also be looked into, but expiration without access controls still allows patient attackers to collect all of the data being generated and store it for future use.
Every company I have worked for has a support organization that deals with customer tickets like this. They might escalate the issue to development, or they might not. But either way they're the ones involved in the conversation.
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.."
I'm sure product decisions I've made seem odd and inscrutable to someone else, but that's because they don't know about the backend interface to a legacy system, etc.
I'm not really seeing any good reason _not_ to expire them...
See http://www.ietf.org/rfc/rfc4122.txt -->
6. Security Considerations -- Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
Furthermore, although the RFC makes a half-hearted attempt to nudge you in that direction, there is no assurance that any of the bits of a UUID are generated in a cryptographically secure manner. If you're using a UUID library that chooses its random numbers poorly, your results may be utterly non-random.
You can still load the invite/resend page, but you won't get any user info from it.
[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]
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.
weev didn't put his dump up on the pirate bay, he sent it to Gawker.
The response surprises me.
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!
For example, at the company I work for, we have a master list, with several levels. Things like password and SSN are the most sensitive, and have much more stringent requirements for how we handle them than a user name.
I think it'd be useful as a user to know what each company's policies are. Ex: Yahoo doesn't mind linking name/email publicly, so maybe I give them a false name. It'd also be useful for companies to compare themselves to their peers, and make corrections if/where they diverge.
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)?
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.
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.)
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.
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.
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.
- make the link protected by login
- accept only post requests
- generate more complicated, hard to guess tokens
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-...
Of course, using POST is not the only solution here (requiring the invitation to be by the signed-in user is way better), and it can represent a UX problem (refreshing causes the dreaded "form resubmit" warning).
But it's not a no-op. It does have effect in security in practice, even if it doesn't in theory.
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.
Should this have never happened? Absolutely. Does it display that Yahoo is "awful," absolutely not.
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>