Hafta 2 — Bilgisayar Virüsleri ve Güvenlik Modelleri¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming\code
.\build.ps1
cd week-02\01-signature-scanner ; .\demo.ps1

sudo apt install -y build-essential cmake libssl-dev python3
git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming/code && ./build.sh
cd week-02/01-signature-scanner && sh demo.sh

0. Başlamadan önce¶

Bu bölüm haftaya hazırlık içindir. Önce bu haftanın dayandığı önceki konuları kısaca hatırlatır; sonra bu haftanın kavramlarını birer cümleyle tanımlayıp her birini ayrıntılı anlatıldığı bölüme bağlar.

Önceki haftalardan gelenler¶

• Varlık, tehdit, zafiyet, risk ve saldırgan modeli — bir varlığın değerini, ona yönelik tehdidi, tehdidi mümkün kılan zayıflığı (zafiyet) ve olasılık × etki çarpımı olan riski ayırt etme dili (Hafta 1, §1; saldırgan modeli için Hafta 1, §3). Bu hafta bu dili zararlı yazılım (tehdit tarafı) ve erişim modelleri (savunma tarafı) üzerinden somutlaştırıyoruz.
• STRIDE ve saldırı ağacı — bir arayüzdeki tehdit türlerini STRIDE'ın altı harfiyle sorup, bulunan tehditleri kök hedeften dallara VE/VEYA mantığıyla ayrıştırma yöntemi (Hafta 1, §7). Bu hafta saldırı ağacına maliyet ekleyip en ucuz saldırı yolunu hesaplıyoruz (§8, Demo 04).

Bu haftanın kavram haritası¶

1. Bu haftanın büyük resmi: tehdit, model, sınıflandırma¶

Geçen hafta güvenliğin dilini kurduk: varlık, tehdit, zafiyet, risk; saldırgan modeli; STRIDE ve saldırı ağacı (Hafta 1, §7). Bu hafta o dilin üç sütununu dolduruyoruz:

• Tehdit tarafı — zararlı yazılım: Saldırganın en görünür aracı olan kötü yazılımı türlere ayıracağız (virüs, solucan, truva atı, fidye yazılımı) ve nasıl gizlendiğini göreceğiz. Çünkü bir savunmayı tasarlarken "bize karşı ne var?" sorusunun cevabının bir kısmı budur.
• Savunma tarafı — güvenlik modelleri: "Kim neye erişebilir?" sorusunu rastgele değil, biçimsel bir modelle yanıtlamayı öğreneceğiz (erişim matrisi, DAC/MAC/RBAC, Bell–LaPadula, Biba, Clark–Wilson). Bu modeller, işletim sistemlerinin (Unix, Windows) izin mimarisinin temelidir.
• Ortak dil — sınıflandırma: Bir açığı bulduğumuzda onu herkesin anladığı bir dille adlandırmalı ve ciddiyetini ölçebilmeliyiz. Bunun için CWE (açık türü), CVE (belirli açık), CVSS (ciddiyet puanı) ve OWASP/MASVS (öncelik listeleri) vardır.

Bu üçü birbirine bağlıdır: zararlı yazılımı tanımadan ona karşı model kuramaz, modeli kurmadan kalan açıkları göremez, açıkları ortak bir dille adlandırmadan da hangi tehdide öncelik vereceğinizi bilemezsiniz.

2. Zararlı yazılım nedir? Kısa bir tarih¶

Zararlı yazılım (malware, "malicious software"), sahibinin izni ve bilgisi dışında zarar vermek, veri çalmak, kaynak kullanmak ya da kontrolü ele geçirmek için yazılmış her programdır. "Virüs" günlük dilde bunların hepsi için kullanılır; oysa virüs yalnızca bir türdür. Ayrımı görmek için önce birkaç dönüm noktasına bakalım.

3. Zararlı yazılımın anatomisi ve türleri¶

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

Bir virüsü anlamanın en kolay yolu onu üç işleve ayırmaktır. Bir hastalık benzetmesiyle:

Her üç parça da bulunmak zorunda değildir: yükü olmayan, yalnız yayılan bir virüs de vardır (yine de kaynak tüketir ve bir zafiyettir). Tetikleyici koşulu bekleyen ve sonra patlayan koda mantık bombası (logic bomb) denir.

Türleri: yayılma biçimine göre¶

Zararlı yazılımları en yararlı biçimde nasıl yayıldıklarına ve ne yaptıklarına göre ayırırız:

4. Solucanlar ne kadar hızlı yayılır? Salgın modeli¶

Bir solucanın tehlikesini belirleyen şey, yükünden çok hızıdır. Yama yayımlamak, imza dağıtmak, ağ kuralı yazmak saatler, bazen günler alır; solucan ise dakikalar içinde doygunluğa ulaşabilir. Bu hızı sezgiyle değil, hesapla görmek için epidemiyolojiden ödünç alınan basit bir model kullanılır.

SI modeli: duyarlı ve enfekte¶

Ağdaki savunmasız makineleri iki gruba ayırırız: duyarlı (S, henüz bulaşmamış) ve enfekte (I). Her enfekte makine birim zamanda rastgele adresleri tarar; taradığı adres duyarlı bir makineye denk gelirse onu da enfekte eder. Enfekte makine sayısı i, toplam savunmasız makine sayısı N ise:

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

• beta * i(t): enfekte makine ne kadar çoksa, o kadar hızlı taranır (büyüme üsteldir).
• (1 - i(t) / N): duyarlı makineler azaldıkça isabet olasılığı düşer (büyüme doyar).

Sonuç, S biçimli bir eğridir: uzun ve sessiz bir açılış evresi, ardından ani bir patlama, sonra doygunluk. Açılış evresi savunmacının tek fırsat penceresidir; patlama başladığında insan hızında tepki artık yetişmez.

Gerçek sayılar¶

Slammer'ı bu kadar hızlı yapan iki şey vardı: tek bir UDP paketi yeterliydi (bağlantı kurma beklemesi yok) ve hedef bulmak için ağı olabildiğince hızlı tarıyordu. İronik biçimde, ilk dakikadan sonra yavaşlamasının nedeni savunma değil, ağ bant genişliğinin dolmasıydı.

Demo 09 — Solucan salgın simülasyonu¶

cd code\week-02\09-outbreak-simulation
.\demo.ps1

cd code/week-02/09-outbreak-simulation
sh demo.sh

  Scenario: Slammer-like (random scanning, fast UDP)
    N=75000 susceptible  i0=1  doubling=8.50 s
      time        infected  fraction
          54 s          78    0.1% |..............................|
         1.5 min       1430    1.9% |#.............................|
         2.1 min      19700   26.3% |########......................|
         2.4 min      45601   60.8% |##################............|
         2.7 min      65251   87.0% |##########################....|
         3.3 min      74429   99.2% |##############################|
      -> 90% saturation:    2.7 min

  COMPARISON (time to reach 90% saturation):
    Code-Red-like : 48013 s (~13.3 hours)
    Slammer-like  : 165 s (~2.7 minutes)
    Hitlist       : 50 s (~0.8 minutes)

25 Ocak 2003'te SQL Slammer (kod adı Sapphire), 376 baytlık tek bir UDP paketiyle savunmasız SQL Server kopyalarının yarısını 10 dakikadan az sürede enfekte etti — solucan tarihinin en hızlı yayılan örneği. Aşağıdaki animasyon outbreak.c'nin SI fark denklemini (yukarıdaki i(t+dt) = i(t) + beta·i(t)·(1-i(t)/N)·dt) adım adım hesaplar; beta değerini değiştirmenin doygunluk süresini nasıl saatlerden dakikalara indirdiğini gösterir.

Örnek seçiciden Zor: Slammer benzeri hızlı yayılma'yı ve Uç durum: başlangıçta zaten yarısı bulaşmış (hitlist)'i deneyin; 🎲 ile kendi N, i0, beta değerlerinizi de sınayabilirsiniz.

Çıktıyı okurken üç şeye bakın:

1. Açılış evresi: Slammer benzeri senaryoda ilk 54 saniyede yalnız 78 makine enfekte. Grafikte hiçbir şey görünmüyor; oysa bir buçuk dakika sonra patlama başlıyor. "Şimdilik az" demek, üstel büyümede en pahalı yanılgıdır.
2. Hız (beta): Aynı modelde yalnız tarama hızını artırmak, doygunluk süresini saatlerden dakikalara indiriyor. Bu yüzden solucana karşı savunma otomatik olmak zorundadır: güvenlik duvarı kuralı, ağ bölümlemesi, önceden uygulanmış yama.
3. Hitlist: Saldırgan açılış evresini önceden hazırladığı hedef listesiyle atlarsa, savunmacının zaten dar olan fırsat penceresi tamamen kapanır.

5. Yayılma ve gizlenme: nasıl fark edilmez?¶

Bir virüs yakalanmamak için sürekli değişmeye çalışır. Bunun dört aşamalı bir merdiveni vardır; her basamak imza tabanlı tespiti biraz daha zorlaştırır:

Önemli fikir şudur: şifreli gövde her kopyada bambaşka görünür ama çözüldüğünde hep aynıdır. İşte bu yüzden şifreli/paketli içeriğin bir belirtisi vardır: yüksek entropi (bkz. Demo 02). Polimorfik virüste değişen çözücü de sonunda gövdeyi çözmek zorundadır; savunma tam bu noktaya — emülasyona — dayanır.

Demo 01 — İmza, polimorfizm, sezgisel analiz, emülasyon¶

Kapsül biçimi (tamamen zararsız, kendi uydurduğumuz oyuncak biçim):

CAPSULE/1
DECODER: ALGO=xs32 SEED=1a2b3c4d LENGTH=3782 DEC
<3782 bayt karıştırılmış gövde...>

Örnek üretici altı dosya yazar: yakalanmış bir örnek (sample_a.bin), onun tek bayt farklı bir kopyası ve aynı gövdenin farklı anahtar/çözücülerle üç "polimorfik" kopyası. Şimdi her yöntemi sırayla deneyelim:

Derleyip çalıştırın (code/ içinde .\build.ps1 ya da ./build.sh, sonra demo klasöründe):

cd code\week-02\01-signature-scanner ; .\demo.ps1

cd code/week-02/01-signature-scanner && sh demo.sh

Adım 2 — Hash (özet) imzası. Dosyanın SHA-256 özetini veritabanındaki bir özetle karşılaştırır.

STEP 2 - Hash (digest) signature: catches the exact same file
  clean.txt          CLEAN      sha256=98eb0dc95503901a...
  sample_a.bin       CAUGHT     Sample.BlueCat.A
  sample_a_1byte.bin CLEAN      sha256=53cdcf9fe2d6fd4b...
   ^ Change a single byte and the digest is completely different: the hash signature is evaded.

Hash imzası kesindir ama kırılgandır: tek bir bayt değişince özet tamamen değişir (çığ etkisi). Bu yüzden saldırgan dosyaya anlamsız bir bayt eklemekle bile hash imzasını atlatır.

Adım 3 — Desen (bayt dizisi) imzası. Dosyanın içinde bilinen bir bayt dizisinin geçip geçmediğine bakar.

STEP 3 - Pattern (byte sequence) signature: survives small changes
  sample_a.bin       CAUGHT     Sample.BlueCat.A
  sample_a_1byte.bin CAUGHT     Sample.BlueCat.A
  poly_1.bin         CAUGHT     Sample.Decoder.xs32
  poly_2.bin         CAUGHT     Sample.Decoder.xs32
  poly_3.bin         CLEAN
   ^ poly_1/poly_2 were caught by the decoder pattern; poly_3, whose
     decoder changed, was never caught at all (polymorphism).

Desen imzası tek bayt değişikliğine dayanıklıdır ve çözücü kodunu imzalayarak poly_1/poly_2'yi yakalar. Ama çözücüsü de değişmiş olan poly_3 (başka algoritma, farklı komut sırası) hiç yakalanamaz — işte polimorfizmin imza tabanlı tespite karşı gücü budur.

Adım 4 — Aynı gövde, farklı anahtar. Üç polimorfik kopyanın ilk gövde baytları:

  poly_1.bin  body[0..15]: 70 5f a6 24 b0 91 dc 94 db bd 97 3b bd 9e 0b 3e
  poly_2.bin  body[0..15]: 9c bf 1d 0a 8a 28 3c 42 7b 5a df ee 63 94 df a8
  poly_3.bin  body[0..15]: b6 34 7f 2e a2 2f 3b 46 db 0f 2b c2 fe 02 54 8b

Üçü de aynı zararsız gövdeyi taşır ama baytları tamamen farklıdır. Bir imza yazmak imkânsıza yakındır.

Adım 5 — Sezgisel (heuristic) analiz. İmza yoksa şüpheli özelliklere puan verir: yüksek entropi (+50), gövdeden önce çalışan çözücü kod (+30), anlamsız "çöp" komutlar (+20).

STEP 5 - Heuristic analysis: no signature, score suspicious traits
  clean.txt          CLEAN      score=  0 H=4.24
  sample_a.bin       CLEAN      score=  0 H=4.76
  poly_1.bin         SUSPICIOUS score= 80 H=7.95 entropy decoder
  poly_3.bin         SUSPICIOUS score=100 H=7.95 entropy decoder junk-code
  archive.bin        SUSPICIOUS score= 50 H=7.88 entropy
   ^ archive.bin is a harmless high-entropy file: a FALSE POSITIVE.
     sample_a.bin slipped past the heuristic (a false negative).

Sezgisel analiz polimorfik kopyaları imza olmadan yakaladı — ama iki hata yaptı: zararsız, yüksek entropili bir dosyayı (archive.bin) şüpheli işaretledi (yanlış pozitif) ve düz gövdeli sample_a.bin'i kaçırdı (yanlış negatif). İşte Cohen'in dediği belirsizlik burada.

Adım 6 — Emülasyon. Kapsülün çözücüsünü güvenli bir "sanal makinede" çalıştırır (gerçek makine kodu değil, 6 komutluk oyuncak bir dil), çözülen gövdeyi yeniden desenle tarar:

STEP 6 - Emulation: run the decoder in a safe environment, then scan
  clean.txt          CLEAN      not a capsule
  sample_a.bin       CAUGHT     Sample.BlueCat.A | no decoder (plain body)
  poly_1.bin         CAUGHT     Sample.BlueCat.A | 5 commands, 0 NOP, xs32
  poly_2.bin         CAUGHT     Sample.BlueCat.A | 5 commands, 0 NOP, xs32
  poly_3.bin         CAUGHT     Sample.BlueCat.A | 8 commands, 4 NOP, lcg8
  archive.bin        CLEAN      not a capsule

Emülasyon hepsini yakaladı: gövdeyi çözünce üç polimorfik kopya da aynı imzaya döndü. Gerçek antivirüsler de şüpheli dosyayı yalıtılmış bir sanal ortamda "çalıştırıp" çözülmüş halini tarar. Bu güçlüdür ama pahalıdır ve zararlı bunu anlarsa (anti-emülasyon) gizlenebilir.

Fred Cohen 1984'teki konferans bildirisinde (1986'daki doktora teziyle yayımlanan) "bilgisayar virüsü" terimini ilk kez biçimsel olarak tanımladı; aynı çalışma, "bu program bir virüs mü?" sorusunu her program için kusursuzca çözen bir algoritmanın var olamayacağını da kanıtladı (durma problemiyle akraba bir sonuç) — işte bu yüzden gerçek bir tarayıcı tek bir kusursuz yöntem yerine birkaç kusurlu yöntemi katman katman kullanır. Aşağıdaki animasyon scanner.c'nin hash, desen ve emülasyon mantığını birlikte adım adım gösterir: her yöntemin yaptığı bayt karşılaştırmasını ve desen eşleşmesini.

Örnek seçiciden Normal: imza dosyanın ortasında bulunuyor'u ve Zor: birçok neredeyse-eşleşme var, gerçek imza yok'u deneyin; imzanın konum 0'da ya da dosyanın son olası konumunda olduğu uç durumlara da bakmaya değer.

6. Karşı önlemler: nasıl yakalarız?¶

Yukarıdaki demoda dört yöntemi gördük. Şimdi bütün karşı önlem ailesini toparlayalım:

Modern uç nokta koruma (EDR/XDR) bunların hepsini birleştirir ve özellikle davranışa ağırlık verir. Örneğin "kısa sürede yüzlerce dosyayı okuyup yüksek entropili haliyle geri yazan süreç" neredeyse kesin bir fidye yazılımı belirtisidir — dosyaların içine bakmadan, yalnız davranıştan.

Demo 02 — Entropi ölçer: şifreli/paketli içerik nasıl anlaşılır?¶

Burada \(p(b)\), b baytının dosyadaki görülme olasılığıdır. Düz metin az sayıda karakteri sık kullanır (düşük H); şifreli/sıkışık veri tüm baytları eşit kullanır (H ≈ 8).

cd code\week-02\02-entropy ; .\demo.ps1

cd code/week-02/02-entropy && sh demo.sh

Örnek dosyalar iki platformda da aynı biçimde üretilir (harici araç gerekmez): tekdüze, düz metin, makine kodu benzeri sentetik veri, AES-256-GCM ile şifreli ve rastgele dosyalar.

STEP 1 - Entropy of different kinds of files (0 = uniform, 8 = random)
  file             bytes    H |0 bit ------------ 8 bit| verdict
  uniform.txt      4096  0.00 |........................| uniform
  document.txt     3504  4.06 |############............| low
  code.bin         2048  6.23 |###################.....| medium
  encrypted.bin    3520  7.94 |########################| HIGH
  random.bin       4096  7.95 |########################| HIGH
   ^ Text is low, machine-code-like is medium, encrypted/random is high.
--------------------------------------------------------------
STEP 2 - The same content in three forms: plain -> machine-code-like -> encrypted
  document.txt     3504  4.06 |############............| low
  code.bin         2048  6.23 |###################.....| medium
  encrypted.bin    3520  7.94 |########################| HIGH
   ^ Encrypted and random data CANNOT BE TOLD APART by entropy alone.

İki önemli sonuç: (1) Entropi tek başına "zararlı mı?" sorusunu yanıtlamaz — şifreli, sıkıştırılmış ve rastgele veri hep 8'e yakındır; bir .zip ya da .png de öyle. Düz metin düşük (~4), derlenmiş makine kodu orta (~6) çıkar. (2) Ama beklenmedik yerde yüksek entropi bir ipucudur. Adım 3 bunu gösterir: bir metnin ortasına gizlenmiş şifreli bölüm, pencereli taramada "sıcak bölge" olarak ortaya çıkar — paketlenmiş programlarda da tipik olan "küçük açıcı kod + yüksek entropili gövde" deseni.

STEP 3 - A mixed file: an encrypted section hidden in the middle of text
  mixed.bin (4608 bytes), window 512 bytes:
    1024-  1535  4.04 |################................| low
    1536-  2047  7.54 |##############################..| HIGH   <-- gizli bölge
    2048-  2559  7.57 |##############################..| HIGH
    3072-  3583  4.03 |################................| low
   ^ Packed programs show a similar 'hot spot': a small unpacking
     stub + a high-entropy encrypted body.

Bu ölçünün kökeni Claude Shannon'ın 1948 tarihli "İletişimin Matematiksel Teorisi" (A Mathematical Theory of Communication) makalesine kadar gider: bir baytın "ne kadar tahmin edilemez" olduğunu tek bir sayıya indirger. Savunmacılar bunu yıllar sonra zararlı yazılım taramasına ödünç aldılar — şifreli/paketli gövde düz metinden çok farklı bir "şekil" bırakır.

Aşağıdaki animasyon entropy.c'nin pencereli tarama döngüsünü adım adım gösterir: her pencerenin histogramı nasıl birikir, H = -Σ p(b) log2 p(b) formülü nasıl hesaplanır, ve düz metinden rastgele veriye geçişte H nasıl sıçrar.

Örnek seçiciden Normal: metin baştan sona tutarlı'yı ve Zor: düz metin, sonra rastgele veri — H sıçrıyor'u deneyin; pencerenin dosyayı bölmediği uç durumda son pencerenin nasıl kısaldığına dikkat edin.

Demo 07 — Kural tabanlı tespit: küçük bir kural motoru¶

İmza tabanlı tespitin gelişmiş biçimi, tek bir bayt dizisi yerine kural kullanmaktır. Sektörde bunun en yaygın aracı YARA'dır: bir kural birkaç dize (string) (metin ya da joker içeren onaltılık desen) ve bu dizeler üzerinde bir koşul tanımlar. Demo 07, bu fikri sıfırdan yazılmış küçük bir motorla ve yalnız kendi uydurduğumuz zararsız desenlerle gösterir.

rule Word_Context {
  string $a     = "download"
  string $b     = "run"
  string $magic = "CAPSULE/1"
  condition ($a and $b) and $magic
}

cd code\week-02\07-rule-engine
.\demo.ps1

cd code/week-02/07-rule-engine
sh demo.sh

STEP 2 - Scan five files with five rules
  5 rule(s) loaded
  clean.txt     (no match)
  guide.txt     (no match)
  capsule.bin   Capsule_Format, Marker_Hex, Word_Pair, Word_Context
  variant.bin   Marker_Hex
  notes.txt     Many_Repeats

STEP 3 - False positive: why did the harmless guide match?
  guide.txt (147 bytes)
    Word_Pair              $a=0 $b=1 -> -
    Word_Context           $a=0 $b=1 $magic=0 -> -
   ^ Word_Pair looked at words, not CONTEXT: a FALSE POSITIVE.

STEP 4 - The modified variant: what did the wildcard (??) buy us?
  variant.bin (74 bytes)
    Capsule_Format         $magic=1 $decode=0 -> -
    Marker_Hex             $h=1 -> MATCHED

STEP 5 - The rule file is input too: a broken file is rejected
line 4: the text is empty, too long, or unclosed
rule file REJECTED (broken or incomplete)

Bu demodan çıkan dört ders:

1. Dar kural kaçırır, geniş kural yanlış alarm verir. Word_Pair yalnız iki kelimeye baktığı için zararsız bir kılavuzu da yakaladı (yanlış pozitif). Aynı kelimeleri bağlamla ($magic) birleştiren Word_Context bu hatayı yapmadı. Kural yazmak, hassasiyet ile kapsam arasında denge kurmaktır.
2. Joker, değişen parçayı tolere eder. variant.bin tanıdık yapısını bozduğu için Capsule_Format kuralını atlattı; ama değişken baytları ?? ile atlayan onaltılık desen (Marker_Hex) onu yine yakaladı. Polimorfizme karşı kural yazarken değişmeyen iskeleti hedeflemek gerekir.
3. Kural motoru da bir ayrıştırıcıdır. Kural dosyası dışarıdan gelir; motor bozuk bir dosyayı kabul etseydi, tespit aracının kendisi saldırı yüzeyi olurdu. Demo, hatalı satırı yakalayıp dosyayı tamamen reddediyor (varsayılan ret). Güvenlik araçlarındaki ayrıştırma hataları gerçek dünyada defalarca istismar edilmiştir.
4. Kural, bilinen şeyi yakalar. Hiç görülmemiş bir zararlı için kural yoktur; bu yüzden kural tabanlı tespit sezgisel ve davranış tabanlı yöntemlerle birlikte kullanılır.

Koşul dilinin kendisi ($id, #id op n, and/or/not, "n of them") küçük bir özyineli-inen (recursive-descent) ayrıştırıcıyla değerlendirilir (expr() → and_expr() → not_expr() → primary(), her önceliğe bir gramer seviyesi). Aşağıdaki animasyon bu ayrıştırıcıyı jeton jeton yürür: parantezli bir grup expr()'e nasıl yeniden girip çıkıyor, and/or neden HER ZAMAN iki tarafı da değerlendiriyor (kısa devre yoktur — bkz. and_expr()'in kendi yorumu "resolve both: let the syntax be checked"), ve kırık bir koşulun çökmek ya da sessizce eşleşmek yerine nasıl CONDITION ERROR döndürdüğü.

Örnek seçiciden Normal: parantez + zincirlenmiş "and" (Word_Context kuralı gibi)'yi ve Zor: "not", "or" ve bir #say karşılaştırması bir arada'yı deneyin; eksik bir koşulun CONDITION ERROR ürettiği uç duruma da bakın.

Demo 08 — Bütünlük izleme: beyaz liste mantığı¶

Kara liste "kötü olanı tanı" der; beyaz liste ise "iyi olanı tanı, geri kalan her şeyden şüphelen" der. Bütünlük izleme bunun dosya düzeyindeki biçimidir: sistem bilinen iyi durumdayken her dosyanın kriptografik özeti bir manifeste yazılır; sonra düzenli olarak yeniden hesaplanıp karşılaştırılır. Tripwire gibi araçlar, uygulama beyaz listeleri (Windows'ta AppLocker/WDAC) ve işletim sistemlerinin kod imzalama denetimleri aynı fikre dayanır.

cd code\week-02\08-integrity-monitoring
.\demo.ps1

cd code/week-02/08-integrity-monitoring
sh demo.sh

STEP 4 - Simulation: an 'attacker' touches the files
  a line was added to library.bin, data.txt was removed, hidden.bin was dropped
  OK       config.conf      9b1741bb66d862e8...
  DELETED  data.txt         (in the manifest, not in the folder)
  CHANGED  library.bin      5ab02b714a50... -> 12c5803ffe5b... (48->62 B)
  OK       start.txt        56d6b8da7f680093...
  NEW      hidden.bin       28262e242da3d683... (not in the baseline)
  RESULT: 3 deviation(s) found -> investigate!

STEP 5 - To cover their tracks, the attacker rewrites the manifest too
  OK       config.conf      9b1741bb66d862e8...
  OK       hidden.bin       28262e242da3d683...
  OK       library.bin      12c5803ffe5bb001...
  OK       start.txt        56d6b8da7f680093...
  RESULT: integrity preserved (4 file(s))
   ^ If the manifest isn't protected, the monitor is FOOLED: everything looks OK.

STEP 6 - But the seal (HMAC) cannot be regenerated without the key
  SEAL INVALID: the manifest was changed by someone without
  the key -> DO NOT TRUST the manifest

Demonun asıl dersi 5. ve 6. adımlardadır: özet değişikliği yakalar, ama beklenen değerler de korunmalıdır. Dosyaları değiştirebilen biri manifesti de değiştirebiliyorsa izleyici "her şey yolunda" der. Çözüm, manifesti anahtarlı bir özetle (HMAC) ya da dijital imzayla mühürlemek ve anahtarı izlenen dosyalarla aynı yerde tutmamaktır. Karşılaştırma da sabit zamanlı yapılır; aksi halde süre farkı doğru baytların sayısını sızdırabilir.

7. Olay incelemeleri: hangi programlama hatası, hangi önlem?¶

Tarihteki büyük salgınların neredeyse hepsi, bir programlama ya da yapılandırma hatasının üzerine kurulmuştur. Aşağıdaki tabloda her olayı zararlının ne yaptığıyla değil, içeri nasıl girdiğiyle okuyoruz; çünkü bu dersin konusu o giriş kapısını kapatmaktır.

Tabloyu yukarıdan aşağı okuyunca bir eğilim görülür: 1988–2008 arasındaki salgınların çoğu tek bir arabellek taşmasıyla yayıldı. 2017'den sonra ise giriş kapısı giderek güncelleme ve derleme süreçlerine kaydı: saldırgan kodu kırmak yerine, kodun kullanıcıya ulaştığı yolu ele geçirdi. Bu dersin iki ucu buradan çıkar: bir yanda sınır denetimi ve güvenli bellek yönetimi (1. ve 4. hafta), öbür yanda imzalı güncelleme, bütünlük doğrulaması ve tedarik zinciri güvenliği (3., 5. ve 10. hafta).

8. Saldırı ağaçları¶

Saldırı ağacını geçen hafta çizmiştik; bu hafta niceliğe dökeceğiz. Kök, saldırganın hedefidir; dallar ona ulaşma yollarıdır. VEYA düğümünde bir dal yeter, VE düğümünde hepsi gerekir. Her yaprağa bir maliyet (gün-adam, ekipman, uzmanlık) yazarsak, ağacı aşağıdan yukarı çözerek en ucuz saldırıyı bulabiliriz:

• VEYA düğümü: çocukların en ucuzu (saldırganın işine gelen).
• VE düğümü: çocukların toplamı (hepsi gerektiği için).

Demo 04 — Saldırı ağacı maliyet hesaplayıcı¶

Windows: cd code\week-02\04-attack-tree ; .\demo.ps1 · WSL/Linux: cd code/week-02/04-attack-tree && sh demo.sh (önce code/ içinde bir kez derleyin).

  [OR] Obtain the payment key  (cost=2)
    [AND] Copy and decrypt the local database [all required]  (cost=9)
    [OR] Read it from memory during use [one is enough]  (cost=2)
      Read memory with a debugger  (cost=2)
    [AND] Eavesdrop between the server and the phone [all required]  (cost=15)

  CHEAPEST ATTACK = 2 unit(s). ... the weakest point:
  -> Read it from memory during use -> Read memory with a debugger

En ucuz yol 2 birim: bellekteki anahtarı okumak. İkinci ağaç, bu dala RASP (hata ayıklayıcı ve kanca algılama — 6. hafta) eklendiğinde ne olduğunu gösterir:

  [OR] Obtain the payment key  (cost=8)
    [OR] Read it from memory during use [one is enough]  (cost=8)
      Memory dump (defeat random wiping)  (cost=8)
  CHEAPEST ATTACK = 8 unit(s).

Savunma, en ucuz saldırıyı 2'den 8'e çıkardı; en zayıf nokta değişti. Bu, güvenlik yatırımını sayıyla gerekçelendirmenin yoludur: "Şu önlem, en ucuz saldırıyı 4 kat pahalılaştırıyor." VE düğümleri saldırganı birden çok katmanı birlikte kırmaya zorlar — derinlemesine savunmanın niceliksel karşılığı.

1999'da Bruce Schneier'in "Attack Trees" makalesi, bu VE/VEYA yapısını güvenlik camiasına tanıttı: her düğüme bir maliyet ya da olasılık koyup en ucuz yolu hesaplayarak bulmak, sezgiyle tartışmaktan daha güvenilirdir. Aşağıdaki animasyon tree.c'nin maliyet hesaplamasını aşağıdan yukarı, düğüm düğüm gösterir: VE düğümünde maliyetler toplanır, VEYA düğümünde en ucuz dal seçilir.

Örnek seçiciden Normal: kök OR, üç seçenekten en ucuzu kazanıyor'u ve Zor: beş AND grubu, aralarındaki fark küçük'ü deneyin; kökün tek bir yaprak olduğu uç duruma da bakın.

9. Güvenlik denetim kaydı: kanıt olarak günlük¶

Saldırı ağacı "saldırgan nereden gelir?" sorusunu sorar; denetim kaydı (audit log) ise "geldi mi, ne yaptı?" sorusunu cevaplar. Bir olaydan sonra neyin olduğunu anlamanın, sorumluyu bulmanın ve bir daha olmasını önlemenin tek yolu güvenilir kayıttır. Kitap bu konuyu Tarif 13.11'de işler; oradaki öneriler bugün de geçerlidir, yalnız araçlar güncellenmiştir.

Ne kaydedilir, ne asla kaydedilmez?¶

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. Bu yüzden öğretim üyesinin yöntemlerinden biri, sürüm derlemesinde hata ayıklama günlüğünü koddan tamamen çıkarmaktır: kapalı bir bayrakla susturulmuş günlük kodu binary dosyada kalır ve hem dizeleriyle bilgi sızdırır hem de yeniden açılabilir.

Demo 10 — Günlük enjeksiyonu (CWE-117)¶

Günlük satırı çoğu zaman kullanıcıdan gelen bir alan içerir: kullanıcı adı, dosya adı, istek yolu. Bu alan satır sonu (\n, \r) ya da terminal kontrol karakteri (ESC dizileri) içeriyorsa, saldırgan günlüğe hiç yaşanmamış bir olayı yazdırabilir ya da gerçek bir satırı ekranda gizleyebilir.

cd code\week-02\10-log-injection
.\demo.ps1

cd code/week-02/10-log-injection
sh demo.sh

STEP 1 - UNSAFE log: the field is written without any check
  AUDIT login user=alice result=FAILURE
  AUDIT login user=bob
  AUDIT login user=admin result=SUCCESS result=FAILURE
  AUDIT login user=carol^[[2K^Mhidden result=FAILURE
STEP 2 - Count the forged line:
  Log: 4 line(s); forged 'admin SUCCESS' line(s): 1
STEP 3 - SAFE log: escaping + a length limit + a fixed format string
  AUDIT login user=bob\x0A2026-... user=admin ...
  AUDIT login user=carol\x1B[2K\x0Dhidden result=FAILURE
  AUDIT login user=AAAAAAAAAAAAAAAA... result=FAILURE
STEP 4 - Count the forged line (safe):
  Log: 4 line(s); forged 'admin SUCCESS' line(s): 0

Güvensiz sürümde üç girdi dört satır üretti: bob adının içine gizlenmiş satır sonu, günlüğe hiç gerçekleşmemiş bir yönetici girişi ekledi. Bu günlüğü okuyan bir yönetici ya da otomatik uyarı sistemi yanlış bir olaya tepki verir; gerçek saldırı ise gürültünün arasında kaybolur. Güvenli sürüm üç şey yapar:

1. Kaçışlama: yazdırılamayan her bayt (\n, \r, ESC) \xNN biçiminde yazılır; her girdi tek satır kalır.
2. Sınır: alan belirli bir uzunlukta kırpılır (...); günlük dosyası bir girdiyle şişirilemez.
3. Sabit biçim dizesi (format string): alan hiçbir zaman printf/syslog'un biçim dizesi olarak verilmez. Kitabın Tarif 13.11'de uyardığı syslog(LOG_INFO, user_input) hatası bir biçim dizesi açığıdır (CWE-134; 4. haftada ayrıntılı): doğrusu syslog(LOG_INFO, "%s", user_input).

Aşağıdaki animasyon logtool.c'nin güvensiz ve güvenli yazma yollarını yan yana gösterir: kaçışlama döngüsünün her baytı nasıl işlediğini, sınırın nerede devreye girdiğini.

Örnek seçiciden Normal: UNSAFE — satır sonu sahte bir kayıt oluşturuyor'u ve Zor: SAFE — AYNI saldırı, kaçışlanınca zararsız'ı deneyin; ANSI kaçış dizisi + satırbaşı içeren uç duruma da bakın.

Kurcalamaya dayanıklı günlük¶

Enjeksiyonu önlemek günlüğün doğru yazılmasını sağlar; ama sisteme sızan bir saldırganın izini silmek için günlüğü sonradan değiştirmesini engellemez. Günlüğün değiştirilemez olması gerekmez; değiştirildiğinin fark edilmesi yeterlidir. Bunun iki klasik yolu vardır:

• Özet zinciri: her kayıt bir önceki kaydın özetini içerir. Bir saldırgan bir kaydın içeriğini, ondan sonraki özetleri de yeniden hesaplamadan değiştirirse, yalnızca o tek kayıt doğrulanamaz — doğrulayıcı her zaman her kaydın kendi saklanan özetiyle karşılaştırır, bu yüzden sonraki kayıtlar (kendi değişmemiş içerikleri ve değişmemiş önceki özetle) yine geçer. Asıl zayıflık anahtar olmamasıdır: dosyayı yeniden yazabilen bir saldırgan, kurcalama noktasından itibaren her özeti yeniden hesaplayıp bütün zinciri yine tutarlı gösterebilir — kurcalamayı tamamen gizleyebilir.
• HMAC zinciri ve anahtar evrimi: her kayıt anahtarlı bir özetle mühürlenir; üstelik anahtar her kayıttan sonra tek yönlü bir fonksiyonla evrilir ve eski anahtar silinir (Schneier–Kelsey, 1999). Saldırgan makineyi ele geçirdiği anda yalnız o anki anahtarı bulur; ondan geriye, önceki kayıtları mühürleyen anahtarlara dönemez. Böylece ele geçirmeden önceki kayıtlar korunur (ileriye güvenlik).

Doğrulayıcı, başlangıç anahtarını ayrı ve güvenli bir yerde (çevrimdışı) tutar ve zinciri baştan yeniden hesaplayarak her kaydı doğrular.

Demo 11 — Kurcalamaya dayanıklı günlük: HMAC zinciri ve anahtar evrimi¶

cd code\week-02\11-tamper-evident-log
.\demo.ps1

cd code/week-02/11-tamper-evident-log
sh demo.sh

STEP 2 - Verify the sound log (evolve):
  #1 seq=1 "wallet opened"  MAC:OK
  ...
  >>> RESULT: the log is INTACT (every record verified).
STEP 3 - Raw tampering: change seq=4's message (the MAC is left stale)
  #4 seq=4 "payment approved amount=9999"  MAC:BROKEN
  >>> RESULT: the log has been TAMPERED WITH (verification failed).
STEP 4 - DELETING a record: seq=5 is deleted
  #5 seq=6 "session closed"  MAC:BROKEN  ORDER:BROKEN

Kayıt değiştirildiğinde MAC tutmuyor; kayıt silindiğinde hem MAC hem sıra numarası bozuluyor. Demonun son adımları asıl farkı gösterir: saldırgan makinede bulduğu anahtarla günlüğü yeniden yazmaya çalıştığında, statik anahtarlı günlükte bütün geçmişi yeniden mühürleyip doğrulayıcıyı kandırabilir; anahtar evrimli günlükte ise yalnız ele geçirme anından sonraki kayıtlara dokunabilir, çünkü önceki anahtarlar artık hiçbir yerde yoktur.

Aşağıdaki animasyon log_chain.c'nin HMAC zincirini gösterir: her kaydın özeti bir öncekinin özetini nasıl içerir, ve bir kaydın mesajını değiştirmenin yalnız o kaydı nasıl "BROKEN" yaptığı — sonraki kayıtlar yine doğrulanır, çünkü zincir her zaman saklanan özetleri izler, asla yeniden hesaplanmış birini değil (gerçek log_chain.exe ile doğrulandı: yalnız seq=4'ü değiştirmek seq=5 ve seq=6'yı MAC:OK bırakıyor).

Örnek seçiciden Normal: sağlam zincir, anahtar evrimi açık'ı ve Zor: EN BAŞTAKİ kayıt değiştiriliyor — yine de yalnızca o kayıt bozuluyor'u deneyin; sabit anahtarla (evrim kapalı) aynı saldırının neden yakalanmadığını gösteren uç duruma da bakın.

10. Erişim denetimi: kim, neye, ne yapabilir?¶

Şimdi savunma tarafına geçiyoruz. Güvenliğin en temel sorularından biri: "Bu özne, bu nesne üzerinde bu işlemi yapabilir mi?" Bunu üç kavramla düzenleriz:

• Özne (subject): işlemi yapan (kullanıcı, süreç).
• Nesne (object): üzerinde işlem yapılan (dosya, kayıt, bellek).
• Hak/izin (right): yapılabilen işlem (oku, yaz, çalıştır).

Erişim denetim matrisi¶

En genel model, satırların özne, sütunların nesne olduğu ve her hücrede izinlerin yazdığı bir matristir:

Bu matris kavramsaldır; gerçekte iki biçimde saklanır:

• Erişim denetim listesi (ACL): Matris sütun sütun saklanır — her nesne "bana kimler erişebilir" listesini tutar. Unix dosya izinleri ve Windows DACL böyledir.
• Yetenek (capability): Matris satır satır saklanır — her özne "nelere erişebilirim" biletlerini tutar.

DAC, MAC, RBAC¶

Gerçek sistemler bunları birlikte kullanır: DAC sahibin isteğini, MAC sistemin zorunlu sınırını, RBAC de yönetim kolaylığını sağlar. Etkin karar genellikle hepsinin kesişimidir ("hem sahip izin vermeli hem sistem politikası izin vermeli").

Demo 03 — Erişim matrisi ve model simülatörü (bölüm 11 ile birlikte)¶

Bu demoyu bir sonraki bölümde biçimsel modellerle birlikte çalıştıracağız; ama ilk adımı salt DAC matrisidir:

Windows: cd code\week-02\03-access-model ; .\demo.ps1 · WSL/Linux: cd code/week-02/03-access-model && sh demo.sh.

STEP 0 - Pure DAC (access control matrix): the owner's permission decides
  library(D   ) R   payment_key (D   ) DAC:YES BLP:OK  BIBA:OK   => ALLOW
  app    (D   ) R   payment_key (D   ) DAC:no  BLP:OK  BIBA:OK   => DENY
  attacker(D   ) R   payment_key (D   ) DAC:no  BLP:OK  BIBA:OK   => DENY
   ^ app READ payment_key: not in the matrix -> DENY (least privilege)

Matriste hakkı olmayan hiçbir özne erişemez — en az ayrıcalık ilkesinin doğrudan uygulaması. Uygulamanın bile ödeme anahtarına doğrudan erişimi yoktur; yalnız güvenlik kütüphanesi erişebilir.

11. Biçimsel güvenlik modelleri¶

DAC "sahip ne derse o" der; ama bu bir sızıntıyı sistemsel olarak önleyemez. Örneğin gizli bir belgeyi okuyabilen bir program, o bilgiyi herkese açık bir dosyaya yazabilir — DAC buna engel değildir. Zorunlu (MAC) modeller tam bu boşluğu kapatır. Üç klasik modeli göreceğiz.

Bell–LaPadula (BLP) — gizlilik¶

1973'te askeri gizlilik için tasarlandı. Nesnelere ve öznelere gizlilik seviyeleri verilir (Genel < Gizli < Çok Gizli). İki kural:

• Basit güvenlik özelliği ("yukarı okuma yok"): Bir özne, kendi seviyesinden daha gizli bir nesneyi okuyamaz. (Memur çok gizli belgeyi göremez.)
• Yıldız (*) özelliği ("aşağı yazma yok"): Bir özne, kendi seviyesinden daha az gizli bir nesneye yazamaz. (General, çok gizli bilgiyi genel bir belgeye yazıp sızdıramaz.)

Özetle BLP "read down, write up" der: aşağıyı oku, yukarı yaz. Amacı gizliliği korumaktır.

Biba — bütünlük¶

1977'de Biba, BLP'yi tersine çevirdi. Bu kez seviyeler güvenilirlik/bütünlük düzeyidir (Dış < Uygulama < Çekirdek). Kurallar simetriktir:

• "Aşağı okuma yok": Bir özne, kendinden daha az güvenilir bir nesneyi okuyamaz. (İş mantığı, doğrulanmamış dış girdiye doğrudan güvenmez.)
• "Yukarı yazma yok": Bir özne, kendinden daha güvenilir bir nesneye yazamaz. (Ağdan veri alan bileşen, imzalı yapılandırmayı bozamaz.)

Yani Biba "read up, write down" der ve bütünlüğü korur: kirli veri, temiz veriyi bozamaz.

Clark–Wilson — ticari bütünlük¶

1987'de Clark ve Wilson, banka gibi ticari sistemler için farklı bir bütünlük modeli önerdi. Askeri seviyeler yerine iyi biçimli işlemler ve görev ayrılığı üzerine kuruludur:

• Kısıtlı veri öğeleri (CDI): Bütünlüğü korunması gereken veriler (hesap bakiyesi).
• Dönüşüm yordamları (TP): CDI'yi yalnız onaylı, iyi biçimli işlemler değiştirebilir (doğrudan yazma yok). Örneğin bakiye ancak "para yatır/çek" yordamıyla değişir.
• Bütünlük doğrulama yordamları (IVP): Verinin tutarlı olduğunu düzenli olarak denetler ("borç = alacak").
• Görev ayrılığı (separation of duty): İşlemi başlatan ile onaylayan farklı kişilerdir.

Clark–Wilson'ın ruhu bugünkü yazılıma doğrudan geçer: veriye doğrudan değil, doğrulanmış işlemlerle dokun; kritik adımı tek kişiye/tek yola bağlama. Geçen haftaki "ayrıcalıkların ayrılması" ilkesinin biçimsel halidir.

Demo 03 — Modelleri karşılaştır¶

  clerk  (Publ) R   operation   (TopS) DAC:YES BLP:DENY BIBA:OK   => DENY
  general(TopS) W   notice      (Publ) DAC:YES BLP:DENY BIBA:OK   => DENY
   ^ clerk READ operation: reading up -> DENY (cannot see secret information)
     general WRITE notice: writing down -> DENY (a leak is prevented)

  listener(Exte) W   record      (Appl) DAC:YES BLP:OK  BIBA:DENY  => DENY
  processor(Appl) R   incoming    (Exte) DAC:YES BLP:OK  BIBA:DENY  => DENY
   ^ listener WRITE record: writing up -> DENY (dirty data must not corrupt clean data)
     processor READ incoming: reading down -> DENY (don't trust untrusted input)

Dikkat edin: DAC her iki durumda da YES (sahip izin vermiş); zorunlu modeli devreye sokan sistemdir. Etkin karar DAC VE MAC olduğu için, sahip izin verse bile model reddedebilir. Politika dosyalarını (policy-confidentiality.txt, policy-lwm.txt) açıp kendi kurallarınızı yazabilirsiniz.

Aşağıdaki animasyon access.c'nin dominates() fonksiyonunu adım adım gösterir: BLP ve Biba'nın aynı etiket karşılaştırmasını nasıl ters yönde kullandığını, "yukarı okuma" ile "aşağı yazma"nın tam olarak hangi karşılaştırmaya karşılık geldiğini.

Örnek seçiciden Normal: BLP, yukarı okuma reddediliyor'u ve Zor: Biba, seviye tutuyor ama kategori kümesi tutmuyor'u deneyin; eşit etiketlerin her zaman izin verdiği uç duruma da bakın.

Bir üçüncü model: Chinese Wall (Brewer–Nash, 1989). BLP ve Biba sabit bir hiyerarşiye dayanır; ama bir danışmanlık firmasında asıl risk çıkar çatışmasıdır — aynı danışman hem BankA hem rakibi BankB için çalışırsa, birinin gizli verisi ötekine sızabilir. David Brewer ve Michael Nash'in 1989 modeli bunu geçmişe bağlı bir kuralla çözer: bir özne bir şirketin verisini okuduktan sonra, aynı çıkar grubundaki rakip şirketlerin verisi ona kapanır.

  consultant1 R   a_balance_sheet  DAC:YES CW:OK   => ALLOW
  consultant1 R   b_balance_sheet  DAC:YES CW:DENY  => DENY
     ^ BankA already read; BankB is in the same class (bank)
  consultant2 W   market_summary  DAC:YES CW:DENY  => DENY
     ^ BankB's data could leak into a public object

BLP/Biba'dan farklı olarak karar burada geçmişe bağlıdır: aynı istek, danışman daha önce hangi şirketi okuduğuna göre bir kez İZİN, bir kez RED alabilir.

12. Unix ve Windows erişim denetimi modelleri¶

Bu klasik modeller kâğıt üzerinde kalmadı; işletim sistemlerinin izin mimarisi onların pratik halidir.

Unix modeli (Tarif 2.1)¶

Unix, DAC'ı kullanıcı/grup kimlikleri ve izin bitleriyle uygular. Her sürecin üç kimliği vardır: effective (izin denetimlerinde kullanılan), real (gerçek sahip) ve saved (geçici düşürüp geri almak için). Her dosyanın üç grup izin biti vardır — sahip, grup, diğerleri — her birinde oku/yaz/çalıştır:

Ek olarak setuid/setgid bitleri (program, sahibinin yetkisiyle çalışır) ve sticky biti (/tmp gibi paylaşılan dizinlerde başkasının dosyasını silememe) vardır. setuid root bir program, çalıştıran kim olursa olsun root yetkisiyle çalışır — güçlü ama tehlikeli; geçen haftaki "en az ayrıcalık" bu yüzden kritiktir.

Windows modeli (Tarif 2.2)¶

Windows daha ayrıntılı bir ACL modeli kullanır. Her nesnenin (dosya, kayıt defteri anahtarı, mutex) bir güvenlik tanımlayıcısı vardır. İki liste bulunur:

• DACL (Discretionary ACL): erişim kurallarını tutar — kim ne yapabilir. Bir dizi ACE (erişim denetim girdisi) içerir; her ACE bir SID (kullanıcı/grup kimliği), bir hak ve "izin ver / reddet" bilgisidir.
• SACL (System ACL): denetim kurallarını tutar — hangi erişimler günlüğe yazılsın.

Önemli bir tuzak: NULL DACL (hiç girdisi olmayan liste) "herkese tam yetki" demektir — asla iyi bir fikir değildir. Windows en iyi eşleşen ACE'yi seçer; "reddet" girdileri genellikle "izin ver"den önce değerlendirilir.

Modern Windows ayrıca bütünlük seviyeleri (Mandatory Integrity Control) ve AppContainer ile Biba'ya benzer zorunlu sınırlar ekler — yani biçimsel modeller pratikte hâlâ yaşıyor.

Demo 06 — TOCTOU yarış durumu¶

WSL / Linux (bu demo yalnız burada çalışır): cd code/week-02/06-toctou && sh demo.sh (önce code/ içinde ./build.sh). Windows'ta .\demo.ps1 WSL'de nasıl çalıştıracağınızı yazar.

STEP 1 - UNSAFE version: check first, then open (the race window)
  unsafe: 'FORGED-RECORD-added-by-us' -> work/log.txt (written)
  --- Result: contents of secret_target.txt ---
    important data lives in here
    FORGED-RECORD-added-by-us
  >>> ATTACK SUCCEEDED: we redirected the write to another file!

STEP 2 - SAFE version: opens in one step with O_NOFOLLOW
  rejected: the target is a symbolic link (O_NOFOLLOW)
  >>> Attack blocked: secret_target.txt was not corrupted.

1988'de Ken Thompson'ın "Reflections on Trusting Trust" (Turing ödülü konuşması) ve aynı dönemin /tmp yarış saldırıları, denetim ile kullanım arasındaki zaman aralığının kendi başına bir açık olduğunu gösterdi; MITRE bu sınıfa daha sonra CWE-367 (TOCTOU Race Condition) numarasını verdi. Aşağıdaki animasyon logwriter.c'nin güvensiz ve güvenli sürümlerini aynı zaman çizelgesinde, saldırganın sembolik bağı tam ne zaman değiştirdiğini göstererek karşılaştırır.

Örnek seçiciden Normal: UNSAFE + saldırgan araya giriyor — saldırı başarılı'yı ve Zor: SAFE + AYNI saldırgan — O_NOFOLLOW engelliyor'u deneyin.

Demo 12 — Windows erişim denetimi algoritması: ACE'ler nasıl değerlendirilir?¶

Windows bir nesneye erişim isteğini, isteyen sürecin erişim belirtecindeki SID'leri (kullanıcı ve gruplar) nesnenin DACL'ındaki ACE'lerle sırayla karşılaştırarak değerlendirir (Tarif 2.2). Kural basit ama sonuçları şaşırtıcıdır:

1. ACE'ler listedeki sırayla incelenir; belirteçte olmayan SID'e ait ACE atlanır.
2. İstenen haklardan birini içeren bir RET ACE'i eşleşirse istek hemen reddedilir.
3. İZİN ACE'leri istenen hakları biriktirir; hepsi verilince istek kabul edilir.
4. Liste biter ve haklar hâlâ eksikse istek reddedilir (varsayılan ret).
5. Kanonik sıra: açık RET → açık İZİN → miras RET → miras İZİN. Windows'un araçları ACE'leri bu sırayla yazar; elle ya da hatalı kodla bozulan sıra, RET'in hiç okunmamasına yol açabilir.
6. NULL DACL (hiç DACL yok) herkese her hakkı verir; boş DACL (ACE'siz) kimseye hiçbir hak vermez. Nesnenin sahibi ise DACL ne derse desin izinleri okuyup değiştirebilir.

cd code\week-02\12-ace-evaluation
.\demo.ps1

cd code/week-02/12-ace-evaluation
sh demo.sh

== SCENARIO: 1a - the book's DACL, alice is a Marketing member ==
    1. DENY  Everyone       FULL
    2. ALLOW Marketing      WRITE
    3. ALLOW Everyone       READ
  Request WRITE:
    ACE 1 DENY  Everyone      -> matched; WRITE denied
  => DENY  (ACE 1: later ACEs are never consulted)
== SCENARIO: 1b - the same ACEs, ALLOW first (not canonical) ==
    ACE 1 ALLOW Marketing     -> granted WRITE (missing: -)
  => ALLOW  (every requested right was granted)
== SCENARIO: 2a - a NULL DACL, the requester is an unrelated account ==
  => ALLOW  (DANGER: including TAKE_OWNER and WRITE_DAC!)
== SCENARIO: 2b - an EMPTY DACL, the same unrelated account ==
  => DENY  (missing: READ)
== SCENARIO: 3b - inheritance broken (removed) ==
  => DENY  (the list ended; missing: READ)

İlk iki senaryoda ACE'ler aynıdır, yalnız sırası farklıdır: kanonik sırada alice reddedilir, bozuk sırada aynı istek kabul edilir. İkinci adım, programcıların en sık yaptığı hatalardan birini gösterir: bir nesneye "herkes erişsin" diye güvenlik tanımlayıcısını NULL DACL ile oluşturmak, herkese yalnız okuma değil, sahipliği alma ve izinleri değiştirme hakkı da verir. Doğrusu, gerekli hakları açıkça veren bir DACL yazmaktır. Üçüncü adım kalıtımı gösterir: açık ACE'ler miras ACE'lerden önce değerlendirilir; kalıtımı kesip miras ACE'leri silmek, beklenmedik bir varsayılan rede yol açabilir.

Aşağıdaki animasyon ace.c'nin ACE değerlendirme döngüsünü adım adım gösterir: her ACE'nin belirteçteki SID'lerle karşılaştırılmasını, ilk eşleşen RET'in listeyi neden hemen durdurduğunu.

Örnek seçiciden Normal: iki ALLOW ACE birlikte tam izni oluşturuyor'u ve Zor: ALLOW önce gelirse DENY hiç görülmeyebilir (kurallı olmayan sıra)'yı deneyin.

Demo 13 — Unix izinleri, umask ve setuid tuzakları¶

Unix modelinin (Tarif 2.1) üç inceliği, gerçek hataların çoğunu açıklar:

• İlk eşleşen sınıf karar verir. Çekirdek önce "istek yapan dosyanın sahibi mi?" diye bakar; sahipse yalnız sahip bitleri geçerlidir, grup ve diğerleri bitlerine hiç bakılmaz. Sahip değil ama grup üyesiyse yalnız grup bitleri, hiçbiri değilse diğerleri bitleri kullanılır.
• umask, yeni dosyanın izinlerini daraltır: gerçek izin = istenen & ~umask. fopen() her zaman 0666 ister; umask 000 ise dosya herkese yazılabilir olur. Hassas dosya open(..., 0600) ile açılmalıdır (Tarif 2.7, 1. hafta).
• setuid program, çalıştıran kişinin değil dosya sahibinin yetkisiyle çalışır. Gerçek, etkin ve saklı kullanıcı kimliği ayrımını bilmeyen bir program, yetkisini "bıraktığını" sanırken saklı kimlik üzerinden geri alınabilir durumda bırakır (Tarif 1.3).

cd code\week-02\13-unix-permissions-umask
.\demo.ps1

cd code/week-02/13-unix-permissions-umask
sh demo.sh

A) Kernel permission check: the first matching class decides
  process request  file          owner:group    perms       class -> decision
  mark    write    report.txt    alice:accounting rw-r-----   group -> DENY
  alice   read     paradox.txt   alice:accounting ---rwxrwx   owner -> DENY
  zoe     read     paradox.txt   alice:accounting ---rwxrwx   other -> ALLOW
   ^ alice CANNOT READ paradox.txt: the owner class was picked and
     the owner bits are '---'; the group/other bits are never consulted.
B) umask: the real permission = requested & ~umask (Recipe 2.7)
  requested umask 000    umask 022    umask 077
  0666      rw-rw-rw-    rw-r--r--    rw-------
C) setuid simulation: alice (uid 1001) runs a setuid program
   owned by root. After exec: effective=saved=0.
    seteuid(1001)                  r/e/s=1001/1001/0 g=1001 ok

paradox.txt örneği sezgiye ters düşer: dosyanın sahibi olan alice onu okuyamaz, ama hiç ilgisi olmayan zoe okuyabilir. Kimlik doğrulamada "önce kim olduğuna bak, sonra yalnız o sınıfın kuralını uygula" mantığı, izinleri yazarken her sınıfı ayrı ayrı düşünmeyi gerektirir. Setuid adımı ise seteuid() ile yapılan geçici bırakmanın saklı kimliği 0 bıraktığını, yani yetkinin geri alınabileceğini gösterir; kalıcı bırakma için setresuid() ile üç kimliğin de değiştirilmesi ve sonucun doğrulanması gerekir.

Aşağıdaki animasyon permissions.c'nin izin denetim algoritmasını ve umask hesaplamasını adım adım gösterir: root/owner/group/other sınıfının nasıl seçildiğini, istenen & ~umask bit işlemini.

Örnek seçiciden Normal: sahip okuyor, izin var'ı ve Zor: "sahip okuyamaz" paradoksu (owner bitleri kapalı)'nı deneyin; umask 000'ın 0666 isteğini herkese açtığı tehlikeli uç duruma da bakın.

Demo 14 — RBAC, görev ayrılığı ve Clark–Wilson¶

Clark–Wilson modelinin iki temel fikri iyi biçimli işlem (veriye yalnız sertifikalı işlemler dokunur) ve görev ayrılığıdır (bir işi başlatan onu onaylayamaz). RBAC ise yetkileri kişilere değil rollere verir; statik görev ayrılığı (SSD) bir kişinin çelişen iki role atanmasını, dinamik görev ayrılığı (DSD) ise aynı oturumda ikisini birden etkinleştirmesini yasaklar.

cd code\week-02\14-rbac-clark-wilson
.\demo.ps1

cd code/week-02/14-rbac-clark-wilson
sh demo.sh

== 1 - RBAC: role assignment and separation of duty (SSD/DSD) ==
[01] ASSIGN carl TELLER
     SSD(TELLER,APPROVER): carl cannot hold both -> DENY
[04] SESSION dana TELLER,AUDITOR
     DSD(TELLER,AUDITOR): both cannot be active in the same session -> DENY
[05] SESSION dana AUDITOR
     session opened; active: AUDITOR
== 2 - Clark-Wilson: only a certified TP touches a CDI ==
== 3 - Separation of duty: a large transfer needs a second person's approval ==
[20] dana IVP
     IVP expected total from the ledger 20250, found 20250
  => CONSISTENT (C1: the CDIs are in a valid state)
== 4 - If a broken TP gets certified, the IVP catches it ==
[31] dana IVP
     IVP expected total from the ledger 20250, found 20220
  => INCONSISTENT! difference -30: a TP is broken, or a CDI changed outside a TP

Dördüncü adım modelin en öğretici yanıdır: sertifikacı hatalı bir işlemi sertifikalarsa, zorlama kuralları (E1–E4) bunu fark edemez, çünkü işlem "yetkili" görünmektedir. Hatayı yakalayan, bağımsız çalışan IVP'dir: toplamlar defterle tutmaz. Programcı için ders: yetki denetimi tek başına yetmez; verinin tutarlılığını ayrıca doğrulayan bir mekanizma gerekir.

Aşağıdaki animasyon bank.c'nin E1–E4 kapılarını (rol var mı, TP sertifikalı mı, oturum açık mı, CDI yalnız TP ile mi değişiyor) sırayla gösterir: hangi kapı isteği durdurduğunu, hangi kapıların geçtiğini.

Örnek seçiciden Normal: beş kapı da geçiyor, TP çalışıyor'u ve Zor: rol doğru ama TP sertifikalı değil (E1'de durur)'u deneyin.

13. Yazılım güvenlik açıklarının sınıflandırılması: CWE¶

Bir açık bulduğunuzda onu adlandırmalısınız ki başkaları anlasın, tekrar bulunmasın ve önlem alınabilsin. İlk araç CWE'dir (Common Weakness Enumeration): MITRE'ın yürüttüğü, zayıflık türlerinin numaralı kataloğu. CVE belirli bir üründeki belirli bir açıksa, CWE onun türüdür.

CWE Top 25, o yıl en çok görülen ve en tehlikeli 25 zayıflığın listesidir; gerçek CVE verisinden, sıklık ve ciddiyet birleştirilerek hesaplanır. Bir güvenlik programının "önce neye bakmalıyım?" sorusuna iyi bir başlangıç cevabıdır. Yıllardır ilk sıralarda sınır dışı yazma (CWE-787), XSS (CWE-79) ve SQL enjeksiyonu (CWE-89) yer alır.

14. OWASP Top 10 ve MASVS¶

CWE tüm zayıflıkları kataloglar; OWASP ise bunları belirli alanlarda öncelik listelerine ve doğrulama standartlarına çevirir.

• OWASP Top 10: Web uygulamalarında en kritik on risk kategorisi (ör. erişim denetimi kırılması, kripto hataları, enjeksiyon, güvensiz tasarım). Bir farkındalık ve öncelik belgesidir; her madde birçok CWE'yi kapsar.
• OWASP ASVS (Application Security Verification Standard): "Güvenli sayılmak için hangi denetimleri geçmeli?" sorusunun web için ayrıntılı, seviyeli kontrol listesidir.
• OWASP MASVS (Mobile Application Security Verification Standard): Aynı fikrin mobil karşılığı. Bu ders mobil koruma ağırlıklı olduğundan MASVS bizim için özellikle önemlidir. Kategorileri (kısaca): STORAGE (depolama), CRYPTO, AUTH (kimlik doğrulama), NETWORK, PLATFORM, CODE (kod kalitesi), RESILIENCE (dayanıklılık — tersine mühendislik ve kurcalamaya karşı koruma). MASVS'in eşlik ettiği test kılavuzu MASTG'dir.

15. CVE ve CVSS: hangi açık, ne kadar ciddi?¶

• CVE (Common Vulnerabilities and Exposures): Belirli bir üründeki belirli bir açığın benzersiz kimliği, ör. CVE-2014-0160 (Heartbleed). CVE bir isimdir, ciddiyet değil. Bir CVE, bir ya da birden çok CWE türüne aittir.
• CVSS (Common Vulnerability Scoring System): Bir açığın ciddiyetini 0.0–10.0 arasında bir sayıya çeviren sistem. FIRST tarafından yürütülür. Üç grup metrik vardır: Temel (açığın kendi özellikleri, değişmez), Zamansal (sömürü kodu var mı, yama çıktı mı), Çevresel (sizin ortamınızda ne kadar önemli). Bu derste Temel puana odaklanacağız.

CVSS v3.1 Temel puanın sekiz metriği:

Demo 05 — CVSS v3.1 taban puan hesaplayıcı¶

Windows: cd code\week-02\05-cvss ; .\demo.ps1 · WSL/Linux: cd code/week-02/05-cvss && sh demo.sh. Elle: python3 cvss.py --examples (Windows'ta py -3.12 cvss.py --examples).

  1) Remote, no authentication needed, full takeover (Heartbleed-like severity)
  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    BASE SCORE = 9.8  |####################|  Critical

  2) The same, but the SCOPE changed (impact spills outside the box) -> higher
  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    BASE SCORE = 10.0  |####################|  Critical

  4) Local privilege escalation (the device is in the attacker's hands) -> high
  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
    BASE SCORE = 7.8  |################....|  High

Aynı etki (C:H/I:H/A:H) olsa bile, uzaktan + kimliksiz bir açık (9.8) yerel + yetkili bir açıktan (7.8) daha yüksek puan alır; kapsam değişince 10.0'a çıkar. FIRST (Forum of Incident Response and Security Teams), CVSS v3.1 özelliğini Haziran 2019'da yayımladı — bu demonun test_cvss.py'si tam o belgedeki örnek puanlara karşı doğrulanır. Puanları ciddiyet bandına çeviririz:

Aşağıdaki animasyon cvss.py'nin taban puan hesabını adım adım gösterir: Etki (Impact) ve Sömürülebilirlik (Exploitability) alt puanlarının sekiz metrikten nasıl hesaplandığını, kapsam değiştiğinde formülün neden değiştiğini.

Örnek seçiciden Normal: Heartbleed benzeri (uzaktan, yetki yok, tam ele geçirme)'yi ve Zor: aynı açık, Kapsam Değişti — puan daha yüksek'i deneyin; hiç etkisi olmayan ve puanı sabit 0.0 çıkan uç duruma da bakın.

16. Zafiyet yaşam döngüsü ve sorumlu ifşa¶

Bir açık keşfedildiği andan kamuya açıldığı ana kadar bir yaşam döngüsünden geçer. Bu döngünün nasıl yönetildiği, kullanıcıların risk altında kaldığı süreyi belirler.

Anahtar kavramlar:

• Zero-day (sıfırıncı gün): Satıcının henüz bilmediği ya da yamasının olmadığı açık. En tehlikeli durum, çünkü savunma yoktur.
• Sorumlu ifşa (coordinated disclosure): Araştırmacı açığı önce satıcıya bildirir, makul bir süre (genellikle 90 gün) yama için bekler, sonra kamuya açıklar. Amaç, kullanıcıları korurken satıcıyı da harekete geçirmektir.
• Tam ifşa (full disclosure): Açığın hemen kamuya açıklanması. Satıcıyı zorlar ama kullanıcıları riske atar; tartışmalıdır.
• Hata ödül programları (bug bounty): Şirketlerin, açıkları sorumlu biçimde bildiren araştırmacılara ödül verdiği programlar. Sorumlu ifşayı teşvik eder.
• Yama boşluğu (patch gap): Yama yayınlandığı an açık kamuya açılır; herkes yamayı tersine mühendislikle inceleyip açığı öğrenebilir. Güncellemeyen kullanıcılar bu boşlukta savunmasızdır — WannaCry, yama çıktıktan sonra hâlâ güncellememiş makinelere yayıldı.

17. Sık yapılan hatalar ve kontrol listeleri¶

Bu hafta dört büyük konuyu birlikte işledik: zararlı yazılım ve tespit, saldırgan zihniyeti ve denetim kaydı, erişim denetimi modelleri, zafiyet sınıflandırma ve önceliklendirme. Aşağıda her küme için önce en sık düşülen yanılgıları, sonra kendinizi sınayabileceğiniz bir kontrol listesini bulacaksınız. Hata maddelerinin her biri "neden yanlış?" sorusunun kısa cevabını da içerir; kontrol listesindeki her maddeyi bir arkadaşınıza kendi cümlelerinizle anlatabiliyorsanız o konuyu öğrenmişsiniz demektir.

Zararlı yazılım ve tespit¶

Saldırgan zihniyeti, saldırı ağaçları ve denetim kaydı¶

Erişim denetimi ve güvenlik modelleri¶

Zafiyet sınıflandırma ve önceliklendirme¶

18. Dönem projesi: bu hafta (S4)¶

Geçen hafta güvenlik kılavuzunuzun S4 — Tehdit modeli ve saldırgan modeli bölümünün iskeletini kurdunuz: STRIDE ile tehditleri çıkardınız ve kaba bir saldırı tablosu yazdınız. Bu hafta o tabloyu bir değerlendiricinin okuyabileceği hâle getiriyorsunuz: her satır ortak bir dille adlandırılacak (CWE), ölçülecek (CVSS) ve en kritik varlık için en ucuz saldırı yolu bir saldırı ağacıyla gösterilecek.

Adım adım yöntem¶

1. Saldırgan modellerini yazın. Tehditten önce saldırganı tanımlayın; yoksa aynı tehdidi farklı satırlarda farklı varsayımlarla puanlarsınız. Bu dersin bağlamında en az şu üçü bulunmalıdır: uzak saldırgan, aynı cihazdaki kötü amaçlı uygulama ve cihaz sahibi (beyaz kutu) saldırgan.
2. Tehditleri arayüzlerden çıkarın. S3'teki arayüz tablonuzun her satırı (istemci–sunucu, uygulama–kütüphane, kütüphane–yerel veritabanı...) için STRIDE'ın altı harfini sorun. S5'teki her varlık en az bir tehditte görünmelidir; görünmüyorsa ya varlık gereksizdir ya tablo eksiktir.
3. CWE eşleyin. Tehdidin kök nedenini (zayıflığı) adlandırın, sonucunu değil. "Anahtar çalınır" bir sonuçtur; kök neden "anahtar kodun içine gömülü" (CWE-321/CWE-798) ya da "anahtar bellekte açık kalıyor" (CWE-316) olabilir. cwe.mitre.org'da girdinin "Mapping" notuna bakın: bazı üst düzey girdilerin eşlemede kullanılması önerilmez.
4. CVSS vektörünü saldırgan modeline göre kurun. Aynı zayıflık, uzak saldırganda AV:N, cihaz sahibinde AV:L/PR:H verir. Hangi modeli varsaydığınızı sütuna yazın. Puanı Demo 05 ile ya da FIRST'ün hesap makinesiyle hesaplayın ve vektörü tam yazın ki değerlendirici tekrarlayabilsin.
5. Önlemi ve bölümü bağlayın. Her tehdidin önlemi kılavuzun başka bir bölümünde anlatılır (S5, S7, S9, S10, S11, S12). Bölüm sütunu, S17 uyum matrisinin de temelidir.
6. Önceliği gerekçelendirin. Önceliği yalnız puana göre sıralamayın; saldırı ağacındaki en ucuz yol ve varlığın değeri birlikte karar verir. Gerekçeyi bir paragrafla yazın.

Tamamen doldurulmuş sentetik örnek¶

Aşağıdaki örnek, dersin ortak örnek mimarisi olan "mobil ödeme uygulaması + güvenlik kütüphanesi" için yazılmıştır. Uygulama; kullanıcı arayüzünü, sunucu ile iletişimi ve yerel veritabanını yönetir. Güvenlik kütüphanesi (native C) oturum anahtarlarını, tek kullanımlık ödeme anahtarı sayaçlarını ve bütünlük/RASP denetimlerini taşır. Bütün değerler uydurmadır; tablo biçimini ve düşünme yolunu göstermek içindir.

S4.1 — Saldırgan modelleri

S4.2 — Tehdit tablosu (CWE ve CVSS v3.1 eklenmiş)

Vektörlerin tamamı CVSS:3.1/ önekiyle okunur; puanlar Demo 05 ile hesaplanmıştır.

S4.3 — Öncelik ve gerekçe (örnek paragraf)

Taban puana göre sıra T9 (8.8) → T3 (7.4) → T2/T7 (6.5) şeklindedir. Ancak "başkasının hesabından ödeme" hedefinin saldırı ağacı (S4.4) en ucuz yolun T7 (3 birim), ardından T3 (6 birim) olduğunu gösteriyor. T9'un istismarı yüksek uzmanlık gerektiriyor (ağaçta 9 birim). Bu yüzden öncelik sırası T7 → T3 → T9 → T1 olarak belirlendi. T1 ve T4'ün düşük puanı, saldırgan modelimizde (SM4) root'un zaten saldırganın elinde olmasından kaynaklanır; bu iki tehdit, vize teslimindeki RASP ve güvenli silme önlemleriyle birlikte ele alınacaktır.

Saldırı ağacı (örnek)¶

Kök hedef: "Başkasının hesabından ödeme yap." Yaprak maliyetleri örnek gün-adam eforudur. Parantez içindeki T numaraları, yaprağın tehdit tablosundaki satırıdır.

Aynı ağaç, Demo 04'ün GERÇEK girdi biçimiyle (tree.c'nin anahtar sözcükleri her zaman İngilizcedir: GOAL, AND, OR, LEAF, cost=; yaprak açıklamaları da gerçek demo dosyalarındaki gibi İngilizce tutulmuştur):

GOAL: Pay from someone else's account
  AND Pay with a stolen device
    LEAF Bypass the screen lock                cost=6
    LEAF Bypass the app PIN                     cost=5
  AND Copy and exfiltrate the session key
    OR Obtain the key
      LEAF Root + debugger (T1)                 cost=4
      LEAF Copy and decrypt the local DB         cost=8
      LEAF Malicious-link code execution (T9)    cost=9
    LEAF Bypass device binding                  cost=6
  AND Man-in-the-middle on the network
    LEAF Set up a rogue access point            cost=1
    LEAF Bypass certificate validation (T3)     cost=2
    LEAF Replay the session token               cost=3
  AND Abuse the server API
    LEAF Log in with your own account           cost=1
    LEAF Tamper with the transaction number (T7) cost=2

Bu dosyayı gerçekten tree.exe'ye verdiğimizde aldığımız çıktının sonu (tree-fraud-example.txt adıyla kaydedip tree.exe tree-fraud-example.txt ile çalıştırıldı):

  CHEAPEST ATTACK = 3 unit(s). The chain the defender should
  break first (the weakest point):

  -> Pay from someone else's account (cost=3)
    -> Abuse the server API [all required] (cost=3)
      -> Log in with your own account (cost=1)
      -> Tamper with the transaction number (T7) (cost=2)

Önlemleri sırayla uyguladığımızda en ucuz yol şöyle değişti (aynı dosya, yalnız ilgili cost= değeri güncellenip yeniden çalıştırılarak — her satır gerçekten doğrulanmıştır):

Bu tablo S4'ün en güçlü kanıtıdır: iki önlem en ucuz saldırıyı 3'ten 10'a çıkardı ve bir sonraki yatırımın nereye yapılacağını (bellekteki anahtar: RASP, güvenli silme, cihaz bağlama) sayıyla gösterdi. Dikkat edin: CVSS'e göre en ciddi satır olan T9 bu hedef için en ucuz yol değildir; iki aracın birlikte okunmasının nedeni budur.

Değerlendirme ölçütleri¶

S4 vize teslimindeki güvenlik analizi ölçütünün ana parçasıdır. Değerlendirmede aşağıdaki tablo kullanılır.

19. Sınıf etkinlikleri¶

Etkinlikler not verilmez; derste konuları pekiştirmek içindir. Her birinin süresi, grup düzeni ve beklenen çıktısı yazılıdır. Hangi etkinliğin hangi ders saatinde yapılacağı "Ders akışı" planındadır; yetişmeyenler öğrencinin kendi çalışmasına bırakılır.

20. Kod okuma alıştırmaları: zafiyeti bul¶

Aşağıdaki kod parçalarında birer zafiyet var. Türünü (CWE) ve düzeltmesini bulun; cevaplar gizli kutuda.

/* Does the user have access to the file? */
if (access(file, W_OK) == 0) {
    FILE *f = fopen(file, "w");     /* ... */
    fprintf(f, "%s\n", record);
    fclose(f);
}

uint32_t expected = 0x1a2b3c4d;
uint32_t found     = crc32(code_region, size);
if (found != expected)
    return ERROR;   /* tampered */
run();

struct user u;
strncpy(u.name, input, sizeof u.name);
/* u.admin field was never assigned */
if (u.admin) grant_admin_panel();

21. Kendi başına çalış¶

Not verilmez; dersi pekiştirmek içindir. Hepsi code/week-02 üzerinde, yalnız kendi bilgisayarınızda yapılır.

22. Kendini sınama¶

23. Quiz-1 tarzı örnek sorular¶

Quiz-1 (8. hafta) bu tarz kısa cevaplı ve kod okuma soruları içerir. Deneyin; cevapları yukarıdaki bölümlerden doğrulayın.

1. Aşağıdaki türleri "kullanıcı etkileşimi gerektirir / gerektirmez" diye ikiye ayırın: virüs, solucan, truva atı, makro virüsü.
2. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N vektörünün taban puanını ve bandını yazın. (İpucu: tipik bir XSS. Demo 05 ile doğrulayın.)
3. Bir sistemin "yetkisi olmayan kimse gizli belgeyi görmemeli" gereksinimi hangi modelle karşılanır? İki kuralını yazın.
4. access() sonra open() kalıbının açığı nedir (CWE numarasıyla) ve tek satırlık düzeltmesi nedir?
5. İmza tabanlı bir tarayıcının bir polimorfik örneği kaçırmasının nedeni nedir? Hangi yöntem bunu yakalar?

24. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Tarif 2.1 (Unix erişim denetimi modeli), 2.2 (Windows erişim denetimi modeli)
• Tarif 2.3 (bir kullanıcının dosyaya erişimini denetleme; TOCTOU)
• Tarif 12.1 (yazılım korumasının sorunu — saldıran ve savunanın aynı yöntemleri kullanması)
• Tarif 13.11 (denetim günlükleme — SACL/syslog bağlamı)

Açık kaynaklar (adıyla anılabilir)

• F. Cohen, "Computer Viruses — Theory and Experiments", 1984 (virüs tanımı ve tespit sınırı).
• D. E. Bell, L. J. LaPadula, güvenlik modeli raporları, 1973 (gizlilik modeli).
• K. J. Biba, "Integrity Considerations for Secure Computer Systems", 1977 (bütünlük modeli).
• D. Clark, D. Wilson, "A Comparison of Commercial and Military Computer Security Policies", 1987.
• B. Schneier, "Attack Trees", 1999.
• MITRE CWE ve CWE Top 25; MITRE CVE; FIRST CVSS v3.1 ve v4.0 belgeleri.
• OWASP Top 10, ASVS, MASVS ve MASTG.
• Gerçek olaylar (tarih doğrulaması için): Brain (1986), Morris solucanı (1988), ILOVEYOU (2000), Code Red (2001), Stuxnet (2010), WannaCry (2017), NotPetya (2017).