Sobig.E is driving me crazy

[Gabriele Neukam]

Not only that I received a good deal of those worms from institutioms of
universities all over the world (US, Poland), now I got absolutely
stupid bounces from Yahoo! Groups. Twice, because the infected machine
misused my address twice.


"We are unable to deliver the message from <[email protected]>
to <[email protected]>.

The email address used to send your message is not subscribed to this
group. If you are a member of this group, please be aware that you may
only send messages to this group using the email address(es) you have
registered with Yahoo! Groups. Yahoo! Groups allows you to send
messages
using the email address you originally used to register, or an alternate
email address you specify in your personal settings."


Didn't they announce that they would be starting to fight spam? Why is
their server unable to identify prolific worms, then?



But the craziest mail I received today was:

-------- Mail --------
"DEAR SIR,

THANKS FOR YOUR FOR YOUR ATTACHMENT.

SORRY WE COULD NOT OPEN THE ATTACHMENT KINDLY RESEND
IT TO US IMMEDIATELY.

HOPE TO HEAR FROM YOU SOONEST,

BEST REGARDS,

VINCENT ORJI.



--- (e-mail address removed) wrote: > Please see
the attached zip file for details.

ATTACHMENT part 2 application/x-zip-compressed

name=your_details.zip "
-------- Mail end --------


Vincent Orji is a 419 scammer. Seems they are just as dumb.


Gabriele Neukam

(e-mail address removed)

 

[FromTheRafters]

| Not only that I received a good deal of those worms from institutioms of
| universities all over the world (US, Poland), now I got absolutely
| stupid bounces from Yahoo! Groups. Twice, because the infected machine
| misused my address twice.
|
|
| "We are unable to deliver the message from <[email protected]>
| to <[email protected]>.

<snip>

| Didn't they announce that they would be starting to fight spam? Why is
| their server unable to identify prolific worms, then?

This isn't spam. This is a legitimate failed delivery report.

A legitimate failed delivery report to the wrong person.
If an ISP is prepared to fight spam, then shouldn't they
also have the ability to keep people from getting constantly
bombarded by 'worm caused' bounces to wrong addresses?

I'm sure the OP knows the difference between spam and
failed delivery reports, but the worm forged addy's have
been causing nearly as much unwanted e-mail as spam
does, and in some cases more.

 

[John Elsbury]

A legitimate failed delivery report to the wrong person.
If an ISP is prepared to fight spam, then shouldn't they
also have the ability to keep people from getting constantly
bombarded by 'worm caused' bounces to wrong addresses?

To be fair, there is no right and wrong in the SMTP world. The ISP /
MTA are just doing what they are supposed to do.

The problem is twofold:

(1) viruses sent to nonexistent addresses apparently from existing and
current addresses. This is a fact of life. Even if the item sent
was not a virus, a legitimate bounce would be sent by the receiving
MTA.

There are two possibilities here.
(a) Fix the end-user mail client and OS so that it doesn't get
infected by, and so send viruses; and - to deal with the cases where
the virus incorporates its own smtp engine -
(b) for the ISP to refuse to accept smtp traffic from leased IPs
(dialup etc.) except where the traffic is addressed to the ISP's own
MTA. This is a better bet: some ISPs are already doing this and, as
more risk getting "blacklisted" because they do not, with the result
that their legitimate customers find their e-mail is not getting
through, one can only hope that the rest will do the same.

(c) It would also be nice if people didn't circulate vast numbers of
e-mail addresses. There's a thought: A "good" ISP might refuse to
accept e-mail messages with more than, say, twenty visible addressees;
instead, these would be returned to the sender with instructions on
how to use BCC. This would not stop viruses, of course, but over time
it would significantly reduce the huge pools of e-mail addresses lying
around in people's address books - thus denying the viruses one source
of information, at least.

(2) virus protection (usually corporate, but perhaps at an ISP) which
sends notifications to apparent senders. This approach was once
valid, but now is generally a waste of time. There is not much point
in telling the addressee, either, as in very general terms nobody
meant to send anybody anything.

The solution here is to educate mail system administrators (etc) to
configure the virus detection software so that notifications are not
sent to apparent senders. What I did (and recommend) is:
= I used to get the incoming virus-generated items quarantined.
Typically I would see twenty-thirty a day when a new outbreak started.

= When the numbers got down (say, after three days) to a manageable
level, I used to make a point of identifying the actual source of the
e-mail (from the headers). I would then send a form letter to the
ISP concerned, with the full headers, explaining that their customer
was sending these out and inviting them to identify, advise, and if
necessary disconnect the customer concerned. I also suggested the
approach in 1(b) above at the same time.

Some ISPs were, of course, more responsive than others.

 

[kurt wismer]

| Not only that I received a good deal of those worms from institutioms of
| universities all over the world (US, Poland), now I got absolutely
| stupid bounces from Yahoo! Groups. Twice, because the infected machine
| misused my address twice.
|
|
| "We are unable to deliver the message from <[email protected]>
| to <[email protected]>.

<snip>

| Didn't they announce that they would be starting to fight spam? Why is
| their server unable to identify prolific worms, then?

This isn't spam. This is a legitimate failed delivery report.

well, it's a failed delivery report - whether or not it's legitimate is
another story entirely... i'm surprised nobody has written a worm that
forges av company support addresses so that av companies get a taste for
what their 'feature' can do...

and the point was that yahoo is supposed to be trying to fight spam, so
why then turn around and ignorantly abuse the email system in another
similar way...

 

[John Coutts]

A failed delivery report should only be generated if the message is
accepted and queued for relay. If the delivery is local, then the receiving
server should not accept delivery from the sending server, and that should be
the end of it.

The problem arises when large email server farms such as Yahoo, MSN, Hotmail,
etc, do background processing after accepting the message. They then attempt to
return the message (including the virus) to the return address. This address is
almost always incorrect, and these companies end up generating tons of useless
traffic, and help spread the virus. By doing this, they are also providing a
means for Spammers to indirectly target servers where they are blocked, by
bouncing them off one of the bigger servers knowing full well that they will
returned to the intended victim via a server that is not blocked.

These large Email companies need to come up with a better way of processing the
rejects. If they would adhere to the standards, this problem would not exist.

J.A. Coutts
Systems Engineer
MantaNet/TravPro
**************** REPLY SEPARATER *****************

 

[FromTheRafters]

To be fair, there is no right and wrong in the SMTP world. The ISP /
MTA are just doing what they are supposed to do.

Yeah, I know, but if they can parse mail and filter spam that way,
then surely they could parse for known worm text in the e-mail
subject lines bodies. I assume they do more than just block the
spam from blacklisted domains.

The problem is twofold:

(1) viruses sent to nonexistent addresses apparently from existing and
current addresses. This is a fact of life. Even if the item sent
was not a virus, a legitimate bounce would be sent by the receiving
MTA.

Yes, I see this as a necessary function.

There are two possibilities here.
(a) Fix the end-user mail client and OS so that it doesn't get
infected by, and so send viruses; and - to deal with the cases where
the virus incorporates its own smtp engine -

Easier said than done apparently. )

(b) for the ISP to refuse to accept smtp traffic from leased IPs
(dialup etc.) except where the traffic is addressed to the ISP's own
MTA. This is a better bet: some ISPs are already doing this and, as
more risk getting "blacklisted" because they do not, with the result
that their legitimate customers find their e-mail is not getting
through, one can only hope that the rest will do the same.

I just recently got a message about my trying to send to the
wrong server. My outgoing e-mail (which I purposefully sent)
was refused due to its not being to the ISP's own MTA. The
"glitch" was cleared up shortly thereafter. So now I know that
my ISP was in the process of making that change. This will
indeed make it harder for a worm to use its own SMTP engine
and send to hardcoded servers. But in the case of worms that
guess at SMTP server names or get the same from the registry,
we are still vulnerable.

(c) It would also be nice if people didn't circulate vast numbers of
e-mail addresses. There's a thought: A "good" ISP might refuse to
accept e-mail messages with more than, say, twenty visible addressees;
instead, these would be returned to the sender with instructions on
how to use BCC. This would not stop viruses, of course, but over time
it would significantly reduce the huge pools of e-mail addresses lying
around in people's address books - thus denying the viruses one source
of information, at least.

There are enough other sources for addresses. I think this
would only be a minor consideration. For a while (a long
time ago) I was collecting addresses from chain letters and
writing to some of the previous Fw: Fw: Fw: addresses I
found within and giving them some statistical probabilities
on how many people now had their addresses on their
computers. E-mail worms and spammers have many ways
to get valid addresses.

(2) virus protection (usually corporate, but perhaps at an ISP) which
sends notifications to apparent senders. This approach was once
valid, but now is generally a waste of time. There is not much point
in telling the addressee, either, as in very general terms nobody
meant to send anybody anything.

The originating IP# owner (ISP) should be notified, and action
taken. (Yeah...and then I woke up)

The solution here is to educate mail system administrators (etc) to
configure the virus detection software so that notifications are not
sent to apparent senders. What I did (and recommend) is:
= I used to get the incoming virus-generated items quarantined.
Typically I would see twenty-thirty a day when a new outbreak started.

= When the numbers got down (say, after three days) to a manageable
level, I used to make a point of identifying the actual source of the
e-mail (from the headers). I would then send a form letter to the
ISP concerned, with the full headers, explaining that their customer
was sending these out and inviting them to identify, advise, and if
necessary disconnect the customer concerned. I also suggested the
approach in 1(b) above at the same time.

Some ISPs were, of course, more responsive than others.

Well, that at least is positive action on your part. It sounds
like a good approach, and one that could be automated to
some extent.

 

[FromTheRafters]

A failed delivery report should only be generated if the message is
accepted and queued for relay. If the delivery is local, then the receiving
server should not accept delivery from the sending server, and that should be
the end of it.

I didn't understand the above, could you maybe rephrase it?

The problem arises when large email server farms such as Yahoo, MSN, Hotmail,
etc, do background processing after accepting the message. They then attempt to
return the message (including the virus) to the return address. This address is
almost always incorrect, and these companies end up generating tons of useless
traffic, and help spread the virus. By doing this, they are also providing a
means for Spammers to indirectly target servers where they are blocked, by
bouncing them off one of the bigger servers knowing full well that they will
returned to the intended victim via a server that is not blocked.

I think I understand this part, but I'm hoping that the first part
(once understood) will help me to also understand the comment
below.

 

[John Elsbury]

I just recently got a message about my trying to send to the
wrong server. My outgoing e-mail (which I purposefully sent)
was refused due to its not being to the ISP's own MTA. The
"glitch" was cleared up shortly thereafter. So now I know that
my ISP was in the process of making that change. This will
indeed make it harder for a worm to use its own SMTP engine
and send to hardcoded servers. But in the case of worms that
guess at SMTP server names or get the same from the registry,
we are still vulnerable.

<snip>

Not quite. Look at this way. An MTA, spammer's trojan / relaying
program, or virus with its own smtp engine has to connect using smtp
protocol (via port 25 iirc) to an smtp relay somewhere. If you are a
dial-up / adsl customer then the only place that connection can go to
is the ISP's MODEM, then their router / whatever, then onto the
destination IP address.

If the ISP - as yours is doing - refuses to pass that traffic - this
is done at their router - unless the destination IP is the ISP's own
MTA, then that connection attempt will fail. It doesn't matter what
IP address the "malware" is trying to connect to, or where it got it
from: if the router is correctly figured it must fail. The only
thing stopping this from happening now is a combination of ISPs with
poorly set up Acceptable Use Policies, ISPs not enforcing their AUPs,
and (never forget) administrator incompetence / ignorance.

I think we will find, over time, that more ISPs will start doing the
Right Thing because of the spam issues alone, and that ISPs who do not
introduce some controls of this sort will be blacklisted by more and
more "good" ISPs. The pressure will become greater as the "bad"
ISPs become a minority. This is primarily aimed at spam, but the
flow-on effect in terms of viruses will be useful. I have already
seen a recent call in the NANAE newsgroup asking for an "internet
death penalty" to be applied to one "spam-friendly" ISP, and I suspect
we will see more of these. In fact, many spam-friendly ISPs' IP
ranges are already blocked wholesale, many administrators refuse to
accept smtp connections from Latin America, China, and so on.

The virus / spam / whatever can still get sent via the ISP's own MTA,
of course, if the connection is made to it, but at least the ISP then
has a chance to analyse the traffic, enforce limits, check for
viruses, detect spam, and so on.

The sooner the better....

 

[Gabriele Neukam]

On that special day, John Elsbury, ([email protected]) said...

(b) for the ISP to refuse to accept smtp traffic from leased IPs
(dialup etc.) except where the traffic is addressed to the ISP's own
MTA. This is a better bet: some ISPs are already doing this and, as
more risk getting "blacklisted" because they do not, with the result
that their legitimate customers find their e-mail is not getting
through, one can only hope that the rest will do the same.

This would be great, but the "bounce" I got *today*, would not be fixed
by this method. It came from IBM, telling "I sent Sobig.E" from an IP
number that belongs to an Austrian (like Waltzer) TFT screens producing
company. This IP number, of course, is fixed, so the checking would be
"valid" for the IP nuber, and only be invalid for the "From:" field.

I would like to cite the message, but it is rather longish. In essence:

----- Excerpt from Mail -----
(header of IBM mail server program)
....
The original message was received at Thu, 10 Jul 2003 00:54:35 -0600
from d03av01.boulder.ibm.com [9.17.193.81]

----- The following addresses had permanent fatal errors -----
<ake(at)raleigh.ibm.com>
(reason: 553 5.3.0 <ake(at)raleigh.ibm.com>... Unregistered userid
ake)
....
(cites "my" mail)
Return-Path: <[email protected]>
Received: from d03as01.boulder.ibm.com (d03av01.boulder.ibm.com
[9.17.193.81])
by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id
h6A6sZ1M085588
for <[email protected]>; Thu, 10 Jul 2003 00:54:35 -0600
Received: from e33.co.us.ibm.com ([9.14.4.131]) by
d03as01.boulder.ibm.com with Microsoft SMTPSVC(5.0.2195.5329);
Thu, 10 Jul 2003 00:54:35 -0600
Received: from NB-JUERGI ([81.223.60.121])
by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6A6sSTP309364
for <[email protected]>; Thu, 10 Jul 2003 02:54:29 -0400
Message-Id: <[email protected]>
From: <[email protected]>
To: <ake(at)raleigh.ibm.com>
Subject: [ProbableSpam] Re: Application
Date: Thu, 10 Jul 2003 8:54:25 +0200
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Jul 2003 06:54:35.0197 (UTC) FILETIME=
[1F6D96D0:01C346B0]
Content-Type: multipart/mixed;
boundary="CSmtpMsgPart123X456_000_00281348"

.... (more boundaries and content codes cited)

your_details.zip is removed from here because it contains a virus.

--CSmtpMsgPart123X456_000_00281348
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Found virus WORM_SOBIG.E in file details.pif (in your_details.zip)
The file is deleted.
----- End of Excerpt -----


What to do, then?


Gabriele Neukam

(e-mail address removed)

 

[FromTheRafters]

<snip>

Not quite. Look at this way. An MTA, spammer's trojan / relaying
program, or virus with its own smtp engine has to connect using smtp
protocol (via port 25 iirc) to an smtp relay somewhere.

Yes, but the 'guessing' I was referring to was the ones that take
the victims' (e-mail address removed) and attempt to connect to
smtp.domain.com ~ or the default server listed in the registry
of the victims machine.

If you are a
dial-up / adsl customer then the only place that connection can go to
is the ISP's MODEM, then their router / whatever, then onto the
destination IP address.

If the ISP - as yours is doing - refuses to pass that traffic - this
is done at their router - unless the destination IP is the ISP's own
MTA, then that connection attempt will fail. It doesn't matter what
IP address the "malware" is trying to connect to, or where it got it
from: if the router is correctly figured it must fail.

Unless it *is* the ISP's own...or am I still missing something?

The only
thing stopping this from happening now is a combination of ISPs with
poorly set up Acceptable Use Policies, ISPs not enforcing their AUPs,
and (never forget) administrator incompetence / ignorance.

Yes, but whacking 'em with a clue-stick may prove as futile
as whacking end users with same.

I think we will find, over time, that more ISPs will start doing the
Right Thing because of the spam issues alone, and that ISPs who do not
introduce some controls of this sort will be blacklisted by more and
more "good" ISPs. The pressure will become greater as the "bad"
ISPs become a minority. This is primarily aimed at spam, but the
flow-on effect in terms of viruses will be useful. I have already
seen a recent call in the NANAE newsgroup asking for an "internet
death penalty" to be applied to one "spam-friendly" ISP, and I suspect
we will see more of these. In fact, many spam-friendly ISPs' IP
ranges are already blocked wholesale, many administrators refuse to
accept smtp connections from Latin America, China, and so on.

Yep, ya gotta hit 'em in the wallet. This will eventually get there.

The virus / spam / whatever can still get sent via the ISP's own MTA,
of course, if the connection is made to it, but at least the ISP then
has a chance to analyse the traffic, enforce limits, check for
viruses, detect spam, and so on.

The sooner the better....

You've got that right...it's long overdue.