7 ms·

Finding a vulnerability is one thing. Using it is another. This person overstepped pretty severely and I'm not shocked at all that they got fired. And honestly

Finding a vulnerability is one thing. Using it is another. This person overstepped pretty severely and I'm not shocked at all that they got fired. And honestly, writing this post at all continues to show bad judgment. I don't think this person understands where white-hat boundaries are, or how to deal with being accused of a crime. Please reconsider if you think doing something like this to your competitors - or anyone - without some kind of program of consent on their part (like the previously mentioned Project Zero) is a good idea.

paxys 5y ago
How did he "use" the vulnerability? What did he do that qualified as overstepping? He literally logged into a website and made requests to a hidden endpoint with random IDs. When he realized he was looking at production user info he stopped and reported it to higher ups. The process he has described is right out of the white hat guidebook. What would you have done differently?
- jorgesborges 5y ago
  He didn’t exactly stop. He could have quit poking around once alarm bells started ringing but he wanted to see how bad it got so he continued to poke around. Knowing when to stop should probably be a white-hat quality.
  - tptacek 5y ago
    This happens a lot! It's gotten people in trouble even in situations like bug bounty programs, where some amount of testing is authorized --- there's a delicate set of norms about stopping your exploration when you find a problem. In a situation where there's no prior authorization --- as is likely the case here --- violating whatever implicit norms exist can easily get you in legal trouble. At the very least, if you stumble across something that spits out a plaintext credit card number, stop right there and don't do another damn thing with the target. Don't see which credit card numbers you can see, don't change the `/100` in your URL to `/101`, just stop.
    - borski 5y ago
      ...and report it, apologizing for going too far in the first place but explaining how you got there and that you want to cooperate in any way to help them fix it. And please, don't tell them you'll give them the bug if they pay you or give you a t-shirt - this is blackmail, most likely (IANAL), and sure to get you in trouble. (but it happens)
    - aaaaaaaaata 5y ago
      Oh, the URL change...so many drug test results.
    - ballenf 5y ago
      The crazy thing is how unintuitive the law is here. If we were calling customer support and asked "can you tell the card number of [John Doe/customer 314/etc]" without ever claiming to be that person, wouldn't we put 100% of the blame on the company for answering that question? (If the caller there used the number, that'd be a different story.) Most devs outside security would just assume that unless you're doing something encryption-related or at least trying multiple passwords, you're not hacking. You're just asking nicely for information. It is amazing how little technical knowledge you need to violate the CFAA.
  - tedk-42 5y ago
    Poking around is exactly how you determine how severe the vulnerability is. Simple data extraction is hardly a outside the what a white hat hacker should do. If there's an API endpoint that returns say, `user.name`, it's reasonable to try other things like `user.email` or `user.credit-card` to see what else could be do BEFORE reporting it. It might be totally valid to return `user.name` where `name` is simply the first name. But you'd never know unless you actually tried a few more endpoints. I agree with a parent comment in that someone dropped the ball here and threw him under the bus to protect reputations and prevent any nastiness between the two companies.
    - tptacek 5y ago
      No. Simple data extraction is what a contracted penetration tester does, because they secured (here's that word again) a contract that limits their liability when doing simple data extraction. Poking around to find out how severe a vulnerability might be is how you manage to get yourself in civil trouble even when you're testing a site that runs a bug bounty; god help you if you're doing it on a site that doesn't have one, or, worse, hasn't really ever heard of one. People share a lot of really bad advice about security research. The best advice you'll get from people that don't work in the field is "stay away" and "don't try to help"; it's cynical, but at least it's not going to get you sued, like following this kind of "poking around is a white hat norm" advice will.
      - paxys 5y ago
        You can get into legal trouble simply by looking at the source code of a web page you are browsing, as has happened in several famous recent cases. However, the take away from that isn't "if you go into Chrome developer tools you totally had it coming". There are bounds to what is or should be considered reasonable testing, and if you don't press against them then they will keep moving closer and closer to the point where simply using your own computer in ways the manufacturer didn't intend will be illegal (and that is already happening as well). According to what the author describes he did absolutely nothing wrong morally or legally, and the attitude of victim blaming prevalent in this thread is a huge problem in the security industry. We should be supporting rather than crucifying him, because one of us will surely be next for looking at a website the wrong way.
  - cbozeman 5y ago
    > Knowing when to stop should probably be a white-hat quality. You don't stop until you fully explore just how severe the vulnerability is and all affected systems. This isn't rocket science. You have to know just how bad things are if you to have any hope of fixing them.
    - bongothrowaway 5y ago
      Isn't that the job of the person who is responsible for the code, and NOT the responsibility of a well-wishing outsider who stumbled across the bug in the first place? Unless you're actually angling to get the job of fixing the code.
- stjohnswarts 5y ago
  Better to reveal such things anonymously over tor or something similar.
deleted 5y ago
[deleted]
bradly 5y ago
> I don't think this person understands where white-hat boundaries are Not that ignorance of the law is an excuse, but when are software developers not in infosec supposed to be taught these limits?
- tptacek 5y ago
  Here you go: https://clinic.cyber.harvard.edu/files/2020/10/Security_Researchers_Guide-2.pdf https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese...
  - bradly 5y ago
    Thank you for the link, but is it something you expect all non-infosec engineers to know?
    - tptacek 5y ago
      I think the subtext of CFAA is that the law believes it shouldn't have to tell you not to try to pry credit cards out of someone else's website. I'm not speaking normatively, I'm just telling you the way it is. I think publicized security research --- which I obviously support --- has created expectations among technologists that either weren't intended, or were more wishful than the facts support (lots of researchers, most probably, think the CFAA is a bad law and are happy to set expectations premised on its illegitimacy, but: see Wesley Snipes for how that turns out). If there weren't lots of public security research, I don't think you'd really have to tell developers not to go looking for vulnerabilities. Again, and to be clear: if it's something running on your own machine, or a machine you own, go nuts.
      - borski 5y ago
        This is an important caveat; the issue at hand is looking for vulnerabilities on other people's machines, not in other people's software. If it is running on your machine (read: not SaaS), reverse away. Releasing the exploit, on the other hand, is a different story (don't do that)
dgb23 5y ago
I agree in a practical sense. But I think there is a huge social problem here. Power relations between employers and employees, corporate goons (lawyers), lack of honest communication, lack of trust, lack of collaboration to make things better, general FUD. This all leads massive inefficiencies, people get hurt, progress is slowed down or even reverted.
crispyambulance 5y ago
> I don't think this person understands where white-hat boundaries are, or how to deal with being accused of a crime. OK but where, exactly, ARE "white-hat" boundaries? Is there a rule-book somewhere that he missed? How does one know how to deal with being accused of a crime? Practice? Cop-shows on TV? IMHO this person is someone who was just too naïve, overly trusting and unlucky. If there's blame here, much of it falls on his organization for failing to handle the initial incident report seriously.

paxys 5y ago

How did he "use" the vulnerability? What did he do that qualified as overstepping? He literally logged into a website and made requests to a hidden endpoint with random IDs. When he realized he was looking at production user info he stopped and reported it to higher ups. The process he has described is right out of the white hat guidebook. What would you have done differently?

jorgesborges 5y ago
He didn’t exactly stop. He could have quit poking around once alarm bells started ringing but he wanted to see how bad it got so he continued to poke around. Knowing when to stop should probably be a white-hat quality.
- tptacek 5y ago
  This happens a lot! It's gotten people in trouble even in situations like bug bounty programs, where some amount of testing is authorized --- there's a delicate set of norms about stopping your exploration when you find a problem. In a situation where there's no prior authorization --- as is likely the case here --- violating whatever implicit norms exist can easily get you in legal trouble. At the very least, if you stumble across something that spits out a plaintext credit card number, stop right there and don't do another damn thing with the target. Don't see which credit card numbers you can see, don't change the `/100` in your URL to `/101`, just stop.
  - borski 5y ago
    ...and report it, apologizing for going too far in the first place but explaining how you got there and that you want to cooperate in any way to help them fix it. And please, don't tell them you'll give them the bug if they pay you or give you a t-shirt - this is blackmail, most likely (IANAL), and sure to get you in trouble. (but it happens)
  - aaaaaaaaata 5y ago
    Oh, the URL change...so many drug test results.
  - ballenf 5y ago
    The crazy thing is how unintuitive the law is here. If we were calling customer support and asked "can you tell the card number of [John Doe/customer 314/etc]" without ever claiming to be that person, wouldn't we put 100% of the blame on the company for answering that question? (If the caller there used the number, that'd be a different story.) Most devs outside security would just assume that unless you're doing something encryption-related or at least trying multiple passwords, you're not hacking. You're just asking nicely for information. It is amazing how little technical knowledge you need to violate the CFAA.
- tedk-42 5y ago
  Poking around is exactly how you determine how severe the vulnerability is. Simple data extraction is hardly a outside the what a white hat hacker should do. If there's an API endpoint that returns say, `user.name`, it's reasonable to try other things like `user.email` or `user.credit-card` to see what else could be do BEFORE reporting it. It might be totally valid to return `user.name` where `name` is simply the first name. But you'd never know unless you actually tried a few more endpoints. I agree with a parent comment in that someone dropped the ball here and threw him under the bus to protect reputations and prevent any nastiness between the two companies.
  - tptacek 5y ago
    No. Simple data extraction is what a contracted penetration tester does, because they secured (here's that word again) a contract that limits their liability when doing simple data extraction. Poking around to find out how severe a vulnerability might be is how you manage to get yourself in civil trouble even when you're testing a site that runs a bug bounty; god help you if you're doing it on a site that doesn't have one, or, worse, hasn't really ever heard of one. People share a lot of really bad advice about security research. The best advice you'll get from people that don't work in the field is "stay away" and "don't try to help"; it's cynical, but at least it's not going to get you sued, like following this kind of "poking around is a white hat norm" advice will.
    - paxys 5y ago
      You can get into legal trouble simply by looking at the source code of a web page you are browsing, as has happened in several famous recent cases. However, the take away from that isn't "if you go into Chrome developer tools you totally had it coming". There are bounds to what is or should be considered reasonable testing, and if you don't press against them then they will keep moving closer and closer to the point where simply using your own computer in ways the manufacturer didn't intend will be illegal (and that is already happening as well). According to what the author describes he did absolutely nothing wrong morally or legally, and the attitude of victim blaming prevalent in this thread is a huge problem in the security industry. We should be supporting rather than crucifying him, because one of us will surely be next for looking at a website the wrong way.
- cbozeman 5y ago
  > Knowing when to stop should probably be a white-hat quality. You don't stop until you fully explore just how severe the vulnerability is and all affected systems. This isn't rocket science. You have to know just how bad things are if you to have any hope of fixing them.
  - bongothrowaway 5y ago
    Isn't that the job of the person who is responsible for the code, and NOT the responsibility of a well-wishing outsider who stumbled across the bug in the first place? Unless you're actually angling to get the job of fixing the code.
stjohnswarts 5y ago
Better to reveal such things anonymously over tor or something similar.

deleted 5y ago

[deleted]

bradly 5y ago

> I don't think this person understands where white-hat boundaries are Not that ignorance of the law is an excuse, but when are software developers not in infosec supposed to be taught these limits?

tptacek 5y ago
Here you go: https://clinic.cyber.harvard.edu/files/2020/10/Security_Researchers_Guide-2.pdf https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese...
- bradly 5y ago
  Thank you for the link, but is it something you expect all non-infosec engineers to know?
  - tptacek 5y ago
    I think the subtext of CFAA is that the law believes it shouldn't have to tell you not to try to pry credit cards out of someone else's website. I'm not speaking normatively, I'm just telling you the way it is. I think publicized security research --- which I obviously support --- has created expectations among technologists that either weren't intended, or were more wishful than the facts support (lots of researchers, most probably, think the CFAA is a bad law and are happy to set expectations premised on its illegitimacy, but: see Wesley Snipes for how that turns out). If there weren't lots of public security research, I don't think you'd really have to tell developers not to go looking for vulnerabilities. Again, and to be clear: if it's something running on your own machine, or a machine you own, go nuts.
    - borski 5y ago
      This is an important caveat; the issue at hand is looking for vulnerabilities on other people's machines, not in other people's software. If it is running on your machine (read: not SaaS), reverse away. Releasing the exploit, on the other hand, is a different story (don't do that)

dgb23 5y ago

I agree in a practical sense. But I think there is a huge social problem here. Power relations between employers and employees, corporate goons (lawyers), lack of honest communication, lack of trust, lack of collaboration to make things better, general FUD. This all leads massive inefficiencies, people get hurt, progress is slowed down or even reverted.

crispyambulance 5y ago

> I don't think this person understands where white-hat boundaries are, or how to deal with being accused of a crime. OK but where, exactly, ARE "white-hat" boundaries? Is there a rule-book somewhere that he missed? How does one know how to deal with being accused of a crime? Practice? Cop-shows on TV? IMHO this person is someone who was just too naïve, overly trusting and unlucky. If there's blame here, much of it falls on his organization for failing to handle the initial incident report seriously.