Vulnerabilities we discovered
In our analysis of PayPal’s mobile apps and website UI, we were able to uncover a series of significant issues. We’ll explain these vulnerabilities from the most severe to least severe, as well as how each vulnerability can lead to serious issues for the end-user.

Using the current version of PayPal for Android (v. 7.16.1), the CyberNews research team was able to bypass PayPal’s phone or email verification, which for ease of terminology we can call two-factor authentication (2FA). Their 2FA, which is called “Authflow” on PayPal, is normally triggered when a user logs into their account from a new device, location, or IP address.

How we did it

This means that attackers can gain easy access to accounts, rendering PayPal’s lauded security system useless.
What’s the worst-case scenario here?
Stolen PayPal credentials can go for just $xx.xx on the black market. Essentially, it’s exactly because it’s so difficult to get into people’s PayPal accounts with stolen credentials that these stolen credentials are so cheap. PayPal’s auth flow is set up to detect and block suspicious login attempts, usually related to a new device or IP, besides other suspicious actions.

But with our 2FA bypass, that security measure is null and void. Hackers can buy stolen credentials in bulk, log in with those credentials, bypass 2FA in minutes, and have complete access to those accounts. With many known and unknown stolen credentials on the market, this is potentially a huge loss for many PayPal customers.
PayPal’s response
We’ll assume that HackerOne’s response is representative of PayPal’s response. For this issue, PayPal decided that, since the user’s account must already be compromised for this attack to work, “there does not appear to be any security implications as a direct result of this behavior.”

costing us 5 reputation points in the process.
#2 Phone verification without OTP
Our analysts discovered that it’s pretty easy to confirm a new phone without an OTP (One-Time Pin). PayPal recently introduced a new system where it checks whether a phone number is registered under the same name as the account holder. If not, it rejects the phone number.

When a user registers a new phone number, an onboard call is made to api-m.paypal.com, which sends the status of the phone confirmation. We can easily change this call, and PayPal will then register the phone as confirmed.

The call can be repeated on already registered accounts to verify the phone.
What’s the worst-case scenario here?
Scammers can find lots of uses for this vulnerability, but the major implication is unmissable. By bypassing this phone verification, it will make it much easier for scammers to create fraudulent accounts, especially since there’s no need to receive an SMS verification code.

PayPal’s response

Initially, the PayPal team via HackerOne took this issue more seriously. However, after a few exchanges, they stopped responding to our queries, and recently PayPal itself (not the HackerOne staff) locked this report, meaning that we aren’t able to comment any longer.

PayPal has set up certain security measures in order to help avoid fraud and other malicious actions on the tool. One of these is a security measure that’s triggered when one of the following conditions, or a combination of these, is met:

• You’re using a new device
• You’re trying to send payments from a different location or IP address
• There’s a change in your usual sending pattern
• The owning account is not “aged” well (meaning that it’s pretty new)

When these conditions are met, PayPal may throw up a few types of errors to the users, including:

• “You’ll need to link a new payment method to send the money”
• “Your payment was denied, please try again later”

How we did it

Our analysts found that PayPal’s sending money security block is vulnerable to brute force attacks.
What’s the worst-case scenario here?
This is similar in impact to Vulnerability #1 mentioned above. An attacker with access to stolen PayPal credentials can access these accounts after easily bypassing PayPal’s security measures.

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.
#4 Full name change
By default, PayPal allows users to only change 1-2 letters of their name once (usually because of typos). After that, the option to update your name disappears.
However, using the current version of PayPal.com, the CyberNews research team was able to change a test account’s name from “Tester IAmTester” to “Christin Christina”.

How we did it

We discovered that if we capture the requests and repeat them every time by changing 1-2 letters at a time, we are able to fully change account names to something completely different, without any verification.
We also discovered that we can use any Unicode symbols, including emojis, in the name field.
What’s the worst-case scenario here?

An attacker, armed with stolen PayPal credentials, can change the account holder’s name. Once they’ve completely taken over an account, the real account holder wouldn’t be able to claim that account, since the name has been changed and their official documents would be of no assistance.
PayPal’s response
This issue was deemed a Duplicate by PayPal since it had been apparently discovered by another researcher.

PayPal’s self-help chat, which it calls SmartChat, lets users find answers to the most common questions. Our research discovered that this SmartChat integration is missing crucial form validation that checks the text that a person writes.

How we did it

PayPal’s response

The same day that we informed PayPal of this issue, they replied that since it isn’t “exploitable externally,” it is a non-issue. However, while we planned to send them a full POC (proof of concept), PayPal seems to have removed the file on which the exploit was based. This indicates that they were not honest with us and patched the problem quietly themselves, providing us with no credit, thanks, or bounty. Instead, they closed this as Not Applicable, costing us another 5 points in the process.

This vulnerability is similar to the one above (#5), since PayPal does not sanitize its Security Questions input.
How we did it
Because PayPal’s Security Questions input box is not validated properly, we were able to use the MITM method described above.
Here is a screenshot that shows our test code being injected to the account after refresh, resulting in a massive clickable link:

Attackers can inject scripts into other people’s accounts to grab sensitive data. By using Vulnerability #1 and logging into a user’s account, a scammer can inject code that can later run on any computer once a victim logs into their account.
This includes:

• Showing a fake pop-up that could say “Download the new PayPal app” which could actually be malware.
• Changing the text user is adding. For example, the scammer can alter the email where the money is being sent.
• Keylogging credit card information when the user inputs it.

There are many more ways to use this vulnerability and, like all of these exploits, it’s only limited by the scammer’s imagination.
PayPal’s response
The same day we reported this issue, PayPal responded that it had already been reported. Also on the same day, the vulnerability seems to have been patched on PayPal’s side. They deemed this issue a Duplicate, and we lost another 5 points.
PayPal’s reputation for dishonesty

end of criticism for not honoring its own bug bounty program.
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

the hacker was just too young.

Another researcher earlier discovered that attempting to communicate serious vulnerabilities in PayPal’s software led to long delays. In the end, and frustrated, the researcher promises to never waste his time with PayPal again.
There’s also the case of another teenager, Joshua Rogers, also 17 at the time, who said that he was able to easily bypass PayPal’s 2FA. He went on to state, however, that PayPal didn’t respond after multiple attempts at communicating the issue with them.
PayPal acknowledged and downplayed the vulnerability, later patching it, without offering any thanks to Rogers.
The big problem with HackerOne

HackerOne is often hailed as a godsend for ethical hackers, allowing companies to get novel ways to patch up their tools, and allowing hackers to get paid for finding those vulnerabilities.
It’s certainly the most popular, especially since big names like PayPal work exclusively with the platform. There have been issues with HackerOne’s response, including the huge scandal involving Valve, when a researcher was banned from HackerOne after trying to report a Steam zero-day.
However, its Triage system, which is often seen as an innovation, actually has a serious problem. The way that HackerOne’s triage system works is simple: instead of bothering the vendor (HackerOne’s customer) with each reported vulnerability,

they’ve set up a system where HackerOne Security Analysts will quickly check and categorize each reported issue and escalate or close the issues as needed. This is similar to the triage system in hospitals.

These Security Analysts are able to identify the problem, try to replicate it, and communicate with the vendor to work on a fix. However, there’s one big flaw here: these Security Analysts are also active Bug Bounty Hackers.
Essentially, these Security Analysts get first dibs on reported vulnerabilities. They have full discretion on the type of severity of the issue, and they have the power to escalate, delay or close the issue.

That presents a huge opportunity for them if they act in bad faith. Other criticisms have pointed out that Security Analysts can first delay the reported vulnerability, and report it themselves on a different

bug bounty platform, collect the bounty (without disclosing it of course), and then close the reported issue as Not Applicable, or perhaps Duplicate.

As such, the system is ripe for abuse, especially since Security Analysts on HackerOne use generic usernames, meaning that there’s no real way of knowing what they are doing on other bug bounty platforms.
What it all means
All in all, the exact “Who is to blame” question is left unanswered at this point because it is overshadowed by another bigger question: why are these services so irresponsible?
Let’s point out a simple combination of vulnerabilities that any malicious actor can use:

1. Buy PayPal accounts on the black market for pennies on the dollar. (On this .onion website, you can buy a $5,000 PayPal account for just $150, giving you a 3,333% ROI.)
2. Use Vulnerability #1 to bypass the two-factor authentication easily.
3. Use Vulnerability #3 to bypass the sending money security and easily send money from the linked bank accounts and cards.

#1 to bypass 2FA and then use Vulnerability #4 to change the account holder’s name. That way, the scammer can lock the original owner out of their own account.
While these are just two simple ways to use our discovered vulnerabilities, scammers – who have much more motivation and creativity for maliciousness (as well as a penchant for scalable attacks) – will most likely have many more ways to use these exploits.
And yet, to PayPal and HackerOne, these are non-issues. Even worse, it seems that you’ll just get punished for reporting it.