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?
> 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:
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.
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".
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.
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.
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.
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.
I haven't used hackerone myself, so this is just based on limited observation, but it looks to me like it was automatically disclosed one month after the reporter made the request. Otherwise, I believe it would have said something like "schofield agreed to make this public".
That is correct. The reporter requested public disclosure after the report was closed. The bug automatically gets disclosed publicly 30 days after the report is closed, unless the team requests more time by re-opening the bug. You can read more about the disclosure philosophy here: https://hackerone.com/guidelines
Another interesting feature might be notifying the engineering team that a following list of bugs will be automatically disclosed in x days and give them a chance to review them with a fresh pair of eyes.
> 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.
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)
where I work they do and they require online training and signing (electronically) a statement to the effect that you understand. of course that doesn't mean it doesn't happen all the time. Your suggestion is about as useful as a chocolate fireguard I'm afraid.
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).
Leaking someone's email address and associated name is bad enough. If Yahoo don't see that as sensitive it places the ability of miscreants to entirely own and abuse Yahoo Mail accounts in some kind of institutional context.
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.
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.
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.
Expiration helps very little if the valid IDs are still easily enumerable. Access control, not expiration, is what is called for here.
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.
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>
Sure, of course, but I would caution against playing armchair developer on someone else's product.
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.
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.
Under no circumstances are RFC-compliant UUIDs of any version as secure as a properly-generated 128-bit (or more) key. Even version 4 and 5 UUIDs necessarily have non-random bits.
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.
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.
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.
col·li·sion
kəˈliZHən/Submit
noun
1.
an instance of one moving object or person striking violently against another.
"a midair collision between two aircraft"
synonyms: crash, accident, impact, smash, bump, hit, fender bender, wreck, pileup More
an instance of conflict between opposing ideas, interests, or factions.
"a collision between experience and theory"
synonyms: conflict, clash; More
2.
COMPUTING
an event of two or more records being assigned the same identifier or location in memory.
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.
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)?
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.
> 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.)
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.
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.
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.
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.
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.
Allowing only POST requests can help for one simple reason - it's harder for people to share the link without knowing what they're giving away.
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.
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
<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>
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.