CONTENTS Title page Declaration Certificate Acknowledgement Abstract List of Figures List of Abbreviations 1 INTRODUCTION 1.1 Introduction 1.

2 Overview 7 1.3 General Features Of Our Project 1.4 Scope Of The Project 1.5 Existing System 1.6 Proposed System 1.7 Hardware Requirements 1.8 Software Requirements 9 10 8 9 9 8 vi 3 4 6 6 i iii iv v

LITERATURE REVIEW 2.1. DEFINTION OF WORM 2.1.1 Naming 2.1.2 Pay Loads 2.1.3 Worms With Good Intent 2.1.4 Protection Against Dangerous Worms 2.2 WORM CONTAINMENT 2.3 CODE RED 2.3.1 CRv1 2.3.2 CRv2

11 11 11 11 12 12 15 16 16

17 18 2.4 SQL SLAMMER 2.4.1 Origin

2.3.3CODE RED II

19 19 21 21 22 24 24 25

2.4.2 Working Of Sql Slammer 2.4.3 Technical Details 2.5 THE WORM CONTAINMENT SCHEME 3 METHODOLOGY AND MATERIAL DESCRIPTION 3.1 DATA FLOW DIAGRAM 3.2 MODULES . 25 3.2.2 Worm Creation Module 3.2.3 Worm Spread Module 3.2.4 Anti-Worm Module 3.2.1 Detector Module

25 26 26

3.2.5 Client Module 3.3 ADVANTAGES 3.4 APPLICATIONS 27 3.5 SCREEN SHOTS 3.5.1 Detector module GUI Design 3.5.2 Worm Spread Module GUI Design 3.5.3 Anti Worm Module Execution 4. 5. 6. 7 8. RESULTS AND DISCUSSIONS CONCLUSION FUTURE PROSPECTS APPENDICES REFERENCES/BIBLIOGRAPHY

26 27

28 28 29 33 34 35 36 37 39

LIST OF FIGURE

FIG NO 1.1

TITLE SPREADING OF WORMS IN NETWORK

PAGE NO 6

1.2

DATA FLOW DIAGRAM

24

LIST OF ABBREVIATIONS API CRV1 CRV2 DNS GUI HTTP IEEE IIS IP IPv4 ISAPI JDBC JVM LPS MSDE Application Program Interface Cod Red Version 1 Cod Red Version 2 Domain Name Server Graphical User Interface Hyper Text Transmission Protocol Institute of Eletrical And Electronics Engineering Internet Information Server Internet Protocol Internet Protocol Version 4 Internet Server Application Program Interface Java Database Connectivity Java Virtual machine Local Preference Scanning worms Microsoft Desktop Engine 4

NIC OLE RMI RCS SQL TCP TRW UDP URL WWW VPN

Network Interface Card Object Linking And Embedding Remote Method Invocation Random Constant Scanning worms Structured Query Language Transmission Control Protocol Threshold Random Walk User Datagram Protocol Uniform Source Locator World Wide Web Virtual Private Network Palo Alto Research Center Inc. Cross Site Scripting

Xerox PARC XSS -

CHAPTER 1: INTRODUCTION

1.1 INTRODUCTION The Internet has become critically important to the financial viability of the national and the global economy. Meanwhile, we are witnessing an upsurge in the incidents of malicious code in the form of computer viruses and worms . Worms are different from computer viruses and are more hazardous in nature in terms of their activity. They are malicious programs that can infect a system and spread rapidly in a network without any human intervention. Whereas a virus can spread inside a system only as a consequence some human intervention such as program execution or any event taking place.

Fig.1.1. Spreading of worms in network One class of such malicious code, known as random scanning worms, spreads itself without human intervention by using a scanning strategy to find vulnerable hosts to infect. Code Red ,SQL Slammer, and Sasser are some of the more famous examples of worms that have caused considerable damage. Network worms have the potential to infect many vulnerable hosts on the Internet before human countermeasures take place. The aggressive scanning traffic generated by the infected hosts has caused network congestion, equipment failure, and blocking of physical facilities such as subway stations, 911 call centers, etc. As a representative example, consider the Code Redworm Version 2 released on19 July 2001 and over a period of less than 14 hours infected more than 359,000 machines. The cost of the epidemic, including subsequent strains of Code Red, has been estimated by Computer Economics to be $2.6 billion. Although Code Red was particularly virulent in its economic impact, it provides an indication of the magnitude of the damage that can be inflicted by such worms. Thus, there is a need to carefully characterize the spread of worms and develop efficient strategies for worm containment. 1.2 OVERVIEW The goal of our research is to provide a model for the propagation of random scanning worms and the corresponding development of automatic containment mechanisms that prevent the spread of worms beyond their early stages. This containment scheme is then extended to protect an enterprise network from a preference scanning worm. A host infected with random scanning worms finds and infects other vulnerable hosts by scanning a list of randomly generated IP addresses. In this paper, we propose a stochastic branching process model for the early phase of worm propagation. We consider the generation-wise evolution of worms, with the hosts that are infected at the beginning of the propagation forming generation zero. The 7

hosts that are directly infected by hosts in generation n are said to belong to generation n + 1. Our model captures the worm spreading dynamics for worms of arbitrary scanning rate, including stealth worms that may turn themselves off at times. We show that it is the total number of scans that an infected host attempts, and not the more restrictive scanning rate, which determines whether worms, can spread. Moreover, we can probabilistically bound the total number of infected hosts. The main idea is to limit the total number of distinct IP addresses contacted (denote the limit as MC) per host over a period we call the containment cycle, which is of the order of weeks or months. We show that the value of MC does not need to be as carefully tuned as in the traditional rate control mechanisms. Further, we show that this scheme will have only marginal impact on the normal operation of the networks. Our scheme is fundamentally different from rate limiting schemes because we are not bounding instantaneous scanning rates. Preference scanning worms are a common class of worms but have received significantly less attention from the research community. Unlike uniform scanning worms, this type of worm prefers to scan random IP addresses in the local network to the overall Internet. We therefore propose a local worm containment system based on restricting a hosts total number of scans to local unused IP addresses (denoted as N). We then use a stochastic branching process model to come up with a bound on the value of N to ensure that the worm spread is stopped.

1.3 GENERAL FEATURES OF OUR PROJECT Low CPU usage. Low memory Requirements. Reliable execution of the system. Quick Manipulations. Ease of use. Compatible to windows platform.

 Consistency maintenance.

1.4 SCOPE OF THE PROJECT In this project we are going model a worm and show the propagation of worms. Then we design a containment which is automated and it is used to contain the spreading of worms beyond its early stages. Thus this project can be used understand the worm propagation. This can be useful to design an Antiworm technique to contain worms. Thus our project can be used in the domain of Network Security. 1.5 EXISTING SYSTEM In previous simulation model uses a combination of the deterministic epidemic model and a general stochastic epidemic model to model the effect of large-scale worm attacks. In an Existing system the complexity of the general stochastic epidemic model makes it difficult to derive results that could be used to contain the worm. In a previous study it is used to detect the presence of a worm by detecting the trend, not the rate, of the observed illegitimate scan traffic. 1.6 PROPOSED SYSTEM This model leads to the development of an automatic worm containment strategy that prevents the spread of a worm beyond its early stage.

Our strategy can effectively contain both fast scan worms and slow scan worms by knowing the worm signature in advance or needing to explicitly detect the worm.

Our automatic worm containment schemes effectively contain the worms and stop its spreading.

1.7 HARDWARE REQUIREMENTS The minimum configuration required to run this project are: Main processor RAM Hard Disk Clock Speed System Bus Speed Cache RAM : Pentium III (or) IV : 128MB : 4.2GB : 550 MHZ : 400 MHz : 256 KB

1.8 SOFTWARE REQUIREMENT Language Front End Design Tools Used Backend Operating System : JDK1.3 (or) Higher. : Swings : JFrame Builder : Microsoft SQL : Windows

A network (LAN) with atleast two systems connected in the network.

10

CHAPTER 2: LITERATURE REVIEW 2.1 DEFINITION OF WORM A computer worm is a self-replicating computer program. It uses a network to send copies of itself to other nodes (computer terminals on the network) and it may do so without any user intervention. Unlike a virus, it does not need to attach itself to an existing program. Worms almost always cause harm to the network, if only by consuming bandwidth, whereas viruses almost always corrupt or modify files on a targeted computer. 2.1.1 NAMING The name worm comes from The Shockwave Rider, a science fiction novel published in 1975 by John Brunner. 2.1.2 PAYLOADS Many worms have been created which are only designed to spread, and don't attempt to alter the systems they pass through. However, as the Morris worm and Mydoom showed, the network traffic and other unintended effects can often cause major disruption. A "payload" is code designed to do more than spread the worm - it might delete files on a host system (e.g., the ExploreZip worm), encrypt files in a cryptoviral extortion attack, or send documents via e-mail. A very common payload for worms is to install a backdoor in the infected computer to allow the creation of a "zombie" under control of the worm author - Sobig and Mydoom are examples which created zombies. 11

Networks of such machines are often referred to as botnets and are very commonly used by spam senders for sending junk email or to cloak their website's address. Spammers are therefore thought to be a source of funding for the creation of such worms, and worm writers have been caught selling lists of IP addresses of infected machines. Others try to blackmail companies with threatened DoS attacks. Backdoors can be exploited by other malware, including worms. Examples include Doomjuice, which spreads better using the backdoor opened by Mydoom, and at least one instance of malware taking advantage of the rootkit and backdoor installed by the Sony/BMG DRM software utilized by millions of music CDs prior to late 2005. 2.1.3 WORMS WITH GOOD INTENT Beginning with the very first research into worms at Xerox PARC there have been attempts to create useful worms. The Nachi family of worms, for example, tried to download and install patches from Microsoft's website to fix vulnerabilities in the host system by exploiting those same vulnerabilities. In practice, although this may have made these systems more secure, it generated considerable network traffic, rebooted the machine in the course of patching it, and did its work without the consent of the computer's owner or user. Other worms, such as XSS worms have been written for research to determine the factors of how worms spread, such as social activity and change in user behavior. Still more worms do very little, or are pranks, such as one that sends the popular picture of the lolowl with the phrase "O RLY?" to a print queue in the infected computer. Most security experts regard all worms as malware, whatever their payload or their writers' intentions. 2.1.4 PROTECTION AGAINST DANGEROUS WORMS Worms spread by exploiting vulnerabilities in operating systems. All vendors supply regular security updates (see "Patch Tuesday"), and if these are installed to a 12

machine then the majority of worms are unable to spread to it. If a vendor acknowledges a vulnerability but has yet to release a security update to patch it, a zero day exploit is possible. However, these are relatively rare. Users need to be wary of opening unexpected email, and should not run attached files or programs, or visit web sites that are linked to such emails. However, as with the ILOVEYOU worm, and with the increased growth and efficiency of phishing attacks, it remains possible to trick the end-user into running a malicious code. Anti-virus and anti-spyware software are helpful, but must be kept up-to-date with new pattern files at least every few days. The use of a firewall is also recommended. In the April-June, 2008, issue of IEEE Transactions on Dependable and Secure Computing, computer scientists describe a potential new way to combat internet worms. The researchers discovered how to contain the kind of worm that scans the Internet randomly, looking for vulnerable hosts to infect. They found that the key is for software to monitor the number of scans that machines on a network send out. When a machine starts sending out too many scans, it is a sign that it has been infected, allowing administrators to take it off line and check it for viruses. Computer worms -- malicious, self propagating programs -- represent a substantial threat to large networks. Since these threats can propagate more rapidly than human response [, automated defenses are critical for detecting and responding to infections. One of the key defenses against scanning worms which spread throughout an enterprise is containment.. Worm containment, also known as virus throttling, works by detecting that a worm is operating in the network and then blocking the infected machines from contacting further hosts. Currently, such containment mechanisms only work against scanning worms because they leverage the anomaly of a local host attempting to connect to multiple other hosts as the means of detecting an infectee. Within an enterprise, containment operates by breaking the network into many small pieces, or cells. Within each cell (which might encompass just a single machine), a

13

worm can spread unimpeded. But between cells, containment attempts to limit further infections by blocking outgoing connections from infected cells. A key problem in containment of scanning worms is efficiently detecting and suppressing the scanning. Since containment blocks suspicious machines, it is critical that the false positive rate be very low. Additionally, since a successful infection could potentially subvert any software protections put on the host machine, containment is best effected inside the network rather than on the end-hosts. We have developed a scan detection and suppression algorithm based on a simplification of the Threshold Random Walk (TRW) scan detector. The simplifications make our algorithm suitable for both hardware and software implementation. We use caches to (imperfectly) track the activity of both addresses and individual connections, and reduce the random walk calculation of TRW to a simple comparison. Our algorithm's approximations generally only cost us a somewhat increased false negative rate; we find that false positives do not increase. Evaluating the algorithm on traces from a large (6,000 host) enterprise, we find that with a total memory usage of 5 MB we obtain good detection precision while staying within a processing budget of at most 4 memory accesses (to two independent banks) per packet. In addition, our algorithm can detect scanning which occurs at a threshold of one scan per minute, much lower than that used by the throttling scheme in, and thus significantly harder for an attacker to evade. Our trace-based analysis shows that the algorithms are both highly effective and sensitive when monitoring scanning on an Internet access link, able to detect low-rate TCP and UDP scanners which probe our enterprise. One deficiency of our work, however, is that we were unable to obtain internal enterprise traces. These can be very difficult to acquire, but we are currently pursuing doing so. Until we can, the efficacy of our algorithm when deployed internal to an enterprise can only be partly inferred from its robust access-link performance.

14

We have also investigated how to enhance containment through cooperation between containment devices. Worm containment systems have an epidemic threshold: if the number of vulnerable machines is few enough relative to a particular containment deployment, then containment will almost completely stop the worm. However, if there are more vulnerable machines, then the worm will still spread exponentially (though less than in the absence of containment). We show that by adding a simple inter-cell communication scheme, the spread of the worm can be dramatically mitigated in the case where the system is above its epidemic threshold. Finally, we discuss inadvertent and malicious attacks on worm containment systems: what is necessary for an attacker to create either false negatives (a worm which evades detection) or false positives (triggering a response when a worm did not exist), assessing this for general worm containment, cooperative containment, and our particular proposed system. We specifically designed our system to resist some of these attacks. 2.2 WORM CONTAINMENT Worm containment is designed to halt the spread of a worm in an enterprise by detecting infected machines and preventing them from contacting further systems. Current approaches to containment are based on detecting the scanning activity associated with scanning worms, as is our new algorithm. Scanning worms operate by picking ``random'' addresses and attempting to infect them. The actual selection technique can vary considerably, from linear scanning of an address space (Blaster), fully random (Code Red), a bias toward local addresses (Code Red II] and Nimda), or even more enhanced techniques (Permutation Scanning). While future worms could alter their style of scanning to try to avoid detection, all scanning worms share two common properties: most scanning attempts result in failure, and infected machines will institute many connection attempts.1Because containment looks for a class of behavior rather than specific worm signatures, such systems can stop new (scanning) worms.

15

Robust worm defense requires an approach like containment because we know from experience that worms can find (by brute force) small holes in firewalls , VPN tunnels from other institutions , infected notebook computers , web browser vulnerabilities , and email-borne attacks to establish a foothold in a target institution. Many institutions with solid firewalls have still succumbed to worms that entered through such means. Without containment, even a single breach can lead to a complete internal infection. Along with the epidemic threshold and sustained sub-threshold scanning, a significant issue with containment is the need for complete deployment within an enterprise. Otherwise, any uncontained-but-infected machines will be able to scan through the enterprise and infect other systems. (A single machine, scanning at only 10 IP addresses per second, can scan through an entire in under 2 hours.)

Thus, we strongly believe that worm-suppression needs to be built into the network fabric. When a worm compromises a machine, the worm can defeat host software designed to limit the infection; indeed, it is already common practice for viruses and mail-worms to disable antivirus software, so we must assume that future worms will disable worm-suppression software. Additionally, since containment works best when the cells are small, this strongly suggests that worm containment needs to be integrated into the network's outer switches or similar hardware elements, as proximate to the end hosts as economically feasible. This becomes even more important for cooperative containment, as this mechanism is based on some cells becoming compromised as a means of better detecting the spread of a worm and calibrating the response necessary to stop it. 2.3 CODE RED 2.3.1 CRv1 On July 12, 2001, a worm began to exploit the aforementioned buffer-overflow vulnerability in Microsoft's IIS webservers. Upon infecting a machine, the worm checks to see if the date (as kept by the system clock) is between the first and the nineteenth of 16

the month. If so, the worm generates a random list of IP addresses and probes each machine on the list in an attempt to infect as many computers as possible. However, this first version of the worm uses a static seed in its random number generator and thus generates identical lists of IP addresses on each infected machine. The first version of the worm spread slowly, because each infected machine began to spread the worm by probing machines that were either infected or impregnable. The worm is programmed to stop infecting other machines on the 20th of every month. In its next attack phase, the worm launches a Denial-of-Service attack against www1.whitehouse.gov from the 20th28th of each month. On July 13th, Ryan Permeh and Marc Maiffret at eEye Digital Security received logs of attacks by the worm and worked through the night to disassemble and analyze the worm. They christened the worm "Code-Red" both because the highly caffeinated "Code Red" Mountain Dew fueled their efforts to understand the workings of the worm and because the worm defaces some web pages with the phrase "Hacked by Chinese". There is no evidence either supporting or refuting the involvement of Chinese hackers with the Code-Red worm. The first version of the Code-Red worm caused very little damage. The worm did deface web pages on some machines with the phrase "Hacked by Chinese." Although the worm's attempts to spread itself consumed resources on infected machines and local area networks, it had little impact on global resources. The Code-Red version 1 worm is memory resident, so an infected machine can be disinfected by simply rebooting it. However, once-rebooted, the machine is still vulnerable to repeat infection. Any machines infected by Code-Red version 1 and subsequently rebooted were likely to be reinfected, because each newly infected machine probes the same list of IP addresses in the same order. 2.3.2 CRv2 At approximately 10:00 UTC in the morning of July 19th, 2001 a random seed variant of the Code-Red worm (CRv2) began to infect hosts running unpatched versions 17

of Microsoft's IIS webserver. The worm again spreads by probing random IP addresses and infecting all hosts vulnerable to the IIS exploit. Code-Red version 2 lacks the static seed found in the random number generator of Code-Red version 1. In contrast, CodeRed version 2 uses random seed, so each infected computer tries to infect a different list of randomly generated IP addresses. This seemingly minor change had a major impact: more than 359,000 machines were infected with Code-Red version 2 in just fourteen hours. Because Code-Red version 2 is identical to Code-Red version 1 in all respects except the seed for its random number generator, its only actual damage is the "Hacked by Chinese" message added to top level webpages on some hosts. However, Code-Red version 2 had a greater impact on global infrastructure due to the sheer volume of hosts infected and probes sent to infect new hosts. Code-Red version 2 also wreaked havoc on some additional devices with web interfaces, such as routers, switches, DSL modems, and printers. Although these devices were not infected with the worm, they either crashed or rebooted when an infected machine attempted to send them a copy of the worm. Like Code-Red version 1, Code-Red version 2 can be removed from a computer simply by rebooting it. However, rebooting the machine does not prevent reinfection once the machine is online again. On July 19th, the probe rate to hosts was so high that many machines were infected as the patch for the .ida vulnerability was applied. 2.3.3 Code Red II On August 4, 2001, an entirely new worm, CodeRedII began to exploit the bufferoverflow vulnerability in Microsoft's IIS webservers. Although the new worm is completely unrelated to the original Code-Red worm, the source code of the worm contained the string "CodeRedII" which became the name of the new worm. Ryan Permeh and Marc Maiffret analyzed CodeRedII to determine its attack mechanism. When a worm infects a new host, it first determines if the system has already been infected. If not, the worm initiates its propagation mechanism, sets up a "backdoor" into the infected machine, becomes dormant for a day, and then reboots the machine. 18

Unlike Code-Red, CodeRedII is not memory resident, so rebooting an infected machine does not eliminate CodeRedII. After rebooting the machine, the CodeRedII worm begins to spread. If the host infected with CodeRedII has Chinese (Taiwanese) or Chinese (PRC) as the system language, it uses 600 threads to probe other machines. All other machines use 300 threads. CodeRedII uses a more complex method of selecting hosts to probe than CodeRed. CodeRedII generates a random IP address and then applies a mask to produce the IP address to probe. The length of the mask determines the similarity between the IP address of the infected machine and the probed machine. 1/8th of the time, CodeRedII probes a completely random IP address. 1/2 of the time, CodeRedII probes a machine in the same / 8 (so if the infected machine had the IP address 10.9.8.7, the IP address probed would start with 10.), while 3/8ths of the time, it probes a machine on the same /16 (so the IP address probed would start with 10.9.). Like Code-Red, CodeRedII avoids probing IP addresses in 224.0.0.0/8 (multicast) and 127.0.0.0/8 (loopback). The bias towards the local /16 and /8 networks means that an infected machine may be more likely to probe a susceptible machine, based on the supposition that machines on a single network are more likely to be running the same software as machines on unrelated IP addresses. The CodeRedII worm is much more dangerous than Code-Red because CodeRedII installs a mechanism for remote, root-level access to the infected machine. Unlike Code-Red, CodeRedII neither defaces web pages on infected machines nor launches a Denial-of-Service attack. However, the backdoor installed on the machine allows any code to be executed, so the machines could be used as zombies for future attacks (DoS or otherwise). A machine infected with CodeRedII must be patched to prevent reinfection and then the CodeRedII worm must be removed. 2.4 SQL SLAMMER 2.4.1 ORIGIN

19

The SQL slammer worm is a computer worm that caused a denial of service on some Internet hosts and dramatically slowed down general Internet traffic, starting at 05:30 UTC on January 25, 2003. It spread rapidly, infecting most of its 75,000 victims within ten minutes. So named by Christopher J. Rouland, the CTO of ISS, Slammer was first brought to the attention of the public by Michael Bacarella - see Notes. Although titled "SQL slammer worm", the program did not use the SQL language; it exploited a buffer overflow bug in Microsoft's flagship SQL Server and Desktop Engine database products, for which a patch had been released six months earlier in MS02-039. Other names include W32.SQLExp.Worm, DDOS.SQLP1434.A, the Sapphire Worm, SQL_HEL, W32/SQLSlammer and Helkern. Sites monitoring the traffic of the Internet such as Internet Storm Center reported significant slowdowns globally, resembling the effects of the Code Red worm in the summer of 2001. Yonhap news agency in South Korea reported that Internet services had been shut down for hours on Saturday, January 25, 2003 nationwide. The effects were mitigated by the fact that it occurred over the weekend. The same attack was reported throughout most of Asia, Europe, and North America. Anti-virus software maker Symantec estimated that at least 22,000 systems were affected worldwide. The Microsoft SQL Server Desktop Engine (MSDE) was affected by the worm and that increased the number of the systems affected. This, together with many home users unaware they have MSDE installed, worsened the effects of this worm. Also, if a computer running MSDE was infected with this worm via the Internet and then connected to a Virtual Private Network, the SQL Servers inside the NAT could be infected. According to a CAIDA-coordinated analysis of the SQL Slammer outbreak, its growth followed an exponential curve with a doubling time of 8.5 seconds in the early phases of the attack, which was only slowed by the collapse of many networks because of the 20

denial of service caused by SQL Slammer's traffic. 90% of all vulnerable machines were infected within 10 minutes, showing that the original estimate for infection speed was roughly correct. 2.4.2 WORKING OF SQL SLAMMER SQL Slammer exploits the way in which MS SQL servers process input on SQL Server Resolution Service port 1434. A specially crafted packet of only 376 bytes sent over the Internet can remotely compromise a vulnerable server. The SQL worm itself is file-less and resides only in memory, much as Code Red. It does not create or delete files but actively scans for other vulnerable MS SQL servers. The aggressive scanning done by SQL Slammer overloaded many networks on January 25, 2003, slowing Internet traffic. SQL Slammer targets systems running MS SQL Server 2000 and/or systems running Microsoft Desktop Engine (MSDE) 2000, which is included in Visual Studio .Net, Asp.net Web Matrix Tool, Office XP Developer Edition, MSDN Universal and Enterprise, Microsoft Access, and Microsoft Application Center 2000. 2.4.3 TECHNICAL DETAILS The worm was based on proof of concept code demonstrated at the Black Hat Briefings by David Litchfield, who had initially discovered the buffer overflow vulnerability that the worm exploited. It is a small piece of code that does little other than generate random IP addresses and send itself out to those addresses. If a selected address happens to belong to a host that is running an unpatched copy of Microsoft SQL Server Resolution Service, the host immediately becomes infected and begins spraying the Internet with more copies of the worm program. Home PCs are generally not vulnerable to this worm unless they have MSDE installed. The worm is so small that it does not contain code to write itself to disk, so it only stays in memory, and it is easy to remove. For example, Symantec provides a free removal utility (see external link below), or it can even be removed by restarting SQL Server (although the machine would likely be immediately reinfected). 21

The worm was made possible by an software security vulnerability in SQL Server first reported by Microsoft on July 24, 2002. A patch had been available from Microsoft for six months prior to the worm's launch, but many installations had not been patched including some at Microsoft. The slowdown was caused by the collapse of numerous routers under the burden of extremely high bombardment traffic from infected servers. Normally, when traffic is too high for routers to handle, the routers are supposed to delay or temporarily stop network traffic. Instead, some routers crashed (became unusable), and the "neighbor" routers would notice that these routers had stopped and should not be contacted (aka "removed from the routing table"). Routers started sending notices to this effect to other routers they knew about. The flood of routing table update notices caused some additional routers to fail, compounding the problem. Eventually the crashed routers' maintainers restarted them, causing them to announce their status, leading to another wave of routing table updates. Soon a significant portion of Internet bandwidth was consumed by routers communicating with each other to update their routing tables, and ordinary data traffic slowed down or in some cases stopped altogether. Ironically because the SQL slammer worm was so small in size, sometimes it was able to get through and legitimate traffic was not. SQL Slammer was the first observed example of a "Warhol worm" a fastpropagating Internet infection of the sort first hypothesized in 2002 in a paper by Nicholas Weaver. Two key aspects contributed to SQL Slammer's rapid propagation. The worm infected new hosts over UDP, and the entire worm (only 376 bytes) fits inside a single packet. As a result, no connection was necessary for an infected host to attempt to infect another machine. Each infected host could instead simply "fire and forget" packets as rapidly as possible (generally hundreds per second). 2.5 THE WORM CONTAINMENT SCHEME The containment system is based on the idea of restricting the total number of

22

scans to unique IP addresses by any host. We assume that we can estimate or bound the percentage of infected host in our system. Our proposed automated worm containment strategy has the following steps: 1. Let MC be the total number of unique IP addresses that a host can contact in a containment cycle. At the beginning of each new containment cycle, set a counter that counts the number of unique IP addresses for each host to be zero. 2. Increment this counter for each host when it scans a new IP address. 3. If a host reaches its scan limit before the end of the containment cycle, it is removed and goes through a heavy-duty checking process to ensure that it is free of infection before being allowed back into the system. When allowed back into the system, its counter is reset to zero. 4. Hosts are thoroughly checked for infection at the end of a containment cycle (one by one to limit the disruption to the network) and their counters reset to zero.

23

CHAPTER 3: METHODS AND MATERIAL DESCRIPTION

Scans each drive ,folder and subfolder in it

Creates a file same as folder name with .myt extension

Worm Creation Module Client 1 Client2 Client3

Changes the IP address of system and restart it

Detector Spreads worm.jar Server Get IP Database

Remote System Worm Spread Module

Updated IP No

Compare

if change

Yes Detector Module 24 AntiWorm Module Victim Host if (.myt )file Delete .myt file folder Scans each drive, from exists Yes the respective folders and subfolders

3.1 DATA FLOW DIAGRAM

Fig 1.2

3.2 MODULES The following are the modules listed in our project: 3.2.1 DETECTOR In this module we have designed a graphical user interfaced design. This module scans the systems that are connected in the Local Area Network (LAN) in which our server system exists.Then it detects the IPv4 addresses of each and every system in the LAN and stores those IP addresses in a database. Then for each and every second it scans the IP address of each system in the database previously stored to update their respective IP addresses.In case at any moment if any of the systems IP address has been changed,then that particular system been identified as victim system infected by worm and that system details are placed in Victims Host window. 3.2.2 WORM CREATION In this module, we create a worm (a demo worm). This module is designed for the creation of worms inside a network. This module scans the system and identifies the 25 Detector Worm Creation Worm Spread Anti worm Client

drives and inside each drive it scans each folders and subfolders till no more subfolders are left.Then it creates a file in the same name as that of the folder name with .myt (dot myt) extension in each and every folder available in that drive.The process is applied recursively for all drives in the system. Then this demo worm tend to change the IP address of the system by just adding fifteen(+15) to the last two octets in the current IP address of the system. After changing the IP address the system gets restarted to update the IP address. 3.2.3 WORM SPREAD In this module we do worm propagation to other sytems in the network. The worm is converted as java archive(JAR) file and send to the systems in the network. Since we are doing a simulation of the worm propagation here, the worm file request is made to all the sytems in the network and that we term as modeling of our project and spread or infected only to those systems that can establish socket connection on the same port id as that of the worm spreading system. 3.2.4 ANTI WORM In this module we detect the systems that have been infected and eliminate the worm infections(if any) from that particular system. Here we scan the drives and inside it the folders and the subfolders for files with dot myt (.myt) extensions and delete those files from those folders. The process is recursive and repeated until the system is free from (.myt) files. This module is done for betterment of the project in order not to affect the system in which the this project is executed and is away from the scope of the IEEE base paper. 3.2.5 CLIENT This module leads to the automatic containment strategy of worms. In this module we have to stop the worm propagation beyond its early stage. A worm scans the hosts 26

available and spreads itself from one host to other host in timely manner. Thus we stop the spreading of worms automatically by using our containment. 3.3 ADVANTAGES Our strategy can effectively contain both fast scan worms and slow scan worms without knowing the worm signature in advance or needing to explicitly detect the worm. Using the branching process model, we are able to provide a precise bound on the total number of scans that ensure that the worm will eventually die out. Further, from our model, we also obtain the probability that the total number of hosts that the worm infects is below a certain level, as a function of the scan limit. In this scheme, we restrict the total number of scans per host to the dark-address space. We derive the precise bound N on the total number of scans to the dark-address space, which ensures that the worm will be contained. 3.4 APPLICATIONS Containing the worms can be applied in any networks to contain the worms. Because worms will not allow the network give its full performance. It degrades the networks performance. It will use the network for its propagation. Thus in order to use the network efficiently and effectively we need to contain the propagation of worms inside our network. Thus containment of worms can be used in office networks, military networks, etc. Generally it can be used in any networks to avoid worm propagation.

27

3.5 SCREENSHOTS 3.5.1 DETECTOR MODULE GUI DESIGN

28

3.5.2 WORM SPREAD MODULE GUI DESIGN

29

BROWSING FOR WORM.JAR

30

SELECTING WORM.JAR FILE

OPENING WORM.JAR FILE

31

OPENING WORM FILE

SPREADING TO CLIENT

32

3.5.3 ANTI-WORM MODULE EXECUTION

33

CHAPTER 4: RESULTS AND DISCUSSION

34

CHAPTER5: CONCLUSION

35

This model allows us to characterize the early phase of worm propagation. Using the branching process model, we are able to provide a precise bound M on the total number of scans that ensure that the worm will eventually die out. Further, from our model, we also obtain the probability that the total number of hosts that the worm infects is below a certain level, as a function of the scan limit M. The insights gained from analyzing this model also allow us to develop an effective and automatic worm containment strategy that does not let the worm propagate beyond the early stages of infection. Our strategy can effectively contain both fast scan worms and slow scan worms without knowing the worm signature in advance or needing to explicitly detect the worm. We show via simulations and real trace data, that the containment strategy is both effective and non intrusive. We extended the worm containment scheme to local preference scanning worms. In this scheme, we restrict the total number of scans per host to the dark-address space. We derive the precise bound N on the total number of scans to the dark-address space, which ensures that the worm will be contained. This containment scheme, combined with firewalls at the network boundary, allows for incremental deployment of the worm containment system without participation of outside networks.

CHAPTER 6:FUTURE PROSPECTS

36

We would like to enhance our project in the following ways in the near future: We like to propose a statistical model for the spread of topology-aware worms and subsequently design mechanisms for automatic containment of such worms. We would also like to characterize the deviation of our proposed branching process model from the ideal stochastic epidemic model, assuming that the values of its rich set of parameters were available. The system in which we run our containment scheme is server client architecture. So the worms are detected only after entering into the FFF network (eg.LAN, WAN) In Future, we like to port our worm containment schemes to edge routers and local routers and to evaluate the performance using real data from enterprise networks, thereby detecting the worms at very earlier stage even before entering into network detected at the router itself.

CHAPTER 7: APPENDICES

37

APPENDIX I DARK ADDRESS SPACE A random-scanning worm randomly selects target IP addresses, some worm scans may hit the address space where no hosts exist. If we monitor on these unused IP addresses, we can detect scans from worms that employ random scanning. These monitored unused IP addresses are called network telescope or Darknet or Dark Address Space. STOCHASTIC ANALYSIS To account for the stochastic property of worm propagation, Rohloff et al. introduced a stochastic density-dependent Markov jump process propagation model for a randomscanning worm drawn from the field of epidemiology. Their analysis indicates that,excluding the early and late growth stages of an epidemic and the time-shifting effects, simulations of a worms propagation using the deterministic and stochastic models are effectively equivalent when the number of vulnerable hosts is sufficiently large. NEED FOR DETERMINISTIC ANALYSIS Therefore, if these effects (those mentioned above) can be ignored, the possible variability of random-scanning-worm epidemics is surprisingly minor. This finding suggests that the deterministic models can be applied to study the performance of worm detection and defense systems.

APPENDIX II 38

Code Red II Detailed information about CodeRed II can be found at eEye and

(http://www.eeye.com/html/Research/Advisories/AL20010804.html) http://aris.securityfocus.com/alerts/codered2/.

Detailed information about Code-Red version 2 can be found at eEye (http://www.eeye.com/html/Research/Advisories/AL20010717.html) and silicon defense (http://www.silicondefense.com/cr/). A machine infected with CodeRedII must be patched to prevent reinfection and then the CodeRedII worm must be removed. A security patch for this vulnerability is available from Microsoft at http://www.microsoft.com/technet/treeview/default.asp? url=/technet/itsolutions/security/topics/codealrt.asp. A tool that disinfects a computer infected with CodeRedII is also available: http://www.microsoft.com/Downloads/details.aspx? displaylang=en&FamilyID=9B7A1710-2B5C-4754-94D4-BC6A81A9A054.

IIS .ida Detailed information about the IIS .ida vulnerability can be found at eEye (http://www.eeye.com/html/Research/Advisories/AD20010618.html). A security patch for this vulnerability is available from Microsoft at http://www.microsoft.com/technet/treeview/default.asp? url=/technet/itsolutions/security/topics/codealrt.asp. CHAPTER8: REFERENCES/BIBLIOGRAPHY .

39

1. The 2. Cisco

Cost

of

Code

Red:

$1.2

Billion,

USA Port

Today

News,

http://www.usatoday.com/tech/news/2001-08-01-code-red-costs.htm,2001. Documentation, Configuring Security, http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/ 12_1e/ swconfig/ port_sec.htm, 2007. 3. H. Andersson and T. Britton, Stochastic Epidemic Models and Their Statistical Analysis, Lecture Notes in Statistics, vol. 151, 2000. 4. J.Bartiomiejczyk and M. Phipps, Preventing Layer 2 Security Threats,http://searchnetworking.te 5. http://www.java2s.com , for clarifications in java codings 6. Z. Chen and C. Ji, Importance-Scanning Worm Using Vulnerable-Host Distribution, in Proc. of IEEE Globecom 2005, St. Louis, MO, 2005 7. Deterministic and Stochastic Models for the detection of Random Constant Scanning Worms ,by Kurt R. R

40