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.
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?
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.
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.
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).
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!
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.
I don't think schofield's response was great, but he certainly didn't pretend the submitter was making something up, he just didn't think the information exposed is sensitive. Realistically this isn't a bug in the software, it's an issue with the design of the invitation feature from a legal/UX standpoint. Either the user sending the information should be aware the information is not private and/or the invitations should expire at some point.
Why do you think schofield is a developer? I didn't see any indication in this conversation.
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.
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.."
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>
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]
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.
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.
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).
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!
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...
I work on both sides of the fence. I respond to reports by researchers and I submit my own fair share to a large number of companies. The problem that is always present and which all employee's taking vulnerability reports need to understand is that there are scenarios outside of their realm of thinking which could bite them. In this case Schofield shouldn't have pushed back on the researcher and instead used the report as justification via a 'headline test' with the development team to make what should have been a simple code modification to use a strong random identifier. Instead Schofield introduced organizational bias that the information wasn't sensitive and now looks rather silly as a result, especially given it looks like the issue may have just been remediated. It is never good when a problem can't be tackled within a 30 day window at the frustration of a security researcher but can then be tackled within a matter of hours over a weekend.
I wonder what it would take to compile a directory of companies and the way each one classifies each piece of their users' data.
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.
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.
Glad to see people still see spam as a problem, a few days ago when there was an article about Twitter Spam people where making it out like Email Spam has gone away and that Twitter should implement the same rules.
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!
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?
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.
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) and Hacker News.
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.
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.
[+] [-] secalex|12 years ago|reply
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|12 years ago|reply
Why should another dev ever bother submitting a security issue to Yahoo if they have to deal with such obstinate silliness?
[+] [-] abalone|12 years ago|reply
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|12 years ago|reply
"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."
[+] [-] diziet|12 years ago|reply
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).
[+] [-] kintamanimatt|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] sugerman|12 years ago|reply
[+] [-] peeters|12 years ago|reply
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.
[+] [-] jpalomaki|12 years ago|reply
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|12 years ago|reply
[+] [-] andrelaszlo|12 years ago|reply
You can still load the invite/resend page, but you won't get any user info from it.
[+] [-] chris_overseas|12 years ago|reply
[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|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] baby|12 years ago|reply
[+] [-] jcromartie|12 years ago|reply
[+] [-] aw3c2|12 years ago|reply
[+] [-] markbnj|12 years ago|reply
[+] [-] zhte415|12 years ago|reply
The response surprises me.
[+] [-] e28eta|12 years ago|reply
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|12 years ago|reply
[+] [-] patcheudor|12 years ago|reply
[+] [-] e28eta|12 years ago|reply
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.
[+] [-] tete|12 years ago|reply
[+] [-] orblivion|12 years ago|reply
[+] [-] vletmixutechre|12 years ago|reply
[+] [-] andenq|12 years ago|reply
[+] [-] dlss|12 years ago|reply
[+] [-] newaccountfool|12 years ago|reply
[+] [-] merijn481|12 years ago|reply
[+] [-] peterwwillis|12 years ago|reply
[+] [-] Joshu42|12 years ago|reply
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|12 years ago|reply
[+] [-] mathias|12 years ago|reply
[+] [-] dang|12 years ago|reply
[+] [-] maouida|12 years ago|reply
- make the link protected by login
- accept only post requests
- generate more complicated, hard to guess tokens
[+] [-] zero-error|12 years ago|reply
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-...
[+] [-] baby|12 years ago|reply
[+] [-] mantrax4|12 years ago|reply
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.