[thelist] HTML email "bug", of sorts.

Jim jimmi at u.washington.edu
Thu Aug 23 21:29:17 CDT 2001


Just FYI. Potential problem (or asset) with HTML email clients. If you are
looking for an alternative to your existing client there is always Pine
(www.washington.edu/pine/).

<tip>Illustrator 9 can output to gif and jpeg so it is a great vector
based application to consider for quick output of mockups, image prepping,
and web typography as image (and it continues to output to pdf).</tip>

<tip>if you need a great editor free of charge that runs on Mac, UNIX,
Windows consider Vim: www.vim.org features include color coding, regular
expressions</tip>

-Jim

---------- Forwarded message ----------

This thread is a bit long, but has some interesting information in it
regarding creative exploitation of HTML enabled email "features" for
doing things that a user doesn't otherwise know are happening.
(I had no idea that you could track spam recipients using this
technique, but then I use Pine so it doesn't affect me.)

Yet another reason to *not* push people into using these features
when designing web services (so people can actually opt out of
exposing themselves to these "features".)

---------- Forwarded message ----------
Date: Sat, 18 Aug 2001 06:17:25 -0400 (EDT)
Subject: HTML email "bug", of sorts.

I'm not sure this is the proper forum for "conspiracy-theory" bugs, but I
figured this would be of interest to anyone trying to prevent the names of
valid email accounts they either own or administer from being verified and
added to "official" known-good spam rosters.

You may have heard of "web-bugs" before.  Or you may not have.  For the
benefit of the less-experienced, here's what they are and what they do:

"Web bugs" are small, 1x1 (or similar-sized) transparent GIF images which
can be used to track the movement of a user around the web.  About 1 in 10
sites use them.  Their effectiveness at this task is somewhat
questionable, but they can be used more effectively for a different task:

I've started noticing something very disturbing in the HTML in spam mails
recently.  I've started seeing web bugs.  Below is an example from a
recent email:

<img
src="http://www.megahardcoresex.com/sites/XXXXXXXX0 (continued)
3b/sf03b08152001.gif?M=XXXXXXXXX&ID=wakko at bitey.net" width="1" height="1">

See it?  A web bug.  If I opened this mail in an HTML-capable browser,
that little image would've popped up and I would've been none the
wiser.  My address would also have been verified by the sender, and stored
in a large database of valid recipients.

So, anyone have any idea of how to deal with this latest little spammer
toy?  Is there any effective way to filter out web bugs without adversely
affecting the delivery intact of legitimate messages?  Could software
change to at least warn viewers that this HTML viewer is accessing offsite
content?  Is it worth doing?

Anyone?  Bueller?

- A.P.



---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 21:20:55 -0700

>You may have heard of "web-bugs" before.

Never by that term, but what you're describing has been around for no less
than FIVE YEARS - almost as long as HTML-enabled email.  The tracking
technique is certainly not new.  I used to hear of them as
"dot-trackers".  A search just now on "web bug" reveals that some people
are now calling them by that name, and the following document may be of
interest:

         <http://www.bugnosis.org/faq.html>


If you had a decent email client (oh, let's say Eudora Pro), there are
features to disable the automatic fetching of linked HTML components (i.e.
view the mail as just the HTML you already have, as well as graphics
embedded within the message as attachments, but not go online to fetch
anything).

Ironically, there's a valid use for them -- listservs and opt-in marketing
propaganda could send a welcome message using a dot-tracker, and if the
corresponding identifier is hit on the server, you know the user has a
fully HTML-enabled email client, and can then update their profile to use
HTML.  If you don't get hit, you send plaintext.  Not that I've heard of
anyone actually using it for this, but it would be nice if companies did
instead of automatically dumping HTML mail on you.

>"Web bugs" are small, 1x1 (or similar-sized) transparent GIF images

aka "transpixel GIF".

>About 1 in 10 sites use them.

I suspect more _real_ (non personal homepage oriented ones) sites use
transpixel gifs -- they're frequently used for image alignment.  Other
sites that track users simply have adbanners all over the place - same
thing, and most users are oblivious to the fact that those adbanners ARE
tracking you.  One of the various reasons I run a (homebrew) proxy script
to eliminate adbanners (others are that printouts are cleaner, the page is
less cluttered, less needless animation, and more efficient use of
bandwidth and client browser cacheing).

>So, anyone have any idea of how to deal with this latest little spammer
>toy?

Disable downloading of images in HTML email or disable HTML rendering entirely.

Another time-proven method is to filter SPAM from your mailbox, using the
so many other characteristics which identify most of the spam out
there.  You should also aggressively protect your email address.

Methinks with a decent email client, it would be easy enough to search
message bodies for your email address within links (note that listservs
that afford an uns*bscribe link would make this difficult, and of course
coded URLs wouldn't be matched), or for 'width="1"', 'height="1"' type
elements and flag these messages as _suspicious_ (procmail, which runs on
unix boxes is an excellent mail filtering utility, but such an option isn't
available to everyone).  Doing such filtering AFTER "known clean" sources
would significantly reduce misidentified messages - even my own spam
filtering has a "green list" of senders and mailing lists which are not as
aggressively filtered as those of unknown origin -- virtually anything left
in my inbox (not specifically dropped into a folder) is spam these days,
and that number is very small with RBL and spam filtering heuristics
running on the server.


---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395





---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 09:30:47 +0100
Subject: RE: HTML email "bug", of sorts.

> <img
> src="http://www.megahardcoresex.com/sites/XXXXXXXX0 (continued)
> 3b/sf03b08152001.gif?M=XXXXXXXXX&ID=wakko at bitey.net"
> width="1" height="1">

Ok, this has me scared now....

> So, anyone have any idea of how to deal with this latest
> little spammer
> toy?  Is there any effective way to filter out web bugs
> without adversely
> affecting the delivery intact of legitimate messages?
> Could software
> change to at least warn viewers that this HTML viewer is
> accessing offsite
> content?  Is it worth doing?

Well, the problem that many people will have with these sorts
of e-mails is known in the trade as Microsoft Outlook. What
really scares me is that *simply clicking* on such an e-mail
in Outlook, loading it up in the AutoPreview page, which many
people regard as "safe" (scripts aren't allowed to run in it),
will cause the bug to be loaded and your address to be verified.

The most scary bit is that I don't think there is any way to
disable remotely-loaded images in Outlook. True, you can choose
which Internet Explorer Security Zone recieved messages fit into,
but I don't think that even the "Restricted Sites" zone disables
off-site image loading (I'll have to check on that one, the help
isn't very clear).

So, where does that leave a user? In Outlook, you can't tell if
an e-mail is HTML without viewing it in the preview pane, in
which case you've already confirmed your existence to spammers.
You can't report the spam using such services as SpamCop unless
you actually open the e-mail to get the source. Now you're
gambling. Staring at this spam, betting as to whether it's html
or text. But to *delete* the thing immediately, you need to
select it, and in selecting it, you are loading it into the
preview pane.

I've turned off my preview pane to start with. And I think a
script which warns you of (or preferably deletes) HTML e-mails
before they are loaded needs developing.





---------- Forwarded message ----------
Date: Sat, 18 Aug 2001 21:40:05 -0700 (PDT)
Subject: Re: HTML email "bug", of sorts.

On Sat, 18 Aug 2001, Alex Prestin wrote:

> <DEFANGED_IMG
> src="http://www.megahardcoresex.com/sites/XXXXXXXX0 (continued)
> 3b/sf03b08152001.gif?M=XXXXXXXXX&ID=wakko at bitey.net" width="1" height="1">
>
> See it?  A web bug.  If I opened this mail in an HTML-capable
> browser, that little image would've popped up and I would've been
> none the wiser.  My address would also have been verified by the
> sender, and stored in a large database of valid recipients.

This is well-known. BGSOUND tags are also vulnerable to misuse in this
manner.

> So, anyone have any idea of how to deal with this latest little
> spammer toy?  Is there any effective way to filter out web bugs
> without adversely affecting the delivery intact of legitimate
> messages?

http://www.impsec.org/email-tools/procmail-security.html

(If you're running a procmail-capable mail server.)

Looking at the tag above shows you what it does...

--
 John Hardin KA7OHZ   ICQ#15735746   http://www.wolfenet.com/~jhardin/




---------- Forwarded message ----------
Date: Sat, 18 Aug 2001 23:10:36 -0400
Subject: Re: HTML email "bug", of sorts.

Alex Prestin wrote:
snip
> See it?  A web bug.  If I opened this mail in an HTML-capable browser,
> that little image would've popped up and I would've been none the
> wiser.  My address would also have been verified by the sender, and stored
> in a large database of valid recipients.

snip

And if you were running WinNT 4 and that referrer pointed to a server
advertising a share, NT would send your username and password to try to log
you on without your knowledge. It could be grabbed and sent back to your
machine, logon, and the atttacker would have all rights to your machince and
network that the ID you're using has.
(as I've mentioned before, MS has known about this hole since before SP2)
Cheers

Thomas Rowe
Systems Engineer, LDI
Bank of America
Atlanta, GA





---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 18:25:50 +0100
Subject: Re: HTML email "bug", of sorts.

AP> See it? A web bug. If I opened this mail in an HTML-capable
AP> browser, that little image would've popped up and I would've been
AP> none the wiser.

I believe the HTML capability of (the excellent imho) "The Bat!" mail
client for MS-Win simply doesn't do remote fetch of such things, IIRC.

Hope this helps anyone searching for such a mail client. It did me :)




---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 16:05:01 -0400
Subject: Re: HTML email "bug", of sorts.


     I've used this in the past to track someone who was reading a
co-workers e-mail to his detriment.
I setup a website called SnoopAlarm.com ( which is not open for public use
yet ) that would record all
of the information about a person running a CGI program that issued a
Content-Type: image/gif.  I then
sent my co-worker an e-mail with the 'image' CGI included.  When the person
read his mail the CGI
program allowed the snooper to see an image, while the CGI sent a pager
alert to the campus police
where the crime was taking place.

---
James Kelley
(502)767-4024
1205-203 Winter Springs Court
Louisville, KY 40243



---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 13:31:03 -0500
Subject: Re: HTML email "bug", of sorts.

> So, anyone have any idea of how to deal with this latest little spammer
> toy?  Is there any effective way to filter out web bugs without adversely
> affecting the delivery intact of legitimate messages?  Could software
> change to at least warn viewers that this HTML viewer is accessing offsite
> content?  Is it worth doing?

Hmm... I found a way to prevent image bugs/trackers from loading in Outlook
Express.

If you add your favorite mail server(s) to ZoneAlarm's "local network"
hosts, then disable Outlook's ability to access the Internet (but leave
intact Outlook's permission to access the "local network"), then mail can be
received, but foreign images cannot load.

Of course, this affects ALL images in ALL e-mail, but you asked for 'any
idea' on how to prevent this. :-)

BTW: The more I use ZoneAlarm, the more I like it.
http://www.zonealarm.com/
(No, I don't work for them.)

Daryl Banttari
Author, "Daryl's TCP/IP Primer"
http://www.ipprimer.com/




---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 16:19:12 -0400 (EDT)
Subject: Re: HTML email "bug", of sorts.

On Sun, 19 Aug 2001, David F. Skoll wrote:

> Use a non-HTML mail browser.  Also, write a script to call that URL with
> thousands of bogus e-mail addresses to poison the spammer's database.


A lot of people have been suggesting this (and it's something I personally
already do), but this doesn't help people who use and prefer HTML-capable
clients.  Yes, HTML email is the scourge of the Internet and should be
banned in my opinion, but the fact of the matter is that more people have
it enabled now than not, and the cute little cards and pictures their
friends, family, and coworkers send them on personalized
"letterhead" isn't going to be convinced (and might not even be able to be
taught how) to turn off HTML.

What I was more interested in finding out is how admins and people who
*are* technically adept can filter these types of things out on a massive
scale (on their mailservers, for example) *without* affecting the delivery
of legitimate mail.  The problems I see with this approach are:

1) how do you determine what's legitimate HTML email and what isn't?  Can
pattern-matching of web bugs be as easy as "*.gif\?.*" or something
similar?

2) where is this type of filter ethically the right thing to do?  on a
server at work?  (I would think "yes".)   What if you work at an ISP?  (I
would be less inclined to think "yes" if I might somehow be restricting
the experience of paying customers.)

Opt-out mail filtering might be a workable solution for those users not
wishing their emails to be tampered with in any way, as long as they know
the ramifications of that decision.

- A.P.




---------- Forwarded message ----------
Date: 19 Aug 2001 15:15:06 +0100
Subject: Re: HTML email "bug", of sorts.

On 18 Aug 2001 06:17:25 -0400, Alex Prestin wrote:

> I'm not sure this is the proper forum for "conspiracy-theory" bugs

It's not conspiracy, merely exploitation of badly designed MUAs.
Consider for a moment whether the "spammer" is really the faulty party
here - they're merely taking advantage of your HTML mail client.

Besides, everyone knows HTML mail is evil anyway :)

> <img
> src="http://www.megahardcoresex.com/sites/XXXXXXXX0 (continued)
> 3b/sf03b08152001.gif?M=XXXXXXXXX&ID=wakko at bitey.net" width="1" height="1">
>
> See it?  A web bug.  If I opened this mail in an HTML-capable browser,
> that little image would've popped up and I would've been none the
> wiser.

That's not true. Had you opened that mail with a dumb HTML-capable mail
client then you would probably have just verified your address with the
spammer. However there are clients which will not display images unless
you issue an instruction for that to occur (I'm playing with evolution,
it is one such client however there are others) and then there are
non-HTML clients which don't have this problem at all.

In short, there are plenty of alternatives around so if you don't like
this behaviour, change your mail client or look for image settings you
can alter.

> So, anyone have any idea of how to deal with this latest little spammer
> toy?

I've seen these appearing for a while now but I mostly ignore them on
the grounds that I don't load their little "web bugs" (can someone
please invent a better term?) and they can readily obtain a valid
address for me anyway.

--jcm





---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 16:49:27 -0700
Subject: Re: HTML email "bug", of sorts.

> (as I've mentioned before, MS has known about this hole since before SP2)
> Cheers

... as have the rest of us.

I would not call NTLMSSP's behavior a "hole."  It's just doing its job.
Properly configured firewalls block 139/445 at the interface where packets
are routed to public/untrusted networks.  You have brought this up a couple
of times here, but I'm not really sure what you are on about.  This is
expected, by-design behavior.

While I can conceptualize a configuration where each workstation has a table
of addresses from which to identify possible hosts to authenticate to (an
NTLM LAT if you will), I prefer to save the cycles and have this addressed
where it belongs- at the border (or as close to home as necessary).  People
constantly bash Microsoft for not having a "real" operating system, yet
demand to have each potential security issue addressed in the OS itself-
something that would take control further and further away from the admin.

That is the skinny on that.
---------------------------------
Attonbitus Deus








---------- Forwarded message ----------
Date: Sat, 18 Aug 2001 20:30:04 -0700 (PDT)
Subject: Re: HTML email "bug", of sorts.

On Sat, 18 Aug 2001, Alex Prestin wrote:

> So, anyone have any idea of how to deal with this latest little spammer
> toy?  Is there any effective way to filter out web bugs without adversely
> affecting the delivery intact of legitimate messages?  Could software
> change to at least warn viewers that this HTML viewer is accessing offsite
> content?  Is it worth doing?

At least Mozilla mail+news can be configured to alert the user before
downloading any image.  You have the option of loading the image, not
loading the image, and permanently placing a hostname on the image loading
shitlist.

Pine of course does not suffer from this particular bug.

Regards,
Jeffrey




---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 16:57:59 +1200
Subject: Re: HTML email "bug", of sorts.

On Sat, Aug 18, 2001 at 06:17:25AM -0400, Alex Prestin wrote:
> So, anyone have any idea of how to deal with this latest little spammer
> toy?  Is there any effective way to filter out web bugs without adversely
> affecting the delivery intact of legitimate messages?  Could software
> change to at least warn viewers that this HTML viewer is accessing offsite
> content?  Is it worth doing?

This is a client problem that needs to be supported there. For example,
Kmail - the KDE Mailer - has a "download remote URLs" checkbox. Simply
turning that off stops HTML mail messages from having things like <img> tags
being activated.

Under Outlook, this isn't possible.

-- 
Cheers

Jason Haar

Unix/Special Projects, Trimble NZ
Phone: +64 3 9635 377 Fax: +64 3 9635 417




---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 11:26:02 +0200
Subject: Re[2]: HTML email "bug", of sorts.

> 1) how do you determine what's legitimate HTML email and what isn't?  Can
> pattern-matching of web bugs be as easy as "*.gif\?.*" or something
> similar?

This is ineffective; a spammer _could_ use a CGI script in the form of
http://www.spammer.com/transparent.gif?4747683621, but if these get
blocked by a popular mailer, they will just move on to other schemes,
like:

http://www.spammer.com/validate/4747683621.html
http://www.spammer.com/validate/4747683621/
http://4747683621.spammer.com/
http://4747683621.spammer.com:25/

This will make filtering of HTML content useless. Furthermore, the html
IMG tag is not the only "dangerous" tag in this aspect. There are many
more other tags to filter, which would require considerable effort on
the part of mailer developers. [The usual scenario for this is that even
years later, holes will be found.]

Some mailers like "The Bat" have their own HTML engine that refuses to
do HTTP requests at all. This seems the best solution.

Disabling HTTP requests totally will certainly break some legitimate
HTML email, but not to the point where it is totally unreadable. Most
HTML emails (stationery etc.) only refer to images enclosed with the
message, so Your Client who likes to write emails with nice green leaves
in the borders will not be disappointed by this feature.

For other HTML mailers like Outlook and Netscape, an application-level
firewall (PGP Corporate Desktop, ZoneAlarm, etc.) is the only way to go.
The best thing is not to allow the mailer any access to the network
apart from the mail protocol ports on known pop3/imap/smtp-servers used.
As shown in example URL 4 above, just blocking access to port 80 or any
non-mail port provides only a false sense of security.

--

---------- Forwarded message ----------
Date: Sun, 19 Aug 2001 12:39:34 -0700
Subject: RE: HTML email "bug", of sorts.


If you're filtering outbound traffic in a corporate environment (something
I'd recommend), it will stop that sort of thing. Additionally, if you're
just a normal dial-up user, you can stop it by opening your connection icon,
choose properties, networking, and make sure "File and Printer Sharing for
Microsoft Networks" is unchecked, as well as "Client for Microsoft
Networks". The first is off by default, the second is enabled by default. If
you are a dial-up user, and not on a home LAN, turning off the Workstation
service will accomplish the same thing. Additionally, a home user can enable
SMB signing, which also defeats the attack. Rolling out SMB signing in a
corporate environment is a bit more complicated.

> -----Original Message-----

> And if you were running WinNT 4 and that referrer pointed to a server
> advertising a share, NT would send your username and password
> to try to log
> you on without your knowledge. It could be grabbed and sent
> back to your
> machine, logon, and the atttacker would have all rights to
> your machince and
> network that the ID you're using has.
> (as I've mentioned before, MS has known about this hole since
> before SP2)




---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 15:33:26 -0600 (MDT)
Subject: Re: HTML email "bug", of sorts.

> On Sun, 19 Aug 2001, David F. Skoll wrote:
>
> What I was more interested in finding out is how admins and people who
> *are* technically adept can filter these types of things out on a massive
> scale (on their mailservers, for example) *without* affecting the delivery
> of legitimate mail.

Here's a simple solution if you can run your inbound mail (or web
pages) through a filter.

1) run them through a simple filter for image tags.  With regex,
the pattern could be as simple as "<img ([^>]+)>", case insensitive.
You might need to include some backslash quotes.

For everything that matches, look for any height and width attributes
for the image.  If it's 1, you have a web bug.  Even if it's 2-8 or so,
it's probably still a web bug.

Either comment it out or delete it.  The latter may be preferable
if don't want to break scripts.

Of course, this basic can also be used to knock out scripts,
uuencoded HTML content (which I've also noticed recently - a lot of
filters don't seem to bother checking for scripts or webbugs within
a uuecoded HTML block, even though many readers will automatically
unpack, load and execute them.)

2) on a related note, if you see anything like
<img src="http://spammer.com/images/foo.gif?some-random-string-here">
you can snip the "?some-random-string-here" part.  Their logs may
still show your IP address, but they won't show a unique identifier
string.

3) if you want to be a bit more forceful, you could take the presence
of a small image as presumptive proof that the message is spam and treat
it as such.

> The problems I see with this approach are:
>
> 1) how do you determine what's legitimate HTML email and what isn't?  Can
> pattern-matching of web bugs be as easy as "*.gif\?.*" or something
> similar?

It's impossible to be 100% certain, but you can certainly answer with
broad strokes.  Is there ever a legitimate reason to use a 1x1 image?
If not, what is the harm in deleting them immediately?

> 2) where is this type of filter ethically the right thing to do?  on a
> server at work?  (I would think "yes".)   What if you work at an ISP?  (I
> would be less inclined to think "yes" if I might somehow be restricting
> the experience of paying customers.)

What about an ISP that decides to filter executable attachments?
Should the ISP offer an opt-out choice on that, or is it something
where they can legitimately say that it's a matter of "public hygiene"?
If the city can force homeowners to remove trash and mow tall grass
that provides a haven to vermin, then it seems that an ISP could take
similar actions again e-vermin like executable attachments or
web bugs used to validate spam lists.

--
Bear Giles




---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 11:22:37 -0700
Subject: Re: HTML email "bug", of sorts.

>
> Under Outlook, this isn't possible.
>
This is a kludge, and I know it is a kludge, but there are some things you
can do...  I don't expect people to roll this out corporately, but it is an
option, albeit awkward.  It all depends on how much you hate html mail and
what your choices for client email programs are.

In Outlook, you can use Message Rules to move emails with "Content-Type:
text/html;" or "Content-Type: multipart/alternative;" to a HTML folder.
This move does not 'preview' the mail, and links are not parsed.  We use ISA
server; the new firewall client can be enabled/disabled at will without a
reboot (the MSProxy 2.0 Winsock proxy client did not allow you to do this
w/o a reboot).  When you get a few html mails in your special folder, just
disable the fw client (preventing outbound connections) and view the mail.
If you get html mail internally, you can allow that in to your Inbox with
some more creative rules.

There were other things we did where we forwarded mail to another box and
then used the run-as to view them under user creds that could get the mail
but not make net connections, but that was really a kludge and I am almost
embarrassed to bring it up.  From an academic standpoint though, it did
provide some interesting alternatives...

hth

AD









---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 19:39:24 -0500 (CDT)
Subject: Re[2]: HTML email "bug", of sorts.

I think that Walter hinted at another scheme that hasn't yet been
explicitly mentioned.  By making a request like the one below the spammer
can use their DNS server logs to track messages, even if all TCP access is
blocked by a personal firewall.

The answer, as stated below, is that any email client that does HTML mail
should be highly restricted on what tags it interprets (no "active"
content) and should not display anything that didn't come included with
the message.  Possibly there should be a special DTD just for this
purpose.

On Mon, 20 Aug 2001, Walter Hop wrote:

..SNIP..

> http://4747683621.spammer.com/

..SNIP..

> Some mailers like "The Bat" have their own HTML engine that refuses to
> do HTTP requests at all. This seems the best solution.

-- 


---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 17:22:03 -0700
Subject: RE: HTML email "bug", of sorts.

This past thread has been following the lines of how the
img tag can be used to track a person's usage, or verify
the existence of an email address. This is just an issue
of privacy.

Maybe it's obvious, but I'd like to point it out anyways.
There exists more dangerous and malicious use of this
hole. It would be possible for a person to send an
email via some anonymous remailer to introduce a URL
attack to the world. This essentially gets the receiver
to execute the attack. Virus writers, like the one of
code red, could have used something like this to
remove the possibility that it could be traced back.

All the ideas of filtering, and the use of different
clients are good ideas. But in this real world, many
people just use outlook because work requires it (me
included). I think that is where a fix needs to implemented.
I don't even see having an option to disable downloading
of images as a good fix. People want to see the images
their friends send. If by default we don't download,
yet still leave an option so the user can 'double-click',
we're still vulnerable to a bit of social engineering.

There just doesn't seem to be a good compromise here.




---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 20:55:29 -0700
Subject: Re: HTML email "bug", of sorts.

> Under Outlook, this isn't possible.
...and...
> This is a kludge, and I know it is a kludge, ....
...and ...
>There just doesn't seem to be a good compromise here.

This is possible, (I'm using it right now)...
It's not a kludge, (in my book anyway)...
And it's a pretty decent compromise...
... and it has (at least one) nice side-effect :-)

1. Install cygwin, (freely available from redhat)

2. Create a shell script to port forward your mail:
#!/bin/sh
ssh -L 25:localhost:25 -L 110:localhost:110 mailxxx.xxx.domain

3. Create a batch file to call the script,
(for example, say it's my_mail_forwarder.sh):
@echo off
C:
chdir \cygwin\bin
bash --login my_mail_forwarder.sh

4. Create a shortcut to the batch file. Run it before you use mail to log on
to your mailserver with port forwarding, (use keys if you don't want to have
to type passwords).

5. Configure Outlook to pop/smtp off localhost,
(under Tools -> Accounts -> Properties)

At this point, you should be downloading your mail securely from your
mailserver, (this is the nice side-effect). But not done yet....

6. Install Zone Alarm.
(Free for personal use, $20 for biz -- you don't need the pro version.)

7. In ZA Control Center -> Security -> Advanced:
Add 127.0.0.1 to the local network, (not sure why it's not there by default)

8. When Outlook next tries to access "Local Network", (popping/sending mail
via the port forwarding ssh session), tell ZA to allow this traffic, (and
remember this setting). When it tries to access the "Internet", (for example
when you open a HTML email), tell ZA to block this traffic, (and remember
this setting).

At this point you are sorted. Outlook will happily render HTML emails in
readable format, but will be blocked from fetching images, (and other nasty
activity that it is prone to undertaking without your consent).

If you have multiple email accounts on different servers, port forward
other, (unused), local ports and configure the Outlook account's ports
appropriately, (Advanced tab in account settings).





---------- Forwarded message ----------
Date: Mon, 20 Aug 2001 21:41:24 -0700
Subject: Re: HTML email "bug", of sorts.

At 15:33 2001-08-20 -0600, Bear Giles wrote:

>1) run them through a simple filter for image tags.  With regex,
>the pattern could be as simple as "<img ([^>]+)>", case insensitive.
>You might need to include some backslash quotes.

.. which immediatley screws up _CODE_ embedded into messages.  "Here, joe,
the solution to the niggling problem is to replace the code in somefunction
with  <img src..."

KLUNK.  This method would have broken valid code - code which may be
expected to be copied and pasted as-is.

>For everything that matches, look for any height and width attributes
>for the image.  If it's 1, you have a web bug.  Even if it's 2-8 or so,
>it's probably still a web bug.

And for code embedded in valid pages, it may not be.  How about for images
without explicit height and width elements - many clients don't show a
preview, or at least show an outline (even on single pixel images) that
this wouldn't matter in email.  In fact, the 'web bug' could just as easily
be a *REGULAR GRAPHIC* (such as a horizontal rule), since you're viewing
HTML email, and by the time you realize an image is being loaded - whether
it is visible or not - the request has already been made.

>Either comment it out or delete it.  The latter may be preferable
>if don't want to break scripts.

Now you're stuck needing to match brackets, which very likely will not work
properly the instant you receive a quoted message:

 > the tag <img src="some tag"
 > height="1" width="1">

Where does the IMG SRC closing bracket appear when you're using a simple
regexp?  What if the second line doesn't appear?

Arguably, if the message body is HTML, the MIME type should indicate as
much, there should be an opening HTML tag (but there might not be, and
email HTML renderers are pretty lax with this), and gt and lt's that aren't
part of the HTML coding of the page would be properly escaped.  Then again,
what stops the spammer from obfuscating their code in the same way?  Try
embedding ORDINALS in your page, and a good HTML renderer will render it
fine, but most regexps will fail to find a match (I use ordinals to
"mailfuscate" mailto urls and even non-URL plaintext email addresses on all
of my webpages - it significantly reduces spam which arrives from
web-spidering spambots).

Besides BGSOUND, page backgrounds and even TABLE backgrounds could utilize
an embedded image, in which case, you won't even see it as an IMG SRC
tag.  Suddenly, your filter needs to fully parse HTML in order to have a
prayer of stripping these tags.

Which makes blocking (via RBL, etc) and effectively filtering spam a pretty
darn good solution.


Someone mentioned having a port-80 filter on your firewall -- what of dot
trackers which reference a specific port number?

         <img src="http://www.somesite.com:110/dot_tracker.file?uniqueid">

Anyone running a firewall would probably block certain services -- but all
the spammer has to do is run their tracking system on a port for a standard
service which a mail client would be expected to access, and that
firewalling isn't going to do you much (unless your firewall only allows
access for POP3 (110) out to one specific server - joe user is unlikely to
configure their machine this way, joe poweruser probably won't because they
have multiple accounts, and joe corporateadmin won't because too many users
check their various mail accounts from the office, and limiting them in
this fashion would be too grievous).


Sorry if I've pointed out another exploit that the spammers could use to
circumvent such firewall rules.

---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395




---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 17:33:43 +0900 (JST)
Subject: Re: HTML email "bug", of sorts.

On Mon, 20 Aug 2001, Bear Giles wrote:

> For everything that matches, look for any height and width attributes
> for the image.  If it's 1, you have a web bug.  Even if it's 2-8 or so,
> it's probably still a web bug.
> ...
> 2) on a related note, if you see anything like
> <img src="http://spammer.com/images/foo.gif?some-random-string-here">
> you can snip the "?some-random-string-here" part.  Their logs may

Nah. My first thought, when asked about the technical details of e-mail
bugs at a certain company whose name I won't mention to protect the
guilty, was, "How do we make sure it doesn't look like a bug?"

So you insert this:

<img src="http://www.example.com/imgs/18465485943/foo.gif" width=400 height=90>

as your company logo in the newsletter or whatever you're sending out.

That invokes a servlet or whatever called /imgs which looks at the
remainder of the path as a parameter, logs a hit from 18465485943 in
your database (we would have associated this with a particular piece of
mail that went out) and returns your company logo. You make sure that
the header specifies that it expires instantly, of course, so you get
information that the message has been forwarded or re-read or whatever.

I really don't see any way to protect against these bugs, except not
to retrieve external images. And that, as others have mentioned, is not
likely to go over so well with a lot of users out there.

cjs
-- 



---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 06:39:12 -0400
Subject: Re: HTML email "bug", of sorts.

On Mon, Aug 20, 2001 at 07:39:24PM -0500, Mark Tinberg wrote:

> I think that Walter hinted at another scheme that hasn't yet been
> explicitly mentioned.  By making a request like the one below the spammer
> can use their DNS server logs to track messages, even if all TCP access is
> blocked by a personal firewall.

Yep, nice point.

> The answer, as stated below, is that any email client that does HTML mail
> should be highly restricted on what tags it interprets (no "active"
> content) and should not display anything that didn't come included with
> the message.  Possibly there should be a special DTD just for this
> purpose.

See RFC 2392, which describes how rich messages (like HTML) can refer to
other objects included with the same multipart message. There may still be
vulnerabilities if the attachment is hostile, especially if your rendering
engine (I'm thinking about Internet Explod^Hrer here) ignores the MIME
type specified in the message headers. But at least restricting the message
to included content via RFC 2392 allows attractive messages with no web
bug, Cross-Site Request Forgery, distributed URL DoS, or other wickedness.

The ZoneAlarm-type tricks are neat; I assume those folks don't often use
webmail applications like acmemail/suirrelmail/hotmail, where restricting
the message to cid:/RFC 2392 references is about the only sane approach.

-Peter




---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 13:58:02 -0400
Subject: Re: HTML email "bug", of sorts.

Hi Bugtraq,

I've been following this particular thread with a great deal of interest as
it directly relates to my present academic course work.  Although the focus
of the debate thus far has been centered around spam, I think there is a
greater ethical dilemma posed by this "bug".

I never took the time to look through the HTML code of e-mails that I
normally receive and have subscribed to, but this thread opened my eyes.  I
was very surprised to see an img src tag with an invisible hyperlinked gif
at the bottom of *every* HTML e-mail I've received.  Keep in mind these are
"legitimate e-mails" received from news subscriptions; a result of shopping
online and filing a profile; and registering software.  Here are some
highlights:

_____=====***=====_____

The New York Times on the Web Headlines newsletter that just recently went
to HTML format:
<IMG SRC="http://images2.nytimes.com/RealMedia/ads/adstream_nx.cgi/email.ny
times.com/todaysheadlines/html at Bottom1">
</BODY>
</HTML>

***Privacy policy at http://www.nytimes.com/info/help/privacy.html does a
fairly decent job of explaining that they use RealMedia as an advertising
server.  I would presume that is what this link is for.

_____=====***=====_____

Staples.com at the bottom of their HTML ads sent to all online shoppers:
<img src="http://od.ed10.net/od/V6P3/H08/EK5O6F">[[V6P3-H08-EK5O6F-H]]27689
0</body>
</html>

***Privacy policy at http://www.staples.com/help/default.asp?area=privacy
doesn't say
anything about why they are collecting information from the e-mails they
send out, or how it's being used.  At least Staples has the decency to put
some text at the bottom after the tag so that you know where it is.

_____=====***=====_____

The Learning Company Family Focus Newsletter (a.k.a. advertisement)
resulting from product registration:
<img
src="http://info.learningco.com/images/blankpixel.gif/Key=9562.Ftzu.DzF2lN">
</HTML>

***Privacy policy at http://www.learningco.com/Info.asp?Info=1805 doesn't
say anything about why they are collecting information from the e-mails they
send out, or how it's being used.  I like the name of the gif -- it says it
all!

_____=====***=====_____

<!-- on soap box -->
The point is that this coding technique is being widely used to harvest
information from subscribers probably for demographic or similar purposes --
it depends upon the source.  The problem is that companies aren't telling
their customers/subscribers in a direct manner that they are doing this.
One must first know and understand the technology, then go and seek out a
privacy policy, and maybe -- just maybe -- find an answer.  More often than
not, the privacy
policy is buried in the middle of a lengthy legal statement for COPPA
compliance to keep the EPIC and the ACLU off their backs.  If companies are
going to use this technique for "legitimate" purposes (very loosely
defined), they should be upfront about it and let their
customers know.  If someone/some company is going to track my shopping
habits and datamine my e-mail, I would appreciate the courtesy of them
letting me know that they're digging into my private life before they do.
This much can be done, and should be done.
<!-- /off soap box -->

There... I feel better.  Venting complete.

Jeffrey W. Dronenburg, Sr.
MIS Major, Univ. of Maryland, Univ. College
Alpha Sigma Lambda





---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 12:48:50 -0600
Subject: Administrivia: HTML Email Thread

While this is an interesting issue, I am killing this thread. The behavior
of email clients that automatically retrieving data from remote servers without
the users knowledge or consent when rendering HTML messages can be considered
a risk, and certainly is considered as such by some.

As described on the list in the past, similar behavior is exhibited by
other applications and document formats. For example, Microsoft Word
documents with embedded images.

It think we are all in agreement that email clients should at least alert
users when fetching remote content and ideally allow the user to disable
such behavior.

At this point a number of workarounds and suggestions for alternate mail
clients have been discussed. Further discussion is off-topic for the list.
If you want to continue discussion this issue the RISKS forum is more
appropriate.

-- 
Elias Levy
SecurityFocus
http://www.securityfocus.com/
Si vis pacem, para bellum







More information about the thelist mailing list