Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the
2
541
453
B1
TEPZZ 54_45¥B_T
(11)EP 2 541 453 B1
(12)
EUROPEAN PATENT SPECIFICATION
(45) Date of publication and mention of the grant of the patent:
17.12.2014 Bulletin 2014/51
(21) Application number: 12158158.1
(22) Date of filing: 06.03.2012
(51) Int Cl.:
G06F 21/53(2013.01)
(54) System and method for malware protection using virtualization
System und Verfahren zum Schutz vor Malware durch Virtualisierung
Système et procédé pour la protection contre les programmes malveillants au moyen de la virtualisation (84) Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR
(30) Priority: 30.06.2011 US 201113174247
(43) Date of publication of application:
02.01.2013 Bulletin 2013/01
(73) Proprietor: Kaspersky Lab, ZAO Moscow 125212 (RU) (72) Inventors: • Rusakov, Vyacheslav E. 123060 Moscow (RU) • Shiryaev, Alexander V. 123060 Moscow (RU)
(74) Representative: Sloboshanin, Sergej et al von Füner Ebbinghaus Finck Hano Mariahilfplatz 3
81541 München (DE)
(56) References cited:
5 10 15 20 25 30 35 40 45 50 55 Description TECHNICAL FIELD
[0001] The present invention relates generally to the field of computer security and, more specifically, to a sys-tem for protecting applications deployed on a host com-puter from malware using virtualization according to the preamble of claim 7 and to a corresponding method ac-cording to claim 1.
BACKGROUND
[0002] Due to fast proliferation and evolution of mal-ware, such as viruses, worms, Trojans, and other types of computer threats, it becomes harder for computer se-curity specialists to keep track of newly emerging threats even using automated malware detection means. Secu-rity concerns are even higher when secuSecu-rity of confiden-tial or secret personal or corporate information must be protected. Some types of malware are specifically de-signed to attack computers and applications deployed thereon in order to collect confidential or secret user and system information. Therefore, security applications, such as antivirus programs and firewalls, must be con-figured to protect critical system and application objects from unauthorized access.
[0003] One mechanism for system protection from malware is "sandboxing", in which untrusted programs are executed in a secure virtual environment. For exam-ple, US 2010/175104 A1 discloses a system and method that allow a computer user to create a temporary guest running space for application without switching user en-vironment, intercepting thereby calls from applications by reading configuration information in the registry on the operation system and determining whether the regular application space or guest application space should re-ceive the call to achieve the goal or comply with a defined policy. Behavioral sandboxing is also known from US 2011/145926 A1, having thereby a network and a com-puter, wherein the network is communicatively coupled to a source of an executable application and the computer is communicatively coupled to the network and includes a behavioral analysis module and a plurality of execution environments with a standard execution environment and a protected execution environment, wherein the be-havioral analysis module is configured to evaluate char-acteristics of the executable application to determine whether it should be executed within the protected exe-cution environment prior to exeexe-cution of the executable application. The execution of a program can be limited to exclude access to the critical areas or processes of the host system or applications deployed thereon. How-ever, known sandboxing techniques have limitations. For example, they may be ineffective when the host system is already infected by the malware. Also, they do not allow filtering of system calls made from the untrusted program based on types of operations other than read/write
op-erations and analysis of requests using different malware detection algorithms. Accordingly, there is need for an improved sandboxing mechanism for protection of a host computer and applications deployed thereon from mal-ware.
SUMMARY
[0004] Disclosed are a method and a system for pro-tecting applications deployed on a host computer from malware using virtualization as set forth by claims 1 and 7, respectively. In one example embodiment, a malware protection system comprises a kernel-level driver config-ured to intercept system calls addressed to an object of a protected application. The system further includes an analysis engine configured to determine if there is a se-curity rule associated with one or more of the intercepted system call, the object of the protected application, and the actions allowed on the object of the protected appli-cation, wherein the security rule indicates at least wheth-er the system call is allowed to be executed or not allowed to be executed on the host computer. If there is a security rule indicating that the system call is allowed to be exe-cuted on the host computer, the analysis engine instructs the host computer to execute the system call. If there is a security rule indicating that the system call is not al-lowed to be executed on the host computer, the analysis engine instructs the host computer to block execution of the system call. If there is no security rule associated with the system call, the analysis engine instructs a handler of a secure execution environment of the host computer to execute the system call in the secure execution envi-ronment using a virtual copy of the object of the protected application.
[0005] In one example embodiment, a method for pro-tecting applications deployed on a host computer prises: intercepting, at the kernel level of the host com-puter, system calls addressed to an object of a protected application deployed on the host computer; determining if there is a security rule associated with one or more of the intercepted system call, the object of the protected application, and the actions allowed on the object of the protected application, wherein the security rule indicates at least whether the system call is allowed to be executed or not allowed to be executed on the host computer; if there is a security rule indicating that the system call is allowed to be executed on the host computer, executing the system call on the host computer; if there is a security rule indicating that the system call is not allowed to be executed on the host computer, blocking execution of the system call on the host computer; and if there is no security rule associated with the system call, executing the system call in a secure execution environment using a virtual copy of the object of the protected application.
[0006] The above simplified summary of example em-bodiment(s) serves to provide a basic understanding of the invention. This summary is not an extensive overview of all contemplated aspects of the invention, and is
in-5 10 15 20 25 30 35 40 45 50 55 tended to neither identify key or critical elements of all embodiments nor delineate the scope of any or all em-bodiments. Its sole purpose is to present one or more embodiments in a simplified form as a prelude to the more detailed description of the invention that follows. To the accomplishment of the foregoing, the one or more em-bodiments comprise the features described and particu-larly pointed out in the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The accompanying drawings, which are incor-porated into and constitute a part of this specification, illustrate one or more example embodiments of the in-vention and, together with the detailed description serve to explain their principles and implementations.
Fig. 1 illustrates schematic configuration of a host computer according to one example embodiment.
Fig. 2 illustrates an example implementation of a malware protection system deployed on the host computer according to one example embodiment.
Fig. 3 illustrates an example of virtualization of a COM subsystem of the host computer according to one example embodiment.
Fig. 4 illustrates diagram of operation of a secure execution environment of the malware protection system according to one example embodiment.
Fig. 5 illustrates a diagram of virtualized components of the secure execution environment according to one example embodiment.
Fig. 6 illustrates a method for interception of local procedure calls by the malware protection system according to one example embodiment.
Fig. 7 illustrates a schematic diagram of operation the malware protection system according to one ex-ample embodiment.
Fig. 8 illustrates algorithm of operation of the mal-ware protection system according to one example embodiment.
Fig. 9 illustrates a schematic diagram of the malware protection system according to one example embod-iment.
Fig. 10 illustrates a schematic diagram of a host com-puter according to one example embodiment.
DETAILED DESCRIPTION OF EXAMPLE EMBODI-MENTS
[0008] Example embodiments of the present invention are described herein in the context of systems and meth-ods for protecting applications deployed on a host com-puter from malware using virtualization. Those of ordi-nary skill in the art will realize that the following descrip-tion is illustrative only and is not intended to be in any way limiting. Other embodiments will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of the example embodiments of the invention as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following de-scription to refer to the same or like items.
[0009] Fig. 1 shows an example schematic configura-tion of a host computer which includes hardware 102, operating system 170 and applications/programs 100. A more detailed configuration of the host computer is shown in Fig. 10, which will be discussed in greater detail herein below. Generally, operating systems (OS) support several levels of privileges for executing programs and applications on the host computer. For example, Win-dows@ OS supports two security modes: kernel mode 110 and user mode 115. Programs and applications 100 are typically deployed in the user mode 115, which in-creases the level of protection for the host computer against critical errors and, in particular, protects system services 130, drivers 140, and hardware abstraction layer 160 of the operating system 170 from access/modifica-tion by malware. The host computer may also include various user mode services 150, such as antivirus and other security services provided by the OS, which control the execution of user-mode applications 100 and monitor state of the host computer’s software and hardware com-ponents.
[0010] Fig. 2 illustrates one example embodiment of a malware protection system deployed on the host com-puter. The malware protection system comprises a ker-nel-level protection driver 230, analytical engine 210 and secure execution environment (SEE) 220. In one exam-ple embodiment, the kernel-level protection driver 230 is configured to intercept system calls (e.g., read, write, load, create process, open network connection, etc.) di-rected to a user-mode application 100 and redirect them to a secure execution environment (SEE) 220. In the SSE 220, the request is analyzed by the analysis engine 210 to determine whether to block system call, allow its exe-cution by the host computer, or execute the system call in the SEE 220 using virtual system components of the SEE 220 without any harm to the application 100 or host computer.
[0011] In one example embodiment, SEE 220 may be implemented as user-mode service 150 that provides vir-tualization of components of the host computer. Fig. 3
5 10 15 20 25 30 35 40 45 50 55 of the host computer which may be implemented in the SEE 220. Generally, the COM provides a model for reuse of system components, such as executable files or dy-namic libraries, which can be called up from any program that supports the COM model. An example of such a program is Internet Explorer® and other browser. COM provides access to and control over a launched copy of such an application. Therefore, in one example embod-iment, when a COM service 300 is addressed by a pro-gram launched on the host computer (which could be a malware), the system call may be redirected to a virtual copy of COM service 301 created in the SEE 220. There-fore, access to the COM objects of the operating system and other OS services does not take place directly. The COM virtual service does not differ from the original serv-ice. For example, when application 100 makes a system call, host system launches a COM server 310, which re-turns the object being requested to the application 100. When the system call from application 100 is redirected to the SEE 220, a virtual COM service 301 creates a virtual server 311 and returns a virtual object to the ap-plication 100.
[0012] Fig. 4 shows a diagram of operation of secure execution environment (SEE) of the malware protection system according to one example embodiment. During execution on the host computer, application 100 may send a system call to the OS 400 where it has to be processed by the OS handler 405. The system call may be intercepted by the kernel-level protection driver 230 of the malware protection system and do not reach the OS handler 405. For example, the protection driver 230 may be configured to intercepted the following system calls: opening up a process/input; reading the process memory; direct access to the memory/disk; access to the file system, the registry and the objects of the OS kernel 400; requests to obtain privileges; and other system calls. After the interception, the protection driver 230 redirects the system call to the secure execution environment 220, where the system call may be executed by the SEE han-dler 410 using a plurality of virtual copies of components of the host computer.
[0013] The process of executing system calls by the SEE handler 410 depends on the level of detail with which the host computer is virtualized in the secure execution environment 220. For effective operation without errors, it is preferred, but not required, to create a virtual copy of the file system, the registry, and some OS services.
Fig. 5 shows examples of virtual components of the host computer reproduced in the SSE 220. As shown, the SEE 220 may include virtual user mode services 500 and COM subsystem 505, virtual kernel objects 510 (e.g., port, pipe, event, mutex, section, semaphore), virtual registry 520, and virtual file system 530. Virtualization of system components may be performed on-the-fly, without rein-stallation or reloading of the host computer because no changes in the kernel of the OS of the host computer are necessary.
[0014] The virtualization implies that changes that
ap-plication 100 makes in the host computer are not actually performed. In other words, the original information in the host system (file or registry key) is not changed. Virtual-ization of a process is understood to be virtualVirtual-ization of its access to the objects of the OS, including its files and registry. Virtualization of an object presupposes the cre-ation of its virtual copy, if this is necessary (access to the real object can also be provided). In one example em-bodiment, SEE handler 410 determines which software and hardware components need to be virtualized in the SEE 220 and executes the system call using the virtual-ized components. The real object is returned to the ap-plication 100, as a rule, during read operation only. The virtual files may be stored in a special directory, and the registry keys in a special branch of the registry. The other OS objects may be stored in RAM.
[0015] In one example embodiment, the protection driver 230 may be also configured to intercepts local pro-cedure calls (LPC). This permits the malware protection system to isolate application 100 by changing the port names. Fig. 6 illustrates an example of such an intercep-tion. The application 100 sends a request for the creation of an object to the library of object linking and embedding 600 (OLE32.dll in the Windows@ OS). This library calls up the function for establishing a connection to the port NtConnectPort("\\RPC_Control\epmapper"), where "\\RPC_Control\epmapper" is the name of the port. This request is intercepted by the protection driver 230 and the port name is changed. After the substitution of the port name, the request does not go to the service for remote procedure call-up RPCSS 610 (in the Windows@ OS), but to the virtual service for remote procedure call-up Virtual RPCSS 615 provided by the secure execution environment 220. The virtual service 615 returns the ep-mapper interface to the application 110 for further inter-action with the secure execution environment 220.
[0016] The previous examples were considered with regard to the interaction of an application with the OS. Such examples reveal the possibility of protecting the OS from malware deployed on the host computer. However, virtualizing all the applications on a computer is an ex-tremely resource-intensive task, and this is not expedient for solving the problem of protection of confidential infor-mation from malware. There is a limited set of applica-tions on the computer that store, transmit, and receive information containing confidential data that should be protected. Such information includes personal corre-spondence, personal data, secret codes, passwords, credit card numbers, and other data. The virtualization of the applications and their interaction with other pro-grams and the OS according to specified rules is a nec-essary layer of protection under the conditions of a con-stantly growing risk to the security of information. There-fore, the malware protection system permits applications containing confidential information to be cut off from mal-ware without loss of functionality or reloading.
[0017] Since malware protection system in accord-ance with one example embodiment of the invention uses
5 10 15 20 25 30 35 40 45 50 55 virtualization of the components and objects of the host computer and applications deployed thereon, the protec-tion of the host computer from infecprotec-tions due to vulner-abilities and errors in the applications may be organized based of the following principles: (1) limiting access to protected objects, such as objects containing confidential data of the user; (2) protecting the host computer against changes: creating and making available copies of the object of the application launched in the secure execution environment in an attempt to modify objects on the host computer; and (3) protecting critical processes and serv-ices launched in the host computer from access on the part of an application launched in a secure execution environment, with the purpose of excluding leaks of ma-licious processes into the host computer.
[0018] In this case, the malware protection system is configured to analyze and filter in the secure execution environment system calls from applications to the objects (e.g., memory areas, files, processes, threads of execu-tion) of the host computer and other applications de-ployed thereon. In addition, the malware protection sys-tem may analyze and filter syssys-tem calls from the objects of the host computer to the applications executed in the secure execution environment.
[0019] In addition, the malware protection system pro-vides the following advantages: protecting host computer against penetration of malware during application’s ac-cess to the Internet; cleaning temporary files, visit logs, and other data that store the history of application’s op-eration; protecting user data processed by the application being protected from unauthorized access of processes from the host computer; securing launch of programs from the applications being protected by automatically launching these programs in the secure execution envi-ronment.
[0020] Fig. 7 illustrates a schematic diagram of oper-ation the malware protection system according to one example embodiment. A malware 710 deployed on host computer 700 executes an algorithm for stealing confi-dential information from the user-mode application 705, such as the Internet browser, banking application, com-munication application or other application that stores confidential user or system information. The malware 710 makes a system call to the operating system, such as a request to read memory of one or more objects (e.g., memory areas, files, processes, threads of execution, etc.) of the application 705. The system call may be in-tercepted by the kernel-level protection driver 230 of the malware protection system and redirected to the secure execution environment 220 of the malware protection system. The SSE 220 may collect all information related to the system call, such as the name of the program that made the call, type of system call (e.g., read, write, load, create process, open network connection, etc.), name of the program being called, the processes and memory areas being accessed by the system call, and other rel-evant information. The SEE 220 sends the collected in-formation to analysis engine 210, which determines the
nature of the system call and reaches a verdict weather to perform the system call, to block the system call, or to execute the system call using virtual system components in the SEE 220.
[0021] In one example embodiment, the analysis en-gine 210 is an expert system of security rules 720 which analyzes the intercepted system call (e.g., the type of system call), the object of the system call, the statistics of system calls from the malware 710, the attributes and behavior of the malware 710 and other information to determine if the system call should be performed or blocked by the malware protection system. One example of security rules is the exclusion of access depending on the object type, designated in the example below with angular brackets:
If {access to <object of the OS kernel>}, then {block ac-cess}
[0022] Depending on the verdict, the system call is ei-ther blocked, sent to the OS handler 405 without modifi-cation, or forwarded to the SEE handler 410 for execution in the SEE 220. The requests to the processes, data, and application memory are filtered according to the rules, which enhance the protection of access to the confiden-tial data 730 of the user-mode application 705.
[0023] Fig. 8 illustrates algorithm of operation of the malware protection system according to one example embodiment. At step 800, the kernel-level protection driv-er intdriv-ercepts a system call to (or from) a usdriv-er-mode ap-plication (e.g., the memory of the apap-plication, its proc-esses, the files of the application). At step 810, the system call is checked by analysis engine of the SEE for com-pliance with security rules and a decision how to process the system call is made at step 815: the system call is blocked at step 820 if it does not comply with the security rules (and an error message may be generated indicated that the system call is prohibited), the system call is per-formed at step 820 (sent to the OS handler) if it does not contain any threats, or execution of the system call is virtualized in the SEE at step 830 if no appropriate secu-rity rule was found. In particular, at step 830, the SEE hander creates in the SEE all necessary virtual copies of system components, such as virtual system services, registry, file system, etc., necessary for virtual execution of the system call. The actions performed within the SEE may be stored at step 840 in a data structure and as-sessed at step 845 if they possess any threat to the se-curity of the application (or its data, processes, etc.) to which the system call was directed. In one example em-bodiment, the analysis at step 845 may include a heuristic analysis of one or more intercepted system call(s) against behavior patterns of known malicious programs, as dis-closed for example in a commonly owned U.S. Patent No. 7,614,084 entitled "System and Method for Detecting Multi-Component Malware". In other example embodi-ments, the analysis at step 845 may include malware signature matching, behavior analysis or other known
5 10 15 20 25 30 35 40 45 50 55 malware detection technique. If no threat has been de-tected, the changes to the objects of the SEE may be applied at step 850 to the host computer. Otherwise, the changes to the SEE are not applied to the host, and the process is terminated at step 855.
[0024] Fig. 9 illustrates a schematic diagram of the malware protection system according to one example embodiment. The kernel-level protection driver 230 in-tercepts system calls. Examples of interceptable re-quests are described above. The intercepted system calls are redirected to the SEE 900, where virtualization of protected application objects and host system compo-nents takes place. If the system call includes a request for a critical object with limited access, a virtualized copy of that object may be created and returned to the program which originated the request. As depicted, the virtualized objects may include but not limited to the user mode serv-ices 500, OS kernel 510, OS registry 520, and file system 530. In addition to the constraints imposed by the SEE on the critical system objects, the SEE includes analysis engine 210 configured to analyze system call for pres-ence of security threats using security rules 215 as de-scribed above. In one example embodiment, the analysis engine 210 may implement a security rating algorithm in which security rules assess and assign security ratings to the intercepted system calls as disclosed in greater detail in a commonly owned U.S. Patent No. 7,530,106 entitled "System and Method for Security Rating of Com-puter Processes". On the basis of the assigned security ratings the analytical engine 210 can make a decision whether to perform, block or virtualize the intercepted system call as described in great detail hereinabove with reference to Figs. 7 and 8.
[0025] Fig. 10 illustrates one example embodiment of a computer system 5, such as a personal computer (PC) or an application server, suitable for implementing the host computer. As shown, computer system 5 may in-clude one or more processors 15, memory 20, one or more hard disk drive(s) 30, optical drive(s) 35, serial port(s) 40, graphics card 45, audio card 50 and network card(s) 55 connected by system bus 10. System bus 10 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus and a local bus using any of a variety of known bus ar-chitectures. Processor 15 may include one or more Intel® Core 2 Quad 2.33 GHz processors or other type of gen-eral purpose microprocessor.
[0026] System memory 20 may include a read-only memory (ROM) 21 and random access memory (RAM) 23. Memory 20 may be implemented as in DRAM (dy-namic RAM), EPROM, EEPROM, Flash or other type of memory architecture. ROM 21 stores a basic input/output system 22 (BIOS), containing the basic routines that help to transfer information between the components of com-puter system 5, such as during start-up. RAM 23 stores operating system 24 (OS), such as Windows@ XP Pro-fessional or other type of operating system, that is re-sponsible for management and coordination of
process-es and allocation and sharing of hardware rprocess-esourcprocess-es in computer system 5. System memory 20 also stores ap-plications and programs 25, such as services 306. Sys-tem memory 20 also stores various runtime data 26 used by programs 25 as well as various databases of informa-tion about known malicious and safe objects.
[0027] Computer system 5 may further include hard disk drive(s) 30, such as SATA magnetic hard disk drive (HDD), and optical disk drive(s) 35 for reading from or writing to a removable optical disk, such as a CD-ROM, DVD-ROM or other optical media. Drives 30 and 35 and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, databases, applications and program mod-ules/subroutines that implement algorithms and methods disclosed herein. Although the exemplary computer sys-tem 5 employs magnetic and optical disks, it should be appreciated by those skilled in the art that other types of computer readable media that can store data accessible by a computer system 5, such as magnetic cassettes, flash memory cards, digital video disks, RAMs, ROMs, EPROMs and other types of memory may also be used in alternative embodiments of the computer system.
[0028] Computer system 5 further includes a plurality of serial ports 40, such as Universal Serial Bus (USB), for connecting data input device(s) 75, such as keyboard, mouse, touch pad and other. Serial ports 40 may be also be used to connect data output device(s) 80, such as printer, scanner and other, as well as other peripheral device(s) 85, such as external data storage devices and the like. System 5 may also include graphics card 45, such as nVidia® GeForce® GT 240M or other video card, for interfacing with a monitor 60 or other video reproduc-tion device. System 5 may also include an audio card 50 for reproducing sound via internal or external speakers 65. In addition, system 5 may include network card(s) 55, such as Ethernet, WiFi, GSM, Bluetooth or other wired, wireless, or cellular network interface for connect-ing computer system 5 to network 70, such as the Inter-net.
[0029] In various embodiments, the algorithms and methods described herein may be implemented in hard-ware, softhard-ware, firmhard-ware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory com-puter-readable medium. Comcom-puter-readable medium in-cludes both computer storage and communication me-dium that facilitates transfer of a computer program from one place to another. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-read-able medium can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection may be termed a computer-readable medium. For example,
5 10 15 20 25 30 35 40 45 50 55 if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
[0030] In the interest of clarity, not all of the routine features of the embodiments are shown and described herein. It will be appreciated that in the development of any such actual implementation, numerous implementa-tion-specific decisions must be made in order to achieve the developer’s specific goals, and that these specific goals will vary from one implementation to another and from one developer to another. It will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine under-taking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
[0031] Furthermore, it is to be understood that the phraseology or terminology used herein is for the pur-pose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combina-tion with the knowledge of the skilled in the relevant art(s). Moreover, it is not intended for any term in the specifica-tion or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.
[0032] The various embodiments disclosed herein en-compass present and future known equivalents to the known components referred to herein by way of illustra-tion. Moreover, while embodiments and applications have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclo-sure that many more modifications than mentioned above are possible without departing from the inventive concepts disclosed herein.
Claims
1. A method for protecting applications deployed on a host computer, the method comprising:
intercepting, at a kernel level of the host com-puter (700), system calls addressed to an object of a protected application (705) deployed on the host computer (700), wherein the system calls are remote procedure calls from an application deployed on the host computer (700);
determining if there is a security rule associated with one or more of the intercepted system call, the object of the protected application (705), and the actions allowed on the object of the protected application (705), wherein the security rule (720) indicates at least whether the system call is al-lowed to be executed or not alal-lowed to be exe-cuted on the host computer (700);
if there is a security rule (720) indicating that the
system call is allowed to be executed on the host computer (700), executing the system call on the host computer (700);
if there is a security rule (720) indicating that the system call is not allowed to be executed on the host computer (700), blocking an execution of the system call on the host computer (700); if there is no security rule (720) associated with the system call, executing the system call in a secure execution environment (220) by replac-ing a port name of an object addressed by a remote procedure call with a port name of a vir-tual copy of the object of the protected applica-tion (705);
analyzing whether changes to the virtual copy of the object of the protected application (705) present any security threat to the application (705), application data (730), or the host com-puter (700);
if the changes to the virtual copy of the object do not present any security threat, applying the changes to a real object in the host computer (700);
if the changes to the virtual copy of the object present a security threat, blocking the execution of the system call on the host computer (700); intercepting at the kernel level the remote pro-cedure call from the application deployed on the host computer (700); and
replacing the port name of the object addressed by the remote procedure call with the port name of the virtual copy of the object in the secure execution environment (220), thereby redirect-ing the remote procedure call to the secure ex-ecution environment (220).
2. The method of claim 1, wherein analyzing whether changes to the virtual copy of the object present any security threat comprises:
performing one or more of heuristic analysis, malware signature matching, and behavior anal-ysis of at least the virtual copy of the object.
3. The method of claim 1, wherein the secure execution environment (220) is implemented as a user-mode service on the host computer (700).
4. The method of claim 1, wherein the secure execution environment (220) further comprises: one or more virtual user mode services (500), one or more virtual kernel objects (510), a virtual registry (520), and a virtual file system (530) of the host computer (700).
5. The method of claim 1, wherein intercepting system calls further comprises:
5 10 15 20 25 30 35 40 45 50 55 driver (230).
6. The method of claim 1, wherein the security rule (720) at least defines an exclusion of access depend-ing on an object type of the system call.
7. A system for protecting applications deployed on a host computer (700), the system comprising:
a kernel-level driver (230) stored in a memory (20) of the host computer (700) and being exe-cutable by a processor (15) of the host computer (700), wherein the kernel-level driver (230) is configured to intercept system calls addressed to an object of a protected application (705), wherein the system calls are remote procedure calls from an application deployed on the host computer (700); and
an analysis engine (210) executable by the proc-essor (15), wherein the analysis engine (210) is configured to:
determine if there is a security rule associ-ated with one or more of the intercepted sys-tem call, the object of the protected appli-cation (705), and the actions allowed on the object of the protected application (705), wherein the security rule indicates at least whether the system call is allowed to be ex-ecuted or not allowed to be exex-ecuted on the host computer (700);
if there is a security rule (720) indicating that the system call is allowed to be executed on the host computer (700), instruct the host computer (700) to execute the system call; if there is a security rule (720) indicating that the system call is not allowed to be executed on the host computer (700), instruct the host computer (700) to block an execution of the system call;
if there is no security rule (720) associated with the system call, instruct a handler (900) of a secure execution environment (220) of the host computer (700) to execute the sys-tem call in the secure execution environ-ment (220) by replacing a port name of an object addressed by a remote procedure call with a port name of a virtual copy of the object of the protected application (705);
characterized in that
the analysis engine (210) is configured to: analyze whether changes to the virtual copy of the object of the protected ap-plication (705) present any security threat to the application (705), applica-tion data (730), or the host computer (700);
if the changes to the virtual copy of the object do not present any security threat, instruct the host computer (700) to apply the changes to a real object in the host computer (700); and
if the changes to the virtual copy of the object present a security threat, instruct the host computer (700) to block the ex-ecution of the system call on the host computer (700); and
the kernel-level driver (230) is further configured to:
intercept the remote procedure call from the application deployed on the host computer (700); and replace the port name of the object addressed by the remote proce-dure call with the port name of the virtual copy of the object in the se-cure execution environment (220), thereby redirecting the remote pro-cedure call to the secure execution environment (220).
8. The system of claim 7, wherein analyzing whether changes to the virtual copy of the object present any security threat comprises:
performing one or more of heuristic analysis, malware signature matching, and behavior anal-ysis of at least the virtual copy of the object.
9. The system of claim 7, wherein the secure execution environment (220) is implemented as a user-mode service on the host computer (700).
10. The system of claim 7, wherein the secure execution environment (220) further comprises:
one or more virtual user mode services (500), one or more virtual kernel objects (510), a virtual registry (520), and a virtual file system (530) of the host computer (700).
11. The system of claim 7, wherein the security rule (720) at least defines an exclusion of access depending on an object type of the system call.
Patentansprüche
1. Verfahren zum Schutz von Anwendungen, die auf einem Host-Computer installiert sind, wobei das Ver-fahren umfasst:
- Abfangen von Systemaufrufen, die an ein Ob-jekt einer auf dem Host-Computer (700)
instal-5 10 15 20 25 30 35 40 45 50 55 lierten geschützten Anwendung (705) adres-siert sind, auf einem Kernel-Level des Host-Computers (700), wobei die Systemaufrufe Femprozeduraufrufe von einer auf dem Host-Computer (700) installierten Anwendung sind; - Bestimmen, ob es eine Sicherheitsregel gibt, die einem oder mehreren der abgefangenen Systemaufrufe, dem Objekt der geschützten An-wendung (705) und den an dem Objekt der ge-schützten Anwendung (705) erlaubten Aktionen zugeordnet ist, wobei die Sicherheitsregel (720) wenigstens angibt, ob es erlaubt oder nicht er-laubt ist, dass der Systemaufruf auf dem Host-Computer (700) ausgeführt wird;
- falls es eine Sicherheitsregel (720) gibt, die angibt, dass es erlaubt ist, dass der Systemauf-ruf auf dem Host-Computer (700) ausgeführt wird, Ausführen des Systemaufrufs auf dem Host-Computer (700);
- falls es eine Sicherheitsregel (720) gibt, die angibt, dass es nicht erlaubt ist, dass der Sys-temaufruf auf dem Host-Computer (700) ausge-führt wird, Blockieren einer Ausführung des Sys-temaufrufs auf dem Host-Computer (700); - falls es keine Sicherheitsregel (720) gibt, die dem Systemaufruf zugeordnet ist, Ausführen des Systemaufrufs in einer sicheren Ausfüh-rungsumgebung (220) durch Ersetzen eines Portnamens eines von einem Fernprozedurauf-ruf adressierten Objekts durch einen Portnamen einer virtuellen Kopie des Objekts der geschütz-ten Anwendung (705);
- Analysieren, ob Änderungen an der virtuellen Kopie des Objekts der geschützten Anwendung (705) irgendeine Sicherheitsbedrohung für die Anwendung (705), Anwendungsdaten (730) oder den Host-Computer (700) darstellen; - falls die Änderungen an der virtuellen Kopie des Objekts keine Sicherheitsbedrohung dar-stellen, Anwenden der Änderungen auf ein re-ales Objekt in dem Host-Computer (700); - falls die Änderungen an der virtuellen Kopie des Objektes eine Sicherheitsbedrohung dar-stellen, Blockieren der Ausführung des System-aufrufs auf dem Host-Computer (700); - Abfangen des Fernprozeduraufrufs von der auf dem Host-Computer (700) installierten Anwen-dung auf dem Kernel-Level; und
- Ersetzen des Portnamens des von dem Fern-prozeduraufruf adressierten Objekts durch den Portnamen der virtuellen Kopie des Objekts in der sicheren Ausführungsumgebung (220), wo-durch der Fernprozeduraufruf zu der sicheren Ausführungsumgebung (220) umgeleitet wird.
2. Verfahren nach Anspruch 1, wobei das Analysieren, ob Änderungen an der virtuellen Kopie des Objekts irgendeine Sicherheitsbedrohung darstellen,
um-fasst:
- Durchführen eines oder mehrerer aus einer heuristischen Analyse, eines Schadsoftwaresi-gnaturabgleichs und einer Verhaltensanalyse von wenigstens der virtuellen Kopie des Ob-jekts.
3. Verfahren nach Anspruch 1, wobei die sichere Aus-führungsumgebung (220) als Benutzermodusdienst auf dem Host-Computer (700) implementiert ist.
4. Verfahren nach Anspruch 1, wobei die sichere Aus-führungsumgebung (220) weiterhin umfasst: einen oder mehrere virtuelle Benutzermodusdienste (500), ein oder mehrere virtuelle Kernel-Objekte (510), eine virtuelle Registrierungsdatenbank (520) und ein virtuelles Dateisystem (530) des Host-Com-puters (700).
5. Verfahren nach Anspruch 1, wobei das Abfangen von Systemaufrufen weiterhin umfasst:
- Abfangen der Systemaufrufe durch einen Ker-nel-Level-Treiber (230).
6. Verfahren nach Anspruch 1, wobei die Sicherheits-regel (720) abhängig von einem Objekttyp des Sys-temaufrufs wenigstens einen Zugriffsausschluss de-finiert.
7. System zum Schutz von Anwendungen, die auf ei-nem Host-Computer (700) installiert sind, wobei das System umfasst:
- einen in einem Speicher (20) des Host-Com-puters (700) gespeicherten und von einem Pro-zessor (15) des Host-Computers (700) ausführ-baren Kernel-Level-Treiber (230), wobei der Kernel-Level-Treiber (230) zum Abfangen von Systemaufrufen konfiguriert ist, die an ein Ob-jekt einer geschützten Anwendung (705) adres-siert sind, wobei die Systemaufrufe Fernproze-duraufrufe von einer auf dem Host-Computer (700) installierten Anwendung sind; und - eine von dem Prozessor (15) ausführbare Ana-lyse-Engine (210), wobei die AnaAna-lyse-Engine (210) dazu konfiguriert ist:
- zu bestimmen, ob es eine Sicherheitsregel gibt, die einem oder mehreren der abgefan-genen Systemaufrufe, dem Objekt der ge-schützten Anwendung (705) und den an dem Objekt der geschützten Anwendung (705) erlaubten Aktionen zugeordnet ist, wobei die Sicherheitsregel wenigstens an-gibt, ob es erlaubt oder nicht erlaubt ist, dass der Systemaufruf auf dem
Host-Com-5 10 15 20 25 30 35 40 45 50 55 puter (700) ausgeführt wird;
- falls es eine Sicherheitsregel (720) gibt, die angibt, dass es erlaubt ist, dass der Sys-temaufruf auf dem Host-Computer (700) ausgeführt wird, den Host-Computer (700) anzuweisen, den Systemaufruf auszufüh-ren;
- falls es eine Sicherheitsregel (720) gibt, die angibt, dass es nicht erlaubt ist, dass der Systemaufruf auf dem Host-Computer (700) ausgeführt wird, den Host-Computer (700) anzuweisen, eine Ausführung des Systemaufrufs zu blockieren;
- falls es keine Sicherheitsregel (720) gibt, die dem Systemaufruf zugeordnet ist, einen Handler (900) einer sicheren Ausführungs-umgebung (220) des Host-Computers (700) anzuweisen, den Systemaufruf in der sicheren Ausführungsumgebung (220) durch Ersetzen eines Portnamens eines von einem Fernprozeduraufruf adressier-ten Objekts durch einen Portnamen einer virtuellen Kopie des Objekts der geschütz-ten Anwendung (705) auszuführen;
dadurch gekennzeichnet, dass
- die Analyse-Engine (210) dazu konfiguriert ist, - zu analysieren, ob Änderungen an der vir-tuellen Kopie des Objekts der geschützten Anwendung (705) irgendeine Sicherheits-bedrohung für die Anwendung (705), An-wendungsdaten (730) oder den Host-Com-puter (700) darstellen;
- falls die Änderungen an der virtuellen Ko-pie des Objekts keine Sicherheitsbedro-hung darstellen, den Host-Computer (700) anzuweisen, die Änderungen auf ein reales Objekt in dem Host-Computer (700) anzu-wenden; und
- falls die Änderungen an der virtuellen Ko-pie des Objektes eine Sicherheitsbedro-hung darstellen, den Host-Computer (700) anzuweisen, die Ausführung des System-aufrufs auf dem Host-Computer (700) zu blockieren; und
- der Kernel-Level-Treiber (230) weiterhin dazu konfiguriert ist,
- den Fernprozeduraufruf von der auf dem Host-Computer (700) installierten Anwen-dung abzufangen; und
- den Portnamen des von dem Fernproze-duraufruf adressierten Objekts durch den Portnamen der virtuellen Kopie des Objekts in der sicheren Ausführungsumgebung
(220) zu ersetzen, wodurch der Fernproze-duraufruf zu der sicheren Ausführungsum-gebung (220) umgeleitet wird.
8. System nach Anspruch 7, wobei das Analysieren, ob Änderungen an der virtuellen Kopie des Objekts irgendeine Sicherheitsbedrohung darstellen, um-fasst:
- Durchführen eines oder mehrerer aus einer heuristischen Analyse, eines Schadsoftwaresi-gnaturabgleichs und einer Verhaltensanalyse von wenigstens der virtuellen Kopie des Ob-jekts.
9. System nach Anspruch 7, wobei die sichere Ausfüh-rungsumgebung (220) als Benutzermodusdienst auf dem Host-Computer (700) implementiert ist.
10. System nach Anspruch 7, wobei die sichere Ausfüh-rungsumgebung (220) weiterhin umfasst:
- einen oder mehrere virtuelle Benutzermodus-dienste (500), ein oder mehrere virtuelle Kernel-Objekte (510), eine virtuelle Registrierungsda-tenbank (520) und ein virtuelles Dateisystem (530) des Host-Computers (700).
11. System nach Anspruch 7, wobei die Sicherheitsregel (720) abhängig von einem Objekttyp des System-aufrufs wenigstens einen Zugriffsausschluss defi-niert.
Revendications
1. Un procédé de protection d’applications déployées sur un ordinateur hôte, le procédé comprenant :
l’interception, à un niveau noyau de l’ordinateur hôte (700), d’appels système adressés à un ob-jet d’une application protégée (705) déployée sur l’ordinateur hôte (700), les appels système étant des appels de procédure à distance pro-venant d’une application déployée sur l’ordina-teur hôte (700),
la détermination s’il existe une règle de sécurité associée à un ou plusieurs appel(s) système(s) intercepté(s), l’objet de l’application protégée (705) et les actions autorisées sur l’objet de l’ap-plication protégée (705), la règle de sécurité (720) indiquant au moins si l’appel système est autorisé à être exécuté ou n’est pas autorisé à être exécuté sur l’ordinateur hôte (700), s’il existe une règle de sécurité (720) indiquant que l’appel système est autorisé à être exécuté sur l’ordinateur hôte (700), l’exécution de l’appel système sur l’ordinateur hôte (700),
5 10 15 20 25 30 35 40 45 50 55 s’il existe une règle de sécurité (720) indiquant que l’appel système n’est pas autorisé à être exécuté sur l’ordinateur hôte (700), le blocage d’une exécution de l’appel système sur l’ordina-teur hôte (700),
s’il n’existe pas de règle de sécurité (720) asso-ciée à l’appel système, l’exécution de l’appel système dans un environnement d’exécution sécurisé (220) par le remplacement d’un nom de port d’un objet adressé par un appel de pro-cédure à distance par un nom de port d’une co-pie virtuelle de l’objet de l’application protégée (705),
l’analyse si des modifications à la copie virtuelle de l’objet de l’application protégée (705) présen-tent une quelconque menace de sécurité pour l’application (705), les données d’application (730) ou l’ordinateur hôte (700),
si les modifications à la copie virtuelle de l’objet ne présentent pas une quelconque menace de sécurité, l’application des modifications à un ob-jet réel dans l’ordinateur hôte (700),
si les modifications à la copie virtuelle de l’objet présentent une menace de sécurité, le blocage de l’exécution de l’appel système sur l’ordina-teur hôte (700),
l’interception au niveau noyau de l’appel de pro-cédure à distance provenant de l’application dé-ployée sur l’ordinateur hôte (700), et
le remplacement du nom de port de l’objet adressé par l’appel de procédure à distance par le nom de port de la copie virtuelle de l’objet dans l’environnement d’exécution sécurisé (220), redirigeant ainsi l’appel de procédure à distance vers l’environnement d’exécution sé-curisé (220).
2. Le procédé selon la revendication 1, dans lequel l’analyse si des modifications à la copie virtuelle de l’objet présentent une quelconque menace de sécu-rité comprend :
l’exécution d’une ou de plusieurs opérations parmi une analyse heuristique, une mise en cor-respondance de signatures de logiciels mal-veillants et une analyse de comportement d’au moins la copie virtuelle de l’objet.
3. Le procédé selon la revendication 1, dans lequel l’en-vironnement d’exécution sécurisé (220) est mis en oeuvre sous la forme d’un service en mode utilisa-teur sur l’ordinautilisa-teur hôte (700).
4. Le procédé selon la revendication 1, dans lequel l’en-vironnement d’exécution sécurisé (220) comprend en outre : un ou plusieurs services en mode utilisa-teur virtuels (500), un ou plusieurs objets noyaux vir-tuels (510), un registre virtuel (520) et un système
de fichiers virtuel (530) de l’ordinateur hôte (700).
5. Le procédé selon la revendication 1, dans lequel l’in-terception d’appels système comprend en outre : l’interception des appels système par un pilote de niveau noyau (230).
6. Le procédé selon la revendication 1, dans lequel la règle de sécurité (720) définit au moins une exclu-sion d’accès en fonction d’un type d’objet de l’appel système.
7. Un système de protection d’applications déployées sur un ordinateur hôte (700), le système comprenant :
un pilote de niveau noyau (230) conservé en mémoire dans une mémoire (20) de l’ordinateur hôte (700) et qui est exécutable par un proces-seur (15) de l’ordinateur hôte (700), le pilote de niveau noyau (230) étant configuré de façon à intercepter des appels système adressés à un objet d’une application protégée (705), les ap-pels système étant des apap-pels de procédure à distance provenant d’une application déployée sur l’ordinateur hôte (700), et
un moteur d’analyse (210) exécutable par le pro-cesseur (15), le moteur d’analyse (210) étant configuré de façon à :
déterminer s’il existe une règle de sécurité associée à un ou plusieurs appel(s) systè-me(s) intercepté(s), l’objet de l’application protégée (705) et les actions autorisées sur l’objet de l’application protégée (705), la rè-gle de sécurité indiquant au moins si l’appel système est autorisé à être exécuté ou n’est pas autorisé à être exécuté sur l’ordinateur hôte (700),
s’il existe une règle de sécurité (720) indi-quant que l’appel système est autorisé à être exécuté sur l’ordinateur hôte (700), donner l’ordre à l’ordinateur hôte (700) d’exécuter l’appel système,
s’il existe une règle de sécurité (720) indi-quant que l’appel système n’est pas autori-sé à être exécuté sur l’ordinateur hôte (700), donner l’ordre à l’ordinateur hôte (700) de bloquer une exécution de l’appel système, s’il n’existe pas de règle de sécurité (720) associée à l’appel système, donner l’ordre à un gestionnaire (900) d’un environnement d’exécution sécurisé (220) de l’ordinateur hôte (700) d’exécuter l’appel système dans l’environnement d’exécution sécurisé (220) par le remplacement d’un nom de port d’un objet adressé par un appel de procédure à distance par un nom de port d’une copie
5 10 15 20 25 30 35 40 45 50 55 virtuelle de l’objet de l’application protégée (705),
caractérisé en ce que
le moteur d’analyse (210) est configuré de façon à :
analyser si des modifications à la copie virtuelle de l’objet de l’application pro-tégée (705) présentent une menace de sécurité quelconque pour l’application (705), les données d’application (730) ou l’ordinateur hôte (700),
si les modifications à la copie virtuelle de l’objet ne présentent pas une mena-ce de sécurité quelconque, donner l’or-dre à l’ordinateur hôte (700) d’appliquer les modifications à un objet réel dans l’ordinateur hôte (700), et
si les modifications à la copie virtuelle de l’objet présentent une menace de sécurité, donner l’ordre à l’ordinateur hôte (700) de bloquer l’exécution de l’appel système sur l’ordinateur hôte (700), et
le pilote de niveau noyau (230) est con-figuré en outre de façon à :
intercepter l’appel de procédure à distance provenant de l’application déployée sur l’ordinateur hôte (700), et
remplacer le nom de port de l’objet adressé par l’appel de procédure à distance par le nom de port de la copie virtuelle de l’objet dans l’en-vironnement d’exécution sécurisé (220), redirigeant ainsi l’appel de procédure à distance vers l’envi-ronnement d’exécution sécurisé (220).
8. Le système selon la revendication 7, dans lequel l’analyse si des modifications à la copie virtuelle de l’objet présentent une menace de sécurité quelcon-que comprend :
l’exécution d’une ou de plusieurs opérations parmi une analyse heuristique, une mise en cor-respondance de signatures de logiciels mal-veillants et une analyse de comportement d’au moins la copie virtuelle de l’objet.
9. Le système selon la revendication 7, dans lequel l’environnement d’exécution sécurisé (220) est mis en oeuvre sous la forme d’un service en mode utili-sateur sur l’ordinateur hôte (700).
10. Le système selon la revendication 7, dans lequel
l’environnement d’exécution sécurisé (220) com-prend en outre :
un ou plusieurs services en mode utilisateur tuels (500), un ou plusieurs objets noyaux vir-tuels (510), un registre virtuel (520) et un systè-me de fichiers virtuel (530) de l’ordinateur hôte (700).
11. Le système selon la revendication 7, dans lequel la règle de sécurité (720) définit au moins une exclu-sion d’accès en fonction d’un type d’objet de l’appel système.
REFERENCES CITED IN THE DESCRIPTION
This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.
Patent documents cited in the description • US 2010175104 A1 [0003]
• US 2011145926 A1 [0003]
• US 7614084 B [0023] • US 7530106 B [0024]
