Home > CAPEC List > CAPEC-39: Manipulating Opaque Client-based Data Tokens (Version 2.9)  

CAPEC-39: Manipulating Opaque Client-based Data Tokens

 
Manipulating Opaque Client-based Data Tokens
Definition in a New Window Definition in a New Window
Attack Pattern ID: 39
Abstraction: Standard
Status: Draft
Completeness: Complete
Presentation Filter:
+ Summary

In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.

+ Attack Execution Flow
Explore
  1. Enumerate information passed to client side:

    The attacker identifies the parameters used as part of tokens to take business or security decisions

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Use WebScarab to reveal hidden fields while browsing.

    env-Web
    2

    Use a sniffer to capture packets

    env-ClientServer env-Peer2Peer env-CommProtocol
    3

    View source of web page to find hidden fields

    env-Web
    4

    Examine URL to see if any opaque tokens are in it

    env-Web
    5

    Disassemble or decompile client-side application

    env-ClientServer env-Peer2Peer
    6

    Use debugging tools such as File Monitor, Registry Monitor, Debuggers, etc.

    env-ClientServer env-Peer2Peer

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    Opaque hidden form fields in a web page

    env-Web
    2Positive

    Opaque session tokens/tickets

    env-Web env-Peer2Peer env-ClientServer env-CommProtocol
    3Positive

    Opaque protocol fields

    env-ClientServer env-Peer2Peer env-CommProtocol
    4Positive

    Opaque Resource Locator

    env-Web env-Peer2Peer env-ClientServer env-CommProtocol

    Outcomes

    IDTypeOutcome Description
    1Success
    At least one opaque client-side token found
    2Failure
    No opaque client-side tokens found
  2. Determine protection mechanism for opaque token:

    The attacker determines the protection mechanism used to protect the confidentiality and integrity of these data tokens. They may be obfuscated or a full blown encryption may be used.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Look for signs of well-known character encodings

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2

    Look for cryptographic signatures

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    3

    Look for delimiters or other indicators of structure

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    Standard signatures of well-known encodings detected

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2Positive

    Token or structural block's length being multiple of well-known block size of a cryptographic algorithm

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    3Positive

    Clear structural boundaries or delimiters

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    4Negative

    Failure outcome in previous step

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Outcomes

    IDTypeOutcome Description
    1Success
    Protection/encoding scheme identified
    2Failure
    No information about protection/encoding scheme could not be determined
Experiment
  1. Modify parameter/token values:

    Trying each parameter in turn, the attacker modifies the values

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Modify tokens logically

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2

    Modify tokens arithmetically

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    3

    Modify tokens bitwise

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    4

    Modify structural components of tokens

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    5

    Modify order of parameters/tokens

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    Success outcome in first step.

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2Negative

    Failure outcome in first step

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
  2. Cycle through values for each parameter.:

    Depending on the nature of the application, the attacker now cycles through values of each parameter and observes the effects of this modification in the data returned by the server

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Use network-level packet injection tools such as netcat

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2

    Use application-level data modification tools such as Tamper Data, WebScarab, TamperIE, etc.

    env-Web
    3

    Use modified client (modified by reverse engineering)

    env-ClientServer env-Peer2Peer env-CommProtocol
    4

    Use debugging tools to modify data in client

    env-ClientServer env-Peer2Peer

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    Success outcome in first step

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2Negative

    Failure outcome in first step

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Outcomes

    IDTypeOutcome Description
    1Success
    Subversion of security controls on server
    2Failure
    Client token reset by server
    3Inconclusive
    Detailed error message describing problem with token, received from server

    Security Controls

    IDTypeSecurity Control Description
    1Detective
    Unexpected/invalid token/parameter value in application logs on server
    2Corrective
    Reset session upon receipt of unexpected/invalid token/parameter value
+ Attack Prerequisites
  • An attacker already has some access to the system or can steal the client based data tokens from another user who has access to the system.

  • For an Attacker to viably execute this attack, some data (later interpreted by the application) must be held client-side in a way that can be manipulated without detection. This means that the data or tokens are not CRCd as part of their value or through a separate meta-data store elsewhere.

+ Typical Severity

Medium

+ Typical Likelihood of Exploit

Likelihood: Very High

+ Methods of Attack
  • Modification of Resources
+ Examples-Instances

Description

With certain price watching websites, that aggregate products available prices, the user can buy items through whichever vendors has product availability, the best price, or other differentiator. Once a user selects an item, the site must broker the purchase of that item with the vendor. Because vendors sell the same product through different channel partners at different prices, token exchange between price watching sites and selling vendors will often contain pricing information. With some price watching sites, manipulating URL-data (which is encrypted) even opaquely yields different prices charged by the fulfilling vendor. If the manipulated price turns out higher, the Attacker can cancel purchase. If the Attacker succeeded in manipulating the token and creating a lower price, he/she proceeds.

Description

Upon successful authentication user is granted an encrypted authentication cookie by the server and it is stored on the client. One piece of information stored in the authentication cookie reflects the access level of the user (e.g. "u" for user). The authentication cookie is encrypted using the Electronic Code Book (ECB) mode, that naively encrypts each of the plaintext blocks to each of the ciphertext blocks separately. An attacker knows the structure of the cookie and can figure out what bits (encrypted) store the information relating to the access level of the user. An attacker modifies the authentication cookie and effectively substitutes "u" for "a" by flipping some of the corresponding bits of ciphertext (trial and error). Once the correct "flip" is found, when the system is accessed, the attacker is granted administrative privileges in the system. Note that in this case an attacker did not have to figure out the exact encryption algorithm or find the secret key, but merely exploit the weakness inherent in using the ECB encryption mode.

Description

Archangel Weblog 0.90.02 allows remote attackers to bypass authentication by setting the ba_admin cookie to 1.

Related Vulnerabilities

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

If the client site token is obfuscated.

Skill or Knowledge Level: High

If the client site token is encrypted.

+ Resources Required

The Attacker needs no special hardware-based resources in order to conduct this attack. Software plugins, such as Tamper Data for Firefox, may help in manipulating URL- or cookie-based data.

+ Probing Techniques

Tamper with the client side data token and observe the effects it has on interaction with the system.

This attack is in and of itself a trial-and-error-based probing technique.

+ Solutions and Mitigations

One solution to this problem is to protect encrypted data with a CRC of some sort. If knowing who last manipulated the data is important, then using a cryptographic "message authentication code" (or hMAC) is prescribed. However, this guidance is not a panacea. In particular, any value created by (and therefore encrypted by) the client, which itself is a "malicious" value, all the protective cryptography in the world can't make the value 'correct' again. Put simply, if the client has control over the whole process of generating and encoding the value, then simply protecting its integrity doesn't help.

Make sure to protect client side authentication tokens for confidentiality (encryption) and integrity (signed hash)

Make sure that all session tokens use a good source of randomness

Perform validation on the server side to make sure that client side data tokens are consistent with what is expected.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Integrity
Modify application data
Confidentiality
Access_Control
Authorization
Gain privileges / assume identity
+ Relevant Security Requirements

Sensitive information stored client side must be integrity checked upon return before use

+ Purposes
  • Penetration
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
+ Content History
Submissions
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
Modifications
ModifierOrganizationDateCommentsSource
CAPEC Content TeamThe MITRE Corporation2017-01-09Updated Related_Attack_PatternsInternal

More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 07, 2015