Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Breaking Smart [Bank] Statements


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:

  1. Encrypted PDF. Used for most accounts.
  2. 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:

  • Lots of JavaScript (around 93% of the file)
  • Some CSS (approximately 6% of the file)
  • Some HTML (approximately 1% of the file)

Clearly, we must dig in the JavaScript code to understand what’s going on.

  • It has 31 JavaScript functions and a lot of variables.
    • 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:


Image001Figure 1. Logic diagram for decryption


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:

Image002Figure 2. Code of the “desenc” function


Here’s the decrypt function:

Image003Figure 3. Code of the “decrypt” function (RC4)


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).


Breaking RC4

Here is a simple diagram of how the encryption works:

Image004Figure 4. Simplified diagram of a stream cipher


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:

Image005Figure 5. Idea behind the attack


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:

DecryptFigure 6. Code of the new “decrypt” function


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