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 queueing 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.
Attack Execution Flow
Explore
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.
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).
2
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.
3
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be
automated.
4
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).
Experiment
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.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
An attacker makes many anonymous connections
and records the session IDs assigned.
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.
env-Peer2Peer env-CommProtocol
env-ClientServer
Indicators
ID
type
Indicator Description
Environments
1
Positive
Trust in the system is based on IP address,
MAC address, network locality, or other general
network characteristic.
env-CommProtocol env-ClientServer
env-Peer2Peer
2
Positive
Web applications use session IDs
env-Web
3
Positive
Network systems issue session IDs or
connection IDs
env-CommProtocol env-ClientServer
env-Peer2Peer
Outcomes
ID
type
Outcome Description
1
Success
Systems or applications grant
trust based on logical or physical network
locality.
2
Success
Session identifiers
successfully spoofed
3
Failure
No session IDs can be found or
exploited
Security Controls
ID
type
Security Control Description
1
Detective
Monitor logs for
unusual amounts of invalid
sessions.
2
Detective
Monitor logs for
unusual amounts of invalid connections or invalid
requests from unauthorized
hosts.
Exploit
Impersonate:
An attacker can use successful experiments to
impersonate an authorized user or system
Security Controls
ID
type
Security Control Description
1
Detective
Analyze logs for users
or systems that are connecting from unexpected
sources.
2
Detective
Analyze logs for users
or systems successfully requesting or performing
unexpected actions.
3
Corrective
If heuristics are
sufficiently reliable, disconnect hosts or users
that appear to be unauthorized
impersonations.
Spoofing:
Bad data can be injected into the system by an
attacker.
Outcomes
ID
type
Outcome Description
1
Success
Unauthorized data is injected
into an application.
Security Controls
ID
type
Security Control Description
1
Detective
Apply heuristic
evaluation to input data. This can include
validating source addresses, user names, ACLs or
other data that indicates authorization. This need
not be done inline at the time the data is
processed, but can be done after the processing
has occurred to detect
attack.
2
Corrective
Apply
transaction-based logic to systems whose initial
authorization cannot be better controlled. Roll
back transactions that are subsequently determined
to be fraudulent or
illegitimate.
Attack Prerequisites
Server software must rely on weak session IDs proof and/or verification
schemes
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Spoofing
API Abuse
Injection
Examples-Instances
Description
Thin client applications like web applications are particularly
vulnerable to session ID attacks. Since the server has very little
control over the client, but still must track sessions, data, and
objects on the server side, cookies and other mechanisms have been used
to pass the key to the session data between the client and server. When
these session keys are compromised it is trivial for an attacker to
impersonate a user's session in effect, have the same capabilities as
the authorized user. There are two main ways for an attacker to exploit
session IDs.
A brute force attack involves an attacker repeatedly attempting to
query the system with a spoofed session header in the HTTP request. A
web server that uses a short session ID can be easily spoofed by trying
many possible combinations so the parameters session-ID= 1234 has few
possible combinations, and an attacker can retry several hundred or
thousand request with little to no issue on their side.
The second method is interception, where a tool such as wireshark is
used to sniff the wire and pull off any unprotected session identifiers.
The attacker can then use these variables and access the
application.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To achieve a direct connection with the weak or non-existent server
session access control, and pose as an authorized user
Resources Required
Ability to deploy software on network. Ability to communicate synchronously or
asynchronously with server
Solutions and Mitigations
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.
Attack Motivation-Consequences
Privilege Escalation
Information Leakage
Data Modification
Injection Vector
Malicious input delivered through standard service calls, e.g. FTP or posting
a message to a message queue.
Payload
Varies with instantiation of attack pattern. The main goal is so spoof or
impersonate a legitimate user.
Activation Zone
Client machine and client network (e.g. Intranet)
Payload Activation Impact
Enables attacker to impersonate another user and access commands and data (and
log behavior to audit logs) on their behalf.
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
