Hacker News Reader

Comment by thaumasiotes | Hacker News Reader

They had out-of-scope issues closed as being out-of-scope, which automatically lowers their reputation on the platform. The researchers are outraged:

> When we submitted this to HackerOne, they responded that this is an “out-of-scope” issue since it requires stolen PayPal accounts. As such, they closed the issue as Not Applicable, costing us 5 reputation points in the process.

But Paypal's policy really couldn't be clearer:

> Out-of-Scope Vulnerabilities

> Vulnerabilities involving stolen credentials or physical access to a device

( https://hackerone.com/paypal )

If Paypal says "don't send us this type of report", and you send one anyway, are you really surprised when your account gets a warning attached saying "this person usually files low-value reports"?

View on HN

Yet paypal's policy explictly says authentication bypasses, like the 2FA bypass they showed, are in scope

>Authentication or authorization flaws, including insecure direct object references and authentication bypass

Reading with the context of the other out-of-scope issues. I think they meant that the ability to buy or steal someones credentials is not a vulnerability in and of itself.

>Vulnerabilities involving stolen credentials or physical access to a device

It is a poorly worded and confusing policy. Yet, if I found a 2FA bypass and I read that policy I would conclude that it is in scope and submit the issue.

Bypass means skipping steps on PayPal's side (like reading user data without a a password), not skipping steps on user side (stealing their password).

> It is a poorly worded and confusing policy. Yet, if I found a 2FA bypass and I read that policy I would conclude that it is in scope and submit the issue.

If you wanted my advice as something of an insider to the platform, I'd say that you should point to the ambiguity there ("One policy says yes, another policy says no?") and ask for an Informational close rather than Not Applicable. (H1 hates it when researchers ask for a specific close status, but it's common and often reasonable.) Closing your report Informational instead of Not Applicable costs the company nothing, so even an argument that isn't very strong on the merits can carry the day.

I wouldn't push for a payout, given the out-of-scope phrasing. If executing a successful attack requires you to possess stolen credentials, they're on solid ground when they tell you the attack is excluded by their policy.

They apparently have fake / security theater 2FA, where things are as inconvenient as 2FA, but pay pal explicitly doesn’t care that it’s easily bypassed, and full of security bypasses.

They also have opt-in 2FA.

It’s unclear which one the author bypassed.

Perhaps the confusion is by design on paypal’s side? Presumably giving people a false sense of security helps them close disputes without paying out?

I think the confusion results from attempting to encode "use good judgement" in formal language. I suspect the reason they talk about stolen accounts being out of scope is because someone bought a bunch of stolen accounts and then demanded a bounty.

Completeness or consistency (choose one)

with the acquired information, the researcher has a few options:

- bulk acquire stolen credentials, bypass 2FA, bypass the security checks when sending money, and accumulate wealth

- sell above process to anyone that has an internet-connected device, the desire to accumulate wealth, and willingness to commit fraud (which I would guess is a non-trivial % of the world's population)

- disclose the vulnerabilities to paypal through any available channels

The fact that they went with the latter AND were punished for it doesn't shock you? Jesus.

Their "In-Scope Vulnerabilities" explicitly includes XSS exploits, though, which they also closed as Not Applicable (after patching the issue).

Tangentially, as a (former?) PayPal user, it's wild to see that they consider vulnerabilities involving stolen credentials as a non-issue. Why do they offer 2FA at all, then?

e: After taking another look at that massive Out-of-Scope list, I'm having a hard time imagining a bug that couldn't be closed as "Not Applicable." What a sham.

I can't really evaluate #5, but their screenshot undermines them -- it shows a chat session between the victim and "PayPal Virtual Agent", with the virtual agent offering some canned text.

If that's all you can do, then this is a self-XSS, which is excluded.

#6 is much more clear; that one's very obviously a self-XSS.

Their full "out of scope" list also includes MITM attacks, which would exclude most of what's in this article. I guess my confusion now is why PayPal even purports to offer bug bounties if they're going to craft an "out of scope" list that allows them to reject every submitted report.

> I guess my confusion now is why PayPal even purports to offer bug bounties if they're going to craft an "out of scope" list that allows them to reject every submitted report.

They're not; you're just choosing to assume bad things about them. Their out-of-scope list is fairly standard. If you asked a guy on the street "what would hacking PayPal look like?", the answer they imagined would probably be in scope.

For example, if I send you a link to my personal website, and when you visit the website your PayPal account automatically sends $500 to my PayPal account, that's in scope.

I'll happily admit that I have no experience with bug bounty programs. I'm just a heavy PayPal user who's shocked to learn that PayPal apparently doesn't care whether someone is able to bypass their security measures. Whether or not that's "standard" doesn't really change my reaction.

> automatically sends $500 to my PayPal account, that’s in scope.

Nope. From the out of scope list:

> Attacks involving payment fraud, theft, or malicious merchant accounts

You're misinterpreting it.

All the more reason to not submit bugs like this to HackerOne. If you can bypass 2FA by having only one factor then I wouldn't consider that 'stolen credentials' and more a singular stolen credential. Their system is designed to defend against this and it does so ineffectively. That is, by definiton, a security issue.

I wish I could define what is and isn't a bug in my code at work. My defect rate would be incredible.

The mitical “it’s not a bug, it’s a feature!”

but this is it:

"This happened even when the issue was eventually patched..." which, based on that, I understand their gripe here

That would be a valid complaint if their report had been closed Not Applicable on the grounds that the behavior didn't present a significant security risk. But it wasn't; it was closed Not Applicable on the grounds that it was ineligible for the program regardless of whether it was a security risk.

hmm yes, I see your point

The vulnerabilities they found allow bypassing the two factor auth so works with only part of the credentials

Reply on news.ycombinator.com