Method and device for virtualization log vulnerability repair

Abstract

The application provides a virtualized log vulnerability repair method and device, and relates to the technical field of computer security. The method comprises the following steps: in response to detecting that a target process uses a Log4j2 framework, obtaining a process identifier; based on the process identifier, creating an independently running virtual process in user memory through an eBPF module of a kernel, and starting a Java virtual machine and an associated network service in the virtual process; constructing a string containing a JNDI protocol identifier as an attack payload in the target process, which is used to simulate Log4j2 remote vulnerability exploitation behavior; sending the attack payload from the target process to the virtual process, and judging whether the Log4j2 remote vulnerability exists according to the response of the virtual process to the attack payload; if the Log4j2 remote vulnerability exists, mounting the eBPF module to the kernel network driver layer to intercept related network traffic. The application combines memory virtualization with kernel layer traffic interception, and realizes accurate detection and effective repair of the Log4j2 remote vulnerability.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a method and device for detecting vulnerabilities in virtualization logs. Background Technology

[0002] Virtualization-based web applications are widely used in critical business areas such as cross-border financial settlement. Apache Log4j2, a widely used Java logging plugin, has remote code execution vulnerabilities (such as the Log4j2 remote vulnerability) that pose a serious threat to the security of global financial systems.

[0003] Currently, the mainstream solution for fixing the Log4j2 vulnerability relies on official patches released by the open-source community. However, this approach has two inherent drawbacks: First, the timeliness and security of the patches depend on overseas development teams. Whether the fixes are thorough and whether they will introduce new, deeper, and more hidden vulnerabilities are difficult to fully verify and trust, resulting in poor self-control. Second, traditional vulnerability verification and fixing often require multiple computers to conduct simulated attack tests, which is a cumbersome and complex process that prevents system maintenance personnel from responding in a timely manner.

[0004] Therefore, there is an urgent need for an integrated solution that can eliminate the dependence on external patches and efficiently and autonomously achieve accurate detection and effective kernel-level repair of Log4j2 remote vulnerabilities within the operating system. Summary of the Invention

[0005] This invention provides a method and device for detecting and repairing virtualization log vulnerabilities, which solves the shortcomings of existing technologies such as reliance on external patches for Log4j2 vulnerability repair, lack of independent controllability, and complex detection and repair processes.

[0006] This invention provides a method for patching virtualization logging vulnerabilities. The method includes: when a target process is detected using a specified logging plugin framework, obtaining the process identifier of the target process, wherein the specified logging plugin framework is the Log4j2 framework; based on the obtained process identifier, creating an independently running virtual process in user memory through the kernel's extended Berkeley packet filter (eBPF) module, and starting a Java Virtual Machine and related network services in the virtual process, wherein the extended Berkeley packet filter is the eBPF module; within the target process, constructing an attack payload to simulate Log4j2 remote vulnerability exploitation behavior, wherein the attack payload contains at least a string with a Java Naming and Directory Interface (JNDI) protocol identifier, wherein the Java Naming and Directory Interface (JNDI) protocol; sending the constructed attack payload from the target process to the virtual process, and determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; when the existence of the remote vulnerability is confirmed, intercepting network traffic related to the vulnerability by mounting the eBPF module to the kernel network driver layer.

[0007] According to a virtualization logging vulnerability detection method provided by the present invention, the specific process of detecting whether a target process is using the Log4j2 framework includes: searching a predefined set of feature values ​​in the memory space of the target process through the kernel's eBPF module. The set of feature values ​​contains one or more feature items from org.apache.logging.log4j.LogManager and log4j.Logger; when these feature values ​​are found in memory, it is confirmed that the target process is using the Log4j2 framework.

[0008] According to a virtualization log vulnerability repair method provided by the present invention, the process of creating a virtual process through the kernel eBPF module includes: in the Java virtualization memory environment, using a non-memory copy process creation technology to allocate an independent memory space, thereby establishing a virtual process.

[0009] According to a virtualization log vulnerability repair method provided by the present invention, the process of constructing an attack payload includes: generating a specific format string containing a JNDI protocol identifier, wherein the string format is ${jndi:ldap: / / } or ${jndi:rmi: / / }.

[0010] According to the virtualization log vulnerability repair method provided by the present invention, the process of constructing the attack payload further includes: performing encoding obfuscation processing on the generated string, and the obfuscation method includes case conversion, special character splitting or uniform resource locator (URL) encoding.

[0011] According to a virtualization log vulnerability repair method provided by the present invention, the process of sending an attack payload to a virtual process includes: embedding a string containing a JNDI protocol identifier into the user agent or source page parameters of the Hypertext Transfer Protocol (HTTP) request header; and then sending the HTTP request to the virtual process.

[0012] According to a virtualization log vulnerability repair method provided by the present invention, the criteria for determining whether a vulnerability exists include: if the virtual process responds to the attack payload and can be remotely accessed, then the Log4j2 remote vulnerability exists; if the virtual process does not respond or cannot be remotely accessed, then the vulnerability does not exist.

[0013] According to a virtualization log vulnerability repair method provided by the present invention, the process of intercepting network traffic includes: capturing the runtime behavior characteristics of the Java Virtual Machine in real time through the eBPF module; and based on these behavior characteristics, mounting the eBPF module to the kernel network driver layer to filter and block data traffic in real time.

[0014] According to a method for detecting and repairing virtualization log vulnerabilities provided by the present invention, the method further includes a vulnerability repair step: after confirming the existence of a vulnerability, a repair instruction is injected into the logical memory area of ​​the Log4j2 framework in the target process in the form of a hot patch, and the vulnerability is repaired by modifying the program execution logic.

[0015] This invention provides a virtualization log vulnerability repair device, comprising: a detection and acquisition module for obtaining the process identifier of a target process in response to the detection that a target process uses the Log4j2 framework; a virtual environment construction module for creating an independently running virtual process in user memory based on the process identifier using the kernel's eBPF module, and starting a Java Virtual Machine and associated network services in the virtual process; a payload construction module for constructing an attack payload in the target process to simulate Log4j2 remote vulnerability exploitation behavior, wherein the attack payload includes at least a string containing a JNDI protocol identifier; a vulnerability detection module for sending the attack payload from the target process to the virtual process and determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; and a vulnerability repair module for intercepting network traffic related to the Log4j2 remote vulnerability by mounting the eBPF module to the kernel network driver layer when the Log4j2 remote vulnerability exists.

[0016] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the virtualization log vulnerability repair method as described above.

[0017] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the virtualization log vulnerability repair method as described above.

[0018] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the virtualization log vulnerability repair method as described above.

[0019] The virtualization log vulnerability repair method and device provided by this invention implements a self-contained vulnerability repair scheme by integrating eBPF technology at the kernel layer. First, memory feature search based on eBPF can accurately identify processes using the Log4j2 framework, laying the foundation for subsequent detection. By creating an independent virtual process and starting a complete service environment, the vulnerability triggering conditions are fully reproduced while ensuring security isolation. In the attack payload construction stage, the combination of standard JNDI string and encoding obfuscation technology effectively covers various vulnerability exploitation variations, improving the comprehensiveness of detection. Through internal inter-process simulated attack and response monitoring, closed-loop verification in a single-machine environment is achieved, simplifying the complexity of traditional multi-machine testing. Finally, by leveraging eBPF's traffic interception capabilities at the kernel driver layer, vulnerability exploitation is blocked from the root of communication, while runtime repair is achieved through a hot patching mechanism, avoiding dependence on external patches and ensuring effective vulnerability repair. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a virtualization log vulnerability repair method provided by the present invention.

[0022] Figure 2 This is a schematic diagram of the framework of a virtualization log vulnerability repair system provided by the present invention.

[0023] Figure 3 This is a schematic diagram of the structure of a virtualization log vulnerability repair device provided by the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0026] The following is combined with Figure 1 This invention describes a method for detecting virtualization log vulnerabilities.

[0027] Figure 1 This is a flowchart illustrating a virtualization log vulnerability repair method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following: S101. In response to the detection of the target process, use the Log4j2 framework to obtain the process identifier of the target process.

[0028] For example, the process of detecting whether a target process is using the Log4j2 framework can be implemented through a kernel-level system monitoring mechanism.

[0029] Specifically, based on eBPF technology, a dedicated probe can be deployed in kernel space. This probe, by being mounted to the system call interface, monitors the dynamic behavior of all user-space processes in real time. When the target process loads a shared library or initializes a class loader, the eBPF module intervenes in the execution flow to scan and analyze the process's memory-mapped regions.

[0030] In some embodiments, a predetermined set of features can be searched in the memory of the target process using the kernel's eBPF module.

[0031] In this embodiment of the invention, the feature set includes at least one of org.apache.logging, log4j.LogManager, and log4j.Logger.

[0032] For example, the feature search process employs a multi-stage matching strategy: First, the eBPF module traverses the process's virtual memory area (VMA) to obtain all memory-mapped regions of the target process; then, it uses a fast string matching technique based on the Boyer-Moore algorithm to search for feature strings in parallel within the text and data segments.

[0033] Alternatively, to improve search efficiency, the memory region can be divided into blocks, and a sliding window mechanism can be used to scan memory pages one by one.

[0034] Specifically, during memory search, the eBPF module ensures accuracy through the following steps: First, it monitors memory access patterns by attaching kernel probes (kprobes) to the page fault handling path of the target process; second, it builds a hash index of feature values ​​and uses a Bloom filter to quickly eliminate mismatched memory regions; then, it performs secondary verification on suspected matching regions, including checking the integrity of the class structure and verifying the consistency of the package namespace; finally, it outputs the matching results to user space through the performance event (perf_event) subsystem for subsequent processing.

[0035] Furthermore, if a set of feature values ​​is found, it is determined that the target process uses the Log4j2 framework.

[0036] For example, in verifying that a target process uses the Log4j2 framework, a multi-level verification mechanism can be used to ensure the accuracy of the judgment: the first level of verification is based on the exact matching of feature strings to ensure that the found feature values ​​fully conform to the class name specification of the Log4j2 framework; the second level of verification checks the class loading context, including verifying the consistency of the class loader hierarchy and package namespace; the third level of verification confirms that the found class does indeed contain the method signatures and field definitions specific to Log4j2 by analyzing bytecode features.

[0037] To further improve reliability, it is also possible to check whether the target process contains a Log4j2 configuration file, such as log4j2.xml or log4j2.properties, and verify the syntax correctness of the configuration file. Only when all verification conditions are met will it be finally confirmed that the target process uses the Log4j2 framework, and the corresponding process identifier (PID) and thread characteristic values ​​will be recorded.

[0038] Thus, this invention achieves accurate identification of Log4j2 framework usage through kernel-level memory scanning technology based on eBPF. Compared with traditional user-space detection methods, it has higher detection efficiency and lower overhead, and can detect processes using the Log4j2 framework in real time, providing accurate target location for subsequent vulnerability detection and remediation.

[0039] S102. Based on the process identifier, create an independently running virtual process in user memory through the kernel's eBPF module.

[0040] In some embodiments, a separate memory space can be allocated in Java virtualization memory through a process creation method that does not involve memory copying, in order to create a virtual process.

[0041] For example, the process of creating a virtual process can employ copy-on-write technology to achieve memory space isolation: the eBPF module calls the process management subsystem to create a new memory mapping based on the target process's address space descriptor. This memory mapping points to the same physical page frames but is marked as read-only in the page table entries. When either the virtual process or the target process attempts to write to these shared pages, a page fault exception is triggered. At this point, the memory management unit (MMU) allocates new physical pages and copies the original content, achieving true memory separation.

[0042] Specifically, when implementing memory isolation, an independent address space can be established through the MMU's remapping function. Then, address space layout randomization (ASLR) technology is used to allocate random base addresses to virtual processes. By setting appropriate memory protection flags, it can be ensured that virtual processes cannot accidentally modify the target process's critical data. Finally, an independent memory mapping table is established, including independent management of code segments, data segments, heaps, and stacks.

[0043] S103. Start the Java Virtual Machine and associated network services in the virtual process.

[0044] In this embodiment of the invention, the associated network service includes at least one of JNDI service, lightweight directory access protocol (LDAP) service, remote method invocation (RMI) service, and HTTP service.

[0045] For example, the service startup process can adopt a layered initialization strategy: first, start the core components of the Java Virtual Machine, including the class loading subsystem, execution engine, and runtime data area; then, start various network services according to their dependencies: first start the JNDI service to establish a naming context, then start the LDAP service to provide directory query functionality, then start the RMI service to support remote method calls, and finally start the HTTP service to handle web page requests.

[0046] Specifically, during service initialization, an independent thread pool can be allocated to each service to avoid resource contention, and appropriate timeout parameters and retry mechanisms can be configured to ensure service reliability. Security policies can be set to restrict service access permissions, and a service health check mechanism can be established to periodically verify the availability of each service.

[0047] S104. In the target process, construct an attack payload to simulate the remote exploit behavior of Log4j2.

[0048] Optionally, the attack payload may include at least a string containing the JNDI protocol identifier.

[0049] In some embodiments, a string containing the JNDI protocol identifier can be constructed.

[0050] In this embodiment of the invention, the string format can be ${jndi:ldap: / / } or ${jndi:rmi: / / }.

[0051] For example, a template library containing multiple attack vectors can be maintained, with each template targeting a specific vulnerability exploitation scenario.

[0052] For example, for LDAP services, a complete LDAP URL is generated, including the protocol header, host address, port number, and distinguished name (DN).

[0053] For example, for an RMI service, an RMI reference is constructed that includes the registry address, object identifier, and serialized data.

[0054] Specifically, when constructing attack payloads, a suitable payload template is first selected based on the characteristics of the target environment; then, the template parameters, including the target address, port number, and payload content, are dynamically filled in; next, the generated payloads are syntax-validated to ensure they conform to the corresponding protocol specifications; finally, a tracking identifier is added to each payload to facilitate subsequent analysis of the attack effect.

[0055] Thus, this invention ensures the accuracy and repeatability of vulnerability detection through a standardized attack payload generation mechanism, generating targeted attack payloads according to different testing needs, and comprehensively covering various exploitation methods of the Log4j2 remote vulnerability.

[0056] Furthermore, the string can be encoded and obfuscated.

[0057] In embodiments of the present invention, encoding obfuscation includes case conversion, special character splitting, or URL encoding.

[0058] For example, the encoding obfuscation process can employ a multi-layer transformation algorithm: in the first layer, random case conversion is applied, such as converting "jndi" to "JnDi" or "jNdI"; in the second layer, special delimiters are inserted, such as using the format ${::-J}ndi:ldap: / / to bypass simple pattern matching; in the third layer, the payload is URL encoded (Percent-encoding), converting special characters into the form of % followed by two hexadecimal digits.

[0059] Specifically, the following techniques can be used when implementing code obfuscation: establish an obfuscation rule base containing a variety of known bypass techniques; intelligently select appropriate obfuscation combinations based on the security protection level of the target environment; and perform decoding tests on the obfuscated payload to ensure that it can be correctly parsed in the target environment.

[0060] Optionally, users can also customize obfuscation rules, allowing them to adjust obfuscation strategies according to actual needs; at the same time, the obfuscation history of each payload is recorded to facilitate subsequent analysis and reproduction.

[0061] Thus, this invention effectively enhances the bypass capability of attack payloads through multi-layered coding obfuscation technology, and more realistically assesses the defense capability against complex attacks by simulating common attack methods in advanced persistent threats (APTs).

[0062] S105. Send the attack payload from the target process to the virtual process.

[0063] In some embodiments, a string containing the JNDI protocol identifier is embedded in the User-Agent or Referer parameter of the HTTP request header.

[0064] For example, the payload embedding process employs a protocol compliance check mechanism, first constructing a request message that conforms to the HTTP specification, and then embedding the attack payload into a specified header field according to the standard format.

[0065] For example, in the User-Agent field, the payload is disguised as a normal browser identifier string.

[0066] For example, the payload can be embedded as part of the URL parameter in the Referer field.

[0067] Specifically, when implementing payload embedding, it is necessary to maintain the correctness of the HTTP request syntax to avoid rejection by intermediate devices due to format errors; simulate the request characteristics of a real browser, including the appropriate header field order and value format; and handle the escaping of special characters to ensure that the payload is not corrupted during transmission.

[0068] Furthermore, HTTP requests can be sent to virtual processes to send attack payloads to virtual processes.

[0069] For example, a connection to a virtual process can be established through the Transmission Control Protocol / Internet Protocol (TCP / IP) stack, and a three-way handshake can be used to ensure the reliability of the connection. At the transport layer, flow control and congestion control mechanisms are implemented to dynamically adjust the sending rate according to network conditions.

[0070] Optionally, appropriate latency and jitter can be introduced to simulate a real network environment.

[0071] Specifically, when sending an HTTP request, the system parses the target address and port number, establishes a socket connection, serializes the request message according to the HTTP protocol specification, sends data through a system call, and monitors the sending status.

[0072] Thus, this invention ensures the effective delivery of attack payloads through the simulation of real network protocols and a reliable transmission mechanism, and provides a reliable testing environment for vulnerability detection by accurately reproducing real-world attack scenarios.

[0073] S106. Determine whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload.

[0074] In some embodiments, if a virtual process responds to an attack payload and is remotely accessed, the Log4j2 remote vulnerability is determined to exist.

[0075] For example, the network connection status of a virtual process can be monitored, and new outbound connections can be detected by analyzing the contents of the / proc / net / tcp file. At the same time, the system call sequence of the virtual process can be tracked through the eBPF module, paying particular attention to the execution of key calls such as connect and execute. The memory status of the virtual process can also be checked to look for signs of malicious code loading.

[0076] Specifically, upon confirming the existence of a vulnerability, it is possible to verify whether a network connection to an external server has been established; verify that the destination of the connection matches the address specified in the attack payload; detect whether a class file from an external source has been loaded into the virtual process; and confirm the complete execution of the exploit chain by analyzing the system call sequence.

[0077] In other embodiments, if the virtual process is unresponsive or cannot be accessed remotely, the Log4j2 remote vulnerability is determined to not exist.

[0078] For example, a reasonable timeout period can be set, during which the state changes of the virtual process can be continuously monitored. If no expected signs of vulnerability triggering are observed, a verification request can be sent to confirm network connectivity. At the same time, the log output of the virtual process can be analyzed to look for error messages or abnormal records.

[0079] Specifically, once the vulnerability is confirmed to be non-existent, verify the correctness of the network configuration to ensure that the virtual process can receive requests normally; check the impact of security policies to confirm whether there are protective measures preventing the exploitation of the vulnerability; analyze the configuration of Log4j2 to confirm whether there are relevant security settings; and eliminate other possible interfering factors, such as service initialization failure or resource limitations.

[0080] Thus, this invention ensures the accuracy of vulnerability detection results through multi-dimensional monitoring indicators and rigorous verification processes, effectively distinguishing genuine vulnerability exploits from other anomalies, and providing a reliable basis for security protection decisions.

[0081] S107. If the Log4j2 remote vulnerability exists, the network traffic related to the Log4j2 remote vulnerability will be intercepted by mounting the eBPF module to the kernel network driver layer.

[0082] In some embodiments, the runtime behavior of the Java Virtual Machine can be captured through the eBPF module.

[0083] For example, the eBPF module is used to set monitoring points in critical execution paths through kernel probes (kprobes) and user-mode probes (uprobes) to track the runtime behavior of the Java Virtual Machine; monitor the class loading process and record the loading timestamp and source of each class; monitor the method call sequence, paying particular attention to application programming interface (API) calls related to vulnerability exploitation; and track memory allocation patterns to detect abnormal memory usage behavior.

[0084] Specifically, when capturing runtime behavior, the eBPF module first mounts to the class loader subsystem, monitors the loading events of all classes, tracks the just-in-time (JIT) compilation process, records the compilation information of hot methods, monitors garbage collection (GC) activities, analyzes memory management status, and finally uses the performance event subsystem to collect runtime metrics and outputs monitoring data in real time through BPF mapping.

[0085] Furthermore, based on runtime behavior, the eBPF module is mounted to the kernel network driver layer to filter and block traffic.

[0086] For example, traffic filtering can be implemented using the following mechanism: an eBPF module is attached to the ingress and egress hooks of the network device through the traffic control (TC) subsystem, and then complex filtering rules are defined. Multi-dimensional matching is performed based on five-tuple information, protocol characteristics, and payload content. For detected malicious traffic, measures such as dropping, redirecting, or rate limiting can be taken.

[0087] Specifically, traffic blocking can employ the following mechanisms: establishing a dynamic filtering rule base containing known attack characteristics and abnormal patterns, identifying and blocking multiple data packets belonging to the same attack session, and using the token bucket algorithm for traffic shaping to prevent denial-of-service attacks.

[0088] Thus, this invention achieves accurate identification and effective blocking of malicious traffic through deep packet inspection and intelligent flow control at the kernel level, providing fundamental security guarantees at the operating system level and effectively preventing the exploitation of the Log4j2 remote vulnerability.

[0089] In the virtualization log vulnerability repair method provided by this invention, the external dependence on community patches is eliminated through the synergistic effect of memory virtualization and kernel-level protection. First, based on eBPF memory feature scanning, the process using the Log4j2 framework is accurately located. Then, by creating an independent virtual process and building a complete service environment, the vulnerability triggering scenario is realistically recreated in an isolated space. By constructing an attack payload containing JNDI protocol identifiers and performing inter-process simulated attacks, closed-loop vulnerability verification is achieved in a single-machine environment. Finally, by leveraging eBPF's traffic interception capabilities at the kernel driver layer, the vulnerability exploitation is blocked from the root of communication, thereby eliminating the external dependence on community patches and achieving accurate detection and effective repair of Log4j2 remote vulnerabilities.

[0090] Optionally, after determining that a Log4j2 remote vulnerability exists, the present invention can also inject the repair instructions into the logical memory area of ​​the Log4j2 framework in the target process in the form of a hot patch, so as to change its program execution logic.

[0091] In some embodiments, hot patch injection employs runtime code modification technology, which attaches to the target process via process tracing (ptrace) system calls or / or process information (proc) file system to obtain the target process's memory mapping information, locate the critical functions that need to be patched, and create a backup of the original code before implementing the patch.

[0092] For example, hot patches can implement targeted fixes for different vulnerability types.

[0093] For example, for JNDI lookup vulnerabilities, the patch will modify the implementation logic of the lookup method to disable the dangerous lookup function.

[0094] For example, to address message formatting vulnerabilities, patches will strengthen input validation and escape special characters.

[0095] Specifically, when implementing hot patches, the compatibility of the target environment is first verified, including the operating system version, Java version, and Log4j2 version; then, a security check is performed to ensure that the patch does not introduce new security risks; next, an atomic update is performed to ensure that there are no state inconsistencies during the patch application process; and finally, functional verification is performed to confirm that the patch is working correctly and has not broken existing functions.

[0096] Thus, this invention achieves instant fixes for the Log4j2 vulnerability through runtime hot patching technology, without requiring application restarts or waiting for official patch releases, greatly shortening the vulnerability fix window and effectively reducing the security risks.

[0097] Optionally, the virtualization log vulnerability repair method provided by the present invention can be run based on a virtualization log vulnerability repair system.

[0098] The following is combined with Figure 2 The virtualization log vulnerability detection system provided by this invention is described in detail.

[0099] Figure 2 This is a schematic diagram of the framework of a virtualization log vulnerability detection system provided by the present invention. Figure 2 As shown, the system may include: a Java container 210, a Java Virtual Machine 220, and a Java Virtual Machine 230.

[0100] The Java container 210 includes a target process 211 and a virtual process 212. The virtual process 212 includes JNDI service, LDAP service, RMI service and HTTP service; the operating system 230 includes an eBPF module 231 and a network driver layer 232.

[0101] For example, the overall operating logic of the virtualization log vulnerability detection system can be as follows: After the system starts, the eBPF module 231 first initializes in the operating system 230, loading the necessary detection programs and filtering rules; the system scans all processes in the Java container 210 and identifies the target process 211 using the Log4j2 framework; then the system creates a virtual process 212 in the isolated environment and starts a complete service stack, including JNDI service, LDAP service, RMI service and HTTP service; during the detection phase, the system injects a specially crafted attack payload into the target process 211 and monitors the response behavior of the virtual process 212; during the protection phase, the eBPF module 231 implements traffic interception at the network driver layer 232 to block malicious connections.

[0102] Thus, through its hierarchical architecture and intelligent operation and maintenance mechanism, this system provides a complete and reliable Log4j2 vulnerability repair solution, which can accurately identify security threats and quickly implement effective protection, thereby improving the overall security level of the system.

[0103] Figure 3 This is a structural diagram of a virtualization log vulnerability repair device provided in an embodiment of this application. The virtualization log vulnerability repair device includes: a detection and acquisition module 301, a virtual environment construction module 302, a payload construction module 303, a vulnerability detection module 304, and a vulnerability repair module 305.

[0104] The system comprises: a detection and acquisition module 301, used to obtain the process identifier of the target process in response to the detection that the target process uses the Log4j2 framework; a virtual environment construction module 302, used to create an independently running virtual process in user memory based on the process identifier through the kernel's eBPF module, and start the Java Virtual Machine and related network services in the virtual process; a payload construction module 303, used to construct an attack payload in the target process to simulate the exploit behavior of the Log4j2 remote vulnerability, the attack payload including at least a string containing the JNDI protocol identifier; a vulnerability detection module 304, used to send the attack payload from the target process to the virtual process, and determine whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; and a vulnerability remediation module 305, used to intercept network traffic related to the Log4j2 remote vulnerability by mounting the eBPF module to the kernel network driver layer when the Log4j2 remote vulnerability exists.

[0105] In some embodiments, the detection and acquisition module 301 described above is specifically used to: search for a predefined set of feature values ​​in the memory space of the target process through the kernel's eBPF module. The set of feature values ​​contains one or more feature items from org.apache.logging.log4j.LogManager and log4j.Logger. When these feature values ​​are found in memory, it is confirmed that the target process is using the Log4j2 framework.

[0106] In some embodiments, the virtual environment construction module 302 is specifically used to allocate an independent memory space in a Java virtualization memory environment using a non-memory copy process creation technique, thereby establishing a virtual process.

[0107] In some embodiments, the payload construction module 303 is specifically used to generate a specific format string containing a JNDI protocol identifier, wherein the string format is ${jndi:ldap: / / } or ${jndi:rmi: / / }.

[0108] In some embodiments, the payload construction module 303 is specifically used to perform encoding obfuscation processing on the generated string, and the obfuscation method includes case conversion, special character splitting or Uniform Resource Locator encoding.

[0109] In some embodiments, the vulnerability detection module 304 is specifically used to: embed a string containing the JNDI protocol identifier into the user agent or source page parameters of the Hypertext Transfer Protocol request header; and then send the HTTP request to the virtual process.

[0110] In some embodiments, the vulnerability detection module 304 is specifically used to: determine that a Log4j2 remote vulnerability exists if the virtual process responds to the attack payload and can be remotely accessed; and determine that the vulnerability does not exist if the virtual process does not respond or cannot be remotely accessed.

[0111] In some embodiments, the vulnerability remediation module 305 is specifically used to: capture the runtime behavior characteristics of the Java Virtual Machine in real time through the eBPF module; and based on these behavior characteristics, mount the eBPF module to the kernel network driver layer to filter and block data traffic in real time.

[0112] In some embodiments, the vulnerability repair module 305 is further configured to inject repair instructions into the logical memory area of ​​the Log4j2 framework in the target process in the form of a hot patch after confirming the existence of a vulnerability, thereby achieving vulnerability repair by modifying the program execution logic.

[0113] In the virtualized log vulnerability repair device provided by this invention, the external dependence on community patches is eliminated through the synergistic effect of memory virtualization and kernel-level protection. First, based on eBPF memory feature scanning, the process using the Log4j2 framework is accurately located. Then, by creating an independent virtual process and building a complete service environment, the vulnerability triggering scenario is realistically recreated in an isolated space. By constructing an attack payload containing JNDI protocol identifiers and performing inter-process simulated attacks, closed-loop vulnerability verification is achieved in a single-machine environment. Finally, by leveraging eBPF's traffic interception capabilities at the kernel driver layer, the vulnerability exploitation is blocked from the root of communication, thereby eliminating the external dependence on community patches and achieving accurate detection and effective repair of Log4j2 remote vulnerabilities.

[0114] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communications interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a virtualization log vulnerability remediation method, which includes: in response to detecting that a target process uses the Log4j2 framework, obtaining a process identifier; based on the process identifier, creating an independently running virtual process in user memory through the kernel's eBPF module, and starting a Java Virtual Machine and associated network services in the virtual process; constructing a string containing a JNDI protocol identifier as an attack payload in the target process to simulate Log4j2 remote vulnerability exploitation behavior; sending the attack payload from the target process to the virtual process, and determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; if it exists, intercepting relevant network traffic by mounting the eBPF module to the kernel network driver layer.

[0115] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the virtualization log vulnerability repair method provided by the above methods. The method includes: in response to detecting that a target process uses the Log4j2 framework, obtaining a process identifier; based on the process identifier, creating an independently running virtual process in user memory through the kernel's eBPF module, and starting a Java Virtual Machine and associated network services in the virtual process; constructing a string containing a JNDI protocol identifier as an attack payload in the target process to simulate Log4j2 remote vulnerability exploitation behavior; sending the attack payload from the target process to the virtual process, and determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; if it exists, intercepting relevant network traffic by mounting the eBPF module to the kernel network driver layer.

[0117] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the virtualization log vulnerability repair method provided by the above methods. This method includes: in response to detecting that a target process uses the Log4j2 framework, obtaining a process identifier; based on the process identifier, creating an independently running virtual process in user memory through the kernel's eBPF module, and starting a Java Virtual Machine and associated network services in the virtual process; constructing a string containing a JNDI protocol identifier as an attack payload in the target process to simulate Log4j2 remote vulnerability exploitation behavior; sending the attack payload from the target process to the virtual process, and determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload; if it exists, intercepting relevant network traffic by mounting the eBPF module to the kernel network driver layer.

[0118] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0119] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting and repairing virtualization log vulnerabilities, characterized in that, The method includes the following steps: In response to the detection that the target process is using a logging plugin framework, the process identifier of the target process is obtained, wherein the logging plugin framework is the Log4j2 framework; Based on the process identifier, an independently running virtual process is created in user memory through the kernel's extended Berkeley package filter module, and a Java Virtual Machine and associated network services are started in the virtual process. The extended Berkeley package filter module is an eBPF module. In the target process, an attack payload is constructed to simulate Log4j2 remote exploit behavior. The attack payload includes at least a string containing a Java Naming and Directory Interface (JNDI) protocol identifier. The attack payload is sent from the target process to the virtual process, and the existence of the Log4j2 remote vulnerability is determined based on the virtual process's response to the attack payload. If the Log4j2 remote vulnerability exists, the network traffic related to the Log4j2 remote vulnerability will be intercepted by mounting the eBPF module to the kernel network driver layer.

2. The method according to claim 1, characterized in that, The detected target process uses a logging plugin framework, including: The kernel's eBPF module searches the target process's memory for a predetermined set of features, the set of features including at least one of org.apache.logging, log4j.LogManager, and log4j.Logger; If the set of features is found, it is determined that the target process uses the Log4j2 framework.

3. The method according to claim 1, characterized in that, The creation of independently running virtual processes in user memory via the kernel's eBPF module includes: In Java Virtualization Memory, a separate memory space is allocated to create the virtual process using a non-memory copy process creation method.

4. The method according to claim 1, characterized in that, The constructed attack payload, used to simulate Log4j2 remote exploit behavior, includes: Construct a string containing the JNDI protocol identifier, in the format ${jndi:ldap: / / } or ${jndi:rmi: / / }.

5. The method according to claim 4, characterized in that, The attack payload constructed to simulate Log4j2 remote exploit behavior also includes: The string is subjected to encoding obfuscation, which includes case conversion, special character splitting, or URL encoding.

6. The method according to claim 1, characterized in that, Sending the attack payload from the target process to the virtual process includes: Embed the string containing the JNDI protocol identifier into the User-Agent or Referer parameter of the HTTP request header; The HTTP request is sent to the virtual process.

7. The method according to claim 1, characterized in that, The step of determining whether the Log4j2 remote vulnerability exists based on the virtual process's response to the attack payload includes: If the virtual process responds to the attack payload and is remotely accessed, then the Log4j2 remote vulnerability is determined to exist. If the virtual process is unresponsive or cannot be accessed remotely, then the Log4j2 remote vulnerability is determined to be nonexistent.

8. The method according to claim 1, characterized in that, The step of mounting the eBPF module to the kernel network driver layer to intercept network traffic related to the Log4j2 remote vulnerability includes: The eBPF module captures the runtime behavior of the Java Virtual Machine; Based on the aforementioned operational behavior, the eBPF module is mounted to the kernel network driver layer to filter and block traffic.

9. The method according to claim 1, characterized in that, The method further includes: After determining that the Log4j2 remote vulnerability exists, the patching instructions are injected as a hot patch into the logical memory area of ​​the Log4j2 framework in the target process to change its program execution logic.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

Images