In Mexico, it’s possible to receive your monthly bank statement via email.
Mexico's banking and securities regulator (CNBV) says that security mechanisms must be applied to the bank statement to avoid an unauthorized third party.
CitiBanamex sends two types of Bank Statements via email:
- Encrypted PDF. Used for most accounts.
- Smart Statements. In 2018, it was sent only to Credit Cards of the type “Tarjetas Oro, Prestige y Beyond Citibanamex”.
The Smart Statement is an HTML file that requests a password to decrypt the content of your monthly credit card statement.
After some analysis of the HTML, here’s what it contains:
- Some CSS (approximately 6% of the file)
- Some HTML (approximately 1% of the file)
- Some are very similar: hexCrypt0, hexCrypt1, hexCrypt2, etc.
- One is particularly interesting: validatePswd
- After some beautify of the JS and following the logic, here’s a simple diagram of what’s happening:
The ‘desenc’ function is quite simple. It makes mainly two things:
- Calls one functions 30 times (push the result to an array).
- Replace the window with the content of the array.
We can see the code in the following image:
Here’s the decrypt function:
After some analysis, we can conclude it looks like RC4.
RC4 (Rivest Cipher 4) is a stream cipher, also known as ARC4 or ARCFOUR. It’s more than 20 years old (Leaked in 1994 & designed in 1987). It’s not considered a strong encryption algorithm.
The only difference with the original RC4 algorithm is line 18, since it’s not adding 1.
There are some attacks on the RC4 algorithm like “Fluhrer, Mantin and Shamir attack”, “Royal Holloway attack”, “NOMORE attack”, amongst others, but they are not simple to execute.
You should never use the same key to encrypt more than one message in any stream cipher. However, in this case, they use the same key to encrypt 30 different messages. We can take advantage of this.
The desired output is HTML, and we can perform a Known-plaintext attack since the first part of the HTML will be the same for every bank statement (it includes some CSS & JS code).
Here is a simple diagram of how the encryption works:
Since we have the Encrypted Text (it’s in the HTML) and we have the Plain Text (the first block is always the same, and we can obtain it from any Bank Statement we have access to) we can use them to obtain the keystream. Finally, we will use the keystream to decrypt the rest of the encrypted blocks.
The attack will use the following logic:
Analysis after fix
After the vendor notified us that they had fixed the issue, we verified that it was indeed fixed. They stopped using RC4, and the decrypt function now uses AES:
The use CryptoJS v3.1.2 for all the cryptographic functions and that’s a good idea.
Responsible Disclosure Timeline
This issue was disclosed to the vendor in a timely manner, and this blog post was held until the problem was fixed. Here’s the disclosure timeline:
- March 22, 2018: Disclosed to the vendor
- April 30th, 2018: Vendor responded
- July 19th, 2018: Vendor confirms the fix
To conclude this post, I would like to share some recommendations & thoughts:
- It’s a good idea to have an in-depth security review before rolling out a new product
- Hire specialists if needed
- Always use cryptography algorithms that are considered safe
- Never roll your own cryptography algorithms (nor implement them differently)
- Never use the same key more than once in a stream cipher
- If possible, have a simple, safe & clear way of communicating security issues to your organization