-
Sadrazamv4
ig:sadrazam_v4 tg: Sadrazam.spy
🔐 AES CTF Rehberi — AES Zafiyetleri, Saldırı Türleri ve Challenge Analizi
AES, günümüzde en yaygın kullanılan simetrik şifreleme algoritmalarından biridir. AES-128, AES-192 ve AES-256 doğru şekilde uygulandığında brute-force ile pratik olarak kırılabilir değildir.Bu nedenle CTF'lerde karşımıza çıkan AES challenge'larında çoğu zaman hedef doğrudan AES algoritmasını kırmak değildir.
Asıl problem genellikle:
- Yanlış AES mode kullanımı
- IV/nonce tekrar kullanımı
- Zayıf key üretimi
- Hatalı padding işlemleri
- Encryption/decryption oracle
- Authentication hataları
- Tahmin edilebilir randomness
- Uygulama mantık hataları
- Side-channel açıkları
Bu rehberin amacı, bir CTF'de AES gördüğümüzde neyi kontrol etmemiz gerektiğini ve hangi zafiyetin hangi durumda düşünüleceğini tek yerde toplamaktır.
🧩 1. Önce AES'in Temel Yapısını Bilmek
AES bir block cipher'dır ve block size her zaman:128 bit = 16 byte
'tır.
Key boyutları ise:
AES-128 → 16 byte
AES-192 → 24 byte
AES-256 → 32 byte
şeklindedir.
Önemli nokta:
AES'in temel round işlemleri:
SubBytes
ShiftRows
MixColumns
AddRoundKey
şeklindedir.
CTF açısından bunların ayrıntılarını bilmek önemli olsa da, çoğu AES challenge'ında saldırı AES'in round fonksiyonlarına değil kullanım biçimine yöneliktir.
🔎 2. Bir AES Challenge'ında İlk Bakılacak Şeyler
Challenge'ı açtığımızda doğrudan saldırıya geçmek yerine önce şu bilgileri çıkarmak gerekir:1. AES hangi mode'da?
2. Key nasıl oluşturuluyor?
3. Key sabit mi?
4. IV var mı?
5. IV nasıl oluşturuluyor?
6. Nonce kullanılıyor mu?
7. Nonce tekrar kullanılıyor mu?
8. Padding kullanılıyor mu?
9. Padding nasıl doğrulanıyor?
10. Encryption oracle var mı?
11. Decryption oracle var mı?
12. Hata mesajları farklı mı?
13. Response süreleri farklı mı?
14. Aynı key ile birden fazla ciphertext var mı?
15. Plaintext'in formatı biliniyor mu?
16. Kullanıcı plaintext üzerinde kontrol sahibi mi?
17. Randomness güvenli mi?
Bu bilgilerden sonra saldırı yöntemi çok daha kolay belirlenir.
🧱 3. ECB — Electronic Codebook
ECB, AES'in en problemli kullanım biçimlerinden biridir.Her plaintext bloğu bağımsız olarak şifrelenir:
P1 → AES(Key) → C1
P2 → AES(Key) → C2
P3 → AES(Key) → C3
Aynı key altında:
P1 = P3
ise:
C1 = C3
olur.
Bu nedenle ECB plaintext'teki tekrarları gizleyemez.
🎯 CTF'de ne yapmalıyız?
Ciphertext'i 16-byte bloklara ayırıp tekrar eden blokları kontrol etmeliyiz.Özellikle:
AES-ECB
+
encrypted token/cookie
veya:
AES-ECB
+
controlled plaintext
+
encryption oracle
görüyorsak ECB'ye yönelik saldırılar düşünülmelidir.
🥷 4. ECB Byte-at-a-Time Attack
En klasik ECB challenge'larından biridir.Örneğin uygulama:
encrypt(user_input + secret)
şeklinde çalışıyorsa kullanıcı plaintext'in bir kısmını kontrol edebilir.
ECB'nin blok bağımsızlığından yararlanılarak input uzunluğu ayarlanır ve secret'ın bilinmeyen byte'ı kontrollü bir ciphertext bloğuyla karşılaştırılır.
Genel mantık:
Input uzunluğunu ayarla
↓
Secret byte'ını blok sınırına getir
↓
Aday byte'ları dene
↓
Ciphertext bloklarını karşılaştır
↓
Eşleşen byte'ı bul
↓
Sonraki byte'a geç
🎯 CTF'de bunu ne zaman düşünmeliyiz?
Şu yapı çok güçlü bir işarettir:AES-ECB
+
encrypt() oracle
+
secret'ın plaintext'e eklenmesi
Bu durumda byte-at-a-time ECB attack ilk incelenecek yöntemlerden biridir.
✂️ 5. ECB Cut-and-Paste Attack
ECB'nin bağımsız blok yapısından kaynaklanan başka bir problem de ciphertext bloklarının yeniden kullanılabilmesidir.Örneğin:
C1 | C2 | C3 | C4
şeklindeki ciphertext'te bloklar bağımsız olduğundan farklı encryption işlemlerinden elde edilen bloklar birleştirilebilir.
Bu özellikle encrypted cookie veya token sistemlerinde önemlidir.
Örneğin plaintext:
user=guest
role=user
gibi bir yapıya sahipse ve uygulama ciphertext'i güvenilir kabul ediyorsa block manipulation mümkün olabilir.
🎯 CTF işareti
ECB+
encrypted cookie/token
+
plaintext formatı üzerinde kontrol
görüyorsak cut-and-paste saldırısını araştırmalıyız.
🔐 6. CBC — Cipher Block Chaining
CBC'de plaintext blokları birbirine zincirlenir:P1 XOR IV → AES → C1
P2 XOR C1 → AES → C2
P3 XOR C2 → AES → C3
Decrypt işlemi:
P1 = D(C1) XOR IV
P2 = D(C2) XOR C1
P3 = D(C3) XOR C2
şeklindedir.
Buradaki XOR ilişkisi CBC'nin bazı manipülasyon saldırılarına açık hale gelmesine neden olabilir.
🪓 7. CBC Bit-Flipping Attack
CBC'de:Pᵢ = D(Cᵢ) XOR Cᵢ₋₁
olduğu için önceki ciphertext bloğundaki değişiklik sonraki plaintext bloğunu etkiler.
Dolayısıyla uygulama plaintext'in belirli bir bölümünü kontrol edilebilir şekilde oluşturuyorsa ciphertext üzerinde yapılan değişikliklerle plaintext'in belirli bitlerinin değiştirilmesi mümkün olabilir.
🎯 CTF'de ne zaman düşünülmeli?
Örneğin:encrypt("role=user")
gibi bir oracle varsa ve daha sonra ciphertext:
decrypt()
veya:
is_admin()
gibi bir fonksiyona veriliyorsa CBC bit flipping incelenebilir.
Burada amaç AES key'ini elde etmek değildir.
Amaç CBC'nin matematiksel yapısından yararlanarak plaintext'i manipüle etmektir.
🧨 8. CBC IV Manipulation
CBC'nin ilk plaintext bloğu:P1 = D(C1) XOR IV
şeklindedir.
Dolayısıyla IV kontrol edilebiliyorsa ilk plaintext bloğu üzerinde kontrollü değişiklikler yapılabilir.
🎯 CTF'de kontrol edilecekler
CBC+
kontrol edilebilir IV
+
decryption veya validation
kombinasyonu varsa IV manipülasyonu araştırılmalıdır.
💣 9. CBC Padding Oracle
Padding oracle, AES-CBC challenge'larında en önemli saldırı türlerinden biridir.CBC decrypt işleminden sonra padding kontrol ediliyorsa ve saldırgan padding'in geçerli olup olmadığını gözlemleyebiliyorsa plaintext hakkında bilgi elde edilebilir.
Örneğin uygulama:
Valid padding
Invalid padding
şeklinde farklı cevaplar veriyorsa bir oracle oluşabilir.
Ancak oracle yalnızca hata mesajından ibaret olmak zorunda değildir.
Şunlar da bilgi sızıntısı oluşturabilir:
HTTP status code
Response length
Response content
Connection behavior
Response time
🎯 CTF'de ne yapmalıyız?
Şunları özellikle kontrol etmeliyiz:Invalid padding
Bad padding
Padding error
Decrypt failed
Different HTTP status
Different response length
Different timing
Bunlardan biri varsa CBC padding oracle ihtimali araştırılmalıdır.
⚡ 10. CTR Mode
CTR, AES'i stream cipher benzeri şekilde kullanır.Basitleştirilmiş olarak:
Keystream = AES(Key, Counter)
Ciphertext = Plaintext XOR Keystream
şeklindedir.
Buradaki kritik konu nonce/counter değerinin tekrar kullanılmamasıdır.
☠️ 11. CTR Nonce Reuse
Aynı key ve aynı nonce/counter başlangıcı tekrar kullanılırsa aynı keystream üretilebilir.Örneğin:
C1 = P1 XOR K
C2 = P2 XOR K
ise:
C1 XOR C2
=
P1 XOR P2
elde edilir.
Bu nedenle AES-CTR'de nonce reuse ciddi bir problemdir.
🎯 CTF'de ne yapmalıyız?
Birden fazla ciphertext veriliyorsa:AES-CTR
+
same nonce
+
same key
kombinasyonunu kontrol etmeliyiz.
Özellikle challenge source code'u verilmişse nonce'un her encryption işleminde nasıl üretildiğine bakmak çok önemlidir.
🔁 12. Two-Time Pad
CTR nonce reuse sonucu ortaya çıkan problem genellikle two-time pad olarak düşünülür.Aynı keystream:
P1 XOR K
P2 XOR K
şeklinde iki farklı plaintext'te kullanılırsa ciphertext'ler XORlandığında keystream ortadan kalkar:
C1 XOR C2 = P1 XOR P2
Plaintext formatının tahmin edilebilir olması burada büyük avantaj sağlayabilir.
Örneğin:
flag{
{"username":
HTTP/1.1
gibi bilinen formatlar analiz sırasında kullanılabilir.
🔥 13. AES-GCM
GCM, AES encryption'ın yanında authentication da sağlayan bir authenticated encryption mode'udur.Genellikle:
Nonce
Ciphertext
Authentication Tag
AAD
gibi bileşenlerle karşılaşılır.
GCM challenge'larında yalnızca ciphertext'e bakmak yeterli değildir.
Şunların tamamı incelenmelidir:
Nonce nasıl oluşturuluyor?
Nonce tekrar ediyor mu?
Tag nasıl doğrulanıyor?
AAD kullanılıyor mu?
Key tekrar kullanılıyor mu?
💥 14. GCM Nonce Reuse
GCM'de aynı key ile nonce'un tekrar kullanılması ciddi güvenlik problemlerine neden olabilir.Bu yüzden:
AES-GCM
+
same nonce
+
same key
+
multiple messages
görülüyorsa nonce reuse mutlaka araştırılmalıdır.
GCM challenge'larında nonce tekrarları bazen doğrudan source code'da, bazen de verilen ciphertext paketlerinde fark edilebilir.
🏷️ 15. Authentication Tag Problemleri
GCM'deki authentication tag, ciphertext'in değiştirilmediğini doğrulamak için kullanılır.Challenge'da:
ciphertext
+
tag
veriliyorsa tag'in nasıl doğrulandığına bakılmalıdır.
Özellikle uygulamanın:
tag verification
işlemini yanlış gerçekleştirmesi önemli olabilir.
Burada hedef AES-GCM algoritmasının matematiğini brute-force etmek değil, authentication mekanizmasının hatalı uygulanıp uygulanmadığını belirlemektir.
🧂 16. AAD — Additional Authenticated Data
GCM'de AAD şifrelenmez fakat authentication işlemine dahil edilir.Örneğin:
AAD = role=user
gibi bir veri bulunabilir.
CTF'de AAD kullanılıyorsa:
AAD nereden geliyor?
Değiştirilebilir mi?
Tag doğrulamasına nasıl dahil ediliyor?
Uygulama AAD'yi doğru kullanıyor mu?
soruları incelenmelidir.
🔑 17. Weak Key
AES'in güvenliği kullanılan key'in güvenliğine de bağlıdır.Örneğin:
key = b"password12345678"
gibi tahmin edilebilir bir key kullanılması AES'in kırıldığı anlamına gelmez.
Sorun key generation'dadır.
CTF'de:
AES
+
predictable key
görülüyorsa key'in nasıl üretildiğine odaklanmak gerekir.
🔓 18. Password-Based Key Derivation
Bazı challenge'larda AES key'i bir password'den türetilir:password
↓
hash/KDF
↓
AES key
Örneğin:
key = MD5(password)
veya:
key = SHA256(password)
gibi basit yapılar görülebilir.
Burada incelenmesi gerekenler:
Password tahmin edilebilir mi?
Salt kullanılıyor mu?
KDF kullanılıyor mu?
KDF yeterince güçlü mü?
Password doğrudan key'e mi dönüştürülüyor?
AES'in kendisini kırmak yerine password/key generation mekanizması incelenmelidir.
🎲 19. Weak Randomness
Kriptografik key, IV veya nonce üretiminde güvenli randomness gerekir.CTF source code'unda:
random
random.seed()
time.time()
timestamp
gibi yapılar görüyorsanız randomness mekanizmasını inceleyin.
Örneğin:
timestamp
↓
PRNG seed
↓
AES key
gibi bir zincir varsa key tahmin edilebilir hale gelebilir.
Burada saldırı AES'e değil random number generation mekanizmasına yönelir.
🔁 20. Fixed IV
Örneğin:IV = b"1234567890123456"
gibi sabit bir IV kullanılıyorsa CBC açısından ciddi bir kırmızı bayraktır.
Özellikle:
CBC
+
same key
+
fixed IV
+
multiple encryptions
kombinasyonu incelenmelidir.
🩹 21. Padding Problemleri
AES block size:16 byte
olduğu için plaintext'in uzunluğu uygun değilse padding uygulanabilir.
Yaygın yöntemlerden biri:
PKCS#7
padding'dir.
Örneğin bir block'u tamamlamak için gereken byte sayısı 03 ise:
03 03 03
eklenebilir.
Padding oracle saldırılarını anlayabilmek için padding mantığını doğru anlamak önemlidir.
⏱️ 22. Timing Side Channel
Bazı challenge'larda doğrudan:valid / invalid
gibi bir cevap bulunmaz.
Bunun yerine işlemin tamamlanma süresi farklı olabilir.
Örneğin:
Input A → response time X
Input B → response time Y
şeklinde istatistiksel olarak anlamlı bir fark oluşuyorsa timing oracle ihtimali değerlendirilmelidir.
Özellikle:
authentication
tag verification
padding validation
gibi işlemlerde timing davranışları incelenebilir.
🧠 23. Side-Channel Attacks
Daha ileri seviye CTF'lerde AES'in matematiksel yapısı yerine implementasyonun fiziksel veya mikro-mimari sızıntıları hedeflenebilir.Örnekler:
Cache Timing
Power Analysis
Electromagnetic Analysis
Fault Injection
Bu tür challenge'larda AES'in kendisi doğru uygulanmış olsa bile işlem sırasında ortaya çıkan yan kanallar secret hakkında bilgi sağlayabilir.
Bu alan normal crypto challenge'larından daha ileri seviyededir.
🧮 24. Known Plaintext
Plaintext'in bir kısmını bilmek:flag{????????}
gibi,
tek başına AES key'ini bulmaya yetmez.
Ancak aşağıdaki gibi bir başka zafiyet varsa oldukça değerli olabilir:
ECB
CTR nonce reuse
CBC manipulation
Dolayısıyla known plaintext'i tek başına bir saldırı olarak değil, başka saldırıları destekleyen bilgi olarak değerlendirmek gerekir.
🚫 25. Brute Force Ne Zaman Mantıksızdır?
AES-128 için key space:2^128
AES-256 için:
2^256
seviyesindedir.
Bu nedenle normal bir CTF challenge'ında:
AES-256
→ brute force
yaklaşımı mantıklı değildir.
AES key'inin gerçekten random ve güvenli üretildiği bir challenge'da başka bir zafiyet aramak gerekir.
Eğer challenge çözülebilir olarak tasarlanmışsa çoğu zaman:
Weak key
Weak RNG
Oracle
Nonce reuse
IV reuse
Implementation bug
gibi bir açık vardır.
🧭 26. AES Challenge İçin Pratik Analiz Sırası
Bir challenge'da AES gördüğümüzde şu sırayla ilerlemek oldukça kullanışlıdır:AES
↓
Mode'u belirle
↓
Key'i incele
↓
IV / nonce'u incele
↓
Reuse var mı kontrol et
↓
Padding'i belirle
↓
Oracle var mı kontrol et
↓
Input kontrolünü incele
↓
Ciphertext yapısını analiz et
↓
Implementation'ı incele
↓
Uygun saldırıyı seç
Örneğin:
AES-ECB
→ ECB pattern / byte-at-a-time / cut-and-paste
AES-CBC
→ IV / padding / bit flipping / padding oracle
AES-CTR
→ nonce reuse / keystream reuse
AES-GCM
→ nonce / authentication tag / AAD / implementation
AES + password
→ password/key derivation
AES + random/time
→ RNG analizi
şeklinde düşünmek oldukça iyi bir başlangıç noktasıdır.
📋 27. AES CTF Checklist
Bir AES challenge'ında aşağıdaki checklist'i kullanabiliriz:[ ] AES version belirlendi
[ ] AES mode belirlendi
[ ] Block size kontrol edildi
[ ] Key size kontrol edildi
[ ] Key'in kaynağı bulundu
[ ] Key'in random olup olmadığı kontrol edildi
[ ] IV bulundu
[ ] IV'nin random olup olmadığı kontrol edildi
[ ] IV reuse kontrol edildi
[ ] Nonce bulundu
[ ] Nonce reuse kontrol edildi
[ ] Padding yöntemi belirlendi
[ ] Padding validation incelendi
[ ] Encryption oracle kontrol edildi
[ ] Decryption oracle kontrol edildi
[ ] Error behavior incelendi
[ ] Response length incelendi
[ ] Timing behavior incelendi
[ ] Aynı key ile birden fazla ciphertext kontrol edildi
[ ] Plaintext formatı incelendi
[ ] ECB block repetition kontrol edildi
[ ] Ciphertext manipulation ihtimali değerlendirildi
[ ] Key derivation incelendi
[ ] Randomness incelendi
[ ] Source code varsa implementation incelendi
🏆 28. En Önemli Mental Model
AES challenge'larında en önemli alışkanlık şudur:Şöyle düşünün:
AES
│
┌────────┴────────┐
│ │
Mode Key
│ │
ECB/CBC/... nasıl üretiliyor?
│ │
IV/Nonce RNG/KDF
│ │
Padding entropy
│
Oracle
│
Implementation
│
▼
Vulnerability
│
▼
Attack
AES'in kendisi sağlam olabilir.
Fakat:
AES + ECB
AES + reused nonce
AES + fixed IV
AES + weak RNG
AES + weak key
AES + padding oracle
AES + bad authentication
AES + implementation bug
kombinasyonlarından biri challenge'ın tamamını çözmeye yetecek bir zafiyet oluşturabilir.
🔥 29. Kısacası: AES Görürsen Ne Yapacaksın?
En kısa haliyle:ECB?
→ Block analysis
ECB + oracle?
→ Byte-at-a-time
ECB + token?
→ Cut-and-paste
CBC?
→ IV + padding + manipulation
CBC + controllable IV?
→ IV manipulation
CBC + padding error?
→ Padding oracle
CBC + controllable plaintext?
→ Bit flipping
CTR?
→ Nonce kontrolü
CTR + nonce reuse?
→ Keystream reuse
GCM?
→ Nonce + tag + AAD
AES + password?
→ Key derivation
AES + timestamp/random?
→ RNG
Farklı hata davranışı?
→ Oracle
Farklı response time?
→ Timing side-channel
Çok sayıda ciphertext?
→ Key/IV/nonce reuse
Garip custom AES implementation?
→ Implementation bug
Son olarak en önemli ayrım:
CTF'lerde genellikle ikinci alanla karşılaşırız.
Bu yüzden iyi bir AES CTF çözücüsü yalnızca “AES nasıl çalışıyor?” sorusunu değil, aynı zamanda:
sorusunu da sorar. 🔐
