Turns out that the ZIP file format that all of these beasties are using is a little bit non-standard. Specifically they are all version 1.0 zip archives and the first (and only) component is not compressed. At MIT we are matching these two strings to recognize the infected ZIP files while letting most (actually I have seen no false positives) if not all "real" ZIP files. We are matching them anywhere within an attachment (well, within the first 16K). However you really only need to see if they are the beginning characters (this is a ZIP file header). What follows are the base64 encoded strings. I have put an asterisk between the first and second character, so my own filters won't reject this message, do remove that before using... U*EsDBAoAAAAAA <= Matches unencrypted ZIP file U*EsDBAoAAQAAA <= Matches encrypted version. -Jeff

pass. I will be the first to admit that using mail as a file transfer protocol isn't the way to go, but getting people to realize that (and forcing them to change) is next to impossible.

Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this. Curtis -- Curtis Maurand mailto:curtis@maurand.com http://www.maurand.com

Or, like me, nobody knows about them. Maybe its time we educate our users. Curtis On Wed, 3 Mar 2004, Laurence F. Sheldon, Jr. wrote:

Curtis Maurand wrote:

...

Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.

There are actually several, some with features much superior to using email as the truck.

The problem with them is: Nobody wants to consider them.

-- -- Curtis Maurand mailto:curtis@maurand.com http://www.maurand.com

Jeff Shultz wrote:

** Reply to message from "Laurence F. Sheldon, Jr." <LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600

...

Curtis Maurand wrote:

...

Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.

There are actually several, some with features much superior to using email as the truck.

The problem with them is: Nobody wants to consider them.

Okay, so what are several ways to share files with a friend, where you don't share any accounts or passwords, and where only your friend will be able to access them?

FTP'ing to a web site is out - you either have no guarantee that they'll be the only one to be able to access the file, or you have to mess with password protected websites, not something a person is going to do to send the kids photos to Grandma.

Actually FTP can be made secure. That and all of the other ideas I might propose require some development work and some change of attitudes. Here is the answer igave in private email to fundentally the same question: quote My personal favorite that at one time would have been the easiest to develop has a MUA that "attaches" the document by storing the text in an HTTP-accessible archive (on the sender's machine? on the sender's MTA machine?) and including a URL in the email. My personal objection to embedded attachments is not a product of the virus rage going on--it goes back a lot farther and has to do with system efficiency, security and privacy issues. (Consider a situation that I have found to common: Person A sends a message transmitting a document containing sensitive information to person B. For reasons that make sense, Person A sends "CC" or "BCC" copies to persons C, D, E, and F.--perhaps to "document" the transmission to B. C-F have no interest in the document, just the fact that it was transmitted. But the get copies of it. A in the process of preparing the message mentions that the document will be made public at a meeting on a future date. E realizes that persons G and H need to be at that meeting and "forwards" the message _and_the_document_ to them. (In one case in my past, "G" was the last person in Creation that should have gotten the document early.) If the message is stored under PKI with A's key all of that and the system overhead goes away. There are others. unquote

On Thu, 4 Mar 2004, Laurence F. Sheldon, Jr. wrote:

Jeff Shultz wrote:

...

** Reply to message from "Laurence F. Sheldon, Jr." <LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600

Okay, so what are several ways to share files with a friend, where you don't share any accounts or passwords, and where only your friend will be able to access them?

[snip]

Actually FTP can be made secure.

That and all of the other ideas I might propose require some development work and some change of attitudes.

Here is the answer igave in private email to fundentally the same question:

quote

[snip]

E realizes that persons G and H need to be at that meeting and "forwards" the message _and_the_document_ to them. (In one case in my past, "G" was the last person in Creation that should have gotten the document early.)

If the message is stored under PKI with A's key all of that and the system overhead goes away.

There are others. unquote

But nothing that's been developed. Joe user's ip address changes on a regular basis. One would still need to find that machine. DNS gets cached (some go past TTL's I've set.) and is too static to be an effective means to get a file. Most instant messengers have facilities for exchanging files, but both sides need to be connected at the same time. Having that file in an email is better. I like SCP, too. It works well, so well that I use that, instead of ftp. You still have to find the other end that has its address changed every day or two. With email, only one end needs to be connected at any one time. email is about the most convenient and easiest way that I know of to get pictures of little Johnnie to Grandmother in a way that is easy for her to understand. Whatever anyone proposes needs to be that easy. Chances are that Grandma's not a geek like most of us. Curtis -- Curtis Maurand mailto:curtis@maurand.com http://www.maurand.com

Just for information - may be useful for someone. Task - we determined, that few infected machines was connected to one of our offices few days ago. They run one of this viruses, which generated a lot of scans and created sugnificant traffic (but traffic was not big enough to rais alarm on outgoing gateway). Activity was short. Computers are not connected in the time of investigation. IDS system and Cisco logs was not active in this office (few tricks with Cisco ACL's and logs allows to detect many viruses instantly; good IDS systems can do it as well). Solution: - get all port statistics from switch (using SNMPGET and using simple 'telnetting' script - we have 'RUN-cmd' tool allowing to run switch commands from shell file; - remove all ports with traffic less than some threshold; - calculate IN/OUT packets ratio for the rest of ports; - find ports, where IN/OUT ratio (IN - to switch) > 6; - in this ports, find ports with average packet size < 256 bytes; It shows all ports with infected notebooks (even if notebook was connected for a half of day). PS. Of course, after this few additional monitoring tools was installed, and we added _all_ switches and _all_ ports to 'snmpstat' monitoring system (it allows to see a traffic in real time, and analiz historical charts, including such things as packet size).

On Fri, 05 Mar 2004 11:23:37 -0500 Valdis.Kletnieks@vt.edu wrote:

I might want to send you a file, but you probably don't want to give me a userid on the machine you'll receive it on, and I probably don't want to give you a userid on my laptop.... Somewhat limits the options for the general case.

yes, ultimately you end up falling back on http or some traditional form of ftp, but for intermediate cases, i've had good luck using rssh in chroot mode at customer sites where there is a need to provide carefully constrained, secure access. rssh: http://www.pizzashack.org/rssh/index.shtml richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

dropload.com seems to me to be the perfect model for anonymous file delivery over the internet. Their system doesn't use SSL yet, but it would be the logical next step. Here is their description: Dropload is a place for you to drop your files off and have them picked up by someone else at a later time. Recipients you specify are sent an email with instructions on how to download the file. Files are removed from the system after 48 hours, regardless if they have been picked up or not. Recipients can be anyone with an email address The whole system uses HTTP for the transfer, no FTP hassles. On Thu, Mar 04, 2004 at 05:20:49PM +0000, Roland Perry wrote:

In article <20040304163204.8AEF010DA3@gateway.wvi.com>, Jeff Shultz <jeffshultz@wvi.com> writes

...

Okay, so what are several ways to share files with a friend, where you don't share any accounts or passwords, and where only your friend will be able to access them?

Putting the files into an obscurely named and unlinked directory of a website will normally be as good as necessary. The sender still has to mess with ftp, unless he has a web-based uploading system at his disposal (see fotopic.net for an example user interface).

If you are prepared to concede that both parties must be subscribed to the same online community (be it Yahoo-Groups-alike or a messenger product) then the possibilities are endless, and many are not beyond granny's capabilities. -- Roland Perry

-- Stephen Milton - Founder/VP Internet (425) 881-8769 x102 ISOMEDIA.COM - Premium Internet Services (425) 869-9437 Fax milton@isomedia.com http://www.isomedia.com

Speaking on Deep Background, the Press Secretary whispered:

...

pass. I will be the first to admit that using mail as a file transfer protocol isn't the way to go, but getting people to realize that (and forcing them to change) is next to impossible.

Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.

Curtis

I've pipedreamed a scheme that would do this: Sending Luser drops file on to Attached File line in the MUA {say, Eudora} and Sends. MUA opens https to its own MTA/server, encrypts & uploads file and designates file name. It puts the unique URL/key into the pseudo-Attachment line of the mailer. [Attachment's encrypted so that if the mail itself is, the file would not be lesser-protected. Real security would require the MUA, not the MTA to do encryption, I guess] Receiving Luser (RL) gets message with Attachment link. {S}he clicks on it, not really knowing/caring it is a https link. Decrypted "attachment" is dumped on RL's desktop. Behind the scenes, the Sending MTA notes the file was grabbed. It has a set of expiration rules, whatever its local policy is -- X days if not yet grabbed one, Y days after the first, -- & a history file al-la Usenet spool. SMTA expires old messages. The advantage to the MTA operators is no longer will people try to cram 35 MB Powerpoint files down mail pipes. Yes, they are stuck storing the files for a few days, and moving later; but ?some? will never be moved at all, saving BW. {The old "what's cheaper, disk or pipe?" issue arises here.} Further, "Attachment" transfer BW could be QOS'ed downscale. Variations might be the file is not stored by the SendingMTA but pushed to the ReceivingMTA/MX. Or when the RL "opens" mail, it's moved from SMTA to RMTA/MX, and then to the RL. I'd have thunk someone already thought of all this, but I've not seen such discussed. Even a clueless guy like me can see there are multiple reasons It Won't Fly, some perhaps solvable. a) Gripe: Attached Files would expire. Someone Would Complain. Response: BFD. Tell the sender to "mail that file again.." b) G: Mail Systems operators are stuck storing files & must run expiration scripts. R: And this is worse than the terrabytes now being queued? Plus, space could be limited and maybe chargeable. c) G: Critical Mass needed before it can be usable at all. You'll never ever get there unless Billy puts it into LookOut^H^H^HOutlook. R: Yea. In order to crack c); I guess it would take not just a solid RFC and running code; but a 900# Gorilla demanding such, maybe Earthlink or AOL. Flaming session is now open. I'm not awake yet, so I plead the Hypnos Defense. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433