The Hidden Risks of Hash Functions: Length Extension Attacks and Server-Side Security Vulnerabilities
Introduction
A Length Extension Attack is a specific vulnerability associated with certain types of hash functions like MD5, SHA-1, and SHA-2. Simply put, this type of attack exploits the fact that given \( H(\text{message}) \) and the length of the message, one can easily calculate \( H(\text{message} \mathbin{\Vert} \text{padding} \mathbin{\Vert} \text{extension}) \) without needing to know the actual message. Here, “||” denotes concatenation, and “padding” is added according to the specifications of the hash function.
This is possible because these hash functions use the Merkle-Damgård construction, which slices the input into multiple blocks. The hash value of each block depends on the hash value of the preceding block. This means that once we’ve calculated the hash for a certain message, we have a “state” from which we can continue adding more blocks.
A Server-Side Validation
To better understand this vulnerability, let’s consider a hypothetical server-side validation model. When a user attempts to log in, the server generates a hash value based on the user’s ID, name, and a 30-character secret key known only to the server. This hash is then sent to the client. Later, when the client tries to access specific APIs, such as one for changing user permissions, the server regenerates the hash for validation using the posted role ID, role name, role permissions, and the same 30-character secret key. If the uploaded hash matches the one generated server-side, the validation is successful, and the new role permissions are written to the database.
Here’s some sample code:
Bypassing Permissions
Due to the vulnerability in this validation model, attackers can bypass permission checks without knowing the SecretKey by reconstructing the transaction request. The core idea behind this unauthorized access is exploiting Length Extension Attacks. The attacker first needs to obtain the original hash and calculate the length of the original data through a simple iterative algorithm. Once these details are known, the attacker can append additional unauthorized parameters to the original data and generate a malicious hash value.
Mechanics of Length Extension Attacks
The susceptibility to Length Extension Attacks stems from the internal mechanisms of some hash functions. These functions initially divide the input data into fixed-length blocks and then add padding to each block to meet specific requirements. This design allows an attacker to construct new valid hashes by padding and appending new data, knowing only the original hash value and its length.
Take SHA-256 as an example. It operates on 512-bit blocks. Data lengths that are not multiples of 512 bits need to be padded according to the following rules:
1. Append a “1” bit at the end of the data;
2. Add a certain number of “0” bits so that the length of the data mod 512 equals 448;
3. Finally, append a 64-bit block indicating the length of the original data.
In summary, a sequence of “1” followed by \( m \) “0”s, plus a 64-bit or 128-bit integer representing the original message length, is added to create a padded message of length \( 512 \times n \). This padded message is then processed by the hash function into \( n \) 512-bit blocks.
Exploitation Methodology
In this example, let’s consider a specific scenario that refers to the code mentioned in the above images. The data string is `data=”user_id=1&user_name=aa”` and the secret key is `SecretKey=”Length_extension_attack_secret”`. The server will parse the uploaded data in the `data` field, splitting parameters like `user_id` and `user_name` using the ampersand (&) as a delimiter. If a `role` field exists, the server will also fetch its value. The server then hashes all the fields along with the `SecretKey` to generate a hash, which is then compared with the hash uploaded for verification. If both hashes match, the parameters are deemed to be authentic and are then utilized directly.
First, we obtain the SHA-256 hash value `hash=”37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68"` by logging into the `loginHandler` interface, using both `data` and `SecretKey`.
Next, let’s explore the difficulty level in breaking this security mechanism. Based on our testing and the principles of Length Extension Attacks, knowing both \(H(\text{message})\) and the length of the message allows us to add new data to it. Initially, the message is a combination of `SecretKey` and `data`. Now that we have \(H(\text{message})\), we only need to determine the length of the message to forge a new hash. Given that the `SecretKey` is a 30-character key, we can deduce the real length of the message after just 30 iterations. This makes it relatively straightforward to construct a new hash. Since we aim to obtain admin privileges, we’ll append the malicious field “&role=admin” to the original data.
Leveraging the characteristics of Length Extension Attacks, we can add new data and generate a new hash without even knowing `SecretKey`. For demonstration, we use a library that has already implemented this functionality [2].
The `adminActionHandler` interface performs its verification based on the uploaded `user_id`, `user_name`, and `role`. At this point, we upload the data as `user_id=1`, `user_name=aa\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x70` along with `role=admin`. (Note: A visual representation is assumed to be shown here.)
The resulting hash value is `84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0`. Following this, we can now invoke the `adminActionHandler` interface. Upon receiving the data, the server will compare the uploaded hash with \( \text{sha256}(\text{SecretKey} + \text{fakeData}) \). After successfully passing this verification, the server will proceed to execute some sensitive operations. In doing so, we have successfully exploited a Length Extension Attack to bypass server-side verification and achieve unauthorized access.
Other Possible Attack Scenarios
1. File Integrity Checks: If the integrity of a file is verified by concatenating a secret key with the file content and hashing it, attackers could extend the file and generate a valid hash, thereby bypassing the integrity check.
2. Web Application Security: In web applications, if a hash function susceptible to length extension attacks is used to validate user-submitted data, attackers could exploit this to submit malicious data.
3. Digital Signatures: In some digital signature schemes, if the signature is generated by concatenating a private key with the message and hashing it, attackers could extend the message and generate a valid signature.
4. Password Storage: Although it’s uncommon, if a password is stored by concatenating a key (like a salt) with the password and hashing it, attackers could attempt to use a length extension attack to crack the password.
How to Defend Against Such Attacks
1. Choose a Hash Function Resistant to Length Extension Attacks: For example, SHA-3 is not susceptible to these kinds of attacks.
2. Use HMAC: HMAC requires both a key and a message as inputs. The output is dependent on both, making it difficult for attackers to execute a length extension attack without knowing the key.
3. Strengthen Permission Verification: Implement additional permission verification steps on the server side, such as multi-factor authentication (MFA).
Characteristics of Common Hash Algorithms:
Conclusion
When it comes to defending against length extension attacks, one effective measure is to use hash functions that are not susceptible to this type of attack, such as SHA-3 and BLAKE2. Additionally, the use of HMAC (Hash-based Message Authentication Code) can provide another layer of security. These measures not only enhance the overall security of the system but also ensure data integrity and application stability.
References:
[1] https://www.rfc-editor.org/rfc/rfc6234#page-8
[2]https://github.com/skerkour/kerkour.com/tree/main/blog/2023/sha256_length_extension_attacks
About SlowMist
SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, Cheers UP, etc.
SlowMist offers a variety of services that include by are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. We also offer AML (Anti-money laundering) software, Vulpush (Vulnerability monitoring) , SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) , Safe Staking and other SaaS products. We have partnerships with domestic and international firms such as Akamai, BitDefender, FireEye, RC², TianJi Partners, IPIP, etc.
By delivering a comprehensive security solution customized to individual projects, we can identify risks and prevent them from occurring. Our team was able to find and publish several high-risk blockchain security flaws. By doing so, we could spread awareness and raise the security standards in the blockchain ecosystem.
Website：
https://www.slowmist.com
Twitter：
https://twitter.com/SlowMist_Team
Github：
https://github.com/slowmist/
