PayPal Inc BB #74 - Persistent Core Backend Vulnerability

Type vulnerlab
Reporter Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri ( []
Modified 2014-06-03T00:00:00


                                            Document Title:
PayPal Inc BB #74 - Persistent Core Backend Vulnerability

References (Source):

PayPal Inc Security UID: cDc49dT

Vulnerability Magazine Article:


Release Date:

Vulnerability Laboratory ID (VL-ID):

Common Vulnerability Scoring System:

Product & Service Introduction:
PayPal is a global e-commerce business allowing payments and money transfers to be made through the Internet. Online money 
transfers serve as electronic alternatives to paying with traditional paper methods, such as checks and money orders. Originally, 
a PayPal account could be funded with an electronic debit from a bank account or by a credit card at the payer s choice. But some 
time in 2010 or early 2011, PayPal began to require a verified bank account after the account holder exceeded a predetermined 
spending limit. After that point, PayPal will attempt to take funds for a purchase from funding sources according to a specified 
funding hierarchy. If you set one of the funding sources as Primary, it will default to that, within that level of the hierarchy 
(for example, if your credit card ending in 4567 is set as the Primary over 1234, it will still attempt to pay money out of your 
PayPal balance, before it attempts to charge your credit card). The funding hierarchy is a balance in the PayPal account; a 
PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master Card or Bill Me Later (if selected as primary 
funding source) (It can bypass the Balance); a verified bank account; other funding sources, such as non-PayPal credit cards.
The recipient of a PayPal transfer can either request a check from PayPal, establish their own PayPal deposit account or request 
a transfer to their bank account.

PayPal is an acquirer, performing payment processing for online vendors, auction sites, and other commercial users, for which it 
charges a fee. It may also charge a fee for receiving money, proportional to the amount received. The fees depend on the currency 
used, the payment option used, the country of the sender, the country of the recipient, the amount sent and the recipient s account 
type. In addition, eBay purchases made by credit card through PayPal may incur extra fees if the buyer and seller use different currencies.

( Copy of the Homepage: ) [ ]

Abstract Advisory Information:
The Vulnerability Laboratory Research Team (Benjamin Kunz Mejri) discovered an application-side vulnerability in the official  PayPal Inc ethernet portal backend application (api).

Vulnerability Disclosure Timeline:
2013-02-12:	Researcher Notification & Coordination (Benjamin Kunz Mejri)
2013-02-12:	Vendor Notification (PayPal Inc Site Security Team - Bug Bounty Program)
2013-07-31:	Vendor Response/Feedback (PayPal Inc Site Security Team - Bug Bounty Program)
2013-07-31:	Vendor Fix/Patch (PayPal Inc - Developer Team - Reward: 750$)
2014-02-14:	Notification about last Payment to Laboratory (PayPal Inc Site Security Team - Bug Bounty Program)
2014-06-04	Public Disclosure (Vulnerability Laboratory)

Discovery Status:

Affected Product(s):
PayPal Inc
Product: Core Application 2014 Q2

Exploitation Technique:

Severity Level:

Technical Details & Description:
An application-side validation web vulnerability and a filter bypass has been discovered in the official  PayPal Inc ethernet portal backend application (api).
The filter bypass allows remote attackers to evade the regular parse and encode filter mechanism of the paypal inc online-service portal web-application.
The persistent input validation vulnerability allows remote attackers to inject own malicious script codes on the application-side of the vulnerable service.

In a reverse analysis after several legal testings against the paypal inc infrastructure, we came to decision to test a new kind of scenario against the service api.
Our team tried to blind evade and bypass the online service filter validation of the backend listings with main values of the profile. Means whenever a moderator
or admin is watching the profile of the paypal inc db listed user in the ethernet, the persistent injected code executes. In the attack scenario we injected malicious 
test codes with scripts in the most attractive values of the paypal user profile database -> `bank account owner/holder (cardholder)`, `name/surname`, `companyname` 
and of course the `account owner`. In the morning (2013-02-12) paypal responded with the following mail to us (review poc). 

The security risk of the application-side validation vulnerability in the security card system module is estimated as critical with a cvss (common vulnerability 
scoring system) count of 8.9. Exploitation of the application-side remote web validation vulnerability requires a low privileged paypal account with restricted access 
and no user interaction. Successful exploitation of the vulnerability results in session hijacking, account database compromise, dev/admin account compromise, external 
redirects and persistent manipulation of affected or connected module context.

Request Method(s):
				[+] POST

Vulnerable Parameter(s):
				[+] Bank Account Owner
				[+] Name and Surname
				[+] Companyname
				[+] Account Owner

Affected Module(s):
				[+] PayPal Inc - Ethernet Backend Portal (User Profile Listing)

Proof of Concept (PoC):
The application-side vulnerability and filter bypass can be exploited by remote attackers with a low privileged paypal inc account with restricted access 
and no direkt admin/moderator user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and 
steps below to continue.

1. I included script code to main values which are saved and could be displayed in the admin or moderator section
Note: A moderator or admin only view important main customer details like compaynames, owners and co.
2. I came to the decision to use the (lucky choosen) values account owner, address, companyname and bank account owner.
3. A mathematic analysis showed me that it must be possible in any way for you guys to watch this values when updating or editing data
Note: A reserve tip came up to me 5 days ago when the women at the support phone was helping me to reset my account and can't read my data. Now i understand :)
4. Then i implemented the vulnerable values saved them in the main profile and after some month i changed them with the new business account
Note: Some of the context is stable saved even if not visible for the user because after the update the context must normally be updated or deleted
5. I was still waiting since one of paypal moderators or admins confirm the issue by watching the blind injected context in the backend application
6. Result was the following mail today after my seperate tests > 
7. Successful reproduced!

--- Copy of Mail by PayPal Inc (2013-02-12) ---
Sender: 	PayPal Site Security <>
Topic: 		[secure] Profile

We have discovered that there is an script that had been associated with your profile.  We see a message that says "Hi" when 
we view your profile internally.  Our group doesn't have direct access to this portal.  Can you think of some testing you might 
have performed where you saved payload in your profile description?  Is this from a vulnerability that you have already submitted?


Solution - Fix & Patch:
The vulnerability can be patched by a secure parse and encode of the vulnerable account profile values. Encode the user inputs of the cardholder and fristname profile 
values to prevent persistent script code executions.
Restrict the input of the vulnerable values by a filter mechanism and disallow special chars as user input.

Affected Input(s):
				[+] Bank Account Owner
				[+] Name and Surname
				[+] Companyname
				[+] Account Owner

Security Risk:
The security risk of the application-side vulnerability in the ethernet portal backend module is estimated as critical.  Attackers are able to hijack sessions of 
internal (ethernet) developers/admins accounts, execute persistent codes in the backend portal next to the important db user profile section or can compromise the view and db entries 
of the affected vulnerable values to provide the manipulated details to the frontend.

Credits & Authors:
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri ( []

Disclaimer & Information:
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either 
expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers 
are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even 
if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation 
of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break 
any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material.

Domains:   	-			       		-
Contact: 	- 	       		-
Section:	 	- 		       		-
Social:!/vuln_lab 		- 	       		-
Feeds:	-   		-
Programs:  	-	-

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to 
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by 
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website 
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact 
( or to get a permission.

				Copyright © 2014 | Vulnerability Laboratory [Evolution Security]