Whitelisting method for blocking script-based malware

Abstract

A whitelisting method for blocking script-based malware, comprising: checking a command line of a process to determine a first interception point where the process starts a startup script file; at the first interception point, detecting whether the startup script file exists in a whitelist; if the startup script file exists in the whitelist, determining that the detection is successful, and starting the startup script file; determining a second interception point where the process arouses a module loader to import a module script file; and at the second interception point, by means of the whitelist, detecting whether the module loader is allowed to import the module script file or whether the module loader is allowed to start the imported module script file.

Description

Whitelist method to block script-type malicious programs Technical Field

[0001] The present invention relates to a whitelist method, in particular to a whitelist method for blocking script-type malicious programs. Background Art

[0002] Currently, there are various whitelisting methods and software that can be used to help users block malicious programs in programs, such as Application Whitelisting (AWL), products developed by Kaspersky, Fapolicyd, and Ivanti.

[0003] Application whitelisting only protects against general malware. Kaspersky only protects the entire configuration of the interpreter process and cannot protect individual scripts within the application control function. Fapolicyd and similar software (such as Trellix) cannot detect malicious scripts without a shebang, and products developed by Ivanti cannot detect malicious scripts without file extensions.

[0004] In view of this, the market needs to provide a novel whitelist method that can meet users' needs for blocking various script-based malicious programs.

[0005] Summary of the Invention

[0006] The main purpose of the present invention is to provide a whitelist method for blocking script-based malware, which can detect and block the execution of script-based malware in a program.

[0007] To achieve the above objectives, the present invention provides a whitelist method for blocking script-type malicious programs, which mainly includes the following steps:

[0008] a) checking a command line (cmdline) of a process to determine a first interception point where the process starts a startup script file;

[0009] b) detecting, at the first interception point, whether the startup script file exists in a whitelist;

[0010] c) determining that the detection passes when the startup script file exists in the whitelist, and opening the startup script file, wherein the startup script file includes at least one module script file;

[0011] d) determining a second interception point at which the program invokes a module loader to import and open the module script file; and

[0012] e) At the second interception point, the module loader is detected through the whitelist to determine whether it is allowed to import the module script file, or whether it is allowed to open the imported module script file.

[0013] Compared to related technologies, the present invention can detect whether a file is a script type file when a program (such as an interpreter program) reads and opens a file, and determine whether the file exists in a whitelist, thereby effectively blocking the execution of script-type malicious programs. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG1 is an architectural diagram of a detection system according to the present invention;

[0015] FIG2 is a flow chart of a specific embodiment of the whitelist method of the present invention;

[0016] FIG3 is a flow chart of a specific embodiment of a method for detecting a first interception point according to the present invention;

[0017] FIG4 is a flow chart of a first specific embodiment of a method for detecting a second interception point according to the present invention;

[0018] FIG5 is a flow chart of a second specific embodiment of a method for detecting a second interception point according to the present invention.

[0019] Explanation of the accompanying figures: 1... Startup point interception program 2... Decoding program 3... Import point interception program 4... Module loading program 5... File execution program S21-S25... Whitelisting steps S31-S38... Detection steps S41-S47... Detection steps S51-S60... Detection steps DETAILED DESCRIPTION

[0020] A preferred embodiment of the present invention is described in detail below with reference to the accompanying drawings.

[0021] The present invention discloses a whitelist method (hereinafter referred to as the whitelist method in the specification) for blocking script-based malware. The whitelist method is mainly applied to Linux systems, but is not limited thereto.

[0022] Specifically, the whitelist method of the present invention can identify when a program is about to open or read a file, whether the program is about to launch an unapproved script or extract data from a pre-approved script. If the program is identified as launching an unapproved script, the script is compared with a whitelist to determine whether the program is permitted to launch the script. Thus, the whitelist can be used to block script-type malicious programs.

[0023] The whitelist method of the present invention can be primarily triggered at two interception points within a program: (1) a first interception point before the program opens a startup script file; and (2) a second interception point before the program continues executing the startup script file until the module loader is executed to import and open a module script file within the startup script file. The whitelist method of the present invention performs whitelist checks on script files (including startup script files or module script files) at both the first and second interception points to determine whether the program is allowed to import and open the script file.

[0024] First, please refer to Figure 1, which illustrates the architecture of the detection system of the present invention. In the embodiment of Figure 1, the whitelisting method of the present invention may include a startup interception program 1 for a first interception point, an interpreter 2 for opening a startup script file, an import interception program 3 for a second interception point, a module loader 4 for importing module script files, and a file execution program 5 for checking if the file passes the inspection.

[0025] Specifically, the user can use an electronic device such as a personal computer, a laptop, a cabinet server or a cloud server to execute the Linux system, and configure the corresponding firmware in the electronic circuit of the electronic device (such as a central processing unit or a microprocessor, etc.). Based on the functions that can be achieved by the electronic circuit in combination with the firmware, the electronic device can virtually divide the program code of the firmware into the above-mentioned programs 1-5. In other words, in the present invention, the above-mentioned programs 1-5 are all firmware programs. When any electronic device executes the firmware, the whitelist method of the present invention (including the various program steps shown in Figures 2 to 5) can be implemented through the programs 1-5.

[0026] In one embodiment, the interpreter 2, the module loader 4, and the file execution program 5 can be implemented by an interpreter program and its module loader, without limitation.

[0027] Please refer to Figure 1 and Figure 2 simultaneously, wherein Figure 2 is a flow chart of a specific embodiment of the whitelist method of the present invention. In one embodiment, the steps shown in Figure 2 are implemented by procedures 1-5 shown in Figure 1.

[0028] As shown in FIG2 , when a Linux system is about to execute a program, the program's cmdline is first checked through a startup point interception program 1 to determine the first interception point at which the program is about to open a startup script file (step S21). Specifically, the whitelist method of the present invention performs process cmdline hooking at the first interception point to check the startup script file before the program opens the startup script file.

[0029] After step S21, the startup point interception program 1 detects whether the startup script file to be launched is in the whitelist (step S22). In one embodiment, the whitelist is pre-established and records information such as the type, list, or file name of the script files that the program is allowed to launch, but is not limited to this.

[0030] In one embodiment, the program is an interpreter process used to open script-based files. The startup point interception program 1 directly checks in step S21 whether the command line of the interpreter program contains a corresponding instruction to open the startup script file, thereby confirming the first interception point before the interpreter program opens the startup script file, and performs a whitelist check on the startup script file at the first interception point.

[0031] If the startup interception program 1 determines that the startup script file is on the whitelist, it means that the startup script file is not a malicious program. At this time, the startup interception program 1 can determine that the startup script file has passed the detection, and the Linux system can then use the interpreter program 2 (such as the interpreter program) to launch the startup script file (step S23).

[0032] Once the program opens the startup script file, it will continue to execute it. This startup script file may need to further import a data file or import and open a module script file. In other words, this startup script file may contain at least one module script file. To prevent this module script file from being malicious and damaging the system after being imported, the whitelist method of the present invention also requires a second check at the second interception point.

[0033] As shown in FIG. 2 , after step S23 , the Linux system uses the import point interception program 3 to determine the second interception point where the program invokes the module loader to import and open the module script file (step S24 ).

[0034] Specifically, when the startup script file is continuously executed by the program until another file needs to be opened, the startup script file will request the interpreter program to open the file. At this time, the interpreter program needs to execute the module loader to import the file that is requested to be opened. In the present invention, the import point interception program 3 identifies the point when the program is about to execute the module loader as the second interception point, and at the second interception point, uses the whitelist to detect whether the module loader is allowed to import this module script file, or whether it is allowed to open the imported module script file (step S25).

[0035] In one embodiment, the whitelist method of the present invention performs module loader hooking at the second interception point to check the module script file before the module loader imports the module script file.

[0036] In another embodiment, the whitelist method of the present invention performs open function hooking at the second interception point to confirm whether the module loader is allowed to open the imported module script file by checking the module script file extension before the module loader opens the imported module script file through the open function (details will be described later).

[0037] In the present invention, when the import point interceptor 3 determines at the second interception point that the module loader can import the module script file, the Linux system then uses the module loader 4 to import the module script file. On the other hand, when the import point interceptor 3 determines at the second interception point that the module loader is allowed to open the imported module script file, the Linux system then uses the file execution program 5 to open the module script file.

[0038] It is worth mentioning that depending on the type of interpreter, either an extension-restricted module loader or an extension-agnostic module loader may be used. For example, if the interpreter is a shell script, Bash script, or JavaScript (with CommonJS), an extension-agnostic module loader will be used; if the interpreter is Python, Perl, PHP, Lua, or Javascript (with ES modules), a module loader with extensions such as .py or .pm will be used.

[0039] In the present invention, if the program uses a module loader that does not restrict file extensions, the import point interception program 3 needs to directly determine at the surface level whether the module loader is allowed to import this module script file; if the program uses a module loader that restricts file extensions, the import point interception program 3 can determine at the bottom level whether this module script file is allowed to be opened after the module script file is imported (detailed description later).

[0040] The various types of the above-mentioned programs are commonly used technical means in the present invention and will not be described in detail here.

[0041] Please also refer to Figure 3, which is a flowchart of a specific embodiment of the first interception point detection method of the present invention. Figure 3 is used to specifically illustrate how the startup point interception program 1 determines whether the program can open the startup script file at the first interception point.

[0042] As shown in FIG3 , first, the startup point interception program 1 detects the instruction line of the program to obtain the program's invocation name (step S31), and determines whether the program is an interpreter program used to execute a script-based file (e.g., a startup script file) based on the invocation name (step S32).

[0043] If it is determined in step S31 that the program is not an interpreter program, then since it is not related to the script file of the blocking target, the startup point interception program 1 can directly determine that the test has passed (step S33) and end the whitelist method of the present invention.

[0044] If the program is determined to be an interpreter program in step S31, the startup point interception program 1 then checks the parameters of the interpreter program's command line (step S34) to determine whether the interpreter program will open a startup script file (step S35), thereby determining the first interception point. If the command parameters do not include a file parameter in step S35, it indicates that the interpreter does not need to open a script file. In this case, since the script file is not related to the blocking target, the startup point interception program 1 can directly determine that the test has passed (step S33), and the whitelisting method of the present invention ends.

[0045] Specifically, in step S34, the startup point interception program 1 can determine whether the interpreter program's command line parameters include the file path and file name of the startup script file. If the command line parameters include the file path and file name of the startup script file, the startup point interception program 1 can determine that the interpreter program will open the startup script file, thereby determining the first interception point (i.e., before the startup script file is opened).

[0046] After confirming that the interpreter program will open the startup script file, the startup point interception program 1 checks the whitelist (step S36) and determines whether the startup script file exists on the whitelist (step S37). If the startup script file exists on the whitelist, it means that the startup script file is not a malicious program, and the startup point interception program 1 determines that the test has passed (step S33). At this point, the interpreter program can open the startup script file.

[0047] If the startup script file is determined not to be in the whitelist in step S37, it indicates that the startup script file is likely a script-type malicious program. In this case, the startup point interceptor 1 blocks the startup script file (step S38), preventing the interpreter program from opening the startup script file according to the command line. This prevents the opening of a script-type malicious program and the resulting damage to the Linux system.

[0048] In one embodiment, each file (including startup script files) opened by the interpreter program has metadata. If a file is on a whitelist, the metadata for that file is assigned a whitelist tag. In this embodiment, the startup point interception program 1 checks the metadata of the startup script file and determines that the metadata contains a whitelist tag corresponding to the whitelist, then determines that the startup script file is on the whitelist.

[0049] In other embodiments, the whitelist may record information such as the types and file names of multiple program files that have been determined not to be malicious programs, and the startup point interception program 1 may determine that the startup script file exists in the whitelist when the type and file name of the startup script file match the type and file name of any program file recorded in the whitelist.

[0050] However, the above are only some specific implementation examples of the present invention, but are not limited thereto.

[0051] Please also refer to Figure 4, which is a flow chart of a first embodiment of the second interception point detection method of the present invention. Figure 4 is used to specifically illustrate how the import point interception program 3 determines whether the module loader can import the module script file at the second interception point.

[0052] As shown in Figure 4, after the interpreter program opens the startup script file, the interpreter program continues to execute the startup script file, and the import point interception program 3 continues to determine whether the interpreter program invokes the module loader (step S41), that is, the import point interception program 3 continues to determine whether the startup script file requests the interpreter program to import and open the module script file.

[0053] If the interpreter program does not invoke the module loader, it means that no other script files need to be imported and opened. When the interpreter program is to invoke the module loader, the import point interception program 3 first executes an additional checksum (step S42) and determines the second interception point (i.e., before the module loader imports the module script file).

[0054] In this embodiment, the interpreter program is an interpreter that uses a module loader that does not restrict file extensions, such as Bash script or Shell script, so the import point interception program 3 needs to detect the module script file to be imported at the surface level.

[0055] As is well known to those skilled in the art, the interpreter program provides an environment variable. In the present invention, this environment variable is edited and modified so that the interpreter program can enter the checker logic shown in FIG. 4 (i.e., a program for checking module script files). In step S42, the entry point interceptor 3 reads the environment variable in the interpreter program to determine whether the module loader has been invoked, and intercepts the module loading instruction or syntax to rewrite the module loader. Consequently, the interpreter program can subsequently execute a checksum based on the intercepted and rewritten module load, thereby performing a check.

[0056] After the checksum is executed, the module loader determines whether the module script file to be imported exists (step S43). If the module script file to be imported does not exist, there is no malware issue, and the import point interception program 3 can directly determine that the detection has passed (step S44), and the whitelist method of the present invention ends. If the checksum confirms that the module script file exists, the import point interception program 3 further checks the whitelist (step S45) and determines whether the module script file is on the whitelist (step S46).

[0057] If the module script file exists in the white list, it means that the module script file is not a malicious program, so the import point interception program 3 can determine that the test is passed (step S44). At this time, the interpreter program can import the module script file through the module loader.

[0058] If, in step S46, the module script file is determined not to be on the whitelist, it indicates that the module script file is likely a script-type malicious program. In this case, the import point interceptor 3 blocks the module script file (step S47), preventing the interpreter program from importing the module script file through the module loader. This prevents the interpreter program from importing malicious script files hidden in approved startup script files, potentially damaging the Linux system.

[0059] In one embodiment, the check code in step S43 mainly intercepts and rewrites the module import instruction or syntax (such as the source command of a shell script or the require syntax of JavaScript commonJS) of the module loader executed by the interpreter program to determine what the module script file is based on the content of the command and whether the module script file exists.

[0060] It is worth mentioning that the embodiment shown in FIG. 4 is an interception point executed at the program surface layer, so that detection can be performed before the module loader actually imports the module script file, and when it is determined that the module script file may be a malicious program, the import of the module script file is directly blocked.

[0061] Continuing with Figure 5, a flowchart of a second embodiment of the second interception point detection method of the present invention is provided. Figure 5 illustrates how import point interception program 3 determines, at the second interception point, whether the interpreter program can open the imported module script file. Compared to the embodiment shown in Figure 4, the embodiment of Figure 5 primarily executes at the program's underlying interception point and primarily checks the module script file before it is opened using the open function.

[0062] Specifically, the embodiment of Figure 5 is applied to an interpreter program of a module loader using a restricted file extension. Therefore, at the second interception point, the import point interception program 3 will first detect the instruction line of the interpreter program to obtain the calling name of the program (step S51), and determine whether the interpreter program is an interpreter program of a module loader using a restricted file extension through the calling name (step S52).

[0063] If it is determined in step S52 that the interpreter program does not use a module loader that restricts file extensions, then since the file extension of the script file to be opened cannot be determined, the import point interception program 3 can directly determine that the test has passed (step S53) and terminate the whitelist method of the present invention.

[0064] If it is determined in step S52 that the interpreter program uses a module loader with restricted file extensions (such as python, Perl, PHP, Lua or JavaScript with Es module), the import point interception program 3 checks the parameters of the startup call (open call) of the interpreter program (step S54) and determines it as the second interception point.

[0065] It's worth noting that in step S31 of Figure 3 , launch-point interceptor 1 checks the interpreter program's calling name at the surface level; in step S51 of Figure 5 , sink-point interceptor 3 checks the interpreter program's calling name at the bottom level. In one embodiment, after obtaining the interpreter program's calling name, launch-point interceptor 1 can pass this information from the surface level to the bottom level via a pass-by-value operation. In this case, sink-point interceptor 3 does not need to check the interpreter program's calling name again at the second interception point; that is, step S51 is not necessarily executed.

[0066] However, the above is only one specific implementation example of the present invention, but is not limited thereto.

[0067] In this embodiment, the sink point interception program 3 checks the parameters of the interpreter program's startup call to obtain information about the module script file being requested to be opened. This information determines whether the module script file exists and determines the second interception point (step S55). If the module script file being requested to be opened does not exist, then there is no malware issue, and the sink point interception program 3 can directly determine that the test has passed (step S53), terminating the whitelisting method of the present invention.

[0068] If the existence of the module script file is confirmed in the parameters of the startup call, the import point interception program 3 can further obtain the extension of the module script file from the parameters of the startup call (step S56), and determine whether the extension of the module script file matches the extension restricted by the module loader (step S57). In one embodiment, the extension restricted by the module loader can be, for example, the extension .py or .pyc of python, or the extension .pm of Perl, etc., but is not limited to this. If the extension of the module script file does not match the extension restricted by the module loader, it means that the module script file is not a restricted file type (that is, it is determined to be a data file required for the script, and the possibility of it being a malicious program is low), so the import point interception program 3 can determine that the detection has passed (step S53). At this time, the interpreter program can open the module script file through the module loader.

[0069] If the module script file's file extension matches the file extension restricted by the module loader in step S57, it means that the module script file belongs to a file type restricted by the module loader. At this time, the import point interception program 3 further checks the whitelist (step S58) and determines whether the module script file exists in the whitelist (step S59).

[0070] If the module script file exists in the whitelist, it means that although the module script file is restricted, it is not a malicious program, so the import point interception program 3 can determine that the test is passed (step S53). At this time, the interpreter program can open the module script file through the module loader.

[0071] If, in step S59, the module script file is determined not to be on the whitelist, it indicates that the module script file is likely a malicious script. In this case, the import point interceptor 3 blocks the module script file (step S60), preventing the interpreter program from opening the module script file through the module loader. This prevents the interpreter program from opening a malicious script file hidden in an approved startup script file, potentially damaging the Linux system.

[0072] The whitelist method of the present invention can detect whether the file to be imported / opened is a script type file at at least two interception points of a program, and determine whether the file exists in the whitelist, thereby blocking the execution of the script type malicious program.

[0073] The above description is only a preferred embodiment of the present invention, and does not limit the claims of the present invention. Therefore, all equivalent changes made by applying the content of the present invention are similarly included in the scope of the present invention and are hereby stated.

Claims

1. A whitelist method for blocking script-type malicious programs, comprising: Step a) checking the instruction line of the program to determine the first interception point of the program to start the startup script file; Step b) detecting at the first interception point whether the startup script file exists in the whitelist; Step c) judging that the detection is passed when the startup script file exists in the whitelist, and opening the startup script file, wherein the startup script file at least includes a module script file; Step d) determining a second interception point where the program starts a module loader to import and open the module script file; and Step e) at the second interception point, detecting through the whitelist whether the module loader is allowed to import the module script file, or whether it is allowed to open the imported module script file.

2. The whitelist method according to claim 1, wherein the step a) comprises: Step a1) checking the instruction line of the program to obtain the calling name of the program; Step a2) determining whether the program is an interpreter program used to open the startup script file based on the calling name; Step a3) when the program is the interpreter program, checks the parameters of the instruction line to determine the first interception point at which the program opens the startup script file.

3. The whitelist method according to claim 2, wherein the step a3) includes determining whether the parameters of the command line include the file path and file name of the startup script file, and determining that the program is to open the startup script file when the parameters of the command line include the file path and the file name, and determining the first interception point.

4. The whitelist method according to claim 1, wherein the startup script file has metadata, and step b) is to determine that the startup script file exists in the whitelist when the metadata of the startup script file contains a whitelist tag corresponding to the whitelist.

5. The whitelist method according to claim 1, wherein the step d) comprises: Step d11) determining whether the program invokes the module loader; Step d12) executes a check code and determines the second interception point when the program invokes the module loader.

6. The whitelist method according to claim 5, wherein the step e) comprises: Step e11) determining whether the module script file to be imported by the module loader exists by executing the check code at the second interception point; Step e12) checking the whitelist when the module script file exists; Step e13) when the module script file exists in the whitelist, judging that the detection is passed, and importing the module script file; and Step e14) blocks the module script file when the module script file does not exist in the whitelist.

7. The whitelist method according to claim 6, wherein the step d12) comprises: Step d121) when the program reads the environment parameters and invokes the module loader, the module loading instruction or syntax is intercepted and the module loader is rewritten; and Step d122) is for the program to execute the check code based on the module loader that has been intercepted and rewritten.

8. The whitelist method according to claim 7, wherein the step d) is to check the command of the program to invoke the module loader, and confirm what the module script file is and whether the module script file exists based on the content of the command.

9. The whitelist method according to claim 1, wherein the step d) comprises: Step d21) determining whether the program invokes the module loader, wherein the module loader is a module loader that restricts file extensions; and Step d22) checks the parameters of the startup call when the program invokes the module loader to confirm the module script file to be opened, and determines the second interception point.

10. The whitelist method according to claim 9, wherein the step e) comprises: Step e21) determining at the second interception point whether the module script file to be opened by the module loader exists; Step e22) when the module script file exists, determining whether the file extension of the module script file matches the file extension restricted by the module loader; Step e23) checking the whitelist when the file extension of the module script file matches the file extension restricted by the module loader; Step e24) when the module script file exists in the whitelist, judging that the detection is passed, and starting the module script file; and Step e25) blocks the module script file when the module script file does not exist in the whitelist.

11. The whitelist method according to claim 9, wherein the step d22) further comprises: Step d221) when the program invokes the module loader, checking the calling name of the program to confirm whether the module loader is the module loader that restricts file extensions; and Step d222) checks the parameters of the startup call of the program when determining that the module loader is the module loader that restricts file extensions.

12. The whitelist method according to claim 10, wherein the step e22) is to check the parameters of the startup call of the program to obtain the extension of the module script file, and compare the extension of the module script file with the extension restricted by the module loader.

Images