Privilege Escalation: How Attackers Gain Unauthorised System Control

Privilege Escalation is the exploitation of a security flaw to access resources normally protected from a user or application. It can allow a low-privileged user to act as a system administrator — opening files, modifying accounts, or destroying Active Directory.

Two Types of Privilege Escalation

TypeDescriptionExample
HorizontalAccess resources belonging to a peer with similar permissionsViewing another user’s banking data
VerticalAccess resources belonging to a higher-privileged accountRegular user gaining root/admin access

Privilege Separation Architecture

A well-designed service splits into a privileged monitor and unprivileged slaves. The slave requests the monitor to perform privileged operations; the monitor validates each request before executing. This minimises the privileged code surface exposed to attack.

  • Pre-Authentication Phase: Unprivileged child has no process privileges or file system access.
  • Post-Authentication Phase: Child gets user-level privileges only; special operations still route through the privileged parent.

Mitigation Guidance

  • Apply the Principle of Least Privilege throughout all service accounts and processes.
  • Remove unused services and applications from network devices.
  • Enforce strict password policies and disable unused accounts.
  • Tighten default access permissions — Windows “Everyone” group should not be the default.
  • Regularly audit log files and baseline system files for anomalies.

HTTP Verb Tampering: Bypassing Security Controls with Unexpected HTTP Methods

HTTP Verb Tampering exploits Verb-Based Authentication and Access Control (VBAAC) mechanisms. When security rules explicitly list which HTTP methods are allowed, they inadvertently permit all unlisted methods. Attackers use HEAD, TRACE, or arbitrary strings like “JEFF” to bypass security constraints entirely.

The VBAAC Flaw (Java EE Example)

<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint><role-name>admin</role-name></auth-constraint>
</security-constraint>

This rule intends to restrict /admin/* to admins. In practice, a HEAD or “JEFF” request bypasses the rule and executes the admin function without authentication.

Avoid Sending Sensitive Data via GET

# NEVER — card number is logged in clear text in server logs:
http://www.example.com/process_card.asp?cardnumber=1234567890123456

Prevention Guidance

  • Enable “deny all” as the default — protect all HTTP methods, not just listed ones.
  • Remove all <http-method> elements from web.xml to protect methods equally.
  • Configure the server to disallow HEAD requests entirely.
  • Ensure all GET-accessible functions are idempotent (read-only, no state changes).