Vulnerability detection method and device, electronic equipment and storage medium
By acquiring detection data packets and sessions, sending call commands to the tested component and judging the response data, the accuracy problem of electronic component vulnerability detection is solved, and the security of electronic components is improved.
Patent Information
- Application Number
- CN202411159299.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-22
- Publication Date
- 2026-03-03
AI Technical Summary
Existing technologies cannot effectively detect vulnerabilities in electronic components, which could allow unauthorized external devices to access information security-related functions, thus compromising the security of electronic components.
By acquiring detection data packets and sessions, calling instructions are sent to the component under test, and its response data is judged to detect unauthorized access vulnerabilities, ensuring that only legitimate devices can call specific functions.
It can efficiently and accurately detect vulnerabilities in electronic components, prevent unauthorized devices from accessing information security-related functions, and improve the security of electronic components.
Smart Images
Figure CN121598379A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to a vulnerability detection method, apparatus, electronic device, and storage medium. Background Technology
[0002] Currently, electronic components can expose various functions to external devices when communicating, enabling them to work together to achieve product functionality. Examples of electronic components include chips in automobiles or mobile phones, data reading modules in automobiles or mobile phones, and products in automobiles or mobile phones. For information security-related functions of electronic components, such as time calibration or log reading by external devices, legitimate external devices are typically required to access these functions to prevent unauthorized access and compromise of the electronic component's security. Therefore, it is necessary to provide a technical solution to detect vulnerabilities in electronic components, preventing unauthorized external devices from accessing their information security-related functions and thus improving overall electronic component security. Summary of the Invention
[0003] This disclosure provides a vulnerability detection method, apparatus, electronic device, and storage medium that can efficiently and accurately detect whether electronic components have vulnerabilities, prevent unauthorized external devices from accessing the information security-related functions of electronic components, and improve the security of electronic components.
[0004] In a first aspect, embodiments of this disclosure provide a vulnerability detection method, including:
[0005] Acquire the detection data packet for the component under test and the session with the component under test;
[0006] Based on the detection data packet, a call instruction is sent to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test;
[0007] Obtain the response data returned by the component under test according to the call instruction, and determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0008] Secondly, embodiments of this disclosure provide a vulnerability detection device, including:
[0009] The acquisition unit is used to acquire the detection data packet for the component under test and the session with the component under test;
[0010] The sending unit is configured to send a calling instruction to the component under test (BUT) within the session based on the detection data packet; the calling instruction is used to request the invocation of a specific function of the BUT; the specific function is related to the information security of the BUT;
[0011] The judgment unit is used to obtain the response data returned by the component under test according to the call instruction, and to determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0012] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the method described in the first aspect above.
[0013] Fourthly, embodiments of this disclosure provide a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the steps of the method described in the first aspect.
[0014] Fifthly, embodiments of this disclosure provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the steps of the method described in the first aspect above.
[0015] In one or more embodiments of this disclosure, firstly, a detection data packet for the component under test (BUT) is acquired, and a session with the BUT is acquired. Then, based on the detection data packet, a call instruction is sent to the BUT within the session. The call instruction requests the invocation of a specific function of the BUT, which is related to the information security of the BUT. Finally, response data returned by the BUT according to the call instruction is acquired. Based on the response data, it is determined whether the BUT has an unauthorized access vulnerability in the aforementioned session. An unauthorized access vulnerability refers to a situation where the BUT allows the call instruction to invoke a specific function when the device sending the call instruction is an unauthorized device. Therefore, through this embodiment, by sending a call instruction to the BUT to request the invocation of a specific function and acquiring the response data of the BUT, it is possible to efficiently and accurately detect whether the BUT has vulnerabilities, prevent unauthorized external devices from invoking the information security-related functions of the BUT, and improve the security of the BUT. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in one or more embodiments of this disclosure 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 only some embodiments recorded in this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A flowchart illustrating a vulnerability detection method provided in an embodiment of this disclosure;
[0018] Figure 2 A flowchart illustrating a vulnerability detection method provided in yet another embodiment of this disclosure;
[0019] Figure 3 This is a schematic diagram of the structure of a vulnerability detection device provided in an embodiment of the present disclosure;
[0020] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation
[0021] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this disclosure, the technical solutions in one or more embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of the embodiments. Based on one or more embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this disclosure.
[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0023] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.
[0024] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.
[0026] This disclosure provides a vulnerability detection method that can efficiently and accurately detect whether electronic components have vulnerabilities, prevent unauthorized external devices from calling the information security-related functions of electronic components, and improve the security of electronic components.
[0027] Figure 1 This is a flowchart illustrating a vulnerability detection method provided in an embodiment of the present disclosure, as shown below. Figure 1 As shown, the method includes:
[0028] Step S102: Obtain the detection data packet for the component under test and the session with the component under test;
[0029] Step S104: Based on the detection data packet, send a call instruction to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test.
[0030] Step S106: Obtain the response data returned by the component under test according to the call command. Based on the response data, determine whether the component under test has an unauthorized access vulnerability in the above session. An unauthorized access vulnerability refers to a situation where the device sending the call command is an illegal device, allowing the component under test to call the command to invoke specific functions.
[0031] In this embodiment, firstly, a detection data packet for the component under test (BUT) is acquired, and then a session with the BUT is acquired. Next, based on the detection data packet, a call instruction is sent to the BUT within the session. This call instruction requests a specific function of the BUT, which is related to the BUT's information security. Finally, the response data returned by the BUT according to the call instruction is acquired. Based on the response data, it is determined whether the BUT has an unauthorized access vulnerability within the aforementioned session. An unauthorized access vulnerability refers to a situation where the BUT allows the call instruction to invoke a specific function when the device sending the call instruction is an unauthorized device. Therefore, this embodiment efficiently and accurately detects vulnerabilities in the BUT by sending a call instruction to request the invocation of a specific function and acquiring the BUT's response data. This prevents unauthorized external devices from accessing the BUT's information security-related functions, thereby improving the security of the BUT.
[0032] The vulnerability detection method in this embodiment can be applied to and executed by a vulnerability detection device, which can be a terminal device such as a mobile phone or computer. The vulnerability detection device runs a vulnerability detection program that can execute the aforementioned vulnerability detection method.
[0033] In one embodiment, the component under test includes the vehicle's ECU (Electronic Control Unit), and the vulnerability detection program includes the Routine Control service defined by the UDS (Unified Diagnostic Services) protocol (ISO 14229).
[0034] In step S102 above, the vulnerability detection device acquires a detection data packet for the component under test. In one example, a pre-written detection data packet can be imported into the vulnerability detection device, thereby enabling the device to acquire the detection data packet for the component under test. The detection data packet includes at least data for invoking a specific function of the component under test, where the specific function is a function of the component under test related to its information security.
[0035] In step S102 above, the vulnerability detection device has pre-created a session with the component under test; therefore, this pre-created session is obtained. For example, the vulnerability detection device sends code to the component under test to create a session, thereby creating a session with the component under test, and then obtains the created session. The session between the vulnerability detection device and the component under test includes one or more of the following: default session, extended session, and programming session.
[0036] The difference between the default session, extended session, and programming session lies in the following: When a vulnerability detection device communicates with the component under test (BUT) through the default session, it cannot browse specific data of the BUT. When communicating through the extended session, it can browse and read specific data. When communicating through the programming session, it can rewrite specific data. Examples of such specific data include the BUT's identifier, sensor data, operational logs, and other information security-related data.
[0037] In one embodiment, the number of detection packets is multiple; the number of the aforementioned sessions is multiple; acquiring the detection packets for the device under test and the sessions with the device under test includes:
[0038] Each detection data packet is acquired sequentially. When the first detection data packet is acquired, the first session type corresponding to this session is determined according to the order of the session types. The session between the device under test and the device is created according to the determined first session type.
[0039] If all detection data packets have been acquired, then each detection data packet is acquired again in sequence until the number of rounds in which each detection data packet is acquired is equal to the number of sessions mentioned above. In each session with the component under test, each detection data packet is used to detect whether the component under test has an unauthorized access vulnerability in the corresponding session.
[0040] In this embodiment, there are multiple detection data packets and multiple sessions. Based on this, when the vulnerability detection device acquires detection data packets and sessions for the component under test, it acquires each detection data packet sequentially according to the arrangement order of each detection data packet. Each time the first detection data packet in each detection data packet is acquired, the first session type corresponding to this session is determined according to the arrangement order of each preset session type, and a session between the device under test and the current device is created according to the determined first session type.
[0041] If all detection data packets have been acquired, they are acquired again sequentially until the number of rounds in which all detection data packets have been acquired equals the number of sessions mentioned above. In each session with the component under test, each detection data packet is used to detect whether the component under test has any privilege escalation vulnerabilities in the corresponding session.
[0042] For example, if the preset session types include default session, extended session, and programming session, the vulnerability detection device acquires each detection data packet sequentially according to the order of their arrangement. When acquiring the first detection data packet, it determines the order of the three session types: default session, extended session, and programming session. Based on this order, the session type for this session is determined to be the default session. The vulnerability detection device then creates a default session with the component under test. In this default session, the vulnerability detection device acquires each detection data packet sequentially and... Figure 1 In steps S104 and S106, the response data corresponding to each detection data packet is obtained. Finally, based on the response data corresponding to all detection data packets, it is determined whether the tested component has an unauthorized access vulnerability under the default session.
[0043] Next, after the vulnerability detection device acquires all the detection data packets for the first time, it re-acquires each detection data packet sequentially. Similar to before, the vulnerability detection device acquires each detection data packet in the order they are arranged. When acquiring the first detection data packet, it determines the order among the three session types: default session, extended session, and programming session. Based on the order, it determines that the session type for this session is an extended session. The vulnerability detection device then creates an extended session with the component under test. In this extended session, the vulnerability detection device acquires each detection data packet sequentially and... Figure 1 In steps S104 and S106, the response data corresponding to each detection data packet is obtained. Finally, based on the response data corresponding to all detection data packets, it is determined whether the tested component has an unauthorized access vulnerability under the extended session.
[0044] Next, after the vulnerability detection device acquires all the detection data packets for the second time, it re-acquires each detection data packet sequentially. Similar to before, the vulnerability detection device acquires each detection data packet in the order they are arranged. When acquiring the first detection data packet, it determines the order of the three session types: default session, extended session, and programming session. Based on the order, it determines that the session type for this session is a programming session. The vulnerability detection device then creates a programming session with the component under test. In this programming session, the vulnerability detection device acquires each detection data packet sequentially and... Figure 1 In steps S104 and S106, the response data corresponding to each detection data packet is obtained. Finally, based on the response data corresponding to all detection data packets, it is determined whether the tested component has an unauthorized access vulnerability in the programming session.
[0045] In this example, after all the detection data packets have been acquired once, the vulnerability detection device can acquire each detection data packet in the order they were arranged. After all the detection data packets have been acquired once again, the vulnerability detection device can acquire each detection data packet in the order they were arranged, thus repeatedly acquiring each detection data packet multiple times. This number of times is equal to the number of sessions mentioned above. Of course, if a session is created according to each preset session type, this number of times can also be equal to the number of preset session types.
[0046] As can be seen, this embodiment enables the determination of the first session type corresponding to the current session based on the order of the various session types when there are multiple sessions and multiple detection data packets. According to the determined first session type, a session is created between the current device and the device under test. In each session with the device under test, each detection data packet is acquired sequentially, so that all detection data packets can participate in each session. In each session, the device under test is checked to see if there is an unauthorized access vulnerability in the corresponding session, thereby improving the accuracy of vulnerability detection.
[0047] In one embodiment, acquiring the test data packet for the component under test and the session with the component under test includes:
[0048] Acquire the test data packet for the component under test, and determine the second session type corresponding to the test data packet;
[0049] Based on the second session type, create a session with the component under test.
[0050] In this embodiment, the vulnerability detection device acquires detection data packets and determines the second session type corresponding to the detection data packets. Based on the second session type, it creates a session with the component under test, and thus the vulnerability detection device acquires the created session. The session type of this session is the second session type. For example, if the second session type includes a default session, the vulnerability detection device creates a default session with the component under test and acquires the default session. Or, if the second session type includes an extended session, the vulnerability detection device creates an extended session with the component under test and acquires the extended session.
[0051] In one example, the number of detection packets is multiple. In this example, after the vulnerability detection device obtains a detection packet each time, it determines the second session type corresponding to the detection packet, creates a session with the component under test based on the second session type, obtains the session, and executes it once. Figure 1 Steps S104 and S106 are performed to obtain the response data corresponding to each detection data packet. Finally, based on the response data corresponding to all detection data packets, it is determined whether the component under test has an unauthorized access vulnerability under the obtained session. In this example, if the second session type corresponding to two adjacent detection data packets is the same, the vulnerability detection device can use the previous session without recreating it. If the second session type corresponding to two adjacent detection data packets is different, the vulnerability detection device creates a new session with the component under test based on the second session type obtained in the later one.
[0052] As can be seen, this embodiment can create a session between the vulnerability detection device and the component under test by determining the session type corresponding to the detection data packet, thus meeting the implementation requirements of the solution in different scenarios.
[0053] In one embodiment, when there are multiple detection data packets, a second session type corresponding to each detection data packet is determined, and a session is created between the detection data packet and the component under test based on the second session type. In this embodiment, determining the second session type corresponding to each detection data packet includes:
[0054] Read the session type identifier in the detection data packet, and determine the second session type corresponding to the detection data packet based on the session type identifier;
[0055] or,
[0056] Obtain the correspondence between the detection packet identifier and the session type, and determine the second session type corresponding to the detection packet based on the correspondence.
[0057] In one scenario, each detection packet carries a session type identifier, which indicates the session type corresponding to the detection packet. Based on this session type identifier, the session type corresponding to the detection packet is determined to be the second session type.
[0058] In another scenario, a pre-established mapping between the identifier of a detection packet and its session type is used. Upon obtaining the identifier of a detection packet, this mapping determines the corresponding session type as the second session type. For example, each detection packet is configured with a sequence number, and a pre-established mapping represents the correspondence between the sequence number of the detection packet and its corresponding session type. Therefore, upon obtaining each detection packet, the sequence number determines the corresponding session type as the second session type.
[0059] As can be seen, this embodiment can determine the second session type corresponding to the detection data packet in multiple ways, improving the flexibility and convenience of determining the second session type.
[0060] As mentioned above, in one embodiment, the number of detection packets is multiple. After the vulnerability detection device acquires a detection packet each time, it determines the second session type corresponding to the detection packet, creates a session with the component under test based on the second session type, acquires the session, and executes it once. Figure 1Steps S104 and S106 are performed to obtain the response data corresponding to each detection data packet. Finally, based on the response data corresponding to all detection data packets, it is determined whether the component under test has an unauthorized access vulnerability under the obtained session. In this example, if the second session type corresponding to two adjacent detection data packets is the same, the vulnerability detection device can use the previous session without recreating it. If the second session type corresponding to two adjacent detection data packets is different, the vulnerability detection device creates a new session with the component under test based on the second session type obtained in the later one.
[0061] As mentioned above, in this embodiment, the number of detection packets can be multiple, and the number of sessions obtained above can be multiple. In this case, for each session, steps S104 and S106 can be executed to obtain the response data corresponding to each detection packet. Finally, based on the response data corresponding to all detection packets, it is determined whether the tested component has an unauthorized access vulnerability in this session.
[0062] For each detection data packet and each session, in step S104 above, based on the detection data packet, a call instruction is sent to the component under test within the session, including:
[0063] Read the data in the test data packet that calls a specific function, generate a call instruction belonging to the session based on the read data, and send the call instruction to the component under test;
[0064] or,
[0065] The test data packet is used as a call instruction belonging to the session, and the call instruction is sent to the component under test.
[0066] In this embodiment, under each session, for each detection data packet, a calling instruction can be generated and sent in the following manner.
[0067] In this embodiment, in one scenario, the detection data packet carries other data besides data for invoking a specific function of the component under test (DUT), such as a session type identifier. Based on this, the data for invoking the specific function of the DUT in the detection data packet is read, and a call instruction belonging to the session is generated according to the read data. The call instruction is then sent to the DUT. For example, the read data can be sent to the DUT as a call instruction.
[0068] In another scenario, a session is created between the device under test and the device based on the first session type. Therefore, the detection data packet does not need to carry useless data, and the detection data packet can be directly used as a call instruction belonging to the session to send the call instruction to the device under test.
[0069] As can be seen, this embodiment can distinguish different situations, generate call instructions based on the detection data packet, and send them to the component under test, thereby improving the efficiency of sending call instructions.
[0070] As mentioned earlier, since the detection data packet includes at least data for invoking a specific function of the component under test (DUT), and this specific function is a function of the DUT related to the DUT's information security, the invocation instruction generated based on the detection data packet is used to request the invocation of the aforementioned specific function of the DUT.
[0071] If the component under test (BUT) does not have an unauthorized access vulnerability, meaning it only allows legitimate devices to call specific functions, the workflow is as follows: the BUT first authenticates the device establishing the session, such as the vulnerability detection device in this example. After successful authentication, the BUT allows the device to call specific functions by sending commands. For example, the BUT allows the device to read the runtime logs by sending commands, provided authentication is successful. If the BUT has an unauthorized access vulnerability, meaning it also allows unauthorized devices to call specific functions, the workflow is as follows: the BUT does not need to authenticate the device establishing the session, such as the vulnerability detection device in this example. It directly allows the device to call specific functions by sending commands. For example, the BUT allows the device to read the runtime logs by sending commands without authentication.
[0072] See Figure 1 As can be seen from the process, in this embodiment, the vulnerability detection device does not send an authentication request to the component under test, nor does it request the component under test to authenticate the vulnerability detection device. Therefore, the vulnerability detection device is an illegal device. In this embodiment, if the component under test does not have an unauthorized access vulnerability, the component under test should return an error message and refuse to call the specific function after receiving the call instruction. If the component under test has an unauthorized access vulnerability, the component under test should not return an error message after receiving the call instruction and allow the call to the specific function.
[0073] Based on this, in one embodiment, determining whether the tested component has an unauthorized access vulnerability under a session, based on the response data, includes:
[0074] Determine whether the response data corresponding to the detection data packet contains an error message indicating that the calling command does not have the necessary permissions;
[0075] Based on the judgment results, determine whether the tested component has an unauthorized access vulnerability under the session.
[0076] In this embodiment, to comprehensively examine the existence of privilege escalation vulnerabilities in the tested component under different detection data packets and different sessions, the number of detection data packets and sessions can be set to multiple. All detection data packets are configured to detect whether the tested component has privilege escalation vulnerabilities in each session. Based on this, for each session, it is determined whether the response data corresponding to each detection data packet carries an error message indicating that the calling instruction does not have the necessary permissions. If the response data corresponding to each detection data packet carries an error message, it is determined that the tested component does not have privilege escalation vulnerabilities in that session. If the response data corresponding to any detection data packet does not carry an error message, it is determined that the tested component has privilege escalation vulnerabilities in that session.
[0077] As can be seen, this embodiment can accurately determine whether the tested component has an unauthorized access vulnerability in each session by judging whether the response data corresponding to the detection data packet carries an error message indicating that the calling instruction does not have the necessary permissions, thus improving the accuracy of the determination, even when there are multiple sessions and multiple detection data packets.
[0078] Figure 2 This is a flowchart illustrating a vulnerability detection method provided in another embodiment of this disclosure. In this embodiment, the session includes three types: default session, extended session, and programming session, and the number of detection data packets is multiple, such as... Figure 2 As shown, this embodiment is executed by a vulnerability detection device and includes:
[0079] Step S202: Sequentially acquire each detection data packet. When the first detection data packet is acquired, create a default session with the component under test.
[0080] Step S204: In the default session, a call command is sent to the component under test based on each detection data packet;
[0081] Step S206: Under the default session, obtain the response data returned by the component under test according to the call command. If each response data carries an error message, it is determined that the component under test does not have an unauthorized access vulnerability under the default session. If any response data does not carry an error message, it is determined that the component under test has an unauthorized access vulnerability under the default session.
[0082] Step S208: If all detection data packets have been acquired, then acquire each detection data packet in sequence again. When the first detection data packet in each detection data packet is acquired, create an extended session with the component under test.
[0083] Step S210: In the extended session, a call instruction is sent to the component under test based on each detection data packet;
[0084] Step S212: Under the extended session, obtain each response data returned by the component under test according to the call command. If each response data carries an error message, it is determined that the component under test does not have an unauthorized access vulnerability under the extended session. If any response data does not carry an error message, it is determined that the component under test has an unauthorized access vulnerability under the extended session.
[0085] Step S214: If all detection data packets have been acquired, then acquire each detection data packet in sequence again. When the first detection data packet in each detection data packet is acquired, a programming session is created with the component under test.
[0086] Step S216: In the programming session, a call instruction is sent to the component under test based on each detection data packet;
[0087] Step S218: In the programming session, obtain the response data returned by the component under test according to the call command. If each response data carries an error message, it is determined that the component under test does not have an unauthorized access vulnerability in the programming session. If any response data does not carry an error message, it is determined that the component under test has an unauthorized access vulnerability in the programming session.
[0088] In this embodiment, the error message can be a code starting with a specific character, and the response data, call command, and detection data packet correspond one-to-one. If a response data does not carry an error message, the response data, the corresponding detection data packet, the corresponding call command, and the session type of the response data can be saved and output to the staff for analysis of the reason for not reporting an error, so as to solve the privilege escalation vulnerability of the tested component.
[0089] In summary, the vulnerability detection method in this embodiment can be applied to the vehicle's ECU to detect whether the ECU has any unauthorized access vulnerabilities, prevent unauthorized external devices from calling functions related to vehicle security, improve vehicle security, and reduce the risk of vehicle attacks.
[0090] Figure 3 This is a schematic diagram of the structure of a vulnerability detection device provided in an embodiment of the present disclosure, as shown below. Figure 3 As shown, the device includes:
[0091] The acquisition unit 31 is used to acquire the detection data packet for the component under test and the session with the component under test;
[0092] Sending unit 32 is configured to send a calling instruction to the component under test in the session based on the detection data packet; the calling instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test;
[0093] The judgment unit 33 is used to obtain the response data returned by the component under test according to the call instruction, and to determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0094] Optionally, the number of detected data packets is multiple; the number of sessions is multiple; the acquisition unit is specifically used for:
[0095] Each of the detection data packets is acquired sequentially. When the first detection data packet is acquired each time, the first session type corresponding to the current session is determined according to the order of the session types. The current session with the tested component is created according to the determined first session type.
[0096] If all the detection data packets have been acquired, then each detection data packet is acquired again in sequence until the number of rounds in which each detection data packet is acquired equals the number of sessions; wherein, in each session with the component under test, each detection data packet is used to detect whether the component under test has an unauthorized access vulnerability in the corresponding session.
[0097] Optionally, the acquisition unit is specifically used for:
[0098] Acquire the detection data packet for the component under test, and determine the second session type corresponding to the detection data packet;
[0099] Based on the second session type, a session is created between the device under test and the device.
[0100] Optionally, the acquisition unit is further specifically used for:
[0101] Read the session type identifier in the detection data packet, and determine the second session type corresponding to the detection data packet based on the session type identifier;
[0102] or,
[0103] Obtain the correspondence between the detection packet identifier and the session type, and determine the second session type corresponding to the detection packet based on the correspondence.
[0104] Optionally, the sending unit is specifically used for:
[0105] Read the data in the detection data packet that calls the specific function, generate a call instruction belonging to the session based on the read data, and send the call instruction to the component under test;
[0106] or,
[0107] The detection data packet is used as a call instruction belonging to the session, and the call instruction is sent to the component under test.
[0108] Optionally, the determination unit is specifically used for:
[0109] Determine whether the response data corresponding to the detection data packet carries an error message indicating that the calling instruction does not have the necessary permissions;
[0110] Based on the judgment result, it is determined whether the tested component has an unauthorized access vulnerability in the session.
[0111] The vulnerability detection device in this embodiment can implement the various processes of the vulnerability detection method embodiment described above and achieve the same effect and function, which will not be repeated here.
[0112] One embodiment of this disclosure also provides an electronic device. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, as shown below. Figure 4 As shown, electronic devices can vary considerably due to differences in configuration or performance. They may include one or more processors 401 and memories 402, with the memory 402 storing one or more application programs or data. The memory 402 can be temporary or persistent storage. The application programs stored in the memory 402 may include one or more modules (not shown), each module including a series of computer-executable instructions within the electronic device. Furthermore, the processor 401 may be configured to communicate with the memory 402, executing the series of computer-executable instructions stored in the memory 402 on the electronic device. The electronic device may also include one or more power supplies 403, one or more wired or wireless network interfaces 404, one or more input or output interfaces 405, one or more keyboards 406, etc.
[0113] In one specific embodiment, the electronic device includes a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the following process:
[0114] Acquire the detection data packet for the component under test and the session with the component under test;
[0115] Based on the detection data packet, a call instruction is sent to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test;
[0116] Obtain the response data returned by the component under test according to the call instruction, and determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0117] The electronic device in this embodiment can implement the various processes of the above-described vulnerability detection method embodiment and achieve the same effect and function, which will not be repeated here.
[0118] Another embodiment of this disclosure also provides a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process:
[0119] Acquire the detection data packet for the component under test and the session with the component under test;
[0120] Based on the detection data packet, a call instruction is sent to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test;
[0121] Obtain the response data returned by the component under test according to the call instruction, and determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0122] The storage medium in this embodiment can implement the various processes of the above-described vulnerability detection method embodiments and achieve the same effects and functions, which will not be repeated here.
[0123] Another embodiment of this disclosure also provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the following process:
[0124] Acquire the detection data packet for the component under test and the session with the component under test;
[0125] Based on the detection data packet, a call instruction is sent to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test;
[0126] Obtain the response data returned by the component under test according to the call instruction, and determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
[0127] The computer program product in this disclosure embodiment can implement the various processes of the above-described vulnerability detection method embodiment and achieve the same effect and function, which will not be repeated here.
[0128] In various embodiments of this disclosure, the computer-readable storage medium includes read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc.
[0129] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.
[0130] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.
[0131] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.
[0132] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing the embodiments of this disclosure, the functions of each unit can be implemented in one or more software and / or hardware.
[0133] Those skilled in the art will understand that one or more embodiments of this disclosure can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0134] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0135] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0136] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0137] It should also be noted that 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 one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0138] One or more embodiments of this disclosure can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.
[0139] The various embodiments in this disclosure are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0140] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.
Claims
1. A vulnerability detection method, characterized in that, include: Acquire the detection data packet for the component under test and the session with the component under test; Based on the detection data packet, a call instruction is sent to the component under test in the session; the call instruction is used to request the invocation of a specific function of the component under test; the specific function is related to the information security of the component under test; Obtain the response data returned by the component under test according to the call instruction, and determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
2. The method according to claim 1, characterized in that, The number of detection data packets is multiple; the number of sessions is multiple; the acquisition of detection data packets for the device under test and the sessions with the device under test includes: Each of the detection data packets is acquired sequentially. When the first detection data packet is acquired each time, the first session type corresponding to the current session is determined according to the order of the session types. The current session with the tested component is created according to the determined first session type. If all the detection data packets have been acquired, then each detection data packet is acquired again in sequence until the number of rounds in which each detection data packet is acquired equals the number of sessions; wherein, in each session with the component under test, each detection data packet is used to detect whether the component under test has an unauthorized access vulnerability in the corresponding session.
3. The method according to claim 1, characterized in that, The acquisition of the detection data packet for the component under test and the session with the component under test includes: Acquire the detection data packet for the component under test, and determine the second session type corresponding to the detection data packet; Based on the second session type, a session is created between the device under test and the device.
4. The method according to claim 3, characterized in that, Determining the second session type corresponding to the detection data packet includes: Read the session type identifier in the detection data packet, and determine the second session type corresponding to the detection data packet based on the session type identifier; or, Obtain the correspondence between the detection packet identifier and the session type, and determine the second session type corresponding to the detection packet based on the correspondence.
5. The method according to claim 1, characterized in that, The step of sending a call instruction to the component under test in the session based on the detection data packet includes: Read the data in the detection data packet that calls the specific function, generate a call instruction belonging to the session based on the read data, and send the call instruction to the component under test; or, The detection data packet is used as a call instruction belonging to the session, and the call instruction is sent to the component under test.
6. The method according to claim 1, characterized in that, The step of determining whether the tested component has an unauthorized access vulnerability in the session based on the response data includes: Determine whether the response data corresponding to the detection data packet carries an error message indicating that the calling instruction does not have the necessary permissions; Based on the judgment result, it is determined whether the tested component has an unauthorized access vulnerability in the session.
7. A vulnerability detection device, characterized in that, include: The acquisition unit is used to acquire the detection data packet for the component under test and the session with the component under test; The sending unit is configured to send a calling instruction to the component under test (BUT) within the session based on the detection data packet; the calling instruction is used to request the invocation of a specific function of the BUT; the specific function is related to the information security of the BUT; The judgment unit is used to obtain the response data returned by the component under test according to the call instruction, and to determine whether the component under test has an unauthorized access vulnerability in the session based on the response data; the unauthorized access vulnerability refers to the component under test allowing the call instruction to call the specific function when the device sending the call instruction is an illegal device.
8. An electronic device, characterized in that, include: processor; as well as, A memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the method described in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store computer-executable instructions that, when executed by a processor, implement the steps of the method described in any one of claims 1-6.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-6.