“We found PayPal vulnerabilities and PayPal punished us for it” • Hacker News Board

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#221

Post by rasengan » Mon, Feb 24, 2020, 5:37 PM UTC

tptacek wrote: post #217

rasengan wrote: post #215

Earlier quoted context omitted.

The former; the author's report (short of seeing what was intentionally left out for proper disclosure reason) is credible, and Paypal's failure to respond/remediate the issue is improper. Getting access in this way to users' financial accounts is absolutely a vulnerability.

They are getting access to the accounts of people who do not have 2FA enabled and whose credentials have been stolen. Every bounty program I've ever paid attention to would close that report. Risk-based anti-ATO systems are heuristic.

> They are getting access to the accounts of people who do not have 2FA enabled and whose credentials have been stolen.

Ok, first, and foremost, don't you think it's a problem if there are stolen accounts? Wouldn't it make sense to visit the .onion site that the author refers to in the article and lock access to all accounts found there?

> Risk-based anti-ATO systems are heuristic.

This is Paypal practicing DID, which is great. What's not great is that the 2FA defense system could be defeated.

> Every bounty program I've ever paid attention to would close that report.

Getting access to a user's financial account and being able to move their money is something I would take serious 100/100 times. I hope you're not paying attention to bounty programs in the financial sector.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#222

Post by wyldfire » Mon, Feb 24, 2020, 5:40 PM UTC

DyslexicAtheist wrote: post #69

guidovranken wrote: post #42

HackerOne 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've never liked these rent-seeking bugbounty platforms which are inserting themselves as middle-men and mediators, but then take away the real value that comes from building direct client relationships. it's ok for people who start out and only want to work on vulns and not bother with "sales" (building long term client relationships). severely limiting though in the long run! much better to spend time on pitching y…

> I've never liked these rent-seeking bugbounty platforms which are inserting themselves as middle-men and mediators, but then take away the real value that comes from building direct client relationships.

They can add value for companies that don't have a reputation and want to have their security problems discovered. But they have to follow through on behalf of researchers and threaten to remove companies that don't pay bounties and/or don't investigate and remediate issues.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#223

Post by thaumasiotes » Mon, Feb 24, 2020, 5:43 PM UTC

Androider wrote: post #191

thaumasiotes wrote: post #106

Earlier quoted context omitted.

The policy of the company I worked for was only to dupe to closed issues if those issues were Resolved -- if the duplicate issue was already closed Informational or N/A, we just closed the new one with the same status. This has advantages in avoiding researcher confusion, as illustrated here. But that was a company policy, not an H1 policy. It's perfectly possible to dupe to a closed issue. (And of course, it's also…

Could you could state that the newly reported issue is both duplicate and that the original report was closed as N/A? Not applicable typically means the reporter is free to try to argue that is in fact applicable, but by stating it's both duplicate and N/A neither the second reporter nor the company will spend further time arguing back and forth, as even if the issue was applicable the credit would go to the original…

What goal are you trying to achieve?

It looks like what happened here was that the issue was (explicitly) labeled a duplicate, and the original issue was (implicitly) N/A, which you can tell if you're familiar with the platform by the fact that the duplicate report cost reputation points.

This achieves the result you mention, that interest in litigating the report further is muted because it's a duplicate. Though you might want it recognized as applicable anyway because of the reputation effects, even if you're the duplicate.

I did once see a company receive a report that duplicated an earlier report that had been closed by mistake. When the new one prompted a reexamination, they reopened the earlier report and duped the new one to it. That struck me as pretty honorable compared to the easier path of leaving the closed report closed and just processing the new one as if it were new.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#224

Post by rsync » Mon, Feb 24, 2020, 5:44 PM UTC

rasengan wrote: post #14

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. According to this image [2], they did not respond…

"If PayPal’s PCI-DSS compliance certification isn’t revoked then PCI-DSS is a farce."

PCI Compliance is total bullshit and everybody knows it.[1]

[1] https://www.rsync.net/resources/regulatory/pci.html

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#225

Post by rasengan » Mon, Feb 24, 2020, 5:44 PM UTC

tptacek wrote: post #206

rasengan wrote: post #204

Earlier quoted context omitted.

> 1. They can suppress a new-computer login challenge (they call this "2FA", but this is a risk-based login or anti-ATO feature, not 2FA). 2FA means 2 Factor Authentication. This works by forcing one to use two different forms of identification to authenticate, such as login/password and, in this case, identification of the computer used. So, with all respect sir, what I'm saying is while this isn't the best 2FA, it…

No.

> No.

Please explain which parts of my comment are false?

Thank you.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#226

Post by nebulous1 » Mon, Feb 24, 2020, 5:45 PM UTC

smsm42 wrote: post #213

ijpsud wrote: post #91

Earlier quoted context omitted.

It's very obviously a distinction without a difference though. Like the authors say, this is a amazing opportunity for black-market paypal account buyers. It's the only line of defense that thousands of people have between black hats and their bank account. In any case, I'd definitely call this 2-factor authentication - the only difference is the trigger (every login vs suspicious logins). It just so happens that the…

There's a huge difference between an informational email "somebody just logged into your account, was it you?" and 2FA workflow which does not let you log in without entering proper code. The latter is a security feature, the former is at most auxiliary informational feature. > I'd definitely call this 2-factor authentication - You'd be misunderstanding what "authentication" means then. Notification and authenticatio…

To be clear, the extra check that is bypassed is not merely an informational message, the system sends you a message and you are supposed to have to enter something contained in that message in order to continue from that IP address/computer.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#227

Post by tptacek » Mon, Feb 24, 2020, 5:45 PM UTC

rasengan wrote: post #225

tptacek wrote: post #206

Earlier quoted context omitted.

No.

> No. Please explain which parts of my comment are false? Thank you.

This feature is not 2FA, and your argument is incoherent even if you fix the terminology, because many anti-ATO systems are heuristic and intriniscally "bypassable" by design, and yet you still want services to have them. ATO is an arms race.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#228

Post by sneak » Mon, Feb 24, 2020, 5:49 PM UTC

cj wrote: post #120

guidovranken wrote: post #42

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

> HackerOne appears to be completely broken and I wouldn't recommend it to anyone. Completely disagree with this. I launched a HackerOne program for my company last month (for free, not using their “managed” service). Of the many reports people submitted, we triaged 30-40 valid reports (most very minor, one or two moderate). We paid out a few thousand dollars in rewards. At the same time, we also did a more tradition…

> And H1 was 2-3x cheaper after paying out the bounties.

Perpetuating a system wherein security researchers are massively underpaid for their services because of a terrible abusive platform doesn't seem like a very nice way to do business.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#229

Post by blazespin » Mon, Feb 24, 2020, 5:50 PM UTC

Hmm, they don't look that bad - https://hackerone.com/paypal

Here's an example of something that got paid out by paypal - https://hackerone.com/reports/739737 (15K)

Good writeup - https://medium.com/@alex.birsan/the-bug-that-exposed-your-pa...

Interesting history with paypal - https://hackerone.com/alexbirsan

Here's how duplicate reports are dealt with - https://docs.hackerone.com/programs/duplicate-reports.html

I am curious if paypal provided the OP with original reports. They don't say. I wonder how much the OP is not saying here, versus how much they understand the platform they are working on.

This statement makes me very curious: "Other criticisms have pointed out that Security Analysts can first delay the reported vulnerability, report it themselves on a different bug bounty platform, collect the bounty (without disclosing it of course), and then closing the reported issue as Not Applicable, or perhaps Duplicate."

How can you do that if you're providing the original report?

Also, the guy is just wrong. You GAIN rep points for duplicates, unless you did something dumb and really amateur like not searching first for already publicly disclosed issues.

https://docs.hackerone.com/hackers/reputation.html#effects-o...

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#230

Post by marcus_holmes » Mon, Feb 24, 2020, 5:52 PM UTC

moftz wrote: post #97

monadic2 wrote: post #80

Earlier quoted context omitted.

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

Why does the regulatory body get to approve who and what can scan implementations of their security scheme? It seems like the ideal auditor and scanning software, in PCI DSS's eyes, would be the one that just barely checks the boxes for minimum security requirements. Poking too hard at their security scheme would reveal how lackluster it is but they still need someone to poke at it to prove compliance. Being able to…

It works better this way around than the other way around - which would be that PayPal gets to pick who audits them with no oversight. You can imagine how thorough that audit would be, and how many times it would find any problems.