Network-based file scanning and solution delivery in real time

[0001] The present application claims priority from a provisional patent application filed Aug. 31, 2001 under Ser. No. 60/316,715, which is incorporated herein by reference.

[0002] The present invention relates to system security, and more particularly to real time network-based malicious code handling.

[0003] Network security management is becoming a more difficult problem as networks grow in size and become a more integral part of organizational operations. Attacks on networks are growing both due to the intellectual challenge such attacks represent for hackers and due to the increasing payoff for the serious attacker. Furthermore, the attacks are growing beyond the current capability of security management tools to identify and quickly respond to those attacks. As various attack methods are tried and ultimately repulsed, the attackers will attempt new approaches with more subtle attack features. Thus, maintaining network security is an on-going, ever changing, and increasingly complex problem.

[0004] Computer network attacks can take many forms and any one attack may include many security events of different types. Security events are anomalous network conditions each of which may cause an anti-security effect to a computer network. Security events including stealing confidential or private information; producing network damage through mechanisms such as viruses, worms, or Trojan horses; overwhelming the network's capability in order to cause denial of service; and so forth.

[0005] Of particular concern is the speed at which malicious code can spread throughout a single computer and even a network of computers. Many computers run anti-virus software that can be updated periodically. However, one problem is that only those viruses known prior to the last update are detected. Thus, a new virus may be undetectable. Further, in a network setting, such as a corporate intranet, only some of the computers may be running anti-virus software, while the others remain vulnerable to infection.

[0006] The prior art has attempted to remedy these problems by allowing users to send a file that they suspect is infected with malicious code to an administrator at a remote server via electronic mail. The administrator looks at the files and determines if they are infected. If so, the virus signature is identified and added to a DAT file, which is archived and stored. The user must then retrieve the updated DAT file from a general download site once it becomes available, install it, and perform a local virus scan. By then, hours and, more likely, days have passed, in which time the virus has spread.

[0007] Other prior art systems have attempted to push scanning software onto the client computer to perform a scan on the client computer. Again, the DAT file has been created prior to the user request. Thus, if the virus signature is not included in the DAT file, the scanning software will not detect the virus.

[0008] What is needed is a way to pull or receive a potentially infected file from a client device, create a solution, and send the solution back to the user in real time.

[0009] A system, method and computer program product are provided for network-based real time data scanning. First, data is received from a client at a server utilizing a network such as the Internet. The data is scanned at the server for analysis purposes. A solution is generated at the server if malicious code is found in the data during the scanning. The solution is sent from the server to the client utilizing the network.

[0010] In one aspect, an indication that the data is clean is sent from the server to the client utilizing the network if no malicious code is found in the data during the scanning. The data can be sent from the client to the server via electronic mail. Similarly, the solution can be sent from the server to the client via electronic mail.

[0011] In another aspect, a user interface, such as an HTML page for display on a web browser, is output utilizing the network. The user interface preferably assists a user in sending the data to the server. As an option, a pointer to the solution can be output on the user interface.

[0012] Preferably, the user interface is update at predetermined intervals. As one option, the user interface presents a status update at predetermined intervals. As another option, a graphic is displayed on the user interface for illustrating a progress of the scanning.

[0013] In a further aspect, the solution is automatically installed on the client. The data received from the client can include multiple files that are sent to the server and scanned. These can include, for example, multiple files stored in a folder on the client, multiple files on compact disk, multiple image files, multiple file applications, etc.

[0014] The malicious code can be a virus, worm, trojan, etc. Preferably, the solution includes a removal file, such as a DAT file, which integrates with existing scanning software on the client.

[0015] In one aspect, a determination is made as to whether the malicious code is identified in an existing solution, and if so, the solution is generated using at least a portion of the existing solution and sent to the client. A name for the malicious code can also be generated if the malicious code is not identified in an existing solution. In a further aspect, the data can be launched into memory with pre-existing files. A determination is made as to whether the data alters the pre-existing files. A removal file (i.e., DAT file) for removing the malicious code from the client is generated. The solution includes the removal file.

[0025] FIG. 1 illustrates an exemplary network environment 100 in which the present embodiment may be implemented. As shown, such network environment 100 includes a network 102 that may take any form including, but not limited to a local area network (LAN), a wide area network (WAN) such as the Internet, etc.

[0026] Coupled to the network 102 is a plurality of components 110 which may take the form of desktop computers, lap-top computers, hand-held computers, printers or any other type of computing hardware/software. In the content of the present invention, a plurality of target components 114 are provided which are coupled to at least one scanning computer 112 via the network 102. Such scanning computer 112 may be equipped with an accompanying database 113. In one embodiment, such database 113 may take the form of a virus information manager (VIM). As shown in FIG. 1, each of the target components 114 and various sub-components thereof may be accessed via different ports, i.e. 10, 125, 10345, etc.

[0027] FIG. 2 shows a representative hardware environment associated with the components 110 of FIG. 1, in accordance with one embodiment. Such figure illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 210, such as a microprocessor, and a number of other units interconnected via a system bus 212.

[0028] The workstation shown in FIG. 2 includes a Random Access Memory (RAM) 214, Read Only Memory (ROM) 216, an I/O adapter 218 for connecting peripheral devices such as disk storage units 220 to the bus 212, a user interface adapter 222 for connecting a keyboard 224, a mouse 226, a speaker 228, a microphone 232, and/or other user interface devices such as a touch screen and a digital camera (not shown) to the bus 212, communication adapter 234 for connecting the workstation to a communication network 235 (e.g., a data processing network) and a display adapter 236 for connecting the bus 212 to a display device 238.

[0029] The workstation may have resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC/OS, or UNIX operating system. It will be appreciated that a preferred embodiment may also be implemented on platforms and operating systems other than those mentioned. A preferred embodiment may be written using JAVA, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications.

[0030] FIG. 3 is a flow diagram depicting a process 300 for network-based real time data scanning. As shown, in operation 302, data is received from a client 114 at a server 112 utilizing a network. In operation 304, the data is scanned at the server 112 for analysis purposes. A solution is generated at the server 112 in operation 306 if malicious code is found in the data during the scanning. In operation 308, the solution, or a statement that the data is clean, is sent from the server 112 to the client 114 utilizing the network.

[0031] FIG. 4 illustrates a system 400 and corresponding process flow for providing real time file scanning and solution delivery according to one embodiment of the present invention. The process allows, for example, receipt of data suspected of containing malicious code from a user and/or client device via the Internet and the subsequent sending of an automated response and/or an automated instant fix over the Internet.

[0032] Malicious code includes any program that performs or attempts to perform any unauthorized act. For example, one type of malicious code is a virus. A virus is a software program that self-replicates recursively. Viruses may damage data, cause the computer to crash, display messages, or lie dormant. Another type of malicious code is a worm, which is a virus that usually replicates using computer networks, such as via email or Internet Relay Chat (IRC). Yet another type is a trojan, a program that either pretends to have, or is described as having, a set of useful or desirable features, but actually contains a damaging payload.

[0033] A webserver 402 receives data from a client via a network. The data is a data sample that the client believes may be infected with malicious code, and may comprise one or more files, or portions of a file(s). The system 400 preferably allows the client to upload data directly from the PC to the webserver 402.

[0034] FIG. 5 illustrates a web-based Graphical User Interface (GUI) 500 from which the client can select data for upload to the webserver 402 for scanning. As shown, the client enters the name of the file to be scanned in the entry field 502, or selects the browse button 504. The system GUI can provide a window or browser that allows the user to find the file they want to submit. Selection of the browse button opens the window 600 shown in FIG. 6. The user selects a file from the window 600 and selects the Open button 602 and then the Scan button 604 to begin the upload.

[0035] If the upload fails, a standard web message can be sent to the client indicating upload failure and instructing the client to try again. If the file is password protected and cannot be opened, the client can be prompted to re-submit the file with a password of “infected” or other predefined password. As an option, if the file is greater than 2 MB, the client can be prompted to submit the file via e-mail. (This is an artificial limitation to reduce load on the system 400. See FIG. 4). As another option, if more than one file is submitted by the client, the client can be prompted to submit only one file, or submit the multiple files through e-mail. (This is an artificial limitation to reduce load on the system 400).

[0036] With continued reference to FIG. 4, the webserver 402 pushes the data to an application server 404. The application server 404 pre-processes the submission. The pre-processing includes determining a size of the file received from the client and determining a name and/or description of the sample, preferably based on information from a database 406. If no existing name or description is found in the database 406, the application server 404 can generate a name and/or description for the sample, such as sample23a or user23a for example. If the file is zipped, the application server 404 unpacks it. If the sample is password protected, the application server 404 attempts to open it.

[0037] The application server 404 also validates that the customer is entitled to the service, such as by verifying a user identifier, and requests a ticket ID from the database 406. Then the sample is re-zipped with the ticket ID and can be password protected for submission to a queue. The original submission and repackaged submission are archived on a storage server 408.

[0038] The scanning server 410 runs one or more scanners 412, 414 which attempt to identify whether the original submission and/or repackaged submission contain malicious code. Preferably, the scanning server 410 runs scanning software associated with the McAfee AVERT Virus Identification System (MAVIS), available from McAfee, 3965 Freedom Circle, Santa Clara, Calif. 95054. McAfee is a Network Associates, Inc. company.

[0039] AVERT (Anti-Virus Emergency Response Team) is a division of McAfee, and is an anti-virus research center where scientists research the latest threats, and uncover threats which may arise in the future.

[0040] According to one embodiment the scanning server 410 runs two commandline scanners 412, 414. Scanner 1 412 runs with Weekly released DAT files. Scanner 2 414 runs with Daily released DAT files, i.e., DAT files updated daily.

[0041] If the scanning server 410 detects a virus in the Weekly DATs, a response is forwarded to the response server 416, which can be a web server, an email server, etc. The response server 416 sends the response with a solution to the client on a website (or by email), preferably in under 90 seconds.

[0042] FIG. 7 illustrates a GUI 700 displayed upon detection of a virus. As shown, the GUI displays the Ticket ID 702, a status 704, results 706, the virus name 708, and what DAT 710 and engine 712 were used to detect the virus. A pointer 714 to the updated DAT file can be provided. The client is prompted to update his or her scanning software with the DAT and/or engine. As an option, the update on the client device can be performed automatically without user intervention. The database 406 is updated and the ticket is closed. Note that status updates may be sent to the client indicating the progression of the process.

[0043] If the scanning server 410 detects a virus in the Daily DATs, a response is sent to the client on a website (or by email), preferably in under 90 seconds with the virus name, a link to an EXTRA.DAT (see below), and what engine was used to detect the virus, with some exceptions (see the section below discussing Daily DAT detection exceptions). The database 406 is updated and the ticket is closed.

[0044] The Daily EXTRA.DAT is generated by an EXTRA.DAT generator 418. The generator process looks at the code sources of the DAILY.DATs and pulls the specific driver(s) used to detect the virus. This driver is compiled into an EXTA.DAT that can be used by the client's Anti-Virus software to detect instances of the malicious code on the client device.

[0045] Preferably, the scanning software includes powerful heuristic abilities, making it possible for the scanners 412, 414 to detect or suspect a file is infected with a new virus that has never been seen before. Heuristic detections are identifiable by the wording NEW or Variant preceding the virus name.

• • [0046] New: Indicates a possible brand new strain of virus. As such, the DAILY source does not contain a proper driver capable of reliably cleaning the file. Also, because it is potentially new, the sample is sent to Virus Research immediately.
  • [0047] Variant: Indicates that a known virus has been found, but modified by a virus writer to the point that the DAILY DATs may not be able to reliably clean the virus. The sample is sent to Virus Research immediately.

[0048] Virus Research, as referred to herein, can be a source of malicious code identification data and/or entity to which questionable data is sent for analysis. Note that the information received from and sent to Virus Research may be received from or sent to any other entity or database, including AVERT.

[0049] For a New or Variant detection the client is sent a response via the web that a possible new or variant virus has been found, and that a Virus Research Researcher 426 will respond to him or her shortly. The database 406 is updated and the ticket remains open. The Virus Research response is preferably sent via e-mail.

[0050] In the case that no virus, either known, new, or variant is determined to be found, the client is sent a response that further analysis is required, and to please wait another period of time, such as 30 seconds. The database 406 is updated and the ticket is left open. The sample is then sent to another automated system called the Dustbin 420.

[0051] The dustbin 420 is a custom made database containing CRC codes for files Virus Research has previously processed and determined are safe, or have a specific state desired to be monitored.

• • [0052] Safe: Defined as not viral or malicious.
  • [0053] Specific state: Has multiple definitions such as a Known False alarm, a Joke file, known corruption, etc.

[0054] If the file is determined by the dustbin 420 to be Safe and the scanners 412, 414 did not detect a virus, then the client is sent a web response stating that the file is known safe and not a threat. The response to the client at this point is preferably around the 120 second mark. The database 406 is updated and the ticket is closed. (As an example in the case of FORMAT.COM, a file native to the Microsoft Windows® operating system, the user may be relied upon to user the file responsibly).

[0055] If the dustbin 420 returns a value other than safe, the submission is sent to the Replication Systems 422. The client is sent a response via the web or email that the file requires further analysis. The database 406 is updated and the ticket remains open.

[0056] The replication systems 422 include one or more replicators. Replicators that can be used include Win32, DOS, and Macro replicators. The replicators receive a sample. The sample is launched into memory and allowed to attempt to infect “Goat” files. Goat files are files that have known properties, i.e., it is known exactly what they are, what they look like, and what they do. Whether the replication is successful is determined by whether the Goat files have been modified in some manner. If replication is successful, the Goat files are a different size or have different functionality.

[0057] If replication is successful, the file sample and Goat files are sent to the AutoDAT Generator 424 for final analysis. The AutoDAT generator 424 analyzes the Goat files for the delta (changed) information and creates a DAT driver capable of detection and removal of virus code. The driver is compiled as an EXTRA.DAT and is sent to the client via the web and/or e-mail. The database 406 is updated and the ticket is left open.

[0058] Preferably, when creating EXTRA.DAT files the AutoDAT generator 424 generates a name for any virus found in real time. For example, the AutoDAT generator 424 can name each virus Auto_Driver, prefixed with an identifier such as W32/, WM/, W95/, W95M, W97M, X97M. One example of such a name is W32/Auto_Driver.

[0059] The AutoDAT generator 424 zips the EXTRA.DAT and Goat files into the original zip package created by the application server 404 and stores the sample on the archive server 408.

[0060] The AutoDAT generator 424 sends an e-mail to Virus Research indicating that a new virus has been discovered and a detection/removal driver has been created. The AutoDAT generator 424 updates the database 406 and re-assigns the owner of the ticket to a Researcher 426. The Researcher 426 reviews the sample and driver and checks the driver into the DAILY Source. The Researcher 426 also updates the database 406 and closes the ticket.

[0061] If a file does not successfully replicate this may not be an indicator the file is safe. The file may contain malicious code that is undetectable to the automated scanning system and/or for which a solution cannot be generated. However, these types are not undetectable or resolvable to a human being.

[0062] If the replication is unsuccessful, the client is sent a response via the web indicating that the file has been analyzed but its condition as “safe” has not been determined. The sample is preferably forwarded to a Researcher 426 for manual review. FIG. 8 illustrates a GUI 800 displayed upon the dustbin 420 returning a value other than safe. Referring again to FIG. 4, the AutoDAT generator 424 updates the database 406 and re-assigns the owner of the ticket to a Researcher 426.

[0063] The Virus Research Researcher 426 determines if the file is safe, infected, or special. In the case of an infected or special file, Virus Research responds to the client via e-mail with the solution or answer, which can either contain an EXTRA.DAT as a solution or a note saying the file is safe.

• • [0064] Safe: CRC code is taken of the submitted file and loaded into the dustbin 420.
  • [0065] Infected: If infected a detection/removal driver is created and sent to the client. The driver is checked into the DAILY source.
  • [0066] Special: There are other non-viral types of threats or perceived threats that may be outside the scope of the process, such as joke programs, malicious batch files, or corrupted files. Virus Research responds to the client in an e-mail explaining the analysis.

[0067] When analysis is complete the Researcher 426 manually updates the database 406 and closes the ticket.

[0068] As mentioned above, the system 400 is preferably accessible online utilizing an Internet-based GUI, which allows the system 400 to provide several optional features. One such feature is on-line registration. All users can be required to register before using the system 400. The registration information can then be used to respond to the client, store legacy scan information, and pull geographical statistics on virus prevalence.

[0069] As mentioned above, the system 400 preferably responds to the client in less than 90 seconds, but the scan information of the user can also be stored in a database. The user can then view the scan information on the web at a later time. Thus, the user does not have to wait for a response; he or she can submit the data and then return later to view the scan results.

[0070] FIG. 9 depicts a GUI 900 that is displayed during scanning according to one embodiment. As an option, the GUI 900 displays a graphic while scanning takes place to illustrate the progress to the client. The progress page can be set to automatically refresh after predetermined intervals of time, such as every 10 seconds, 20 seconds, etc.

[0071] While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. For example, any of the network elements may employ any of the desired functionality set forth hereinabove. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.