15 ms·

Thank you to everybody who cautioned against judgment before hearing the whole story. Here is my response: https://www.facebook.com/notes/alex-stamos/bug-bounty

• deleted 11y ago
  [deleted]
• tdicola 11y ago
  Thanks for the response, but why did you start by contacting the CEO of Synack instead of the researcher directly?
  • blazespin 11y ago
    Yeah, why not just a quick email- "Hey are you working for Synack here or independently?"
    • DullDeveloper 11y ago
      Supposedly he was using his synack email address, why would they assume he worked independently?
      • kelvie 11y ago
        He posted a reply on his blog saying that the only used his synack email address after the initial exchange with the synack CEO
  • arasmussen 11y ago
    > At this point, it was reasonable to believe that Wes was operating on behalf of Synack. His account on our portal mentions Synack as his affiliation, he has interacted with us using a synack.com email address, and he has written blog posts that are used by Synack for marketing purposes. I feel like that bullet point answers your question pretty well.
    • tdicola 11y ago
      I'm more questioning the flow of researcher reports vulnerability, company awards bounty, researcher disputes bounty value, CSO of company contacts CEO of researcher's company. Is that normal escalation procedure?
      • tptacek 11y ago
        Wait, you just made something up. Even the researcher doesn't claim that Alex contacted the CEO of Synack because of a dispute over the bounty. Rather, it's the other way around: the researcher disputed the bounty, and did so by revealing that he'd retained AWS credentials from Instagram long after they'd closed the vulnerability that he used to get them. Alex contacted the CEO of Synack to ensure the credentials weren't used, because if they were, Alex couldn't be control Facebook's response: they've got a bug bounty participant who has essentially "gone rogue" and is exploiting Facebook servers long after they've told him to stop. They need him to stop.
        • brazzledazzle 11y ago
          The "bug" here is that they aren't really keeping track of their AWS buckets and keys at all. Least privilege, access logging, remote IP flagging, etc. These operational failures are ostensibly the responsibility of the CSO. I'm not saying this researcher was 100% in the right, but this is the CSO ass covering. "Don't pay attention to the obvious operational deficits, the problem is the researcher overreaching." A simple phone call directly to the researcher that cut through the bullshit would have made everything better. But he had to make sure it didn't get out and the only way he could do that was by using the only leverage he had: The researcher's employer.
          • tptacek 11y ago
            Alex has in the last few months built one of the best teams in application security at Facebook (Facebook security is now seemingly most of O.G. iSEC Partners). I get it, everyone hates big companies and especially Facebook evil Facebook but, come on. They know what they're doing. If you understand how security works inside of big companies, this is a really silly theory to run with. CSOs are happy when shit like this gets discovered, because it gives them ammunition to get the rest of the company to adjust policies. If you were working from the understanding that a CSO comes in and just immediately tells a team of (what is it) NINE THOUSAND developers how to do stuff differently... no. That's not how it works. The problem is that nobody at Facebook with the possible exception of like 10 people none of whom are Alex can make huge operational changes like "change all the ways we store keys across an entire huge business unit". So, you tell Alex you took AWS credentials he didn't know existed and you're going to start mining them for a story you're bringing to the media, and now Alex is in a position where he's NOT ALLOWED to sit back and try to manage the situation himself. Delete the keys or I have to tell legal what's happening. The researcher NEEDED TO HEAR THAT.
• deleted 11y ago
  [deleted]
• dsacco 11y ago
  Thank you for the response, Alex, especially the details about the researcher's email address and affiliation. It makes your actions seem reasonable, in my opinion. As a security researcher, I personally would not be dissauded from reporting to the Facebook Whitehat program due to this incident. I'm glad companies can offer transparency like this.
  • phaed 11y ago
    > Thank you for the response, Alex... It makes your actions seem reasonable... I'm glad companies can offer transparency like this. The people who like you the most and are the easiest to persuade.
  • Mandatum 11y ago
    I think his response was too personal. They're both adults, and calling his employing company's CEO to make a point because you can, is to me, way too close for comfort. There were other personal attacks in his response that I've talked about here: https://news.ycombinator.com/item?id=10755402 https://news.ycombinator.com/item?id=10755402
• deleted 11y ago
  [deleted]
• bigiain 11y ago
  So the bits where you lost the ssl keys, auth cookie keys, app signing keys, push notification keys - and had to ask him (via his employer) about what data he'd accessed are all true? Implying you have no records of who else might have done this and acquired those keys? Boggle!
  • gsnedders 11y ago
    That's one interpretation: the other is that you're placing faith in them being honest, and you'll get a list of what he'd got without the time of doing forensics of the systems, and hence being able to change the keys sooner.
    • bigiain 11y ago
      "Placing faith in them being honest", in the same conversation you're having with their uninvolved employer saying what they found is " trivial and of little value" at the same time as threatening them with Facebook's legal team and law enforcement? Doesn't pass the sniff test from here. (Admittedly there's no doubt an iceberg-sized bit of this whole drama that neither side are admitting exists.)
• brazzledazzle 11y ago
  The lesson here is when you find Operations issues (particularly Security Operations) at Facebook don't report them. Those make the CSO look bad directly.
  • blazespin 11y ago
    Yep. Code bugs, no problem. Engineers don't report to Alex!
• blazespin 11y ago
  The real question is did you rotate the keys (and do further hardening, I hope!) because of the vuln report Wes made? If so, than you should be grateful for his work pointing out your mistaken single point of failure via AWS S3 security and you should have rewarded him handsomely.
  • bigiain 11y ago
    I can't work out how to not make this sound almost infinitely cynical, but their ssl key expires in 13 days - they only had to shut him up for another few weeks and they could have pretended they weren't currently MITM-able: https://www.instagram.com https://www.instagram.com Not Valid After: Thursday, 31 December 2015 11:00:00 pm Australian Eastern Daylight Time Maybe they'll upgrade it to something better than: Signature algorithm SHA1withRSA WEAK
    • agrot3ra 11y ago
      Does this have anything to do with the SHA1 sunset on 31 December?
      • bigiain 11y ago
        That'll be why the key expires on Dec 31 even though it was only issued back in April. It doesn't explain why Instagram has been happily using a known-compromised wildcard ssl key for two weeks now. Makes you wonder who actually values and protects Instagram's user privacy more - the researcher or the Facebook CSO...
        • Phlarp 11y ago
          >Makes you wonder who actually values and protects Instagram's user privacy more - the researcher or the Facebook CSO... No, I don't wonder about this at all.
      • secalex 11y ago
        Different key, dude. We rotated what was exposed.
• CptMouse 11y ago
  Yep, my opinion of Facebook reinforced to the highest extent. Utter amateurism and disgusting behaviour. What an absolutely idiotic way to handle this situation, and coming from the very top. I haven't used Facebook in years, thank you for an excellent reminder to delete my Instagram account. edit: Alex, how about the "shit, we really fucked up; I apologise to our users, yadda yadda" blog post?
• ryanlol 11y ago
  Why have you not rotated your private keys? notBefore=Apr 14 00:00:00 2015 GMT notAfter=Dec 31 12:00:00 2015 GMT (Feel free to respond here if you want to pay me the bug bounty for this)
  • res0nat0r 11y ago
    $ echo | openssl s_client -connect www.instagram.com:443 2>/dev/null | openssl x509 -noout -dates notBefore=Apr 14 00:00:00 2015 GMT notAfter=Dec 31 12:00:00 2015 GMT AWS bucket creds are not the same thing as SSL certs and were most likely specific to only relevant s3 buckets which are totally separate from any load balancers.
    • ryanlol 11y ago
      I never claimed that AWS bucket creds were the same thing as SSL certs.
      • res0nat0r 11y ago
        Then rotating their SSL keys shouldn't be relevant.
        • tck42 11y ago
          Unless I'm misunderstanding, it's relevant because this researcher was able to access (from the blog): -- SSL certificates and private keys, including both instagram.com and *.instagram.com If this researcher was able to access it via not much more than a hole that was _already reported multiple times_, then I think it's not a stretch to think that [many?] other less honest parties could (and in my opinion most likely do) already have it. If it was me, even if it's definitely only a single researcher who got access (and it doesn't sound to me like they know for sure - but regardless), something _that_ sensitive would have to be rotated anyways. If it was someone outside the teams that strictly require access to it operationaly, I'd rotate it, let alone outside the company.
• meshko 11y ago
  Sounds like FB acted pretty unprofessionally both in the infrastructure department and in handling of the situation. You had some embarrassing mistakes and instead of acknowledging them you tried to scare the reporter into shutting up and leaving you alone. That part is pretty clear. Whether he violated your rules and how much you pay him I don't care.
  • blazespin 11y ago
    Especially in the infrastructure department. This is the huge story here.. putting all your creds on S3 in the open protected by one key?? Craziness.
    • meshko 11y ago
      why would private keys be on any system somehow accessible from the internet? gotta put all in the cloud?
    • lox 11y ago
      Yes, exactly this. Without escalating an RCE, how would he have been able to expose this absolutely huge flaw? The initial report was inconsequential, but this seems like at the very least a much more than $2500 bug. If things like this are considered "unethical" it kind of makes finding million dollar bugs in a bug bounty close to impossible.
      • joshuahutt 11y ago
        I agree. According to Stamos, though, there was no flaw: > The fact that AWS keys can be used to access S3 is expected behavior and would not be considered a security flaw in itself.
        • option_greek 11y ago
          If he thinks that is how it should be and nothing needs to be changed then god save their user data. He conveniently missed out the key separation and privilege escalation shown by the researcher.
• joshAg 11y ago
  I think the root cause of the problem is the unclear policy by FB. Privilege escalation can be hard to catch, and can be a separate bug in and of itself, even if it requires a separate exploit to get the initial privileges. The published policy didn't say anything about not doing what he did. I'm not going to argue that what he did should or shouldn't be ok, but FB has no control over what other people do. Yeah, maybe it'd be better if people asked for clarification first instead of asking forgiveness, but there's no way to force them to do that. FB does have control over what their policy says and allows/disallows. If you don't want people to exfiltrate any data and look at it on a local machine instead of just keeping a session on the exploited machine, then put that in the policy. If you don't want people poking around for other exploits after gaining access, then spell that out in the policy. The point of the policy isn't to stop everyone. Sure it will stop some/most people, but some people don't listen. The point is that when it happens again you can point to the clear policy and say "you're an asshole, we're not paying you because you violated our explicit policy, and we are reviewing what you did with our lawyers to see if we should notify law enforcement". Yes, doing this fix/policy update now doesn't fix this situation, but it prevents anyone else from doing something similar and claiming ignorance of this situation and FB's position.
  • btilly 11y ago
    I would have come here to say this if you had not said it already. A major root cause is that the published guidelines say nothing directly about exfiltrating sensitive data. This leads to legitimate confusion for exactly the reasons given. The actual policies make sense given what the published guidelines say, but that's not good enough. The policy needs to be changed. Not by much, but it needs changing. Here is a Responsible Disclosure Policy that might work better than your current one: We expect to have a reasonable time to respond to your report before making any information public, and not to be put at any unnecessary risk from your actions. Specifically you should avoid invading privacy, destroying data, interrupting or degrading services, and saving our operational data outside of our network. We will not involve law enforcement or bring any lawsuits against people who have followed these common sense rules.
  • pera 11y ago
    Usually serious security issues requires some kind of escalation, and escalation probably requires, at some point, exfiltration of (non personal) data. If the rules of the program are that restrictive I don't know how many serious bugs will be found by "ethical" hackers...
• Alupis 11y ago
  The bigger issue here, and the one that Alex at Facebook seems to gloss over - if Wes got this data using a 2 year old well known exploit -- then who else got it without anyone knowing? While Alex may have a right to be upset at Wes for taking data, Alex should recognize Wes is likely the least of his worries now. Wes wasn't/isn't a professional security researcher... and he was able to do this. That should frighten Alex, and Facebook should have been much more rewarding to Wes for forcing this issue to be taken care of.
  • eastonhockey19 11y ago
    "This bug has been fixed, the affected keys have been rotated, and we have no evidence that Wes or anybody else accessed any user data."
    • Alupis 11y ago
      Because of the sequence of events that played out...
      • eastonhockey19 11y ago
        Yes and he got paid for it.
        • Alupis 11y ago
          I'm not quite sure I understand your point? Of course he got paid, that's how bug bounties work... that doesn't detract in any way from the point I made above.
          • eastonhockey19 11y ago
            And I don't understand yours. You were concerned about other people other than Wes accessing the same data via the same flaw, Alex said that did not happen.
• Scarbutt 11y ago
  Imo you are just trying to cover up yourself poorly, you should accept the guilt of having had a server with a well known vulnerability that had the keys to the kingdom instead of blaming everything on Wes.
• mannykannot 11y ago
  With regard to to your final sentence: "Condoning researchers going well above and beyond what is necessary to find and fix critical issues would create a precedent that could be used by those aiming to violate the privacy of our users, and such behavior by legitimate security researchers puts the future of paid bug bounties at risk." Regardless of whether one thinks Weinberg's actions were ill-advised, there seems to be a general consensus that they were instrumental in the discovery of some very critical issues, and that you are lucky it was he who found them.
• gotothrowaway 11y ago
  This isn't all that complicated, as far as I can tell. Guy discloses a vulnerability. He knows it potentially has wide reaching security concerns, and downloads enough data to prove that if necessary. Guy gets shortchanged on the bounty, indicating that either a) facebook is trying to shortchange him, or b) facebook doesn't realize how big of a vulnerability this truly is Everything about Facebook's response indicates b): they didn't realize how big a vulnerability this truly was. Otherwise, the data he downloaded would have been useless by the time he used it. You can argue that the guy "went rogue" by hostaging information, but fact is he deserved to be paid more and he was able to prove it. Now facebook looks bad.
  • muteh 11y ago
    I'm not sure you understand how the law works
    • gotothrowaway 11y ago
      I'm not sure in this case, that's true. But whether or not this was illegal I generally support skirting laws if it makes everyone else more secure. To that end, I also support Snowden.
    • itsthecourier 11y ago
      laws aside, USD2500 for all that data? hmmm, is our data that cheap?
    • lox 11y ago
      I'm not sure anyone really understands how the law works when it comes to bug bounty programs and legal retaliation by companies. Is there any case law precedent yet?
      • ghayes 11y ago
        Especially when Facebook expressly authorizes this type of activity (to some degree). The relevant passage is cited in the original article.
• blazespin 11y ago
  According to the rules https://www.facebook.com/whitehat/ https://www.facebook.com/whitehat/ "We only pay individuals" Wes COULDN'T have been working for Synack to find bugs as your program doesn't even allow for it.
  • grahamannett 11y ago
    And according to the update on the post, Alex chose to contact his 'company' (that he had contracted for) even though he had not contacted them through the company email (meaning he sought out a way to go about intimidating Wes). Seem's incredibly petty and intimidating of Alex and reflects poorly on Facebook imo.
• funkyy 11y ago
  Alex, I am always in to hearing from both sides. But despite your reply, I see wrong doings on both sides unfortunately. I dont think you have discussed this message with public relations dept or rep management one. OK, so lets look at this - your response showed us one extremaly important issue. No clear rules in your system. Wes actually by exploiting your system, exploited your lack of rules regarding the handling of white hat hackers. Listen, hacker should exploit ALL possible issues. He exploited your weakest one - the rules behind the system. Close the case - reward him XX,XXX for exploiting weakness in your policy for dealing with white hat hackers, spend another as much to bulletproof your policy. Do not reward him for hacks, that are unethical, as it would be wrong, but do it for the other exposure - small dent on your white hat hacker system.
• purpleidea 11y ago
  Shame on you for contacting his employer directly. This teaches a good lesson to all the black, grey and white hats out there. Next time they'll know to just p0wn to 0wn.
• deleted 11y ago
  [deleted]
• ryanackley 11y ago
  At this point, it was reasonable to believe that Wes was operating on behalf of Synack. Huh? how did you make this connection? Why would he then report his findings to you? From my point of view, contacting his employer was clearly meant as a gut punch.
  • mdholloway 11y ago
    This section was 100% written by a lawyer, and is intended to sound obvious without in fact being obvious at all.
• nl 11y ago
  I told Jay that we couldn't allow Wes to set a precedent that anybody can exfiltrate unnecessary amounts of data and call it a part of legitimate bug research, and that I wanted to keep this out of the hands of the lawyers on both sides. I did not threaten legal action against Synack or Wes.... In case it isn't clear, most people will interpret "I want to keep this out of the hands of lawyers" exactly as a threat to start legal action. To be honest I'm not really sure how else it should be interpreted?
  • pkinsky 11y ago
    "I want to keep this out of the hands of lawyers" is almost universally understood to mean "please do what I say so that I don't have to sue you, which is what I will do if you do not comply".
    • xp_cmdshell 11y ago
      Maybe someday the response to this sort of threat will be "In the interests of sharing, I already passed on this information to your favorite class action law firm and the media. It's already in the hands of lawyers and your company is already being sued."
  • deleted 11y ago
    [deleted]
• fbsucks 11y ago
  just pay the man, you guys got billions of dollars. honestly, I've lost all respect I had for you.
• pera 11y ago
  > The fact that AWS keys can be used to access S3 is expected behavior and would not be considered a security flaw in itself. A security "mistake" then? :)
• itslennysfault 11y ago
  Yea, wouldn't want to "set a precedent" that infosec researchers will be rewarded for doing the right thing. Next time someone uncovers your private keys at least they'll know upfront that there is no money in doing the right thing which might just make selling them to the highest bidder seem like a more compelling option.
• mabbo 11y ago
  Bug bounties are supposed to represent a high probability payoff of a lesser amount of money for finding a bug. This is in comparison to going the black hat sales root, where probability of sale might be lower, but the payoff might be higher. I can imagine one or two state actors who might pay top dollar to have keys to the kingdom to a major social network. All I'll remember of this entire story is the outcome- huge vulnerability found (high black market value), and Facebook is talking about lawyers and paying small bounties. Nobody will remember that technically he broke a rule that wasn't well explained. The next Wes will have his major vulnerability in hand, and have this story in his mind. It may change his decisions. Make this right. Even if you are in the right who cares? You need the perception of your program to be impeccable, paying more than researchers expect. Facebook can afford it more than they can afford to blemish the image of their big bounty. Invite Wes to help you rewrite the confusing parts of the rules. Leave that story in everyone's memories instead.
• vlamanna 11y ago
  I'm not really impressed by your reaction...
• mavdi 11y ago
  No excuses for contacting his employer though. Just plain intimidation.
• jtwebman 11y ago
  What he did do is expose that you guys don't know how to use aws and S3. Those keys should have never been on a server in the first place. I think it would have been in your best interest to fix it and pay him. Now that other hackers know Instagram sucks at server management it is only time before someone finds another key. Guess what they are not going to do? They are not going to report it but download and sell your info.
• lawnchair_larry 11y ago
  Sorry Alex, you're in the wrong here. Your threats to go to law enforcement completely undermine the credibility of your bug bounty program. Your publicly calling another professional "unethical" is a serious charge for what is a grey area at best, and the facts and history of issues reported by this person would not lead a reasonable person to conclude malice. And ignoring him but going to his boss, that's just petty. Not even one attempt to talk to the guy like an adult about what he was doing? You couldn't even be bothered to say anything? You'd be amazed how a polite reply to the effect of, "thanks, you've proven your point, and we are getting a little uncomfortable with where this is headed" might have solved all of this. If he ignored you and kept hacking after that, by all means steamroll him, but if you don't even have that much respect for your peers, I'm not sure why you bother with the bounty program.
  • mkagenius 11y ago
    CXOs do not talk directly to anyone other than CXOs right?
  • zamalek 11y ago
    Agreed. You've have quite a list of arguments defending the researcher when only his track record should have been enough to prove his good will. Despite the landslide of evidence of good will, Facebook decided to act in bad faith. Unacceptable, I hope other researchers read and remember this story.
• Fordrus 11y ago
  This response deepens my concern about the situation, rather than alleviating it. In this response, you make it sound like calling this security researcher's employer's CEO was a reasonable escalation of the situation, and that is deeply concerning to me, especially given the actual text of the post Wes published here. It also appears, based on your post, that you think that stating, approximately, "I hope we don't need to contact our legal teams or law enforcement about this," does not constitute a threat of legal or law-enforcement action, and I also find that deeply troubling. While I think you could make a legal distinction that these weren't technically threats of such action, any reasonable person in the researcher's position would by positively idiotic if he/she failed to feel threatened in that way by such statements.
• downandout 11y ago
  There is a definite issue with the Facebook bug bounty program in that there are many serious issues with the platform that don't fit within the relatively narrow parameters of the program. I reported an issue that enabled anyone to customize a wall post that says it goes to any site of my choosing in the post (cnn.com, whitehouse.gov, etc), completely customize both the content and photo of the post, and have the link actually go to a URL of my choosing instead of the domain it shows in the post. Examples at [1] and [2]. This issue, which enables uber-credible phishing and other attacks with the assistance of Facebook (since Facebook falsely reports to the user that the link goes to a credible domain of the attacker's choosing while actually sending them to any URL controlled by the attacker), was rejected. Not only was I told that it was not a bug that I could be paid for, but that it really wasn't a bug at all, and that they would do nothing about it. If these kinds of serious issues are essentially ignored because they don't meet the very narrow guidelines set forth in the bug bounty program, Facebook is going to miss a massive number of problems with its platform. [1] http://prntscr.com/9fj40t http://prntscr.com/9fj40t [2] http://prntscr.com/9fj46h http://prntscr.com/9fj46h
• deleted 11y ago
  [deleted]
• msravi 11y ago
  Ok, so here's the thing. Your $2500 payout was not commensurate with the severity of the bug. It ought to have been more. A LOT more. You're basically telling bounty hunters to not go any further to "prove" the severity of the bug because you're saying, "Trust us. We'll measure the maximum impact and reward you fairly" And yet, you're not being fair at all. So the bounty hunter needs to "prove" the severity of the bug for you. You're digging your own grave here by not acting in good faith. The next guy who finds a good bug is not going to disclose it to you - he's going to sell it on the black market for a few hundreds of thousands. Or millions.
• mback00 11y ago
  Um... Have to side with Wes here. Your rules were not nearly adequate, and instead of going at Wes directly with adequate and in-depth communication, the CSO went after his employer - which is _not_ ethical.
• ctvo 11y ago
  I hope someone calls your CEO and talks to him about your conduct.
• Artoemius 11y ago
  Sorry, but it looks like your technical issue has become a PR issue. Contacting his employer was an act of intimidation, and no amount of cover-up will make up for it.
• shawn-butler 11y ago
  "I did say that Wes's behavior reflected poorly on him and on Synack, and that it was in our common best interests to focus on the legitimate RCE report and not the unnecessary pivot into S3 and downloading of data." You lost me at this point. Who do you think you are really?
  • Mandatum 11y ago
    He must be pretty delusional if he thinks that's an OK thing to write on a blog. If I was him I'd deny, deny, deny or try and make it seem a whole lot less sinister than it is.
• mbrameld 11y ago
  > The fact that AWS keys can be used to access S3 is expected behavior and would not be considered a security flaw in itself. Isn't it a security flaw that a single AWS key was able to access all of Instagram's data?
• Dr_tldr 11y ago
  Let's take a step back here: Facebook threatened to have a security analyst arrested for demonstrating and promptly disclosing the full extent of a serious exploit in a non-destructive manner. Whatever other behavior he engaged in that was unnecessary or ineligible for the bug bounty program, that's incredibly unethical on your part. Especially so, because you clearly didn't believe he was going to do any damage to your system or you would've actually called the FBI instead of someone he worked with. So, you just wanted to cause him reputational damage and personal problems as an act of petty retaliation. You're right on some of the technical issues here, but in terms of ethics, your behavior has been far worse than his. I don't think you realize how much long-term damage you're doing to your relationship with the wider security community by threatening to jail people who were at no point acting maliciously and at no point caused any damage.
• deleted 11y ago
  [deleted]
• deadowl 11y ago
  You talk about ethics like it is an entirely black and white concept. I would consider a lot of Facebook's practices unethical in comparison to my own set of ethics. There are ethical dilemmas, which are basically what most discussion about ethics is about to begin with. You use the word unethical but without discussing ethical dilemmas, and that makes your argument weak even though you potentially have a very strong argument.
• deleted 11y ago
  [deleted]
• JonoBB 11y ago
  If the intention of a bug bounty program is for white hat disclosure, you have done pretty much everything you can for vulnerabilities to be dealt with a black hat manner. Well done.
• klzns 11y ago
  8
• rev_null 11y ago
  Couldn't it be argued that instagram's choice to store private keys in a third party system (amazon) is a million(s?) dollar bug?
• c2h5oh 11y ago
  Quite frankly I'm not surprised Wes is sour about how this was handled and the amount granted as bounty. It's very rare for a single vulnerability to grant you keys to the kingdom. If you check pwn2own vast majority of the hacks leverage more than one. Most major attacks start with a small bug. The real severity of the vulnerability is how far can it be pushed to broaden the scope. In this case that admin panel was just an entry point to a whole chain of security SNAFUs (aws keys in files at a multi-billion-dollar internet company, seriously?). To reiterate, he got access to: - source code - aws keys - plethora of 3rd party platform keys - a bunch of private keys - user data This might not be the million dollar bug, but close. Just thing about what an actual attacker could have done with it: - login as / impersonate ANY instagram account - impersonate whole instagram (code + ssl keys!) - inject malware into instagram app and sign it with your keys - download tons of user data - wreck havoc in aws (possibly expanding what he has access to - we don't know what else he would have been able to access had he spent weeks not hours exploring). This is not a missing permission check allowing you to delete other peoples photos. This is huge and based of that credit and significantly higher bounty is due. Aside from that the handling of the whole matter was not good: - if your policy is not precise interpret it to your disadvantage. you screwed up not making it clear - contacting his boss should only happen (if at all) after he has been asked the same account - the post about "bug bounty ethics" misses the point. Following your logic heartbleed investigation should have ended when someone discovered a buffer over-read without exploring where that leads.
• yegortimoshenko 11y ago
  > At no time did we say that Wes could not write up the bug, which is less critical than several other public reports that we have rewarded and celebrated. There is no bug more critical than one that results in complete access to Instagram infrastructure. Sure, the bug is stupid, but you are fooling yourself.
• anupj 11y ago
  Going to his employer, instead of talking to him direct was just petty.