Home > CAPEC List > CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness (Version 3.9)

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

Attack Pattern ID: 461
Abstraction: Standard
View customized information:
Description
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
Extended Description

When web services require callees to authenticate, they sometimes issue a token / secret to the caller that the caller is to use to sign their web service calls. In one such scheme the caller, when constructing a request, would concatenate all of the parameters passed to the web service with the provided authentication token and then generate a hash of the concatenated string (e.g., MD5, SHA1, etc.). That hash then forms the signature that is passed to the web service which is used on the server side to verify the origin authenticity and integrity of the message. Because of the iterative design of the hash function, it is possible, from only the hash of a message and its length, for an adversary to conduct signature forgery by computing the hash of longer messages that start with the initial message and include the padding required for the initial message to reach a multiple of 512 bits. It is important to note that the attack not limited to MD5 and will work on other hash functions such as SHA1.

Typical Severity

High

Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.115Authentication Bypass
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
Execution Flow
Explore

  1. Find a vulnerable web service: The adversary finds a web service that uses a vulnerable authentication scheme, where an authentication token is concatenated with the parameters of a request and then hashed

    Techniques
    Read application documentation to learn about authentication schemes being used
    Observe web service traffic to look for vulnerable authentication schemes
Experiment

  1. Attempt adding padding to parameters: An adversary tests if they can simply add padding to the parameters of a request such that the request is technically changed, with the hash remaining the same

    Techniques
    Exploit the hash function extension / padding weakness with only padding to test the weakness
Exploit

  1. Add malicious parameters to request: Add malicious parameters to a captured request in addition to what is already present. Do this by exploiting the padding weakness of the hash function and send the request to the web service so that it believes it is authenticated and acts on the extra parameters.

    Techniques
    Exploit the hash function extension / padding weakness by adding malicious parameters to a web service request such that it is still deemed authentic
Prerequisites
Web services check the signature of the API calls
Authentication tokens / secrets are shared between the server and the legitimate client
The API call signature is generated by concatenating the parameter list with the shared secret and hashing the result.
An iterative hash function like MD5 and SHA1 is used.
An attacker is able to intercept or in some other way gain access to the information passed between the legitimate client and the server in order to retrieve the hash value and length of the original message.
The communication channel between the client and the server is not secured via channel security such as TLS
Skills Required
[Level: Medium]
Medium level of cryptography knowledge, specifically how iterative hash functions work. This is needed to select proper padding.
Resources Required

Access to a function to produce a hash (e.g., MD5, SHA1)

Tools that allow the attacker to intercept a message between the client and the server, specifically the hash that is the signature and the length of the original message concatenated with the secret bytes

Mitigations
Design: Use a secure message authentication code (MAC) function such as an HMAC-SHA1
Example Instances
To leverage an attack against the has function extension / padding weakness, consider the message to be passed to the web service is M (this message includes the parameters passed to the web service concatenated with the secret token / key bytes). The message M is hashed and that hash is passed to the web service and is used for authentication. The attacker does not know M, but can see Hash (M) and Length (M). The attacker can then compute Hash (M || Padding (M) || M') for any M'. The attacker does not know the entire message M, specifically the attacker does not know the secret bytes, but that does not matter. The attacker is still able to sign their own message M' and make the called web service verify the integrity of the message without an error.
Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parent )
References
[REF-398] Thai Duong and Juliano Rizzo. "Flickr's API Signature Forgery Vulnerability". 2009年09月28日. <http://netifera.com/research/flickr_api_signature_forgery.pdf>.
Content History
Submissions
Submission DateSubmitterOrganization
2014年06月23日
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2018年07月31日
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Attack_Prerequisites, Description Summary
2020年12月17日
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Example_Instances
2021年10月21日
(Version 3.6)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow
2022年09月29日
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Extended_Description
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2025, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.

AltStyle によって変換されたページ (->オリジナル) /