How to exploit LFI to retrieve sensitive files in NGINX

Question

I am studying Local File Inclusion (LFI) vulnerabilities and want to understand how attackers can exploit them specifically in an NGINX environment. My main questions are:

• How does NGINX’s configuration affect LFI exploits?
• What are common techniques to bypass restrictions, such as null-byte truncation or path normalization?
• How can an attacker retrieve sensitive files like /etc/passwd or application source code?
  I would also like to know the best mitigation strategies to secure an NGINX server against such attacks.

Answer 1

Local File Inclusion (LFI) vulnerabilities occur when an application allows users to include files on the server through user input, leading to potential exposure of sensitive information or code execution. In an NGINX environment, understanding how LFI can be exploited and implementing effective mitigation strategies are crucial for maintaining server security.

1. Impact of NGINX Configuration on LFI Exploits

NGINX's configuration plays a significant role in either facilitating or preventing LFI vulnerabilities:

• Root and Alias Directives: The root directive sets the root directory for requests, while the alias directive maps a URI to a specific directory. Misconfigurations, such as improper path settings, can inadvertently expose server files.

  Example:

  location /files/ {
      alias /var/www/html/uploads/;
  } 

If user input isn't properly sanitized, an attacker could manipulate the path to access unintended files.

• Autoindex Module: Enabling the autoindex module allows directory listings. If not correctly configured, it can reveal sensitive files to unauthorized users.

  Example:

  location / {
      autoindex on;
  } 

This setup could expose directory contents if access permissions aren't strictly controlled.

2. Techniques to Bypass Restrictions

Attackers employ various methods to circumvent security measures:

• Null Byte Injection: Some applications may terminate file paths at a null byte (%00), allowing attackers to truncate the file path and access unintended files.

  Example:

  http://example.com/index.php?page=../../etc/passwd%00 

Here, %00 might terminate the string, leading to /etc/passwd being included.

• Path Traversal: By injecting sequences like ../, attackers can navigate to parent directories and access restricted files.

  Example:

  http://example.com/index.php?page=../../../../etc/passwd 

This input attempts to traverse directories to reach /etc/passwd.

• Path Normalization: NGINX normalizes paths, resolving sequences like /../. Attackers might use double URL encoding or other encoding schemes to bypass filters.

  Example:

  http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd 

Here, %25 represents %, so %252e decodes to ..

3. Retrieving Sensitive Files

To access files like /etc/passwd or application source code, attackers might:

• Leverage LFI to Read Files: By exploiting LFI, attackers can include and read files from the server.

  Example:

  http://example.com/index.php?page=../../etc/passwd 

This could display the contents of /etc/passwd if not properly secured.

• Log File Poisoning: Attackers inject malicious code into server logs (e.g., access logs) and then include these logs via LFI to execute code.

  Example:

  http://example.com/index.php?page=../../var/log/nginx/access.log 

If the access log contains injected PHP code, including it might execute the code.

4. Mitigation Strategies

To protect an NGINX server from LFI attacks:

• Input Validation and Sanitization: Ensure all user inputs are validated and sanitized. Restrict inputs to expected values and formats.

  Example:

  $allowed_pages = ['home', 'about', 'contact'];
  if (in_array($_GET['page'], $allowed_pages)) {
      include $_GET['page'] . '.php';
  } else {
      // Handle error
  } 

This restricts inclusion to predefined pages.

• Disable Unnecessary Modules: Turn off modules like autoindex if not required to prevent unintended exposure.

  Example:

  location / {
      autoindex off;
  } 

This prevents directory listings.

• Set Safe Permissions: Ensure that NGINX processes have limited permissions, preventing access to sensitive files.

  Example:

  user nginx;
  worker_processes auto;

Running NGINX under a dedicated user with restricted permissions limits potential damage.

• Use Chroot Jail: Restrict NGINX to a specific portion of the filesystem, isolating it from sensitive areas.

  Example:

  location / {
      root /var/www/html;
      # Other configurations
  } 

This confines NGINX to /var/www/html.

• Employ Web Application Firewalls (WAFs): WAFs can detect and block malicious requests targeting LFI vulnerabilities.

  Example:

ModSecurity with the OWASP Core Rule Set can help identify and prevent LFI attempts.

Integrating a WAF adds an additional security layer.

By understanding the intricacies of NGINX configurations and implementing robust security measures, you can effectively defend against LFI exploits and protect sensitive server files.