Skip to content

Event: "global_shlib_modification"

Quick Explanation

The global_shlib_modification recipe detects modifications to a crucial configuration file used by the dynamic linker to preload shared libraries during system startup. Such modifications are a common persistence technique, enabling unauthorized code to execute covertly during boot or logon processes. Detected during a CI/CD pipeline pull request, this suggests potential malicious code injection, posing significant risks to both CI and production environments. If left undetected, it could lead to persistent unauthorized access, severely compromising system integrity.

More Information

Information

  1. Description: Global shared library injection
  2. Category: Persistence
  3. Method: Boot or Logon Autostart Execution
  4. Importance: Critical

Analysis of the Event

This security event involves detecting a shared library injection through the modification of the ld.so.preload file located in the /etc directory. The ld.so.preload file is utilized by the dynamic linker to preload shared libraries during the boot or logon process, making it a prime target for persistence mechanisms. Malicious actors can exploit this to load unauthorized code early in the system’s startup sequence. This technique is often used for stealthy and persistent attacks, allowing malicious code to execute without direct user or administrator interaction.

In this instance, the Jibril runtime tracing tool identified an attempt to modify the ld.so.preload file, classified under the persistence category. The method involved is "boot_or_logon_autostart_execution," a common persistence technique exploiting the system’s autostart mechanisms. The critical importance level indicates that such a modification could allow unauthorized code to load every time the system starts, providing continuous access to the attacker.

The MITRE ATT&CK framework associates this behavior with several tactics, including persistence (T1547.006: Boot or Logon Autostart - Ld.so Preload), as it aims to maintain unauthorized access. The attack vector in this event is specifically related to file access and execution, where the modification of a key configuration file (ld.so.preload) triggers the detection.

The introduction of this modification during the CI/CD pipeline likely points to a deliberate or accidental injection of malicious code, which would persist across reboots if undetected. This could lead to backdoor access or unauthorized control over system processes, severely compromising the system's integrity.

Implications for the CI/CD Pipeline

The detection of this event during a pull request suggests that malicious code was either introduced or triggered during the CI testing process. This poses a significant risk to both the CI and production environments, as the modified ld.so.preload file would preload a shared library that might contain unauthorized or malicious functionality. If the code were merged into the main branch and deployed, it could result in long-term persistence for the attacker, granting unauthorized access every time the system boots.

This could further compromise the integrity of the CI/CD pipeline by tampering with test results, introducing false positives or negatives, and potentially masking the presence of other vulnerabilities. Additionally, any deployed system could be compromised, affecting not only development environments but also production systems, leading to severe security breaches.

To mitigate this threat, it is recommended to:

  1. Immediately review the relevant pull request to identify the code that triggered the modification of the ld.so.preload file.
  2. Revert any unauthorized changes in the /etc/ld.so.preload file and ensure its permissions are set to prevent unauthorized modifications.
  3. Perform a comprehensive security audit of all recent code changes, dependencies, and libraries used in the build to ensure no further malicious injections.
  4. Implement additional monitoring around critical system files like ld.so.preload to detect any future unauthorized modifications.
  5. Strengthen the CI/CD pipeline with enhanced security checks to prevent code changes from tampering with critical configuration files.
  6. Consider isolating and analyzing the shared libraries that were being preloaded to ensure no malicious payloads are being executed.
  7. Regularly update and enforce security policies for handling autostart execution files and system configuration files.
  8. Conduct a post-mortem analysis to determine if this was an internal error or an external attack, and take appropriate measures to prevent reoccurrence.