
“We found PayPal vulnerabilities and PayPal punished us for it” - teslademigod1
https://cybernews.com/security/we-found-6-critical-paypal-vulnerabilities-and-paypal-punished-us/
======
guidovranken
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 months to merge my patch. Maybe they're
volunteers, so I can't blame them. Reported it to the bug bounty [1] which
promises high rewards on January 20th and apart from triaging it, there has
been radio silence since despite having invoked HackerOne mediation. I have
more Squid memory bugs and I'd rather rm -rf them than go through this process
again.

HackerOne used to be decent but this appears to be a structural problem now
[2].

[1] [https://hackerone.com/ibb-squid-cache](https://hackerone.com/ibb-squid-
cache) [2]
[https://twitter.com/DevinStokes/status/1228014268567547905](https://twitter.com/DevinStokes/status/1228014268567547905)

~~~
cj
> 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 traditional 2-week penetration test with
Cobalt ([https://cobalt.io/](https://cobalt.io/)) that cost over $10,000, and
HackerOne was the _clear_ winner when it came to the number of high quality
security reports worth fixing. And H1 was 2-3x cheaper after paying out the
bounties.

I’m sure HackerOne isn’t great for all companies, but just posting this to
refute the blanket statement that HackerOne is “completely broken” across the
board.

~~~
sneak
> _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.

~~~
tptacek
The platform has nothing to do with the rates; plenty of companies run bounty
programs without H1, and there is a general standard range for findings across
all platforms.

None of these findings appear to have been worth much of anything.

------
rideontime
From PayPal's response to a 2FA bypass:

> If the attacker has the victim's password, they would already be able to
> gain access to the account via web UI too. As such, the account is already
> compromised. As such, there does not appear to be any security implications
> as a direct result of this behavior.

Seriously? This means PayPal's 2FA is just security theater. I'd rather they
didn't offer it at all in this case, at least then I'd know how insecure my
account really was.

~~~
nebulous1
From reading a different article, the terminology seems to be a bone of
contention here. This ’2FA' is an email message PayPal send when they detect a
new login location. They do not call it 2FA and they do offer actual 2FA that
cybernews have not bypassed.

~~~
ijpsud
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 they have different code for each
of those two cases, and these bounty hunters have discovered a bug in one of
them.

~~~
smsm42
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
authentication are different things. Email is notification, not
authentication. Confusing it means either not knowing what authentication is,
or purposely confusing matters to present issue as something it isn't.

~~~
nebulous1
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.

~~~
smsm42
OK if it blocks login then it's at least partial 2FA for those logins. I
thought it's only informational judging from the Forbes article but if it's
not then it's part of the auth workflow and thus can be regarded as 2FA.

------
tptacek
People have a weird mental model of how big-company bug bounty programs work.
Paypal --- a big company for sure, with a large and talented application
security team --- is not interested in stiffing researchers out of bounties.
They have literally no incentive to do so. In fact: the people tasked with
running the bounty probably have the opposite incentive: the program looks
better when it is paying out bounties for strong findings.

Here are the vulnerabilities in their report:

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).

2\. They can register accounts for one phone, then change it to another phone,
to "bypass" phone number confirmation.

3\. There are risk-based controls in Paypal that prevent transactions when
anomalies are detected, and some of them can apparently be defeated with brute
force.

4\. They can change names on accounts they control.

5\. They found what appears to be self-XSS in a support chat system.

6\. They found what appears to be self-XSS in the security questions challenge
inputs.

None of these are sev:hi vulnerabilities, let alone "critical". 2 of them ---
#4 and #6 --- are duplicates of other people's issues. Self-XSS
vulnerabilities are often excluded entirely from bounty programs.

For the last 3 hours, the top comment on this thread has been an analysis
saying that, because Paypal is PCI-encumbered, and HackerOne reports can
function as "assessments" for PCI attestations, Paypal is in danger of losing
its PCI status (and the fact that it won't is evidence that they are "too big
to fail"). To put it gently: that is not how any of this stuff works. In
reality, formal bug bounty programs are a firehose of reports suggesting that
DKIM configuration quirks are critical vulnerabilities, and nobody in the
world would expect any kind of regulatory outcome simply from the way a bounty
report does or doesn't get handled. It should, I hope, go without saying that
nobody is required to run a bounty in the first place, and most companies
probably shouldn't.

The login challenge bypass finding was actually interesting (it would be more
interesting if they fully disclosed what it was and what Paypal's response
was). But these reporters have crudded up their story with standard bug-
bounty-reporter hype, and made it very difficult to judge what they found. I'm
inclined not to believe their claim that Paypal acted abusively here (and I am
not a fan of Paypal).

~~~
nebulous1
> I'm inclined not to believe their claim that Paypal acted abusively here
> (and I am not a fan of Paypal).

I agree that they have some issues with the way they've reported it, and I
agree with your numbered points except that they imply that #5 may make the
support agent vulnerable, but I'm not sure you can say PayPal haven't acted
abusively. Many of the reports are legitimate vulnerabilities even if they
aren't critical ones. The first is clearly a security issue yet PayPal have
said that it isn't. In return they have received nothing but a reputation hit,
and this is clearly unfair.

Do PayPal specifically say that anything involving stolen details are out of
scope? This seems a bit weak considering they have numerous systems in place
to combat misuse of stolen accounts. And even if they do it doesn't explain
#2.

edit: To answer my own question, the page at lists "Vulnerabilities involving
stolen credentials or physical access to a device" as out of scope for web
applications. They likely intend that to apply to mobile applications also,
but they've structured the page in a way that makes that ambiguous.

~~~
pvg
_Do PayPal specifically say [...]_

This is why this article is a bad HN submission - it's not really on everybody
on HN to figure out whether these reports are any good, whether they were
handled correctly by PayPal, HackerOne, etc. It's up to the people writing
them up to make this as clear as possible and they don't come anywhere close
to that. This just creates a massive discussion driven by speculation and off-
topic tangents about a problem people had on ebay and talmudic regulatory
'analysis'.

------
leejo
This doesn't surprise me. I'm currently trying to get a refund out of PayPal
after what looks like a massive flaw in their refund process. I paid for
something on eBay and it appears to have been a compromised account. The
original auction, feedback history, etc, looked legit. The flow was this:

1) I pay for a product on eBay using PayPal, using my creditcard (direct from
card, not from any existing PayPal balance).

2) Seller marks item as shipped but then 5mins later issues an e-check refund
(rather than a refund on my creditcard).

3) Seller cancels and deletes the original item on eBay so i can no longer
raise a dispute there.

4) The e-check refund continues to bounce as clearly the compromised paypal
account can't pull those funds from the other source.

5) The refund being in limbo means my dispute with PayPal gets closed as "a
refund was previously issue" (which did, and will continue to, bounce).

The important part is 2 - since I paid for this on my card the refund should
have gone direct to my card. However, since I paid for this on my creditcard
I've raised a chargeback with the issuing bank, which should hopefully make
PayPal sit up and put a bit more effort into sorting this out.

~~~
fencepost
_I 've raised a chargeback with the issuing bank, which should hopefully make
PayPal sit up and put a bit more effort into sorting this out._

Or just close your account and ban you.

~~~
leejo
Possibly, a blog post will follow if that happens. PayPal has aways been a
firewall around my creditcard number and I've never linked any other current
account for pulling funds as, having worked in the payments industry, I know
what a shit show it can be and that (in most cases, especially like this) the
creditcard issuer will stand with the cardholder and not the merchant.

Now i'm using other methods to pay for most e-commerce transactions: one time
PANs, a distinct debit account that I keep a minimum amount of funds in for
this stuff, etc. So PyaPal are no longer seeing anything like the level of use
they once did from me. They can ban my account if they want, the issuing bank
have already said they will proceed with the chargeback if PayPal don't issue
a refund.

~~~
fencepost
What may save you is terms on the card about refunds needing to be credited
back to the card - pretty sure that used to be the case and probably still is.
I think it was originally to prevent under the table cash advances, but also
to protect merchants from giving refunds then being hit with chargebacks. If
the bouncing e-check was done through PayPal as well then they may have
screwed up by allowing it.

------
rasengan
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 or refute within 30 days.

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

[1] [https://www.itgovernance.co.uk/blog/a-guide-to-the-pci-
dsss-...](https://www.itgovernance.co.uk/blog/a-guide-to-the-pci-dsss-
vulnerability-scanning-and-penetration-testing-requirements)

[2] [https://cybernews.com/wp-
content/uploads/2020/02/paypal-2fa-...](https://cybernews.com/wp-
content/uploads/2020/02/paypal-2fa-bypass2.png)

~~~
ailideex
> 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, you must schedule a rescan within 30 days to prove that
> the critical, high-risk or medium-risk vulnerabilities have been patched.

Scan in this sentence refers to "a PCI DSS external scan".

The list of approved vendors that can conduct PCI DSS external scans can be
found here:
[https://www.pcisecuritystandards.org/assessors_and_solutions...](https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors)

Please find cybernews' certificate number there and quote it for us, I have
looked and can't find it.

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.

And even if they were an approved scanning vendor, from what little I know
about PCI-DSS, these scans are part of larger process - so even if they were
an approved scanning vendor the scan failure would still have had to be part
of the larger process for this 30 day limit to apply.

I could go on and on about how much I hate PayPal and random other things, but
just because I don't like something does not quite justify making false claims
about it.

~~~
monadic2
> 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 than simply demonstrating
aptitude directly.

~~~
moftz
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 ignore anyone or anything that isn't
on the approved list seems like willful negligence.

~~~
michaelt
_> Why does the regulatory body get to approve who and what can scan
implementations of their security scheme?_

Because it's a scanner for PCI-DSS compliance, not a scan for security issues.

They do not fear that unapproved scanners will be more strict than approved
scanners, they fear they will be less strict.

------
fulldecent2
If you are receiving your money or reputation from a platform (like HackerOne)
then you are going to be underappreciated, undervalued, and treated like an
expense that should be minimized.

Here is what responsible disclosure looks like in 2020 from somebody that has
self-worth:

> (Message posted to Hacker One, and emailed to any address you can find, and
> sent in a letter by mail. Yes mail. Also copied in all those ways to
> investors of the target.)

>

> Dear Sir or Madam:

>

> I have learned about a security issue in PayPal's service. This includes
> being able to login to user accounts without the credentials the system is
> expecting. [Be vague about how exactly it works, but explain the impact.]

>

> I am not an employee or contractor of PayPal and I will publish this on my
> blog at [https://privacylog.blogspot.com](https://privacylog.blogspot.com)
> to build on my reputation for finding and improving the security of internet
> systems.

>

> This post will publish on 2020-03-09, which is two weeks from today.

>

> If you are committed to fix this issue before public disclosure, I will be
> happy to work with you. You can contact me at ...

\---

Key points:

\- The discussion is about my reputation and values. \- I am not demanding any
payment (not sure if that is legal). \- Set a firm publish date. \- This asks
them to make a commitment to fix and frames the discussion going forward.

And if they do not get back to you, then when you publish you explain it just
like you see in newspapers: "the vendor failed to respond and act on this
report when I contacted them by email, social media and paper mail with two
weeks' notice".

------
dev_hacker
Moral of story is obvious: Next time sell the exploits on the dark web and
skip the blog post.

~~~
m-p-3
It's all that PayPal deserves of they get a pass for PCI-DSS non-compliance.

~~~
AnIdiotOnTheNet
I'm sure that'll be a great comfort to the victims of whoever those flaws are
sold to.

~~~
annoyingnoob
Who would you like to be upset with in a case where the black market is more
efficient than HackerOne?

If the legitimate channels are not working then the system is broken and you
should blame PayPal and HackerOne. Be pissed at PayPal for not making it
easier to report real issues. Be pissed at PayPal for not finding the issues
themselves.

~~~
prostheticvamp
The failure of the legitimate market causally explains the emergence of a
black market.

It doesn’t morally vindicate people who sell exploits on the black market.

This is, I don’t know, kindergarten-level ethics? I’m flabbergasted at the
self-serving rationalizations here.

~~~
annoyingnoob
To be clear, I am not personally advocating the use of the black market to
sell exploits. I'm saying that the black market may be more attractive in
cases like this and that anger at the black market in this case is misguided.
The failure is with PayPal and/or HackerOne in this case. When the black
market is more efficient that is a failure of the legitimate marketplace and
you should place your anger with the legitimate marketplace that failed.

------
sn4pp
> They deemed this issue a Duplicate, and we lost another 5 points.

A dupe costs points?! On bugcrowd you GET points for dupes...

~~~
thaumasiotes
The points associated with a duplicate report depend on the status of the
report you get duped to. I assume in this case the original report was Not
Applicable.

~~~
sn4pp
Oh so an N/A dupe? That sounds plausable.

~~~
thaumasiotes
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 possible that you get duped
to an open issue which is later closed N/A, though that's pretty awkward. You
kind of hope for N/A issues to be closed right away, not to stay open for long
periods.)

And not duping to closed issues causes other issues -- it meant always having
to leave an internal comment citing the other issue that this one was secretly
a duplicate of.

~~~
Androider
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 reporter.

~~~
thaumasiotes
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.

------
strictnein
I'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 and have a malicious cert installed? Yeah... not
"critical" and out-of-scope for most places.

For "#2 Phone verification without OTP", look at the messages they were
sending. Did they not understand H1's responses? Repeatedly demanding answers
isn't a great look. It's not surprising it was locked.

For #3: it requires stolen creds. A "security" flaw that requires stolen creds
and brute forcing isn't going to get much traction anywhere.

#4 was a dupe

#5 is a self XSS, no one accepts these

#6 is a stored self XSS and a dupe

~~~
Dylan16807
> So you need to be MITM'd and have a malicious cert installed?

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.

~~~
SpicyLemonZest
As far as I can tell, "it's impossible to use stolen credentials" is not part
of Paypal's security model or a promise that Paypal has actually made. It's
important to distinguish flaws in a company's security model from additional
security controls we think they ought to add.

~~~
Dylan16807
But why does that system exist at all, if it's not supposed to do _something_?

It's not "impossible to use stolen credentials", it's "you have to clear this
barrier to use stolen credentials". If that barrier is broken, that sounds
like a flaw in the security model.

~~~
SpicyLemonZest
It's analogous to the systems that make your password show up as dots when you
type it in. The security model isn't affected at all - dedicated attackers can
"break the barrier" by just looking at your keyboard instead - but it
significantly mitigates harm by making certain low-effort attacks harder to
perform.

~~~
Dylan16807
A not-for-sure harm mitigation as part of defense in depth is a great thing to
put in a security model.

But with the flaw here, the effectiveness drops to zero. The "making certain
attacks harder to perform" is basically gone in the scenario where someone is
buying a bunch of credentials. That's not good!

------
harikb
There is plenty of blame to go around _beyond_ the management. Management is
always going to deflect, deny, or do whatever to save their face. There must
be “architect/lead engineer” level folks whose primary task is to engineer
these stuff well. WTF are they doing?

There should be a wall of shame for these (not by person, but by company and
group). Next time you get a contact/candidate who “lead the sign-on 2fa
management” at PayPal, we will know to be extremely cautious.

There is no “karma” in tech world. People design the shittiest systems in
company 1 and then move on to some other role in company 2 and float around
taking credit for more and more stuff someone else did.

~~~
dinkydrew
As someone in management, I will somewhat agree that management too often
deflects from their ownership and responsibility, but what you are saying is
also a form of deflection, unless you also espouse a kind of paternalistic
oversight over architects/engineers that would absolve them of responsibility
by simply being mindless executors of management's commands and lead. I
suspect that is not something most here would support.

There needs to be a balance, each party needs to play their own role and work
in unison. As much as managers need to manage things and largely clear the way
for architects and engineers, architects and engineers need to perform their
job and role, to which I would argue belongs adhering to industry standards
for security as a core aspect.

If there was clear pressure or even overriding of architects/engineers
insisting on adhering to standards by managers who were not performing their
role of advocating on behalf of or negotiating with architects/engineers, and
instead were even sabotaging them and their product, then sure, it's a
management failure; but at that point, architects/and engineers should have
also even out right refused and revolted against managers or at the very least
clearly and expressly voiced their vehement opposition.

As a manager, I would have even stuck my neck out and sided with an architect
and engineer rebellion if they were pressured or even asked to sacrifice core
requirements. I also understand though that not all organizations have
managers that would do that, especially in careerist organizations where
managers see people as bodies to pile up to climb the ladder faster.

~~~
harikb
I am surprised you read it that way. I was justifying what management does -
as in the are usually paid to make sure shit doesn’t hit the fan. But the
architect/engineer who design these should have made better decisions.

------
cosmodisk
Sound like PayPal business as usual. Crappy company with crappy attitudes.
It's fascinating when people spend their time and effort on good causes
instead of joining the dark side just to be shown the middle finger instead.

------
tfandango
I have not used Paypal since I had to file a dispute over an item I bought on
ebay via Paypal. As a response they snail-mailed me a bunch of screenshots of
an internal web-app with a bunch of info for someone else, SSN, CC number,
address, etc. Everything I would need to do something bad. I called them and
they did not seem to care so I called the guy (I had his number of course) but
he never answered or responded to my email.

A few months later I got a voicemail from paypal, apparently my original call
bubbled up. They asked if I had destroyed the info and to let them know if I
had not (I did). Then there was a long pause (I guess they assumed the
voicemail was over), and it turned out there were 4-5 people on that call and
they then discussed how the call went and whether or not it was sufficient to
CYA.

I've not used it since, and I hoped they got their act together (sounds like
maybe not).

~~~
Cynddl
What does CYA mean? Haven't seen this acronym before.

~~~
JimiofEden
[https://en.wikipedia.org/wiki/Cover_your_ass](https://en.wikipedia.org/wiki/Cover_your_ass)

------
d4n
Unfortunately, for many companies, bug bounty programs have been the best
invention in silencing security research and CVEs. They promise the world,
beat you down on severity / payouts, sometimes just claim duplicate or known
issue with no way to verify, and then block public disclosure. Very
frustrating.

------
hprotagonist
paypalsucks has been a registered domain since 2002 for a good reason.

~~~
aneutron
That is a hilarious random fact. Thanks for the info.

------
LegitShady
>When we pushed the HackerOne staff for clarification on these issues, they
removed points from our Reputation scores, relegating our profiles to a
suspicious, spammy level. This happened even when the issue was eventually
patched, although we received no bounty, credit, or even a thanks. Instead, we
got our Reputation scores (which start out at 100) negatively impacted,
leaving us worse off than if we’d reported nothing at all.

That seems like a good way to make sure nobody trusts your business. What say
you, hackerone? How can anyone trust this business acting against what
ostensibly is its core functions.

~~~
thaumasiotes
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](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"?

~~~
EthanHeilman
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.

~~~
hedora
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?

~~~
EthanHeilman
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)

------
dinkydrew
This is a bit tangential to the topic, but I find it immensely more
interesting that after literal decades of utterly egregious abuses and
downright evil behavior by PayPal, people still seem to be surprised by this
type of behavior.

I find it so fascinating because it is a kind of manifestation of what is
clearly a kind of mentality of abused people, the kind of people who usually
others see as being trapped in a kind of inability to internalize the abuse
being perpetrated against them, and therefore rationalize, excuse, ignore,
etc. to simply push away and hide and suppress the clear abuses happening to
them. It's just as sad as it is interesting to me because of the inherent
illogical puzzle it represents, a puzzle that clearly has not yet been solved
or for which there exists no easy and clean solution. How do you get someone
out of an abusive relationship, be it a personal relationship or something
like a formalized cult?

We are all abused by PayPal and other tech companies on a constant basis, yet
all we do is lament the treatment, while simply just continuing on in the
abusive relationship. Someone should tell PayPal, etc. "no, you are not
allowed to abuse us anymore. We have human rights and your lies, deceit,
abuse, manipulation, gaslighting, monopolization, etc are not going to be
tolerated anymore." But I guess our other abusers in Congress get too much
money and free meals out of it to change that.

------
Moru
I know of a really nice vulnerability but I know when to shut up. I almost
scammed a legitimate business by mistake. Made sure to pay them with a normal
bank transfer instead. Don't want to complain in case their account gets
closed down or something. Not touching PayPal again.

------
ohithereyou
I'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.

~~~
sn4pp
> I would actively, publically, and immediately disclose bugs that affect
> anybody who is a client of HackerOne.

Sadly you can't feed your children from media drama.

Maybe, in the long run, but it's more likely to get sued.

~~~
ohithereyou
The market for a freelance security researcher out there is hard, no doubt,
but disclosing bugs publically is an addition to your resume, akin to any
other professional development you do. It demonstrates you can do the work and
it shows the skills you have.

Suing someone for disclosing an actual bug is a long term losing proposition
for any company in a competitive industry.

~~~
sn4pp
> but disclosing bugs publically is an addition to your resume

Request disclosure on hackerone then. Idk, breaking the law to get a job
doesn't seem ok to me.

~~~
thaumasiotes
The screenshot in #2 does show the H1 Staff screwing up -- @cybernews requests
disclosure and gets a response saying "you may request disclosure if you would
like this reviewed, using the drop down menu" (which @cybernews has already
done).

@cybernews' behavior in that thread isn't ideal, but they're more in the right
than in the wrong on that one, judging by the screenshot.

~~~
sn4pp
I'm not talking about this case specifically.

At least Paypal was notified before the public disclosure!

------
jokoon
I say it all the time, there are no incentives or rules regarding
cybersecurity standards, or companies have no obligations to follow them. The
cost and risks of cybersecurity is pretty high, the public are always the
first victims and pay the damage.

Cybersecurity always has been a national problem which should be solved by
laws.

Insurance companies or banks should at least be encouraged to do more.

Cybersecurity shouldn't be improved with bug bounties.

------
soared
Are hackerone analysts employees of the company? If so the conclusion drawn
sounds like complete bs.

If the analysts are just other users, then it definitely sounds like there is
a problem.

~~~
thaumasiotes
Bug triagers may be employees of HackerOne, employees of the company (e.g.
Paypal here), or contractors indirectly working for the company (I worked in
this role for a year). They're not going to be random other researchers.

The screenshots in this article show a "HackerOne Staff" stamp, so those
triagers are employees of H1.

~~~
soared
So it’s pretty far fetched that they would be purposely delaying reports so
they could steal the rewards.

~~~
thaumasiotes
Hmmm.

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

Time to response is tracked. Reports are timestamped. So delaying response to
a report is a bad strategy -- reports are supposed to get precedence based on
when they were filed, not based on when they were responded to, and the delay
will be a black mark on your triaging record. This is the main objection to
Cybernews' conclusion.

Similarly, I'd be a little surprised if one company had a presence on multiple
bug bounty platforms. The standard flow is that you find a bug, look up the
company, and report it to them using whatever they tell you is their standard.
I've seen many reports including text like "Hello, I sent you this report by
email, and I was told I should file it on HackerOne". (Including this text, if
it's true, is a good idea for multiple reasons.) Centralizing reports makes
many things more convenient -- including timestamp comparisons, but much more
importantly it makes checking for earlier duplicate reports easier.

I'd also be a little surprised if HackerOne allowed their triagers to file
reports for the same companies they do triage for. They hire triagers from the
researcher pool, and they do allow triagers to hunt bounties on their own
time, but it would be a common-sense protection to prohibit them from
reporting to the same companies they triage for. I haven't worked directly for
H1; I don't know whether they have such a policy or not.

In conclusion, there is some potential for abuse, but it's unlikely that a
triager can abuse the system in the most obvious way, by personally stealing
reports that come to them for triage. I'd worry more about a triager
prioritizing their friend's report over a stranger's. I don't think triager
abuse is a significant risk of reporting through H1. I don't know the details
of what protections are in place.

later edit: on H1, each report has an ID number assigned in sequence -- if you
dupe an earlier report to a later report, the researcher will definitely
notice and complain.

------
znpy
The author might as well have sold the exploits for the best offer.

If a company advertises a bug bounty problem but fails to follow through, such
company kinda deserves to be hacked. I mean, you are wasting people's time and
still getting critical bug reports, probably along with a detailed write-up.

Also, we might also discuss about the fact that for a company that moves (and
earns) so much money as PayPal, 30 kUSD is probably very little when compared
to the possible outcomes of being hacked.

------
BrandoElFollito
We run a private bug bounty (not via H1 but another platform), classical
pentests, dynamic code assessment and a responsible disclosure program.

Pentests are ok, they help to scrap plenty of bugs. I am not a great fan
otherwise because it is based on a fixed rate.

Private bb ended up fantastic. Great bugs, great researchers, reasonably good
pay (not Apple grade but we paid some 30k€ irrc). Feedback from researchers
was good, including unexpected public praise.

Dynamic code reviews are a mixed bag. Usually crap, sometimes hidden gems.

Responsible disclosure is a mixed bag too. It is very binary : 20% great from
great researchers we usually invite to the private bounty afterwards, and 80%
garbage. Oh man, the garbage. Often I do not even understand the submission
(not being a native English speaker either).

One other problem with public programs are legal implications to pay an
anonymous reporter (imagine a US company paying someone affiliated with NC or
Iran or Daesh, and that info published in the press)

------
mjparrott
Given that there seems to be no consequence to getting hacked, I could see
companies putting their bug bounties into a filibuster program. They can
outsource their liability. I doubt the insurance companies who rate them care
if the 3rd party bounty administrator is effective.

------
jonnycomputer
I have no experience, but it seems to me that a bug bounty program would be
ripe for abuse by employees intercepting reports, feeding them to a partner
hacker, and then splitting the bounty between themselves. What stops that from
happening?

------
ryanlol
> Most ethical hackers will remember the 2013 case of Robert Kugler, the
> 17-year old German student who was shafted out of a huge bounty after he
> discovered a critical bug on PayPal’s site. Kugler notified PayPal of the
> vulnerability on May 19, but apparently PayPal told him that because he was
> under 18, he was ineligible for the Bug Bounty Program.

>But according to PayPal, the bug had already been discovered by someone else,
but they also admitted that the young hacker was just too young.

Bad PR like this shows that bug bounty programs are probably more trouble than
they’re worth.

------
HoustonRefugee
None of this is surprising. I keep the lowest possible amount of money in
paypal to cover eBay charges. Too many horror stories.

------
WUHANCLAN
HackerOne is complete garbage. I spent close to a month digging into Uber and
compromised their m.uber.com mobile endpoint; they hemmed and hawed and then
awarded the $25K to another HackerOne top performer stating that he had
discovered the exact same vulnerability the day before I had submitted the
report.

What's weird about it is that I was using Burp Proxy for everything, and this
guy was directly connected to PortSwigger (and Uber was running some
promotional for a free three month license for Burp Proxy).

HackerOne completely sided with Uber on everything, gave the Portswigger kid
$25K and that was that.

So, in summary: HackerOne is trash, and Burp Proxy may contain backdoor
functionality which is relayed directly back to Portswigger whenever a high
value critical vulnerability is discovered with it.

~~~
albinowax_
Hi, I work at PortSwigger.

> Uber was running some promotional for a free three month license for Burp
> Proxy

This is flat out wrong - the promotional partnership was done with HackerOne.

> What's weird about it is that I was using Burp Proxy for everything...

Burp Suite is used by tens of thousands of security experts and if we posted
vulnerability data back we would get caught in about ten seconds. Also it
would be stupid and illegal etc

Could you share the username of this 'Portswigger kid'? As far as I know I'm
the only person here that does bug bounty hunting, and I've never received a
25k payout off Uber. So I'm wondering if this person is actually affiliated
with PortSwigger at all.

~~~
WUHANCLAN
Either Uber lied about this guy discovering the flaw so they didn't have to
pay me, or Burp Proxy is sending telemetry back to Portswigger with high value
vulnerabilities being discovered with the platform. I worked with nobody on
this attack, I shared no information with anyone else, and submitted a remote
execution vulnerability using HackerOne's supposedly secure triage system.

I wrote it all up on Medium, it got close to 400K reads over the 2018
Christmas holiday with many other stories in a similar vein related to
incompetence in their security group. HackerOne is worthless, a scam unless
you are full time working for them on bug bounties and already connected with
their top ranked researchers.

------
Darknessgazer
If anyone in this thread is interested in talking about their experiences with
HackerOne, please shoot me an email at david.morris@fortune.com.

Positive or negative. We can set up a time to talk, or if you're more
comfortable, just include details in your email.

------
ghostpepper
Off topic, but did anyone else think that the diagonal black line on the Share
button on cybernews.com looks like a very thin hair on your screen? Almost
feels like it was done on purpose

------
neycoda
If a company or government ignores security vulnerability reports this way,
then you publicize it,anonymously if necessary, through the press if
necessary, to the bad guys if necessary.

------
hoppla
My two last reports were closed as duplicate. I got some rep for one, and zero
rep for the other. Both were real vulnerabilities. It is strange the
reputation reward is not consistent.

~~~
lgeorget
According to HackerOne help page on reputation, it depends on the status of
the vulnerability: yet undisclosed, not applicable, publicly known...

------
rishabhd
Been there, seen that. I find it hard to trust bug bounty platforms and their
vulnerabilities as a researcher.

------
IronWolve
Interesting timing, a pro hackone article on slashdot posted hours after this
post about hackerone issues.

------
homakov
None of the bugs is critical, not even medium severity.

------
Vysero
I have heard enough. I am done using PayPal.

------
stebann
Hackers of the world, unite!

------
blazespin
Hmm, they don't look that bad -
[https://hackerone.com/paypal](https://hackerone.com/paypal)

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

Good writeup - [https://medium.com/@alex.birsan/the-bug-that-exposed-your-
pa...](https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-
password-539fc2896da9)

Interesting history with paypal -
[https://hackerone.com/alexbirsan](https://hackerone.com/alexbirsan)

Here's how duplicate reports are dealt with -
[https://docs.hackerone.com/programs/duplicate-
reports.html](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...](https://docs.hackerone.com/hackers/reputation.html#effects-
of-report-state-on-reputation)

