Bugünün planı (3 saat)

Öğrenme çıktısı: ÖÇ.1 (yaygın yazılım güvenlik açıklarını tanımlar ve sınıflandırır)

Önceki haftalardan gelenler

• Varlık, tehdit, zafiyet, risk ve saldırgan modeli — bir varlığın değerini, ona yönelik tehdidi, zafiyeti ve
  olasılık × etki olan riski ayırt etme dili (Hafta 1)
• STRIDE ve saldırı ağacı — bir arayüzdeki tehditleri STRIDE'ın altı harfiyle sorup kök hedeften dallara
  VE/VEYA mantığıyla ayrıştırma yöntemi (Hafta 1)

Bu hafta: bu dili zararlı yazılım (tehdit) ve erişim modelleri (savunma) üzerinden somutlaştırıyoruz; saldırı
ağacına maliyet ekleyip en ucuz saldırı yolunu hesaplıyoruz (Demo 04).

Demolar nasıl çalışıyor?

• Tek kaynak, iki platform: Windows (Visual Studio 2022 Community, MSVC) ve WSL/Linux (GCC)
• Özet/şifreleme gerektiren demolarda Windows'ta işletim sisteminin BCrypt kütüphanesi, Linux'ta OpenSSL
  kullanılır (code/common/cen429_crypto.h) — Windows'ta ayrıca OpenSSL kurmanız gerekmez
• Derle: Windows .\build.ps1 · WSL/Linux ./build.sh
• Çalıştır: her demo klasöründe Windows .\demo.ps1 · WSL/Linux sh demo.sh
• Demo 6 (TOCTOU) yalnız WSL/Linux'ta çalışır

⚠️ Etik: Hiçbir demoda gerçek zararlı yazılım, kendini çoğaltan kod, dosya silme/şifreleme ya da ağ
saldırısı yoktur. Hepsi kendi klasöründe, yönetici yetkisi olmadan çalışan güvenli benzetimlerdir;
öğrendiklerinizi yalnız kendi bilgisayarınızda deneyin.

"Virüs" her şey değildir

Zararlı yazılım (malware): sahibinin izni dışında zarar veren her program.

• Virüs, zararlı yazılımın yalnızca bir türüdür.
• Ayrım nasıl yayıldığına göre yapılır:
  • Virüs: başka dosyaya iliştirilir, taşıyıcı çalışınca yayılır
  • Solucan: kendi başına, ağ üzerinden yayılır
  • Truva atı: masum görünür, kendini kopyalamaz
  • Fidye / rootkit / bot / silici: yük ya da davranış türleri

Haftanın üç parçası — şema

• Tehdit: zararlı yazılım türleri ve gizlenmesi
• Savunma: erişim denetimi ve biçimsel modeller
• Ortak dil: CWE · CVE · CVSS · OWASP · MASVS

Zararlı yazılımın kısa tarihi — şema

Cohen 1984: tespitin sınırı

Bir virüs, kendini (belki değiştirerek) başka programlara kopyalayabilen programdır.

• Cohen kanıtladı: "Bu program virüs mü?" sorusunu her durumda doğru yanıtlayan genel bir algoritma yoktur (durma probleminden indirgenir).
• Pratik sonuç: hiçbir antivirüs %100 tespit edemez.
  • ✅ Yanlış pozitif: temiz dosyayı yakalar
  • ❌ Yanlış negatif: zararlıyı kaçırır

Bunu Demo 01'de kendi gözümüzle göreceğiz.

Bir virüsün üç parçası

• Tetikleyici koşulu bekleyip patlayan koda mantık bombası denir.
• Her parça zorunlu değildir: yalnız yayılan, yüksüz bir virüs de vardır (yine de zafiyettir).

Virüsün üç parçası — şema

Virüs alt türleri

• Program (dosya) virüsü: çalıştırılabilir dosyaya bulaşır; dosya çalışınca virüs de çalışır.
• Makro virüsü: ofis belgesinin makro diline yazılır; belge açılınca çalışır (Melissa, 1999).
• Önyükleme sektörü virüsü: diskin ilk sektörüne bulaşır, işletim sisteminden önce çalışır (Brain, 1986).
  • Modern UEFI Secure Boot bu sınıfı büyük ölçüde zorlaştırdı.

Solucan, truva atı, fidye

Solucanın tehlikesi hızdır: dakikalar içinde yüz binlerce makine.

Diğer türler

• Rootkit: kendini ve diğer zararlıları işletim sisteminden gizler (dosya/süreç/ağ listesinden siler). Tespiti en zor sınıf.

• Bot / botnet: uzaktan komut alan makineler ağı (DDoS, spam, madencilik).

• Casus / reklam yazılımı: veri toplar ya da reklam gösterir.

• Silici (wiper): fidye gibi görünür ama veriyi kalıcı yok eder (NotPetya). Amaç para değil, yıkım.

• Arka kapı (backdoor): gizli erişim bırakır.

Solucan ne kadar hızlı yayılır?

SI modeli — duyarlı (S) ve enfekte (I) makineler:

i(t+dt) = i(t) + beta * i(t) * (1 - i(t)/N) * dt

• beta * i: enfekte çoğaldıkça tarama hızlanır → üstel büyüme
• (1 - i/N): duyarlı azaldıkça isabet düşer → doygunluk
• Sonuç: sessiz açılış → ani patlama → doygunluk (S eğrisi)

⚠️ Savunmacının tek penceresi açılış evresi

SI modeli: adım adım

• S (duyarlı): henüz bulaşmamış, savunmasız makine.
• I (enfekte): zaten bulaşmış, kendisi de tarayan makine.
• N: toplam savunmasız makine sayısı (S + I).
• Her enfekte makine birim zamanda rastgele adres tarar; adres duyarlıya denk gelirse onu da enfekte eder.

Salgın modeli — şema

Slammer neden yavaşladı?

• İlk dakikadan sonra yayılma hızı düştü.
• Neden? Savunma değil — ağın bant genişliği doldu.
• Solucan kendi trafiğiyle kendi yayılma kanalını tıkadı.
• Ders: bazen saldırganın kendi başarısı, kendi sınırını yaratır.

İkiye katlanma süresi

• Enfekte sayısının iki katına çıkması için geçen süre, bir salgının hızının en sezgisel ölçüsüdür.
• Code Red: ikiye katlanma ~37 dakika.
• Slammer: ikiye katlanma ~8,5 saniye.
• Aradaki fark ~260 kat — ikisi de "solucan" olsa da savunma penceresi tamamen farklıdır.

Demo 09 çıktısını okurken: açılış evresi

• İlk 54 saniyede yalnız 78 makine enfekte (%0.1).
• Grafikte neredeyse hiçbir şey görünmüyor.
• 1,5 dakika sonra patlama başlıyor.
• "Şimdilik az" demek, üstel büyümede en pahalı yanılgıdır.

Demo 09 çıktısını okurken: hız ve hitlist

• Hız (beta): tarama hızını artırmak, doygunluğu saatlerden dakikalara indirir.
• Bu yüzden savunma otomatik olmalı: güvenlik duvarı kuralı, ağ bölümleme, önceden yama.
• Hitlist: saldırgan hazır hedef listesiyle başlarsa açılış evresi atlanır.
• Savunmacının zaten dar penceresi tamamen kapanır.

SI salgın modeli: yayılma adım adım (animasyon)

Salgın — uç durum: başlangıçta zaten yarısı bulaşmış

Programcıya ders (salgın)

• Yayılma hızını programcı belirlemez.
• Ama ilk bulaşmayı mümkün kılan hatayı programcı yapar.
• Code Red, Slammer, Blaster — hepsi sınır denetimsiz bir taşma ile yayıldı.
• Her dinlenen ağ portu bir saldırı yüzeyidir; kullanılmayan hizmeti hiç açmayın.

Kendiniz deneyin: beta yarıya inerse?

outbreak.c içindeki beta değerini yarıya indirip yeniden çalıştırın.

Soru: Doygunluk süresi nasıl değişir? Hitlist senaryosunda i0'ı 100'e çıkarınca fark ne kadar kalır?

Cevap: Beta yarıya inince büyüme yavaşlar, doygunluk süresi uzar. Hitlist senaryosunda açılış evresi zaten atlandığı için i0 artışının etkisi daha küçüktür — hitlist'in asıl gücü açılışı atlaması, başlangıç sayısı değil.

Demo 01 — Oyuncak antivirüs

code/week-02/01-signature-scanner · Kitap: Tarif 12.1

• Zararsız, çalıştırılamayan bir "KAPSÜL" biçimi: başlık + çözücü + gövde.
• Dört yöntem, dört sınır:

Demo 01 — Hash kırılgan, desen dayanıklı

STEP 2 (hash):
  sample_a.bin        CAUGHT  Sample.BlueCat.A
  sample_a_1byte.bin  CLEAN   <- one byte changed, digest is different

STEP 3 (pattern):
  poly_1.bin  CAUGHT  Sample.Decoder.xs32
  poly_2.bin  CAUGHT  Sample.Decoder.xs32
  poly_3.bin  CLEAN   <- the decoder changed too (polymorphism)

Hash çığ etkisiyle tek baytta kırılır; desen çözücüyü yakalar ama polimorfizm onu da atlatır.

Demo 01 — Sezgisel: iki tür hata

STEP 5 (heuristic):
  sample_a.bin  CLEAN       score=  0   <- FALSE NEGATIVE (missed it)
  poly_1.bin    SUSPICIOUS  score= 80
  archive.bin   SUSPICIOUS  score= 50   <- FALSE POSITIVE (harmless)

• İmza olmadan polimorfiği yakaladı ✅
• Ama zararsız yüksek-entropili dosyayı şüpheli sandı ❌
• Ve düz gövdeli örneği kaçırdı ❌

Cohen'in belirsizliği tam burada.

Demo 01 — Emülasyon hepsini çözer

STEP 6 (emulation):
  poly_1.bin  CAUGHT  ... | 5 commands, 0 NOP, xs32
  poly_2.bin  CAUGHT  ... | 5 commands, 0 NOP, xs32
  poly_3.bin  CAUGHT  ... | 8 commands, 4 NOP, lcg8

• Çözücüyü güvenli sanal makinede çalıştırır, açılan gövdeyi tarar.
• Üç polimorfik kopya da aynı imzaya döndü.
• Güçlü ama pahalı; zararlı "sanal makinedeyim" derse gizlenebilir.

Sonuç: tek yöntem yetmez → katmanlı savunma.

İmza taraması: hash + desen + emülasyon (animasyon)

İmza taraması — uç durum: imza dosyanın son konumunda

Entropi: rastgelelik ölçüsü

• H ~ 0: hep aynı bayt · H ~ 4–5: metin/kod
• H ~ 6: derlenmiş program · H ~ 8: şifreli/sıkışık/rastgele

Antivirüs: "paketli/şifreli kod?" · EDR: "dosyaları hızla şifreleyen süreç?" (fidye)

Demo 02 — Entropi ölçer

code/week-02/02-entropy

  tekduze.txt   0.00  |........................| tekduze
  belge.txt     4.17  |#############...........| dusuk
  kod.bin       6.23  |###################.....| orta
  sifreli.bin   7.95  |########################| YUKSEK
  rastgele.bin  7.95  |########################| YUKSEK

⚠️ Entropi tek başına "zararlı mı?" demez: .zip/.png de yüksektir. Beklenmedik yerde yüksekse ipucudur.

Demo 02 — Sıcak bölge ve fidye izi

Mixed file (window 512):
   1024-1535  4.04  low
   1536-2047  7.54  HIGH  <- hidden encrypted section
   2048-2559  7.57  HIGH

Ransomware trace: document.txt 4.06 --> encrypted.bin 7.94

• Paketlenmiş programın deseni: küçük açıcı + yüksek entropili gövde.
• Bir süreç kısa sürede çok dosyada bu sıçramayı yapıyorsa davranış tabanlı koruma alarm verir.

Entropi: pencereli tarama (animasyon)

Entropi — uç durum: pencere dosyayı bölmüyor

Karşı önlem katmanları — şema

EDR örneğinde davranış izi

• Süreç, kısa sürede yüzlerce dosyayı okuyup yüksek entropili haliyle geri yazıyor.
• İçeriğe hiç bakmadan, yalnız bu davranış neredeyse kesin bir fidye yazılımı belirtisidir.
• Davranış tabanlı koruma dosyanın "ne olduğuna" değil, "ne yaptığına" bakar.
• Bu ipucu Demo 02'deki entropi sıçramasıyla aynı fikrin çalışma zamanı hâlidir.

Aynı alet kutusu: saldırgan ve savunmacı

• Bir zararlının gizlenmek için kullandığı teknik ile meşru yazılımın kendini korumak için kullandığı teknik çoğu zaman aynıdır.
• Fark niyet ve bağlamdadır: biri sizin varlığınızı korur, diğeri imzadan kaçar.
• Şifreli gövde + çözücü deseni: polimorfik virüste de, korumalı mobil uygulamada da var.
• Bu simetri dönem boyunca (9., 11. hafta) tekrar karşımıza çıkacak.

Örnek: mobil ödeme neden şifreli sabit tutar?

• Tersine mühendisliği yavaşlatmak için hassas dizeler/sabitler şifreli tutulur, kullanım anında çözülür.
• Bir değerlendirici binary dosyada yüksek entropili bölge görünce sorar:
  • Çözücü nerede?
  • Anahtarı nasıl buluyor?
  • Anahtar bellekte ne kadar açık kalıyor?
• Aynı entropi ölçümü hem antivirüsün hem değerlendiricinin ortak aracıdır.

İtibar / bulut tabanlı tespit

• Dosyanın yaygınlığı, kaynağı, dijital imzası bulutta sorgulanır.
• "Milyonlarca kullanıcıda görülmüş ve temiz" ise güvenilir sayılır; "hiç görülmemiş, imzasız" ise şüphelidir.
• Güçlü yanı: hızlı yayılan tehdide karşı anında güncellenir.
• Zayıf yanı: gizlilik (dosya bilgisi buluta gider) ve internet bağlantısı gerektirir.

Kural motoru: koşul ayrıştırıcı (animasyon)

Koşul ayrıştırıcı — uç durum: kırık bir koşul

Kara liste vs beyaz liste

• Kara liste: "kötü olanı tanı" — bilinen zararlıyı listele, geri kalanına izin ver.
• Beyaz liste: "iyi olanı tanı" — bilinen iyiyi listele, geri kalan her şeyden şüphelen.
• Bütünlük izleme, beyaz listenin dosya düzeyindeki biçimidir.
• Sistem iyiyken her dosyanın özeti bir manifeste yazılır, sonra düzenli karşılaştırılır.

Soru — hangi tür, hangi katman?

E-posta ekindeki "fatura.pdf.exe" açılınca çalışıp adres defterindeki herkese kendini yolluyor.

Soru: Bu hangi tür zararlı? İlk yakalayacak katman ne olurdu?

Cevap: Solucan/truva karışımı — kullanıcı açar (truva atı gibi başlar), sonra kendi kendine yayılır (solucan gibi). İlk yakalayacak katman: imza/desen (bilinen bir örnekse) ya da sezgisel (yeniyse).

Soru — tedarik zinciri saldırısı

Bir yazılımın resmî güncellemesine, derleme sırasında arka kapı ekleniyor (SUNBURST benzeri).

Soru: İmza tabanlı tespit ve izin listesi (whitelisting) bunu yakalar mı?

Cevap: Hayır, ikisi de başarısız olur. Dosya geçerli imzalıdır ve izin listesinde zaten vardır (güncelleme resmî kaynaktan geliyor). Tedarik zinciri saldırısının korkutucu yanı tam budur: güvendiğiniz kaynağın kendisi ele geçirilmiştir.

Demo 08 — Bütünlük izleme (beyaz liste)

code/week-02/08-integrity-monitoring · SHA-256 manifesti + HMAC mühür

CHANGED  library.bin  5ab02b71... -> 12c5803f... (48->62 B)
DELETED  data.txt     (in the manifest, not in the folder)
NEW      hidden.bin   (not in the baseline)
-- attacker rewrites the manifest --
RESULT: integrity preserved    <- monitor FOOLED
SEAL INVALID -> DO NOT TRUST the manifest

✅ Özet değişikliği yakalar · ⚠️ beklenen değerler de korunmalı (HMAC/imza, anahtar ayrı yerde)

Tarif 12.2: CRC32 → SHA-256/HMAC · 6. haftada çalışma zamanı bütünlük denetimi

Değerlendirici: bütünlük denetimini nasıl kırar?

İki adımlı test:

1. Önce izlenen bir dosyayı değiştirir → tespit edildi mi?
2. Sonra beklenen değerleri (manifest, gömülü özet) de değiştirmeye çalışır.

İkinci test geçilemiyorsa denetim yalnız kazaya karşı korur, saldırgana karşı değil.

Sabit zamanlı karşılaştırma

• İki özeti karşılaştırırken ilk farklı bayta kadar mı, yoksa hep aynı sürede mi bakılıyor?
• Süre farkı, doğru baytların sayısını sızdırabilir (zamanlama yan kanalı).
• Bütünlük ve HMAC karşılaştırmaları sabit zamanlı yapılmalı.
• Demo 08'in HMAC mührü bu yüzden özel bir karşılaştırma kullanır.

Neden CRC32 yeterli değil?

• CRC32 hata tespiti için tasarlandı, saldırgana karşı değil.
• Aynı CRC32 değerini veren farklı içerik bulmak kolaydır (çakışma ucuz).
• Saldırgan dosyayı değiştirip CRC'yi eski değere döndürebilir.
• Bu yüzden bütünlük denetiminde kriptografik özet (SHA-256) ya da imza gerekir.

Olay incelemelerinin iskeleti — şema

Olaylardan programcıya dersler

1. Sınır denetimi: 1988–2008 salgınlarının çoğu tek bir arabellek taşması (1. ve 4. hafta)
2. Sürümde hata ayıklama kodu bırakma (Morris / sendmail DEBUG)
3. Gereksiz hizmeti açma: her port bir saldırı yüzeyi (Slammer, Blaster)
4. İmzalı güncelleme + istemcide doğrulama (NotPetya) — 3. ve 10. hafta
5. Derleme ortamı ve tedarik zinciri güvenliği (SUNBURST) — 5. hafta SBOM
6. Güncelleme mekanizması güvenlik özelliğidir: yama gecikmesi = açık kapı

Eğilim: 1988–2008 vs 2017 sonrası

• 1988–2008: salgınların çoğu tek bir arabellek taşmasıyla yayıldı (Morris → Conficker).
• 2017 sonrası: giriş kapısı güncelleme ve derleme süreçlerine kaydı (NotPetya, SUNBURST).
• Saldırgan artık kodu kırmak yerine, kodun size ulaştığı yolu ele geçiriyor.
• İki savunma ucu: sınır denetimi (1., 4. hafta) + imzalı güncelleme/tedarik zinciri (3., 5., 10. hafta).

Yama gecikmesi bir güvenlik açığıdır

• WannaCry'ın açığının yaması, saldırıdan iki ay önce yayımlanmıştı.
• Slammer'ınki de aylar önceden vardı.
• Sonuç: güncelleme mekanizması güvenlik özelliğinin bir parçasıdır.
• Güncellemesi zor/yavaş bir ürün, düzeltilmiş hataları bile aylarca açık tutar.

Tartışma: makrolar neden varsayılan kapalı?

Soru: Office, 2022'den beri internetten gelen belgelerdeki makroları varsayılan engelliyor. Bu, Melissa ve ILOVEYOU gibi eski salgınların hangi zayıflığını kapatıyor?

Cevap: Kullanıcının "makroları etkinleştir" tuzağına düşmesine dayanan yayılma yolunu kapatıyor. Varsayılan ayar, kullanıcı eğitiminden daha güçlüdür: eğitim her kullanıcıda işe yaramayabilir, ama güvenli varsayılan herkesi aynı anda korur.

Tedarik zinciri: SUNBURST'ten NotPetya'ya

• NotPetya (2017): bir muhasebe yazılımının güncelleme sunucusu ele geçirildi, on binlerce makineye yayıldı.
• SUNBURST (2020): bir izleme yazılımının derleme ortamına sızılıp imzalı kütüphaneye arka kapı eklendi.
• Ortak nokta: saldırgan sizin güvendiğiniz kaynağı hedef alıyor, sizi değil.
• Savunma: güncellemeleri imzala + istemcide doğrula, derleme ortamını koru (5. hafta SBOM).

Yanılgı: "İmza veritabanım güncel, güvendeyim"

Yanılgı: Güncel imza veritabanı yeterli korumadır.

Gerçek: İmza yalnız bilineni yakalar. Tek baytlık değişiklik özet imzasını, çözücüsü değişen polimorfik kopya desen imzasını atlatır (Demo 01).

İmza, savunmanın başlangıcıdır, bitmez.

Yanılgı: "Yüksek entropi = zararlı"

Yanılgı: Yüksek entropili her dosya şüphelidir.

Gerçek: Şifreli, sıkıştırılmış ve rastgele veri hep 8'e yakındır; .zip, .png, şifreli yedek de öyle.

Entropi yalnız beklenmedik yerde anlamlı bir ipucudur (Demo 02).

Yanılgı: kum havuzu ve emülasyonun sınırı

"Kum havuzunda temiz çıktı, o hâlde temiz." Zararlı sanal ortamı sezip uyuyabilir; sonuç "bu koşullarda bir şey yapmadı" demektir, "zararsızdır" değil.

"Emülasyon metamorfik zararlıyı da çözer." Emülasyon şifreli gövdenin çözüldüğü anı yakalar; metamorfik kodda sabit bir gövde yoktur. Burada davranış tabanlı tespit gerekir.

Yanılgı: "%100 tespit eden ürün alırız"

Yanılgı: Doğru ürünü seçersek hiçbir zararlı kaçmaz.

Gerçek: Cohen'in (1984) kanıtladığı gibi, "bu program virüs mü?" sorusunu her durumda doğru yanıtlayan genel bir algoritma yoktur.

Her tespit yöntemi yanlış pozitif ile yanlış negatif arasında bir denge kurar.

Yanılgı: "Bütünlük izlemesini düz SHA-256 listesiyle yaptım"

Yanılgı: Bir dosya listesi + özetleri yeterli bütünlük denetimidir.

Gerçek: Saldırgan dosyayı değiştirdiği gibi listeyi de güncelleyebilir.

Beklenen değerler anahtarlı (HMAC) ya da imzalı olmalı ve saldırganın erişemeyeceği yerde durmalıdır (Demo 08).

Yanılgı: "Yama yayımlandı, iş bitti"

Yanılgı: Yama çıktığı an risk biter.

Gerçek: WannaCry'ın kullandığı açığın yaması saldırıdan yaklaşık iki ay önce çıkmıştı.

Yama uygulanana kadar risk sürer; yayımlanan yama saldırgana da yol gösterir.

Saldırı ağacı = niceliksel tehdit

• Kök: saldırganın hedefi · Dallar: ona ulaşma yolları.
• VEYA: en ucuz çocuk yeter · VE: çocukların toplamı gerekir.
• Yapraklara maliyet yazarsak en ucuz saldırıyı buluruz.

Saldırı ağacı kurma adımları — şema

Demo 04 — Savunma maliyeti artırır

code/week-02/04-attack-tree

BEFORE:  CHEAPEST ATTACK = 2  (read from memory)
AFTER:   CHEAPEST ATTACK = 8  (RASP added)

• "Bellekten oku" dalına RASP (anti-debug, anti-hook) eklendi.
• En ucuz saldırı 2 → 8 birime çıktı; en zayıf nokta değişti.
• Güvenlik yatırımını sayıyla gerekçelendirmenin yolu budur.

Saldırı ağacı: en ucuz yol (animasyon)

Saldırı ağacı — uç durum: kök tek bir yaprak

Yanılgı: "VE ile VEYA fark etmez"

Yanılgı: Saldırı ağacında düğüm türü önemli değil.

Gerçek: VEYA düğümünde en ucuz çocuk yeter; VE düğümünde çocukların toplamı gerekir.

Karıştırmak en ucuz yolu yanlış buldurur ve savunma parası yanlış dala gider.

Yanılgı: "En pahalı dalı güçlendirelim"

Yanılgı: Görünüşte en tehlikeli/karmaşık saldırı yolunu güçlendirmek en iyisidir.

Gerçek: Saldırgan her zaman en ucuz yolu seçer. Savunma köke giden en ucuz yolu pahalılaştırmıyorsa, en ucuz saldırının maliyeti hiç değişmez (Demo 04).

Yanılgı: "Önlem eklemek yeter"

Yanılgı: Ağaca bir savunma düğümü eklemek riski kapatır.

Gerçek: Her önlemin kendisi de atlatılabilir. Önlem düğümünün altına onu aşma yollarını (karşı-karşı önlem) yazmadan hesap iyimser çıkar.

Saldırı ağacı vs denetim kaydı: iki soru

• Saldırı ağacı: "Saldırgan nereden gelir?" — önceden, planlama sorusu.
• Denetim kaydı (audit log): "Geldi mi, ne yaptı?" — sonradan, kanıt sorusu.
• Bir olaydan sonra ne olduğunu anlamanın, sorumluyu bulmanın tek yolu güvenilir kayıttır.
• Kitap bunu Tarif 13.11'de işler; öneriler bugün de geçerli, yalnız araçlar güncellendi.

Denetim kaydı: ne yazılır, ne yazılmaz?

Tarif 13.11 · günlüğü saldırganın da okuyacağını varsayarak tasarla

Denetim kaydı — şema

Günlük enjeksiyonu: güvensiz vs güvenli (animasyon)

Günlük enjeksiyonu — uç durum: ANSI kaçış dizisi

Zafiyetli kod: günlük enjeksiyonu ve biçim dizesi

fprintf(log, "giris: %s\n", kullanici_adi);  /* CWE-117 */

syslog(LOG_INFO, kullanici_girdisi);  /* CWE-134 */

Kullanıcıdan gelen veri günlükte kaçışsız satır sonu ya da doğrudan biçim dizesi olarak kullanılmamalı:
syslog(LOG_INFO, "%s", girdi).

Özet zinciri: basit ama kırılabilir

• Fikir: her kayıt, bir önceki kaydın özetini içerir.
• Bir kaydı değiştirmek yalnız o kaydın kendi özetini bozar (doğrulayıcı her zaman saklanan zinciri kontrol eder, yeniden hesaplanmışı değil).
• Sorun: özet anahtarsız — yetenekli bir saldırgan sonraki tüm özetleri de yeniden hesaplayıp kurcalamayı tamamen gizleyebilir.
• Çözüm: özeti anahtarlı yapmak → HMAC zinciri (bir sonraki slayt).

Sürüm derlemesinde günlük neden kaldırılır?

• Kayıt, bir saldırganın da okuyabileceği varsayılarak tasarlanır.
• Günlüğe yazılan her sır, günlük dosyasına erişen herkese verilmiş demektir.
• Kapalı bir bayrakla susturulmuş hata ayıklama kodu, binary dosyada kalır.
• Hem dizeleriyle (string) bilgi sızdırır hem de yeniden açılabilir — bu yüzden sürüm derlemesinde tamamen çıkarılmalıdır.

Kurcalamaya dayanıklı günlük: HMAC zinciri (animasyon)

HMAC zinciri — uç durum: statik anahtar (evrim yok)

İleriye güvenlik: anahtar neden evrilir?

• Her kayıttan sonra anahtar tek yönlü bir fonksiyonla değişir; eski anahtar silinir.
• Saldırgan makineyi ele geçirdiğinde yalnız o anki anahtarı bulur.
• O andan geriye, önceki kayıtları mühürleyen anahtarlara dönemez.
• Sonuç: ele geçirmeden önceki kayıtlar korunur (Schneier–Kelsey, 1999).

Soru — sondan kesme yakalanır mı?

Demo 11'in ürettiği zincirden son üç satırı silin.

Soru: Doğrulayıcı bunu fark eder mi? Neden?

Cevap: Yalnızca zincirin son değeri ya da kayıt sayısı ayrıca (uzak bir sunucuda) tutuluyorsa fark eder. Zincirin kendisi yalnız dosyada tutulursa, sondan kesme iç tutarlılığı bozmaz — çünkü silinen kayıtlardan sonra gelen hiçbir kayıt yoktur ki tutarsızlık göstersin.

Kural (özet): denetim kaydı

• Kullanıcı verisini kaçışlayarak ve sınırlayarak yazın.
• Sırları (parola, anahtar) asla yazmayın.
• Günlüğü anahtarlı bir zincirle mühürleyin; anahtarı her kayıtta evriltin.
• Doğrulama anahtarını günlüğün bulunduğu makinede tutmayın.
• Mümkünse kayıtları anında ayrı bir sunucuya gönderin.

Sahada nasıl uygulanır? — mobil günlük

• Mobil uygulamalarda cihaz üzerindeki günlük en az tutulur, hassas alan içermez.
• Güvenlik olayları (bütünlük hatası, hata ayıklayıcı algılama) sunucuya raporlanır.
• Bu, 6. haftada göreceğimiz RASP önlemlerinin "raporlama" ayağıdır.
• Cihazdaki günlük saldırganın elindedir; asıl kanıt uzaktaki kopyadır.

Yanılgı: "Denetim kaydına her şeyi yazalım"

Yanılgı: Daha çok bilgi, daha iyi kanıt demektir.

Gerçek: Parola, PIN, anahtar ve tam kart numarası kayda asla girmez (CWE-532).

Kayıt, olayı yeniden kurmaya yetecek kadar bilgi taşır: kim, ne, ne zaman, nerede, sonuç.

Yanılgı: "Kullanıcı adını olduğu gibi yazdım"

Yanılgı: Kullanıcıdan gelen alan doğrudan günlüğe yazılabilir.

Gerçek: İçinde satır sonu olan bir girdi sahte kayıt satırı üretir (CWE-117, Demo 10).

Denetim karakterleri kaçışlanmalı ya da yapılandırılmış (alan alan) kayıt kullanılmalıdır.

Yanılgı: "Kayıt sonuna özet ekledim, kurcalama anlaşılır"

Yanılgı: Dosyanın sonuna bir özet eklemek yeterli korumadır.

Gerçek: Anahtarsız özeti saldırgan yeniden hesaplar.

HMAC zinciri araya ekleme/değiştirmeyi yakalar; sondan kesmeyi yakalamak için son zincir değeri ayrıca (uzak sunucuda) tutulmalıdır (Demo 11).

Özne, nesne, hak — ve matris

• Özne (kullanıcı/süreç) · Nesne (dosya/kayıt) · Hak (oku/yaz/çalıştır).

Matris iki biçimde saklanır: ACL (sütun: nesne kimin erişeceğini tutar) · Yetenek (satır: özne biletleri).

DAC ve MAC — şema

Demo 03 — Salt DAC (matris)

code/week-02/03-access-model

  library(D   ) R   payment_key (D   ) DAC:YES => ALLOW
  app    (D   ) R   payment_key (D   ) DAC:no  => DENY  (matriste yok)
  attacker(D   ) R   payment_key (D   ) DAC:no  => DENY

Uygulamanın bile ödeme anahtarına doğrudan erişimi yok → en az ayrıcalık.

Bell–LaPadula: gizlilik

Seviyeler: Genel < Gizli < Çok Gizli

• Yukarı okuma yok: kendinden gizli olanı okuyamaz.
• Aşağı yazma yok (*-özellik): kendinden az gizli olana yazamaz.

"Read down, write up" — gizli bilgi aşağı sızamaz.

Örnek: "Gizli" etiketli bir kullanıcı "Çok Gizli" bir belgeyi okuyamaz; "Çok Gizli" bir süreç "Genel" bir dosyaya yazamaz (sızıntı böyle önlenir).

Biba: bütünlük (BLP'nin tersi)

Seviyeler: Dış < Uygulama < Çekirdek (güvenilirlik)

• Aşağı okuma yok: kendinden az güvenilir veriyi okuyamaz.
• Yukarı yazma yok: kendinden güvenilir veriye yazamaz.

"Read up, write down" — kirli bilgi yukarı çıkamaz, temizi bozamaz.

Clark–Wilson: ticari bütünlük

Askeri seviye yerine iyi biçimli işlem + görev ayrılığı (1987, banka):

• CDI: bütünlüğü korunacak veri (bakiye).
• TP: CDI'ye yalnız onaylı işlemler dokunur (doğrudan yazma yok).
• IVP: tutarlılığı düzenli denetler ("borç = alacak").
• Görev ayrılığı: başlatan ≠ onaylayan.

"Veriye doğrudan değil, doğrulanmış işlemlerle dokun."

Demo 03 — BLP ve Biba çıktısı

BLP:  clerk    READ  operation  BLP:DENY => DENY  (read up)
      general  WRITE notice     BLP:DENY => DENY  (write down)

Biba: listener WRITE record     BIBA:DENY => DENY  (write up)
      processor READ  incoming  BIBA:DENY => DENY  (read down)

DAC her ikisinde YES; reddi getiren sistem (MAC) kuralıdır.

Erişim matrisi: DAC + BLP + Biba + Chinese Wall (animasyon)

Erişim matrisi — uç durum: eşit etiketler

Unix erişim modeli

-rwxr-x--- → sahip / grup / diğerleri, her biri oku-yaz-çalıştır.

• Üç kimlik: effective / real / saved UID.
• setuid: program sahibinin (çoğu zaman root) yetkisiyle çalışır — güçlü ama tehlikeli.
• sticky bit: /tmp'te başkasının dosyasını silememe.

Kitap: Tarif 2.1

Unix izin bitleri — şema

Demo 06 — TOCTOU yarışı (CWE-367)

code/week-02/06-toctou (yalnız WSL/Linux) · Kitap: Tarif 2.3

UNSAFE (lstat first, then fopen):
  >>> ATTACK SUCCEEDED: write redirected to secret_target.txt!
SAFE (O_NOFOLLOW, one step):
  rejected: the target is a symbolic link

Denetim ile kullanım arasındaki boşluk bir yarıştır. Çözüm: tek atomik adım (O_NOFOLLOW, O_EXCL), fd üzerinden çalış.

TOCTOU yarışı: denetim ile kullanım arasındaki pencere (animasyon)

TOCTOU — uç durum: SAFE, saldırgan yok

Windows ACE değerlendirme sırası (animasyon)

ACE sırası — uç durum: kurallı sıra, DENY ilk ACE

Unix izin denetimi ve umask (animasyon)

Unix izinleri — uç durum: umask 000 tehlikesi

RBAC + Clark–Wilson: işlem denetim kapıları (animasyon)

RBAC — uç durum: kullanıcı hiç tanınmıyor

Yanılgı: "Kimliği doğruladık, yetkiyi de doğrulamış olduk"

Yanılgı: Giriş yapabilen kullanıcı, her şeyi yapabilir.

Gerçek: Kimlik doğrulama "sen kimsin?" sorusudur; yetkilendirme "bunu yapabilir misin?" sorusudur — ayrı adımlardır.

2025 CWE Top 25'te dördüncü sıradaki CWE-862 (eksik yetkilendirme) tam bu hatadır.

Yanılgı: "Hata olursa izin verelim"

Yanılgı: Politika okunamıyorsa ya da belirsizse, kullanıcı mağdur olmasın diye izin verilmeli.

Gerçek: Güvenli varsayılan ilkesi tam tersini söyler: politika okunamıyorsa cevap ret olmalıdır (CWE-636, "fail-open" hatası).

"Fail-closed" (hata olunca kapat) güvenli sistemlerin varsayılanıdır.

Yanılgı: "NULL DACL ile boş DACL aynı"

Yanılgı: İkisi de "izin yok" gibi görünür.

Gerçek: NULL DACL (hiç DACL yok) herkese tam erişim verir — sahiplik alma dahil. Boş DACL (ACE'siz liste) ise kimseye hiçbir hak vermez.

İlki ciddi bir zafiyettir (CWE-732); ikisini karıştırmak tehlikelidir (Demo 12).

Yanılgı: "ACE sırası önemli değil"

Yanılgı: Aynı ACE'ler farklı sırada yazılsa da sonuç aynıdır.

Gerçek: Windows ACE'leri sırayla değerlendirir ve ilk belirleyici girdide durur.

Kanonik sırada açık ret girdileri izinlerden önce gelir; elle yanlış sıralanmış bir DACL, niyet edilen reddi etkisiz bırakabilir (Demo 12).

Yanılgı: "chmod 777 ile sorun çözüldü"

Yanılgı: "Erişim reddedildi" hatasını chmod 777 ile geçiştirmek pratik bir çözümdür.

Gerçek: Sorun izinlerin herkese açılmasıyla çözülmez, büyütülür.

Sırlar 0600 ile oluşturulmalı, umask programın başında bilinçli ayarlanmalıdır (Demo 13).

Yanılgı: "RBAC kurduk, görev ayrılığı kendiliğinden gelir"

Yanılgı: Rol tabanlı erişim denetimi kurmak, görev ayrılığını otomatik sağlar.

Gerçek: Aynı kişiye hem "iade başlat" hem "iade onayla" rolü verilirse RBAC görev ayrılığını sağlamaz.

Statik (SSD) ya da dinamik (DSD) görev ayrılığı kısıtı ayrıca tanımlanmalıdır (Demo 14).

Mobil izin modeli ve en az ayrıcalık

• Her uygulama kendi kum havuzunda çalışır — diğer uygulamaların verisine varsayılan olarak erişemez.
• Hassas kaynaklar (kamera, konum, kişiler) çalışma anı izni ister; kullanıcı onaylamadan erişilmez.
• Bu, DAC (kullanıcı onayı) ile MAC'e (sistemin zorunlu kum havuzu sınırı) benzer bir karma modeldir.
• En az ayrıcalık ilkesinin (Hafta 1) günümüz mobil işletim sistemlerindeki somut hâlidir.

CWE: zayıflık türleri kataloğu

• CWE = zayıflığın türü (SQL enjeksiyonu → CWE-89).
• CWE Top 25: o yıl en çok görülen/tehlikeli 25 zayıflık.

Hiyerarşik: pillar → class → base → variant. En somut CWE'yi seç.

Yanılgı: "CWE ile CVE aynı şey"

Yanılgı: İkisi de aynı anlama gelir, birbirinin yerine kullanılabilir.

Gerçek: CWE zayıflığın türüdür (SQL enjeksiyonu → CWE-89). CVE belirli bir üründeki belirli açığın kimliğidir (Heartbleed → CVE-2014-0160).

Bir CVE, bir ya da birden çok CWE türüne aittir.

Yanılgı: "En genel CWE'yi seçmek güvenlidir"

Yanılgı: Emin olmadığımda en üst düzey (genel) CWE'yi yazmak daha güvenlidir.

Gerçek: CWE-20 (girdi doğrulama) gibi üst düzey girdiler düzeltmeyi anlatmaz.

Kural: mümkün olan en somut (tercihen base düzeyi) CWE'yi seçin.

OWASP Top 10 ve MASVS

MASVS-RESILIENCE = tersine mühendisliğe direnç → bu dersin kod gizleme (H9, H14), RASP (H6), whitebox (H11) konuları.

OWASP ve MASVS — şema

Yanılgı: "OWASP Top 10 bir kontrol listesidir"

Yanılgı: Top 10'daki 10 maddeyi karşılıyorsam güvenliyim demektir.

Gerçek: Top 10 bir farkındalık belgesidir, doğrulama standardı değil.

Doğrulanabilir gereksinimler web için ASVS'de, mobil için MASVS ve MASTG'dedir.

CVE ve CVSS

• CVE: belirli üründeki belirli açığın kimliği (CVE-2014-0160 = Heartbleed). Bir isim, ciddiyet değil.
• CVSS: açığın ciddiyeti 0.0–10.0. Üç grup: Temel (değişmez), Zamansal, Çevresel.

Bir CVE bir ya da birden çok CWE türüne aittir.

CWE, CVE, CVSS — şema

Demo 05 — CVSS hesaplayıcı

code/week-02/05-cvss (Python)

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  = 9.8  Kritik
              ... S:U -> S:C          = 10.0 Kritik
AV:L (yerel) /PR:L/... C:H/I:H/A:H    = 7.8  Yuksek

• Uzaktan + kimliksiz en yüksek; kapsam değişince 10.0.
• ⚠️ Temel puan bağlamı bilmez: 4.0'lık açık tam sizin varlığınızı vuruyorsa sizin için 9.8'den önemli olabilir.

CVSS v3.1 taban puan hesabı (animasyon)

CVSS — uç durum: hiç etki yok

CVSS v4.0 kısaca

• 2023'te geldi; v3.1'in bazı zayıflıklarını giderir.
• Temel puan artık CVSS-B olarak anılır.
• Kapsam (S) metriği kaldırıldı; yerine ayrı Zafiyet Etkisi (VC/VI/VA) ve Sonraki Sistem Etkisi (SC/SI/SA).
• Sömürü olgunluğu (E) ve tehdit/çevre metrikleriyle CVSS-BTE hesaplanabiliyor.
• Bu derste hesap makinesi v3.1 için yazıldı; sahada hâlâ en yaygın odur.

Yanılgı: "v3.1 vektörünü v4.0'a girerim"

Yanılgı: CVSS v3.1 vektörü, v4.0 hesap makinesinde de doğrudan çalışır.

Gerçek: v4.0'da Kapsam (S) yoktur; AT, VC/VI/VA, SC/SI/SA metrikleri vardır ve UI üç değer alır (N/P/A).

Vektörler birbirine çevrilmez, yeniden kurulur.

CVSS'in sık yapılan hatası

Yanılgı: "CVSS 9.8, hemen yamalayalım; 4.0, beklesin."

• Temel puan bağlamı bilmez: açığın kendi özelliklerini ölçer.
• 4.0'lık bir açık, tam sizin en değerli varlığınızın kapısıysa sizin için 9.8'den önemli olabilir.
• Bunun için Çevresel metrikler ve varlık tablonuz (S5) vardır.
• Puan önceliklendirmeye başlangıçtır, son söz değildir.

CVSS'in ötesi: EPSS

• EPSS (Exploit Prediction Scoring System): bir açığın 30 gün içinde istismar edilme olasılığı (0–1 arası).
• CVSS ciddiyeti ölçer, EPSS olasılığı ölçer — ikisi farklı sorulara cevap verir.
• "EPSS yüksek, o hâlde CVSS de yüksektir" yanlıştır; ikisi birbirinden bağımsız ölçülür.
• İkisi birlikte okunduğunda öncelik sırası netleşir.

CVSS'in ötesi: KEV

• KEV (Known Exploited Vulnerabilities): kanıtlanmış biçimde istismar edilen açıkların kataloğu.
• Her kayıt: CVE kimliği, istismar kanıtı, açık düzeltme yönergesi.
• "KEV'de yoksa istismar edilmiyordur" yanlıştır — listede olmamak güvenlik kanıtı değildir.
• KEV'deki bir açık, düşük CVSS puanı alsa bile öncelikli ele alınmalıdır.

Yanılgı: "Cihazdaki açıklar düşük puan alıyor, önemsiz"

Yanılgı: AV:L (yerel erişim) çıkan bir açık, düşük puanlıysa göz ardı edilebilir.

Gerçek: Bu dersin saldırgan modelinde cihaz zaten saldırganın elindedir (beyaz kutu).

Puan düşse bile risk azalmaz; puanın yanına saldırı potansiyeli (süre, uzmanlık, ekipman) de yazılmalıdır.

Pratik: vektörü siz kurun

Soru: Bir saldırgan ağdan, kimlik doğrulamadan, kullanıcı etkileşimi olmadan bir sistemi tamamen ele geçiriyor (gizlilik, bütünlük, erişilebilirlik hepsi tam bozuluyor). CVSS v3.1 vektörü ve puanı nedir?

Cevap: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (Kritik). Kapsam da değişseydi (S:C) puan 10.0'a çıkardı.

Zafiyet yaşam döngüsü

• Zero-day: satıcının bilmediği/yamasının olmadığı açık.
• Sorumlu ifşa: önce satıcıya bildir, ~90 gün bekle, sonra açıkla.
• Yama boşluğu: yama çıkınca açık kamuya açılır; güncellemeyen savunmasız (WannaCry).

Yaşam döngüsü: dört aşama

1. Keşif: açık bulunur (araştırmacı, saldırgan ya da satıcı).
2. Bildirim: araştırmacı satıcıya bildirir (ya da saldırgan sessizce kullanır).
3. Yama: satıcı düzeltmeyi yazıp yayımlar.
4. Yayın: yama kullanıcıya ulaşır, uygulanırsa risk biter.

Her ok arasında geçen süre, saldırgana verilen zaman penceresidir.

Açığın yaşam çizgisi — şema

Hata ödül programları (bug bounty)

• Şirketlerin, açığı sorumlu biçimde bildiren araştırmacılara ödül verdiği programlar.
• Amaç: araştırmacıyı tam ifşa yerine sorumlu ifşaya yönlendirmek.
• Araştırmacı için kazanç; şirket için erken uyarı.
• Büyük teknoloji şirketlerinin çoğunda artık standart bir uygulamadır.

Sahada süreç: bir açık bildirilirse ne olur?

Bir ürün ekibi için yaşam döngüsü bir süreçtir:

• Bildirim kanalı: security.txt, güvenlik e-postası.
• Bir sorumlu kişi/ekip.
• Yama SLA'sı: ne kadar sürede düzeltilecek?
• Sürüm/yama duyuru mekanizması.

Bir değerlendirme yalnız kodu değil, bu süreci de sorar.

Tam ifşa neden tartışmalı?

Soru: Tam ifşa (full disclosure) neden riskli kabul edilir?

Cevap: Açık, yama yokken herkese duyurulur. Satıcıyı harekete geçirmeye zorlar, ama aynı zamanda saldırganlara da hazır bir yol haritası verir — kullanıcılar savunmasızken.

Dönem projesi: bu hafta (S4)

• [ ] S4 saldırı/tehdit tablonuzdaki her satıra bir CWE ekleyin.
• [ ] En kritik varlığa bir saldırı ağacı (Demo 04 biçimi); en ucuz yol + en etkili önlem.
• [ ] Kullandığınız bileşenlerin CVE'lerini bulup CVSS puanlayın.
• [ ] Uygun erişim modelini (DAC / MAC / RBAC) gerekçelendirin.

| ID | Tehdit | Varlik | Yol | CWE | Onlem | Bolum |

Sınıf etkinlikleri

1. Zararlıyı sınıfla, katmanı seç: altı senaryoda tür ve ilk yakalayan katman
2. Saldırı ağacı düellosu: karşı grup, ağaçta olmayan daha ucuz bir yol arar
3. Matristen modele: aynı politikayı ACL, yetenek listesi, BLP/Biba etiketiyle yaz
4. Bulgudan yama sırasına: CWE + CVSS + EPSS + KEV + SSVC ile beş bulguyu sırala
5. Denetim kaydını kurcala: Demo 11 zincirinde değiştirme/silme/sondan kesmeyi dene
6. Kod okuma turnuvası: dört koda CWE, saldırı ve düzeltme yaz
7. Olay otopsisi: Heartbleed/WannaCry/Log4Shell için CVE-CWE-CVSS-tarih doldur

Kendini sınama (seçme)

1. Virüs, solucan, truva atı farkı?
2. Polimorfizm ≠ metamorfizm: fark?
3. Yüksek entropi zararlıyı kanıtlar mı?
4. BLP iki kuralı ve neyi korur?
5. Biba, BLP'den nasıl ayrılır?
6. DAC ile MAC farkı?
7. CWE ile CVE farkı?
8. CVSS Temel puan neyi ölçmez?

Kendini sınama (devam)

9. İmza ve sezgisel tespitin güçlü/zayıf yanı?
10. Günlük enjeksiyonu (CWE-117) nasıl önlenir?
11. Sorumlu ifşa nedir?

Kendini sınama — cevaplar (9–11)

9. İmza hızlı ama yeniyi kaçırır; sezgisel yeniyi bulur ama yanlış alarm üretir.
10. Günlüğe yazılan kullanıcı verisindeki satır sonu/kontrol karakterlerini temizle/kaçır; yapılandırılmış
    günlük kullan.
11. Açığı önce üreticiye bildirip yama için süre tanımak, sonra kamuya açıklamak.