CAPEC-21 - Exploitation of Session Variables, Resource IDs and other Trusted Credentials

Attacks on session IDs and resource IDs take advantage of the fact that some software accepts user input without verifying its authenticity. For example, a message queuing system that allows service requesters to post messages to its queue through an open channel (such as anonymous FTP), authorization is done through checking group or role membership contained in the posted message. However, there is no proof that the message itself, the information in the message (such group or role membership), or indeed the process that wrote the message to the queue are authentic and authorized to do so.

Many server side processes are vulnerable to these attacks because the server to server communications have not been analyzed from a security perspective or the processes "trust" other systems because they are behind a firewall. In a similar way servers that use easy to guess or spoofable schemes for representing digital identity can also be vulnerable. Such systems frequently use schemes without cryptography and digital signatures (or with broken cryptography). Session IDs may be guessed due to insufficient randomness, poor protection (passed in the clear), lack of integrity (unsigned), or improperly correlation with access control policy enforcement points.

Exposed configuration and properties files that contain system passwords, database connection strings, and such may also give an attacker an edge to identify these identifiers.

The net result is that spoofing and impersonation is possible leading to an attacker's ability to break authentication, authorization, and audit controls on the system.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 3
  • Spoofing
  • API Abuse
  • Injection
  • Purposes 1
  • Penetration
  • Scopes 3
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality
  • Read application data
  • Confidentiality
  • Modify application data
  • Integrity

Low level: To achieve a direct connection with the weak or non-existent server session access control, and pose as an authorized user

Server software must rely on weak session IDs proof and/or verification schemes

Ability to deploy software on network. Ability to communicate synchronously or asynchronously with server

Step 1 - Survey the application for Indicators of Susceptibility

Using a variety of methods, until one is found that applies to the target system. the attacker probes for credentials, session tokens, or entry points that bypass credentials altogether..

Tecnique ID: 1 - Environment(s) env-Web

Spider all available pages

Tecnique ID: 2 - Environment(s) env-Web env-CommProtocol env-ClientServer env-Local

Attack known bad interfaces

Indicator ID: 1 - Environment(s) env-Web env-Peer2Peer env-ClientServer env-CommProtocol

Type: Positive

Session IDs are used

Indicator ID: 2 - Environment(s) env-Web env-Peer2Peer env-CommProtocol env-ClientServer env-Local

Type: Positive

Open access points exist that use no user IDs or passwords, but determine authorization based on message content


Security Control ID: 1

Type: Detective

Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them).

Security Control ID: 2

Type: Detective

Create links on some pages that are visually hidden from web browsers. Using iframes, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application.

Security Control ID: 3

Type: Preventative

Actively monitor the application and either deny or redirect requests from origins that appear to be automated.

Security Control ID: 4

Type: Detective

Monitor velocity of feature activations (non-web software). Humans who activate features (click buttons, request actions, invoke APIs, etc.) will do so far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them).


Outcome ID: 1

Type: Success

Session IDs are identifiable

Outcome ID: 2

Type: Success

Open channels are available



Step 1 - Fetch samples

An attacker fetches many samples of a session ID. This may be through legitimate access (logging in, legitimate connections, etc) or just systematic probing..

Tecnique ID: 1 - Environment(s) env-Web env-Peer2Peer env-CommProtocol env-ClientServer

An attacker makes many anonymous connections and records the session IDs assigned.

Tecnique ID: 2 - Environment(s) env-Web env-Peer2Peer env-CommProtocol env-ClientServer

An attacker makes authorized connections and records the session tokens or credentials issued.

Tecnique ID: 3 - Environment(s) env-Peer2Peer env-CommProtocol env-ClientServer

An attacker gains access to (legitimately or illegitimately) a nearby system (e.g., in the same operations network, DMZ, or local network) and makes a connections from it, attempting to gain the same privileges as a trusted system.

Indicator ID: 1 - Environment(s) env-CommProtocol env-ClientServer env-Peer2Peer

Type: Positive

Trust in the system is based on IP address, MAC address, network locality, or other general network characteristic.

Indicator ID: 2 - Environment(s) env-Web

Type: Positive

Web applications use session IDs

Indicator ID: 3 - Environment(s) env-CommProtocol env-ClientServer env-Peer2Peer

Type: Positive

Network systems issue session IDs or connection IDs


Security Control ID: 1

Type: Detective

Monitor logs for unusual amounts of invalid sessions.

Security Control ID: 2

Type: Detective

Monitor logs for unusual amounts of invalid connections or invalid requests from unauthorized hosts.


Outcome ID: 1

Type: Success

Systems or applications grant trust based on logical or physical network locality.

Outcome ID: 2

Type: Success

Session identifiers successfully spoofed

Outcome ID: 3

Type: Failure

No session IDs can be found or exploited



Step 1 - Impersonate

An attacker can use successful experiments to impersonate an authorized user or system.

Step 2 - Spoofing

Bad data can be injected into the system by an attacker..


Design: utilize strong federated identity such as SAML to encrypt and sign identity tokens in transit.

Implementation: Use industry standards session key generation mechanisms that utilize high amount of entropy to generate the session key. Many standard web and application servers will perform this task on your behalf.

Implementation: If the session identifier is used for authentication, such as in the so-called single sign on use cases, then ensure that it is protected at the same level of assurance as authentication tokens.

Implementation: If the web or application server supports it, then encrypting and/or signing the session ID (such as cookie) can protect the ID if intercepted.

Design: Use strong session identifiers that are protected in transit and at rest.

Implementation: Utilize a session timeout for all sessions, for example 20 minutes. If the user does not explicitly logout, the server terminates their session after this period of inactivity. If the user logs back in then a new session key is generated.

Implementation: Verify of authenticity of all session IDs at runtime.