Challenge 63 ☆☆

Welcome to challenge Challenge 63.

Hardcoded Encryption Key Challenge

This challenge demonstrates a common but dangerous mistake: encrypting a secret while hardcoding the encryption key in the same source file.

A developer has attempted to protect a secret by encrypting it with AES. However, both the encryption key and the initialization vector (IV) are hardcoded directly in the Java source code alongside the ciphertext. This makes the encryption completely ineffective — anyone with access to the source code can decrypt the secret trivially.

Your goal: 1. Find the Java source file for this challenge in the codebase 2. Locate the hardcoded AES key and IV in the source code 3. Decrypt the ciphertext using the key and IV you found 4. Submit the plaintext as your answer

How to decrypt:

echo "TDPwOvcLsbCWV5erlk6OHFnlFoXNtdQOt2JQeq+i4Ho=" | openssl enc -d -aes-128-cbc \
  -K $(echo -n "SuperSecretKey12" | xxd -p) \
  -iv $(echo -n "InitVector123456" | xxd -p) \
  -base64
💡 Tip: Secrets are often strings, numbers, or encoded values. Copy and paste exactly what you find.

Hint for Challenge 63

This challenge demonstrates bad encryption practices — specifically hardcoding an encryption/decryption key in source code.

Where to look: 1. Find the Challenge63 Java source file in the challenges/docker/challenge63/ directory 2. Look for static final String constants near the top of the class 3. You will find the AES key, IV, and ciphertext all in the same file

How to decrypt once you have the key:

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import base64

key = b'SuperSecretKey12'
iv  = b'InitVector123456'
ciphertext = base64.b64decode("TDPwOvcLsbCWV5erlk6OHFnlFoXNtdQOt2JQeq+i4Ho=")

cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend())
decryptor = cipher.decryptor()
plaintext = decryptor.update(ciphertext) + decryptor.finalize()
print(plaintext.strip())

Remember: If an attacker can read your source code, hardcoded keys offer zero protection.

Reason for Challenge 63

This challenge highlights a widespread mistake in software development: using encryption while storing the key in the same location as the ciphertext.

Why this is dangerous: - Encryption is only as strong as the secrecy of the key - Hardcoding the key in source code means anyone with repository access can decrypt the secret - Source code is often more widely accessible than developers realize — through Git history, leaked repos, or insider access - Many secret scanning tools will detect both the key and ciphertext patterns

The correct approach: - Store encryption keys in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.) - Never commit keys to version control - Use environment variables for keys, not source code constants - Consider whether encryption is even necessary if the key must live near the data

Real world examples: This exact pattern has been found in numerous data breaches where developers believed their secrets were "safe" because they were encrypted, not realizing the key was equally exposed.

Additionally, this challenge uses AES in CBC mode which is vulnerable to padding oracle attacks. Production code should use AES/GCM instead.

References: - OWASP Top 10 - OWASP Secrets Management Cheat Sheet


⬅️ Previous
🏠 Main Page
Next ➡️
0