| Name |
Web Services API Signature Forgery Leveraging Hash Function Extension Weakness |
|
| Likelyhood of attack |
Typical severity |
| High |
High |
|
| Summary |
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. There is a practical attack against an authentication scheme of this nature that makes use of the hash function extension / padding weakness. Leveraging this weakness, an attacker, who does not know the secret token, is able to modify the parameters passed to the web service by generating their own call and still generate a legitimate signature hash (as described in the notes). Because of the iterative design of the hash function, it is possible, from only the hash of a message and its length, to compute 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. |
| 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 |
| Solutions | Design: Use a secure message authentication code (MAC) function such as an HMAC-SHA1 |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-290 |
Authentication Bypass by Spoofing |
| CWE-328 |
Reversible One-Way Hash |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-115 |
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place. This refers to an attacker gaining access equivalent to an authenticated user without ever going through an authentication procedure. This is usually the result of the attacker using an unexpected access procedure that does not go through the proper checkpoints where authentication should occur. For example, a web site might assume that all users will click through a given link in order to get to secure material and simply authenticate everyone that clicks the link. However, an attacker might be able to reach secured web content by explicitly entering the path to the content rather than clicking through the authentication link, thereby avoiding the check entirely. This attack pattern differs from other authentication attacks in that attacks of this pattern avoid authentication entirely, rather than faking authentication by exploiting flaws or by stealing credentials from legitimate users. |
|