Script Whitelisting at Dual Interception Points for Linux Malware
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing whitelisting methods fail to effectively block script-based malware, particularly in Linux systems, as they do not provide protection for individual scripts without shebang or file extensions, leaving systems vulnerable to malicious script execution.
Innovation Solution
A whitelisting method that checks script files at two interception points: a first interception point before launching a startup script file and a second interception point before importing a module script file, using a whitelist to verify the legitimacy of these files.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing whitelisting methods (Application Whitelisting, Kaspersky, Fapolicyd) are used, then general malicious program protection is provided, but script-based malware without shebang or file extensions cannot be detected and blocked
Solution Approach 1:
The patent segments the script execution process into multiple interception points: before script execution (first interception point) and before module loading (second interception point). This allows independent verification of each component, enabling detection of malicious scripts even without traditional file extensions or shebang lines.
Solution Approach 2:
The patent implements preliminary verification by checking whether scripts and modules exist in the whitelist before execution or loading occurs. This advance verification prevents malicious scripts from executing, addressing the limitation of existing methods that only provide post-execution protection or configuration-level control.
2Reliability
If Kaspersky provides protection for the entire configuration of the interpreter process, then configuration-level security is improved, but individual script protection within the application control function is not provided
Solution Approach 1:
The patent divides the interpreter process protection into two independent verification mechanisms: a first verification mechanism for startup scripts before execution, and a second verification mechanism for module scripts before loading. This segmentation allows individual script protection without complicating the overall interpreter process control.
Solution Approach 2:
The patent introduces a whitelist as an intermediary verification mechanism between the interpreter process and the scripts/modules. This intermediary layer provides individual script verification while maintaining the simplicity of the overall process control architecture.
3Ease of operation
If Fapolicyd and similar software are used, then system-level policy control is provided, but detection of malicious scripts without shebang is not possible
Solution Approach 1:
The patent performs preliminary verification by checking the whitelist before script execution, enabling detection of malicious scripts without relying on shebang lines or traditional file extensions. This advance check prevents undetectable scripts from executing while maintaining ease of system-level policy control.
Solution Approach 2:
The patent replaces traditional mechanical detection methods (relying on shebang lines and file extensions) with a whitelist-based verification mechanism. This substitution enables detection of scripts without traditional identifiers while maintaining the simplicity of system-level policy control.
4Adaptability or versatility
If Ivanti products are used, then application control is provided, but detection of malicious scripts without file extensions is not possible
Solution Approach 1:
The patent segments the verification process into two independent stages: verification of startup scripts before execution and verification of module scripts before loading. This segmentation enables detection of scripts without file extensions while maintaining comprehensive application control capability.
Solution Approach 2:
The patent introduces a whitelist intermediary that verifies scripts before execution and module loading before import. This intermediary mechanism enables detection of scripts without traditional file extensions while preserving the application control versatility of the system.
Data Source
AI summary
A whitelisting method for blocking script-based malware includes steps of: checking a command line of a process to confirm the process to launch a first interception point of a startup script file; checking whether the startup script file in a whitelist at the first interception point; determining that a test is passed when the startup script file exists in the whitelist, and launching the startup script file, wherein the startup script file at least includes a module script file; confirming the process to invoke a module loader to import and launch a second interception point of the module script file; checking whether the module loader is allowed to import the module script file, or is allowed to launch the module script file that has been imported by using the whitelist at the second interception point.