A02:2021 – Cryptographic Failures

Faktörler

CWEs Eşleştirildi	Maks Görülme Oranı	Ort. Görülme Oranı	Ort. Ağırlıklı Exploit	Ort. Ağırlıklı Impact	Maks Coverage	Ort. Coverage	Toplam Olay	Toplam CVE
29	46.44%	4.49%	7.29	6.81	79.33%	34.85%	233,788	3,075

Genel Bakış

Daha önce Sensitive Data Exposure olarak bilinen ve bir kök neden yerine daha çok geniş bir semptomu tanımlayan kategori, bir basamak yükselerek #2’ye geldi. Odak noktası, kriptografiyle (veya yokluğuyla) ilgili hatalardır. Bunlar çoğu zaman hassas verilerin açığa çıkmasına yol açar. Dikkate değer Common Weakness Enumeration (CWE) örnekleri arasında CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm ve CWE-331: Insufficient Entropy yer alır.

Açıklama

İlk yapılacak şey, hem transit halinde hem de at rest durumundaki verilerin korunma ihtiyacını belirlemektir. Örneğin parolalar, kredi kartı numaraları, sağlık kayıtları, kişisel bilgiler ve ticari sırlar; özellikle bu veriler gizlilik yasalarına (ör. AB’nin GDPR’ı) veya düzenlemelere (ör. finansal veriler için PCI DSS) tabi ise, ekstra koruma gerektirir. Böyle veriler için:

Herhangi bir veri clear text olarak mı iletiliyor? Bu, HTTP, SMTP, FTP gibi protokolleri ve STARTTLS gibi TLS upgrade’lerini de kapsar. Harici internet trafiği tehlikelidir. Load balancer’lar, web server’lar veya back-end sistemler arasındaki tüm internal trafiği doğrulayın.
Varsayılan olarak veya eski kodlarda herhangi bir eski/zayıf kriptografik algoritma ya da protokol kullanılıyor mu?
Varsayılan crypto key’ler mi kullanılıyor, zayıf key’ler mi üretiliyor veya doğru key management/rotation eksik mi? Crypto key’ler source code repository’lere commitlenmiş mi?
Encryption zorunlu kılınmıyor mu; örneğin (browser) security directive’leri veya HTTP header’ları eksik mi?
Alınan server certificate ve trust chain düzgün biçimde doğrulanıyor mu?
Initialization vector’lar (IV) yok sayılıyor, yeniden kullanılıyor veya ilgili mode of operation için yeterince güvenli üretilmiyor mu? ECB gibi güvenli olmayan bir mode kullanılıyor mu? Sadece encryption yerine authenticated encryption daha uygunken yanlış kullanım var mı?
Password-based key derivation function olmaksızın parolalar crypto key olarak mı kullanılıyor?
Kriptografik amaçlar için tasarlanmamış randomness mi kullanılıyor? Doğru fonksiyon seçilmiş olsa bile developer tarafından seed edilmesi gerekiyor mu ve eğer gerekmiyorsa, developer güçlü seeding’i düşük entropy/tahmin edilebilir bir seed ile ezmiş olabilir mi?
MD5 veya SHA1 gibi deprecated hash fonksiyonları kullanılıyor mu ya da kriptografik hash gereken yerlerde non-cryptographic hash fonksiyonları mı kullanılıyor?
PKCS number 1 v1.5 gibi deprecated cryptographic padding yöntemleri kullanılıyor mu?
Cryptographic error message’lar veya side-channel bilgiler exploitable mı; örneğin padding oracle saldırılarıyla?

ASVS Crypto (V7), Data Protection (V9) ve SSL/TLS (V10)’a bakın.

Nasıl Önlenir

Minimum olarak şunları yapın ve referansları danışın:

Uygulamanın işlediği, depoladığı veya ilettiği verileri sınıflandırın. Hangi verilerin gizlilik yasaları, düzenleyici gereklilikler veya iş ihtiyaçları açısından hassas olduğunu belirleyin.
Gereksiz yere hassas veri depolamayın. Mümkün olan en kısa sürede atın veya PCI DSS uyumlu tokenization ya da truncation kullanın. Saklanmayan veri çalınamaz.
Tüm hassas verileri at rest durumda encrypt edin.
Güncel ve güçlü standart algoritma, protokol ve key’leri kullanın; doğru key management uygulayın.
Tüm verileri in transit durumda TLS gibi secure protocol’lerle encrypt edin; forward secrecy (FS) cipher’ları, server tarafında cipher önceliklendirmesi ve secure parametreler kullanın. HTTP Strict Transport Security (HSTS) gibi directive’lerle encryption’ı zorunlu kılın.
Hassas veri içeren response’lar için caching’i devre dışı bırakın.
Veri sınıflandırmasına göre gerekli security control’lerini uygulayın.
Hassas veri taşımak için FTP ve SMTP gibi legacy protokolleri kullanmayın.
Parolaları Argon2, scrypt, bcrypt veya PBKDF2 gibi güçlü, adaptive ve salted hashing function’larıyla, uygun work factor (delay factor) kullanarak saklayın.
Initialization vector (IV) seçimi mode of operation’a uygun olmalıdır. Birçok mode için CSPRNG (cryptographically secure pseudo random number generator) uygundur. Nonce gerektiren mode’larda IV için CSPRNG gerekmez. Tüm durumlarda, sabit bir key için aynı IV asla iki kez kullanılmamalıdır.
Sadece encryption yerine her zaman authenticated encryption kullanın.
Key’ler kriptografik olarak rastgele üretilmeli ve memory’de byte array olarak saklanmalıdır. Eğer password kullanılacaksa, uygun bir password-based key derivation function ile key’e dönüştürülmelidir.
Gereken yerlerde kriptografik randomness kullanıldığından ve tahmin edilebilir/düşük entropy ile seed edilmediğinden emin olun. Modern API’lerin çoğu güvenlik için developer’ın CSPRNG’yi seed etmesini gerektirmez.
MD5, SHA1, PKCS number 1 v1.5 gibi deprecated kriptografik fonksiyon ve padding şemalarından kaçının.
Konfigürasyon ve ayarların etkinliğini bağımsız şekilde doğrulayın.

Örnek Saldırı Senaryoları

Senaryo #1: Bir uygulama, veritabanındaki kredi kartı numaralarını otomatik veritabanı encryption’ı ile şifreliyor. Ancak bu veriler geri çekildiğinde otomatik olarak decrypt ediliyor; bu da bir SQL injection açığının kredi kartı numaralarını clear text olarak almasına izin veriyor.

Senaryo #2: Bir site tüm sayfalar için TLS kullanmıyor/enforce etmiyor veya zayıf encryption destekliyor. Bir saldırgan (ör. güvensiz bir kablosuz ağda) ağ trafiğini izliyor, bağlantıları HTTPS’ten HTTP’ye downgrade ediyor, istekleri kesiyor ve kullanıcının session cookie’sini çalıyor. Saldırgan daha sonra bu cookie’yi yeniden oynatıp kullanıcının (authenticated) oturumunu ele geçiriyor ve özel verilere erişiyor veya bunları değiştiriyor. Alternatif olarak taşınan tüm verileri de manipüle edebilir (ör. bir para transferinin alıcısını).

Senaryo #3: Parola veritabanı, herkesin parolasını unsalted veya basit hash’lerle saklıyor. Bir file upload açığı, saldırganın parola veritabanını almasına izin veriyor. Tüm unsalted hash’ler, önceden hesaplanmış hash’lerin bulunduğu rainbow table ile açığa çıkarılabiliyor. Basit veya hızlı hash fonksiyonlarıyla üretilen hash’ler, salted olsalar bile GPU’larla kırılabilir.