Yesterday it was a Facebook web-based Elevation of Privilege bug found by a Laxman Muthiyah, a bug-bounty hunter in India.
Today, it’s a PayPal Cross Site Scripting (XSS) flaw from a resarcher in Germany called Ebrahim Hegazy.
Cross Site Scripting
First, a quick review of Cross Site Scripting.
Imagine that I want to get your website to serve up malicious content for me.
Say, perhaps, that I want to alter your “Pay Now” page so that the customer sees a credit card payment form that comes from you, looks legitimate, seems secure…
…but sends the form data back to me instead.
One way is to hack right into into your web server and modify your content delivery system.
Another way – a method that is generally much easier to pull off once you know how to do it – is to trick your website into “echoing back” data that I supplied remotely, but setting that data to be the malicious content I want to display.
Where to start?
Websites often take user-supplied content that arrives in a web request from outside, and use some or all of that content in their reply, for example during searches.
Suppose I search for “facetiously” by submitting a URL like this:
If that word doesn’t appear on your site, you might send back something like this:
But if I were a crook, I might search for something hostile instead, such as:
Whereupon your web server needs to be very careful not to reply with:
If you were to send that reply, you would effectively be publishing my script as a trusted part of your site, even though you’d never seen the script before in your life, let alone passed it through code review, testing and quality assurance.
Worse still, if a customer should complain about the malicious content, you wouldn’t be able find it your web content delivery system, because it was squirrelled in from outside at runtime.
A flaw of this sort is not in your content, it’s in your programming, notably how strictly you sanitise user-supplied data before consuming it.
→ HTTP requests that include user-supplied data usually package it into the URL, typically following a question mark (“?”) as above, or use a special sort of request called a POST. In an HTTP POST, the user-supplied data is placed into the body of the request instead of the URL.
The PayPal XSS
Back to Ebrahim Hegazy, who goes by Zigoo0.
He hasn’t given details of the XSS he unravelled against PayPal, but according to his own description, the bug was in a CGI script that formed part of PayPal’s securepayments.paypal.com service.
CGI is short for Common Gateway Interface, and it is a standard way for web servers to take user-supplied data from a web request, and pass it into a back-end system for processing.
The output of the back-end server is then used to construct the HTTP reply that goes back to the user.
PayPal’s Secure Payments page produces a form on which a user normally enters details needed to complete a payment transaction, such as credit card long number, expiry date and short number (CVV2).
In other words, if crooks could subvert that form, they’d have a potential gold mine for cybercrime.
And that’s what Hegazy says he figured out how to do, using Cross Site Scripting.
He claims to be able to lead a user to a perfectly legitimate-looking PayPal Secure Payments page in which the payment form is configured to send the credit card data back to him, not onwards to PayPal’s own payment processing system.
What to do?
Fortunately, there’s no need to do anything.
Hegazy found the glitch back in June 2015, told PayPal, and waited until they’d told him the problem was fixed (and paid his bounty, of course!) before going public.
So this hole no longer exists and therefore cannot be exploited.
How much?
Hegazy didn’t reveal how much he was paid, but PayPal’s own Bounty Program page lists the payout for Cross Site Scripting (XSS) at a fixed fee of $750.
Ironically, the abovementioned Laxman Muthayiah of India trousered $2500 for his recent Facebook bug, even though it feels as though Ebrahim’s bug was rather more serious.
But payout rules are payout rules, and that’s how it goes.
At any rate, Hegazy was complimentary to PayPal:
Thanks, Paypal Security team for the good coordination, [and the] fast responses [to] emails.
In a word, “Result.”
4caster
This is how the system should work. People who seek and discover a vulnerability, and promptly report it to the owners of the system, should receive a bounty. It’s a pity the Pentagon (the one across the “pond”) doesn’t follow that procedure.
Paul Ducklin
Well, yes. But within a strict set of rules.
For example, most bounty programmes have clear rules that prohibit bounty claims where vulnerabilities were found in unethical (and, more importantly, potentially dangerous) ways. That’s why the United Airlines bounties explicity exclude “hacking on the plane,” and most bounty programmes exclude “research” that involves illegal activities, such as socially engineering passwords or deliberately probing live sites in a way that could affect availability or privacy for other users.
Analogy: if you noticed that the ‘stone chip protector’ cover over my 4×4 headlights (hyopthetical – I don’t have a 4×4) was loose and told me, I’d be quite pleased. But I’d be kind of cross if you proved it without asking permission by throwing a stone at the headlight and when it broke, saying, “Hey – guess what?”
Adam
Y’know, if you REALLY wanted to go for maximum alliteration, you could have titled the article “PayPal patches potential payment-pilfering problem”.
(Though “problem” wouldn’t be a very technically-accurate one-word description, I suppose.)