Re: Self updating worms?

[Gadi Evron <ge () linuxbox org>]

VX-ers have been trying to get a good grip on updating their creations 
for a while now.

Some attempts were made, as you mentioned, using IRC, web pages and 
network scanning.

Let us examine these techniques for a second.

1. IRC.
It is growing increasingly difficult to locate the echo channels, learn 
the interface commands and discover the right commands as well as gain 
privileges to kill them. And these drone armies are HUGE. Most of them 
are not considered worms at all but Trojan horses.

To do all this you must first find them, and once found. "making like a 
drone" or infiltrating is becoming increasingly difficult over time.

Once one Trojan horse was successfully installed, another soon follows 
through the same vulnerability - "door", or using the successful Trojan 
horse which got in to install yet another. I.e. using a backdoor rather 
than, possibly, the original exploit.

Although this is old and at times not very easy to work out, IRC 
controlled drone armies are huge, about, and successful.

Usually, they are unrelated to "worms", though. As such, much wider 
spread and a lot slower to spread.

2. Web pages.
Once you see the web page in the code or on the network, you can block 
it. You can also try and take the page down with different percentages 
of success - depending heavily on the hosting company and their care of 
their abuse inbox. Still, a very successful technique for worms over 
short periods of time.

History shows that even if updates come weeks later and these pages were 
empty (thus innocent), they will then most than likely still be on the 
air to be used for the update.

3. Network scans.
I.e. find the open backdoor installed by the worm and use it to 
update/install a new one, much like specified above under "IRC".

There are other ways. One recent "trick" was to use the hostile email 
messages an infected host sends out, to send IP lists of infected 
machines in that particular seeding attempt history.

There have been some P2P attempts and the kiddies keep getting better.

Personally? I look at the numbers.

This is no longer a world open only to l33t asm coders. This is what I 
call "open source malware".
Not to be confused with the open source initiatives and communities of 
the Internet. It only means that the source is freely available.

Many VX-ers over the years released their source. From groups such as 
29A through the good old DMSETUP at version 5, and others. Nowadays 
however kiddies can find the source for many of the big names out there, 
freely available, with updates AND support web forums. In contract to 
the closed communities of VX-ers.

See the numbers. See how many of them are SDbots, Agobots and so on and 
so forth.. all originating from the one before them.. but let us not go 
into biological models.

Over a thousand reported malware samples every month. There are a lot 
more. Most of these when they arrive at our doorstep (not known worms we 
all get flooded by, Trojan horses) are identified as something generic 
by heuristics.

It's only going to get worse. Why bother with updating a worm, which is 
a dead end as far as traceability - they want to remain anonymous - when 
they can simply release 30 new ones with minor modifications?

There is more to this, naturally, but I'm trying to make a point.

Worm controlling and drone army creation is going to keep becoming a 
bigger and bigger issue now that organized crime and spammers are 
involved - i.e. the people who see the return on their investment. And 
they do invest.

Point is.. keeping a _trail_ in order to update a network, without 
throwing rocks blindly and hoping for success - leaves a _trail_. It 
doesn't have to be a legal trail, but it can sure lead back to them, 
ruining their infrastructure online and at the end not meet the simple 
test of cost vs. benefit.

There are some promising technologies out there which may be the answer 
for their hopes and our fears... but that's not something I'd like to 
discuss here. They discuss it among themselves and have more resources 
than most security researchers as it is - when it comes to sharing 
information and finding samples.

That's about it in a few lines...

        Gadi Evron.

--
Email: ge () linuxbox org. Backup: ge () warp mx dk.
Phone: +972-50-428610 (Cell).

Jonathan Wilkins wrote:

> It occured to me at CanSec this year that tools such as Core's Impact,
> Immunity's Canvas and the open source Metasploit Framework (not to
> mention the various worm development languages that Tom Ptacek, Joae
> Nazario and Dave Aitel have been discussing) open up a new possibility
> for worm automation.  By using standardized payloads, they allow for
> extraction of injector code.  This opens the possibility of worms
> learning of new exploits in a totally automated fashion.
>
> I know this is no trivial task, but it would allow a stealthy worm to
> continue to exploit new hosts long after it's initial release.  One
> major disadvantage for a slow spreading worms has been that the longer
> it takes to spread, the more hosts will be patched when it finally
> attempts an attack.  If a slow spreading worm was able to get new
> information on current exploits techniques long after initial release
> this disadvantage would disappear.  Previously, worm authors have
> attempted to provide updates through web sites, IRC channels, Usenet,
> and the like, but the communication channels were easily disrupted.  By
> building code into the worm that can identify payloads and extract
> delivery code, the slow spreading worm could compromise thousands of
> hosts without becoming such a obvious presence on the network that it is
> discovered.  Further, since it's already examining network traffic, the
> addition of a cryptographically secure update and control mechanism adds
> obvious value (worm updates via spam?).  
>
> Imagine a worm that starts off by scanning 10000 hosts, in the next
> generation, each instance would only scan 1000, then 100, then 10, then
> 1, then only scan with a 10% probability and so on.  Depending on the
> wait between generations, the vulnerability used could be quite
> different between different instances.
>
> Thoughts?
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave