Vulnerability detection method and device, electronic equipment and computer readable storage medium

Abstract

The application provides a vulnerability detection method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: a scanner sends a payload request to a server to be detected, wherein the payload request comprises a vulnerability verification code; the server to be detected executes the payload request, and sends a JNDI request to a JNDI server when the execution of the payload request is abnormal; the JNDI server returns a class file corresponding to the JNDI request; and the server to be detected executes the code in the class file to further verify whether a vulnerability exists in the server to be detected according to the execution result of the code. The application detects the vulnerability of the server to be detected through the payload request comprising the vulnerability verification code. The vulnerability verification code is only used to send the JNDI request, so the code is relatively simple, the possibility of being filtered is relatively small, and the accuracy of the vulnerability detection is improved.

Description

Technical Field

[0001] This application relates to the field of cybersecurity, and more specifically, to a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Currently, common vulnerability detection methods involve sending one or more specially processed requests to the server being tested, and then using the target web server's response to determine if a vulnerability exists. However, during vulnerability detection, not all vulnerabilities will generate a response after being triggered, and requests may be filtered when a vulnerability is triggered, leading to a lower accuracy rate in vulnerability detection. Summary of the Invention

[0003] In view of this, the purpose of the embodiments of this application is to provide a vulnerability detection method, apparatus, electronic device and computer-readable storage medium that can improve the accuracy of vulnerability detection.

[0004] In a first aspect, embodiments of this application provide a vulnerability detection method, comprising: sending a payload request to a server to be detected via a scanner, the payload request including vulnerability verification code; executing the payload request via the server to be detected, and sending a JNDI request to a JNDI server when the payload request execution fails; the JNDI server returning a class file corresponding to the JNDI request to the server to be detected based on the JNDI request; and the server to be detected, after obtaining the class file corresponding to the JNDI request, executing the code inside the class file corresponding to the JNDI request to further verify whether there is a vulnerability in the server to be detected based on the execution result of the code.

[0005] In the above implementation process, the server under test executes a payload request. If an exception occurs during payload request execution, a JNDI request is sent to the JNDI server for initial vulnerability detection. The detection results are then further verified by executing the code within the class file returned by the JNDI server. This reduces the occurrence of false positives and false negatives, improving the accuracy of vulnerability detection. Furthermore, since this payload request is vulnerability detection code used only to trigger the JNDI request, the code is relatively simple, making it easy to bypass security detection products when exploiting vulnerabilities, and the likelihood of it being filtered out is low, further improving the accuracy of vulnerability detection.

[0006] In one embodiment, the JNDI server returns the class file corresponding to the JNDI request to the server to be detected according to the JNDI request, including: after obtaining the JNDI request, the JNDI server parses the JNDI request to determine the class file corresponding to the JNDI request, and sends a class file retrieval request to the target server; the target server returns the corresponding class file to the JNDI server according to the class file retrieval request.

[0007] In the above implementation process, by setting the target server to store class files, this vulnerability detection method can also be used on some special JNDI servers, increasing the application scenarios of this vulnerability detection method.

[0008] In one embodiment, the class file stores code that verifies or exploits vulnerabilities.

[0009] In the above implementation process, by storing verification or exploit code in the class file, the vulnerability of the server to be tested can be detected or exploited by executing the verification or exploit code, so as to further verify the vulnerability in the server to be tested, thereby improving the accuracy of vulnerability detection of the server to be tested.

[0010] In one embodiment, before the scanner sends a payload request to the server to be tested for execution of the payload request, the method further includes: sending a vulnerability detection request to the server to be tested via the scanner; executing the vulnerability detection request via the server to be tested and returning a vulnerability detection result to the scanner; if the server to be tested does not return the vulnerability detection result, the scanner constructs one or more payload requests based on the vulnerability detection request.

[0011] In the above implementation process, when the server under test does not return vulnerability detection results, the scanner further constructs a payload request for the server under test to perform further vulnerability detection. Further processing is performed on cases where no vulnerability detection results are returned, thereby improving the accuracy of vulnerability detection.

[0012] In one embodiment, the method further includes: the scanner determining whether the server to be detected has vulnerabilities by examining the log records of the JNDI server.

[0013] In the above implementation process, the efficiency of vulnerability detection can be improved when the scanner checks the JNDI server's logging settings after a JNDI request is issued. The accuracy of vulnerability detection can be improved when the scanner checks the JNDI server's logging settings after code execution within a class file. The effectiveness of the vulnerability detection method can be adjusted by modifying the scanner's JNDI server logging settings, thus expanding the application scenarios for vulnerability detection.

[0014] In one embodiment, the JNDI server is integrated on the scanner.

[0015] In the above implementation process, by integrating the JNDI server onto the scanner, the scanner, the server under test, and the JNDI server are always in the same network environment. Even if the server under test is in an intranet environment, vulnerability detection can still be performed, reducing the limitations of the network environment of the server under test on vulnerability detection and improving the adaptability of vulnerability detection to various scenarios.

[0016] In one embodiment, the JNDI server includes multiple different JNDI servers.

[0017] In the above implementation process, by setting up multiple different JNDI servers, each with its own environment, the payload request can be successfully executed in different environments. This increases the adaptability of the vulnerability detection method to different environments and reduces the limitations imposed by the environment on the use of this vulnerability detection method.

[0018] Secondly, embodiments of this application also provide a vulnerability detection device, comprising: a request sending module, configured to send a payload request to a server to be detected via a scanner, the payload request including vulnerability verification code; a first execution module, configured to execute the payload request via the server to be detected, and send a JNDI request to a JNDI server when the payload request execution fails; a return module, configured to have the JNDI server return a class file corresponding to the JNDI request to the server to be detected based on the JNDI request; and a second execution module, configured to have the server to be detected, after obtaining the class file corresponding to the JNDI request, execute the code inside the class file corresponding to the JNDI request, so as to further verify whether there is a vulnerability in the server to be detected based on the execution result of the code.

[0019] Thirdly, embodiments of this application also provide an electronic device, including: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method described in the first aspect above, or any possible implementation of the first aspect.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the vulnerability detection method described in the first aspect or any possible implementation thereof.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A schematic diagram illustrating the interaction between the scanner, the server to be detected, the JNDI server, and the target server provided in the embodiments of this application;

[0024] Figure 2 A block diagram illustrating an electronic device provided in an embodiment of this application;

[0025] Figure 3 A flowchart of the vulnerability detection method provided in the embodiments of this application;

[0026] Figure 4 This is a schematic diagram illustrating the interaction between the scanner, the server to be detected, the RMI server, and the target server provided in an embodiment of this application.

[0027] Figure 5 This is a schematic diagram of the functional modules of the vulnerability detection device provided in the embodiments of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] In today's internet environment, all kinds of web applications are emerging. These web applications have changed people's daily lives and habits, and people are becoming increasingly dependent on them. Various web applications have been integrated into people's lives.

[0031] Attacks targeting web services are increasing, and the methods are becoming more diverse. Therefore, more and more people are focusing on how to quickly and efficiently detect vulnerabilities and how to exploit them. Discovering the hidden problems as early as possible is crucial to ensuring that web applications function properly in the application environment without causing major security incidents and reducing unnecessary losses.

[0032] Through long-term research, the inventors of this application have discovered numerous problems in the current vulnerability detection and exploitation process. For example, during vulnerability detection, not all vulnerabilities can be identified by the response from the target web server; some vulnerabilities do not provide a response after being triggered. Furthermore, if complex operations are required to exploit vulnerabilities, the constructed payload becomes more complex, resulting in bloated requests that are easily filtered by the target web server. Even if the request reaches the target web server, parts of the payload may be filtered, preventing successful exploitation. Additionally, even if the code is not filtered, the exploitation method varies in different environments, leading to inaccurate vulnerability detection results in certain environments.

[0033] In view of this, the inventors of this application propose a method for detecting and exploiting vulnerabilities such as command execution, code execution, and deserialization in Java-based web servers using JNDI. Specifically, when detecting vulnerabilities, one or more payloads are constructed and sent to the server under test. If the server under test triggers a vulnerability while processing this request, it will issue a JNDI request and send it to a JNDI server. The JNDI server will return a remote object to the server under test. When the server under test receives this object, it will execute the code within the object. This code can be used to further verify the existence of vulnerabilities and perform more complex exploits.

[0034] To make the vulnerability detection method in this solution easier to understand, some basic concepts of this application will be described first:

[0035] JNDI (Java Naming and Directory Interface) is a standard Java naming system interface provided by Sun Microsystems. JNDI provides a unified client API and, through different implementations of the JNDI Service Provider Interface (SPI), allows administrators to map the JNDI API to specific naming services and directory systems, enabling Java applications to interact with these naming and directory services.

[0036] Payload: Viruses typically perform harmful or malicious actions. The part of the virus code that implements this function is called the "payload." The payload can do anything a program running in the victim's environment can do, and can perform actions including corrupting or deleting files, sending sensitive information to the virus's author or any arbitrary recipient, and providing a backdoor to the infected computer.

[0037] To facilitate understanding of this embodiment, the operating environment for implementing the vulnerability detection method disclosed in this application embodiment will be described in detail first.

[0038] like Figure 1 The diagram illustrates the interaction between a scanner, a server under test, a JNDI server, and a target server, as provided in an embodiment of this application. The server under test establishes a communication connection with the scanner and the JNDI server via a network for data communication or interaction. Similarly, the JNDI server establishes a communication connection with the scanner and the target server via a network for data communication or interaction.

[0039] The scanner, the server under test, the JNDI server, and the target server can be set on the same device, partially on the same device, or all on different devices. These devices can be personal computers (PCs), tablets, smartphones, personal digital assistants (PDAs), etc.

[0040] Of course, the scanner, the server under test, the JNDI server, and the target server can also be different terminals. For example, the scanner and the server under test can be clients, and the NDI server and the target server can be remote terminals. Alternatively, the server under test can be a client, and the scanner, NDI server, and target server can be remote terminals, etc. The specific configuration of the scanner, the server under test, the JNDI server, and the target server can be adjusted according to the actual situation, and this application does not impose specific restrictions.

[0041] The scanner described above is used to send vulnerability detection requests to the server to be detected and receive the execution result of the vulnerability detection request from the server to be detected. Based on the execution result of the vulnerability detection request, a payload request is constructed to perform vulnerability detection on the server to be detected again through the payload request.

[0042] The server under test is used to execute vulnerability detection requests and payload requests sent by the scanner, and to send the execution results to the scanner. The server under test is also used to send a JNDI request to the JNDI server when an exception occurs during payload execution, to execute the code in the class file returned by the JNDI server, and to send the execution result to the scanner.

[0043] The JNDI server is used to parse a JNDI request after receiving it, obtain the server address corresponding to the JNDI request, and send the JNDI request to the target server corresponding to the server address so that the target server can return the corresponding class file.

[0044] The target server here stores a class file containing vulnerability detection code. After receiving a JNDI request, the target server processes the JNDI request to obtain the corresponding class file and return it to the JNDI server.

[0045] To facilitate understanding of this embodiment, the electronic device that performs the vulnerability detection method disclosed in this application embodiment will be described in detail below.

[0046] like Figure 2 The diagram shown is a block illustration of an electronic device. The electronic device 100 may include a memory 111 and a processor 113. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100. For example, the electronic device 100 may also include components that are more... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0047] The memory 111 and processor 113 described above are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The processor 113 described above is used to execute executable modules stored in the memory.

[0048] The memory 111 can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 111 stores programs, and the processor 113 executes these programs upon receiving execution instructions. The methods executed by the electronic device 100 as defined in any embodiment of this application can be applied to or implemented by the processor 113.

[0049] The aforementioned processor 113 may be an integrated circuit chip with signal processing capabilities. The processor 113 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a digital signal processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0050] The electronic device 100 in this embodiment can be used to execute various steps in the various methods provided in the embodiments of this application. The implementation process of the vulnerability detection method is described in detail below through several embodiments.

[0051] Please see Figure 3 This is a flowchart of the vulnerability detection method provided in the embodiments of this application. The following will describe... Figure 3 The specific process shown will be explained in detail.

[0052] Step 201: Send the payload request to the server to be detected via the scanner.

[0053] Generally, vulnerabilities on the market are mostly of a few common types, and new vulnerabilities are rare. Even if new vulnerabilities emerge, they are likely to fall under one of these common types, and analog detection can be used for these new vulnerabilities. Therefore, for common vulnerabilities on the market, corresponding vulnerability detection code can be built in advance based on these common vulnerabilities before detection, and this vulnerability detection code can be stored in an appropriate location (e.g., scanner, target server). During vulnerability detection, this vulnerability detection code is executed on the server under test, and the existence of vulnerabilities on the server under test can be determined based on the execution status or results.

[0054] The payload request here includes vulnerability verification code. This payload request may include one or more requests. When the payload request consists of multiple requests, the vulnerability verification code corresponding to each payload request is different, and the type of vulnerability being verified is different for each payload request.

[0055] The vulnerability verification code in the payload request mentioned above is a code segment pre-built based on common vulnerabilities for sending JNDI requests.

[0056] Understandably, a scanner can send multiple payload requests to the server under test simultaneously. Upon receiving these requests, the server executes them sequentially. Alternatively, based on the probability of different vulnerabilities occurring, different payload requests can be sent sequentially to the server under test, allowing the server to execute the corresponding vulnerability verification code according to the order of the received payload requests.

[0057] The server to be tested here can be any webpage, application software, plugin, etc.

[0058] Step 202: Execute the payload request through the server to be tested, and send a JNDI request to the JNDI server if the payload request execution fails.

[0059] Understandably, the vulnerability detection code in the payload request is pre-built code specifically for vulnerability detection. That is, this vulnerability detection code is built with corresponding vulnerability rules tailored to the characteristics of different vulnerabilities.

[0060] The payload request execution exception here means that the server under test encountered an error during the execution process or the execution result when executing the payload request.

[0061] For example, under normal circumstances, the process of a server under test performing a certain action is as follows: after obtaining object A, verify object A. If verification is successful, execute the request corresponding to object A. Or, if verification fails, stop executing the action. If the payload request modifies object A into object B, which the server under test cannot handle, and sends this payload request to the server under test, and if the server under test, after obtaining object B, directly executes the request corresponding to object B, it indicates an execution exception occurred during the execution of the payload request, and a JNDI request is triggered and sent to the JNDI server.

[0062] For example, if a payload request is to request the server to be tested to access a certain website, and the server to be tested does not respond to the payload request, fails to access the website, or accesses another website, it indicates that an execution error occurred when executing the payload request, and a JNDI request is triggered to be sent to the JNDI server.

[0063] The above-mentioned payload request execution exception is merely an example. The payload request can be adapted to the specific vulnerability type, and the execution process of the corresponding payload request action will also be different. This application does not impose any specific restrictions.

[0064] The JNDI request here can include the name of the server to be detected, the address of the server to be detected, the exception code, the request path, etc.

[0065] The JNDI servers mentioned above can include RMI, LDAP, and other servers. Understandably, different JNDI servers correspond to different vulnerability detection environments.

[0066] Step 203: The JNDI server returns the class file corresponding to the JNDI request to the server to be tested based on the JNDI request.

[0067] The class file here stores code that verifies or exploits vulnerabilities. The code for verifying or exploiting vulnerabilities in this class file is pre-built based on the vulnerability.

[0068] Understandably, the vulnerability verification or exploitation code stored in the class file is used to further verify or exploit detected vulnerabilities. The vulnerability detection code in the payload request triggers the server being tested to send an NDI request; its main function is to send the request. During vulnerability detection, it may be necessary to first check for the existence of a vulnerability; if a vulnerability exists, it is then exploited. The payload request stores the code for detecting the existence of a vulnerability, while the class file stores the code for further exploitation. In other words, the vulnerability detection code stored in the payload request and the vulnerability verification or exploitation code stored in the class file represent different types of code required at different stages of vulnerability detection or for different types of vulnerabilities.

[0069] By storing the vulnerability detection code separately, the payload request code can be made simpler during vulnerability detection, making it less likely to be filtered out and able to bypass security detection products such as vulnerability execution, thereby improving the accuracy of vulnerability detection.

[0070] The JNDI server mentioned above stores class files. When the JNDI server receives a JNDI request, it parses the request to determine the corresponding class file and returns the class file to the server to be tested.

[0071] Step 204: After obtaining the class file corresponding to the JNDI request, the server under test executes the code inside the class file corresponding to the JNDI request to further verify whether there are vulnerabilities in the server under test based on the execution result of the code.

[0072] When the server under test executes the payload request, or during payload transmission, unexpected situations may occur, potentially leading to false positives when the server executes the payload request to detect vulnerabilities. By re-executing the code within the class file, the vulnerabilities in the server under test are further detected to ensure the accuracy of vulnerability detection.

[0073] In some embodiments, the code inside the class file executed by the server under test is exploit code, and the server under test can further exploit the vulnerability by executing the code inside the class file.

[0074] In the above implementation process, the server under test executes a payload request. If an exception occurs during payload request execution, a JNDI request is sent to the JNDI server for initial vulnerability detection. The detection results are then further verified by executing the code within the class file returned by the JNDI server. This reduces the occurrence of false positives and false negatives, improving the accuracy of vulnerability detection. Furthermore, since this payload request is vulnerability detection code used only to trigger the JNDI request, the code is relatively simple, making it easy to bypass security detection products when exploiting vulnerabilities, and the likelihood of it being filtered out is low, further improving the accuracy of vulnerability detection.

[0075] In one possible implementation, step 202 includes: after receiving a JNDI request, the JNDI server parses the JNDI request to determine the class file corresponding to the JNDI request, and sends a class file retrieval request to the target server. The target server then returns the corresponding class file to the JNDI server based on the class file retrieval request.

[0076] In practical vulnerability detection, some JNDI servers cannot store and process class files; they can only act as a bridge between the server being tested and the class file storage server, enabling information exchange between these servers. In this case, a target server also needs to be configured to build and store the class files.

[0077] The target server stores class files. During the construction of the target server and JNDI server, the class file links are registered with the JNDI server. During class file registration, the resource names in the JNDI service and the class file links in the target server correspond one-to-one.

[0078] After receiving a JNDI request, the JNDI server parses the JNDI request to determine the resource name corresponding to the JNDI request, and uses the resource name to determine the class file linked to the resource name, and then sends a request to the target server to obtain the class file.

[0079] After receiving the request for the class file, the target server returns the corresponding class file to the JNDI server.

[0080] To better understand the vulnerability detection method in this embodiment, the following uses an RMI server as an example to further describe the vulnerability detection method with examples:

[0081] like Figure 4 As shown, when detecting vulnerabilities, the scanner sends a payload request to the server under test (specifically, http: / / target / ?=jndi:rmi: / / localhost:8888 / exp in the diagram), where the parameter value is an RMI request link. When the server under test executes this link, if a vulnerability is found, it sends an RMI request. This RMI request is received by the RMI server, which parses the request, finds the corresponding object on the target server through the path "exp," retrieves the object (class file) from the target server, and returns it to the server under test. The server under test then performs a series of default processes on the object to determine whether a vulnerability exists based on the processing results.

[0082] In the above implementation process, by setting the target server to store class files, this vulnerability detection method can also be used on some special JNDI servers, increasing the application scenarios of this vulnerability detection method.

[0083] In one possible implementation, the class file stores code that verifies or exploits vulnerabilities.

[0084] The class files here can be modified to achieve different effects and be adjusted for different environments.

[0085] In one embodiment, the class file includes multiple class files, each corresponding to the verification or exploitation of different vulnerabilities.

[0086] In another embodiment, the class file can be modified before each execution, and then the modified class file can be sent to the JNDI server so that the server to be tested can achieve the corresponding effect when executing the class file.

[0087] In the above implementation process, by storing verification or exploit code in the class file, the vulnerability of the server to be tested can be detected or exploited by executing the verification or exploit code, so as to further verify the vulnerability in the server to be tested, thereby improving the accuracy of vulnerability detection of the server to be tested.

[0088] In one possible implementation, before step 201, the process includes: sending a vulnerability detection request to a server to be detected via a scanner; executing the vulnerability detection request via the server to be detected and returning the vulnerability detection result to the scanner; if the server to be detected does not return a vulnerability detection result, the scanner constructs one or more payload requests based on the vulnerability detection request.

[0089] The vulnerability detection requests here are specially processed requests built by the scanner for regular vulnerability detection. In other words, they can be understood as regular vulnerability detection requests.

[0090] Understandably, when the server to be tested executes the vulnerability detection request, not all vulnerabilities can be determined to exist based on the server's response. In other words, some vulnerabilities will not return detection results to the scanner after being triggered.

[0091] If no detection results are returned to the scanner, the scanner constructs one or more payload requests and sends them to the server under test for further vulnerability detection. If detection results are returned to the scanner, since the vulnerability of the server under test is already known, there is no need to construct payload requests for further vulnerability detection, and the vulnerability detection ends.

[0092] In the above implementation process, when the server under test does not return vulnerability detection results, the scanner further constructs a payload request for the server under test to perform further vulnerability detection. Further processing is performed on cases where no vulnerability detection results are returned, thereby improving the accuracy of vulnerability detection.

[0093] In one possible implementation, the method further includes: the scanner checking the logs of the JNDI server to determine whether the server to be detected has vulnerabilities.

[0094] Since the server under test only sends a JNDI request to the JNDI server when an execution exception occurs during the execution of the payload request, the JNDI server's log records can be checked directly to determine whether there are vulnerabilities in the server under test.

[0095] This scanner can view the JNDI server's logs at preset intervals. It can also be triggered by conditions, such as JNDI server actions or target server actions, to view the JNDI server's logs. Furthermore, it can view the JNDI server's logs when the execution result of the code within a class file matches the predicted result. The conditions for viewing the JNDI server's logs can be adjusted according to actual needs; this application does not impose specific limitations.

[0096] Understandably, since the conditions for the scanner to view the JNDI server's log records can be adjusted according to the actual situation, the steps for the scanner to view the JNDI server's log records will also change accordingly. For example, if the condition for the scanner to view the JNDI server's log records is: triggered by a JNDI server action, then the step of the scanner viewing the JNDI server's log records can be set after step 202. If the condition for the scanner to view the JNDI server's log records is: the execution result of the code inside the class file is consistent with the prediction result, then the step of the scanner viewing the JNDI server's log records can be set after step 204.

[0097] In some embodiments, when the vulnerability detection accuracy of the server to be tested does not need to be so high, the scanner can directly determine whether the server to be tested has a vulnerability after viewing the log records of the JNDI server, and take the result obtained by the scanner by viewing the log records of the JNDI server as the detection result of the server to be tested, without executing the above steps 203 and 204.

[0098] In the above implementation process, the efficiency of vulnerability detection can be improved when the scanner checks the JNDI server's logging settings after a JNDI request is issued. The accuracy of vulnerability detection can be improved when the scanner checks the JNDI server's logging settings after code execution within a class file. The effectiveness of the vulnerability detection method can be adjusted by modifying the scanner's JNDI server logging settings, thus expanding the application scenarios for vulnerability detection.

[0099] In one possible implementation, the JNDI server is integrated on the scanner.

[0100] Typically, the scanner and the server under test are set up on the same device or in the same network environment, with each scanner scanning its corresponding server. Therefore, the scanner and the server under test are usually in the same network environment. Thus, when building a JNDI server, the JNDI server can be integrated with the scanner. Because the scanner and the server under test are in the same network environment, vulnerability detection can still be performed on the server under test even if it is in an intranet environment.

[0101] In the above implementation process, by integrating the JNDI server onto the scanner, the scanner, the server under test, and the JNDI server are always in the same network environment. Even if the server under test is in an intranet environment, vulnerability detection can still be performed, reducing the limitations of the network environment of the server under test on vulnerability detection and improving the adaptability of vulnerability detection to various scenarios.

[0102] In one possible implementation, the JNDI server comprises multiple different JNDI servers.

[0103] When setting up a JNDI server, you can set up multiple different JNDI servers. Each JNDI server stores payloads for various environments to ensure that the corresponding payload requests can be successfully executed through different JNDI servers in different environments.

[0104] The multiple JNDI servers here are independent of each other, and the specific implementation principles and vulnerability triggering conditions of these multiple different JNDI servers are different.

[0105] In the above implementation process, by setting up multiple different JNDI servers, each with its own environment, the payload request can be successfully executed in different environments. This increases the adaptability of the vulnerability detection method to different environments and reduces the limitations imposed by the environment on the use of this vulnerability detection method.

[0106] Based on the same application concept, this application also provides a vulnerability detection device corresponding to the vulnerability detection method. Since the principle of the device in this application is similar to that of the aforementioned vulnerability detection method, the implementation of the device in this application can refer to the description in the above-mentioned method embodiments, and the repeated parts will not be described again.

[0107] Please see Figure 5 This is a functional module diagram of the vulnerability detection device provided in this application embodiment. Each module in the vulnerability detection device in this embodiment is used to execute the steps in the above method embodiments. The vulnerability detection device includes a request sending module 301, a first execution module 302, a return module 303, and a second execution module 304; wherein,

[0108] The sending module 301 is used to send a payload request to the server to be detected via a scanner. The payload request includes vulnerability verification code.

[0109] The first execution module 302 is used to execute the payload request through the server to be detected, and to send a JNDI request to the JNDI server when the payload request execution fails.

[0110] The return module 303 is used to return the class file corresponding to the JNDI request to the server to be tested through the JNDI server according to the JNDI request.

[0111] The second execution module 304 is used to execute the code inside the class file corresponding to the JNDI request after the server under test obtains the class file corresponding to the JNDI request, so as to further verify whether there are vulnerabilities in the server under test based on the execution result of the code.

[0112] In one possible implementation, the return module 303 is further configured to: after obtaining the JNDI request, the JNDI server parses the JNDI request to determine the server address corresponding to the JNDI request, and sends the JNDI request to the target server corresponding to the server address; the target server determines the corresponding class file according to the JNDI request, and returns the class file to the JNDI server.

[0113] In one possible implementation, the vulnerability detection device further includes a request construction module, configured to: send a vulnerability detection request to the server to be detected via the scanner; execute the vulnerability detection request via the server to be detected and return a vulnerability detection result to the scanner; if the server to be detected does not return the vulnerability detection result, the scanner constructs one or more payload requests based on the vulnerability detection request.

[0114] In one possible implementation, the vulnerability detection device further includes a viewing module for: the scanner determining whether the server to be detected has vulnerabilities by viewing the log records of the JNDI server.

[0115] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the vulnerability detection method described in the above method embodiments.

[0116] The computer program product of the vulnerability detection method provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the vulnerability detection method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0117] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0118] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0119] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, 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 this application. 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. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0120] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vulnerability detection method, characterized in that, include: The scanner sends a payload request to the server to be detected, and the payload request includes vulnerability verification code. The vulnerability verification code in the payload request is a code segment used to send a JNDI request; the vulnerability verification code in the payload request is configured to trigger the server to be tested to send a JNDI request; The payload request is executed through the server to be tested, and a JNDI request is sent to the JNDI server when the payload request execution fails. The JNDI server returns the class file corresponding to the JNDI request to the server to be tested according to the JNDI request; the class file stores code for verifying or exploiting vulnerabilities; the code for verifying or exploiting vulnerabilities stored in the class file is configured to further verify or exploit the detected vulnerabilities. After obtaining the class file corresponding to the JNDI request, the server under test executes the code inside the class file corresponding to the JNDI request to further verify whether there are vulnerabilities in the server under test based on the execution result of the code. The method further includes, prior to the scanner sending a payload request to the server to be inspected for the server to execute the payload request: The scanner sends a vulnerability detection request to the server to be detected. The vulnerability detection request is executed through the server to be detected, and the vulnerability detection result is returned to the scanner. If the server to be detected does not return the vulnerability detection result, the scanner constructs one or more payload requests based on the vulnerability detection request.

2. The method of claim 1, wherein, The JNDI server returns the class file corresponding to the JNDI request to the server to be tested based on the JNDI request, including: After receiving the JNDI request, the JNDI server parses the JNDI request to determine the class file corresponding to the JNDI request, and sends a class file retrieval request to the target server. The target server returns the corresponding class file to the JNDI server based on the class file retrieval request.

3. The method of claim 1, wherein, The method further includes: The scanner determines whether the server under test has vulnerabilities by examining the log records of the JNDI server.

4. The method according to any one of claims 1-3, characterized in that, The JNDI server is integrated on the scanner.

5. The method according to any one of claims 1 to 3, characterized in that, The JNDI server includes multiple different JNDI servers.

6. A vulnerability detection apparatus characterized by comprising: include: The request sending module is used to send a payload request to the server to be detected via the scanner. The payload request includes vulnerability verification code. The vulnerability verification code in the payload request is a code segment used to send a JNDI request; the vulnerability verification code in the payload request is configured to trigger the server to be tested to send a JNDI request; The first execution module is used to execute the payload request through the server to be detected, and to send a JNDI request to the JNDI server when the payload request execution fails. The return module is used to return the class file corresponding to the JNDI request to the server to be detected through the JNDI server according to the JNDI request; the class file stores code for verifying or exploiting vulnerabilities; the code for verifying or exploiting vulnerabilities stored in the class file is configured to further verify or exploit the detected vulnerabilities; The second execution module is used to execute the code inside the class file corresponding to the JNDI request after the server under test obtains the class file corresponding to the JNDI request, so as to further verify whether there are vulnerabilities in the server under test based on the execution result of the code; The vulnerability detection device further includes a request building module, used to send a vulnerability detection request to the server to be detected through the scanner; The vulnerability detection request is executed by the server to be detected, and the vulnerability detection result is returned to the scanner; if the server to be detected does not return the vulnerability detection result, the scanner constructs one or more payload requests based on the vulnerability detection request.

7. An electronic device, comprising: include: The processor and memory, wherein the memory stores machine-readable instructions executable by the processor, wherein when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 5.

Images