Patent Application
20190138715
Flaws or errors exist in almost very computer program and are generally referred to as software bugs. Software bugs can arise from incorrect design, coding, or assembly of computer programs. Following good practices in software design, coding, and testing reduces software bugs, but cannot eliminate them. When a software bug in a computer program is triggered during its execution, it may result into corruption of data or memory and cause the program to crash. Corruption of program memory is a vulnerability that can lead to exploits.
The design of modern computer systems permits the exploitation of software bugs to take control of the execution of a computer program and obtain unauthorized privileges, For example, a buffer overflow attack works by overwriting portions of an executing program's stack and heap memory locations with code provided by the attacker. Such an attack is feasible when the computer program does not validate input from the user before copying the buffer into memory.
Buffer overflow vulnerabilities are relatively easy, to introduce and have been exploited for many years. Due to the severe security implications of these exploits, several new methods have been introduced to prevent them. The most prevalent method is the use of canaries, that is, constant values inserted within critical sections of the program stack, the integrity of which can be confirmed during program execution, Another method, available in operating systems that support the No-eXecute (NX) bit, can prevent execution of code residing in certain areas of memory, for example, the stack, but it can also interfere with proper execution of some programs, such as those that decode their image on stack. While the use of the NX bit and canaries does prevent most buffer overflow attacks these techniques can be bypassed, and so do not constitute a complete solution.
Some advanced attacks do not inject new code into the application, but instead exploit legitimate functions to which the application has linked to carry out their malicious actions. Return-to-libc attacks, for example, use functions from libc, the standard library for the C programming language, to gain unauthorized access. Since the success of such attacks hinges on knowing the precise address of the function to be coopted, randomization of the load address of libc was introduced as a defense mechanism to mitigate them. With libc loading at a new address every time the program initiates, the exploit cannot use a fixed address to call functions from libc as part of its attack. While this technique was initially successful, it was soon learned that address space layout randomization could be bypassed by obtaining the address of libc functions from the procedure linkage table (PLT) of the program.
Recently a new class of attacks based on return oriented programming (ROP) has emerged which is able to defeat all existing methods for preventing exploits. These attacks provide the attacker with a fully functional language that is Turing-complete. Using ROP, the attacker can craft gadgets out of snippets from the code of the target program to implement any action he desires without injecting any detectable code during the attack. Some attempts have been made to apply address space randomization ideas to the structure of a program to prevent successful use of gadgets created from the program. Unfortunately, these methods impose additional cost, introduce compatibility challenges with existing monitoring tools, and do not offer guarantees that they can be robust against as yet unseen attacks.
Therefore, a need exists for systems and methods to protect clients from attacks that exploit unpatched or unknown vulnerabilities in computer programs. The solution does not take away functionality in order to improve security. The security mechanism should work seamlessly and without requiring anything from the user.
In one aspect, a method useful for monitoring and validating execution of executable binary code, includes the step of disassembling an executable binary code of an application. The method includes the step of detecting and obtaining an application programming interface (API) call that is executed by the executable binary code. The APl calls can include system calls and API calls to library functions, collectively referred to as API call from hereon. It is noted that, in some embodiments, a permutation of API calls, systems calls, and/or privileged instructions can be utilized. The method includes the step of listing a type of the API call. The method includes the step of listing a location of the API call. The method includes the step of listing a target of the API call. The method includes the step of listing a location of return from the API call.
The method includes the step of detecting a privileged instruction that is executed by the executable binary code. The method includes the step of obtaining the privileged instruction that is executed by the executable binary code. The method includes the step of listing a type of the privileged instruction. The method includes the step of listing a location of the privileged instruction.
The method includes the step of creating a rule set for validating the API call and the privileged instruction execution by the executable binary code. The method includes the step of transmitting the rule set to a validation code at an enforcement point. The method includes the step of loading a rule set in the memory of the validation code, wherein the rule set pertains to an API call type, an API call target, an API call location, an API call return location, a privileged instruction type and a privileged instruction location. The method includes the step during an execution of the application, monitoring the code to determine a conformity of the API call, system call and/or the privileged instruction made by the application with the rule set. The method includes the step of inserting a monitoring and validation code that, during execution of an application, generates an event based on the API call, system call and/or the privileged instruction. The method includes the step of transmitting the event stating the type, location address, target address, and return address for the observed API call or the location if privileged instruction. The method includes the step of transmitting the event based on the API call, system call and/or the privileged instruction to a validator application, wherein the validator application validates the rule set. The method includes the step of with the validator application: checking a conformity of the event based on the API call, system call and/or the privileged instruction with the rule set. The method includes the step of implementing a default action when a rule violation is detected for an event associated with an API call, system call and/or privileged instruction during the execution of the binary code. The method includes the step of and applying an additional validation for the API call system call and/or the privileged instruction in the executable binary code.
The Figures described above are a representative set, and are not an exhaustive with respect to embodying the invention.
Disclosed are a post sandbox system, method, and article of manufacture for detecting and blocking zero-day exploits and unpatched vulnerability exploits via API call validation. The following description is presented to enable a person of ordinary skill in the art to make and use the various embodiments. Descriptions of specific devices, techniques, and applications are provided only as examples. Various modifications to the examples described herein can be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the various embodiments.
Reference throughout this specification to “one embodiment,” “an embodiment,” ‘one example,’ or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable mariner lr orae or more embodiments. in the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art can recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. in other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
The schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, and they are understood not to limit the scope of the corresponding method indeed some arrows or other connectors may be used to indicate only the logical flow of the method, For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs shay or may not strictly adhere to the order of the corresponding steps shown.
Definitions
Example definitions fear some ert embodimentsare now provided.
Application programming interface (API) is a set of subroutine definitions, protocols and tools for building application soft are. An API call can include system calls and API calls to library functions. System calls are special class of API calls that wrap privileged instructions.
Control transfers in a computer program can be instructions that directs the fll of execution of the program. JMP, CALL, RET, IRET, and INT are examples of control transfer instruction.
Dynamic linked library (DLL) refers to a program module providing a set of API calls. The use of DLLs helps modularize programs and often used in providing interface to the operating system.
Disassembly of a binary code is the process converting machine executable instructions into human readable assembly code.
Dynamic analysis refers to execution of an application in a sandboxed environment to observe, record, and analyze its actions.
Executable applications can be files that contain computer program that can be executed on a computer. An executable application file has a specific format that enables the computer to load the file into memory and execute instructions in the file. Examples of, executable binary code are executable applications, dynamic linked library (DLL), kernel module, etc.
An event is information collected about the state of the process including register values, application stack, application process map, and application file attributes.
Hypervisor can be computer software, firmware or hardware that creates and runs virtual machines.
Hooking refers to a range of techniques used to alter or augment the behavior of an operating system, of applications, or of other software components by intercepting function calls or messages or events passed between software components. A software hook can be a set of code that handles such intercepted function calls, events or messages.
Libc is commonly used as a shorthand for the ‘standard’ C library,(e.g. a library of standard functions that can be used by various C programs).
No-eXecute (NX) is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (code) or for storage of data, a feature normally only found in Harvard architecture processors.
Procedure Linkage Table (PLT) can be a part of the executable text section, consisting of a set of entries (one for each external function the shared library calls). Each PLT entry is a short chunk of executable code.
Processor register is a small set of data holding places that are part of the computer processor.
Return-oriented programming (ROP) is a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as non-executable memory (W xor X technique) and code signing.
Stack frame is collection of all data stored on the stack that is associated with a function call.
Virtual Machine Manager (VMM) is a desktop-drive virtual machine manager with which users can manage virtual machines (VM).
Whitelist can be a list or register of entities that provide a particular privilege, service, mobility, access or recognition. Entities on the list can be accepted, approved and/or recognized.
Zero-day vulnerability can refer to a computer-software vulnerability that is unknown to those (including the vendor of the target software) who would be interested in mitigating the vulnerability.
Exemplary Systems and Methods
In one example embodiments, an objective of the present invention is to protect computing devices from cyber-attacks wherein an adversary can exploit unknown or unpatched vulnerability in the software executing on the computing devices to gain unauthorized access. The adversary effects his aims by executing privileged functions on the computer system. A description and embodiment is provided for a deterministic method that prevents the unauthorized invocation of such functions, to include API calls, privileged instructions, and system API calls that wrap privileged instructions, collectively referred to as API calls from here on, during the execution of the application. The validation of API calls during the execution of the application is achieved by checking the consistency between the API call and the region of application code responsible for invoking the API call. The method's robust technique for determining allowable API calls overcomes the shortcomings of traditional whitelisting, blacklisting, and sandbox/heuristics/behavior-based security solutions, and makes it feasible to detect all exploits, and block any malicious code that is part of a exploit from executing, on the computing device.
Based on the discussion of prior art, it should be very clear to anyone well-versed in the art of cyber security that the utility of monitoring API calls to detect exploits is limited by our collective inability to set rules or heuristics that consistently discriminate the legitimate from the malicious, This invention describes a fundamental advance that solves this dilemma and provides a method to differentiate between malicious intent and a legitimate reason for an API call without requiring any special knowledge about the attack method or vulnerability on the part of the user.
In one embodiment of the invention, the bulk of the work is done on a remote server: the code of an application to be executed on a computer system is sent to a remote server where it is disassembled and scanned for API calls; the server creates a rule list based on API calls and their locations in the software; software hooks are placed in the code for monitoring API calls during program execution; the instrumented code is sent back to the client; the client executes the program, logging and sending to the server each observed API call, its location, and location of return from the API call; using the rule list, the server determines whether the event is compliant; if the event is non-compliant, a secondary validation technique is applied to reduce false positives; appropriate action is taken.
Secondary validation plays a crucial role in the robustness of the invention, providing a way to resolve disassembly ambiguities and flag true attack events. To perform the secondary test, upon receipt of an event, the corresponding application executable binary is disassembled; a list of all instructions is generated; a list of all API calls is generated; the received event is matched with the disassembled binary at the locations that are consistent with known instructions and API calls. If the exact memory location, return location, and type of API call are not consistent with the information extracted from the disassembled executable binary, the event is considered invalid. If the event is an API call, two additional checks are made. The first check is pointer consistency and the second check is API call argument validation. These two additional checks are strong conditions for validating an event.
Both rule list generation and secondary validationare deterministic and automatic—they do not require human intervention. These features provide a tremendous advantage over traditional black/white list-based approaches that always require a human in the loop to make the final decision.
In a variation of the first embodiment, once the server has created the rule list, it sends the list to the client and the client validates events. Splitting the work in this way cuts down on network activity, but can still keep the compute-intensive tasks at the server.
In a second embodiment of the invention, all of the work is done on the executing computer: the code of the application to be executed is disassembled and scanned for API calls; a rule list based on API calls and their locations in the software is created; software hooks are placed in the code for monitoring API calls during program execution the computer executes the program, validating each observed API call in turn; and taking appropriate action.
In a third embodiment of the present invention API calls are monitored without modifying the application binary: the code of an application executing on a computer system is scanned for API calls; a list of API calls and their locations in the software is created; software hooks are placed for monitoring API calls during program execution; during the execution of the program the type, location address, and return address of observed API calls are compared with information about expected API calls; events are logged; prescribed action is taken if an observed API call is not compliant. It is noted that the software hooks are placed in the kernel.
In a fourth embodiment of the invention the application binary is modified for monitoring API calls: the binary code of an application executable stored on a computer system is disassembled and scanned for API calls; software hooks are placed for monitoring API calls during program execution; a new executable is created; during the execution of the program the type, location address, and return address of API calls are compared with information about expected API calls; events are logged; prescribed action is taken if an observed API call is not compliant.
In a fifth embodiment of the invention the rule list is generated not from disassembly en masse but from observing and analyzing executing API calls. The execution of the application is monitored and events are collected. The monitoring of the application continues for a period of time and based on the collected events, a rule list for all API calls is generated.
A benefit of using authentication of API calls for preventing cyber-attacks is that the solution does not use information about cyber-attack method or the vulnerability it exploits; it does not rely an rules or heuristics to be configured by the user. Another advantage is the ability to detect and block cyber-attacks before any harmful malicious instructions are executed. As discussed above, since traditional black- and whitelisting-based methods for API call filtering rely on attack catalogues, they will never catch all attacks, especially new ones. Often, the attack can be detected only after malicious code has already executed on the computing device and caused significant harm. In contrast, the task of generating a list of rules for controlling the API calls and privileged instructions executed by applications is simple and deterministic. it can be automated much more efficiently than can the generation of a black list of potential attacks and attack vectors.
A change in the state of a computer system is achieved by executing privileged instructions on the processor of the computer system. Often, privileged instructions are wrapped in system API calls which, in turn, are wrapped in standard API calls provided by libraries. Some examples of API calls are write( ), read( ), open( ), and fork( ), to name just a few. Some examples of privileged instructions are sysenter and int. An attack on a computer system via exploitation of a zero-day, or unpatched vulnerability is successful only if the attacker can execute API calls and privileged instructions. If an exploited vulnerability changes a program's execution, then by definition, the API call and privileged instruction execution pattern can also change, and the attack can be detectable. In the following, the term API call can again be used to refer to all the types of privileged instructions mentioned above.
The present invention uses a rule list to monitor and enforce API calls during program execution. In one embodiment of the present invention, authentication of program execution is accomplished by observing its action from a more highly-privileged process. No modifications to the program being protected are necessary. In another embodiment of the present invention, authentication of program execution at the byte level is accomplished via dynamic or static instrumentation of the application image that is executing in the memory of the client computing device.
In one embodiment, a deterministic method can be utilized (e.g. instead of heuristics) tto mediate API calls. Instead of forcing the user to rely upon heuristics to build and configure a set of rules, one example embodiment can extract information from the internal structure of the code to generate rules and then, during the execution of the code, validate activity against them.
Whitelisting, the concept of, a priori, only allowing predetermined functions to run, is commonly used to block attacks on applications. The seccomp security feature of the Linux kernel, for example, provides a mechanism to restrict API calls by type. The restriction is at the discretion of the user, and while it provides some security, it does not prevent the attacker from using whatever permitted API calls remain to inflict damage. The advantage of the present invention is its ability to detect and block almost every category of zero-day exploits without relying on the user's knowledge of attack signatures. Further, some may embodiments may not require access to the source code, a very significant advantage over the method used in seccomp, as assuming access to third-party source code and recompilation of applications is not practical.
Coarse-grained methods focus on the broad behavior of applications, can monitor the API calls made by them. Type or sequence of API calls, file system changes, new process creation, etc., are some of the tell-tale signs of a zero-day exploit that can be detected by these coarse-grained methods. The enforcement of coarse-grained methods can be based on sand boxes, host-based intrusion prevention systems (HIPS), or virtual machine monitors (VMMs). These implementations have little visibility into the execution of an application, and the actual exploit mechanism is typically not detected. The limitations of coarse-grained behavior-based methods are two-fold. First, they do not stop the exploit. Second, as the actions that follow an exploit often overlap with known actions of the application these methods have difficulty separating normal execution from zero-day activity.
For the embodiment illustrated in
As shown in
In one example, the validation is performed by instrumenting the application code itself. This can improve performance by avoiding context switching during validation. The instrumentation can also be applied at the kernel, hypervisor, or firmware. Furthermore, the instrumentation to insert the validation code into the application binary can be done statically or dynamically. When the validation code is part of the application binary or runtime image, the application may change, and rules can be interpreted correctly to account for relocated API calls.
In one embodiment, the validation is separate from the application and the rules can be applied directly, as the application image may not change. The validation process can be implemented at several locations on the client 150, including, but not limited to VMM and kernel. As long as the validation process can observe and control API calls for applications executing on the client, the validation process can detect and block exploit attack attempts. When an API call is observed by the validation process, its calling location, target address, type of API call, and return location are validated.
In one embodiment, the rule list 128 can be continually updated as client computers execute applications. As shown in
The updated rules can be sent back to the clients and added to the rule list 128. While the embodiment discussed here uses the rule server 160 to perform the analysis, it is not limited to it. The analysis of API calls in an application and generation of rules can also be performed locally at the enforcement point 150.
Computing system 210 can include additional components including, inter alia, central processing unit 240, storage device 260, network device 250, and input/output port 270. While the computing system illustrated here has been illustrated with a single CPU, storage device, network device, and input/output port, it is noted various different configurations of the computing system can incorporate more than one of the individual components, as well as, other components. For example, the computer system may further include random-access memory (RAM), erasab e programmable read-only memory (EPROM), read-only memory (ROM), compact disk ROM (CD-ROM), storage area network (SAN), or any other storage medium that can be accessed by computing system 21.
Based on the recorded API calls, a rule>Iist is generated in step 306 by applying a validation mechanism to the location of each API call. Validation can ensure that a recorded API call is consistent with the binary structure of the code and part of ,a possible execution trace for that binary. One example of checking consistency involves using knowledge about the API call and its arguments. Based on how the arguments used by the API call are loaded into the registers serves as partial validation. The check can be further enhanced by validating the type of each argument. Once an API call has been validated, a rule is created by specifying the type and location of the call. When all the API calls have been validated, the generated rule list is transmitted to an enforcement point in step 308. At the enforcement point, the generated rule list is used to permit or deny execution of API calls based on the outcome of the validation of observed API calls.
In step 404, the new application or code is started. The validation process enumerates applications on the computing device by scanning the storage media attached to the computing device or by monitoring any process starting or modules executing on the computing device. A rule list for each module in the application process is loaded in step 406. When an API call is executed by the code in step 408. The validation process uses the rule list for that application process to determine if the API call, system call and/or privileged instruction can be permitted in step 410. If the rule is violated, an event is logged and default action is performed in step 414, otherwise the application process continues its normal execution in step 412. The code for validation of API calls can also be used in a monitoring mode to generate a rule list dynamically. In monitoring mode, upon encountering an API call, an event is logged and the code execution is allowed to proceed. The enforcement of API calls executed by the application can also be accomplished without having to modify the application code.
When an API call point is reached during program execution, the validation process uses the rule list for that process to determine if the action can be permitted in step 510. If the rule is violated, an event is logged and default action is performed in step 514, otherwise the program continues its normal execution in step 512. The code for validation of API calls can also be used in monitoring mode to generate a rule list dynamically. An event can be logged and the API call is allowed to proceed. The validation can also be enforced by inserting the validation code after the API call and validating the return to address.
Implementation of instrumentation for the purpose of API call validation can be achieved in various ways. Potential methods include, inter alia, substituting the file handle of the executable with that of an instrumented application executable, instrumenting the application image in memory, and trapping API call execution in a VMM.
When an API call, system call or privileged instruction execution is based on a computed variable, a corresponding rule cannot be created by static analysis of the application executable. Accordingly,
1The validation'method is also applied to all un or API calls that invoke API calls. The validation of API calls by an application can be masked when the API call is executed by another module or library on behalf of the application. In these examples, the originator of the API call and privileged instruction can be another module. Accordingly,
Accordingly, it is noted that systems and methods for validation of API calls and privileged instruction execution in applications are provided. The specifications and drawings are not intended to limit the exclusionary scope of this patent document.
Conclusion
Although the present embodiments have been described with reference to specific example embodiments, various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices, modules, etc. described herein can be enabled and operated using hardware circuitry, firrnv are, software or any combinationhardware firmware, and software (e.g, embodied in a machine-readable medium).
In addition, it can be appreciated that the various operations, processes, and methods disclosed herein can be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and can be performed in any order (e.g., including using means for achieving the various operations). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, in some embodiments, the machine-readable medium can be a non-transitory form of machine-readable medium.
