[ba-ohs-talk] Klez Among Us
I notice that there is a Klez infection using this distribution list as one
of its distribution mechanisms/disguises. At the beginning, there was a
message every other day claiming to be from the list. Lately there haven't
been any and I didn't think any more of it. Then there was another this
morning. (01)
CRITICAL SUMMARY
---------------- (02)
This is a long message. With regard to the identification of an infected
system that is sending Klez-infected messages to the BA-OHS-Talk list, here
is the key information: (03)
1. If you know or have mail from dmcusa@dmc.fr on your system, or that
e-mail in your address book and, (04)
2. You access the Internet through rr.com in Upstate New York
(Albany-Rochester area), (05)
3. You use Microsoft Outlook or Outlook Express or have used it and it is
still installed on your system, (06)
YOUR SYSTEM MAY BE INFECTED. The rest of this message may help you to
determine whether or not your system is one of the infected ones. (07)
IMMEDIATE ACTION. Whether or not you fit this profile, you can satisfy
yourself that your computer is not a source of this particular pandemic by
accessing
http://www.symantec.com/avcenter/venc/data/w32.klez.gen.html
obtaining the removal tool, and meticulously following the instructions
given for it (sometimes it is necessary to read ahead in the instructions
for a current step to make complete sense - do that). The tool is benign and
will not make any alterations to an uninfected system. You must operate it
in the way specified so that the methods of disguise built into Klez are
overcome. (08)
LONGER VERSION
-------------- (09)
Because of the way Klez works, it is not possible to know whose computer is
infected, although there may be clues in the content. Here are the clues
that I picked out of the headers for this morning's arrival. I offer
comparisons with a legitimate posting from Mei Lin for comparison: (010)
BASIC ADDRESSING INFORMATION
---------------------------- (011)
1. The message says it is to ba-ohs-talk-list@bi0.bootstrap.org. That's
peculiar. This looks like something mined from a message header and not
someone's address book. Messages normally say they are to
ba-ohs-talk@bootrap.org, the recommended name of the list. (012)
2. The subject of the message is "Technology provided by Google" Notice
that there is no "[ba-ohs-talk]" prefix as on a message that enters the
server via the ba-ohs-talk address. However, this subject was mined from
something. There is an e-mail on the infected system with that subject. (013)
3. The message is identified as from "dmcusa <dmcusa@dmc.fr>" so the
infected machine has either a mail piece or an address book with this e-mail
address. For normally-created messages, my mail client (Outlook 2000
Internet Mail Only configuration) would normally report it as from
"owner-ba-ohs-talk@bootstrap.org; on behalf of dmcusa [dmcusa@dmc.fr]" and
we don't have that here. (014)
4. The Return-Path and the Errors-To header of the message are both to
<njcdj@nycap.rr.com>. Again, for a normal forwarding through the list,
these are both <owner-ba-ohs-talk@bootstrap.org>. (015)
FORENSIC OBSERVATIONS: (016)
It would appear that Klez does not discriminate between list addresses and
other addresses when it mines for this information. Consequently, the
falsification of a distribution-list message has a number of defects. (017)
Beside the peculiar impersonation of the list, there is contradictory
information between the from (dmcusa@dmc.fr) and the sender
(njcdj@nycap.rr.com). (018)
My experience is that the infected system is one that has dmcusa@dmc.fr in
their address book or in other mail, and has received messages from
BA-OHS-Talk (because the list is actually hosted on a server identified as
bi0.boostrap.org). The njcdj@nycap.rr.com is likely related to where the
infected message was actually injected into the Internet SMTP mail system,
so someone in Eastern Standard Time and upstate New York (probably the
Albany area) may have the infected machine. (019)
BACKTRACKING THE MESSAGE ROUTING
-------------------------------- (020)
Here's what is to be found out by working back through the transmission
history in the e-mail headers: (021)
5. According to the headers, my mailserver (onyx.bcentralhost.com) received
the infected message from alias2.acm.org [199.222.69.22] with an EST which
is plausible for a message sent to me at dennis.hamilton@acm.org. (In the
case of Mei Lin's posting, [monty.bcehtralhost.com] received the message, so
it was handled by a different server. It came from alias2.acm.org though.) (022)
6. According to the headers, the ACM Email Forwarding Service received the
message from bio.bootstrap.org [130.107.1.200] with a PST time stamp. One
odd thing here is that the ACM Email Forwarding Service does not say who the
message was addressed to. (The same thing happens with legitimate postings
to BA-OHS-Talk.) (023)
7. According to the headers, bi0.boostrap.org (Postfix) received the message
(delivered to ba-ohs-talk-list@bi0.bootstrap.org) from
ms-smtp01-nyroc.rr.com [24.92.226.148]. (With the legitimate posting to the
correct list address, b10.bootstrap.org receives the message twice, first on
its way into the list and then as part of the handover for distribution. A
receipt to ba-ohs-talk arrives at b10.boostrap.org and is handed over to
ba-ohs-talk-list also on b10.bootstrap.org and then it is sent on to its
destination.) (024)
FORENSIC OBSERVATION: Because Klez is mining an inbox or other source of
e-mail addresses, it is picking up an origin to attempt infection through
that is intermediate in the list forwarding process. What is interesting is
that ba-ohs-talk-list on b10.bootstrap.org accepts forwardings from other
than itself, an interesting vulnerability of the list server software. The
piping model used in mail systems is very nice, but it provides an entry for
penetration (the kind of thing spammers love). [Soapbox observation: In
this case, it appears to be supporting Klez propogation in a totally
accidental way. We have been talking about this kind of difficulty in my
M.Sc program's Computer Structures class. I think it is possible to
safeguard against this sort of thing, but we have to change the way we look
at our systems, and then there is the question of whether we are willing to
do the work. -- dh:] (025)
8. And finally, according to the headers, ms-smtp-01.nyroc.rr.com received
the message from Wyfqxk (alb-24-194-35-232.nycap.rr.com [24.194.35.232])
with an EST timestamp. (Meilin's message came to the list through
blount.mail.mindspring.net [207.69.200.226] which received the message from
h-68-164-24-171.snvacaid.covad.net ([68.164.24.171] helo=D9KP0711) with the
>From address set to "Mei Lin Fung" <meilin@ix.netcom.com>.)
FORENSIC OBSERVATION: This is the basis for suspicion that message
injection actually occuring in the Albany, New York (nycap) area although it
might be Rochester (nyroc) too. (026)
COHERENCE OBSERVATION. I provided all of this because of a problem that we
all have, recognized or not, around the coherence of e-mail communication.
Many of our mail clients don't show us this material from the "postal header
and routing" information that accompanies our mail, and we may not know how
to find it. (For Outlook 2000 Internet Mail Only, look under View / Options
of a received message.) In addition, because Klez is designed to
impersonate a plausible source other than the actual sending system,
recipients cannot ascertain the true origin of the message. However, Klez
incorporates facts from somewhere, and *SOMEONE* may recognize the
coincidence of facts that makes it likely their computer is a virus host and
their e-mail materials are being tapped as the source of disguise materials.
But the operator of the infected system won't know this because a recipient
needs to ferret out the clues and let people know about them, so that
someone on this list may notice something striking that raises an alarm with
them. One of the difficulties of the current e-mail situation is that a
sender is hard-pressed to know what recipients actually get and recipients
have great difficulty letting senders know what's not working or what's
different than intended. In this case, we have the added noise of
intentional misdirection and the programmed behavior intended to accomplish
that in the Klez implementation. (027)
FINAL FORENSIC OBSERVATIONS. So, somebody (probably more than one person)
on this list has an infected computer. The obvious thing to do is use
e-mail scanning Antivirus software that also verifies that *out-going* mail
is not infected. Who wants to be Klez's typhoid Mary, after all? If your
Antivirus software doesn't seem to be working, that is a clue, too. There
are web sites that provide simple downloads that can be run to determine
whether there is a Klez infection, and it is done in a way where the
barriers Klez establishes to avoid discovery are bypassed. I recommend the
description and safeguards offered at
http://www.symantec.com/avcenter/venc/data/w32.klez.removal.tool.html
The removal tool is benign and will tell you whether it finds an infection
or not. More about Klez can be found at
http://www.symantec.com/avcenter/venc/data/w32.klez.gen.html
You will notice that this particular virus has been around since November
2001! (028)
You may also notice the amount of successful social engineering that goes
into the propogation and perpetuation of these beasties. It seems
appropriate to this list, with the interest that many of us have in
improving the capacity of society to achieve coordinated results that
enhance the quality of life for everyone in a sustainable way. There are
technical problems here, in how erstwhile ease-of-use provisions disguise
vulnerabilities. There is also the fact that I noticed this "outbreak" on
BA-OHS-Talk in messages received January 11, 12, and 13, with one more on
January 16, and then nothing until today. And this is the first time I have
said anything about it. After previous past struggles with Klez and its
wily ways on this and other lists, I just figured that it would be handled,
and I took the absence of the usual complaints (or misfired detection
messages from mail servers back to the list) as an indication that all was
in order. Silly me. (029)
NEXT STEPS. Well, so I am going to invent some sort of form for reporting
this kind of thing back to distribution lists when they arise there. I
don't know any other way to alert someone that information on their machine
might be what a Klez infection is using to create impersonations. If I
don't do this, or I wait, I am simply contributing to the pandemic, while
congratulating myself that my system is not infected (possible ironic
outcome there.) (030)
-- orcmid (031)
------------------
Dennis E. Hamilton
http://NuovoDoc.com/
mailto:dennis.hamilton@acm.org
tel. +1-206-932-6970
cell +1-206-779-9430
The Miser Project: http://miser-theory.info/
AIIM DMware: http://DMware.info/ (032)