Attacking Access Controls

• Access control mechanisms are entirely dependent upon authentication and session management.
• Why it matters:
  • Need for way to decide action and resource access permissions.

Common Vulnerabilities

• Three main categories:
  1. Vertical privilege escalation
     • Allow the access of different parts of functionality by different types of users.
       1. Guest user access vs. Admin user access
     • User can perform actions that their role does not inherently permit.
  2. Horizontal privilege escalation
     • Allows users to access a subset of resources of the same type.
       1. Accessing someone else's email when access should only be limited to your own.
     • User can perform actions that are not entitled to them.
  3. Context-dependent (Business logic exploitation)
     • User access is completely based upon the state of the application.
       1. The user can modify parts early on, but are not allowed to in later stages.
     • User can exploit a flaw in the state machine of the application to access a given function or resource.
• These vulnerabilities often intertwine. So, changing another user's password is a horizontal privilege escalation. Then, a user can access that other user's higher privileges, equating to a vertical privilege escalation.

Completely Unprotected Functionality

• Examples:
  • Knowing the exact URL of a function, even if its "secret" or "hidden".
    • Usually only accessed by an administrator menu.
    • Can be guessed or found out by looking deeply at client-side code.

Direct Access to Methods

• APIs often are called on the server-side of an application. When server-side functionality is required by extensions, developers may end up just directly calling API methods from that extension.
• By directly calling methods, access controls might be completely bypassed.
• Can be revealed by simply looking at the URL path, where functionalities are defined in a RESTful manner.

Identifier-Based Functions

• Common to use identifiers passed in request parameters to specify a resource that is being accessed.
• With poor access controls, any user may request that resource by knowing its identifier.
• Resources may be identified by a randomly generated GUIDs.
  • These can still be randomly guessed, predicted, or even iterated until the correct resources are enumerated.

Multistage Functions

• Access controls may be properly implemented in earlier stages of a multi-stage process, but completely nonexistent in later stages.
• Typically, this vulnerability is exploited by changing data passed to later stages. This works because data may not be properly validated after it has already been processed.

Static Files

• An application may, through dynamic content loading, issue requests upon loading a page that loads some static content. Typically, this is loading a PDF or some other type of file.
• Unfortunately, this type of loading of these static files, no matter how random the names are generated, leads to a total lack of access control in the loading of them.

Platform Misconfiguration

• Some access controls are implemented at the web server or application platform layer.
• Access may be restricted based on:
  • URL path
  • User role
  • HTTP request method
    • Circumvention of this access control type may occur by simply using other HTTP request methods are allowed and perform the same functionality.
    • Unimplemented methods may simply fall through.

Insecure Access Control Methods

Parameter-Based Access Control

• Role or access level is based on a hidden form field, cookie, or query string parameter.
  • e.g. ?admin=true
• By just being aware or stumbling upon this access control information, a user can easily perform vertical privilege escalation.

Referer-Based Access Control

• Access control decisions here are based on the HTTP referer header.
• Administrative functions might just do validations based on this header.

Location-Based Access Control

• Access control can also be limited based on geolocation of an individual. For instance, if a user is at a certain business location, they may be assumed to have a certain level of access.
• This can be easily exploited by using a web proxy, VPN, mobile device, or by blatant spoofing.

Attacking Access Controls

Testing with Different User Accounts

• By testing using different accounts, the methods for accessing resources and functions can be much more easily assessed.
  • Test based on different access levels (vertical)
  • Test same access levels (horizontal)
• With each different user test, attempt to generate diffs using site maps from each user context. Look for differences that mean something, as many may simply be expected and neutral.
  • Consider identical responses!

Testing Multistage Processes

• Process:
  1. Test each request individually in the multistage process.
  2. Try to find improper validation of:
     • Input
     • User Access
  3. Use accounts with different privileges to attempt the same requests
  4. Attempt to find differences in the responses based on requests submitted by different users and under different privilege levels.

Testing with Limited Access

• Sometimes you may only have one user account to test for hidden or restricted functionality.
  • In this case, content discovery methods must be employed.
    • Iterate through identifiers
      • Find means to predict them, whether they are simply generated based off of incrementing previously used identifiers or by weak algorithms.
  • Attempt using appended query parameters that may signify certain privileges. For instance, appending admin=true to request urls.
  • Next, test for using the Refererheader for access control decisions.
  • Lastly, check all HTML and client-side scripts for references to hidden functionalities.

Testing Direct Access to Methods

• Process:
  1. Identify any parameters using Java naming conventions:
     • get, set, add, update, is, has + <CamelcasedName>
  2. Look for methods that list all available methods, resources, or interfaces.
  3. Guess methods, like described in Ch.4
  4. Attempt these methods from multiple, different user contexts.

Testing Controls Over Static Resources

• Process:
  1. Look for a static, 'protected' resources and access them normally
  2. Use a different user context to access the same, enumerated resources.
  3. If this works, try to identify identifiers or name schemes for these.

Testing Restrictions on HTTP Methods

• Process:
  1. Use a high-privilege account to identify privileged requests
  2. If the request does not use anti-CSRF tokens or other methods, attempt using the same features with different types of HTTP methods.
  3. If any requests accept requests using different HTTP methods, use a different user context with lower privileges and test each of these HTTP methods.

Securing Access Controls

• Recommendations:
  • Do not just hide URLs as a means for access control
  • Do not trust user-submitted parameters that signify role or privilege
  • Do not assume multi-stage processes will be followed in a correct order
  • Validate all user input with each stage of any process
  • Base access control decisions on the session
  • Use a central component to check access controls
    • Programmatically test for exceptions and fix vulnerabilities.
  • Consider restricting administrative access based on IP addresses
    • Obviously, combine with session usage for access control
  • Static content access methods:
    • Passing a file name to a dynamic server-side page
    • Direct access using HTTP authentication or other application authentication methods
  • Consider per-transaction reauthentication
  • Log all privileged access

A Multilayered Privilege Model

• Methods:
  • Access control based on user roles defined at the application server
  • Different database accounts based on different user actions
  • Using a table of privileges defined in the database
  • Least privileges for each operating system account
• Access Control concepts:
  • Programmatic control
    • Programmatically reference a table of defined privileges to enforce access control.
    • Vulnerabilities like injection-based attacks
  • Discretionary access control (DAC)
    • Types:
      • closed: Access denied unless explicitly granted
      • open: access accepted unless explicitly denied
    • Have to be very specifically defined and may be incomplete
  • Role-based access control (RBAC)
    • Roles are assigned to users and referenced for access controls.
  • Declarative control
    • Restricted database accounts are used to access the database.