XSS Flaw on PayPal.com

Earlier today Wesley Kerfoot reported on the Full Disclosure mailing list that a page in the Paypal.com domain is susceptible to a non-persistent reflected cross site scripting attack (XSS). While non-persistent XSS bugs are somewhat common, this is quite serious for a site like PayPal, where user accounts are linked directly to bank accounts, debit, or credit cards and payment can be made to third parties without any additional authentication after user access is gained.

Update: As of 7pm EST, it appears that a mitigation has been implemented for this vulnerability on the PayPal web site where all requests to /xclick/business redirect to the PayPal homepage.

An attacker able to trick a user with a valid Paypal session into clicking a crafted version of the link below (wouldn’t be hard, think a link on an eBay auction listing or a phishing e-mail for example) could hijack the user’s session and initiate financial transactions on their behalf including money transfers. Alternatively this legitimate URL could be used to redirect the user to a spoofed PayPal web site designed to steal user credentials, which is a fairly common scam except in this case more effective as the user would see an actual PayPal URL to click on.

Attack String
The following string is provided as example in the Full Disclosure posting:

https://www.paypal.com/xclick/business=<script> XSS PAYLOAD </script>

Which in turn results in this:

Of course where this works, this will just as easily work:

https://www.paypal.com/xclick/business=<script> alert(document.cookie); </script>

Which dutifully reflects back wrapped in a header tag on the resulting page:

<div class="legacyErrors " id="page">
<div id="header"><h1><script> alert(document.cookie); </script></h1></div>
<hr>
<div id="content">
<div id="headline">

And finally which displays the user’s logged in session information:

Rather then displaying the cookies, the attacker would redirect the information to another web site, set them locally as his session, and begin to initiate transactions on the part of the user. This is only one example, since Javascript can be executed in the context of the PayPal web site, the attacker could write a script to do just about any action on the site that is possible using Javascript, Flash, etc.. Site redirects, iFrame injection, and even other injection flaws are possible on a web page that does not validate untrusted input.

XSS at a High Level
While the definition is ever expanding, XSS attacks are generally considered a type of injection problem where malicious input is injected into an otherwise trusted web page causing an unexpected behavior such as sending data to or from an unknown third party web site (cross site). Because the script is being run in the context of the trusted web site, it has access to cookies such as session tokens, as well as any other user information available within the security context of that web site. XSS vulnerabilities are somewhat common in web applications and will occur unfettered wherever untrusted input is not validated by the web application or encoded before output back to the user.

PayPal
The San Jose based company is owned by eBay and has more than 78 million customer accounts. As such the service is used to clear many of the transactions on the popular auction site. The service allows users to send money without needing to share financial information, a key enabler for sending and receiving money from third parties on the Internet. They are in some 190 markets around the world and can work with 19 different currencies.

In 2008 roughly $60 billion dollars moved through Paypal’s systems.

Paypal does make available additional authentication protection in the form of a one time password token called a ‘security key’ by them (similar to the ones made popular by RSA). The token costs five dollars and is available to residents of Australia, Germany, Canada, the United Kingdom and the United States. Paypal however allows a bypass of this hard token by allowing the user to enter further information such as credit card or bank number, severely impacting its effectiveness as a security measure.

Further authentication “on the front door” of the web site (the login screen) does not prevent a user session from being hijacked after authentication as is possible in a cross site scripting attack like this one.
PCI Compliance

Of note is that PayPal does claim PCI compliance, involving the following activities in their words:

• Maintain a vulnerability management program
• Pass quarterly remove vulnerability scans

The wording on that second bullet from the PayPal site is a little strange, we assume it means to pass vulnerability scans that validate whether earlier problems identified by previous scans were removed.

The attack string above is basic enough that it would or should be tested and picked up as a vulnerability by the most rudimentary web scanners available, throwing the validity of any scanning being done into question. Actual credit card data is displayed in an obfusticated manner on the Profile section of the web site (only the last four digits show up on the site), so the site may be considered out of scope of a PCI required scan?

The digital certificate of the scanalert.com URL, a redirect to the McAfee service PayPal provides to its business customers at no cost for a year, has a bad digital certificate.

Finally
Generally users can apply for refunds from PayPal when an account has been broken into, but like any other service there are a share of horror stories. In general a site such as this should escape all output that originates from untrusted sources, with the variety of possible attack strings this is not full proof but is a significant mitigation against injection attacks. This is not PayPal’s first brush with this problem, last year a similar issue was identified by Harry Sintonen. As PayPal is, for many users of eBay and other online services, the only payment game in town (the only one which a seller will use to collect payment) this type of issue needs to be corrected fairly quickly in a comprehensive manner (a site wide change to introduce web vulnerability scanning, escape all user provided input when outputted, and/or validation of all user provided input ideally).

References

• Full Disclosure – Paypal XSS Vulnerability: http://seclists.org/fulldisclosure/2010/Mar/486

Tags: PayPal, XSS