8 ms·

Flickr: Invitations disclosure (resend feature)

317 points by mathias 13y ago

jpalomaki 13y ago
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 13y ago
  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 13y ago
    Exactly what I was thinking, expiration isn't even necessary.
    - kngspook 13y ago
      Of course, hashing _and_ expiration would be best. I'm not really seeing any good reason _not_ to expire them...
  - nilved 13y ago
    Or just use a UUID.
    - logn 13y ago
      UUIDs (depending on the version) could be easier to guess than a hash or random string. See http://www.ietf.org/rfc/rfc4122.txt 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.
      - nknighthb 13y ago
        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.
        jamiesonbecker 13y ago
        Even so, UUID's would be nearly infinitely better than the current model of incrementing integers! Wow...
  - eli 13y ago
    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.
andenq 13y ago
Well thats messed up... At least now I know how spammers get my email :D
- dlss 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        > 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.)
diziet 13y ago
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 13y ago
  This is not a collision rate. Collision is when two plain text gives the same hash.
  - unreal37 13y ago
    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.
  - ubershmekel 13y ago
    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.
- deleted 13y ago
  [deleted]
abalone 13y ago
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.
- diziet 13y ago
  To be fair the 'schofield' has been diligent before: https://www.google.com/search?q=site:hackerone.com+schofield https://www.google.com/search?q=site:hackerone.com+schofield 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).
  - jamesbrownuhh 13y ago
    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.
- nknighthb 13y ago
  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."
kintamanimatt 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      Are First/Last names personal information in Spain too? So a customer list would also have the same protections?
- sugerman 13y ago
  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.
zhte415 13y ago
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.
mantrax4 13y ago
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.
chris_overseas 13y ago
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]
nilved 13y ago
I have no idea why anybody would do business with a company as awful as Yahoo in 2014.
- 1945 13y ago
  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 13y ago
    You're assuming that my comment was based on this incident alone.
pratnala 13y ago
Shame on you, Yahoo!
Joshu42 13y ago
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 13y ago
  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.
ludicast 13y ago
<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>
flylib 13y ago
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
peterwwillis 13y ago
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?
jcromartie 13y ago
Isn't this basically how weev got sent to federal prison?
- aw3c2 13y ago
  No, there is a difference between accessing things and publishing things with malicious intent.
  - mukyu 13y ago
    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.
maouida 13y ago
To fix,this, they should - make the link protected by login - accept only post requests - generate more complicated, hard to guess tokens
- zero-error 13y ago
  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-post-more-secure-than-the-other https://stackoverflow.com/questions/198462/is-either-get-or-...
  - jessaustin 13y ago
    Maybe this is a repetition of that old "POST-only prevents CSRF" myth?
  - mantrax4 13y ago
    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.
- baby 13y ago
  I think making longer and more complicated token is enough.
tszming 13y ago
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...
- tete 13y ago
  Can you tell us about them?
- orblivion 13y ago
  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 13y ago
    There was also the invitation text which might contain private messages.
- patcheudor 13y ago
  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.
- e28eta 13y ago
  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.
andrelaszlo 13y ago
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.
vletmixutechre 13y ago
Awe, I was in the middle of writing a scraper for this and it seems they have now "fixed" it.
yp_master 13y ago
Anyone able to view this site without Javascript?
e28eta 13y ago
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!
markbnj 13y ago
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.
secalex 13y ago
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 13y ago
  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?
  - donohoe 13y ago
    Did you not read the part where they stated they missed this one and didn't remedy it as they should have?
  - epriest 13y ago
    > 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.
merijn481 13y ago
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!
mathias 13y ago
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 13y ago
  I changed the title in accordance with the HN guidelines.
  - mathias 13y ago
    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 13y ago
      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.

317 points by mathias 13y ago

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 13y ago
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 13y ago
  Exactly what I was thinking, expiration isn't even necessary.
  - kngspook 13y ago
    Of course, hashing _and_ expiration would be best. I'm not really seeing any good reason _not_ to expire them...
- nilved 13y ago
  Or just use a UUID.
  - logn 13y ago
    UUIDs (depending on the version) could be easier to guess than a hash or random string. See http://www.ietf.org/rfc/rfc4122.txt 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.
    - nknighthb 13y ago
      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.
      - jamiesonbecker 13y ago
        Even so, UUID's would be nearly infinitely better than the current model of incrementing integers! Wow...
- eli 13y ago
  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.

andenq 13y ago

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

dlss 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      > 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.)

diziet 13y ago

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 13y ago
This is not a collision rate. Collision is when two plain text gives the same hash.
- unreal37 13y ago
  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.
- ubershmekel 13y ago
  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.
deleted 13y ago
[deleted]

abalone 13y ago

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.

diziet 13y ago
To be fair the 'schofield' has been diligent before: https://www.google.com/search?q=site:hackerone.com+schofield https://www.google.com/search?q=site:hackerone.com+schofield 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).
- jamesbrownuhh 13y ago
  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.
nknighthb 13y ago
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."

kintamanimatt 13y ago

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 13y ago
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 13y ago
  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 13y ago
    Are First/Last names personal information in Spain too? So a customer list would also have the same protections?
sugerman 13y ago
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.

zhte415 13y ago

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.

mantrax4 13y ago

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.

chris_overseas 13y ago

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]

nilved 13y ago

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

1945 13y ago
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 13y ago
  You're assuming that my comment was based on this incident alone.

pratnala 13y ago

Shame on you, Yahoo!

Joshu42 13y ago

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 13y ago
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.

ludicast 13y ago

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

flylib 13y ago

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

peterwwillis 13y ago

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?

jcromartie 13y ago

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

aw3c2 13y ago
No, there is a difference between accessing things and publishing things with malicious intent.
- mukyu 13y ago
  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.

maouida 13y ago

To fix,this, they should - make the link protected by login - accept only post requests - generate more complicated, hard to guess tokens

zero-error 13y ago
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-post-more-secure-than-the-other https://stackoverflow.com/questions/198462/is-either-get-or-...
- jessaustin 13y ago
  Maybe this is a repetition of that old "POST-only prevents CSRF" myth?
- mantrax4 13y ago
  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.
baby 13y ago
I think making longer and more complicated token is enough.

tszming 13y ago

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

tete 13y ago
Can you tell us about them?
orblivion 13y ago
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 13y ago
  There was also the invitation text which might contain private messages.
patcheudor 13y ago
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.
e28eta 13y ago
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.

andrelaszlo 13y ago

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.

vletmixutechre 13y ago

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

yp_master 13y ago

Anyone able to view this site without Javascript?

e28eta 13y ago

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!

markbnj 13y ago

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.

secalex 13y ago

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 13y ago
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?
- donohoe 13y ago
  Did you not read the part where they stated they missed this one and didn't remedy it as they should have?
- epriest 13y ago
  > 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.

merijn481 13y ago

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!

mathias 13y ago

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 13y ago
I changed the title in accordance with the HN guidelines.
- mathias 13y ago
  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 13y ago
    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.