Transcript No Slide Title

Worm Trends
CERT® Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
The CERT Coordination Center is part of the Software Engineering
Institute. The Software Engineering Institute is sponsored by the
U.S. Department of Defense.
© 2004 by Carnegie Mellon University
some images copyright www.arttoday.com
1
Overview
Major Internet worms
• SQL/Slammer
• MS-Blaster
• Welchia/Nachi
• Witty
• Sasser
• Dabber
• Plexus
© 2004 by Carnegie Mellon University
2
SQL/Slammer - Jan 25th, 2003
Memory resident worm that spread via flaw in MS SQL Name
Resolution service
-
1434/UDP
Pseudo random target selection
Points of Interest
-
Single packet contained entire payload (exploit, and complete worm)
Attacked service utilized UDP
These factors combined allowed the worm to shift performance bottlenecks from
system constraints and network latency to a system constrained only by
bandwidth. This allowed a VERY rapid attack pattern.
Slammers performance was less from design as it was from
circumstances lining up for the attacker, but the lesson on
what works was clear. The worm resulted in extensive
network congestion/outage and infected most vulnerable
hosts in the first 10-15 minutes it was released.
© 2004 by Carnegie Mellon University
3
Blaster - Aug 11th, 2003
Attacked via flaw in MS RPC service
-
135/TCP
Semi-sequential scanning algorithm that started locally
DDoS code programmed to attack windowsupdate.com
Utilized TFTP and bind shellcode to propagate
Points of Interest
-
Attacked a core OS service versus application
Directly based on public exploit code
SYN flood DDoS attack feature which became common in subsequent Malware
Crashed RPC service after remote shell was terminated (after infection) because
of a poor function call choice
Blaster attacked a core OS service. This meant there was a
large vulnerable population to exploit. After Blaster, an
increase in embedded DDoS code was seen. Additionally,
there was active discussion of the code that caused the
RPC service to crash. This issue was fixed in a manual
exploit shortly before the worm was released. The
community had learned from the mistake.
© 2004 by Carnegie Mellon University
4
Welchia/Nachi - Aug 18th, 2003
Basic purpose was to kill MSBlast, patch the
vulnerability used by Blaster (and itself) and then to
delete itself after Jan 1, 2004.
Points of Interest
-
Attempt at “white” worm
Pre-attack ping testing – Improved scanning speed
Patched Vulnerability
Programmed to delete itself after Jan 1, 2004
Lesson learned from this worm was the
unpredictable nature of worms when released into
the wild. Traffic from the scanning routine caused
network congestion / outages.
© 2004 by Carnegie Mellon University
5
Witty – March 19th, 2004
Attacked flaw in ISS product’s Protocol Analysis Module
-
Targeted random UDP ports (port was not relevant due to PAM processing
method)
Random IP selection
DESTRUCTIVE worm attempted to delete data at random disk locations
Points of Interest
-
-
Destructive payload – this is rare in Malware for at least the following reasons:
» Hard to generate money with this kind of attack
» Eventually destroys the infected host and kills itself through disk rot
Released less than 2 days from public announcement
Launched via BOT Network ~ 100 starting points for the worm
This worm was efficient, destructive and highly targeted. The
use of BOT nets to launch the worm worked well and proved
the value of bots in spreading worms.
© 2004 by Carnegie Mellon University
6
Sasser – April 30th, 2004
Attacked flaw via MS LSASS service
(MS bulletin MS04-011)
-
445/TCP
Multiple target selection methods
Points of Interest
-
Insecure code – implemented an ftp daemon that contained a buffer overflow
vulnerability
Later variant utilized the pre-attack ping seen in Nachi
Attempts to kill certain variants of Bagle virus
Netsky virus authors claimed authorship
Two main points of interest in this code are the
insecure code it introduced to the system and the
possibility that is was used as a combat weapon
against a rival intruder group.
© 2004 by Carnegie Mellon University
7
Dabber – May 13th, 2004
Attacked systems infected with Sasser worm via vulnerability
introduced in the Sasser ftp daemon code.
Installed backdoor shell for future control of host
Points of Interest
-
Exploited vulnerability in existing Malware
Taught the ability of the Malware community to discover and
leverage weaknesses in their “competitions” products to gain
“market share”. The expected result will be an improvement
in secure coding skills by the Malware authors.
© 2004 by Carnegie Mellon University
8
Plexus – June 3rd, 2004
~322 days from Vendor vulnerability announcement to Worm
Worm that also included other attack techniques such as P2P
and email
Network attack attempted to exploit MSRPC vulnerability from
almost a year before. Ultimate goal was spread of personal
information capture Trojan. It also installed backdoor and
proxy code on the host.
Points of Interest
-
Served as transport for other Malware – The use of the worm to install personal
information stealing code represents the main motivation of the Malware
development community…Money.
Spreading malware via worm propagation has potential with
individual user systems because even though the worm is
very noisy and easily detected by organizations, home users
are less likely to notice the infection. Exploiting older
vulnerabilities also fits with the target audience because they
are also less likely to be up to date on patches.
© 2004 by Carnegie Mellon University
9
Lessons
• Attacking UDP services can be far more efficient
• Enhancements in scanning algorithms
• Optimize code size to improve performance
• Bot nets as launching points for worms
• Worms for combat with rivals
• Worms can be efficient transport for other
Malware
© 2004 by Carnegie Mellon University
10
Trends
Propogation vs. payload
• Greater emphasis on purpose after spreading
(e.g., DoS, patching, backdoors, harvesting
information)
Target platform
• Windows worms much more common than other
platforms (e.g., Linux, Solaris, etc)
Financial incentives are increasing
• Follow the money
• Targeting end-users rather than infrastructure
© 2004 by Carnegie Mellon University
11
CERT® Contact Information
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh PA 15213
USA
Hotline: +1 412 268 7090 CERT personnel answer 8:00 a.m. —
5:00 p.m. EST(GMT-5) / EDT(GMT-4),
and are on call for emergencies
during other hours.
Fax:
+1 412 268 6989
Web:
http://www.cert.org/
Email:
[email protected]
© 2004 by Carnegie Mellon University
12