Security Vulnerability: AssetCryptImpl Uses Insecure Encryption Configuration

[cmtanko]

Summary

The AssetCryptImpl.java template in Titanium SDK uses AES-CBC encryption without integrity checking, making it vulnerable to padding oracle attacks. This affects all Android applications built with Titanium SDK that use asset encryption.

Affected File

android/templates/build/AssetCryptImpl.java

Current implementation:

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, 
    new SecretKeySpec(ti.cloak.Binding.getKey(salt), "AES"), 
    new IvParameterSpec(salt));

Vulnerability Details

CWE Classification

• CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
• OWASP Mobile Top 10: M5 - Insufficient Cryptography
• OWASP MASVS: MSTG-CRYPTO-3

Security Issues

1. CBC Mode Without HMAC/Integrity Checking

   • CBC mode with PKCS5/PKCS7 padding is vulnerable to padding oracle attacks
   • Without integrity checking (HMAC), attackers can manipulate ciphertext and use decryption error responses to decrypt data byte-by-byte
   • No authentication means tampering cannot be detected

2. IV Reuse and Predictability

   • The initialization vector (IV) is derived from the salt, not randomly generated
   • The same salt is used as both the IV and for key derivation
   • IVs must be unique and unpredictable for each encryption operation in CBC mode
   • Reusing IVs with the same key compromises security

3. Same Value Used as Salt and IV

   • Cryptographic best practice requires separate, distinct values for key derivation salt and encryption IV
   • Using the same value for both purposes weakens the overall security

Impact

Severity: High

An attacker with access to an APK file could:

• Extract and decrypt JavaScript assets through padding oracle attacks
• Reverse engineer application logic and business rules
• Extract hardcoded API keys, endpoints, or other sensitive information from the JavaScript code
• Modify and re-encrypt assets (if they can re-sign the APK)

Environment

• Titanium SDK Version: 12.8.0.GA (and likely all prior versions)
• Platform: Android
• Build Type: Production/Distribution builds with asset encryption enabled

Discovered By

Security assessment of production Android application built with Titanium SDK 12.8.0.GA

[hbugdoll]

[!WARNING]
In case of security issues, please note https://github.com/tidev/titanium-sdk?tab=readme-ov-file#security

[cb1kenobi]

@cmtanko Thank you very much for reporting this. I’ll take a look!

[cmtanko]

@cb1kenobi Just checking in to see if there’s been any update on this issue. Do we have a fix planned or an ETA yet, or is it still pending triage?

[cb1kenobi]

@cmtanko I have chatted with some of the other contributors my ideas for a new encryption solution. Since we don't have the source code for the current encryption/decryption, it makes it hard to triage. The best thing we can do is start from scratch. This is actually a good thing! The current implementation only encrypts source code, app props, and i18n strings. What about other data such as SQLite databases, XML, JSON, HTML, images, etc? We can fix that along with the vulnerability you reported.

We need to write the encryptor in C++ or Rust, then we have to develop Android and iOS libraries to decrypt in Java and Obj-C. This is going to take time and honestly we are tackling the more pressing issue of Node.js support (i.e. we don't support Node 24 for iOS device builds). I don't have a timeline, but once we get our Node.js packages whipped into shape and ship SDK 13.1, then I can start on a proper encryption fix.