METHOD AND MODULE FOR DETECTING ATTEMPT CYBER ATTACKS IN A FLEET OF COMPUTERS

Description

Technique antérieure

[0001] The invention relates to the general field of securing computer programs.

[0002] The invention relates more particularly to a method for orchestrating the computer security of a computer equipment infrastructure using mitigation policies.

[0003] It is important to remember that when software has a vulnerability, mitigation does not aim to fix the software, which continues to run normally, but rather to block the effects of the vulnerability. For example, if software has a security flaw when sending a particular packet through a packet-sending function, mitigating this vulnerability might involve blocking the process of sending that specific packet. Mitigation does not eliminate the vulnerability but renders it unexploitable.

[0004] In the field of computer security, security vulnerabilities are listed in a public list accessible at https: / / cve.mitre.org / , each vulnerability referenced in the list being identified by a unique CVE identifier (for Common Vulnerabilities and Exposures).

[0005] Thousands of CVE identifiers are issued each year, and complex software can accumulate hundreds of CVEs.

[0006] Managing CVEs to maintain the security of a fleet of IT equipment can therefore prove extremely complex. The documents Maxime Belair et al: "SNAPPY programmable kernel-level policies for containers", Proceedings of the 36th Annual ACM Symposium on Applied Computing, 2021; and FR3110726A1 represent the state of the art in this area. Exposé de l'invention

[0007] The invention aims to facilitate the security management of a computer network by detecting the processes on those computers that are the target of a cyberattack. As a corollary, the invention strengthens the security of a computer network.

[0008] To this end, and according to a first aspect, the invention relates to a method for detecting an attempted computer attack implemented by a computer, said attack exploiting a vulnerability in a function to be protected running in a process of a user space of said computer, the execution of the function to be protected resulting in the execution, prior to said attack, of a kernel function, said method comprising the following steps: execution of a mitigation policy in the kernel, the mitigation policy being associated with said kernel function and being loaded into a kernel namespace associated with said process and dedicated to security; and if, during its execution, said mitigation policy detects an attack vector supported by said policy and targeting said function to be protected: sending a message containing data representative of said process to a security management server.

[0009] Correspondingly, the invention proposes a module for detecting an attempted computer attack on a computer, said attack exploiting a vulnerability in a function to be protected running in a process in a user space of said computer, the execution of said function to be protected resulting in the execution, prior to said attack, of a kernel function, said module comprising: an execution submodule configured to execute a mitigation policy in said kernel, said mitigation policy being associated with said kernel function and being loaded into a kernel namespace associated with said process and dedicated to security; a sending submodule configured to send, to a security management server, a message containing data representative of the process, said sending submodule being configured to send said message if said mitigation policy detects an attack vector supported by said policy and targeting said function to be protected.

[0010] Thus, the process makes it possible to identify the processes on which computer attacks take place, a computer attack designating one or more instructions allowing to bypass one or more security rules in the execution of a computer process.

[0011] A vulnerability is a flaw in a process that, if exploited, allows an attacker to bypass the security rules of the computer system on which the process is executed. For example, the CVE-2021-44228 vulnerability, known as "Log4Shell," is present in the Log4J logging software component. Log4J is used by many applications that use the Java programming language. In the most severe cases, this vulnerability allows a remote attacker to force the target machine to execute arbitrary code.

[0012] Recall that a namespace isolates, in an abstraction, the instance of a system resource for the processes associated with that namespace. Modifications made to the system resource are visible to other processes associated with the namespace, but invisible to other processes. Namespaces are notably used to implement containers. We will subsequently write that a system resource in a namespace is declared by that namespace.

[0013] A container is an execution environment on which processes run, a container being associated with a set of namespaces allowing the execution of these processes to be isolated from the rest of the system's processes.

[0014] In one embodiment, the data representing a process and included in the message is data representing the namespace associated with the process. The detection method then makes it possible to identify namespaces, for example containers, that are under cyberattack.

[0015] It should be noted that containers are only one non-limiting example in a particular embodiment of the process as described above.

[0016] The process allows messages identifying the namespaces of the attacked processes to be sent to a security management server.

[0017] The security management server can, in particular, receive such messages from other computers that implement the same detection process.

[0018] Also, in some embodiments of the process, the messages sent to a security management server include the identifiers of the vulnerabilities exploited by the attacks.

[0019] The method presented proposes using a mitigation policy executed in the computer's kernel. Advantageously, it is not necessary to restart the kernel for the mitigation policy to take effect.

[0020] According to the procedure, the mitigation policy program loaded into the kernel is an executable program. It is not simply a signature or a set of rules.

[0021] The execution of the mitigation policy at the kernel level is triggered, directly or indirectly, by the launch of the execution, in user space, of the function to be protected.

[0022] For example, the execution of the mitigation policy is triggered directly by the function to be protected, in other words by the function to be protected itself.

[0023] In another example, the execution of the mitigation policy is triggered indirectly by the function to be protected, in other words by another user-space function whose execution is triggered by the launch of the execution of the function to be protected.

[0024] In one embodiment, the execution of the mitigation policy makes it possible both to detect an attack using this function, and to block this attack.

[0025] Subsequently, we will write that the process is attacked, or that the container (or more generally the namespace) in which this process runs is attacked, if an attack is triggered directly or indirectly by the execution of this function.

[0026] The described method advantageously allows information about attacked processes to be sent to a security management server. This information can, for example, identify the containers, or more generally the namespaces, in which these processes are running. The security management server can be controlled by a central administrator.

[0027] This process can be advantageously applied to a plurality of computers in a computer network, which makes it possible to send information on attacks suffered by each of the computers in the computer network back to the security management server.

[0028] In this case, the central administrator has a role in orchestrating security across the computer network.

[0029] The invention also allows the central administrator to avoid the need to manually consult each administrator of each computer so that each of them, for example, can manually and locally check if a given vulnerability affects the software on their machine.

[0030] According to a particular implementation method of the detection process, the said mitigation policy is loaded into a namespace dedicated to security and associated with the root process of said computer.

[0031] A computer implementing the detection process includes a root process associated with namespaces from which the namespaces of the computer's containers inherit. If a mitigation policy is declared in the namespace associated with the root process and dedicated to security, then the namespaces associated with each container and dedicated to security inherit this mitigation policy. In other words, a process running in a container will be protected by the mitigation policy declared in the namespace associated with the root process.

[0032] This embodiment advantageously allows for the automatic monitoring of all containers on the computer because each container inherits the mitigation policies of the namespace associated with the root process of the computer.

[0033] Thus, for any container (or more generally for any namespace dedicated to security) on the computer, if a process in that container calls the function to be protected, the mitigation policy is executed and makes it possible to detect if an attack is in progress in that container.

[0034] According to a particular embodiment of the invention, the detection process comprises the following steps: reception, from said security management server, of a mitigation policy identifier; installation, in said computer kernel, of the mitigation policy corresponding to said mitigation policy identifier.

[0035] This implementation method advantageously allows a central administrator controlling the security management server to orchestrate the installation of mitigation policies in a fleet of computers.

[0036] Mitigation policies can therefore be managed centrally, without requiring the contribution of administrators of at least some computers in the fleet, which avoids the manual installation of the mitigation policy on at least some, for example on all machines in the fleet.

[0037] According to a particular implementation method of the detection process, said installation step comprises sub-steps of: sending a request containing the mitigation policy identifier to a security server; obtaining, in response to the request, a description file of said mitigation policy; obtaining object code of the mitigation policy identified in said description file; generating executable code of said mitigation policy from said object code; and installing the executable code in said kernel.

[0038] Advantageously, the detection process proposes to download the appropriate mitigation policy program when a vulnerability affecting software running on the computer equipment has been identified, and to automatically install this program in the kernel of the equipment to mitigate this vulnerability.

[0039] Alternatively, a mitigation policy can be systematically installed on all computers. Coupling with a vulnerability scanner, as proposed here, to install the policy only if the scanner detects that the software is potentially vulnerable (regardless of its actual exploitability), is an option.

[0040] This implementation method thus proposes to install the mitigation policy from a security server if necessary.

[0041] Using a security server advantageously saves memory space on the computer kernel.

[0042] This implementation also makes it possible to provide the computer with a database containing a plurality of mitigation policies that can be installed as needed, at the discretion of the security management server.

[0043] According to a particular implementation method of the detection process, the said step of sending said message to the security management server is implemented from user space in response to the sending of a signal by the kernel to user space to signal the detection of the attack vector by the mitigation policy.

[0044] A signal is sent from the kernel to user space. This transmission is triggered by the execution of the mitigation policy. Specifically, the message sending process can be coded within the mitigation policy itself. Part of the data to be sent can be coded within the mitigation policy, and another part can be automatically retrieved from the kernel (for example, the identifier of the security-dedicated namespace and / or the identifier of the current process).

[0045] This signal contains information about the process, for example about the namespace associated with the process and possibly the container of this process, and can identify the attack.

[0046] The message sent to the security management server can characterize the attacked process and / or its namespace and / or the container in which the process executed. In particular, this message can reiterate the information contained in the signal transmitted to user space by the kernel, and may also contain additional information to more precisely characterize the attacked container, for example: the container image name, the main process name, and the container's startup time.

[0047] Such additional information can be particularly useful if a container is stopped and restarted. In this case, a signal obtained by the kernel cannot link the stopped container to the restarted container because the latter is associated with a namespace whose identifier has changed with the container restart. The container image name, in particular, allows this link to be established. This additional information can also be useful for applying security measures to all processes running a container image identical to that of the attacked process that triggered the execution of the mitigation policy and the sending of the signal.

[0048] According to one implementation method of the detection process, said at least one message contains at least one piece of information from among: a computer identifier; a representative data of the namespace associated with the attacked process and dedicated to security; a vulnerability identifier; a time at which the execution of the mitigation policy was triggered.

[0049] This method of implementation makes it advantageous to spatially and temporally locate an attack on a network of computers implementing the detection process.

[0050] The computer's identifier is, for example, its IP address ("Internet Protocol" in English).

[0051] The data representing the container could, for example, be the identifier of the container namespace dedicated to security and including the mitigation policy.

[0052] According to a second aspect, the invention proposes an identification method implemented by a security management server to identify an attempted computer attack on at least one computer, said attack exploiting a vulnerability in a protected function running in a user space of the computer. This method comprises the following steps: reception from said at least one computer of a message containing data representative of a process running in said user space, when an attack vector targeting said function to be protected has been detected by the execution, in the computer kernel, of a mitigation policy loaded in a kernel namespace dedicated to security and associated with that process; addition to a list of data representative of that message.

[0053] Correspondingly, the invention proposes an identification module that can be implemented in a security management server, said module being configured to identify an attempted computer attack on at least one computer, said attack exploiting a vulnerability in a function to be protected running in a user space of the computer, said module comprising: a receive submodule configured to receive from said at least one computer a message containing data representative of a process running in said user space, when an attack vector targeting the function to be protected has been detected, in the kernel of the computer, by the execution of a mitigation policy loaded in a kernel namespace dedicated to security and associated with that process; an add submodule configured to add to a list data representative of said message.

[0054] The invention proposes a method for identifying, from a server, all the processes under attack in a network of computers, and / or the namespaces or containers associated with these processes.

[0055] This identification of attacked processes makes it advantageous to facilitate the orchestration of security across the computer network by a central administrator controlling the security management server.

[0056] To this end, the invention proposes to pool messages from attacked computers by adding them to a list.

[0057] This list allows the administrator to make decisions regarding security management across the computer network. For example, the presence of certain attacks on specific processes or containers may prompt the installation of additional security programs to improve the security of those processes or containers.

[0058] According to a particular method of implementation, the process includes a step of sending an identifier of said mitigation policy to at least one computer.

[0059] Thus, if the central administrator becomes aware of a new vulnerability endangering the computer fleet, the invention advantageously allows him to order the installation of a mitigation policy on the entire fleet to protect the computers from this vulnerability.

[0060] This implementation method avoids requiring administrators of the various computers to manually install mitigation policies to protect those computers.

[0061] According to a particular embodiment of the invention, the identification process includes a step of sending to at least one computer an identifier of a security server from which said mitigation policy is extracted.

[0062] In a case where mitigation policies are distributed across multiple security servers, the invention allows each computer to identify the security server from which to download the desired mitigation policy.

[0063] Each of the processes described above can be implemented by a computer program.

[0064] Therefore, the invention also relates to a computer program on a recording medium, this program being capable of being implemented in computer equipment or more generally in a computer. This program includes instructions enabling the implementation of a process as described above.

[0065] This program can use any programming language, and be in the form of source code, object code, or code somewhere between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0066] The invention also relates to an information carrier or a recording medium readable by a computer, and comprising instructions for a computer program as mentioned above.

[0067] Information or recording media can be any entity or device capable of storing programs. For example, media can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive, or a flash memory.

[0068] On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be carried via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0069] The program according to the invention can in particular be downloaded onto an Internet-type network.

[0070] Alternatively, the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to perform or to be used in the performance of one of the processes as described above. Brève description des annexes et des figures

[0071] Other features and advantages of the present invention will become apparent from the description given below, with reference to the attached drawings which illustrate an example of an embodiment without any limiting character.

[0072] Regarding the appendices: [Appendix 1] Appendix 1 represents a first executable code snippet of a mitigation policy that can be used in a particular implementation; [Appendix 2] Appendix 2 represents a second executable code snippet of a mitigation policy that can be used in a particular implementation;

[0073] In the figures: [ Fig.1 ] there [ Fig.1 ] represents an implementation of detection and identification processes conforming to a particular embodiment; [ Fig.2 ] there [ Fig.2 ] represents detection and identification devices conforming to a particular embodiment; [ Fig.3 ] there [ Fig.3 ] represents an installation step of the detection process conforming to a particular embodiment; [ Fig.4 ] there [ Fig.4 ] represents an example of a description file conforming to a particular implementation method; [ Fig.5 ] there [ Fig.5 ] represents components of a computer kernel conforming to a particular embodiment; [ Fig.6 ] there [ Fig.6 ] represents a process table stored in a computer kernel conforming to a particular embodiment; [ Fig.7 ] there [ Fig.7 ] represents in flowchart form the main steps of a security process that can be implemented in a particular embodiment. Description détaillée de plusieurs modes de réalisation particuliers

[0074] There [ Fig.1 ] represents a particular embodiment of the invention in which the detection and identification processes are implemented.

[0075] In the example represented by the [ Fig.1 ], a single computer EQ n implements the detection process and the identification process is implemented to identify computer attacks on this computer EQ n.

[0076] Such an example on a single computer is shown for the sake of simplicity but is in no way limiting to the invention. In particular, the detection and identification methods can be implemented on multiple computers.

[0077] It should be noted that in other embodiments of the invention, the detection and identification processes can be implemented independently of each other.

[0078] The stages, represented on the [ Fig.1 ], of the detection process implemented by the EQ computer, are steps of: reception F_R, from a MIDA module of a security management server, of an identifier of a mitigation policy PG k; installation F_I of the mitigation policy PG k in a kernel KER n of the computer EQ n; execution F_Ex of a mitigation policy PG k in the kernel KER n; sending F_E1 of a signal from the kernel KER n to the user space USR n; sending F_E2, in reaction to said sending F_E1, of a Log i message from the user space USR n to said security management server CNode.

[0079] The steps of the identification process shown on the [ Fig.1 are steps in: sends E_E from the security management server to computer EQ n, of a signal enabling the installation of mitigation policy PG k; receives E_R the Log i message from user space USR n of computer EQ n; adds E_A a data representative of the Log i message to a list.

[0080] The steps of the identification process are carried out by a MIDA module of the CNode security management server while the steps of the detection process are carried out by an MDET n module of the user space of the computer EQ n.

[0081] The MIDA module sends and receives signals or messages via communication means 13' shown on the [ Fig.2 ].

[0082] The MDET module sends and receives signals or messages via communication means 13.

[0083] The signal sent to the computer during the E_E step is, for example, of the form http: / / IPHost:port / add_policy?namespace=0&CVE_ID=CVEID where "IPHost:port" is the IP address of computer EQ n, where the argument "namespace=0" indicates that the mitigation policy is to be installed in a namespace of the root process of computer EQ n, and where the argument "CVE_ID=CVEID" indicates the CVEID of the CVE vulnerability against which to protect the containers of computer EQ n.

[0084] It should be noted that installing the PG k mitigation policy in the root process namespace in this example represents a specific implementation of the invention and is not limiting. In particular, namespaces associated with other processes can be chosen for installing the PG k mitigation policy. Thus, by way of example, the signal sent by the security management server and received by the computer may include an argument indicating the namespace in which the PG k mitigation policy should be installed, for example, the root process namespace or another namespace. Also by way of example, the server may send signals to multiple computers indicating that the mitigation policy should be installed in namespaces that may differ from one computer to another.

[0085] The advantage of choosing the root process namespace is that the containers in which other processes run inherit the PG k mitigation policy installed in the root process namespace. Thus, in this case, the mitigation policy allows for the detection of attack attempts in all containers on the EQ n computer and their protection.

[0086] Upon receiving the signal F_R from the CNode security management server, the MDET module n implements an installation step F_I of the mitigation policy PG k on the kernel KER n, in response to this signal. For example, if this signal contains the identifier of a CVE vulnerability, the MDET module n implements the installation of a mitigation policy to protect the computer EQ n against this vulnerability.

[0087] A specific method for implementing the F_I installation step is shown on the [ Fig.3 and will be described below.

[0088] On the [ Fig.1 is also represented an execution step F_Ex of the mitigation policy PG k in the kernel KER n. In this example, the execution of the mitigation policy is triggered by the execution (in English "call") of a vulnerable function fc1 called during the execution of the process p1 in the container C1.

[0089] In this embodiment, launching the execution of the vulnerable function fc1 indirectly triggers the execution of a kernel function oper_exec(), which itself triggers the execution of the mitigation policy PG k. Specifically, the execution of the function to be protected, fc1, triggers the execution of an exec() function in user space USR n, which in turn triggers the execution of the oper_exec() function in the kernel.

[0090] In another embodiment, the execution of a function to be protected directly leads to the execution of a function in the kernel associated with a mitigation policy.

[0091] The triggering of the PG k mitigation policy by the execution of the kernel function `oper_exec()` is, for example, enabled by a well-known hook. This mechanism allows the PG k mitigation policy to be linked to the `oper_exec()` function in such a way that the PG k mitigation policy is executed before an attack, should one occur. Depending on the outcome of the mitigation policy execution, the vulnerable function is either blocked or executed.

[0092] Such an execution of the mitigation policy PG k in the KER n kernel is described in particular in document [1], which proposes a security method using a security policy, with the mitigation policy taking the role of a security policy. Such a method is represented on the [ Fig.7 and is described later.

[0093] If the mitigation policy PG k detects an attack, a FE_1 signal is sent to user space USR n. The instruction for this first FE_1 transmission can be directly coded in the mitigation policy's executable program.

[0094] This signal can, for example, take the form "Timestamp, IPHost, SecurityNamespaceID, CVEID, Msg". Here, "Timestamp" corresponds to the millisecond at which the mitigation policy was triggered in response to the attempted exploitation of the vulnerability identified as "CVEID". "IPHost" corresponds to the IP address of the computer EQ n. "SecurityNamespaceID" corresponds to the security-dedicated namespace of the container C1 on which the process p1, which triggered the policy, was executed. "Msg" corresponds to an additional text message describing the attack. An example of how this signal could be written is: "1644824642, 192.168.1.152, 4026532216, CVE-2021-3156, Attempt to exploit CVE-XXXX-XXXX blocked".

[0095] During the F_E2 step of sending to the Cnode security management server, the MDET n module may optionally enrich the message described above with context information to more precisely characterize the attacked container (e.g., container image name, main process name, container startup time), to form the Log i message.

[0096] The Log i message sent during the F_E2 step is received by the CNode security management server during the E_R step.

[0097] During step E_A, a signal representing this Log i message is added to a list. This signal can, for example, be a copy of the Log i message, or a compressed version of this message.

[0098] The CVE-2021-3156 vulnerability serves as an example of how a mitigation policy is implemented. This CVE vulnerability, which affects the sudo command, is particularly critical given its widespread use in numerous environments. When a command is executed with sudo, the command arguments are first concatenated, and metacharacters are escaped with a backslash (for example, "\" becomes "\\"). When a special character, such as [, {, (, \, or ^, is interpreted as a normal character rather than a special character, it can be preceded by a backslash \. This is called escaping a character.

[0099] In particular, the escaping described here is not performed when sudo is executed via the symbolic link sudoedit -s. As a result, if an argument of the sudoedit command ends with a single backslash, the arguments not being escaped by sudo, the program will copy characters outside the limits of the memory buffer, which will cause a buffer overflow.

[0100] A mitigation policy attached to the kernel function oper_exec(), triggered by launching the execution of a binary, can mitigate the CVE-2021-3156 vulnerability by detecting and blocking any attempt to execute the sudoedit command with an argument ending with a single backslash.

[0101] An example of an executable code snippet in eBPF (Extended Berkeley Packet Filter) for such a mitigation policy is shown in Appendix 1. In this code snippet, the first call to the STRING_HELPER function checks if the executed command is sudoedit. The second call checks if an argument ends with a single backslash. If the sudoedit command is executed with a single backslash, then the command execution is aborted (with the "RET_DENIED" statement); otherwise, the command is executed (with the "RET_ALLOWED" statement).

[0102] In this example, the STRING_HELPER function is a support function required for the execution of the mitigation policy. It can be loaded onto the KER n kernel as described later.

[0103] Appendix 2 presents an executable code snippet in eBPF for a mitigation policy that sends a message to userspace if the `sudoedit` command is executed with a single backslash. This message indicates that the mitigation policy has detected this attack. This code snippet can be added to a line preceding the `return RET_DENIED` statement in the code snippet presented in Appendix 1.

[0104] There [ Fig.2 ] represents a set consisting of a CNode security management server, two computers EQ 1 and EQ 2 and an SRV SEC security server.

[0105] The CNode security management server is equipped with a MIDA module implementing the identification process according to one embodiment of the invention. It is also equipped with means for communication with computers and a COM module for communication with a user, for example, an administrator of the computer network.

[0106] Each computer EQ 1 and EQ 2 is equipped to implement the detection method according to an embodiment of the invention. For clarity, the details of computer EQ 2 are not detailed on the [ Fig.2 ], but this one, like the EQ 1 computer, includes the components to implement the process of detecting computer attacks.

[0107] The EQ 1 computer includes a SYS 1 software system and hardware components, including in particular: a processor 10, a RAM type random access memory 11, a ROM type read-only memory 12, communication means 13 and non-volatile rewritable memory, for example a hard disk 14.

[0108] The communication means 13 are configured to communicate with the SRV SEC security server and the CNode security management server.

[0109] The SERV SEC server and other means used in this example to implement the F_I installation step of a mitigation policy are shown below.

[0110] This SERV SEC security server includes a database containing a set of CVE vulnerability identifiers and, associated with each of these vulnerability identifiers (ID CVEi), the ID Fi of a program description file (PG i) configured to run in a computer's kernel and to implement a mitigation policy capable of mitigating the vulnerability of ID CVEi. The description file identified by ID Fi is represented on the [ Fig.4 and is described later.

[0111] PG i programs can be downloaded by the EQ i equipment from the SERV SEC security server. For simplicity, such a PG i program implementing a mitigation policy is called a mitigation policy.

[0112] A CVEi vulnerability ID identifier is, for example, in the form CVE-AAAA-IIII, where AAAA is the year of publication and IIII is a unique number.

[0113] In the embodiment described here, the PG i mitigation policies downloadable from the SERV SEC security server are source files in eBPF language, denoted PG s< i .

[0114] In another embodiment described here, the PG i mitigation policies downloadable from the SERV SEC security server are object files denoted PG O< i obtained by compiling PG S< i source files in eBPF language.

[0115] In the embodiment described here, the description files are in JSON format (in English, "JavaScript Object Notation").

[0116] In the implementation example described here, the ID Fi description file for a PG i mitigation policy includes: in a "VUL ID" field, the CVEi ID identifier of the vulnerability that this policy can mitigate; and in a "META_PG" structure of the metadata of the PG i mitigation program.

[0117] In the embodiment described here, the metadata of the PG i mitigation program includes: a metadata "NP" corresponding to the name of this program PG; and at least one metadata "HK" corresponding to a trigger point (in English "hook") of this program.

[0118] In the embodiment described here, a mitigation policy PG i can call upon at least one support function (or dependency, in English "helper") HLP i,j.

[0119] In the implementation example described here, when a policy PG i calls at least one support function HLP i,j: The ID Fi description file contains, in a "META_HLP" structure, metadata for this HLP i,j support function; and these HLP ij support functions can be downloaded from the SERV SEC security server.

[0120] In the embodiment described here, the META_HLP metadata of an HLP support function i,j includes: a metadata "NH" corresponding to the name of this support function; a metadata "HSH" corresponding to a hash of this support function; and a metadata "EP" corresponding to an entry point of the function.

[0121] The SYS 1 software system comprises a kernel or operating system KER 1, and a user space USR 1. In the embodiment described here, the KER 1 operating system is of the Linux type (registered trademark).

[0122] In the embodiment shown in the [ Fig.2 ], the MDET 1 detection module includes a MINST 1 installation sub-module. This MINST sub-module is configured to implement the F_I installation step of the detection method according to the invention, the main steps of which are represented in flowchart form in the [ Fig.3 ].

[0123] In the example described here, the USR 1 user space contains: a root process p0 and a container C1 associated with user-level rights created by the root process p0; and an administration tool ADM 1 associated with administrator-level rights.

[0124] In this example, launching the execution of a vulnerable fc1 function (e.g., sudoedit) causes the execution of the exec function in userspace USR n, which in turn launches the execution of the oper_exec function to be executed in the KER 1 kernel.

[0125] The vulnerable function to protect fc1 is, for example, the sudoedit function mentioned above.

[0126] A CVE vulnerability such as CVE-2021-3156 described earlier can be detected at the LSM (Linux Security Module) level, triggered by the execution of the fc1 function. In this case, a central administrator can perform the E_E step of sending a signal received by the kernel of both computers EQ1 and EQ2, or only one of the two computers. As described earlier, in this embodiment, this signal includes a vulnerability identifier. This identifier enables the F_I installation step.

[0127] There [ Fig.3 ] represents a particular way of implementing the installation step F_I of the detection process. In this example, the installation F_I is implemented by a MINST n sub-module of the EQ n computer installation.

[0128] This particular method is described in the French patent application filed on 02 / 03 / 2021 under number 2102026.

[0129] This describes the F_I installation step for a computer EQ n, which can designate one of the computers EQ 1 and EQ 2 represented on the [ Fig.2 ].

[0130] During a substep F10 of the installation step F_I, the MINST installation submodule n sends a REQ request to the SRV SEC server, this REQ request containing the vulnerability identifier ID CVEk corresponding to the signal sent E_E by the security management server and received (F_R) in the user space USR n of the computer EQ n.

[0131] During a substep F20, the MINST installation submodule n receives, in response to the REQ request, the description file whose ID Fk identifier is associated with the vulnerability identifier ID CVEk in the SRV SEC security server database BD.

[0132] This ID Fk description file is represented at the [ Fig.4 ].

[0133] In the implementation example described here, the ID Fk description file contains: in the "VUL ID" field, the CVEk ID of the vulnerability; in the "META_PG" structure, the metadata of a PGk policy for mitigating the CVEk ID vulnerability; and in the "META_HLP" structure, the metadata of two support functions HLPk1 and HLPk2 called by the PGk policy.

[0134] In the example of the [ Fig.4 ], the META_PG metadata for the PG k mitigation program includes: the metadata “NP” corresponding to the PG k name of this program; and the metadata “HK” corresponding to the trigger point of the PG k program constituted here by the call of the oper_exec function, which corresponds for example to the execution of a binary.

[0135] In the example of the [ Fig.4 ], the META_HLP metadata of the HLPk1 support function includes: the metadata “NH” corresponding to the HLPk1 name of this support function; the metadata “HSH” including a hash “a0...65f” of this support function; and the metadata “EP” corresponding to a DYNFUN entry point in this support function, for example 4.

[0136] In the example of the [ Fig.4 ], the META_HLP metadata of the HLPk2 support function includes: the metadata “NH” corresponding to the HLPk2 name of this support function; the metadata “HSH” including a hash “c7...409” of this support function; and the metadata “EP” corresponding to a DYNFUN entry point in this support function; for example 2.

[0137] During a substep F30 of the installation step F_I, the MINST n installation submodule checks whether the HLPk1 and HLPk2 support functions required for the execution of the PG k mitigation policy and identified in the ID Fk description file received in substep F20 are already installed in the KER n kernel.

[0138] In the implementation described here, the MINST n module performs this check through a kernel interface of the KER n kernel. This operation can be performed by querying a virtual filesystem, for example similar to the Sysfs system described in particular in the Linux manual https: / / man7.org / linux / man-pages / man5 / sysfs.5.html.

[0139] In practice, generic support functions that can be called by many mitigation programs can be pre-installed in the KER n kernel.

[0140] In the implementation example described here, the HLPk1 and HLPk2 support functions are already installed in the KER n kernel and the result of the F30 test is positive.

[0141] During substep F40, the MINST n installation module downloads the mitigation program PG k identified in the ID Fk description file received in substep F20. In the embodiment described here, this download is performed from the SRV SEC security server.

[0142] In the embodiment described here, this program (denoted PG S< k ) is downloaded as source code in eBPF format.

[0143] During a substep F50, the MINST n installation module compiles the PG k mitigation program.

[0144] During a substep F60, the mitigation program PG k is linked with an HDF header file using a linking mechanism, to obtain an executable mitigation program PG E< k . In the embodiment described here, this HDF header file is stored in rewritable non-volatile memory 14 ([ Fig.2 ]).

[0145] This HDF header file is updated every time an HLPk1 and HLPk2 support function is installed in the KER n kernel.

[0146] There [ Fig.8 ] illustrates an example of an HDF header file that might contain, assuming that only the HLPk1 and HLPk2 support functions are installed in the KER n kernel and that the HLPk1 function was installed before the HLPk2 function: a first line L1 added at the time of installation of the HLPk1 support function in the KER n kernel; and a second line L2 added at the time of installation of the HLPk2 support function.

[0147] Each line L1, L2 can contain: the string of characters "#define ___ID_", concatenated to the name of the support function, i.e. to the string of characters "HLPk1", "HLPk2", concatenated to the character "_", concatenated to the hash of the support function, namely in this example "a0...65f" for line L1 and "c7...409" for line L2, concatenated to the string of characters "__", concatenated to a number corresponding to a position index of the support function in the kernel memory KER n, 0 for line L1 and 1 for line L2.

[0148] The HDF header file may contain, after all the L1, L2, ... lines corresponding to each of the support functions installed in the KER n kernel, a line: # define fnsup_stat(fs_id, h, pe_id, arg) fnsup_dyn(__ID_##fs_id##_##h##__, pe_id, arg)

[0149] A person skilled in the art understands that if, for example, the mitigation file PG k contains in its source code the instruction fnsup_stat(HLPk1, a0...65f, 4, arg), the F60 linking substep translates this instruction: firstly, using fnsup_dyn(__ID_HLPk1_a0...65f__, 4, arg), then secondly, using fnsup_dyn(0, 4, arg), because, on line L1, __ID_HLPk1_a0...65f__ is defined as 0 where 4 corresponds to the entry point to be called in the support function HLPk1.

[0150] The executable form of the mitigation policy PG k, in binary, is stored in non-volatile memory 14 of the computer EQ n for installation in a ZPS area of ​​the kernel KER n during a substep F70 described later.

[0151] In the implementation described here, the `fnsup_stat` function is a static function that acts as a proxy for calling the support functions installed in the KER n kernel. In the implementation described here, this function has three parameters: an identifier of the support function fs_id, valued at "0" in this example; an entry point pe_id in the support function, valued at 4 in this example; and arguments valued here at arg.

[0152] According to this embodiment of the invention, when the mitigation programs are loaded into the kernel (substep F70 described later), a memory space is reserved for them, and the address of this memory space is associated with the fs_id identifier of the support function in a TB table of the kernel KER n.

[0153] In the example of the [ Fig.5 ] which illustrates a KER n kernel of an EQ n computer, the KER n kernel TB table illustrates the situation in which the PG k mitigation program is installed at address @PG k, with a support function identifier set to 0 so that the execution of the instruction fnsup_dyn(0, 4, arg) triggers the execution of the PG k mitigation policy at entry point 4, with the arguments arg.

[0154] Back to the F30 test ([ Fig.3 ]), if it turns out that at least one HLPk1 and HLPk2 support function identified in the description file is not installed in the KER n kernel, the result of the F30 test is negative, and this support function must be downloaded (step H10) from the SEC SRV server and installed (step H20) in the ZPS area of ​​the KER n kernel represented on the [ Fig.5 ].

[0155] In the embodiment described here, the support functions are downloaded as object code and intended to be linked with the object code of the mitigation policy.

[0156] These download steps are performed by a module in the USR n user space which has administrator rights.

[0157] Once all the support functions needed to execute the PG k mitigation policy are installed in the KER n kernel, this file can be compiled (substep F50), linked (substep F60) and in turn loaded into the kernel.

[0158] In the embodiment described above, the mitigation program is downloaded as source code. Alternatively, the PG k mitigation program is downloaded as object code (denoted PG O< k), and the F50 compilation substep is not required. In one embodiment of this variant, compiling the mitigation program into source code uses the IF FK description file of the [ Fig.4 In addition to the PG O<k object code, it generates an array with one cell for each support function called by this mitigation policy. The kth cell of this array is reserved to contain the fs_id of the kth support function, taken in the order of the ID Fk description file. This array is downloaded along with the PG O<k object code, during step F40. At linking time (substep F60), each k cell of the array is filled with the HLP k,1 of the kth support function.

[0159] It is important to remember that in this example, the PG k mitigation policy aims to mitigate and detect the vulnerability exploiting the call of the fc1 function by a process.

[0160] To execute the mitigation policy, and in the embodiment described herein, the invention implements the securing process described in document [1].

[0161] This security process is shown on the [ Fig.7 ].

[0162] In the embodiment described here, processes in user space USR n are isolated using a namespace mechanism. For example, the Linux operating system provides several namespaces (e.g., Network, IPC, PID, User) that can be used to isolate processes within a mechanism that defines process sets, so that processes in a given set cannot see the resources used by another process set.

[0163] In the example described here: The root process p0 is associated with different namespaces respectively: ENIPC0 (for IPC), ENIPD0 (for PID), ENUser0 (for User); the processes of container C1, in this case process p1, are associated with different namespaces: ENIPC1, ENIPD1, ENUser1.

[0164] In the example described here, the process p1 calls the function fc1 to be protected, the execution of which calls another function exec running in user space USR n.

[0165] In the embodiment described here, the file opening operation oper_open() and the function execution operation oper_exec() are considered to be sensitive operations.

[0166] In the example of the [ Fig.2 The process p1 of container C1 calls: the open() system call for opening a file which generates, during its execution, the sensitive operation oper_open(); and the exec() system call for executing a binary which generates, during its execution, the sensitive operation oper_exec().

[0167] In the example of the [ Fig.2 ], the process p0 does not call the functions exec(), open().

[0168] In accordance with the mechanism described in document [1] and represented on the [ Fig.6 ], the p0 and p1 processes are also associated with an ENSECURE namespace dedicated to security management.

[0169] In the embodiment described here, the process p0 is associated with the security management namespace ENSECURE0 and the container C1 is associated with the security management namespace ENSECURE1.

[0170] There [ Fig.6 ] represents a TABPID table of processes stored in the KER n kernel. In the KER n kernel, a process consists of a structure with several fields to manage its lifecycle such as its PID identifier, its flags, its stack, and an nsproxy field which contains pointers to namespaces.

[0171] In particular, the nsproxy field contains an ENSECURE pointer to the security management namespace associated with this process. This namespace defines a data structure that includes, among other things, the mitigation policy.

[0172] A process's ENSECURE namespace contains a link to the ENSECURE namespace of its parent namespace. In the example described here, ENSECURE1 associated with container C1 points to the ENSECURE0 namespace of process p0.

[0173] The ENSECURE namespaces therefore form a tree.

[0174] As is known to those skilled in the art, a process can change namespaces to join the namespace of one of its child processes, for example by using the unshare() command.

[0175] From the user space USR n, it is possible to access the identifier of a namespace, but it is not possible to modify its structure. This characteristic advantageously prevents any modification or deactivation of a security or mitigation policy by a container.

[0176] In the example implementation described here, it is assumed that the process p0() has defined a mitigation policy PG k to secure calls to the sensitive function execution operation oper_exec(). It is assumed that it has not defined a security policy to secure calls to the sensitive file opening operation oper_open().

[0177] In the implementation example described here, it is assumed that container C1 has not defined its own security policy to secure calls by its processes, in this case p1, to the sensitive binary execution operation oper_exec(), in addition to the PG k policy defined by process p0.

[0178] We now consider the context in which the PG ka mitigation policy was generated by compilation and linking during substeps F50 and F60 of the F_I installation step. The PG k mitigation program stored in non-volatile memory 14 must be loaded into the ZPS area of ​​the KER n kernel security policies.

[0179] In the implementation of the F_I installation step described here, the MINST n installation submodule includes load_ps() instructions to load (substep F70) a mitigation program as a binary-compiled eBPF file into the ZPS area of ​​the KER n kernel. This load_ps() function opens the eBPF file located in non-volatile memory 14 and copies it to an interface with the KER n kernel. As described previously, this step includes allocating memory space in the ZPS area for this mitigation function and associating the address of this memory space with a support function fs_id in a TB table of the KER n kernel.

[0180] In the embodiment described here, this write to the kernel interface triggers an event to store the mitigation program in the namespace of the root process p0.

[0181] In the embodiment described here in connection with the [ Fig.5 ], the KER n kernel includes a Linux Security Modules security control infrastructure (ICS), a Linux Security Management Module (LSM1), and possibly at least one other LSM2 security module, for example, a SELinux module or an AppAmor module.

[0182] In the implementation example described here, the KER n kernel includes a control table TABCTR which defines, for each sensitive OPS operation (opening a file, executing a binary, ...) whether the LSM1 security module wants to control these sensitive operations or not.

[0183] In the verification example described here, it is assumed that the LSM1 security module only wants to verify the sensitive operation of executing a binary oper_exec().

[0184] There [ Fig.7 ] represents in flowchart form the main steps of a security process implemented by the GAS system call manager, the ICS security control infrastructure (LSM framework) and the LSM1 security module as shown in the [ Fig.5 ].

[0185] In the example implementation described here, the GAS system call manager determines, during an E10 step, whether a system call triggered by a user-space process must perform a sensitive OPS operation. If so, it triggers the ICS security control infrastructure of the KER n kernel.

[0186] The ICS infrastructure determines whether the sensitive OPS operation is listed in the TABCTR table.

[0187] In the implementation described here, if a process attempts to perform the sensitive operation of opening a file (oper_open()) by calling the open() function, the result of the determination step is negative because this sensitive operation is not checked by the LSM1 security module. However, this operation can be checked by the LSM2 security module, for example, SELinux and an AppAmor module.

[0188] When process p1 calls the exec function, the ICS infrastructure determines that this operation is listed in the TABCTR table and it triggers the execution of the LSM1 security module during an E20 step.

[0189] During an E30 step, the LSM1 security module determines the namespace associated with the current process that initiated the call. It uses the current process from the TABPID process table for this purpose. In this case, it is process p1.

[0190] The LSM1 security module then loops through the current process's namespace policies related to that sensitive operation. In one particular embodiment, the LSM1 security module then loops through the policies of its ancestor namespaces, if any exist.

[0191] During an E40 step, the LSM1 security module determines whether the current namespace has defined one or more security policies to verify the validity of the sensitive operation.

[0192] This is the case if the exec() function for executing a binary was called by the process p1.

[0193] If so, the relevant security module LSM1 executes during an E50 step the security policy(ies) defined in the ENSECURE security management namespace of the current process for this sensitive operation.

[0194] In this case, during the first iteration, no PG k mitigation policy is executed.

[0195] In the embodiment described here, a mitigation policy, and in particular the PG k mitigation policy, returns a negative RET result if it detects a security problem (for example, reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem.

[0196] If this RET value is positive, the security module determines, if it exists, the parent namespace of the current process namespace (step E60) and the loop repeats.

[0197] In this case, during the second iteration, the PG k mitigation policy of the ENSECURE0 namespace of process p0 is executed and the open_exec() function is blocked.

[0198] The LSM1 security module records this blockage in a log file FLOG ( Fig.5]) of the KER n kernel during an E70 step and sends a negative RET result to the ICS security control infrastructure. This FLOG log file can be analyzed by the administrator using the ADM administration tool.

[0199] In another case where all security policies (in this example, only the PG k mitigation policy is installed) of the entire namespace tree have been executed with a positive RET result, the LSM1 security module sends a positive RET result to the ICS security control infrastructure (test E90).

[0200] In the embodiment described here, if the ICS security control infrastructure receives a positive RET result, it does not trigger any particular action and the system call is executed, unless an action is triggered by another LSM2 security module, for example, an SELinux module or an AppAmor module.

[0201] In the embodiment described here, if the ICS security control infrastructure receives a negative RET result, the ICS security control infrastructure triggers an AS security action during an E80 step. This action may consist of destroying the process that initiated the call and raising an alert in the FLOG log file. [1]: Snappy: Programmable Kernel-Level Policies for Containers, Maxime Bélair, Sylvie Laniepce, Jean-Marc Menaud, March 2021, ACM ISBN 978-1-4503-8104-8 / 21 / 03

[0202] The appendices are presented below. [Appendix 1]

[0203] if (secuhub_helper(STRING_HELPER, HASH_STRING, STRING_BINNAME, {(void*)0, " / usr / bin / sudo"}) == 1 && secuhub_helper(STRING_HELPER. HASH_STRING, STRING_REGEX, {(void*)-1, "^(.*[^\\])?\\$"}) == 1) return RET_DENIED; return ALLOWED [Appendix 2]

[0204] secuhub_helper(STRING_HELPER, HASH_STRING, ALERT_ONCE, {PR_ERR, "Attempt to exploit CVE-2021-3156 blocked"});

Claims

1. Method for detecting an attempted cyber attack, which method is implemented by a computer (EQn) of a pool of computers, said attack exploiting a vulnerability (CVEk) of a function to be protected (fc1) being executed in a process (p1) of a user space (USRn) of said computer (EQn), launch of execution of said function to be protected (fc1) resulting in execution, prior to said attack, of a kernel function (oper_exec), said method comprising steps of: - reception (F_R), from a security management server (CNode), of a mitigation policy identifier (IDCVEk); - installation (F_I), in said kernel (KERn), of a mitigation policy (PGk) corresponding to said mitigation policy (PGk) identifier; - execution (F_Ex) of said mitigation policy (PGk) in said kernel (KERn), said mitigation policy (PGk) being associated with said kernel function (oper_exec) and being loaded into a namespace (ENSECURE1) of the kernel associated with said process (p1) and dedicated to security; and, if said mitigation policy detects during its execution an attack vector addressed by said policy and targeting said function to be protected (fc1): - sending (F_E) to said security management server (CNode) a message (Logi) containing a datum representative of said process (p1).

2. Method according to Claim 1, characterized in that execution of said function to be protected (fc1) results in execution of another function (exec) of said user space (USRn) which results in execution of said kernel function (oper_exec).

3. Method according to Claim 1 or 2, wherein said mitigation policy (PGk) is loaded into a namespace (ENSECURE0) dedicated to security and associated with a root process of said computer (EQn).

4. Method according to any of Claims 1 to 3, wherein said security server (CNode) is configured to send the mitigation policy identifier to a plurality of computers of said pool of computers.

5. Method according to any of Claims 1 to 4, wherein said installation step (F_I) comprises substeps of: - sending (F10) a request (REQ) containing said mitigation policy identifier (IDCVEk) to a security server (SRVSEC); - obtaining (F20), in response to the request (REQ), a description file (IDFk) describing said mitigation policy (PGk); - obtaining (F40, F50) an object code (PGOk) of the mitigation policy (PGk) identified in said description file (IDFk); - generation (F60) of an executable code (PGEk) of said mitigation policy (PGk) from said object code (PGOk); and - installation (F70) of the executable code (PGEk) in said kernel (KERn).

6. Method according to any of Claims 1 to 5, wherein said step of sending (F_E) said at least one message (Logi) to the security management server (CNode) is implemented from said user space (USRn) in response to said kernel (KERn) sending (F_E1) a signal to said user space (USRn) to signal said detection of said attack vector.

7. Method according to any of Claims 1 to 6, wherein said at least one message (Logi) contains at least one piece of information among: - an identifier (IPn) of said computer (EQn); - a datum representative of said namespace (ENSECURE1) associated with said process (p1) and dedicated to security; - an identifier of said vulnerability (CVEk); - a time at which the execution of the mitigation policy was triggered.

8. Identification method implemented by a security management server (CNode) to identify an attempted cyber attack on at least one computer (EQn) of a pool of computers, said attack exploiting a vulnerability (CVEk) of a function (fc1) to be protected being executed in a user space of the computer, said method comprising steps of: - sending (E_E) to said at least one computer an identifier of said mitigation policy (PGk); - reception (E_R), from said at least one computer (EQn), of a message (Logi) containing a datum representative of a process (p1) being executed in said user space, when an attack vector targeting said function to be protected (fc1) has been detected, in the kernel of the computer, by the execution of a mitigation policy (PGk) loaded into a namespace (ENSECURE1) of the kernel dedicated to security and associated with this process; - addition (E_A) to a list of a datum representative of said message (Logi).

9. Method according to Claim 8, comprising a step of sending said mitigation policy identifier to a plurality of computers of the pool of computers.

10. Module (MDETn) for detecting an attempted cyber attack in a computer (EQn) of a pool of computers, said attack exploiting a vulnerability (CVEk) of a function to be protected (fc1) being executed in a process (p1) of a user space (USRn) of said computer (EQn) , launch of execution of said function to be protected (fc1) resulting in execution, prior to said attack, of a kernel function (oper_exec), said module comprising: - a sub-module for reception, from a security management server (CNode), of a mitigation policy identifier (IDcvek); - a sub-module for installation, in said kernel (KERn), of a mitigation policy (PGk) corresponding to said mitigation policy (PGk) identifier; - an execution sub-module (M_Ex) configured to execute said mitigation policy (PGk) in said kernel (KERn), said mitigation policy (PGk) being associated with said kernel function (oper_exec) and being loaded into a namespace (ENSECURE1) of the kernel associated with said process (p1) and dedicated to security; - a sending sub-module (M_E) configured to send to said security management server (CNode) a message (Logi) containing a datum representative of said process (p1), said sending sub-module (M_E) being configured to send said message if said mitigation policy detects an attack vector addressed by said policy and targeting said function to be protected (fc1).

11. Identification module (MIDA) able to be implemented by a security management server (CNode), said module (MIDA) being configured to identify an attempted cyber attack on at least one computer (EQn) of a pool of computers, said attack exploiting a vulnerability (CVEk) of a function (fc1) to be protected being executed in a user space of said computer, said module (MIDA) comprising: - a sub-module for sending to said at least one computer an identifier of said mitigation policy (PGk); - a reception sub-module (M_R) configured to receive, from said at least one computer (EQn), a message (Logi) containing a datum representative of a process (p1) being executed in said user space, when an attack vector targeting the function to be protected has been detected, in the kernel of the computer, by the execution of a mitigation policy (PGk) loaded into a namespace (ENSECURE1) of the kernel dedicated to security and associated with the process (p1); - an addition sub-module (M_A) configured to add to a list a datum representative of said message (Logi).

12. Computer program comprising instructions that, when the program is executed by a computer, cause the latter to implement a method according to any of Claims 1 to 9.

13. Recording medium, readable by a computer (EQn) and / or a server (CNode), for recording a computer program comprising instructions for the execution of the steps of a method according to at least one of Claims 1 to 9.