Earlier quoted context omitted.
it's not just email, its phone also. i recently recently logged inco company paypal from out of country and paypal complained it wants to confirm account via email, fine i confirmed. and then it said it also needs to conform the via phone. ie a call. so it is a form of 2fa. can i also complain how is 2fa a pain if multiple persons use that account. you cannot enable it if they allow only one user per account. there a…
I haven't looked at PayPal specifically, but if it's a standard authenticator app can you not both set it up via the QR code when you enable it while everybody is present? However, obviously the real answer is to add multiple users to the same paypal account, which apparently you can do with a PayPal Business account.
“We found PayPal vulnerabilities and PayPal punished us for it”
181–190 of 337 posts
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#182HackerOne appears to be completely broken and I wouldn't recommend it to anyone. Disagreements are to be expected on a bug bounty platform, but these days they just stop responding altogether and don't pay. It borders on outright fraud. I've been trying to report a Squid RCE (CVE-2020-8450) since October. The Squid maintainers seemed unprepared for dealing with the report as they kept being unresponsive and it took 2…
I submitted a vulnerability to a vendor on H1 along with a typical “I plan on publicly disclosing this vulnerability on X date” note, and started getting emails directly from H1 telling me that this undermined vendors’ confidence in the platform and that doing what I was doing might make it so I can’t use HackerOne any more. In the same correspondence they said that my approach made sense—but they continued to threaten that “it would be a shame if you weren’t able to participate any more”.
In my case, the vendor verified the vulnerability quickly, but kept dodging my follow-ups by replying without answering my questions. When the vendor refused to assign a CVE after I asked four times, I contacted the HackerOne CNA directly to get an assignment. They replied within 48 hours asking if there was any public information already, I said no and that I was planning on disclosing on X date, and then they just stopped replying for a month until after the deadline passed.
At a glance, H1’s disclosure guideline appears fairly reasonable: 30 days by default, an upper bound of 180 days. In actuality, those times only start once a vendor closes a ticket, and can be extended indefinitely. Reporters aren’t allowed to speak publicly about anything they send to the platform until the ticket is closed and the vendor agrees to allow it, even in the public programs.
As far as I can tell, HackerOne’s primary purpose now is to act as a shield for bad vendors to hide their security defects from the public by using network effects to bully reporters into keeping quiet. The community team claim this isn’t what they’re doing and that they always ask “why should this be private?”, but their marketing material to vendors tells a different story[0], their actions with me tell a different story, and the vendor I reported to had over 100 closed reports, going back years, and none of them were publicly disclosed.
Unless you must pay your bills with security bounties, or don’t actually care and just want to dump a report and forget about it, I unequivocally recommend against using HackerOne to report a vulnerability.
[0] https://www.hackerone.com/sites/default/files/2018-11/The%20... page 12: “even with a public program, bug reports can remain private and redacted, disclosure timeframes are up to you”
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#183Earlier quoted context omitted.
> PCI DSS requirements specify that companies have 30 days to refute or remediate externally reported issues [1]. If they don’t respond or fix some of these issues, then PayPal will no longer be compliant and all credit card companies will be forced to stop working with them unless they wish to set precedence that PCI-DSS compliance is no longer required to be followed. Quote from your source: > If your scan fails, y…
> I would guess that, contrary to your implication, they are not an approved scanning vendor. If this is the case then it really does not speak to the characteristics of PCI-DSS and your comment just seems wrong. Actually this makes a pretty good case for this regulation being a joke. They clearly aren’t up to the responsibility of being a payment processor and are leaning on the law to sustain their business rather…
Did you read downthread about the actual "2FA" feature this team "bypassed"?
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#184Earlier quoted context omitted.
You achieve that compliance by paying HackerOne, as a company, to perform a compliance scan. This does not mean any swinging dick that reports a vulnerability through HackerOne is causing PayPal to fall out of compliance. These scans are planned well in advance and are part of a normal audit cycle. (edit: typo) On top of that, there's not really any legal issues for being non-compliant, as has been pointed out elsewh…
As someone who deals with PCI-DSS compliance in fintech land on a daily basis this thread is showing me there are a lot of people who like to crow on about stuff they don't know a thing about.
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#185Earlier quoted context omitted.
Protection from fraud . Fraud costs the credit card industry money. It makes people less likely to trust/use them, which then costs them business. You said - "avoid actually being regulated and are a way to shift liability" This is like saying a store put razors in a locked case to avoid being regulated. Or they simply don't want their stuff stolen? I was being facetious when I said if we want to be cynical, because…
> Or they simply don't want their stuff stolen? Equating credit card fraud to physical theft is silly. The intermediaries of the credit card industry earn revenue by charging fees to process transactions. When fraud occurs, they're only liable if they were some how responsible. PCI allows the network to shift liability to the periphery and to allow the central network to deny taking responsibility for systemic proble…
In both cases someone is out money. It isn't a difficult step.
Fraud costs the credit card industry. It costs issuers (they shoulder 60% of the direct cost), merchants, and it costs the future of the industry because it is a nuisance for end-users.
They make a standard of best practices to reduce fraud. Following those best practices is good for every single participant, outside of criminals. Reducing fraud wholesale is the goal, obviously.
Spinning this in a nefarious fashion is not helpful to anyone, and does nothing but muddies the waters.
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#186PCI DSS requirements specify that companies have 30 days to refute or remediate externally reported issues [1]. If they don’t respond or fix some of these issues, then PayPal will no longer be compliant and all credit card companies will be forced to stop working with them unless they wish to set precedence that PCI-DSS compliance is no longer required to be followed. According to this image [2], they did not respond…
> PCI DSS requirements specify that companies have 30 days to refute or remediate externally reported issues [1]. If they don’t respond or fix some of these issues, then PayPal will no longer be compliant and all credit card companies will be forced to stop working with them unless they wish to set precedence that PCI-DSS compliance is no longer required to be followed. Quote from your source: > If your scan fails, y…
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#187I've had plenty of problems with bug bounty platforms and have completely stopped doing them. But most/all of these "critical" reports aren't critical and some of the behavior of their "researchers" is unprofessional at best. There's maybe one legit report here, and that's #2. #1 "In order to bypass PayPal’s 2FA, our researcher used the PayPal mobile app and a MITM proxy, like Charles proxy." So you need to be MITM'd…
No. The attacker is the man in the middle to himself, because why are you trusting the client.
> A "security" flaw that requires stolen creds and brute forcing isn't going to get much traction anywhere.
The feature is meant to stop people from using stolen creds.
It does not work.
Given that stolen creds exist, that sounds like a security flaw to me.
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#188I've seen several stories about how HackerOne doesn't pay out bug bounties when bugs are reported. I, for one, wouldn't submit bugs/PoC to them, and I would actively, publically, and immediately disclose bugs that affect anybody who is a client of HackerOne.
i think you might want to take a breath, rethink that position and not let your anger cause you to do something stupid. if you disclose a vulnerability, the company HAS EVERY RIGHT to sue you. every security researcher _thinks_ that they are protected by some unwritten good Samaritan law, when in fact, you are hacking and that carries financial and criminal penalties. this is why these bug bounties and established wa…
Note: I didn't say that I would do this for every company. Just ones that use HackerOne. They have decided to abdicate their responsibility for their security vunerability reporting, and I feel completely justified in dumping info on their vulnerabilities.
Releasing the details of a vulnerability is not stupid. The users of the software/service deserve to know the data/service they're using is unsafe when a vendor refuses to act on a valid security issue
>If you disclose a vulnerability, the company HAS EVERY RIGHT to sue you.
You don't need the right to file a lawsuit to file a lawsuit. You just file the lawsuit. Now, you need an actual, actionable claim to prevail a a plaintiff in a lawsuit. Whether such a thing exists in practice is something we leave to lawyers to argue about and judges/juries to decide.
If your company is in a competitive industry and I release the details of a vunerability in your software and you sue me then that vulnerability and lawsuit becomes marketing item number one for all of your competitors.
>this is why these bug bounties and established ways of notifying the company of the vulnerabilities exists
Arguably why they exist. In reality, they tend to exist to give people an incentive to not dump the vuln details on the black market, embargo bugs so customers don't leave, and attempt to maintain a good relationship with security researchers. They do not grant immunity from being sued or somehow grant the legal right for security researchers to do their work as your comment seems to indicate.
Your post reads like propaganda from a bug bounty organization. I'm not saying that you're shilling, just that you're misinformed. In the US it is generally legal to conduct security research. In the US it is legal to communicate the results of that research publicly so long as you have not agreed in some contract to not do so.
Where did you get the idea that legitimate security research is a crime?
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#189Earlier quoted context omitted.
It's not a regulation. It's a contractual obligation between the merchant and the PCI counsel (which is made up by VISA/Mastercard/the backing banks/etc). It was put in place to avoid regulation.
Then perhaps regulation is necessary if this is their level of scrutiny?
Re: “We found PayPal vulnerabilities and PayPal punished us for it”
#190Earlier quoted context omitted.
It's not a regulation. It's a contractual obligation between the merchant and the PCI counsel (which is made up by VISA/Mastercard/the backing banks/etc). It was put in place to avoid regulation.
Then perhaps regulation is necessary if this is their level of scrutiny?