1. 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 Worm Trends

2. © 2004 by Carnegie Mellon University 2 Overview Major Internet worms SQL/Slammer MS-Blaster Welchia/Nachi Witty Sasser Dabber Plexus

3. © 2004 by Carnegie Mellon University 3 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.

4. © 2004 by Carnegie Mellon University 4 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.

5. © 2004 by Carnegie Mellon University 5 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.

6. © 2004 by Carnegie Mellon University 6 Witty – March 19 th, 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.

7. © 2004 by Carnegie Mellon University 7 Sasser – April 30 th, 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.

8. © 2004 by Carnegie Mellon University 8 Dabber – May 13 th, 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.

9. © 2004 by Carnegie Mellon University 9 Plexus – June 3 rd, 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.

10. © 2004 by Carnegie Mellon University 10 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

11. © 2004 by Carnegie Mellon University 11 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

12. © 2004 by Carnegie Mellon University 12 CERT® Contact Information CERT Coordination Center Software Engineering Institute Carnegie Mellon University 4500 Fifth Avenue Pittsburgh PA 15213 USA Hotline: +1 412 268 7090CERT 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:cert@cert.org