Scan and Hijack
My solution I emailed to the sponsor was quite lengthy, so I'll try to condense it here.
The JPG is for logging the victim's IP address.
The "document.location" script function hijacks the browser session; the "document.cookie" object compromises the session information, and the "Grab" program assumes control.
"Grab" at a minimum will log the cookie info in preparation for a future attack.
Most likely "Grab" will simply copy the cookies and act as a Doppleganger of the victim, allowing the hacker to resume the session in progress as if he were the victim.
Worse still "Grab" might prompt the victim as if the password had been entered incorrectly, with an identically forumlated dialog to the real one (which the hacker could have seen and thus duplicated), and the victim will be fooled into handing over the password.
Lastly, and worst of all, "Grab" might try to trick the user into installing executables under the guise of an update of some sort. The user, believing he is logged in to the company website, might just be fooled into doing it.
Central to the hack however it is exploited is the hijacking of the browser away from the company server and into the clutches of the hacker's "Grab" program.
The solutions for fixing this hack are, on the server side, escape-sequencing all control characters from user-entered text, so that if the user enters, "<script>document.gotcha()</script>" what the data entry clerk sees is, "<script>document.gotcha()</script>". This simple solution elegantly frightens the data entry clerk into calling the IT department, who promptly take appropriate action. If the clerk ignores the suspicious text, well, the web app ignores it, too; no harm done.
On the browser side JavaScript is easy enough to disable, and there are also ways to explicitly disable domain-jumping which vary from browser to browser. It is also possible to disable images, but in my opinion that is a poor way to solve the problem of web bugs. If the web app hands the browser an image link, the browser should download and display it; that's its job. (But I would NOT extend that logic to the running of scripts!)
Lastly, the email client can be set to text-only, disabling HTML completely, or you can explicitly disable JavaScript and images, although on some email clients these prohibitions are shared with the browser, meaning disabling images in email requires they be disabled in the browser, too.
If you have an email server and a personal firewall (ZoneAlarm, of course!) you can set the personal firewall to allow the email client access only to the email server. Neither hackers nor spammers can tag your IP from an email image if your email client isn't allowed to access the Internet.
Although I personally use the ZoneAlarm setup it does not technically meet the parameters of the challenge, which require two email solutions based entirely on the email client's configuration. Still ... works for me.
So whaddya think? Worth a free book?
Derrick Jones, Software Developer
Managerial Assistance Corporation
