RFC: virus handling

[Thomas Zehetbauer]

--=-8t+9gk5k1J22gODjJtFk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Looking at the current outbreak of the Mydoom.A worm I would like to
share and discuss some thoughts:

1.) Virus Detected Notifications
After filtering out the messages generated by the worm itself there
remain a lot of messages generated by automated e-mail scanning
solutions.

1.1.) Configuration
Unless the virus scanner provides special handling for worms and virii
which knowingly use a faked sender address it should not send out
notification messages unless the administrator has been warned that
these notification messages may not reach the intended recipient and has
still enabled this feature.

1.2.) Format
These messages cannot be easily filtered because they come in many
different formats and do often not contain any useful information at
all.

1.2.1.) Standardization
To allow filtering of these messages they should always carry the text
'possible virus found' in the subject optionally extended by the name of
the virus or the test conducted (eg. heuristics).

1.2.2.) Virus Information
The message should always include the name of the virus found or the
test conducted (eg. forbidden file type).

1.1.2.) Original Message
The notification should never include the original message sent as
otherwise it may send the worm/virus to a previously unaffected third
party or re-infect a system that has already been cleaned.

1.2.) Notification
Regarding wasted time and storage capacity the false notifications sent
out to innocent third parties by many systems are already causing more
damage than the actual worm or virus. Given the current situation of
many unaware or ignorant administrators everyone capable to do so should
tell these people to fix their badly configured e-mail scanners.

2.) Non Delivery Notifications
It seems that this worm is trying to avoid people getting treacherous
non delivery notifications by using obviously faked but otherwise
plausible e-mail addresses. This may cause double bounce messages or
even message loops at badly configured sites.

2.1.) Avoid
Virus filters should therefore be designed and implemented before
checking the legitimacy of the intended recipient. This would also avoid
helping the virus spread by bouncing it to a previously unaffected third
party.

3.) ISPs
It is worth to note that once again primarily individuals using a
commercial provider have been affected by this worm.=20

3.1.) Notification
As these people do mostly not run a SMTP server on their system it is
unfortunately almost impossible to contact them when only knowing their
IP address.

3.1.1.) Abuse Role Account
Providers should provide an adequately stuffed abuse role account to
allow the affected users beeing notified. To ease efficiency messages
sent there should include the IP address, the exact time and date of the
incident and the name of the virus on the subject line.

3.1.2.) e-mail Alias and Web-Interface
Additionally providers should provide e-mail aliases for the IP
addresses of their customers (eg. customer at 127.0.0.1 can be reached
via 127.0.0.1@provider.com) or a web interface with similiar
functionality. The latter should be provided when dynamically assigned
IP addresses are used for which an additional timestamp is required.

3.2.) Disconnect
Providers should grant their customers some grace period to clean their
infection and should thereafter be disconnected entirely or filtered
based on protocol (eg. outgoing SMTP) or content (eg. transparent
smarthost with virus scanner) until they testify that they have cleaned
their system.

Regards
Tom

--=20
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
mail pgp-key-request@hostmaster.org

Experience is what you get when you expected something else.



--=-8t+9gk5k1J22gODjJtFk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQEVAwUAQBfZGGD1OYqW/8uJAQLkVwf/S/EqlV5NNS1njJu380fQQX0p+oI7tZeU
oC24XZF9bCFieVioqUWYWls4u1z9Aobg82dWUIE0LrEdnCihdC XlgPLVG4jTWknK
SxGmloxzF8JpVvmpDYiz2yjjg5TiqtyiKUNZ8ABelAealfAGVC BBKqPwsiT8AyaB
mrIkaDiMwDaR4/wesj3tYiRdh8pyYakX3JjaQnmxxImCAa+4/PYqYgCo31RurtmN
YCf7PgGZEcYb3E11X8NrlZqhsz7ns3Lqclb2eUqErI1yX4K31y v5/EJSjFjLOSXD
TA9HX1GwN8LN5zVNibpNcgVYVkSFPEIOiFaj9AJvT7qdawgb/R6kWg==
=dCCL
-----END PGP SIGNATURE-----

--=-8t+9gk5k1J22gODjJtFk--

[3APA3A]

Dear Thomas Zehetbauer,


--Wednesday, January 28, 2004, 6:45:39 PM, you wrote to bugtraq@securityfocus.com:

TZ> Looking at the current outbreak of the Mydoom.A worm I would like to
TZ> share and discuss some thoughts:

Most of your ideas are already covered by RFC1892/RFC3462. The only
problem is antiviral developers won't learn.


--
~/ZARAZA
Áðîñüòå ñòàðàòüñÿ - íè÷åãî èç ýòîãî íå âûéäåò. (Òâåí)

[Jeremy Mates]

--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

* Thomas Zehetbauer <thomasz@hostmaster.org>
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).

I prefer the term 'malware' instead, to avoid the various worm/virus/
trojan horse/Microsoft Windows distinctions that can be made.

The 'possible virus found' statement might actually work for some
English speakers where the malware in question was not forged from some
other system not under the control of the recipient in question.

Personally, I prefer discarding all malware, and would love to see e-
mail forwarding break in favor of Sender Permitted From (SPF):

http://spf.pobox.com/

> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.

Without even the full message headers to figure out where the message
originated from?

> It seems that this worm is trying to avoid people getting treacherous
> non delivery notifications by using obviously faked but otherwise
> plausible e-mail addresses. This may cause double bounce messages or
> even message loops at badly configured sites.

Some sites configure their e-mail systems this way to prevent 'RCPT TO'
scans from revealing all valid e-mail addresses. Others may use
forwarding services, where the forwarding service has no means of
guessing what addresses the site in question allows.

> Virus filters should therefore be designed and implemented before
> checking the legitimacy of the intended recipient. This would also
> avoid helping the virus spread by bouncing it to a previously
> unaffected third party.

What, instead of a quick 'EHLO, MAIL FROM, RCPT TO, User unknown' a site
instead has to accept every message, scan it for known malware, and then
figure out what to do? I do hope this is not what you are recommending.

> Providers should provide an adequately stuffed abuse role account to
> allow the affected users beeing notified. To ease efficiency messages
> sent there should include the IP address, the exact time and date of
> the incident and the name of the virus on the subject line.

Which name of the malware? Worm.SCO.A? MyDoom? Other? What if the IP
address turns out to be a e-mail relay? Where does one find the original
infected Microsoft system without the full message headers? What if the
mailing list stripped out the previous headers? What if the malware
starts forging the received headers?

> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.

Expensive and hard if not impossible to implement at larger sites. Would
be prone to spamming, and false notifications about e-mail relays that
are not yet catching the latest in malware. And downright useless if the
user does not know or care what their Windows system is doing, is on
vacation, or whose open wireless network is letting someone else release
malware to the Internet.

> Providers should grant their customers some grace period to clean
> their infection and should thereafter be disconnected entirely or
> filtered based on protocol (eg. outgoing SMTP) or content (eg.
> transparent smarthost with virus scanner) until they testify that they
> have cleaned their system.

Others null route infected hosts first (thereby stopping the flow of
malware) instead of waiting. This allows one to close off any open
wireless networks one does not otherwise have the policital clout to
properly disable:

1. Install Microsoft Windows on a laptop.
2. Infect said system with various malware.
3. Connect to open wireless network.
4. Wait for Network Operations to close wireless network port down.

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: https://www.sial.org/jmates.key

iD8DBQFAF/pwqEafhhHD1igRAkqVAKCfJWK3jdKxNWEn31NsvWMYeked2QCg hYXd
woIjxjnRHMkA7va7CzUW/Dw=
=JKmw
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

[Rainer Gerhards]

I agree with most in this post, but not with 3), the ISP actions.

This is not doable for an ISP, not from a ressource (manpower) point of
view and even hardly from a contractual basis. And, no, I am not with an
ISP.

Other than that, I really think the AV vendors should do this. Also, I
hardly can see a point in including the original bounced mail in any
bounce - the orginal headers should be enough. After all, if the senser
is really the sender, shouldn't he know what he sent? ;)

Rainer=20

> -----Original Message-----
> From: Thomas Zehetbauer [mailto:thomasz@hostmaster.org]=20
> Sent: Wednesday, January 28, 2004 4:46 PM
> To: bugtraq@securityfocus.com
> Subject: RFC: virus handling
>=20
> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:
>=20
> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there
> remain a lot of messages generated by automated e-mail scanning
> solutions.
>=20
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address it should not send out
> notification messages unless the administrator has been warned that
> these notification messages may not reach the intended=20
> recipient and has
> still enabled this feature.
>=20
> 1.2.) Format
> These messages cannot be easily filtered because they come in many
> different formats and do often not contain any useful information at
> all.
>=20
> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by=20
> the name of
> the virus or the test conducted (eg. heuristics).
>=20
> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).
>=20
> 1.1.2.) Original Message
> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.
>=20
> 1.2.) Notification
> Regarding wasted time and storage capacity the false=20
> notifications sent
> out to innocent third parties by many systems are already causing more
> damage than the actual worm or virus. Given the current situation of
> many unaware or ignorant administrators everyone capable to=20
> do so should
> tell these people to fix their badly configured e-mail scanners.
>=20
> 2.) Non Delivery Notifications
> It seems that this worm is trying to avoid people getting treacherous
> non delivery notifications by using obviously faked but otherwise
> plausible e-mail addresses. This may cause double bounce messages or
> even message loops at badly configured sites.
>=20
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before
> checking the legitimacy of the intended recipient. This would=20
> also avoid
> helping the virus spread by bouncing it to a previously=20
> unaffected third
> party.
>=20
> 3.) ISPs
> It is worth to note that once again primarily individuals using a
> commercial provider have been affected by this worm.=20
>=20
> 3.1.) Notification
> As these people do mostly not run a SMTP server on their system it is
> unfortunately almost impossible to contact them when only=20
> knowing their
> IP address.
>=20
> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account to
> allow the affected users beeing notified. To ease efficiency messages
> sent there should include the IP address, the exact time and=20
> date of the
> incident and the name of the virus on the subject line.
>=20
> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.
>=20
> 3.2.) Disconnect
> Providers should grant their customers some grace period to=20
> clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they=20
> have cleaned
> their system.
>=20
> Regards
> Tom
>=20
> --=20
> T h o m a s Z e h e t b a u e r ( TZ251 )
> PGP encrypted mail preferred - KeyID 96FFCB89
> mail pgp-key-request@hostmaster.org
>=20
> Experience is what you get when you expected something else.
>=20
>=20
>=20

[Sascha Wilde]

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 28, 2004 at 04:45:39PM +0100, Thomas Zehetbauer wrote:

> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).

I would prefer to use "X-" Extension Fields in the Mail header for
this. This could be made more flexible and without messing with the
Subject line, which might be localized or used to provide more
speific Information like "mail-worm badthing.C found".

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.

I think this wouldn't work, and it wouldn't be a good idea in general.
Thirst of all, most privat customers use dynamic IPs, so the address
wouldn't belong to one specific user. Furthermore these addresses
would be easy to guess (in most cases even _known_) and a great target
for spamers and worms, and finaly the average customer isn't captable
of distinguishing a false virus-warning from a real one -- there are
many hoax out there, and some worms already spread using faked
virus-warnings, so I think sending Virus-Warnings via eMail to
end-users isn't a good idea at all.
=20
> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they have cleaned
> their system.

Hard measurements like that may be usefull in some cases, but the reasons
must be verified very carefully -- otherwise it would be a easy to
abuse bases for DOS attacs, just by sending complains to the ISP.

yust my two cent
cheers
--=20
Sascha Wilde
We're Germans and we use Unix. That's a combination of two=20
demographic groups known to have no sense of humour whatsoever.
-- Hanno Mueller in de.comp.os.unix.programming

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQFAGPoRqL6urpPh1/wRAiQ4AJ9n1Mb+2fvrSZGi9Hvxy0RyB4soHwCdFHqp
LA4f/bZ7eYqQsp7UJXn6rTw=
=7XdL
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--

[Craig Morrison]

And since I missed the Reply all.. For the list at large:

Thomas Zehetbauer wrote:

> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:

Glad to oblige..

>
> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there
> remain a lot of messages generated by automated e-mail scanning
> solutions.

Shut off notifications.

>
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address it should not send out
> notification messages unless the administrator has been warned that
> these notification messages may not reach the intended recipient and has
> still enabled this feature.

Shut off notifications.

>
> 1.2.) Format
> These messages cannot be easily filtered because they come in many
> different formats and do often not contain any useful information at
> all.

Shut off notifications.

>
> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).
>

Shut off notifications.

> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).

Shut off notifications. (Is there a trend appearing here?)

>
> 1.1.2.) Original Message
> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.

Shut off notifications.

>
> 1.2.) Notification
> Regarding wasted time and storage capacity the false notifications sent
> out to innocent third parties by many systems are already causing more
> damage than the actual worm or virus. Given the current situation of
> many unaware or ignorant administrators everyone capable to do so should
> tell these people to fix their badly configured e-mail scanners.

Fire the admins..

Shut off notifications.

>
> 2.) Non Delivery Notifications

[much snippage]

Just about everything you have stated to this point can be covered by
shutting off notifications. As we have all seen over the past 3 years,
the notifications are useless and only serve to clog up bandwidth and
bring systems down.

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.

Excuse me?

I need to hear more about how this could be implemented and _maintained_
easily.

>
> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they have cleaned
> their system.

Any admin worth their salt is already doing this. If they aren't, they
need to find a new job.

>
> Regards
> Tom
>


--
Craig Morrison

http://www.mtsprofessional.com/
A Win32 email server that works for You.

[Dave Aronson]

On Wed January 28 2004 10:45, Thomas Zehetbauer wrote:

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be
> reached via 127.0.0.1@provider.com)

This would vastly simplify dictionary-attack spamming.

> or a web interface with similiar functionality.

Better, but still might be easily abused by scripting.

> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean
> their infection and should thereafter be disconnected entirely or
> filtered based on protocol (eg. outgoing SMTP) or content (eg.
> transparent smarthost with virus scanner) until they testify that
> they have cleaned their system.

Grace, shmace! Viri can do their dirty work in a matter of seconds.
How about the ISP *immediately* blocks just the port(s) in question?
(Recognizing that that could be *all* ports.) It could unblock after
some time period with no outbound virus infection (or phone home for
orders, etc.) attempts, and of course reblock when any new such
activity is detected.

--
Dave Aronson, Senior Software Engineer, Secure Software Inc.
(Opinions above NOT those of securesw.com unless so stated!)
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
Web: http://destined.to/program http://listen.to/davearonson

[Mike Healan]

> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account

Typo: "stuffed" > "staffed"

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.


I would disagree with 3.1.2. Otherwise you could end up with direct
marketing companies such as Doubleclick harvesting the IP addresses
accessing their banner ads and then sending UCE to those people. Or for
that matter, it could lead to a mass attack with someone sending UCE to
every IP address allocated to an ISP. *Someone* probably will be using
that IP and spammers clearly don't care who sees their spam.

Otherwise I entirely agree with this. Bouncing a virus-infected email is
worse than useless. It is active participation in the distribution of
the worm and the damage to networks it is causing.

Regards,

Mike Healan
Editor
www.spywareinfo.com

----- Original Message -----
From: "Thomas Zehetbauer" <thomasz@hostmaster.org>
To: <bugtraq@securityfocus.com>
Sent: Wednesday, January 28, 2004 10:45 AM
Subject: RFC: virus handling

[Pavel Levshin]

Hello, Thomas!
You wrote to <bugtraq@securityfocus.com> on Wed, 28 Jan 2004 16:45:39 +0100:

TZ> 1.1.) Configuration
TZ> Unless the virus scanner provides special handling for worms and virii
TZ> which knowingly use a faked sender address it should not send out
TZ> notification messages unless the administrator has been warned that
TZ> these notification messages may not reach the intended recipient and
TZ> has still enabled this feature.

Antivirus software MAY be configured to send notifications to local senders
and/or recipients, i.e. to domains which are handled by this server.
Antivirus filtering software SHOULD NOT be configured to send out
notifications to senders or recipients other than local, unless it
distinguishes between faked and real addresses.

I know many administrators who do not care of a few thousands antivirus
reports per day. No "warnings" are accepted. I would like to have some RFC
which disallows such behaviour, so I could send them all to RFC-ignorant BL.

TZ> 1.2.1.) Standardization
TZ> To allow filtering of these messages they should always carry the text
TZ> 'possible virus found' in the subject optionally extended by the name
TZ> of the virus or the test conducted (eg. heuristics).

It is unfair in relation to other languages. Many users do not read in
English, and Subject is supposed to be human-readable field. This
information could have standard form in other header.

TZ> 3.1.2.) e-mail Alias and Web-Interface
TZ> Additionally providers should provide e-mail aliases for the IP
TZ> addresses of their customers (eg. customer at 127.0.0.1 can be reached
TZ> via 127.0.0.1@provider.com) or a web interface with similiar
TZ> functionality. The latter should be provided when dynamically assigned
TZ> IP addresses are used for which an additional timestamp is required.

It tends to be non-standard interface, which is very hard to find and use.


With best regards, Pavel Levshin. E-mail: flicker@mariinsky.ru

[Daniele Orlandi]

Thomas Zehetbauer wrote:
>
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address

I think that virus scanners SHOULD provide some sort of information on
the reliability of headers and SMTP envelope of the virus e-mail and act
accordingly.

I use amavisd-new which has support for listing viruses/worms that fake
the sender's email address. Unfortunatelly the list is external to the
actual virus scanner and has to be updated manually.

This is a major problem, since the administrators are often (an with
good reason) not responsive enought with the rapid floods like the one
we saw recently.

> it should not send out notification messages unless the administrator has
> been warned that these notification messages may not reach the intended
> recipient and has still enabled this feature.

I would say that a virus scanner SHOULD NOT send notifications unless it
has informations on the reliability of the sender's e-mail address.

> 1.2.) Format
> These messages cannot be easily filtered because they come in many
> different formats and do often not contain any useful information at
> all.

They could be formatted with a message/delivery-status part but the
problem wouldn't exist at all if all the notifications are sent to the
real infected recipient.

Bye.

--
Daniele Orlandi

[Piotr KUCHARSKI]

On Wed, Jan 28, 2004 at 04:45:39PM +0100, Thomas Zehetbauer wrote:
> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:

I guess you missed Internet Draft about almost exactly what you want:
http://www.ietf.org/internet-drafts/draft-kucharski-email-viruses-00.txt

Also more general I-D could be helpful:
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-04.txt

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)

[Pavel Kankovsky]

On Wed, 28 Jan 2004, Thomas Zehetbauer wrote:

> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).

Delivery Status Notification (RFC 1894) has many disadvantages but IMHO it
is still better than Yet Another Idiosyncratic Ad-hoc Format.

> 1.1.2.) Original Message
> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.

Notifications, if they are sent at all, should always include at least the
headers of the original message.

(Anyway, people removing a piece of malware from their computer without
taking any steps to prevent future infections (at least reinfections by
the same kind of malware) *deserve* to be reinfected.)

> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they have cleaned
> their system.

Infected hosts should be blocked/disconnected immediately. A filter set up
several hours after the fact (I suppose any reasonable "grace period"
would have to be at least several hours long) is pointless because a
typical 21st century fast spreading worm has already had enough time to
attack everyone in its vicinity.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

[Patrick Proniewski]

On 28 janv. 2004, at 16:45, Thomas Zehetbauer wrote:

> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:


You bring some definitely interesting points here.

I agree with your 1) and 2), but 3) rises some technical concern

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.


could be a really good idea, if not so easy to use for spammers or even
for virii. The moment you setup such a service, spammers/virus coder
will write a script that can reach every single user with an active
connexion. It's a really major drawback I think.


patpro
--
je cherche un poste d'admin-sys Mac/UNIX
(ou une jeune et jolie femme riche)
http://patpro.net/cv.php

[John Fitzgibbon]

There is one standardized feature for virus and other bounce messages, (which
isn't mentioned in the original proposal), which I believe would really help:

A bounce should *always* include a MIME attachment of type
message/rfc822-headers which contains the full headers from the original
mail. This makes it relatively easy to check on the receiving side if the
original "Received: from" headers are valid, and simply drop bounces that
relate to messages that were originally sent with forged headers.

In terms of the general traffic levels that email virus filters generate, it
strikes me as moronic that anti-virus vendors do not implement a flag to
indicate whether a particular virus signature relates to a virus that is
likely to have come from a forged address, (in which case the mail should
simply be dropped, or stored for administrative review). <rant> Given that
they can't even manage that much, it's little surprise that they don't
understand the value in standardizing the bounce or reading a few RFCs.
</rant>

John Fitzgibbon.


On Wednesday 28 January 2004 07:45 am, Thomas Zehetbauer wrote:
> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:
>
> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there
> remain a lot of messages generated by automated e-mail scanning
> solutions.
>
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address it should not send out
> notification messages unless the administrator has been warned that
> these notification messages may not reach the intended recipient and has
> still enabled this feature.
>
> 1.2.) Format
> These messages cannot be easily filtered because they come in many
> different formats and do often not contain any useful information at
> all.
>
> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).
>
> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).
>
> 1.1.2.) Original Message
> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.
>
> 1.2.) Notification
> Regarding wasted time and storage capacity the false notifications sent
> out to innocent third parties by many systems are already causing more
> damage than the actual worm or virus. Given the current situation of
> many unaware or ignorant administrators everyone capable to do so should
> tell these people to fix their badly configured e-mail scanners.
>
> 2.) Non Delivery Notifications
> It seems that this worm is trying to avoid people getting treacherous
> non delivery notifications by using obviously faked but otherwise
> plausible e-mail addresses. This may cause double bounce messages or
> even message loops at badly configured sites.
>
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before
> checking the legitimacy of the intended recipient. This would also avoid
> helping the virus spread by bouncing it to a previously unaffected third
> party.
>
> 3.) ISPs
> It is worth to note that once again primarily individuals using a
> commercial provider have been affected by this worm.
>
> 3.1.) Notification
> As these people do mostly not run a SMTP server on their system it is
> unfortunately almost impossible to contact them when only knowing their
> IP address.
>
> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account to
> allow the affected users beeing notified. To ease efficiency messages
> sent there should include the IP address, the exact time and date of the
> incident and the name of the virus on the subject line.
>
> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1@provider.com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.
>
> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they have cleaned
> their system.
>
> Regards
> Tom

[James C. Slora Jr.]

Craig Morrison wrote Wednesday, January 28, 2004 4:26 PM

> Shut off notifications.

Yup.

Standardizing notifications according to some new RFC would accomplish:
1. Providing another standard message format for socially engineering virus
deliveries.
2. Adding yet another format for notifications - no such RFC would be
universally adopted.
3. Feeding us geeks more useless esoterica to discuss indignantly on the
lists - should noncompliant notifications be a new classification for
rfc-ignorant blacklisting?
4. Continuing bombardment by enough mistaken and virus-faked notifications
to make all notifications worse than useless.
5. Continuing possibilities for using MTA event-handling automation as a
virus distribution vehicle. Possibilities would be more limited, but they
would not be eliminated.
6. It would make it easier to filter the notifications, as the original
poster intended. But I would rather not get them at all when most of them
are mistaken automated notifications.

Dealing with misaddressed mail and incoming infections is boring and costly.
But automated NDRs and virus notifications just spread a larger cost out
across a mail system. They eat the time of the system, the users, their
correspondents, and possibly someone else's admin. They are a selfish way to
push the costs onto others, and probably cost an organization more than they
save in the mail admin's time.

My opinion is you should drop what bad mail you can, and deal with the rest.
Notifications are only useful when they are actionable - they have to be
well-analyzed, and they have to be sent only to people who understand them
and who have the motivation and ability to deal with them. That is a tall
order, which means there should only be a few manually reviewed
notifications.

[Dave Clendenan]

On Wed, Jan 28, 2004 at 02:00:03PM -0800, John Fitzgibbon wrote:
> There is one standardized feature for virus and other bounce messages, (which
> isn't mentioned in the original proposal), which I believe would really help:
>
> A bounce should *always* include a MIME attachment of type
> message/rfc822-headers which contains the full headers from the original
> mail. This makes it relatively easy to check on the receiving side if the
> original "Received: from" headers are valid, and simply drop bounces that
> relate to messages that were originally sent with forged headers.
>

Outstanding idea. If you (or anyone else on the list) already have a
tested procmail recipe for this, please share. If not, let's make one
and share it around...


thanks


--
Dave Clendenan
dave@clendenan.ca

PGP fingerprint: 910E 8400 7A16 822C 9B62 209F 6CAB DEDF BF4B DF75

Subtlety is the art of saying what you think,
and getting out of the way before it is understood

[David Brodbeck]

> -----Original Message-----
> From: Daniele Orlandi [mailto:daniele@orlandi.com]

> I use amavisd-new which has support for listing viruses/worms
> that fake
> the sender's email address. Unfortunatelly the list is external to the
> actual virus scanner and has to be updated manually.

Given that the majority of new viruses forge the sender's email address, I
think the reverse would make more sense -- have a list of viruses that
*don't* forge, and only send notifications for those.

[Matthew Dharm]

--5I6of5zJg18YgZEa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 28, 2004 at 07:24:52PM +0100, Patrick Proniewski wrote:
> On 28 janv. 2004, at 16:45, Thomas Zehetbauer wrote:
>=20
> >Looking at the current outbreak of the Mydoom.A worm I would like to
> >share and discuss some thoughts:
>=20
>=20
> You bring some definitely interesting points here.
>=20
> I agree with your 1) and 2), but 3) rises some technical concern
>=20
> >3.1.2.) e-mail Alias and Web-Interface
> >Additionally providers should provide e-mail aliases for the IP
> >addresses of their customers (eg. customer at 127.0.0.1 can be reached
> >via 127.0.0.1@provider.com) or a web interface with similiar
> >functionality. The latter should be provided when dynamically assigned
> >IP addresses are used for which an additional timestamp is required.
>=20
>=20
> could be a really good idea, if not so easy to use for spammers or even=
=20
> for virii. The moment you setup such a service, spammers/virus coder=20
> will write a script that can reach every single user with an active=20
> connexion. It's a really major drawback I think.

Perhaps something with more limited functionality, then?

Consider a provider who offers the e-mail address of
virusalert@provider.com (name it what you will), to which can be fed an
e-mail consisting of a single line -- that line is the IP address and a
one-word 'name' for the problem.=20

Thus, if I find I'm getting MyDoom.A from 127.2.2.1, I can send a message
that will alert _someone_ (who is presumeably not asleep at the controls).

It also means that general e-mail cannot be sent via this interface -- no
spamming. The provider can take this information, look it up (with the
timestamp the e-mail came in at, if necessary for large dynamic pools), and
take action (the least of which, I hope, would be to notify the end-user).

This could even be done without e-mail at all. A quick HTTP GET/POST could
carry this information. Heck, this could run much like ident/auth
services to a designated machine (i.e. virusalert.provider.com).

Matt

--=20
Matthew Dharm Home: mdharm@one-eyed-alien.net=
=20
Senior Software Designer, Momentum Computer

IT KEEPS ASKING ME WHERE I WANT TO GO TODAY! I DONT WANT TO GO ANYWHERE!
-- Greg
User Friendly, 11/28/97

--5I6of5zJg18YgZEa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAIAq8IjReC7bSPZARAkSKAKCUJ3XYL3mZJ82OBHqMdp M7lpT9YACeN1S7
E2tuA++MHUvMUUBphs8kMUE=
=pq60
-----END PGP SIGNATURE-----

--5I6of5zJg18YgZEa--

[Shaun Bertrand]

Mmmmm,

Well to be quite honest I've had a lot of luck mitigating with an ISP to
solve any DoS issues. Now that's not to say the results have always been
successful, but if you know the means of communication and WHO to
contact within the ISP you may have some luck. I've blocked ICMP floods,
DDoS, DoS, and other propagation attempts at the ISP. The trick is to
convince the ISP that this is also their problem. X company pays X
amount of dollars per month to achieve a certain amount of bandwidth. If
X company is being adversely affected due to outside entities you can
sometimes convince an ISP that they have to do something about it.
Remember the ISP's and RPC DCOM? Almost every ISP now blocks 135/139.=20

I dunno, maybe I'm taking this too much in the context of enterprise
companies vs home users. Anyways... My 1/2 cent.=20

=20

-----Original Message-----
From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20
Sent: Wednesday, January 28, 2004 12:04 PM
To: Thomas Zehetbauer; bugtraq@securityfocus.com
Subject: RE: virus handling

I agree with most in this post, but not with 3), the ISP actions.

This is not doable for an ISP, not from a ressource (manpower) point of
view and even hardly from a contractual basis. And, no, I am not with an
ISP.

Other than that, I really think the AV vendors should do this. Also, I
hardly can see a point in including the original bounced mail in any
bounce - the orginal headers should be enough. After all, if the senser
is really the sender, shouldn't he know what he sent? ;)

Rainer=20

> -----Original Message-----
> From: Thomas Zehetbauer [mailto:thomasz@hostmaster.org]
> Sent: Wednesday, January 28, 2004 4:46 PM
> To: bugtraq@securityfocus.com
> Subject: RFC: virus handling
>=20
> Looking at the current outbreak of the Mydoom.A worm I would like to=20
> share and discuss some thoughts:
>=20
> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there=20
> remain a lot of messages generated by automated e-mail scanning=20
> solutions.
>=20
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii

> which knowingly use a faked sender address it should not send out=20
> notification messages unless the administrator has been warned that=20
> these notification messages may not reach the intended recipient and=20
> has still enabled this feature.
>=20
> 1.2.) Format
> These messages cannot be easily filtered because they come in many=20
> different formats and do often not contain any useful information at=20
> all.
>=20
> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text

> 'possible virus found' in the subject optionally extended by the name=20
> of the virus or the test conducted (eg. heuristics).
>=20
> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the=20
> test conducted (eg. forbidden file type).
>=20
> 1.1.2.) Original Message
> The notification should never include the original message sent as=20
> otherwise it may send the worm/virus to a previously unaffected third=20
> party or re-infect a system that has already been cleaned.
>=20
> 1.2.) Notification
> Regarding wasted time and storage capacity the false notifications=20
> sent out to innocent third parties by many systems are already causing

> more damage than the actual worm or virus. Given the current situation

> of many unaware or ignorant administrators everyone capable to do so=20
> should tell these people to fix their badly configured e-mail=20
> scanners.
>=20
> 2.) Non Delivery Notifications
> It seems that this worm is trying to avoid people getting treacherous=20
> non delivery notifications by using obviously faked but otherwise=20
> plausible e-mail addresses. This may cause double bounce messages or=20
> even message loops at badly configured sites.
>=20
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before=20
> checking the legitimacy of the intended recipient. This would also=20
> avoid helping the virus spread by bouncing it to a previously=20
> unaffected third party.
>=20
> 3.) ISPs
> It is worth to note that once again primarily individuals using a=20
> commercial provider have been affected by this worm.
>=20
> 3.1.) Notification
> As these people do mostly not run a SMTP server on their system it is=20
> unfortunately almost impossible to contact them when only knowing=20
> their IP address.
>=20
> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account to=20
> allow the affected users beeing notified. To ease efficiency messages=20
> sent there should include the IP address, the exact time and date of=20
> the incident and the name of the virus on the subject line.
>=20
> 3.1.2.) e-mail Alias and Web-Interface Additionally providers should=20
> provide e-mail aliases for the IP addresses of their customers (eg.=20
> customer at 127.0.0.1 can be reached via 127.0.0.1@provider.com) or a=20
> web interface with similiar functionality. The latter should be=20
> provided when dynamically assigned IP addresses are used for which an=20
> additional timestamp is required.
>=20
> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean=20
> their infection and should thereafter be disconnected entirely or=20
> filtered based on protocol (eg. outgoing SMTP) or content (eg.=20
> transparent smarthost with virus scanner) until they testify that they

> have cleaned their system.
>=20
> Regards
> Tom
>=20
> --=20
> T h o m a s Z e h e t b a u e r ( TZ251 )
> PGP encrypted mail preferred - KeyID 96FFCB89
> mail pgp-key-request@hostmaster.org
>=20
> Experience is what you get when you expected something else.
>=20
>=20
>=20



DISCLAIMER:
This e-mail, including attachments, may include confidential and/or =
proprietary information, and may be used only by the person or entity to =
which it is addressed. If the reader of this e-mail is not the intended =
recipient or his or her authorized agent, the reader is hereby notified =
that any dissemination, distribution or copying of this e-mail is =
prohibited. If you have received this e-mail in error, please notify the =
sender by replying to this message and delete this e-mail immediately.

[David F. Skoll]

On Thu, 29 Jan 2004, Pavel Levshin wrote:

> Antivirus software MAY be configured to send notifications to local senders
> and/or recipients, i.e. to domains which are handled by this server.
> Antivirus filtering software SHOULD NOT be configured to send out
> notifications to senders or recipients other than local, unless it
> distinguishes between faked and real addresses.

I would add:

"If anti-virus filtering software sends notifications to non-local
recipients, then the sender address of the notifications MUST be an
address that can be replied to, and this reply MUST reach a human
being."

Rationale: When my filtering software bounces all these stupid notifications,
I want a person to get stuck with all the bounce messages, thereby encouraging
him/her to turn off non-local notifications.

--
David.

[Volker Kuhlmann]

> > A bounce should *always* include a MIME attachment of type
> > message/rfc822-headers which contains the full headers from the original
> > mail. This makes it relatively easy to check on the receiving side if the
> > original "Received: from" headers are valid, and simply drop bounces that
> > relate to messages that were originally sent with forged headers.

> Outstanding idea. If you (or anyone else on the list) already have a
> tested procmail recipe for this, please share. If not, let's make one
> and share it around...

Done that:

http://volker.dnsalias.net/soft/procmail/virusnotification.rc

As a quick guess, the received: recipe catches 1/2 - 2/3 of all
responses from those idiots, though I'm not recording exactly which
recipe triggers because I don't care which rubbish it is.

Anything can be improved, of course.

Volker

--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.

[Casper Dik]

>
>
>> -----Original Message-----
>> From: Daniele Orlandi [mailto:daniele@orlandi.com]
>
>> I use amavisd-new which has support for listing viruses/worms
>> that fake
>> the sender's email address. Unfortunatelly the list is external to the
>> actual virus scanner and has to be updated manually.
>
>Given that the majority of new viruses forge the sender's email address, I
>think the reverse would make more sense -- have a list of viruses that
>*don't* forge, and only send notifications for those.

Considering that virus scanners still operate using signatures,
it seems logical to include a flag for each specific virus so that
when it is recognized the virus software knows that they shouldn't
bother me.

(A, and yes, it is a lot of fun that those virus scanner vendors sell
*localized* versions of their software so I've now had them tell me in
more languages and character sets than I care to remember how bloody
incompetent they are.)


Casper

[Ben Wheeler]

On Tue, Feb 03, 2004 at 12:55:24PM -0800, Matthew Dharm wrote:
> Consider a provider who offers the e-mail address of
> virusalert@provider.com (name it what you will), to which can be fed an
> e-mail consisting of a single line -- that line is the IP address and a
> one-word 'name' for the problem.
>
> Thus, if I find I'm getting MyDoom.A from 127.2.2.1, I can send a message
> that will alert _someone_ (who is presumeably not asleep at the controls).

I don't see much difference between this and the normal strategy of
just notifying abuse@ or some other address at the ISP. It is similarly
doomed to failure, because you end up with so many reports that the ISP
cannot possibly verify whether each report is legitimate or not. So they
would have a choice of either:
1. Ignore all reports. "It's not our job to protect our lusers from viruses."
or
2. Automatically take action against all reports. Thus is becomes a great
way to DoS your enemies, just report them as infected.

Since the ISP gets money from its customers, not from people who report
abuse, they will always tend towards option 1 as the number of reports
increases. Reporting abuse or infection is mostly a complete waste
of time, just like reporting spam. It might have worked a few years ago,
it generally doesn't anymore (and the exceptions get fewer all the time).

Our time would be far better invested in ways to prevent the spread of
viruses by other means rather than trying to report infections, after
it's already too late, to either ISPs who will usually do nothing, or
end users who will usually be clueless (otherwise they wouldn't have
got infected in the first place, right?)

Ben

[Shawn McMahon]

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 04, 2004 at 01:44:30PM +0000, Ben Wheeler said:
>=20
> cannot possibly verify whether each report is legitimate or not. So they=
=20
> would have a choice of either:
> 1. Ignore all reports. "It's not our job to protect our lusers from virus=
es."
> or=20
> 2. Automatically take action against all reports. Thus is becomes a great
> way to DoS your enemies, just report them as infected.

You're forgetting a third option:

Find or develop a method of scanning their hosts for the
virus/worm/trojan/foo, and cut off access on the necessary ports when
those hosts are found.

That's what Road Runner, for instance, did in some areas in response to
Code Red and Nimda.

A more extreme position (that I favor) is to put a note in the account's
file that they are infected and causing a problem, then cut off their
access entirely. When they call tech support, they find out they're
infected.

If ISPs do this (and as I've stated, some do), then reporting infections
to them is vital, because unless they understand that it's a large
number of their users, they won't bother dealing with it.


--=20
Shawn McMahon | Let every nation know, whether it wishes us well or ill,
EIV Consulting | that we shall pay any price, bear any burden, meet any
UNIX and Linux | hardship, support any friend, oppose any foe, to assure
http://www.eiv.com| the survival and the success of liberty. - JFK

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQFAIjyIEcl9bQ0RMt0RAs0kAKCX/sZJJCLl9Wem5XE8iU9fm/WihwCffgmq
HXdLB6CBN3SptKfREEZCBQI=
=hi2Q
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--