Ethereum2john format not Private-Key Safe - Needs warning for new users

[Chick3nman]

The script, https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/run/ethereum2john.py, for extracting Ethereum wallet hashes produces an output that includes enough information for anyone with the formatted "hash" to decipher the wallet contents and expose the private keys upon successful password recovery. I suggest we add a standard warning printed during/before every extraction that will warn the user not to share the hash with untrusted parties.

@kholia

I'm looking for feedback before adding this in a PR. If you want to go ahead and do this, feel free.

There may be other formats that have similar private data exposures, such as 7zip archives, that may also need a warning added to them though this format is especially damaging due to the direct association with large amounts of money.

[solardiz]

I support this request/idea.

Ideally, we'd also add a way to crack more of these things without such exposures, or mitigating the exposures at least partially. Password recovery for cryptocoin wallets is in demand and a lot of (most?) people who forgot their wallet passwords are not tech-savvy enough to use/tune JtR well, so I wish it were possible for more capable users of JtR to provide this as a service without such risks. (And right now it's risks even to whoever provides the service - they'd be suspected of theft even if they don't steal anything but someone else does, via whatever other means.)

When we're relying on CBC padding to verify successful guesses, perhaps we only need two last blocks? Maybe we could encode only those two, and only decrypt the last one? That would also speed things up a little bit. Now, whether two last blocks of a private key are (enough to recover) the whole key or not will vary (what key size, public key cryptosystem, randomness) - we'd need to also look into this. Just thinking out loud.

[magnumripper]

@kholia is busy FTM with real-life upgrades. We'd love a PR adding a warning message, for a start.

[Chick3nman]

@solardiz This is impossible with some modes, sadly. Currently, the verification for presale ether wallets is done via the SHA3 hash, there is no way to perfectly verify the success of a password otherwise since the data contained in the AES is simply the key data. The SHA3 hash is of the mac portion combined with the entire decrypted private key/wallet information so we must first decrypt all of the AES data, then hash the decrypted value + mac to see if the password is the correct original password. This loops the entire AES portion of the wallet file into the attack. It's an annoying problem.

When I get a chance, I will create a PR for at least the ethereum script that shows the warning. Bit busy right now but I can definitely have it done by later today.

[solardiz]

Thanks, @Chick3nman.

Sure what I suggested will sometimes be impossible, but I think there are also formats/modes where it's possible - e.g., in the below excerpt from ethereum_fmt_plug.c maybe (just maybe!) the padding checks are sufficient to have a negligible chance of false positives and we do not really have to do the SHA-3? Maybe this varies by the amount of padding (that is, how far from full the last block is)?

                                AES_set_decrypt_key(master[i], 128, &akey);
                                memcpy(iv, cur_salt->encseed, 16);
                                AES_cbc_encrypt(cur_salt->encseed + 16, seed, cur_salt->eslen - 16, &akey, iv, AES_DECRYPT);
                                if (check_pkcs_pad(seed, cur_salt->eslen - 16, 16) < 0) {
                                        memset(crypt_out[index+i], 0, BINARY_SIZE);
                                        continue;
                                }
                                padbyte = seed[cur_salt->eslen - 16 - 1];
                                datalen = cur_salt->eslen - 16 - padbyte;
                                if (datalen < 0) {
                                        memset(crypt_out[index+i], 0, BINARY_SIZE);
                                        continue;
                                }
                                Keccak_HashInitialize(&hash, 1088, 512, 256, 0x01);
                                Keccak_HashUpdate(&hash, seed, datalen * 8);
                                Keccak_HashUpdate(&hash, dpad.data, 1 * 8);
                                Keccak_HashFinal(&hash, (unsigned char*)crypt_out[index+i]);

[Chick3nman]

It could be possible to implement a "Key Safe" mode+format, where you give up the verification, take the chance of having some false positives, but do so in a "Key Safe" way so that you can let others try as well without risking your keys.

[solardiz]

That's what I mean, but perhaps we can also estimate the chance of false positives - e.g., with 6+ bytes of padding it's probably low enough, and with 8+ negligible. The *2john tools can know this and report on it, or choose to output different things (and print different messages accordingly) depending on it.

[Chick3nman]

Submitted a PR for the Ethereum script to start. Other formats that are similar will need to be identified and worked on. A "safe mode" would be a cool feature as well, though I feel like we'd hit quite a few collision on this mode in particular. Hard to say for sure, will need to look into a bit more.

[kholia]

@Chick3nman Thanks for the PR!

Typically the *2ohn.py tools are non-interactive, and don't require interaction with the user after they start. This make redirecting the output of such programs to output files possible easily.

Currently proposed change,

sys.stdout.write("WARNING: Upon successful password recovery, this hash format may expose your PRIVATE KEY. Do not share extracted hashes with any untrusted parties!")
reply = str(raw_input('\nDo you wish to continue? (y/n): ')).lower().strip()
if reply[0] != 'y':
    return

Perhaps showing the warning message on stderr and not prompting the user for input is good enough (though perhaps not as safe as your approach)?

sys.stderr.write("WARNING: Upon successful password recovery, this hash format may expose your PRIVATE KEY. Do not share extracted hashes with any untrusted parties!")

Is such a trade-off acceptable?

[Chick3nman]

Sure, that's perfectly acceptable. I tend to prompt the user with an interactive block when warning them of things because I've learned that users ignore warnings almost every time if they aren't required to step through it. In this case, its not going to immediately cause harm and the users will likely be already hesitant to share so printing to stderr to keep things simple should be adequate.

[kholia]

The warning message is in place now. Hence, I am closing this issue now.