Sun May 23 2004, 1:30 AM
Demo system for "mail bugs", tiny images embedded to emails in order to track the message - if and when it was opened, if/where it was forwarded. Often used by spammers - some spam filters use a presence of an inline image with URL to an external server with a query string as one of signatures.
Support for HTML mails is common in most contemporary email clients. However, only the most recent ones allow screening of objects refered by the message itself. As a result, many clients open images from third-party servers. The risks range from privacy risks (conventional web bugs) to annoyance (porn spam with explicit images not sent in the message itself but included there from external servers) to security risks (embedding an object in the mail that exploits a suitable browser hole - opening a connection from the client to the server often allows bypassing firewalls and the added user-agent browser identification allows the server to tailor the eventual exploit for the client type and version).
There are even subjects attempting to commercialize on the technology; an example can be eg. DidTheyReadIt? (USA Today article here, some more links here, an analysis in Risks Digest 23.49 here); my system may be quite quickly adapted to perform a similar service.
(The Didtheyreadit.com system converts a plaintext message to HTML and appends this 1x1 image on
<img src="http://didtheyreadit.com/index.php/worker?code=a28e7ad42e7ca17174572b5bXXXXXXXX" width="1" height="1" />
(last 8 hex digits obscured). Thanks to Neil Schwartzman for pointing it out
(According to the Risks Digest analysis above, which is more recent, the tag format is now
<img src="http://didtheyreadit.com/b906148b2edfdab9e7de03a23f59687eworker.jpg" width="1" height="1" />;
the hash is now part of the filename instead in an URL parameter. This is probably to avoid
looking like a web bug, in order to pass through spam filters - images with parameters are
The demo system has three parts:
Every bug has its own ID, which is a number assigned according to a desired algorithm. In this case, the ID is a number of seconds from Jan 1 1970, aka raw Unix time (which was the easiest solution as I don't suppose more than one bug per second will have to be generated even under peak usage). Every bug also has some server-stored information: the email address where the bug was sent, the email address where the bug relays its activity data, the time it was created, the user-selected comment (up to 4 lines). ID 0 is reserved for a demo bug that is not mailed but shows the same data on a webpage.
After being activated, the bug reports following data to the email specified as its creator (in the demo system it is forced to be the same address as the recipient of the bug, to prevent abuse): the IP address and reverse-lookup domain name where it was requested from, approximate geographical location (supplied by the IP2loc project), remote browser type; proxy information, if contained in the request header; HTTP referer, which is useful for web bug tests (see lower) and for tests of vulnerability of webmail accounts; the time the bug was created; and the user comment assigned to the bug.
If you want to only peek at the information the bug sends out when activated, look at the demo link here.
If you want to see it in action, use the form here. The addresses won't be used for other purposes. If a challenge-response antispam system will be encountered, the message will be thrown away and ignored - please allow receiving of messages from email@example.com if you want to perform the test.
After receiving the bug, you may like to forward it around a bit to see the mail tracking.
If you are a webmaster, you may also wish to test how the bug behaves on a webpage (just extract the IMG tag from the bugged mail message and put it into a webpage source; please don't use it outside of the testing scope: this machine is on a slow line and the connection is not guaranteed to be reliable). Web bugs could be also used for sharing user identity (stored in cookies) between multiple servers, and - together with mail bugs - to tie the user's email identity to the cookie-based and/or IP-based one, but that is beyond the scope of this demo.
The same approach can be used to track opening of any document that allows insertion of an object referenced by URI; I suppose it applies to Microsoft Office documents (in detail explained here), PDF files, and potentially many many other file types. Recent introduction of DRM-enabled multimedia files that "phone home" for permission to be played, together with their embedding into the webpages and other documents, allows even more possibilities.
There are other methods to insert a bug than just the IMG tag; any object that has to be fetched from a remote server will do, be it image, frame (both full-page and inline), script, stylesheet, or an ActiveX object. The tendency of the mail clients to allow retrieval of different types of objects depends on their type and security/privacy setting. Also, the image itself does not have to be invisible - it may quite well contain some useful (or at least pretty) information.
BCC copies of all the generated mails are sent to the developer, to provide him with experience and to discourage the users from misusing the system. Abusers will be blacklisted.
And because no chess game is fun if the white pieces won't show up, you may like to check Bugnosis, the web bug detector (MSIE only). Other tools usable for other browsers are eg. Privoxy (free, opensource), WebWasher (shareware), or SpyBlocker (shareware), and there are more. Beware though, they may or may not work for your specific threat model.
Also, some browsers (eg. Mozilla) provide the option to disallow download of images from third-party servers. (Which may break eg. pages depending on Akamai cache, but is good for ads and web bugs.)
Yet another option is to use an "application firewall", a program hooking the socket creating/binding
operation and disabling network access to programs that aren't supposed to have it. Examples of such
programs are eg.
Tiny Personal Firewall,
(Thanks to Michael Puchol of Sonar Security for reminding me of this.)
server, and various SSL-related information.