Security Notes
  • Whoami
  • Pentesting
    • WEP-Pen
      • Reconnaissance
      • Enumeration
      • OWSAP TOP 10
        • Injection
          • Cross Site Scripting
            • Cross Site Scripting
            • Exploitation
            • Protections
          • SQL Injection
            • SQL Injection Overview
          • NoSQL Injection
          • CRLF Injection
          • XML Injection
        • Broken Access Control
          • Path Traversal
          • Sensitive Cookie with Improper SameSite Attribute
          • Link Following
          • Incorrect Default Permissions
          • Information disclosure
          • CSRF
            • csrf checklist
          • 403 bypass
          • Exposure of WSDL File Containing Sensitive Information
          • bussiness logic checklist
          • 2FA bypass checklist
          • admin panal checklist
          • idor checklist
          • Authentication checklist
          • reset_password_checklist
          • ATO
        • Cryptographic Failures
          • Cryptographic Failure
          • Weak Encoding for Password
          • Improper Following of a Certificate's Chain of Trust
            • Understanding Digital Certificates : Self-Signed and CA-Signed Certificate **
            • Transport Layer Security (TLS) and SSL **
          • Clear Text Transmission Of Sensitive Data
            • SSLStripping **
        • Insecure Design
        • Security Misconfiguration
          • CORS Miscofigration
          • Mail Server Misconfiguration
        • Vulnerable and Outdated Components
          • Using Components with Known Vulnerabilities
        • Identification and Authentication Failures
          • JWT Hacking
          • SAML Authentication bypass
        • Software and Data Integrity Failures
          • mass assignment
          • PostMessage Vulnerabilities
            • PostMessage Vulnerabilities
            • Blocking main page to steal postmessage
            • Bypassing SOP with Iframes - part 1
            • Bypassing SOP with Iframes - part 2
            • Steal postmessage modifying iframe location
        • Security Logging and Monitoring Failures
        • Server-Side Request Forgery (SSRF)
          • SSRF
      • Checklists
        • aem misconfiguration
        • exif_geo
        • xss
        • Session Management
        • Authorization
        • cookie
        • Django
        • Symfony
        • json
        • bypass rate limit
        • Rce
        • Register Page
      • eWPTXv2 Preparation
        • Encoding & Filtering
        • Evasion Basics
        • Cross-site scripting (XSS)
        • XSS Filter Evasion
        • Cross-site request forgery (CSRF
        • HTML5
      • API-Pen
        • API Discovry
        • Reverse Engineering API Documentation
        • Excessive Data Exposure
        • Vulnerability Scanning
        • API Authentication Attacks
          • Classic Authentication Attacks
          • API Token Attacks
        • API Authorization Attacks
          • Broken Object Level Authorization (BOLA)
          • Broken Function Level Authorization
        • Improper Assets Management
        • Mass Assignment
        • SSRF
        • Injection Attacks in API
        • Evasive Maneuvers
        • GraphQL Vulnerabilities
    • NET-Pen
      • Active Directory Pentesting
        • Active Directory Components
        • Initial Attack Vectors
          • LLMNR Poisoning
          • SMB Relay Attacks
          • IPv6 Attacks ( IPv6 DNS Takeover )
          • Printer Hacking
          • Methodology
          • Some Other Attacks
            • Zerologon (CVE-2020-1472)
            • PrintNightmare (CVE-2021-1675)
        • Post-Compromise Attacks
          • Pass Attacks
          • Kerberoasting Attack
          • Token Impersonation Attack
          • LNK File Attack
          • GPP / cPassword Attacks
          • Mimikatz
          • Methodology
        • We've Compromised the Domain
          • Dumping the NTDS.dit
          • Golden Ticket Attacks
          • Methodology
        • Case Study
        • Password Attacks
      • Attack Vectors by Port
        • FTP 21
        • SSH 22
        • Telnet 23 - 2323
        • SMTP 25
        • DNS 53
        • Kerberos 88
        • POP 110-995
        • RPC 111
        • Ident 113
        • NNTP 119
        • NetBIOS 137-138
        • SMB / Samba 135-139, 445
        • MSRPC 135
        • SNMP 161
        • LDAP 389,636
        • Modbus 502
        • OpenSSL 1337
        • Ms-SQL 1433
        • Oracle Listener 1521 1522 1529
        • NFS 2049
        • MySql 3306
        • RDP 3389
        • ADB Android Debug Bridge 5555
        • WinRM 5985 5986
        • VNC 5800 5900
        • Redis 6379
        • Unreal IRC 6667
        • Tomcat 8080
        • MongoDB 27017
        • http 80
      • Network basics
      • Information Gathering
      • Privilege Escalation
        • Windows Privilege Escalation
        • Linux Privilege Escalation
    • write-ups
      • How i found a Privilege Escalation via Impersonation Features feature
      • How I was able to discover ATO Via IDOR vulnerability
      • Easy full Account Takeover via Facebook OAuth Misconfiguration
Powered by GitBook
On this page
  • Vulnerable Scenario (Local and Remote)
  • Vulnerable Application Example
  • Impact and Exploitation
  • Mitigation Strategy
  1. Pentesting
  2. WEP-Pen
  3. OWSAP TOP 10
  4. Broken Access Control

Link Following

CWE-59: Improper Link Resolution Before File Access ('Link Following')

CWE-59 refers to a security vulnerability that occurs when an application resolves symbolic or hard links to files before properly validating the link’s target. This can allow attackers to control which file or directory the application accesses, potentially leading to unauthorized access to sensitive files, privilege escalation, or other types of attacks.

How It Works:

This vulnerability arises when a program opens a file path (which may be controlled by the user) and fails to check whether the path refers to a symbolic link. Instead, the program blindly follows the link and accesses the file it points to, without any validation. If an attacker can control or manipulate the symbolic link’s target, they can trick the program into accessing sensitive files or data, such as system files that should be protected.


Vulnerable Scenario (Local and Remote)

1. Local Attack ( which is likely ) :

  • Vulnerable Application: A local file viewer or editor that opens any file without validating whether it is a symlink.

  • Attack Steps:

    1. The attacker creates a symbolic link (symlink.txt) that points to /etc/passwd.

    2. The attacker uploads the symbolic link to the server or places it within a directory accessible by the vulnerable application.

    3. The application opens the symbolic link as if it were a regular file, and it ends up reading /etc/passwd.

  • The attacker gains unauthorized access to sensitive information, such as user credentials stored in /etc/passwd.

2. Remote Attack (via HTTP Request):

  • Vulnerable Web Application: A file upload service where users can upload files for sharing, without checking for symbolic links.

  • Attack Steps:

    1. The attacker uploads a symbolic link (e.g., user_file.txt) through the web interface. This symlink points to /etc/passwd on the server.

    2. The web application stores the file in the server's file storage system without validating whether it's a symlink.

    3. The attacker, knowing the file's location (e.g., /uploads/user_file.txt), requests the file via an HTTP request:

      GET /uploads/user_file.txt HTTP/1.1
      Host: vulnerable-app.com
    4. The application, unaware that user_file.txt is a symlink, follows it and opens /etc/passwd instead of the intended file.

  • The attacker can access sensitive system information through the web interface, such as user credentials stored in /etc/passwd:

HTTP/1.1 200 OK
Date: Fri, 11 Jan 2025 13:45:00 GMT
Server: Apache/2.4.7 (Ubuntu)
Content-Type: text/plain; charset=UTF-8
Content-Length: 122

root:x:0:0:root:/root:/bin/bash
user:x:1001:1001:user:/home/user:/bin/bash

Vulnerable Application Example

Let's take a look at an example in Python where the application reads a file without checking if it's a symbolic link

import os

def process_file(file_path):
    """Vulnerable function that opens a file without checking for symbolic links"""
    print(f"Opening file: {file_path}")
    
    # The application reads the file without checking if it's a symbolic link
    try:
        with open(file_path, 'r') as f:
            data = f.read()
            print(data)
    except Exception as e:
        print(f"Error: {e}")

# Simulated file upload path (the attacker can control this path)
uploaded_file = '/uploads/user_file.txt'
process_file(uploaded_file)

Lab Setup:

  1. Create a vulnerable directory for file uploads and the sensitive file:

    mkdir /uploads
    touch /uploads/user_file.txt  # Simulate uploaded file
  2. Create a sensitive file (e.g., /etc/passwd or any other important file on the system):

    echo "root:x:0:0:root:/root:/bin/bash" > /etc/passwd
  3. Create a symbolic link from the uploaded file path to the sensitive file:

    ln -s /etc/passwd /uploads/user_file.txt
  4. Run the vulnerable application:

    python3 vulnerable_app.py
  5. Exploit the vulnerability:

    The attacker can upload a symbolic link to /uploads/user_file.txt, which points to /etc/passwd. When the application reads the file, it will follow the symlink and access the sensitive file.

    Opening file: /uploads/user_file.txt
    root:x:0:0:root:/root:/bin/bash

Impact and Exploitation

As seen in the example, the vulnerable application opens the file /uploads/user_file.txt without checking whether it’s a symbolic link. Since /uploads/user_file.txt is a symlink to /etc/passwd, the application reads and prints the contents of /etc/passwd, exposing sensitive system information. This results in information leakage, where data that should be protected is inadvertently exposed.


Mitigation Strategy

To mitigate this vulnerability, it is essential to verify the target of symbolic links before following them. In Python, this can be done using the os.path.islink() function to detect symbolic links before accessing them.

Here’s a secure version of the code:

import os

def process_file(file_path):
    """Secure function that checks for symbolic links before opening the file"""
    if os.path.islink(file_path):
        print("Error: Symbolic link detected. Aborting file access.")
        return
    
    print(f"Opening file: {file_path}")
    
    try:
        with open(file_path, 'r') as f:
            data = f.read()
            print(data)
    except Exception as e:
        print(f"Error: {e}")

# Simulated file upload path
uploaded_file = '/uploads/user_file.txt'
process_file(uploaded_file)

n this version, the program first checks whether the file is a symbolic link using os.path.islink(). If the file is a symbolic link, the program aborts the operation and prevents accessing the target file, thus preventing the exploitation of the vulnerability.

Resources

PreviousSensitive Cookie with Improper SameSite AttributeNextIncorrect Default Permissions

Last updated 4 months ago

OS Path Documentation for Python
Latest vulnerabilities for CWE-59