Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cybernews.com

Post reply on HN
Print view View original

311–320 of 337 posts

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

#311

Post by WUHANCLAN »

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 is complete fraud. They've got a super duper simple carrot before the horse business model which has thousands of kids beating up web apps for free. A valuable service for their Fortune 100 clientele; for the people actually doing the work for them, not so much.

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

#312

Post by tptacek »

csnover wrote: post #305
tptacek wrote: post #286

Earlier quoted context omitted.

It presumes a definition of "responsible" that suits the interests of vendors and treats the safety of end-users as an externality, in such a way that anyone operating in good faith and responding to different legitimate incentives is by definition "not" disclosing "responsibly". It's a linguistic ploy, and not one that should be dignified. In 2020, non-ironic use of the term "responsible disclosure" has become somew…

You’re right that I am a software engineer, not a vulnerability researcher. I keep up with vulnerability research only insofar that I need to be aware of new classes of exploit so that I can write secure code (and, hey, it can be interesting!). So, what is the correct term that is supposed to be applied to the approach of disclosing to a vendor first, giving them a hard deadline, and then doing a public disclosure? A…

It is in fact "coordinated disclosure".

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

#313

Post by tptacek »

brianpgordon wrote: post #303
tptacek wrote: post #198

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…

> 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. Really? Most companies? That seems like an extraordinary claim. I'm not a security researcher but if I stumbled on some security issue in something that's not open-source and not owned by my employer, the only way I'd consider reporting it is if they have a bug bounty / responsible…

That depends on the kind of issue you found and the type of service it was, but, yes: without an authorization of some sort, it's probably unlawful to test for large classes of serverside vulnerabilities. The kind of work Project Zero does, on the other hand, is both more impactful and does not usually require authorization, since they're analyzing software running on their own machines.

Most companies should not run bug bounties. Most companies haven't even had a competently run software security assessment (either from an in-house software security expert or from a retained third party). Authorizing serverside tests and soliciting inbound reports from random people is not on the list of "first things you should do to get your house in order", and most people do not have their houses in order.

If this sounds like an extraordinary claim, I'd suggest maybe paying more attention to software security people and less attention to Reddit and HN stories about bug bounties; it's easy to get the wrong impression from message board threads, and as you can pretty plainly see, a lot of commentary on message board threads isn't well-informed.

Katie Moussouris is maybe a good starting point if you want to inject the "bug bounties can be bad" take directly into your veins. But there are lots of other people to listen to; it's a mainstream take. If you want a pro-bounty take, you can read what Cody Brocious writes. My (mainstream) take isn't the only decent take.

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

#315

Post by meowface »

csnover wrote: post #305
tptacek wrote: post #286

Earlier quoted context omitted.

It presumes a definition of "responsible" that suits the interests of vendors and treats the safety of end-users as an externality, in such a way that anyone operating in good faith and responding to different legitimate incentives is by definition "not" disclosing "responsibly". It's a linguistic ploy, and not one that should be dignified. In 2020, non-ironic use of the term "responsible disclosure" has become somew…

You’re right that I am a software engineer, not a vulnerability researcher. I keep up with vulnerability research only insofar that I need to be aware of new classes of exploit so that I can write secure code (and, hey, it can be interesting!). So, what is the correct term that is supposed to be applied to the approach of disclosing to a vendor first, giving them a hard deadline, and then doing a public disclosure? A…

"Coordinated" would suggest the bug discoverer and the vendor coordinate on a time. (As for whether this is what actually happens in practice, no idea.)

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

#316

Post by csnover »

tptacek wrote: post #312
csnover wrote: post #305

Earlier quoted context omitted.

You’re right that I am a software engineer, not a vulnerability researcher. I keep up with vulnerability research only insofar that I need to be aware of new classes of exploit so that I can write secure code (and, hey, it can be interesting!). So, what is the correct term that is supposed to be applied to the approach of disclosing to a vendor first, giving them a hard deadline, and then doing a public disclosure? A…

It is in fact "coordinated disclosure".

Even when the disclosure is not actually coordinated, in the common sense of the word, because the vendor doesn’t agree to the deadline and/or isn’t given any option to pick a longer deadline?

Edit: The Google Project Zero FAQ[0] explicitly states its approach is not coordinated disclosure:

> Prior to Project Zero our researchers had tried a number of different disclosure policies, such as coordinated vulnerability disclosure. Coordinated vulnerability disclosure is premised on the idea that any public disclosure prior to a fix being released unnecessarily exposes users to malicious attacks, and so the vendor should always set the time frame for disclosure.

It seems to me that if “responsible disclosure” is problematic for the reasons you’ve mentioned, “coordinated disclosure” is too. Actually, it’s maybe even worse, since “the researcher refused to coordinate with us on the deadline” is objectively true, whereas “the researcher didn’t disclose this vulnerability responsibly” is totally subjective.

As I said in https://news.ycombinator.com/item?id=22407821 I don’t like the phrase “responsible disclosure”, especially given its history, but “coordinated disclosure” doesn’t seem to do any better at being a phrase that can’t be weaponised against researchers. It also has the downside of meaning different things to different people within infosec which makes it unreasonably hard to communicate effectively and concisely.

So, you know, anyone reading this with high stature in infosec, please coin something unambiguously unique (“time-gated disclosure”?) so less time can be spent talking about semantics and more time can be spent on how to improve software security for everyone. :-)

[0] https://googleprojectzero.blogspot.com/p/vulnerability-discl...

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

#317

Post by tptacek »

csnover wrote: post #316
tptacek wrote: post #312

Earlier quoted context omitted.

It is in fact "coordinated disclosure".

Even when the disclosure is not actually coordinated, in the common sense of the word, because the vendor doesn’t agree to the deadline and/or isn’t given any option to pick a longer deadline? Edit: The Google Project Zero FAQ[0] explicitly states its approach is not coordinated disclosure: > Prior to Project Zero our researchers had tried a number of different disclosure policies, such as coordinated vulnerability d…

I don't know what else to tell you. "Responsible Disclosure" was literally a coercive marketing strategy cooked up by vendors; it isn't a term we arrived at organically. Don't use that term. Use any other term you like, but the convention in the field is "coordinated disclosure".

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

#318

Post by harikb »

dinkydrew wrote: post #86
harikb wrote: post #57

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

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

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.

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

#319

Post by tzs »

hoistbypetard wrote: post #263
rideontime wrote: post #59

Earlier quoted context omitted.

I was about to dismiss the article thanks to lines like this: > In essence, it would work with phished credentials just as well as with stolen ones But, sure enough, it's not the opt-in 2FA, triggered on every login, that was bypassed, but the 2FA checks triggered when PayPal detects suspicious activity. As far as I can tell, if you've enabled 2FA yourself, this bypass won't work. Thanks for the link! Going to go mak…

I went to enable the opt-in 2FA in response to this report. It's pretty rough, IMO. It gives you no way to use scratch codes as a backup. You're stuck with either adding a second TOTP device or allowing SMS as a backup. Adding a second TOTP device is OK security-wise but adding a second device to my safe and making sure it's still working periodically kind of sucks. SMS is not OK. Printed scratch codes would beat the…

You can make a backup by saving in some safe place a copy of the QR code and/or the 16 character text code Paypal gives you to set up your TOTP device.

You can then use that later to set up a replacement TOTP device if something happens to your first one.

I usually use "grab" on my Mac to save a copy of the QR code as a PNG, encrypt that, and save it in an offsite location.

Another popular approach is to print the QR code and save the printout in a fireproof sale. If you do that, I recommend printing it before you use it to set up your first device, and then set up the first device from the printed code just to make sure the printed code is fine.

If you save the text code, you can also use that with oathtool from oath-toolkit [1] to generate the TOTP code on the command line if you need to use Paypal before you have your replacement TOTP device.

Note: if you do want to have two TOTP devices set up at the same time, there are two ways to do this with Paypal. One way is just to scan the same code in both devices. You can either set them both up at the same time, or add the second one later using the backup you made of the original code.

The other way is to go to Paypal's security settings and explicitly say you want to add a backup TOTP. It will then give you a QR code to scan. That is not the same code as it gave you for the first device. The codes generated from the second device initialized from that second code will not be the same as the codes from your first device.

I have no idea what the user interface is for logging in when you have two devices generating separate TOTP sequences. Does it expect you to use the first device, and if that fails ask you to try a backup? Or does it just accept codes from either? Or something else?

Offhand, I can't think of any compelling reason to prefer your two devices to have different codes, or for Paypal to need to know that you are using two devices. Just setting them up with the same code and letting them appear to the be the same device as far as Paypal is concerned seems simpler to me.

[1] https://www.nongnu.org/oath-toolkit/

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

#320

Post by thaumasiotes »

WUHANCLAN wrote: post #310
thaumasiotes wrote: post #256

Earlier quoted context omitted.

What would you expect HackerOne to do in the situation you describe? You filed a duplicate report. All of the malfeasance you allege is coming from Portswigger.

No idea which one it was, or both. 23K isn't something to sneeze at though, and would be plenty of incentive for the folk at Portswigger to work with douchebags like whoever this shubby dude is in order to collect these bounties. 24K for one bounty... or sell $299 licenses to nerds.. hmm, which one is more profitable...

...the second one is significantly more profitable.
Post reply on HN