121–130 of 337 posts
Earlier quoted context omitted.
What is their certificate number?
> If PayPal’s PCI-DSS compliance certification isn’t revoked then PCI-DSS is a farce. This comment chain has convinced me that PCI-DSS is a farce.
Earlier quoted context omitted.
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.
So it’s pretty far fetched that they would be purposely delaying reports so they could steal the rewards.
> 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.
Earlier quoted context omitted.
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 bu…
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.
Earlier quoted context omitted.
Yes? If we want to be cynical, of course there was a self-serving reason they created the standards -- because fraud, especially "internet" fraud, was on a massive upswing and it threatened this enormous new market of credit card spending. There is no question it's in their self-interest to improve the general condition of transactions.
> If we want to be cynical, of course there was a self-serving reason they created the standards It's not cynical, it is literally the reason PCI exists. > Five different programs had been started by card companies... The intentions of each were roughly similar: to create an additional level of protection for card issuers - https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...
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 of course everything any business does is in their own self-interest. Of course it is -- that goes without saying, unless one is just trying to be glum.
Earlier quoted context omitted.
Squid is vastly under-equipped to deal with the security hygiene needed for a project this important. That's the tragedy of the open source world : mission critical for everyone, but no actor willing to maintain it properly. It's Heartbleed all over again.
I keep thinking we need some sort of new license for open source that limits which entities can use the software based on their net worth or the networth of their shareholders. That way large companies like Google can automatically fund these long tail of projects without burdening casual hackers or startups with unnecessary costs.
After a certain amount of time passes, the software reverts to an open source license of the author’s choosing:
https://mariadb.com/bsl-faq-adopting/
Example: use restricted to non-production use, reverts to GPLv2 in four years:
The clock protects users from lazy / out of business vendors. If few enough improvements have been made recently for it to make sense, the customers simply fork an old version of the project, and deploy that instead of paying for ongoing “development.”
(The business source license is not “open source”, but I think it is close enough to be a good compromise in practice)
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).
Earlier quoted context omitted.
I keep thinking we need some sort of new license for open source that limits which entities can use the software based on their net worth or the networth of their shareholders. That way large companies like Google can automatically fund these long tail of projects without burdening casual hackers or startups with unnecessary costs.
> I keep thinking we need some sort of new license for open source that limits which entities can use the software based on their net worth or the networth of their shareholders. That might be a new license, but it is by definition not open source. And, no, companies like Google won't “automatically” buy commercial software with that style of license; from their perspective it's worse than regular commercial software…
Earlier quoted context omitted.
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.
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…
Overall that may be being too pedantic, and shouldn't give PayPal a pass on the issue. Perhaps even entertaining it is just muddying the waters allowing PayPal to slip away. The extra check is a security check. If cybernews have by bypassed it then they have bypassed a security check. Logically this is therefore a security issue, and if PayPal are saying that it's not a security concern then they're saying that they were just wasting everybody's time with the unnecessary check to begin with. That would clearly be a lie, as the fact that they developed and continued to use the system indicate that they think it provides security.
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…
Earlier quoted context omitted.
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.
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.