- The Problem
- The Tools
- Three Illustrations
- Building a Cracke
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building a Cracker
The following discussion applies to almost any program that encrypts data. The point here is to illustrate how easy it is to turn a valid program’s encryption/decryption routine into an attack vector that can crack the very files it’s meant to protect. All the more reason why it’s essential for you to use a strong password; otherwise, your data may be minutes away from being exposed.
Up to this point, the focus of this article has been demonstrating how an attacker can use a debugger to bypass flawed encryption schemes. We’ve seen that it’s fairly easy to locate the password verification routine, as it comes into the program from the user interface, or through the error message that often appears when a program rejects the wrong password. However, yet another attack vector can be used to gain access to protected data: cracking the password itself.
Any security professional will tell you that implementing an encryption algorithm is incredibly tricky. Even if the algorithm is strong enough to keep the data sufficiently protected, it must be implemented properly, or the protection efforts are essentially worthless. Ironically, due to the nature of most encryption products, a dedicated person can turn the developer’s code against the user.
Airscanner’s tradition is to return to programs where we’ve discovered bugs, in order to see whether the vendor has fixed the problems. We understand that to error is human, and if a company fixes its software, we can update our security alerts. Following that logic, we revisited the previously mentioned bugs in CodeWallet and tried to duplicate the previous finding—but failed. In other words, to our best knowledge, CodeWallet 6.62 is not longer a security risk and we can recommend this software—as long as the user selects a strong password!
During our research into this program, we discovered that the entered password is converted from its x number of characters into a 128-bit string that’s stored in the header of the file. This value is an encrypted hash of the original password, which means that anyone who wants to crack a CodeWallet file has to figure out how this hash is created and use that information as leverage against the encryption.
There are two ways in which a person can defeat a hash. The first and most commonly used method is to "brute force" your way through the hash. One program that performs this function rather well is known as Cain, from the Cain and Abel suite. As Figure 11 shows, Cain can crack any number of algorithms, and quite quickly—assuming that the user selected a weak password.
)
Figure 11 Cain’s password cracker.
The second method of defeating a hash is to bump up the hash against a pre-calculated "rainbow" table. This table is created offsite (typically by powerful supercomputers) by taking a very long list of possible password values and passing those values through the hashing algorithm. The end result is a list of passwords with their respective hashes. In order to "crack" a specific password, a malicious hacker just has to search the rainbow table for a hash match, which then can be linked directly to the original password.
With either technique, you have to know how the hash is generated from the given password. As illustrated with Cain, numerous algorithms out there can be used for this purpose. However, it appears that CodeWallet is using its own hashing/encryption algorithm. As a result, it’s impossible to take the password hash stored in the data file and run it through existing hash-cracking programs.
Instead, you could tweak the CodeWallet binary file to crack the password.
It appears that CodeWallet first turns the entered password into a hash via a proprietary algorithm, and then encrypts that value via the RC4 algorithm, using the entered password as its seed. This is only an educated guess, but if we’re correct, this isn’t a bad way to protect the password. There are better ways, but they involve public/private keys or a stronger form of encryption.
Following is a summary of how CodeWallet works:
- CodeWallet is executed, the wallet is selected, and the password window opens.
- The password is entered and the user clicks OK.
- GetWindowText captures the password and places it on the memory stack.
- The password is hashed and then encrypted to create a 128-bit key.
- The memcmp function compares the key from the file with the newly encrypted password.
- If the two match, the file is decrypted. If not, the user is warned that the wrong password was entered.
What would happen if someone patched the binary file to do the following instead?
- CodeWallet is executed, the wallet is selected, and the password window opens.
- The password is entered and the user clicks OK.
- Redirect to patch.
- One (1) is added to a hardcoded starting value, that value is written to memory for storage, and that value is placed on the stack.
- Redirect to the main program.
- The calculated password is hashed and then encrypted to create a 128-bit key.
- The memcmp function compares the key from the file with the newly encrypted password.
- Redirect to patch.
- The results are compared. If they match, the password is shown in a message box. If no match exists, the previous password is extracted from memory, one is added, and the result is placed on the stack.
- All variables are reset.
- Redirect to entry point for continued calculations.
The end result? CodeWallet should brute-force crack the password by iterating up through all possible values, checking each one until it finds the match. While nice in theory, we decided to test the idea and got to work creating a proof of concept that turned out to be a bit of a challenge.
After dealing with a few unexpected obstacles, such as enabling write access to the binary in the PE header, including a piece of code to reset the stack address, patching the binary to get around a few quirks that arose, and dealing with a NULL (0x00) byte bug, we had a password cracker that would crack any four-character ASCII password you can find on the keyboard. Figure 12 illustrates the results.
)
Figure 12 CodeWallet password.
Again, this doesn’t mean that CodeWallet is insecure—it just indicates why you should never use a four-character password to protect your sensitive data. Given enough time/motivation, any protection can be cracked. The goal for a software vendor is to balance the user’s needs with the technology to best represent those needs. Unfortunately, this balance sometimes means putting a little bit of the responsibility in the user’s camp, which consequentially can lead to inadequate security.