A proxy client-based vulnerability detection method and related device

Abstract

The application provides a vulnerability detection method based on a proxy client and related equipment, which can be applied to various scenes such as cloud technology, artificial intelligence, intelligent transportation and auxiliary driving. The method comprises the following steps: scanning a target container to obtain feature information of the target container, wherein the feature information comprises one or more of a kernel version, a container version and a container configuration; determining a vulnerability detection result of the target container according to the feature information of the target container; and sending the vulnerability detection result of the target container, wherein the vulnerability detection result is used for sending vulnerability alarm information. According to the embodiment of the application, the target container can be scanned from multiple dimensions, so that the container vulnerability can be accurately and timely discovered before the vulnerability escape attack occurs, and an alarm can be given, thereby avoiding the loss caused by the occurrence of the container vulnerability escape attack.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a vulnerability detection method and related equipment based on a proxy client. Background Technology

[0002] With the development of computer technology, container technology has been widely used in various fields because it can effectively divide the resources of a single operating system into isolated groups, thereby better balancing conflicting resource usage demands among these groups. However, the use of container technology poses a security risk of container escape. Container escape can severely threaten the confidentiality, availability, and stability of devices using container technology.

[0003] Currently, the common method for detecting container escape attacks is to monitor the host machine and then block the attack once a container vulnerability escape attack is detected. However, this method of blocking attacks after they have already occurred is still prone to causing losses. Summary of the Invention

[0004] This application provides a vulnerability detection method and related equipment based on a proxy client, which can accurately and promptly detect container vulnerabilities and issue alerts, thereby avoiding losses caused by container vulnerability escape attacks.

[0005] On one hand, embodiments of this application provide a vulnerability detection method based on a proxy client, the method comprising:

[0006] The target container is scanned to obtain its characteristic information, which includes one or more of the following: kernel version, container version, and container configuration.

[0007] The vulnerability detection result of the target container is determined based on the characteristic information of the target container;

[0008] The vulnerability detection results of the target container are sent, and the vulnerability detection results are used to send vulnerability alert information.

[0009] On the other hand, embodiments of this application provide a vulnerability detection device based on a proxy client, the device comprising:

[0010] The acquisition module is used to scan the target container and obtain the feature information of the target container, the feature information including one or more of kernel version, container version and container configuration;

[0011] The determination module is used to determine the vulnerability detection result of the target container based on the feature information of the target container;

[0012] The communication module is used to send the vulnerability detection results of the target container, and the vulnerability detection results are used to send vulnerability alert information.

[0013] In another aspect, embodiments of this application provide a computer device, which includes: a processor, a memory, and a network interface; the processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the vulnerability detection method based on the proxy client in embodiments of this application.

[0014] Accordingly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, perform the vulnerability detection method based on a proxy client as described in this application embodiment.

[0015] Accordingly, this application also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the steps of the vulnerability detection method based on a proxy client provided in this application.

[0016] Accordingly, this application also provides a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to execute the vulnerability detection method based on a proxy client provided in this application.

[0017] This application's embodiments scan the target container to obtain its characteristic information, including one or more of the kernel version, container version, and container configuration. Then, based on this characteristic information, the vulnerability detection result of the target container is determined, and finally, the vulnerability detection result is sent. This ensures that if a vulnerability exists in the target container, a vulnerability alert is sent. This application scans the target container from multiple dimensions, enabling accurate and timely detection and alerting of container vulnerabilities before vulnerability escape attacks occur, thereby avoiding losses caused by container vulnerability escape attacks. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application 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 of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the architecture of the vulnerability detection system provided in the embodiments of this application;

[0020] Figure 2 This is a flowchart illustrating the vulnerability detection method based on a proxy client provided in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the internal structure of the vulnerability detection system provided in the embodiments of this application;

[0022] Figure 4 This is a schematic diagram of the workflow of the vulnerability detection system provided in the embodiments of this application;

[0023] Figure 5 This is a schematic diagram of the workflow of the scanning module in the proxy client provided in this application embodiment;

[0024] Figure 6 This is a schematic diagram of the kernel scanning module provided in an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of the workflow of the version scanning module provided in the embodiments of this application;

[0026] Figure 8 This is a schematic diagram of the workflow of the access interface configuration scanning module provided in the embodiments of this application;

[0027] Figure 9 This is a schematic diagram of the workflow of the nested function configuration scanning module provided in the embodiments of this application;

[0028] Figure 10 This is a schematic diagram of the workflow of the privileged function configuration scanning module provided in the embodiments of this application;

[0029] Figure 11 This is a schematic diagram of the structure of the vulnerability detection device based on a proxy client provided in an embodiment of this application;

[0030] Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0032] To better understand the embodiments of this application, some technical terms involved in the embodiments of this application will be introduced below:

[0033] Vulnerability: A flaw in the security of a computer system that threatens the confidentiality, integrity, availability, and access control of the system or its application data.

[0034] Docker: An open-source application container engine that allows developers to package their applications and dependencies into a portable container and then deploy it to any popular Linux or Windows machine. It can also achieve virtualization. Containers are completely sandboxed and have no interface with each other.

[0035] Agent (Personal Software Agent): A computing entity that can continuously and autonomously function in a distributed or collaborative system, often simply referred to as an "intelligent agent." In a broad sense, an agent refers to any entity possessing intelligence, which can be computer hardware or intelligent software. In this scenario, an agent can be understood as a small scanner that periodically scans for problems and reports them to its superiors (e.g., control or management devices) if a problem is detected.

[0036] This application provides a vulnerability detection method based on a proxy client to automatically and promptly discover vulnerabilities. The vulnerability detection method based on a proxy client provided in this application relates to cloud technology. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." Resources in the "cloud" appear infinitely scalable to users and can be accessed, used on demand, and expanded at any time. As a provider of basic cloud computing capabilities, a cloud computing resource pool (referred to as a cloud platform, generally called Infrastructure as a Service (IaaS) platform) is established, deploying various types of virtual resources within the resource pool for external customers to choose from. The cloud computing resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0037] The vulnerability detection method based on a proxy client provided in this application relates to blockchain technology. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0038] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation and monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, network status monitoring, and node device health status monitoring.

[0039] like Figure 1 As shown, Figure 1This is a schematic diagram of the architecture of a vulnerability detection system provided in this application embodiment. The vulnerability detection system mainly includes a control device 102 and a device under test 101. The device under test includes at least one container, and a proxy client is deployed in the device under test 101. The proxy client is used to perform vulnerability detection on the target container in the device under test 101. The control device 102 may include a proxy client distribution module, which is used to distribute proxy clients to the device under test. The control device 102 may also include a message receiving module, which can receive messages sent by the device under test and messages sent by the proxy client. The control device 102 may also include an alarm module, which is used to send alarm information to the management device when a container vulnerability is detected in the device under test 101.

[0040] In one possible embodiment, a proxy client deployed in a target container within the device under test 101 can scan the container in the device under test 101 to obtain the container's characteristic information; the proxy client can also determine the vulnerability detection result of the target container based on the target container's characteristic information; the proxy client can also send the vulnerability detection result of the target container to the control device 102. It should be noted that the proxy client can scan and detect all containers in the device under test 101.

[0041] In one possible embodiment, deploying a proxy client in the device under test 101 can be as follows: the device under test 101 sends a vulnerability detection request to the control device 102. After receiving the vulnerability detection request, the control device 102 selects any one of multiple proxy clients and assigns it to the device under test 101. After the target proxy client performs vulnerability detection on the device under test 101, it feeds back the result to the control device 102, which then feeds back the result to the management device.

[0042] Optionally, deploying the proxy client in the device to be detected 101 can also be done by the control device 102 determining one or more devices to be detected 101 corresponding to the configured vulnerability detection task, and automatically distributing the proxy client to each device to be detected 101.

[0043] Optionally, the device to be tested 101 is the client device of the vulnerability detection platform, which is also the device that needs to be detected for vulnerabilities. It is a device with communication capabilities, including but not limited to: a server cluster or distributed system composed of multiple physical servers, cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, as well as devices such as laptops, smart home appliances, and vehicle terminals. The control device 102 includes a vulnerability detection chip, a server cluster or distributed system composed of multiple physical servers, and can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0044] Optionally, the aforementioned devices to be tested and management devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, and vehicle terminals. The embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0045] It should be noted that, Figure 1 In the scenario shown, the number of vulnerability detection devices 102 based on proxy clients and devices 101 to be detected can be one or more, and this application does not impose any restrictions.

[0046] The following will combine Figures 2 to 10 The vulnerability detection method based on a proxy client provided in this application embodiment will be described in detail.

[0047] Please see Figure 2 , Figure 2 This is a flowchart illustrating a vulnerability detection method based on a proxy client provided in an embodiment of this application. The image processing method includes steps S201 to S203.

[0048] S201. Scan the target container to obtain its characteristic information, which includes one or more of the following: kernel version, container version, and container configuration.

[0049] The aforementioned container encapsulates the application and its dependencies, sharing resources with the host operating system. Because the container achieves isolation through operating system-level virtualization, it requires no additional operating system overhead during runtime. This improves efficiency and reduces performance overhead. One or more containers can be allowed simultaneously within a device under test, with the target container being any container within the device under test.

[0050] Optionally, the feature information may include only one of the kernel version, container version, and container configuration (e.g., the feature information includes only the kernel version, or only the container version, or only the container configuration). The feature information may also include any two of the kernel version, container version, and container configuration (e.g., the feature information includes both the kernel version and container version, or both the kernel version and container configuration, or both the container version and container configuration). The feature information may also include all three (e.g., the feature information includes the kernel version, container version, and container configuration).

[0051] S202. Determine the vulnerability detection results of the target container based on the characteristic information of the target container.

[0052] Optionally, the vulnerability detection results corresponding to the target container can be determined based on the characteristic information of the target container (for example, the kernel vulnerability detection results of the target container can be determined based on the kernel version of the target container, or the kernel vulnerability detection results and version vulnerability detection results of the target container can be determined based on the kernel version and container version of the target container).

[0053] In one possible embodiment, the vulnerability detection result of the container to be detected is determined based on the characteristic information of the target container. Specifically, the following steps are taken: First, vulnerability judgment conditions are obtained, which include one or more of kernel vulnerability judgment conditions, version vulnerability judgment conditions, and configuration vulnerability judgment conditions; then, the characteristic information of the target container is matched with the vulnerability judgment conditions to obtain a matching result, which includes one or more of kernel detection results, version detection results, and configuration detection results; finally, the vulnerability detection result of the target container is determined based on the matching result, which includes vulnerability identification information, such as the vulnerability detection result may include one or more of kernel detection results, version detection results, and configuration detection results.

[0054] Optionally, the vulnerability assessment condition is a preset condition, which can be a fixed value or a range, without restriction. The vulnerability assessment condition can be any one or more of the following: kernel vulnerability assessment condition, version vulnerability assessment condition, and configuration vulnerability assessment condition. For example, the vulnerability assessment condition can be a kernel vulnerability assessment condition, or it can be a combination of kernel vulnerability assessment condition and version vulnerability assessment condition, or it can be a combination of kernel vulnerability assessment condition, version vulnerability assessment condition, and configuration vulnerability assessment condition.

[0055] Optionally, the target container's feature information can be matched with vulnerability assessment conditions. This can involve determining whether the target container's feature information and vulnerability assessment conditions are equal, or comparing the relative relationship between the target container's feature information and vulnerability assessment conditions (e.g., version relationship). The matching result can be any one or more of the following: kernel detection result, version detection result, and configuration detection result. For example, the matching result can be a kernel detection result, a version detection result, and a configuration detection result, or even a combination of all three. It should be noted that there is a one-to-one correspondence between the target container's feature information, the vulnerability assessment conditions, and the matching result. That is, if the target container's feature information is a kernel version, then the vulnerability assessment condition is a kernel vulnerability assessment condition, and the matching result is also a relevant vulnerability matching result.

[0056] Optionally, the vulnerability detection results may include vulnerability identification information, or related information about the vulnerability (such as the location where the vulnerability occurs). The vulnerability identification information can be the name of the vulnerability (e.g., a kernel vulnerability) or the corresponding code for that type of vulnerability (e.g., CVE-2019-14271). When no vulnerability is detected, the vulnerability detection results may also include a security message.

[0057] By matching vulnerability criteria with characteristic information, it is possible to determine whether a target container has a vulnerability. This allows for the timely detection of vulnerabilities before container escape occurs.

[0058] In one possible embodiment, the feature information of the target container is matched with the vulnerability determination conditions to obtain a matching result. Specifically, the kernel version of the target container feature information is first obtained; then the kernel version is compared with the first preset version included in the kernel vulnerability determination conditions; if the kernel version is lower than the first preset version, the kernel detection result included in the matching result is determined to be a kernel vulnerability. The kernel detection result includes the kernel version and the identification information of the kernel vulnerability.

[0059] Since the target container runs on a kernel shared with the device under test, the kernel version can represent either the kernel version of the target container or the kernel version of the device under test. Kernel vulnerabilities allow attackers to remotely compromise the device under test and gain low-privilege access on certain system versions. They can then exploit this vulnerability to extract data locally from the compromised device, gaining administrator privileges and causing damage. An example is the Dirty Cow vulnerability in Linux systems.

[0060] In one possible embodiment, to prevent the aforementioned kernel vulnerability from harming the device under test, the kernel version of the target container can be obtained to determine the kernel version of the system of the device under test corresponding to the target container. Then, the kernel version of the system of the device under test is compared with a first preset version. If the kernel version of the system of the device under test is lower than the first preset version, a kernel vulnerability is determined to exist, and the identification information of the kernel vulnerability and the kernel version of the system of the device under test are used as the kernel detection result. For example, in a Linux system, a kernel vulnerability (Dirty Cow vulnerability) exists in kernel versions with Linux kernel versions lower than 3.9. That is, if the obtained kernel version of the target container is 3.7, which is lower than the first preset version 3.9, then the kernel detection result is determined to be a vulnerability, and the kernel detection result includes kernel version 3.7 and the kernel vulnerability.

[0061] In one possible embodiment, matching the characteristic information of the target container with vulnerability determination conditions to obtain a matching result can be further specified as follows: First, obtain the characteristic information of the target container, including the container version and container plugin version, where the container plugin version is the version of the target plugin within the target container; then, match one or both of the container version and container plugin version with a second preset version included in the version vulnerability determination conditions, where the second preset version includes one or more of a first container version threshold, a second container version threshold, a third container version threshold, and a container plugin version threshold; finally, if one or both of the container version and container plugin version match the second preset version included in the version vulnerability determination conditions, then determine that the version detection result included in the matching result indicates the existence of a version vulnerability, where the version detection result includes one or more of the container version, container plugin version, and version vulnerability identification information.

[0062] Optionally, if the container is a Docker container, the target plugin can be the runC tool, which is a lightweight tool for running containers and can be considered a command-line tool. The runC tool is the core component of a Docker container; the creation, running, and destruction of Docker containers are all accomplished by calling the runC tool.

[0063] Optionally, one or both of the container version and container plugin version can be matched with a second preset version included in the version vulnerability determination criteria. This can be matching the container version with the second preset version included in the version vulnerability determination criteria, or matching the container version and container plugin version with the second preset version included in the version vulnerability determination criteria. The second preset version can be a first container version threshold, a second container version threshold and a container plugin version threshold, a third container version threshold, or a combination of the first, second, and container plugin version thresholds. It should be noted that the second container version threshold needs to be used together with the container plugin version threshold as a version vulnerability determination criterion.

[0064] Optionally, the first container version threshold is used to determine if a Shocker attack vulnerability exists; the second container version threshold and the container plugin version threshold are used to determine if a runC escape vulnerability exists; and the third container version threshold is used to determine if a container vulnerability escape caused by the Docker cp command exists. To better understand container version vulnerabilities, the following provides a detailed explanation of the three types of container version vulnerabilities. First, Shocker attack: Because container versions prior to the first container version threshold grant the Shocker program the ability to call specific functions, attackers can brute-force scan the file system of the device under test by calling these specific functions to obtain the target file content, i.e., container escape occurs. Second, runC escape vulnerability: When the target container version is prior to the second container version threshold and the container plugin version is prior to the container plugin version threshold, attackers are allowed to rewrite the runC binary file on the device under test, allowing them to execute commands as administrator on the device under test, i.e., container escape occurs. Finally, container vulnerability escape caused by the Docker cp command: In versions prior to the third container version threshold, when the device under test uses the copy command (cp command), it calls a helper process. This helper process is not containerized and dynamically loads certain libraries at runtime. Attackers can inject code into the aforementioned auxiliary processes by replacing these specific libraries within the container. When an attempt is made to copy files from the container, this code will be executed, causing the container to escape and harm the device being monitored.

[0065] In one possible embodiment, to prevent the aforementioned version vulnerability from causing damage to the device under test, the container version of the target container is compared with a first container version threshold. If the container version of the target container is lower than the first container version threshold, it is determined that a Shocker attack may exist, thus determining that the version detection result included in the matching result indicates the existence of a version vulnerability. This version detection result includes the container version of the target container and the identification information of the version vulnerability (e.g., Shocker attack). Similarly, the container version of the target container can also be compared with a second container version threshold, and the container plugin version of the target container can also be compared with a container plugin version threshold. If the container version of the target container is lower than both the second container version threshold and the container plugin version of the target container is lower than the container plugin version threshold, it is determined that a runC escape vulnerability may exist, thus determining that the version detection result included in the matching result indicates the existence of a version vulnerability. This version detection result includes the container version of the target container (e.g., Docker version-18.09.1, runC version 1.0-rc6) and the identification information of the version vulnerability (e.g., runC escape vulnerability, or CVE-2019-5736). Similarly, the container version of the target container can be compared with the third container version threshold. If the container version of the target container is equal to the third container version threshold, it is determined that there may be a container vulnerability escape caused by the Docker cp command. Thus, the version detection result included in the matching result is determined to be a version vulnerability. The version detection result includes the container version of the target container (e.g., Docker version-19.03.0) and the identification information of the version vulnerability (e.g., container vulnerability escape caused by the Docker cp command, or CVE-2019-14271).

[0066] In one possible embodiment, the feature information includes container configuration. The feature information of the target container is matched with the vulnerability determination conditions to obtain a matching result. Specifically, the container configuration of the target container is first obtained, which includes one or more of access interface configuration, nested function configuration, and privileged function configuration. Then, the container configuration of the target container is matched with the configuration vulnerability determination conditions to obtain a configuration detection result, which includes one or more of access interface configuration detection results, nested function configuration detection results, and privileged function configuration detection results.

[0067] Optionally, the container configuration can be any one of the access interface configuration, nested feature configuration, and privileged feature configuration (for example, the container configuration is an access configuration, or the container configuration is a privileged feature configuration). The container configuration can also be any two of the access interface configuration, nested feature configuration, and privileged feature configuration (for example, the container configuration is an access interface configuration and a privileged feature configuration). The container configuration can also be an access interface configuration, a nested feature configuration, and a privileged feature configuration.

[0068] Optionally, the configuration detection result can be any one of the following: access interface configuration detection result, nested function configuration detection result, and privileged function configuration detection result (e.g., the configuration detection result can be the access interface configuration detection result). Alternatively, the configuration detection result can be any two of these three results (e.g., the configuration detection result can be both the access interface configuration detection result and the privileged function configuration detection result). Furthermore, the configuration detection result can also be a combination of all three. It should be noted that there is a one-to-one correspondence between container configuration and configuration detection result. That is, if the container configuration is an access configuration, then the configuration detection result is the access interface configuration detection result; if the container configuration is both an access interface configuration and a privileged function configuration, then the configuration detection result is both the access interface configuration detection result and the privileged function configuration detection result.

[0069] In one possible embodiment, the configuration vulnerability determination conditions include access vulnerability determination conditions, and the access interface configuration includes the open status of the default port corresponding to the remote access interface in the target container; the container configuration of the target container is matched with the configuration vulnerability determination conditions to obtain the configuration detection result, specifically: first, the target port corresponding to the remote access interface is determined based on one or both of the open status of the default port and the port corresponding to the target process; then, the remote access interface is called through the target port to access the specified resource in the target container; finally, if the access is successful, it is determined that the access interface configuration matches the access vulnerability determination conditions, and the configuration detection result includes the access interface configuration detection result indicating the existence of an access interface configuration vulnerability, the access interface configuration detection result including the port identifier of the target port and the identification information of the access vulnerability.

[0070] Optionally, the default port's open state includes two states: open and closed. The target port for the remote access interface is determined based on one or both of the default port's open state and the port corresponding to the target process. Specifically: first, determine the default port's open state; if the default port is open, then directly determine the target port for the remote access interface as the default port. The default port can be port 2375. Alternatively, the target port can be determined based on one or both of the default port's open state and the target process. More specifically: first, determine the default port's open state; if the default port is closed, then scan the target container's processes to determine if the target process exists (whether the remote access interface's process exists). If the target process exists, then the port corresponding to that target process is determined as the target port for the remote access interface.

[0071] Optionally, the specified resource within the target container can be http: / / xxx.xxx.xxx.xxx / info, http: / / xxx.xxx.xxx.xxx / images / json, or http: / / xxx.xxx.xxx.xxx / containers / json. The port identifier of the target port included in the access interface configuration detection results can be the port number (e.g., port 2375), and the vulnerability identifier information can be the name of the vulnerability (e.g., remote access interface configuration vulnerability). Accessing the specified resource within the target container (e.g., http: / / xxx.xxx.xxx.xxx / info) is to determine if there is any unauthorized access to the remote access interface.

[0072] Optionally, the remote access interface of the target container can be the Docker Remote API of the Docker container. Because the Docker Remote API can execute Docker commands, attackers can directly call the Docker Remote API to manipulate Docker, thereby sending the container to escape and causing damage to the device being monitored.

[0073] For example, the process first checks if the default port 2375 is open. If port 2375 is not open, it scans the target container's processes to determine if a Docker Remote API process exists. If a Docker Remote API process is found, it attempts to access the target container's resource http: / / xxx.xxx.xxx.xxx / images / json. If access is successful, it determines that the Docker Remote API access is unauthorized, and therefore determines that the access interface configuration detection result includes an access interface configuration vulnerability. The remote access vulnerability and the port number where the Docker Remote API is open are used as the access interface configuration detection result.

[0074] In one possible embodiment, the configuration vulnerability determination conditions include nested vulnerability determination conditions, and the nested functional configuration includes the configuration information of the socket file in the target container. The container configuration of the target container is matched with the configuration vulnerability determination conditions to obtain the configuration detection result. Specifically, firstly, the socket file in the target container is queried based on the configuration information of the socket file in the target container; then, if the socket file is found, the target resource information of the device to be tested is obtained, including network resources and container images; finally, if the acquisition is successful, it is determined that the nested functional configuration matches the nested vulnerability determination conditions, and the nested configuration detection result included in the configuration detection result indicates the existence of a nested configuration vulnerability. The nested detection result includes the file path of the socket file and the identification information of the nested vulnerability.

[0075] Optionally, the socket file in the target container can be the docker.sock file within the Docker container. This socket file (docker.sock file in the Docker container) is used for communication between the daemons inside the target container. The configuration information for the socket file in the target container can include whether the socket file exists and whether it can obtain information about the device being tested. The container image can be the file system (RootFileSystem) of the device being tested, which contains programs that can run on the system kernel and the corresponding data.

[0076] Optionally, attackers can leverage the exposed socket files within the target container to perform any operation within any container running on the device under test. This can cause the container to escape, thereby damaging the device under test.

[0077] In one possible embodiment, to prevent the above situation from occurring, the nested feature vulnerability can be investigated as follows: First, scan the target container to check for the existence of socket files; if socket files exist, use `docker -H unix: / / / var / run / docker.sock info` to attempt to obtain information about the device under test. If the information about the device under test can be obtained, it is determined that the nested feature configuration matches the nested vulnerability judgment conditions, and it is determined that the nested configuration detection results included in the configuration detection results indicate the existence of a nested configuration vulnerability.

[0078] In one possible embodiment, the configuration vulnerability determination conditions include privileged vulnerability determination conditions, and the privileged function configuration includes the access permission configuration of the target container for the disk of the device under test. The container configuration of the target container is matched with the configuration vulnerability determination conditions to obtain the configuration detection result. Specifically: first, if the access permission configuration indicates that the target container has access permissions, the identification information of the disk of the device under test is obtained; then, based on the identification information of the disk of the device under test, the disk of the device under test is mounted to the target container; finally, if the mounting is successful, it is determined that the privileged function configuration matches the privileged vulnerability determination conditions, and the privileged function configuration detection result included in the configuration detection result is determined to indicate the existence of a privileged configuration vulnerability, and the privileged function configuration detection result includes the identification information of the privileged vulnerability.

[0079] Mounting, in this context, involves mapping directories on the host machine to directories within the container, thereby enabling bidirectional automatic data synchronization between the two. In this solution, the disk of the device under test is mapped to a directory within the target container. Mounting can be a single directory mount, a multi-directory mount, or a read-only directory mount.

[0080] Optionally, after successfully mounting the disk of the device under test to the target container, and before determining that the privileged function configuration detection result includes a privileged configuration vulnerability, the step further includes: unmounting the disk of the device under test. Alternatively, after determining that the privileged function configuration detection result includes a privileged configuration vulnerability, the disk of the device under test is unmounted.

[0081] Optionally, when privileged access configurations are vulnerable, attackers can use specific commands (such as the `mount` command) to mount the disk of the device under test into the container. Because the host machine (device under test) and the container (target container) directories are automatically synchronized after mounting, attackers can gain read and write permissions to all files on the device under test through this mounting method. In addition, attackers can also execute commands on the device under test by writing scheduled tasks, thereby causing damage to the device.

[0082] In one possible embodiment, to prevent the above situation from occurring, the privileged function vulnerability can be investigated in the following way. First, based on the access permission configuration, check whether the disk of the device under test can be accessed. If access is possible, attempt to mount the disk of the device under test to the container. If the mounting is successful, cancel the mounting, and determine that the privileged function configuration detection result included in the configuration detection result indicates the existence of a privileged configuration vulnerability.

[0083] S203. Send the vulnerability detection results of the target container. The vulnerability detection results are used to send vulnerability alert information.

[0084] Optionally, the proxy client can determine vulnerability alert information based on the vulnerability detection results of the target container. For example, if the vulnerability detection results indicate that the target container has a vulnerability, the client can generate the corresponding alert information and then send the alert information to provide an alert before the vulnerability escapes.

[0085] Optionally, the proxy client sends the vulnerability detection results of the target container to the control device. The control device determines the vulnerability alarm information based on the vulnerability detection results of the target container. For example, when the vulnerability detection results indicate that the target container has a vulnerability, the control device generates the corresponding alarm information and sends the vulnerability alarm information to issue an alert.

[0086] Optionally, the proxy client sends the vulnerability detection results of the target container to the control device. The control device determines the vulnerability alarm information based on the vulnerability detection results of the target container. For example, when the vulnerability detection results indicate that the target container has a vulnerability, the control device generates the corresponding alarm information and sends the vulnerability alarm information to the management device, which then sends the vulnerability alarm information to issue an alert.

[0087] Optionally, when a vulnerability is detected in the device under test, the control device can send a vulnerability alert to the management device while simultaneously storing the vulnerability detection result as a historical vulnerability detection result. If the device under test is free of vulnerabilities for a certain period, the control device can periodically send security information about the device under test to the management device. For example, if no vulnerabilities are found within a week, meaning the control device does not receive any vulnerability detection results for the target container within a week, the control device can send a security message to the management device to inform it that the environment of the device under test is currently secure.

[0088] To better understand this solution, the following will be combined with... Figures 3-9 The present solution will be further explained using an exemplary embodiment:

[0089] Firstly, as Figure 3 As shown, Figure 3 This is a Docker container escape vulnerability detection system that applies this solution. The system includes a controller 30 (corresponding to...). Figure 1 The system comprises a control device (301) and a proxy client (31). The controller (301) includes three modules: a proxy client distribution module (301), used to select a proxy client from multiple proxy clients and distribute it to the device under test; a message receiving module (302), used to receive messages sent by the proxy client or send messages to the proxy client (31); and an alarm module (303), used to send an alarm message to the device under test if a vulnerability exists. The proxy client (31) includes two modules: a communication module (311), used to communicate with the control terminal; and a scanning module (312), used to execute the steps in this solution. Figure 4 As shown, the system's operation flow is as follows: First, the control terminal is started and run ( Figure 4 In step 402), the proxy client is obtained from the control terminal, and then the proxy client is executed in the container. Figure 4 Step 403 in the process. The agent client uses the scanning module to scan the container ( Figure 4 Step 404 in the process involves detecting whether the container has a container escape vulnerability. Figure 4 In step 405, if a container escape vulnerability is detected, the communication module of the proxy client is used to send the relevant information to the control end. Figure 4 Step 406). After receiving the information, the control terminal activates the alarm module and sends the alarm information to the device under test (…). Figure 4 Step 407 in the middle.

[0090] The scanning module 312 in the proxy client 31 includes a kernel scanning module 3121, a configuration scanning module 3122, and a version scanning module 3123. The workflow of the scanning module 312 in the proxy client 31 is as follows: Figure 5 As shown: Determining the existence of kernel vulnerabilities by scanning the kernel version. Figure 5 Step 502 in the process involves scanning network interfaces, characteristic files, and high-risk startup items to determine if there are any configuration errors that could lead to container escape vulnerabilities. Figure 5 Step 503 in the process; by scanning the Docker version, determine whether the currently used version has a container escape vulnerability. Figure 5 (Step 504 in the process). Summarize the above scan results, and if vulnerabilities are found, output the relevant information ( Figure 5 (Steps 505 and 506 in the text). It should be noted that there is no specific order in which the kernel scan, configuration scan, and version scan are performed. In other words, the three scans can be performed in any order, such as performing the version scan first, then the configuration scan, and finally the kernel scan, or vice versa.

[0091] The kernel scanning module 3121's workflow is as follows: Figure 6 As shown, first obtain the kernel version ( Figure 6 Step 601 in the process involves determining if there is a version issue with the kernel version. Figure 6 In step 602, if a version issue exists, output the relevant information. Figure 6 (Step 604 in the process). Since the Linux kernel in the host machine (the device under test) and the Docker container (the target container) shares the same kernel, determining the kernel version in the container allows us to determine the kernel version of the host machine. For example, if kernel version 2.6.22 < 3.9 (x86 / x64), then the Dirty Cow vulnerability (CVE-2016-5195) exists.

[0092] The workflow of the version scanning module is as follows: Figure 7 As shown, first obtain the version ( Figure 7 In step 702), it should be noted that the container version is not the same as the kernel version mentioned above. The container version refers to the container's version, while the kernel version refers to the kernel version of the container. Then, it is determined whether there is a problem with this version. Figure 7 In step 703, if there is a problem, output the relevant information. Figure 7(Step 704 in the example). For instance, first, based on the obtained Docker container version, confirm whether the currently used container has vulnerabilities such as Shocker attack (Docker version < 1.0, present in most versions prior to Docker 1.0), runC escape vulnerability (CVE-2019-5736) (Docker version < 18.09.2, runc version < 1.0-rc6), or Docker cp command vulnerability leading to container escape attack (CVE-2019-14271) (Docker 19.03.0). If these vulnerabilities exist, proceed to the next step; otherwise, terminate directly. 2. If relevant vulnerabilities are determined to exist, output relevant information, including vulnerability name, Docker version, runc version information, etc.

[0093] The configuration scanning module 3122 includes the Docker Remote API unauthorized access configuration scanning module 31221 (also known as the remote access configuration scanning module), the Docker in Docker configuration scanning module 31222 (also known as the nested function configuration scanning module), and the privileged configuration scanning module 31223 (also known as the privileged function configuration scanning module).

[0094] The workflow of the Docker Remote API unauthorized access configuration scanning module 31221 is as follows: Figure 8 As shown, first check if the access interface is enabled. Figure 8 Step 802 in the process, if enabled, checks whether the access interface is unauthorized. Figure 8 In step 803, if unauthorized access is detected, relevant information will be output. Figure 8 (Step 804 in the example). For instance, first, by scanning process information and open ports, it is confirmed whether the Docker Remote API interface is enabled. The Docker Remote API is open on port 2375 by default. If the Docker Remote API interface is enabled, try accessing http: / / xxx.xxx.xxx.xxx / info. If access is successful, it is determined that there is a Docker Remote API unauthorized access vulnerability. Finally, after confirming the existence of the vulnerability, relevant information is output, including the vulnerability name, open ports, etc.

[0095] The workflow of the Docker in Docker configuration scanning module 31222 is as follows: Figure 9 As shown, the first step is to check if a socket file exists. Figure 9 In step 902), if it exists, then attempt to obtain the container information of the device to be detected. Figure 9In step 903, if the acquisition is successful, the relevant information will be output. Figure 9 (Step 904 in the example). For instance, first, the system scans the files in the container to see if a `docker.sock` file exists. Then, if a `docker.sock` file exists, it uses `docker -H unix: / / / var / run / docker.sock info` to attempt to obtain information about the host machine's Docker container, including network and image information. If the host machine's information can be obtained, it means that the host machine's Docker can be called and executed within the Docker container. Mounting the host machine's `docker` file and `docker.sock` file into the container confirms the existence of a Docker in Docker vulnerability. Finally, after confirming the vulnerability, relevant information is output, including the vulnerability name and the path to the `docker.sock` file.

[0096] The workflow of the privileged configuration scanning module 31223 is as follows: Figure 10 As shown, the first step is to check whether the disk of the device under test can be accessed. Figure 10 In step 1002, if access is available, try to see if the device to be tested can be mounted onto the container. Figure 10 Step 1003 in the process, if mounting is successful, output the relevant information and then end. Figure 10 Steps 1004 and 1005 in the process.

[0097] See Figure 11 , Figure 11 This is a schematic diagram of the vulnerability detection device based on a proxy client provided in this application embodiment. The vulnerability detection device based on a proxy client provided in this application embodiment includes:

[0098] like Figure 11 The module 1101 shown is the acquisition module 1101, which is used to scan the target container and obtain the characteristic information of the target container. The characteristic information includes one or more of the kernel version, container version and container configuration. The module 1102 is the determination module 1102, which is used to determine the vulnerability detection result of the target container based on the characteristic information of the target container. The module 1103 is the communication module 1103, which is used to send the vulnerability detection result of the target container. The vulnerability detection result is used to send vulnerability alarm information.

[0099] In another implementation, the acquisition module 1101 is further configured to acquire vulnerability determination conditions, which include one or more of kernel vulnerability determination conditions, version vulnerability determination conditions, and configuration vulnerability determination conditions; the determination module 1102 is further configured to match the feature information of the target container with the vulnerability determination conditions to obtain a matching result, which includes one or more of kernel detection results, version detection results, and configuration detection results; the determination module 1102 is further configured to determine the vulnerability detection result of the target container based on the matching result, which includes vulnerability identification information.

[0100] In another implementation, the acquisition module 1101 is further configured to acquire the kernel version, which is included in the characteristic information of the target container; the determination module 1102 is further configured to compare the kernel version with the first preset version included in the kernel vulnerability determination conditions; the determination module 1102 is further configured to determine that the kernel detection result included in the matching result is a kernel vulnerability if the kernel version is lower than the first preset version, and the kernel detection result includes the kernel version and the identification information of the kernel vulnerability.

[0101] In another implementation, the acquisition module 1101 is further configured to acquire the characteristic information of the target container, including the container version and the container plugin version, wherein the container plugin version is the version of the target plugin within the target container; the determination module 1102 is further configured to match one or both of the container version and the container plugin version with a second preset version included in the version vulnerability determination conditions, wherein the second preset version includes one or more of a first container version threshold, a second container version threshold, a third container version threshold, and a container plugin version threshold; the determination module 1102 is further configured to determine that if one or both of the container version and the container plugin version match the second preset version included in the version vulnerability determination conditions, the matching result includes a version detection result indicating the existence of a version vulnerability, wherein the version detection result includes one or more of the container version, the container plugin version, and the identification information of the version vulnerability.

[0102] In another implementation, the acquisition module 1101 is further used to acquire the container configuration of the target container, the container configuration including one or more of the access interface configuration, nested function configuration and privileged function configuration; the determination module 1102 is further used to match the container configuration of the target container with the configuration vulnerability judgment conditions to obtain the configuration detection result, the configuration detection result including one or more of the access interface configuration detection result, nested function configuration detection result and privileged function configuration detection result.

[0103] In another implementation, the determining module 1102 is further configured to determine the target port corresponding to the remote access interface based on one or both of the open status of the default port and the port corresponding to the target process; the determining module 1102 is further configured to call the remote access interface through the target port to access the specified resource in the target container; the determining module 1102 is further configured to determine, if the access is successful, that the access interface configuration matches the access vulnerability judgment condition, and determine that the access interface configuration detection result included in the configuration detection result indicates that there is an access interface configuration vulnerability, the access interface configuration detection result including the port identifier of the target port and the identification information of the access vulnerability.

[0104] In another implementation, the determining module 1102 is further configured to, if a socket file is found, obtain the target resource information of the device to be detected, including network resources and container images; the determining module 1102 is further configured to, if the acquisition is successful, determine that the nested function configuration matches the nested vulnerability judgment condition, and determine that the nested configuration detection result included in the configuration detection result is that a nested configuration vulnerability exists, including the file path of the socket file and the identification information of the nested vulnerability.

[0105] In another implementation, the acquisition module 1101 is further configured to acquire the identification information of the disk of the device to be tested if the access permission configuration indicates that the target container has access permissions; the determination module 1102 is further configured to mount the disk of the device to be tested to the target container according to the identification information of the disk of the device to be tested; the determination module 1102 is further configured to determine that the privileged function configuration matches the privileged vulnerability judgment condition if the mounting is successful, and determine that the privileged function configuration detection result included in the configuration detection result is that there is a privileged configuration vulnerability, and the privileged function configuration detection result includes the identification information of the privileged vulnerability.

[0106] It is understood that the functions of each functional unit of the vulnerability detection device based on the proxy client provided in this application embodiment can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, and will not be repeated here.

[0107] In feasible embodiments, the vulnerability detection device based on a proxy client provided in this application can be implemented in software. The vulnerability detection device based on a proxy client can be stored in a memory and can be software in the form of programs and plugins, and includes a series of units, including an acquisition unit and a processing unit; wherein, the acquisition unit and the processing unit are used to implement the vulnerability detection method based on a proxy client provided in this application.

[0108] In other feasible embodiments, the vulnerability detection device based on a proxy client provided in this application can also be implemented using a combination of hardware and software. As an example, the vulnerability detection device based on a proxy client provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the vulnerability detection method based on a proxy client provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0109] Please see Figure 12 This is a schematic diagram of a computer device 120 provided in an embodiment of this application. The computer device 120 may include a processor 1201, a memory 1202, a network interface 1203, and at least one communication bus 1204. The processor 1201 is used to schedule computer programs and may include a central processing unit, a controller, or a microprocessor. The memory 1202 is used to store computer programs and may include high-speed random access memory, non-volatile memory, such as disk storage devices or flash memory devices. The network interface 1203 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface) to provide data communication functions. The communication bus 1204 is responsible for connecting the various communication components. This computer device 120 may correspond to the vulnerability detection device 100 based on a proxy client described above. The memory 1202 is used to store computer programs, which include program instructions. The processor 1201 is used to execute the program instructions stored in the memory 1202 to perform the processes described in steps S201 to S203 of the above embodiments, performing the following operations:

[0110] In practice, the aforementioned computer equipment can perform the above-described actions through its built-in functional modules. Figures 2 to 10 The implementation methods provided for each step are detailed in the above-mentioned implementation methods, and will not be repeated here.

[0111] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are implemented when executed by a processor. Figure 2The vulnerability detection methods based on proxy clients provided in each step are detailed in the implementation methods provided in each step above, and will not be repeated here.

[0112] The aforementioned computer-readable storage medium can be the internal storage unit of the recommended model training device provided in any of the foregoing embodiments or the aforementioned terminal device, such as the hard drive or memory of an electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0113] The terms "first," "second," "third," "fourth," etc., in the claims, description, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0114] In the specific implementation of this application, data related to user information (such as kernel version, container version, etc.) are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0115] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The presentation of this phrase in various locations throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. The term "and / or" as used in this specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, 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 device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The 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 operate 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 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable agent-based vulnerability detection device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

Claims

1. A vulnerability detection method based on a proxy client, characterized in that, The method includes: The target container is scanned to obtain its characteristic information, which includes one or more of the following: kernel version, container version, and container configuration. Obtain vulnerability assessment criteria, which include one or more of kernel vulnerability assessment criteria, version vulnerability assessment criteria, and configuration vulnerability assessment criteria; The feature information of the target container is matched with the vulnerability determination conditions to obtain a matching result, which includes one or more of kernel detection results, version detection results, and configuration detection results; the vulnerability detection result of the target container is determined based on the matching result. Send the vulnerability detection results of the target container, and the vulnerability detection results are used to send vulnerability alert information; The step of matching the feature information of the target container with the vulnerability determination conditions to obtain a matching result includes: The characteristic information of the target container is obtained, including the container version and the container plugin version, wherein the container plugin version is the version of the target plugin within the target container; Match one or both of the container version and the container plugin version with the second preset version included in the version vulnerability determination conditions. The second preset version includes one or more of the first container version threshold, the second container version threshold, the third container version threshold, and the container plugin version threshold. If one or both of the container version and the container plugin version match the second preset version, then the matching result is determined to include a version detection result indicating the existence of a version vulnerability. The version detection result includes one or more of the container version, the container plugin version, and the identification information of the version vulnerability.

2. The method according to claim 1, characterized in that, The step of matching the feature information of the target container with the vulnerability determination conditions to obtain a matching result includes: The kernel version is included in the characteristic information of the target container. Compare the kernel version with the first preset version included in the kernel vulnerability determination criteria; If the kernel version is lower than the first preset version, then the matching result includes the kernel detection result indicating the existence of a kernel vulnerability. The kernel detection result includes the kernel version and the identification information of the kernel vulnerability.

3. The method according to claim 1, characterized in that, The feature information includes container configuration. Matching the feature information of the target container with the vulnerability determination conditions to obtain a matching result includes: Obtain the container configuration of the target container, wherein the container configuration includes one or more of the following: access interface configuration, nested function configuration, and privileged function configuration; The container configuration of the target container is matched with the configuration vulnerability judgment conditions to obtain the configuration detection result. The configuration detection result includes one or more of the following: access interface configuration detection result, nested function configuration detection result, and privileged function configuration detection result.

4. The method according to claim 3, characterized in that, The configuration vulnerability determination criteria include access vulnerability determination criteria, and the access interface configuration includes the open status of the default port corresponding to the remote access interface in the target container. The step of matching the container configuration of the target container with the configuration vulnerability determination conditions to obtain the configuration detection result includes: The target port corresponding to the remote access interface is determined based on one or both of the open status of the default port and the port corresponding to the target process. Access the specified resource within the target container by calling the remote access interface through the target port; If the access is successful, it is determined that the access interface configuration matches the access vulnerability determination condition, and the access interface configuration detection result included in the configuration detection result is determined to be an access interface configuration vulnerability. The access interface configuration detection result includes the port identifier of the target port and the identification information of the access vulnerability.

5. The method according to claim 3, characterized in that, The configuration vulnerability determination criteria include nested vulnerability determination criteria, and the nested function configuration includes the configuration information of the socket file in the target container; the step of matching the container configuration of the target container with the configuration vulnerability determination criteria to obtain the configuration detection result includes: The socket file in the target container is queried according to the configuration information of the socket file in the target container; If the socket file is found, the target resource information of the device to be detected is obtained, including network resources and container images. If successful, it is determined that the nested function configuration matches the nested vulnerability judgment condition, and the nested configuration detection result included in the configuration detection result is determined to be a nested configuration vulnerability. The nested configuration detection result includes the file path of the socket file and the identification information of the nested vulnerability.

6. The method according to claim 3, characterized in that, The configuration vulnerability determination criteria include privileged vulnerability determination criteria, and the privileged function configuration includes the disk access permission configuration of the target container on the device to be tested; matching the container configuration of the target container with the configuration vulnerability determination criteria to obtain the configuration detection result includes: If the access permission configuration indicates that the target container has access permissions, then obtain the disk identification information of the device to be detected; Based on the identification information of the disk of the device under test, the disk of the device under test is mounted to the target container; If the mounting is successful, it is determined that the privileged function configuration matches the privileged vulnerability determination condition, and the privileged function configuration detection result included in the configuration detection result is determined to be a privileged configuration vulnerability. The privileged function configuration detection result includes the identification information of the privileged vulnerability.

7. A vulnerability detection device based on a proxy client, characterized in that, The device includes: The acquisition module is used to scan the target container and obtain the feature information of the target container, the feature information including one or more of kernel version, container version and container configuration; The acquisition module is also used to acquire vulnerability determination conditions, which include one or more of kernel vulnerability determination conditions, version vulnerability determination conditions, and configuration vulnerability determination conditions. The determination module is used to match the feature information of the target container with the vulnerability determination conditions to obtain a matching result, wherein the matching result includes one or more of kernel detection results, version detection results, and configuration detection results; and to determine the vulnerability detection result of the target container based on the matching result. A communication module is used to send the vulnerability detection results of the target container, and the vulnerability detection results are used to send vulnerability alert information; The acquisition module is further configured to acquire the feature information of the target container, including the container version and the container plugin version, wherein the container plugin version is the version of the target plugin within the target container; The determining module is further configured to match one or both of the container version and the container plugin version with a second preset version included in the version vulnerability determination conditions. The second preset version includes one or more of a first container version threshold, a second container version threshold, a third container version threshold, and a container plugin version threshold. If one or both of the container version and the container plugin version match the second preset version, the matching result is determined to include a version detection result indicating the existence of a version vulnerability. The version detection result includes one or more of the container version, the container plugin version, and version vulnerability identification information.

8. A computer device, characterized in that, include: The system includes a processor, a communication interface, and a memory, which are interconnected. The memory stores executable program code, and the processor is used to call the executable program code to execute the vulnerability detection method based on a proxy client as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the vulnerability detection method based on a proxy client as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the steps of the vulnerability detection method based on a proxy client as described in any one of claims 1-6.

Images