PHP-Post 1.0 Cookie Modification Privilege Escalation Explained

What this paper is

This paper details a privilege escalation vulnerability in PHP-Post versions 0.21 and 1.0. The vulnerability allows a remote attacker to gain administrative privileges by manipulating the application's cookies, specifically when the "auto login" feature is enabled.

Simple technical breakdown

PHP-Post, a web application, had a security weakness in how it handled user sessions, particularly when users were set to auto-login. Instead of properly verifying a user's identity and permissions, the application relied on information stored in cookies. An attacker could intercept or craft a cookie, change a regular user's identifier to an administrator's, and then submit this modified cookie back to the server. Because the application didn't re-validate the administrator status after the cookie was set, it would mistakenly grant the attacker administrative rights, even without knowing the administrator's password.

Complete code and payload walkthrough

The provided paper does not contain any executable code or shellcode. It describes a vulnerability and provides a "Proof of Concepts" section that demonstrates how to manipulate HTTP cookies.

Proof of Concepts Breakdown:

The paper shows two examples of cookie strings:

1. Original Cookie:
   logincookie[pwd]=5a329326344d1d38; logincookie[user]=3nitr0; logincookie[last]=2006-07-07+05%3A24%3A44; logincookie[lastv]=1152264284; post[329]=330

   • logincookie[pwd]=5a329326344d1d38: This likely represents a hashed password for the user. The value 5a329326344d1d38 is a hexadecimal string, suggesting it's a MD5 hash or similar.
   • logincookie[user]=3nitr0: This is the username identifier. 3nitr0 is likely a user ID or a specially crafted username string.
   • logincookie[last]=2006-07-07+05%3A24%3A44: This appears to be a timestamp indicating the last login time.
   • logincookie[lastv]=1152264284: This might be a Unix timestamp or a related value for the last login.
   • post[329]=330: This is an unknown cookie parameter, possibly related to a specific post or setting within the PHP-Post application.

2. Modified Cookie (Exploited):
   Cookie: logincookie[pwd]=5a329326344d1d38; logincookie[user]="ADMINS USERNAME"; logincookie[last]=2006-07-07+05%3A24%3A44; logincookie[lastv]=1152264284; post[329]=330`

   • The key change here is logincookie[user]="ADMINS USERNAME". The attacker replaces the original username identifier (3nitr0) with the actual username of an administrator. The paper explicitly states "without password ;)", implying that the password hash (logincookie[pwd]`) was not changed, as it was not necessary for this specific attack.

Mapping:

• logincookie[user] -> User identifier within the cookie.
• Modification of logincookie[user] to an administrator's username -> Exploitation vector for privilege escalation.

Payload:

There is no executable payload in the traditional sense (like shellcode). The "payload" is the crafted HTTP cookie itself. The action of sending this modified cookie to the vulnerable server is the exploit.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server. No prior authentication is strictly required to initiate the attack, as it targets the session management mechanism. However, knowing that "auto login" is enabled is a prerequisite.
• Lab Preconditions:
  • A running instance of PHP-Post (versions 0.21 or 1.0) configured with the "auto login" feature enabled.
  • Knowledge of at least one administrator username within the application. This could be discovered through other means (e.g., default credentials, enumeration).
  • A tool capable of intercepting and modifying HTTP requests/responses, such as Burp Suite, OWASP ZAP, or a custom script using libraries like requests in Python.
• Tooling Assumptions:
  • Web proxy for intercepting and modifying traffic.
  • A way to craft HTTP requests with specific cookies.
• Execution Pitfalls:
  • "Auto Login" Not Enabled: If the "auto login" feature is disabled, this specific vulnerability will not be exploitable.
  • Cookie Obfuscation/Encryption: If the application uses more robust session management, such as signed or encrypted cookies, simply changing the username value might be detected as invalid.
  • Server-Side Validation: Modern web applications often have more rigorous server-side validation of session data, which would likely prevent this type of manipulation.
  • Discovering Admin Username: The attacker needs to know a valid administrator username. This might require reconnaissance.
  • Cookie Format Changes: The exact format and naming of cookies can change between versions or with custom configurations, requiring adaptation.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target application and its version. Determine if "auto login" is a feature and if it's enabled. Attempt to enumerate potential administrator usernames.
  • Proxying Traffic: Set up a web proxy to capture the initial login or subsequent requests from a legitimate user. Observe the cookie structure.
  • Crafting the Exploit: Modify the captured cookie, replacing the user identifier with the target administrator's username.
  • Delivery: Send the crafted HTTP request containing the modified cookie to the target server.
  • Verification: Check if administrative functions are now accessible.
• Expected Telemetry:
  • Web Server Logs: An HTTP request with a modified Cookie header. The User-Agent might be standard or indicative of automated tools.
  • Application Logs: Potentially, logs indicating a user session being established with elevated privileges without a corresponding successful login event (if the application logs such details).
  • Network Traffic: Unencrypted HTTP traffic containing the manipulated cookie. If HTTPS is used, the cookie content would be encrypted, but the fact that a request with a modified cookie was sent would still be visible at a higher network layer if not properly inspected.

Where this was used and when

• Context: This vulnerability was relevant for web applications built with PHP, specifically the PHP-Post bulletin board/messaging system.
• Approximate Years/Dates:
  • Discovery: November 23, 2005.
  • Publication: July 18, 2006.
  • This indicates the vulnerability was actively present and exploitable around 2005-2006.

Defensive lessons for modern teams

• Never Trust Client-Side Data: Do not rely solely on data sent from the client (like cookies) to determine user privileges or identity. Always validate on the server.
• Robust Session Management: Implement secure session management practices. This includes:
  • Using strong, randomly generated session IDs.
  • Setting appropriate session timeouts.
  • Regenerating session IDs upon login or privilege change.
  • Using secure, HTTP-only, and SameSite cookie flags.
  • Considering server-side session storage instead of relying solely on cookies.
• Input Validation and Sanitization: While not directly applicable to cookie manipulation in this specific case, general input validation is crucial. However, for session tokens and identifiers, server-side validation of their integrity and associated permissions is paramount.
• Secure Authentication Flows: Ensure that authentication and authorization checks are performed at every critical step, especially when accessing sensitive resources or performing administrative actions.
• Regular Patching and Updates: Keep all web applications and their dependencies updated to the latest secure versions. Vendors typically release patches for known vulnerabilities.
• Least Privilege Principle: Even if a session is established, ensure that the user only has the minimum necessary privileges for their intended actions.

ASCII visual (if applicable)

This vulnerability is primarily about manipulating data in transit. A simple visual representation of the data flow is applicable.

+-----------------+       +---------------------+       +-----------------+
| Attacker's      | ----> | Web Server (PHP-Post| ----> | Application     |
| Browser/Client  |       |  with Auto Login)   |       | Logic           |
+-----------------+       +---------------------+       +-----------------+
        ^                                                      |
        |                                                      |
        | Modified Cookie                                      |
        | (e.g., logincookie[user]="admin")                    |
        |                                                      |
        +------------------------------------------------------+

Explanation:

1. The attacker's browser sends an HTTP request to the web server.
2. The attacker crafts this request to include a modified cookie.
3. The web server receives the request and passes the cookie to the PHP-Post application logic.
4. The application logic, due to the vulnerability, trusts the modified cookie and grants administrative privileges without proper re-authentication.

Source references

• PAPER ID: 2036
• PAPER TITLE: PHP-Post 1.0 - Cookie Modification Privilege Escalation
• AUTHOR: FarhadKey
• PUBLISHED: 2006-07-18
• PAPER URL: https://www.exploit-db.com/papers/2036
• RAW URL: https://www.exploit-db.com/raw/2036

Original Exploit-DB Content (Verbatim)

[KAPDA::#52] - PHP-Post 1.0 Cookie Modification Privilege Escalation Vulnerability


Vulnerable product: Tested on PHP-Post 0.21 and 1.0
Vendor: http://php-post.co.uk
Vulnerability: Privilege Escalation


Date:
--------------------
Found: Nov 23, 2005
Vendor Contacted: Jun 01, 2006
Release Date: July 18, 2006

Vulnerability:
--------------------
Privilege Escalation:
PHP-Post contains a flaw that may allow a remote attacker to gain administrative privileges.
PHP-Post doesn't properly authenticate remote users if auto login is on!
By editing the values of the cookie, an attacker can change their privilege from a regular 
user to administrator and submit it back to the site.


Proof of Concepts:
--------------------
Cookie: logincookie[pwd]=5a329326344d1d38; logincookie[user]=3nitr0; logincookie[last]=2006-07-07+05%3A24%3A44; logincookie[lastv]=1152264284; post[329]=330

change to:

Cookie: logincookie[pwd]=5a329326344d1d38; logincookie[user]="ADMIN`S USERNAME"; logincookie[last]=2006-07-07+05%3A24%3A44; logincookie[lastv]=1152264284; post[329]=330

without password ;)


Credit:
--------------------
Farhad Koosha
FarhadKey of KAPDA
farhadkey [at} kapda <d0t> net
Greetz to CVH and Pi3cH :)
Kapda - Security Science Researchers Insitute of Iran
http://www.KAPDA.ir

# milw0rm.com [2006-07-18]