[841] in winnt
How Klez works
daemon@ATHENA.MIT.EDU (Peter H. Lemieux)
Thu May 9 10:32:27 2002
Message-ID: <000601c1f766$4bce2310$1064a8c0@rememberall>
From: "Peter H. Lemieux" <phl@cyways.com>
To: <ntpartners@mit.edu>
Date: Wed, 8 May 2002 20:36:58 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Dave Broderick" <djbroder@MIT.EDU>
> As I understand it, this virus may be able to spoof email addresses, so
the > *apparent* sender might not even be *guilty*, or even a real person.
The Klez virus appears to grab pairs of addresses from an infected
machine's addressbook, then forges a message containing a replica of
itself with one address as the value of the "From:" header and the other
as value of the "To:" header. The use of forged messages makes Klez much
more insidious than it first appears.
However Klez cannot really mask itself from detection because there are
always a second pair of "from" and "to" addresses over which it has no
control. These are the values attached to the "mail from:" and "rcpt to:"
headers which are part of the SMTP dialog between the mail servers. The
transmitting host sends both these headers before the actual contents of
the message, including the "From:" and "To:" fields.
The value of "mail from:" appears in the Return-Path header which is
usually at the very top of the complete set of mail headers. The value of
"rcpt to:" usually follows immediately thereafter in the top-most
Received: header.
In a message sent by Klez the contents of the Return-Path: header contain
yet a third address found neither in the From: header nor the To:. This
could be yet another forgery by Klez, using a third entry from the address
book to generate the Return-Path. I think, though, that the address in
the Return-Path is, in fact, the address of the person whose machine is
infected.
The SMTP transaction itself generates the rest of the headers that appear
at the top of an Internet message. There can be a number of Received:
headers which track the progress of the message from the originating
server to the receiving server. Ultimately the message arrives at a
server designated to accept mail for the recipient's domain, and the final
SMTP transaction takes places. This transaction generates the top-most
Received: header and a header called "Return-Path:" at the very top of the
message. The final Received: header includes the text "for
<somebody@somewhere.com>". This
However, there are two headers at the top of each received message that
contain the SMTP "envelope" information, the "mail from:" and "rcpt to:"
addresses that are exchanged between the servers during the SMTP
transaction. The "rcpt to:" address appears in the final Received: header
at the top of the message after the word "for". The SMTP sender appears
in the Return-Path header that's always at the top of the message. This
is almost certainly the address of the person whose computer is infected.
Here's one of the dozens of examples that get bounced by my server every
day. This one's from a mailing list I manage:
Return-Path: <bush@verizon.net>
Received: (from uucp@localhost) by mail.cyways.com (8.9.3/8.9.3) id
MAA31736
for <autofraud@lists.nclc.org>; Fri, 3 May 2002 12:38:15 -0400
Received: from out020pub.verizon.net(206.46.170.176), claiming to be
"out020.verizon.net" via SMTP by mail.cyways.com, id smtpdnOoWdM; Fri May
3 12:38:05 2002
Received: from Bveil ([65.115.199.201]) by out020.verizon.net
(InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP
id <20020503163654.KOLW1765.out020.verizon.net@Bveil>
for <autofraud@lists.nclc.org>; Fri, 3 May 2002 11:36:54 -0500
From: dpittman <dpittman@ctg.net>
To: autofraud@lists.nclc.org
This message claims to be from dpittman@ctg.net to
autofraud@lists.nclc.org, the list address. A quick glance shows,
however, that the actual originator of this message is bush@verizon.net,
both from the Return-Path entry and from the fact that the message was
sent originally by out020.verizon.net. (It's true that Verizon could be
the e-mail provider for ctg.net, but I've checked and they're not.)
Instead, the worm is exploiting bush@verizon.net's addressbook, which
happens to contain both the dpittman@ and autofraud@ addresses.
There's are a number of "social engineering" features involved in this.
First, it's not unlikely that two people in my addressbook may know each
other. So the chances are reasonable that the next target will trust the
forged sender and open the attachment. Secondly, the worm has created a
substantial amount of distraction in our economy. I've had a number of
long discussions about this worm, trying to explain to people why the fact
that someone got an infection message from them doesn't mean that they're
infected themselves! It's impressive how effective this worm has been in
creating a ruckus by a simple act of misdirection.
Unfortunately other than pressuring the message originator to clean up his
or her computer, there's little you can do without access to the mail
server itself, which is clearly impossible on lists hosted by MIT.
Peter
Some additional, less relevant, thoughts...
By the way, the Return-Path cannot always be relied upon, either. On Unix
machines running Berkeley sendmail, for instance, the adminstrator
("root") and other designated "trusted" users may forge the SMTP sender
address. So as a trusted user, I can forge a message from A to B that
contains A's address in the Return-Path and send it out my server. List
servers routinely forge the SMTP sender in order to direct bounces and
other errors, which are sent to the Return-Path address, to the list's
owner rather than to the list subscribers.
If you can control the server, as I do, you can filter for viruses at
delivery. My (Linux) mail server blocks delivery of messages with
attached .bat, .scr, .exe, .wav, and .pif, files, routing a copy to a
quarantine mailbox. The administrator is shown a (defanged) copy of the
infected message so she can determine whether the file was incorrectly
blocked and, if so, forward the quarantined copy on to the recipient.
While my solution is home-grown, most commercial antivirus providers offer
server-based virus scanning for popular mail platforms like Exchange and
Groupwise.
