Mailing List Archive

On Tuesday 03 February 2004 13:45, Fred wrote:

> This concept was done before (welchia?) but they made a bad choice. My
> intent is not to infect them with a copy of said evil program but only to
> close the infection and inform the user, no harm done.
>
> I'm thinking this would be just as bad as creating a virus, but at least
> someone was fighting for the people!

The problem is, what if your 'benign' fix doesn't account for something it has
never seen before, and (at a long stretch) formats the drive of the machine
it is trying to fix? Which is worse, the fix or the problem?

It's a nice idea, but really and truly, the fix should be made in other ways,
including but not limited to:
* ISPs disabling port 25 outbound from client IP pools unless the client can
prove a reason to have that access. Everyone else either gets blocked, or
use transparent proxying to force port 25 to the ISP mail server.
* ISPs running AV engines on inbound and outbound queues. This has the effect
of slowing mail down a bit, but it's worth it.
* Companies setting their firewalls to not allow 25 outbound from anything but
a registered mail server.
* Companies running combination gateway + server + desktop AV engines

None of those options are cheap, but they are doable. If you can, run the
outbound SMTP checker before the 200 status code returned on the DATA
segment. Deliveries will take a bit longer from the client point of view,
but viruses can be rejected before they have a chance to be passed into the
net.

Fred wrote:
> [...]
> I'm thinking one might be able to create an evil program to scan
for
> these infections and close them down.

I do like the idea, but if I'm not mistaken:

1. Somebody did this for a previous worm.

2. It caused it's own unintended side effects.

3. The author is being prosecuted.

> [...]
> I'm thinking this would be just as bad as creating a virus, but
at
> least someone was fighting for the people!

I think it probably WOULD be just as bad. Something like the good
samaritan/vigilante firing into the school yard to get the bad
guy. The fundamental problem is that it's equally illegal to 'fix'
systems without permission (though I'm no lawyer.) And of course,
left to their own devices, people will come up with 100 different
interpretations of what 'fix' means.

> Sysadmins need to do something to take control of their
networks. At
> least a million infections of .a, that means a lot more zombies
to
> send spam and attack our blacklists.

THAT is the underlying problem. The counter-attack approach is
certainly interesting... and maybe law enforcement
should/could/will do something similar. But it is reactive at
best.

It sure would be nice if ISPs would choke off infected machines.

- Bob

> -----Original Message-----
> From: Duncan Hill [mailto:satalk@nacnud.force9.co.uk]
> Sent: Tuesday, February 03, 2004 8:52 AM
> To: spamassassin-users@incubator.apache.org
> Subject: Re: OT - myDoom why not fight back?
>
>
> On Tuesday 03 February 2004 13:45, Fred wrote:
>
> > This concept was done before (welchia?) but they made a bad
> choice. My
> > intent is not to infect them with a copy of said evil
> program but only to
> > close the infection and inform the user, no harm done.
> >
> > I'm thinking this would be just as bad as creating a virus,
> but at least
> > someone was fighting for the people!
>
> The problem is, what if your 'benign' fix doesn't account for
> something it has
> never seen before, and (at a long stretch) formats the drive
> of the machine
> it is trying to fix? Which is worse, the fix or the problem?
>
> It's a nice idea, but really and truly, the fix should be
> made in other ways,
> including but not limited to:
> * ISPs disabling port 25 outbound from client IP pools unless
> the client can
> prove a reason to have that access. Everyone else either
> gets blocked, or
> use transparent proxying to force port 25 to the ISP mail server.
> * ISPs running AV engines on inbound and outbound queues.
> This has the effect
> of slowing mail down a bit, but it's worth it.
> * Companies setting their firewalls to not allow 25 outbound
> from anything but
> a registered mail server.
> * Companies running combination gateway + server + desktop AV engines
>
> None of those options are cheap, but they are doable. If you
> can, run the
> outbound SMTP checker before the 200 status code returned on the DATA
> segment. Deliveries will take a bit longer from the client
> point of view,
> but viruses can be rejected before they have a chance to be
> passed into the
> net.
>

The best idea I heard so far was ISPs quaruntining the infected machines.
All traffic is blocked, and any website gets diverted to a web page
explaining that the user is infected and how to fix the infection. This does
rewuire active scanning by the ISP.

On a side note, to stop some of the DDOS, is it possible for ISPs to static
route a domain to local 127.0.0.1?? SO for the first day of a scheduled
DDOS, an ISP would route all www.sco.com traffic to the users own system.
That would save a lot of traffic :)

--Chris

We have gone to a CYA mode which is cost effective
and functional for our systems.

Some of the processes (in addition to SA) we perform are:

Scan all In/Out traffic for virus/worms
Disallow the 50 or so executable files in email
Disallow the discovered problematic zip files
Do not accept email from machines without an appropriate MX/A record

We found being the Internet police is too daunting because everybody
has a kid that loves kazaa, et al and folks still think there are 2 Internets,
the safe one and the dangerous one. Of course they all think the places
they visit are on the safe Internet.

I personally do not believe a law will be effective, as the law makers
are no smarter than a box of rocks when it comes to the Internet.
(my personal favorite is the "do not email list")

just my nickle

Greg

"Bob George" <mailings02@ttlexceeded.com> wrote in message
news:005c01c3ea5d$dd136600$011010ac@ttlexceeded.com...

> > I'm thinking one might be able to create an evil program to scan for
> > these infections and close them down.
>
> I do like the idea, but if I'm not mistaken:
>
> 1. Somebody did this for a previous worm.
>
> 2. It caused it's own unintended side effects.
>
> 3. The author is being prosecuted.

Yes, the Nachi worm was designed to get rid of Blaster. See
http://www.microsoft.com/security/antivirus/nachi.asp.

Regards,
John

Well, it's a good idea and has already been done, btw. It's been
discussed many times on the honeypot group. This is definately OT, but
someone tested this on their local network with the blaster virus
(proof-of-concept). End result was it worked, but as I recall their was a
lot of talk about the multiple laws it breaks and such. You could if you
really wanted to, do this via a honeypot, but I wouldn't recommend it.
It's generally frowned upon to take an offensive approach. At any rate,
this is getting really off topic for this group...so I'm just ganna put my
foot in my mouth now. :)

--
Jon

Fred said:
> Sorry for the off topic, the low list traffic had me thinking.
>
> I thought of a dirty trick to fight back against the spammers who are
> creating trojans with backdoors.
>
> I'm thinking one might be able to create an evil program to scan for these
> infections and close them down.
>
> If a backdoor exists which allows myDoom.b to infect the system through
> the previous mydoom.a infection, it should be therotically possible to
> infect the system with a nice trojan to remove previous infections and
> inform the (L)user what just happened.
>
> This concept was done before (welchia?) but they made a bad choice. My
> intent is not to infect them with a copy of said evil program but only to
> close the infection and inform the user, no harm done.
>
> I'm thinking this would be just as bad as creating a virus, but at least
> someone was fighting for the people!
>
> Sysadmins need to do something to take control of their networks. At
> least a million infections of .a, that means a lot more zombies to send
> spam and attack our blacklists.
>
>
> Frederic Tarasevicius
>

This idea is similar to "Filters that fights back":

http://www.paulgraham.com/ffb.html