Enhanced inquiry method for malicious object identification

Enhanced Inquiry Method for Malicious Object Identification Dinesh Kumar Saini, Jabar H. Yousif, Wail M. Omar

Faculty of Computing and Information Technology, Sohar University Sultanate of Oman E-mail: [email protected], [email protected]

Abstract This paper proposes a new technique for malicious object detec-tion and identification. The technique is based on a concept of vi-rus inquiry. The inquiry is an activity that is performed by the malicious object during its initiation. The malicious object uses this activity to ensure its uniqueness in memory. The inquiry can be regarded as a common behavior of malicious object such as viruses. The proposed system is designed using the concept of Ob-ject Oriented Programming (OOP) that treats the operating system, user program, and virus as objects. It is constructed of three ele-mentary objects that perform their activities depending on two da-tabases.

Keywords: Malicious object, Replication Strategy, Computer Security, Computer Viruses, Anti-Virus Design, and Object-Oriented Programming. Introduction Viruses, worms, and Trojan horses are all malicious programs that harms the computer security, but there are differences between the three, and knowing those differences can help users better protect computers from their often damaging effects.[1,2] Surveys have shown that the most common network security problem today is the virus[6,7,]. This type of threat is often communicated via me-dium; it can be am e-mail also. The relative importance of a threat to the user usually depends upon the type of transmission. The im-pact of a threat could have different ramifications between these two types of sites. This document will focus on those threats in-volving viruses, Trojan horses, worms, and scams and there in-quiry methods. A worm is similar to a virus except it is designed to self replicate and can cause damage to systems and large networks. A worm might alter, install, or destroy files and programs. Unlike a virus, a worm does not necessarily require a host file for attach-ment. Worms are easily spread across the Internet via e-mail and chat programs. Virus is a self-replicating program. Some definitions also add the constraint that it has to attach itself to a host program to be able to replicate, while others instead specify different sub-classes of vi-ruses with such constraints [3,4] Hence worms become a sub-class to viruses in that case. Often viruses are said to reside only on the infected host computer, not replicating outside it. The targeting function of what files to infect sometimes is described as the virus blindly infecting almost every executable file it finds, other times the virus targets a specific file. A virus (if not regarded as a sub-class of Trojan horses) often does not have to depend on a careless victim to start its execution. Instead it utilizes vulnerability in the attacked system’s program code.

Viruses can be subdivided into a number of types based on their features. Network viruses This kind of virus is proficient in quickly spreading across a Local Area Network (LAN) or even over the Internet. Usually, it propa-gates through shared resources, such as shared drives and folders. Once it infects a new system, it searches for potential targets by searching the network for other vulnerable systems. Once a new vulnerable system is found, the network virus infects the other sys-tem, and thus spreads over the network. Some of the most noto-rious network viruses are Nimda and SQLSlammer. Some of the category of the viruses are like Macro viruses, Logic bomb, Cross site scripting virus, Sentinels, Archaic forms, Companion virus, Boot sector virus, Multipartite virus. Replication strategies In order to replicate itself, a virus must be permitted to execute code and write to memory. For this reason, many viruses attach themselves to executable files that may be part of legitimate pro-grams. If a user tries to start an infected program, the virus' code may be executed first. Viruses can be divided into two types, on the basis of their behavior when they are executed. Nonresident viruses immediately search for other hosts that can be infected, infect these targets, and finally transfer control to the application program they infected. Resident viruses do not search for hosts when they are started. Instead, a resident virus loads itself into memory on execution and transfers control to the host program. The virus stays active in the background and infects new hosts when those files are accessed by other programs or the operating system itself.

Nonresident viruses Nonresident viruses can be thought of as consisting of a finder module and a replication module. The finder module is responsible for finding new files to infect. For each new executable file the finder module encounters, it calls the replication module to infect that file. For simple viruses the replicator's tasks are to:

• Open the new file

• Check if the executable file has already been infected (if it is, return to the finder module)

• Append the virus code to the executable file

• Save the executable's starting point

SIGSOFT Software Engineering Notes Page 1 May 2009 Volume 34 Number 3

http://doi.acm.org/10.1145/1527202.1527213 DOI: 10.1145/1527202.1527213

• Change the executable's starting point so that it points to the start location of the newly copied virus code

• Save the old start location to the virus in a way so that the virus branches to that location right after its execution.

• Save the changes to the executable file

• Close the infected file

• Return to the finder so that it can find new files for the replicator to infect.

Resident viruses Resident viruses contain a replication module that is similar to the one that is employed by nonresident viruses. However, this module is not called by a finder module. Instead, the virus loads the repli-cation module into memory when it is executed and ensures that this module is executed each time the operating system is called to perform a certain operation. For example, the replication module can be called each time the operating system executes a file. In this case, the virus infects every suitable program that is executed on the computer. Resident viruses are sometimes subdivided into a category of fast infectors and a category of slow infectors. Fast infectors are designed to infect as many files as possible. For in-stance, a fast infector can infect every potential host file that is accessed. This poses a special problem to anti-virus software, since a virus scanner will access every potential host file on a computer when it performs a system-wide scan. If the virus scanner fails to notice that such a virus is present in memory, the virus can "piggy-back" on the virus scanner and in this way infect all files that are scanned. Fast infectors rely on their fast infection rate to spread. The disadvantage of this method is that infecting many files may make detection more likely, because the virus may slow down a computer or perform many suspicious actions that can be noticed by anti-virus software. Slow infectors, on the other hand, are de-signed to infect hosts infrequently. For instance, some slow infec-tors only infect files when they are copied. Slow infectors are designed to avoid detection by limiting their actions: they are less likely to slow down a computer noticeably, and will at most infre-quently trigger anti-virus software that detects suspicious behavior by programs. The slow infector approach does not seem very suc-cessful however. Any program, during its execution, needs some services that are provided by the operating system [6, 7], such as I/O operations, memory allocation, files handling etc. These services can be ac-cessed by calling the appropriate operating system routine with a message that indicates the required operation [8]. Any malicious object should intercept the messages from the user program to the operating system by putting itself between them [9,5]. This means that the virus will receive any user program message to the operat-ing system. Then the virus does its activities and calls the operating system using the original message as shown in figure (1).

In this work, a new method is presented. The proposed method is based on a common virus behavior called " Inquiry " which is a technique used by the virus during the activation stage to ensure that there is no virus of the same type previously activated in memory. According to the outcome of the inquiry, the virus de-cides whether to terminate or continue. The inquiry can be used as a simple way to identify the virus. Also, the inquiry is used to pre-vent virus activation.

Malicious object Decomposition The virus, as any program, can be decomposed into parts [9,6,7]. Each part has a specific function and executed in a specific time during the virus life cycle. General description of these parts and their functions is given below: Initiation Part: It is the first part of virus that is executed during the activation stage of the virus .The activation stage takes place whenever an infected program is executed or during booting opera-tion from an infected disk. The duty of this part is to prepare suita-ble environment in the computer to begin the virus activities. The most important operation performed by this part is the Inquiry. More details are presented in the next section.

Reproduction Part It is responsible of transferring the virus infection by copying the virus into clean (not infected) files or disks. The virus spies on the activities of the operating system that helps to infect more files and disks. The infection operations take different types according to the virus type and/or media to be infected. Virus programs have developed many techniques that make the analysis of the virus dif-ficult. Harmful Effect Part This part is responsible of the harmful effect of the virus. The ef-fect is different from virus to another. The part is executed accord-ing to specific timing technique. For example, virus may play music in certain time, destroy the data on the hard disk in specific date, or damage the infected program after number of execution times. In the present work, we are interested in the initiation part whose functions are identical for all viruses. This work focuses on the inquiry operation of the initiation part.

User Program

Malicious Object

Operating System

Figure1. Malicious object inception



Inquiry Techniques The inquiry is the operation of sending a message and waiting for the corresponding reply. Depending on the reply, the virus discov-ers either a similar virus is previously activated or not. If a similar virus is already activated, the former one will terminate with no more actions. Otherwise, it pursues its activation process.

The inquiry can be accomplished by calling the operating system with a dummy function uniquely chosen by virus designer. If there is a previously activated virus (of the same type) then it will an-swer the inquiry by returning a predetermined message as a result of this call. Otherwise, the operating system will return an invalid function message as a response to that call. It is obvious that each virus has its inquiry message, which must be uniquely selected. It is possible to conclude that the inquiry mes-sage can be used as a virus identification signature. System Architecture The objectivity of the virus motivates such a design. This objec-tivity arises from the known and common behavior and function of viruses, as well as the different and hidden structure of those virus-es. The operating system can be considered as an object for the same reasons.

Inquiry Identificator This object is responsible of distinguishing the virus inquiries from the calls to the operating system. This object detects the virus’s inquiry depending on a database (Virus Inquiry Code DB "VICDB") that contains known virus’s inquiry codes. This object receives the calls directly from the user program and according to the call code; it sends a message to the corresponding object. If the received call is not inquiry then it sends a message (received code) to the “Invalid Function Identificator Object". Otherwise, it means that the message (call) sender is a virus. In this case, one of two actions may be taken. If the virus remover is available, the "Virus Remover Object" is excited with a message that represents the vi-rus identification code. If it is not available, the proposed system is organized as a set of independent objects. Each object has a speci-fied function. These objects interact with each other through mes-sage sending. The whole system spies on the system activities by intercepting the messages that are sent by user program to the op-erating system. In other words, the proposed system monitors the activities of programs under execution, where these programs may be infected by a virus. According to the calls issued by the user program, the system can decide whether a virus infects the pro-gram or not. The system also has the ability of estimating the exis-tence of an unknown virus. Figure (2) represent the Data Flow Diagram (DFD) of the proposed system objects, the operating sys-tem, and user program (probably infected). In this DFD, the user program and operating system represent the source and destination of the data flow respectively. The bubbles in this DFD represent the system objects and directed edges between them represent the object messages.

Function Code

Invalid Function Traffic DataBase

Inquiry Information

Invalid Function

Function Code (Valid)

Virus ID

Code

Function Code

Virus Inquiry Code

Inquiry replay

Function Code

User Program Operating System

Inquiry Identifica-tion

Invalid Function Identification

Invalid Function Processor

Virus Re-mover

Virus Inquiry Code Databas-es

System Dynamism

Figure2. Description of the system objects is given below:



object inhibits the virus. This can be achieved by sending back to the virus a message (inquiry reply) that tricks it. This message represents the code that the virus expects, which indicates that a virus of the same type already lies in memory. The object can ob-tain the inquiry reply from the VICDB. Invalid Function Identificator In case of classifying the user program call as not an inquiry mes-sage, the Inquiry Identificator Object passes a message with the call code to the “Invalid Function Identificator Object". This object verifies the received code to see if it is a valid function code or not, where the valid function codes are documented. If it is valid, the operating system is called to achieve the original requested func-tion. Otherwise, it sends the message to the “Invalid Function Pro-cessor Object" to process this function. Invalid Function Processor: "Invalid Function Identification Ob-ject" excites this object when the function is invalid. This function may be an inquiry from unknown virus (newly appeared) or a user defined function. Such function is used to establish the connection between user programs. In the case of invalid function, the object searches the database (Invalid Function Traffic DB) for a record of this function. The existence of such a record means that similar call has been recorded previously. If the two calls are issued from dif-ferent programs then it is an indication for probability of unknown virus existence. The repetition of such calls increases this probabil-ity. In this situation, an alarm message is displayed that explains, to the user, the name of programs that are probably infected. Whether the call is issued for the first time or not, its information is record-ed in the database. It is obvious that this system provides the user with early information about any new infection in his computer system.

Updating the VICDB One of the important facilities of the proposed system is the ability of expanding the database by adding new virus inquiry codes. This ability enhances the detection of newly discovered viruses. It is not difficult to find many ways to update the VICDB periodically. For example the user can update his VICDB with new information provided to him through different ways or replace the VICDB file by downloading it from an Internet site. There are many advantag-es of the proposed system. Upgrading the system needs not upgrad-ing the programs but it is enough to update the database. This is more suitable for the user from economic point of view. Also the system can be updated easily to detect up to date viruses. Malicious Attack and Defense Security threats are two types, active and passive; however both can have negative repercussions for the network. There are a num-ber of malicious attacks in addition to virus infestations that can impact the security of an organization’s resources [10, 11, and 12]. Active threats include brute force, masquerading, address spoofing, session hijacking, replay, man-in-the-middle, and dictionary at-tacks. Passive threats include eavesdropping and monitoring. Addi-tional types of programs that are destructive to systems include

logic bombs, Trojan horses, and Worms [5, 6] Malware detector can be used for identifying the malicious code. These detection techniques form a hierarchy of signatures and the detector first searches for the most specific signature and then work its way up the hierarchy. Here is the algorithm for detecting the malicious object

Algorithm to find the signature component

Input: A malware sample M = {hm1, . . . , mni} with n instructions, a program range [L..R], and a malware name σ Output: The leftmost index of a signature component within the given range. Find Leftmost (M, L, R, σ) Begin Sig ← 0 While L ≠ R do C ← (L+R)/2 V ← Encode (M, L, C) If O (V) = σ then L← C Else R← C End V← Encode (M, L,R) if O(V ) ≠ then sig← L Return sig End

Conclusion Malicious object detection and identification is one of the main activity needed to counterpart the malicious object propagation and spread. A technique is suggested which is based on a concept of virus inquiry during the malicious object initiation. The malicious object uses this activity to ensure its uniqueness in memory. References

1. Bimal Kumar Mishra and Dinesh Kumar Saini “Mathe-matical Models on Computer viruses” Elsevier Interna-tional Journal of Applied Mathematics and Computation, Volume 187, Issue 2, 15 April 2007, Pages 929-936.

2. Bimal Kumar Mishra and Dinesh Kumar Saini “SEIRS epidemic model of transmission of malicious objects in computer network” Elsevier International Journal of Ap-



plied Mathematics and Computation, Volume 188, Issue 2, 15 May 2007, Pages 1476-1482.

3. Dinesh Kumar Saini and Hemraj Saini "VAIN: A Sto-chastic Model for Dynamics of Malicious Objects", the ICFAI Journal of Systems Management, Vol.6, No1, pp. 14- 28, February 2008.

4. Hemraj Saini and Dinesh Kumar Saini "Malicious Object dynamics in the presence of Anti Malicious Software” Eu-ropean Journal of Scientific Research ISSN 1450-216X Vol.18 No.3 (2007), pp.491-499 © Euro Journals Pub-lishing, Inc. 2007 http://www.eurojournals.com/ejsr.htm

5. Dinesh Kumar Saini and Hemraj Saini “Proactive Cyber Defense and Reconfigurable Framework for Cyber Secu-rity” International Review on computer and Software (IRCOS) Vol.2. No.2. March 2007, pages 89-98.

6. Robert C. Newman “Cyber crime, identity theft, and fraud: practicing safe internet - network security threats and vulnerabilities” InfoSecCD '06: Proceedings of the 3rd annual conference on Information security curriculum development, September 2006.

7. Okamoto T and Ishida Y “A Distributed Approach against Computer Viruses Inspired by Immune System", IEICE Transaction on Communications, may 2000.

8. Post G and Kagan A, “Management Tradeoffs in Anti-Virus Strategies”, Information and Management, Jan 2000.

9. Mikdam A. Al-Salami, Salah F. Saleh, Sabah A. Ali, “General Virus Detector and Deactivator “, Al-Hadba University College Conf., 2000.

10. Dinesh Kumar Saini and Hemraj Saini "Cyber Wars and Defense: an Introduction” National Symposium on Cyber Forensics and Computer Crimes, 11th - 13th August, 2006, Punjabi university (Patiala)-Punjab.

11. Dinesh Kumar Saini and Hemraj Saini "Cyber Defense: Mathematical Modeling and Simulation, National confe-rence on Mathematical Analysis and its Real Time Appli-cations, 16th -17th September, 2006, University of Berhampur (Berhampur)-Orissa, pp. 106-111.

12. Dinesh Kumar Saini and Hemraj Saini “A Study on Cyber Crime in India” National Seminar on Mathematics and Computer Science, 29-30 November 2005, S.D. (P.G.) College, Muzaffarnagar.

13. Mihai Christodorescu, Somesh Jha “Testing malware de-tectors” ISSTA '04: Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing and analysis July 2004



Documents

Enhanced inquiry method for malicious object identification