Slashdot Mirror

← Back to Stories (view on slashdot.org)

Facebook, Researcher Spar Over Instagram Flaw Disclosure (exfiltrated.com)

Posted by samzenpus on from the can't-we-all-just-get-along? dept.

msm1267 writes: A security researcher is in a bit of a scrum with Facebook over vulnerability disclosures that not only tested the boundaries of the social network's bug bounty program, but he said, also prompted hints of legal and criminal action, which Facebook has since denied. Wesley Wineberg, a contract employee of security company Synack, said today that he had found some weaknesses in the Instagram infrastructure that allowed him to access source code for recent versions of Instagram, SSL certificates and private keys for Instagram.com, keys used to sign authentication cookies, email server credentials, and keys for more than a half-dozen critical other functions, including iOS and Android app signing keys and iOS push notification keys. Wineberg also accessed employee accounts and passwords, some of which he cracked, and had access to Amazon buckets storing user images and other data prompting claims of user privacy violations from Facebook.

31 comments

  1. They're all the same by Anonymous Coward · · Score: 0

    We complain about companies that leave their source code, signing keys, private keys and so on in some publicly accessible server, but then Facebook does exactly the same, when it should know better.

    Companies are all the same, it seems.

    1. Re:They're all the same by Anonymous Coward · · Score: 0

      Companies are all the same, it seems.

      Way to start this off with a totally inane comment!

  2. Compromise by penguinoid · · Score: 2

    Post the full details, everything, on your Facebook account. That way if they don't like it they can just delete it.

    --
    Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
  3. That's not a weakness. by Anonymous Coward · · Score: 0

    That's a fucking disaster. Over half that shit should be compartmentalized.

    IT security is amateur hour almost everywhere.

  4. When the CSO is involved it is a coverup. by EmperorOfCanada · · Score: 4, Interesting

    One of the problems with bug bounties is information control. I am not talking about the bugs leaking out or making the company look bad so much as the information is then clear for the higher ups in the company to see what bugs the outside world is discovering. Thus those in charge of security look at bug bounties as career damaging information they can't control. I am willing to guess that many submissions are made to bug bounty gathering organizations that are complete crap. People no doubt write in vague things such as "You are using the Monkey BM operating system which is known to have many flaws. You can send the cheque to ..." Thus it is probably easy for the CSO to take a genuine flaw and file it under the category "spurious". The worse the flaw, and the more clear the evidence as to how damming it is no doubt are the ones that they want to make go away the fastest. The CSO probably is used to being Tyrannical to his own employees and many other employees of the company. Can you imagine if he called your boss within the company and indicated that you were presenting a threat to the company?

    So when he pulled this shit and called up a company out of the blue he probably thought his reign of terror would apply there too.

    So if I were his boss I would not only look into this one case but I would look to see how many other cases he suppressed. Then, I would carefully look into his behaviour in the office. I would suggest that they hire an outside company that can do anonymous surveying of his immediate underlings and others that he has dealt with to see if he is a bully. I would also look into any firings that he was involved with; especially if they were outside his direct purview. Did he have some guy escorted out of the building because he wanted his parking space?

    1. Re:When the CSO is involved it is a coverup. by Anonymous Coward · · Score: 0

      This. If it was half as clean-cut a case as the article and Facebook want to make it sound there is no way in the entirety of the universe the CSO "Doesn't want to involve lawyers on either side" unless he's even more culpable than the 'hacker'.

      What about if he had a chunk of data not publicly disclosed hidden away for insurance and blackmail? Then calling the guys boss to bitch about him would the worst possible course of action.

  5. Facebook's statement by cerberusss · · Score: 1

    Facebook’s statement:

    “We are strong advocates of the security researcher community and have built positive relationships with thousands of people through our bug bounty program. These interactions must include trust, however, and that includes reporting the details of bugs that are found and not using them to access private information in an unauthorized manner"

    They forgot to end that with "...because we're the only ones that are allowed to do that, while shoveling truckloads of money into our bank accounts".

    --
    8 of 13 people found this answer helpful. Did you?
    1. Re:Facebook's statement by Anonymous Coward · · Score: 5, Insightful

      Facebook isn't wrong though. There isn't a single white-hat penetration tester out there who will say its ok to access systems you aren't given permission to access, even if its in the act of discovering vulnerabilities that you intend to disclose. He found a vulnerability in their system and instead of reporting it immediately he decided to see how deep that particular rabbit hole went. He used credentials that did not belong to him to access systems he did not have permission to access, a direct violation of many countries' laws (including the US where those servers are housed). This "security researcher" did way more than discover and disclose a vulnerability, he also took advantage of that vulnerability without permission from facebook, in direct violation of most countries' laws. If I was facebook I wouldn't just not pay the guy, I would consider legal action as well. It should not be acceptable to be able to hack into someone's servers if only you report it to them later. Who knows if this individual "security researcher" or his company might have decided to keep some of those private certs and credentials around for future use. Just because this one might not have doesn't mean the next one wouldn't. This behavior is unacceptable from a supposed "security researcher", especially since he should know better.

    2. Re:Facebook's statement by Cederic · · Score: 2

      Yeah, it's weird that he's pissed off with them after he's the one that broke multiple laws.

      Whether they're incompetent fuckwits exploiting two billion people is totally irrelevant, he still broke the law and shouldn't be surprised if legal action follows.

      If he's lucky it'll only be civil action.

    3. Re:Facebook's statement by stephanruby · · Score: 1

      Who knows if this individual "security researcher" or his company might have decided to keep some of those private certs and credentials around for future use.

      Actually, if there is a chance he has a copy of the signing keys, some of which can not be changed, Facebook should just pay the bounty, and consider itself lucky that the security researcher doesn't consider himself a criminal.

      Facebook should take a page out of the US anti-nuclear proliferation playbook. If a country is trying to get the nuke. You punish it. You bomb it back to the dark ages. On the other hand, once a country already has a new working nuke (especially more than one). You put on a show for the rest of the world about punishing that country, but ultimately, you stop any serious punishment very quickly and you befriend the country in question.

    4. Re:Facebook's statement by Anonymous Coward · · Score: 0

      Honestly what did he expect? Puppies and rainbows galore after telling them that he had the keys to the kingdom in his grasp?

    5. Re: Facebook's statement by bill_mcgonigle · · Score: 4, Insightful

      > There isn't a single white-hat penetration tester out there who will say its ok to access systems you aren't given permission to access, even if its in the act of discovering vulnerabilities that you intend to disclose.

      If you're not hired by FB but are probing their systems to look for vulnerabilities as their bounty system encourages, you cannot meet the criterion you outline.

      The goal apparently needs to be more clear: if FB's goal is to find as many problems as possible then stopping at the first problem and closing that door does not achieve the goal.

      Unless we hear that he sold the info to a third party, it looks like there's no victim here and FB looks bad for overreacting when it got caught with its pants down (wait ... Instagram, not Snapchat).

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re: Facebook's statement by Anonymous Coward · · Score: 0

      This is why the bug bounty programs are basically big ass honey pots.

      This guy found a huge flaw and now he's a criminal. He didn't do anything malicious. He just snooped around to see how deep the exploit went and scraped up some info to have proof. What white hat wouldn't have done the same. I know I would have. It's our jobs to pen test and see how far we can take it, as long as no one is injured and the equipment isn't maliciously tampered with. And yet he's crucified for this. Fuck Facebook and fuck bug bounty programs. Sell them on the black market for way more $$$. That must be what they want.

    7. Re: Facebook's statement by Cederic · · Score: 1

      It's our jobs to pen test and see how far we can take it, as long as no one is injured and the equipment isn't maliciously tampered with.

      It's not your job to break the law. Maliciously tampering is a very subjective interpretation, and thinking you can merrily compromise someone else's system tells me your judgement is sadly lacking.

      Sell them on the black market for way more $$$. That must be what they want.

      Or maybe they want responsible disclosure without exploitation. Is that possible?

  6. Warning, do not try at home by phantomfive · · Score: 3, Informative

    access source code for recent versions of Instagram, SSL certificates and private keys for Instagram.com, keys used to sign authentication cookies, email server credentials, and keys for more than a half-dozen critical other functions, including iOS and Android app signing keys and iOS push notification keys. Wineberg also accessed employee accounts and passwords, some of which he cracked

    Warning: if you are going do security research, don't access all that stuff (without permission from the company), it can be completely illegal.
    People have literally gone to jail for accessing less than this guy did. Whether you think it should be illegal or not, it is illegal and you should be more careful than he was.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:Warning, do not try at home by Xest · · Score: 2

      Yeah, as much as I hate to defend Facebook here, I fail to see how Facebook is in the wrong here, it's clear the guy didn't just find an exploit, but used it to scour into the deepest depths of Facebooks network and to exfiltrate the most sensitive of data.

      That's not security research uncovering a vulnerability, that's outright hacking in to Instagram and then saying "Oh I was just doing you a favour" after the fact.

      When you find an exploit you report it, if instead you delve into the system and start to not only exfiltrate sensitive data, but start breaking the encryption on it too, then you're going beyond mere discovery into a fully fledged attack, and as you say, for that to be legal it requires actual permission.

      The security "researcher" in this article is genuinely the bad guy here, he's broken just about every rule in the book of ethical security research.

      There's no reason to crack the passwords. Knowing that the encryption used is crackable is sufficient enough for a report, just as knowing that Amazon bucket access info is sufficient enough for a report without needing to delve into them and copy private data from them onto your own computer.

    2. Re:Warning, do not try at home by Anonymous Coward · · Score: 0

      Did he find it and notify fb? Is yes and they did nothing after being warned. Then the guy went and proved it works. Then fb is in the wrong.

    3. Re:Warning, do not try at home by Xest · · Score: 2

      No they're not, if someone leaves their car door unlocked, and you tell them, and they still don't lock it, it doesn't give you the right to go for a joyride, break a few speed limits, and run a few people over. No matter what the circumstances, it's pretty clear this guy broke numerous laws regardless of how inept Facebook were.

      The best you can do if someone doesn't act when you alert them is to go public, and hope that scares them into taking the issue a bit more seriously.

    4. Re:Warning, do not try at home by Anonymous Coward · · Score: 0

      Isn't FB publicly advertising a bounty for ways to break into their system effectively giving everyone permission to break into their system and then tell FB how they did it?

    5. Re:Warning, do not try at home by Anonymous Coward · · Score: 0

      But their bug bounty program encourages it!

  7. Signed authentication cookies by phantomfive · · Score: 1

    Does signing an authentication cookie actually accomplish anything? Couldn't the cookie just be copied byte-for-byte and used as is? What is the point of signing it?

    --
    "First they came for the slanderers and i said nothing."
    1. Re:Signed authentication cookies by Anonymous Coward · · Score: 0

      Nobody other than one who has the private key can sign the key, that way you know the cookie came from the person holding the private key.
        - Also you cannot modify the cookie and impersonate users and you cannot sign the new key
        - When cookie goes back with the HTTP request the server can make sure that the cookie was indeed created by the server

    2. Re:Signed authentication cookies by Anonymous Coward · · Score: 0

      Usually the authentication cookie includes the user name and expiry date and sometimes other information about the client (browser used, ip...). This information is then hashed and signed. You can copy the cookie byte-by-byte, but will only be valid for the same user during the validity. If you have the key, you can generate cookies for every user and expiry date.

    3. Re:Signed authentication cookies by Anonymous Coward · · Score: 0

      Does signing an authentication cookie actually accomplish anything?

      Traditionally, the user authenticates, and then the server hands them a cookie, which is stored in a server side session. Subsequent requests then include that cookie, so the server can match it against the session cookie, and determine what the user has access to.

      When you have lots of servers, like Facebook do, you'd need to replicate the session over all those servers. While possible, on a huge scale this is technically difficult.

      My guess is that FB chose a more stateless solution, where they give the user a signed cookie saying "you are confirmed user X". Then instead of matching it with a stored server side cookie, they can just verify the signature on any server.

      The drawback of course would be that if anyone gets hold of the signing key, they could impersonate any user session.

    4. Re:Signed authentication cookies by DarkOx · · Score: 1

      Older versions of rails deserialized cookies to a Ruby object. That is an RCE if you make a complex object. The expectation of the web application is the cookie would ddeserialize to Hash or similar object. Well if you create an object that defines some of the methods commonly used on Hashes like [], select, each etc you will be able to put whatever you want there and get it called. The security Rails had in place on that was to check the signature. If the signature was valid than the browser faithfully regurgitated the cookie as sent by the application and the information was safe to use to construct an object for use in processing the next request. If the signature was not valid than the application knew the cookie should be discard. If an attacker discovers the secrets needed to sign the cookie than (s)he can tamper with them undetected and get remote code execution.

      If I were doing a test of an application for an organization I did not have a defined client relationship and I saw something like this (I actually have done this) I would generally have injected something like `nslookup somewildlonguniquestring@mydomian.com` and watched DNS server to see if it gets such a request. Other variants like `ping myhost.mydomian.com1` or using curl or Ruby's httpclient to make some web requests that I could watch logs for would also be candidates. One of the challenges with a blind RCE is you don't know what will work on the remote system. Which is why when you have a defined relationship you usually go directly to your reverse-shell type payloads. In the case of bug bounties that isn't a good idea though. The web server should log requests hopefully even things like cookies, so if you don't go shell it should be EASY for forensics to confirm you did what you said you did and no more. As so as you invoke a shell or something now its a lot harder in most cases to be able to proved EXACTLY what you did or did not do.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    5. Re:Signed authentication cookies by phantomfive · · Score: 1

      If I were doing a test of an application for an organization I did not have a defined client relationship and I saw something like this (I actually have done this) I would generally have injected something like `nslookup somewildlonguniquestring@mydomian.com` and watched DNS server to see if it gets such a request....... The web server should log requests hopefully even things like cookies, so if you don't go shell it should be EASY for forensics to confirm you did what you said you did and no more.

      That's a good idea.

      --
      "First they came for the slanderers and i said nothing."
  8. scrum by Anonymous Coward · · Score: 1

    Please don't use the word 'scrum', it conjures up images of project managers and developers furiously masturbating over epics and user stories.

    1. Re:scrum by Anonymous Coward · · Score: 0

      :fapfapfap:... I'm .... sprin... I'm gonna.... I'm sprinnnnnnnnnnnnnnnnnnnnnnnnting.

      Brb guys, going to go vape in the company parking lot. (Yes, I was sprinting at my desk)

  9. how would they know about these vulnerabilities by Anonymous Coward · · Score: 0

    unless someone actually tries to find them? why have these programs if you don't want people to try to find these problems in the first place? they should be happy he told them about it instead of selling the information to the highest bidder. it's like saying anyone who can break this security gets a cash reward.... but when it's done they instead get a criminal charge