1. Home
  2. Networking Firewalls
  3. Possible Eudora Exploit?

Possible Eudora Exploit?

About 2-3 times a month I get an email from some outfit called denniskirk.com. I have no idea how I got targeted, because the message comes to my primary ISP address which I NEVER provide online. The subject line always contains the string "Dennis Kirk" so it was a trivial matter to tell my old mail alerter program (Winbiff, in case anyone's interested) to nuke that message on sight while it was still on the pop server.

I recently stopped using Winbiff because I was trying out another program that does the same thing. Thus the message from denniskirk.com started arriving here.

Eudora correctly flagged it as junk every time.

Now here's where it gets interesting.

I have a Linksys router and I use WallWatcher to monitor the router's log. I just happened to have WallWatcher open when I opened Eudora and at that very moment, WallWatcher reported a packet going out from my system on port

80 to - you guessed it - denniskirk.com.

The interesting thing is that all this time the message was in my Junk folder, which I don't routinely open every time I pop mail. I do check Junk fairly often just to make sure there's been no false positive on junk mail detection, and the Junk folder is one of the 4 folders that I keep on my Eudora task bar.

The simple fact of opening Eudora triggers a packet to denniskirk.com 100% of the time I tried it. As soon as I deleted the message from Junk -- no more packets.

The only thing I didn't check before deleting the spam was whether or not it would detect Eudora's opening if Junk *wasn't* one of the folders perched on the Eudora taskbar at program startup, but I'll eventually get another one of those messages and will play around with it some more.

I recently started using a firewall called Look 'n' Stop, which is designed to stop rogue packets from going out of the system, but I'm still learning how to use it so I wasn't successful in attempting to define a rule for the firewall that would stop that outgoing packet.

I have no idea about the contents of these packets. I suspect (hope) that it's nothing more than simply an email "bug" that lets the spammer know it's reached a real live system.

As a last resort, I'll go back to using Winbiff, which will stop the message from arriving here in the first place, but curiosity has gotten the better of me and I want to see if I can stop this packet from going out the next time one of those messages arrives here.

Conceptually of course, the reason the packet is going out to begin with must be because it's using a launch vehicle (Eudora) which has already been given permission to connect to the internet -- which leads me to wonder if there really IS way of stopping an authorized program from sending an unauthorized packet.

Tom

Reply to
Tom Hall
Loading thread data ...

Most likely a web bug in the email, if it is a current version of Eudora it should have a setting somewhere to not load remote images ie "web bugs".

If you want to determine what is really being sent;

or

if the email address has really not been exposed before than it may be subject to dictionary attack or some other form of guessing.

You might look to see if you can limit Eudora to the IP addresses or server names and protocols it needs to function.

John

Reply to
John Mason Jr

On Sat, 07 Oct 2006 10:22:17 -0600, Tom Hall declaimed the following in comp.mail.eudora.ms-windows:

I presume you mean going /to/ port 80 @ denniskirk.com... Port 80 is normally the port one uses to connect to an HTTP server. Your client should be using a non-dedicated scratch (high number) port on the local end.

First question is: is it the Eudora process that is sourcing that connection (if you are using the M$ Viewer option, it might be flagged as IE sourcing the packet).

ZoneAlarm's advanced configuration options allow one to define rules on IP and Port numbers, so it is possible (I've not tried it) to create a blocking rule on TCP port 80 (with or without a range of IP numbers on which to apply it).

I don't use the M$ Viewer, and I have Eudora options set to block active content (anything in the body that has to hit the web at view-time rather than coming down with the body). URL LINKS are allowed, because Eudora doesn't open those -- it opens my browser and passes the link to it.

Reply to
Dennis Lee Bieber

Eudora implements return receipts and it implements MAPI. Maybe a look into the headers of this message will help.

Yours, VB.

Reply to
Volker Birk

Ah, I wrapped this first ;-) This sounds like you're using HTML as mail format and have some external references in your mail (for example, a picture embedded with an tag).

I think, you could try to configure Eudora not to load external references, or better try to switch off HTML mail at all.

Yours, VB.

Reply to
Volker Birk

Another option is to deselect "Use Microsoft's Viewer."

Notan

Reply to
Notan

You all are missing the point. The message only has to EXIST in order to trigger the packet, which happens whether the message is even displayed or not.

Tom

Reply to
Tom Hall

Hm... maybe some trick with MAPI. Interesting, can you supply a copy of the message?

Yours, VB.

Reply to
Volker Birk

Execution WITHOUT opening the e-mail?

Huh?

Notan

Reply to
Notan

Another one should arrive in a week or so. I'll come back here with any results I find.

Tom

Reply to
Tom Hall

Exactly. That's precisely why I started the thread.

Tom

Reply to
Tom Hall

I've received another of these messages, and am happy to report that the exclusion rule I wrote for my firewall works. The packet generated by viewing the message was blocked from going out.

Someone expressed an interest in seeing an email message that could trigger an outgoing packet simply by being viewed. I moved this message to its own folder and have a zip file consisting of the MBX and TOC for anyone interested in seeing it. Just un-munge my address, drop me a line and I'll send the zip file to you.

Tom

Reply to
Tom Hall

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.