Week 2 — Computer Viruses and Security Models¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming\code
.\build.ps1
cd week-02\01-imza-tarayici ; .\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-imza-tarayici && sh demo.sh

0. Before we start¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full.

What we bring from earlier weeks¶

• Asset, threat, vulnerability, risk, and the attacker model — the language for telling an asset's value, the threat against it, the weakness that makes the threat possible (vulnerability), and risk (probability × impact) apart (Week 1, §1; for the attacker model, Week 1, §3). This week we make this language concrete through malware (the threat side) and access models (the defence side).
• STRIDE and the attack tree — asking STRIDE's six letters against an interface, then breaking the resulting threats down from a root goal into branches with AND/OR logic (Week 1, §7). This week we add cost to the attack tree and compute the cheapest attack path (§8, Demo 04).

This week's concept map¶

1. This week's big picture: threat, model, classification¶

Last week we built the language of security: asset, threat, vulnerability, risk; the attacker model; STRIDE and the attack tree (Week 1, §7). This week we fill in three columns of that language:

• Threat side — malware: We will break the attacker's most visible tool, malicious software, into types (virus, worm, trojan horse, ransomware) and see how it hides. Because part of the answer to "what is ranged against us?" when designing a defence is this.
• Defence side — security models: We will learn to answer "who can access what?" not arbitrarily, but with a formal model (access matrix, DAC/MAC/RBAC, Bell–LaPadula, Biba, Clark–Wilson). These models are the foundation of the permission architecture of operating systems (Unix, Windows).
• Common language — classification: When we find a vulnerability we must name it in a language everyone understands and be able to measure its severity. That is why we have CWE (flaw type), CVE (specific flaw), CVSS (severity score), and OWASP/MASVS (priority lists).

These three are linked: without recognising malware you cannot build a model against it, without building the model you cannot see the remaining flaws, and without naming flaws in a common language you cannot know which threat to prioritise.

2. What is malware? A brief history¶

Malware ("malicious software") is any program written to cause harm, steal data, use resources, or seize control without the owner's permission and knowledge. In everyday language "virus" is used for all of these; however, a virus is only one type. To see the distinction, let's first look at a few milestones.

3. The anatomy and types of malware¶

A virus's three parts¶

The easiest way to understand a virus is to split it into three functions. Using a disease analogy:

Not all three parts have to be present: there are viruses with no payload that only spread (they still consume resources and constitute a vulnerability). Code that waits for the trigger condition and then goes off is called a logic bomb.

Types: by propagation style¶

The most useful way to distinguish malware is by how it spreads and what it does:

4. How fast do worms spread? The epidemic model¶

What determines a worm's danger is its speed, far more than its payload. Releasing a patch, distributing a signature, writing a firewall rule takes hours, sometimes days; a worm, on the other hand, can reach saturation within minutes. To see this speed through calculation rather than intuition, we use a simple model borrowed from epidemiology.

The SI model: susceptible and infected¶

We split the vulnerable machines on the network into two groups: susceptible (S, not yet infected) and infected (I). Every infected machine scans random addresses per unit time; if the scanned address happens to hit a susceptible machine, it infects it too. If i is the number of infected machines and N is the total number of vulnerable machines:

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

• beta * i(t): the more infected machines there are, the faster scanning happens (growth is exponential).
• (1 - i(t) / N): as susceptible machines run out, the hit probability drops (growth saturates).

The result is an S-shaped curve: a long, quiet opening phase, followed by a sudden explosion, then saturation. The opening phase is the defender's only window of opportunity; once the explosion starts, a human-speed response can no longer keep up.

Real numbers¶

Two things made Slammer this fast: a single UDP packet was enough (no waiting to establish a connection), and it scanned the network as fast as possible to find targets. Ironically, the reason it slowed down after the first minute was not the defence — it was that the network bandwidth had filled up.

Demo 09 — Worm Epidemic Simulation¶

cd code\week-02\09-salgin-simulasyonu
.\demo.ps1

cd code/week-02/09-salgin-simulasyonu
sh demo.sh

  Senaryo: Slammer benzeri (rastgele tarama, hizli UDP)
    N=75000 savunmasiz  i0=1  ikilenme=8.50 s
      zaman        enfekte    oran
          54 s          78    0.1% |..............................|
         1.5 dk       1430    1.9% |#.............................|
         2.1 dk      19700   26.3% |########......................|
         2.4 dk      45601   60.8% |##################............|
         2.7 dk      65251   87.0% |##########################....|
         3.3 dk      74429   99.2% |##############################|
      -> %90 doygunluk:    2.7 dk

  KARSILASTIRMA (%90 doygunluga ulasma):
    Code Red benzeri : 48013 s (~13.3 saat)
    Slammer benzeri  : 165 s (~2.7 dakika)
    Hitlist          : 50 s (~0.8 dakika)

When reading the output, look at three things:

1. Opening phase: in the Slammer-like scenario, only 78 machines are infected in the first 54 seconds. Nothing seems to be happening on the chart; yet the explosion begins a minute and a half later. Saying "it's little for now" is the most expensive mistake you can make with exponential growth.
2. Speed (beta): in the same model, merely increasing the scanning speed brings the saturation time down from hours to minutes. That is why defence against a worm has to be automatic: a firewall rule, network segmentation, a patch applied in advance.
3. Hitlist: if the attacker skips the opening phase with a pre-prepared target list, the defender's already narrow window of opportunity closes completely.

5. Propagation and Concealment: How Does It Go Unnoticed?¶

A virus constantly tries to change so as not to get caught. This has a four-step ladder; each step makes signature-based detection a little harder:

The key idea is this: the encrypted body looks completely different in every copy but is always the same once decrypted. This is exactly why encrypted/packed content has a tell: high entropy (see Demo 02). In a polymorphic virus, the changing decryptor still has to decrypt the body in the end; defence rests exactly on this point — emulation.

Demo 01 — Signature, Polymorphism, Heuristic Analysis, Emulation¶

The capsule format (completely harmless, a toy format we invented ourselves):

KAPSUL/1
COZUCU: ALGO=xs32 TOHUM=1a2b3c4d UZUNLUK=3782 COZ
<3782 bayt karıştırılmış gövde...>

The sample generator writes six files: a captured sample (ornek_a.bin), a copy of it that differs by a single byte, and three "polymorphic" copies of the same body with different keys/decryptors. Now let's try each method in turn:

Compile and run it (.\build.ps1 or ./build.sh inside code/, then in the demo folder):

cd code\week-02\01-imza-tarayici ; .\demo.ps1

cd code/week-02/01-imza-tarayici && sh demo.sh

Step 2 — Hash signature. Compares the file's SHA-256 digest against a digest in the database.

ADIM 2 — Hash (ozet) imzasi: birebir ayni dosyayi yakalar
  temiz.txt          TEMIZ      sha256=ce1f848e3795ae86...
  ornek_a.bin        YAKALANDI  Ornek.MaviKedi.A
  ornek_a_1bayt.bin  TEMIZ      sha256=a4220c8a0a41a9ff...
   ^ Tek bir bayt degisince ozet bambaska: hash imzasi atlatildi.

A hash signature is exact but brittle: when a single byte changes, the digest changes completely (the avalanche effect). That is why an attacker can evade a hash signature just by appending one meaningless byte to the file.

Step 3 — Pattern (byte-sequence) signature. Checks whether a known byte sequence occurs inside the file.

ADIM 3 — Desen (bayt dizisi) imzasi: kucuk degisikliklere dayanikli
  ornek_a.bin        YAKALANDI  Ornek.MaviKedi.A
  ornek_a_1bayt.bin  YAKALANDI  Ornek.MaviKedi.A
  poli_1.bin         YAKALANDI  Ornek.Cozucu.xs32
  poli_2.bin         YAKALANDI  Ornek.Cozucu.xs32
  poli_3.bin         TEMIZ
   ^ poli_1 ve poli_2 cozucu deseniyle yakalandi; cozucusu
     degisen poli_3 hic yakalanamadi.

A pattern signature is resistant to a single-byte change, and it catches poli_1/poli_2 by signing the decryptor code. But poli_3 (a different algorithm, a different instruction order), whose decryptor has also changed, cannot be caught at all — this is exactly polymorphism's power against signature-based detection.

Step 4 — Same body, different key. The first body bytes of the three polymorphic copies:

  poli_1.bin   ilk 16 govde bayti: 6f 57 bc 28 e2 81 dd 85 87 e1 f4 3d ...
  poli_2.bin   ilk 16 govde bayti: 83 b7 07 06 d8 38 3d 53 27 06 bc e8 ...
  poli_3.bin   ilk 16 govde bayti: bd 2c 85 32 f4 1f 3a 57 7f 6b 08 c0 ...

All three carry the same harmless body, but their bytes are completely different. Writing a signature for this is close to impossible.

Step 5 — Heuristic analysis. When there is no signature, it scores suspicious features: high entropy (+50), decryptor code that runs before the body (+30), meaningless "junk" instructions (+20).

  temiz.txt          TEMIZ      puan=  0 H=4.29
  ornek_a.bin        TEMIZ      puan=  0 H=4.71
  poli_1.bin         SUPHELI    puan= 80 H=7.95 entropi cozucu
  poli_3.bin         SUPHELI    puan=100 H=7.95 entropi cozucu cop-komut
  arsiv.bin          SUPHELI    puan= 50 H=7.88 entropi
   ^ arsiv.bin zararsiz yuksek-entropili dosya: YANLIS POZITIF.
     ornek_a.bin ise sezgisel olarak gozden kacti (yanlis negatif).

Heuristic analysis caught the polymorphic copies without a signature — but it made two mistakes: it flagged a harmless, high-entropy file (arsiv.bin) as suspicious (a false positive), and it missed the plain-bodied ornek_a.bin (a false negative). This is exactly the uncertainty Cohen was talking about.

Step 6 — Emulation. Runs the capsule's decryptor in a safe "virtual machine" (not real machine code, a toy language with 6 instructions), then scans the decrypted body again with the pattern:

  temiz.txt          TEMIZ      kapsul degil
  ornek_a.bin        YAKALANDI  Ornek.MaviKedi.A | cozucu yok (duz govde)
  poli_1.bin         YAKALANDI  Ornek.MaviKedi.A | 5 komut, 0 BOS, xs32
  poli_2.bin         YAKALANDI  Ornek.MaviKedi.A | 5 komut, 0 BOS, xs32
  poli_3.bin         YAKALANDI  Ornek.MaviKedi.A | 8 komut, 4 BOS, lcg8
  arsiv.bin          TEMIZ      kapsul degil

Emulation caught all of them: once the body was decrypted, all three polymorphic copies reduced to the same signature. Real antivirus products also "run" a suspicious file in an isolated virtual environment and scan its decrypted form. This is powerful but expensive, and if the malware detects it (anti-emulation), it can hide.

6. Countermeasures: How Do We Catch It?¶

We saw four methods in the demo above. Let's now pull the whole family of countermeasures together:

Modern endpoint protection (EDR/XDR) combines all of these and gives particular weight to behaviour. For example, "a process that reads hundreds of files in a short time and writes them back in a high-entropy form" is nearly certain evidence of ransomware — from behaviour alone, without looking inside the files.

Demo 02 — Entropy Meter: How Is Encrypted/Packed Content Recognised?¶

Here, \(p(b)\) is the probability of byte b occurring in the file. Plain text uses a small number of characters frequently (low H); encrypted/compressed data uses all bytes equally (H ≈ 8).

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

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

Sample files are generated the same way on both platforms (no external tool required): uniform, plain text, synthetic machine-code-like data, AES-256-GCM-encrypted, and random files.

ADIM 1 — Farkli turde dosyalarin entropisi (0 = tekduze, 8 = rastgele)
  tekduze.txt      4096  0.00 |........................| tekduze
  belge.txt        3360  4.17 |#############...........| dusuk
  kod.bin          2048  6.23 |###################.....| orta
  sifreli.bin      3376  7.95 |########################| YUKSEK
  rastgele.bin     4096  7.95 |########################| YUKSEK

ADIM 2 — Ayni icerik uc halde: duz -> makine-kodu-benzeri -> sifreli
  belge.txt        3360  4.17 |#############...........| dusuk
  kod.bin          2048  6.23 |###################.....| orta
  sifreli.bin      3376  7.95 |########################| YUKSEK
   ^ Sifreli ve rastgele veri entropiye bakarak AYIRT EDILEMEZ.

Two important conclusions: (1) Entropy alone does not answer the question "is it malicious?" — encrypted, compressed, and random data are all close to 8; so are a .zip or a .png. Plain text comes out low (~4), compiled machine code medium (~6). (2) But high entropy in an unexpected place is a clue. Step 3 shows this: an encrypted section hidden in the middle of a text shows up as a "hot region" in a windowed scan — the same "small unpacking stub + high-entropy body" pattern that is typical of packed programs.

    1024-  1535  4.14 |#################...............| dusuk
    1536-  2047  7.56 |##############################..| YUKSEK   <-- gizli bölge
    2048-  2559  7.66 |###############################.| YUKSEK
    3072-  3583  4.17 |#################...............| dusuk

Demo 07 — Rule-Based Detection: A Small Rule Engine¶

An advanced form of signature-based detection is to use a rule instead of a single byte sequence. The most common tool for this in the industry is YARA: a rule defines a few strings (text, or a hexadecimal pattern with wildcards) and a condition over those strings. Demo 07 shows this idea with a small engine written from scratch, using only harmless patterns we made up ourselves.

kural Kelime_Baglam {
  dizge $a = "indir"
  dizge $b = "calistir"
  dizge $sihir = "KAPSUL/1"
  kosul ($a and $b) and $sihir
}

cd code\week-02\07-kural-motoru
.\demo.ps1

cd code/week-02/07-kural-motoru
sh demo.sh

ADIM 2 — Bes dosyayi bes kuralla tara
  temiz.txt     (eslesme yok)
  kilavuz.txt   Kelime_Cifti
  kapsul.bin    Kapsul_Bicimi, Isaret_Hex, Kelime_Cifti, Kelime_Baglam
  varyant.bin   Isaret_Hex
  notlar.txt    Cok_Tekrar

ADIM 3 — Yanlis pozitif: zararsiz kilavuz neden eslesti?
    Kelime_Cifti           $a=1 $b=1 -> ESLESTI
    Kelime_Baglam          $a=1 $b=1 $sihir=0 -> -
   ^ Kelime_Cifti kelimelere bakti, BAGLAMA bakmadi: YANLIS POZITIF.

ADIM 4 — Degistirilmis varyant: joker (??) ne kazandirdi?
    Kapsul_Bicimi          $sihir=1 $coz=0 -> -
    Isaret_Hex             $h=1 -> ESLESTI

ADIM 5 — Kural dosyasi da girdidir: bozuk dosya reddedilir
satir 4: metin bos, uzun ya da kapanmamis
kural dosyasi REDDEDILDI (hatali ya da eksik)

Four lessons from this demo:

1. A narrow rule misses, a broad rule raises false alarms. Kelime_Cifti also caught a harmless guide because it only looked at two words (a false positive). Kelime_Baglam, which combines the same words with context ($sihir), did not make this mistake. Writing a rule means balancing precision against coverage.
2. A wildcard tolerates the changing part. varyant.bin evaded the Kapsul_Bicimi rule because it broke the familiar structure; but the hexadecimal pattern that skips the variable bytes with ?? still caught it. When writing a rule against polymorphism, you need to target the skeleton that does not change.
3. A rule engine is also a parser. The rule file comes from the outside; if the engine accepted a malformed file, the detection tool itself would become an attack surface. The demo catches the faulty line and rejects the file entirely (default deny). Parsing bugs in security tools have been exploited many times in the real world.
4. A rule catches what is known. There is no rule for a never-before-seen piece of malware; that is why rule-based detection is used together with heuristic and behaviour-based methods.

Demo 08 — Integrity Monitoring: Whitelist Logic¶

A blacklist says "recognise the bad"; a whitelist says "recognise the good, and be suspicious of everything else." Integrity monitoring is the file-level form of this: while the system is in a known-good state, every file's cryptographic digest is written into a manifest; it is then recomputed and compared regularly. Tools like Tripwire, application whitelists (AppLocker/WDAC on Windows), and operating systems' code-signing checks all rest on the same idea.

cd code\week-02\08-butunluk-izleme
.\demo.ps1

cd code/week-02/08-butunluk-izleme
sh demo.sh

ADIM 4 — Benzetim: bir 'saldirgan' dosyalara dokunur
  TAMAM    ayar.conf        fa747caed81475dc...
  DEGISTI  kutuphane.bin    c603d7c61459... -> 64b8f2b2c00e... (49->65 B)
  SILINDI  veri.txt         (manifestte var, klasorde yok)
  YENI     gizli.bin        6eb16b9b1e293479... (taban cizgisinde yok)
  SONUC: 3 sapma bulundu -> incele!

ADIM 5 — Saldirgan izini ortmek icin manifesti de yeniden yazar
  TAMAM    gizli.bin        6eb16b9b1e293479...
  TAMAM    kutuphane.bin    64b8f2b2c00effa2...
  SONUC: butunluk korunmus (4 dosya)
   ^ Manifest korunmazsa izleyici KANDIRILIR: hepsi TAMAM gorunuyor.

ADIM 6 — Ama muhur (HMAC) anahtarsiz yeniden uretilemez
  MUHUR GECERSIZ: manifest anahtarsiz biri tarafindan
  degistirilmis -> manifeste GUVENME

The demo's real lesson is in steps 5 and 6: the digest catches a change, but the expected values must also be protected. If someone who can modify the files can also modify the manifest, the monitor says "everything is fine." The fix is to seal the manifest with a keyed digest (HMAC) or a digital signature and not keep the key in the same place as the monitored files. The comparison is also done in constant time; otherwise a timing difference could leak how many bytes matched.

7. Incident Case Studies: Which Programming Error, Which Countermeasure?¶

Almost every major epidemic in history was built on a programming or configuration error. In the table below we read each incident not by what the malware did, but by how it got in; because this course's subject is closing that entry point.

Reading the table from top to bottom, a trend appears: most epidemics between 1988 and 2008 spread through a single buffer overflow. After 2017, the entry point increasingly shifted to update and build processes: instead of breaking the code, the attacker seized the path by which the code reaches the user. This course's two ends come from exactly this: on one side, bounds checking and safe memory management (Weeks 1 and 4); on the other, signed updates, integrity verification, and supply-chain security (Weeks 3, 5, and 10).

8. Attack Trees¶

We drew an attack tree last week; this week we will put it into numbers. The root is the attacker's goal; the branches are the ways to reach it. At an OR node, one branch is enough; at an AND node, all of them are required. If we write a cost (person-days, equipment, expertise) on every leaf, we can solve the tree bottom-up and find the cheapest attack:

• OR node: the cheapest of the children (whichever suits the attacker).
• AND node: the sum of the children (since all are required).

Demo 04 — Attack Tree Cost Calculator¶

Windows: cd code\week-02\04-saldiri-agaci ; .\demo.ps1 · WSL/Linux: cd code/week-02/04-saldiri-agaci && sh demo.sh (build once inside code/ first).

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

  CHEAPEST ATTACK = 2 units. ... the weakest point:
  -> Read it from memory at the moment of use -> Read from memory with a debugger

The cheapest path is 2 units: reading the key from memory. The second tree shows what happens when RASP (debugger and hook detection — Week 6) is added to this branch:

  [OR] Capture the payment key  (cost=8)
    [OR] Read it from memory at the moment of use [one is enough]  (cost=8)
      Memory dump (defeat the random erasure)  (cost=8)
  CHEAPEST ATTACK = 8 units.

The defence raised the cheapest attack from 2 to 8; the weakest point changed. This is how you justify a security investment with a number: "this countermeasure makes the cheapest attack 4 times more expensive." AND nodes force the attacker to break multiple layers together — the quantitative counterpart of defence in depth.

9. Security Audit Logging: The Log as Evidence¶

The attack tree asks "where does the attacker come from?"; the audit log answers "did they get in, and what did they do?" A reliable record is the only way to understand what happened after an incident, find who is responsible, and prevent it from happening again. The book covers this topic in Recipe 13.11; the recommendations there still hold today, only the tools have been updated.

What Is Logged, and What Should Never Be Logged?¶

Logging is designed assuming that an attacker might also read it. Every secret written to the log has, in effect, been handed to anyone who can access the log file. This is why one of the instructor's methods is to remove debug logging from the code entirely in a release build: logging code that is merely silenced with a disabled flag still remains in the binary, leaking information through its strings and remaining re-enablable.

Demo 10 — Log Injection (CWE-117)¶

A log line very often contains a field that comes from the user: a username, a filename, a request path. If this field contains a line break (\n, \r) or a terminal control character (an ESC sequence), an attacker can make the log print an event that never happened, or hide a real line on screen.

cd code\week-02\10-gunluk-enjeksiyonu
.\demo.ps1

cd code/week-02/10-gunluk-enjeksiyonu
sh demo.sh

ADIM 1 - GUVENSIZ gunluk: alan denetlenmeden yaziliyor
  DENETIM giris kullanici=ayse sonuc=BASARISIZ
  DENETIM giris kullanici=kayra
  DENETIM giris kullanici=admin sonuc=BASARILI sonuc=BASARISIZ
  DENETIM giris kullanici=deniz^[[2K^Mgizli sonuc=BASARISIZ
ADIM 2 - Sahte satiri say:
  Gunluk: 4 satir; sahte 'admin BASARILI' satiri: 1
ADIM 3 - GUVENLI gunluk: kacislama + sinir + sabit bicim dizgesi
  DENETIM giris kullanici=kayra\x0A2026-... kullanici=admin ...
  DENETIM giris kullanici=deniz\x1B[2K\x0Dgizli sonuc=BASARISIZ
  DENETIM giris kullanici=AAAAAAAAAAAAAAAA... sonuc=BASARISIZ
ADIM 4 - Sahte satiri say (guvenli):
  Gunluk: 4 satir; sahte 'admin BASARILI' satiri: 0

In the unsafe version, three inputs produced four lines: a line break hidden inside the name kayra added an administrator login that never happened to the log. An administrator or an automated alerting system reading this log reacts to a fake event; the real attack, meanwhile, gets lost in the noise. The safe version does three things:

1. Escaping: every unprintable byte (\n, \r, ESC) is written in \xNN form; every input stays on a single line.
2. Bounding: the field is truncated at a fixed length (...); the log file cannot be inflated with a single input.
3. A fixed format string: the field is never passed as the format string of printf/syslog. The mistake syslog(LOG_INFO, kullanici_girdisi) that the book warns about in Recipe 13.11 is a format string vulnerability (CWE-134; covered in detail in Week 4): the correct form is syslog(LOG_INFO, "%s", kullanici_girdisi).

Tamper-Resistant Logging¶

Preventing injection ensures the log is written correctly; but it does not stop an attacker who has breached the system from changing it afterwards to cover their tracks. The log does not need to be unmodifiable; it is enough that a modification is noticed. There are two classic ways to do this:

• Digest chain: every record contains the digest of the previous record. Changing a record in the middle breaks the chain of every record after it. However, an attacker can recompute the whole chain from scratch; there is no key.
• HMAC chain and key evolution: every record is sealed with a keyed digest; moreover, the key evolves through a one-way function after every record, and the old key is deleted (Schneier–Kelsey, 1999). The instant an attacker seizes the machine, they only find the current key; they cannot go backward from it to the keys that sealed earlier records. This protects the records that predate the breach (forward security).

The verifier keeps the initial key in a separate, secure (offline) place, and validates every record by recomputing the chain from the start.

Demo 11 — Tamper-Resistant Logging: HMAC Chain and Key Evolution¶

cd code\week-02\11-kurcalamaya-dayanikli-gunluk
.\demo.ps1

cd code/week-02/11-kurcalamaya-dayanikli-gunluk
sh demo.sh

ADIM 2 - Saglam gunlugu dogrula (evrim):
  #1 seq=1 "cuzdan acildi"  MAC:OK
  ...
  >>> SONUC: gunluk BUTUNLUKLU (tum kayitlar dogrulandi).
ADIM 3 - Ham kurcalama: seq=4 mesajini degistir (MAC eski)
  #4 seq=4 "odeme onaylandi tutar=9999"  MAC:BOZUK
  >>> SONUC: gunluk KURCALANMIS (dogrulama basarisiz).
ADIM 4 - Kayit SILME: seq=5 silinir
  #5 seq=6 "oturum kapandi"  MAC:BOZUK  SIRA:BOZUK

When a record is modified, the MAC no longer matches; when a record is deleted, both the MAC and the sequence number break. The demo's final steps show the real difference: when the attacker tries to rewrite the log with the key found on the machine, in the static-key log they can reseal the whole history and fool the verifier; in the evolving-key log, they can only touch the records after the moment of capture, because the earlier keys no longer exist anywhere.

10. Access Control: Who Can Do What, to What?¶

We now move to the defence side. One of security's most fundamental questions is: "Can this subject perform this operation on this object?" We organise this with three concepts:

• Subject: the one performing the operation (a user, a process).
• Object: the thing the operation is performed on (a file, a record, memory).
• Right/permission: the operation that can be performed (read, write, execute).

The Access Control Matrix¶

The most general model is a matrix where rows are subjects, columns are objects, and every cell holds the permissions:

This matrix is conceptual; in reality it is stored in two forms:

• Access control list (ACL): the matrix is stored column by column — every object keeps a list of "who can access me." Unix file permissions and the Windows DACL work this way.
• Capability: the matrix is stored row by row — every subject keeps tickets for "what can I access."

DAC, MAC, RBAC¶

Real systems use these together: DAC provides the owner's wishes, MAC the system's mandatory boundary, and RBAC administrative convenience. The effective decision is usually the intersection of all of them ("both the owner must permit it and the system policy must permit it").

Demo 03 — Access Matrix and Model Simulator (together with Section 11)¶

We will run this demo together with the formal models in the next section; but its first step is the DAC matrix alone:

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

ADIM 0 — Salt DAC (erisim denetim matrisi): karar sahibin izninde
  kutuphane(D   ) OKU odeme_anahtari(D   )  DAC:VAR ...  => IZIN
  uygulama(D   ) OKU odeme_anahtari(D   )  DAC:yok ...  => RED
  saldirgan(D   ) OKU odeme_anahtari(D   )  DAC:yok ...  => RED
   ^ uygulama OKU odeme_anahtari: matriste yok -> RED (en az ayricalik)

No subject that has no right in the matrix can access it — a direct application of the principle of least privilege. Not even the application has direct access to the payment key; only the security library can access it.

11. Formal Security Models¶

DAC says "whatever the owner says goes"; but this cannot prevent a leak systemically. For example, a program that can read a confidential document can write that information to a publicly readable file — DAC does not prevent this. Mandatory (MAC) models close exactly this gap. We will look at three classic models.

Bell–LaPadula (BLP) — Confidentiality¶

Designed in 1973 for military secrecy. Objects and subjects are given confidentiality levels (Unclassified < Confidential < Top Secret). Two rules:

• The simple security property ("no read up"): a subject cannot read an object more confidential than its own level. (A clerk cannot see a top-secret document.)
• The star (*) property ("no write down"): a subject cannot write to an object less confidential than its own level. (A general cannot write top-secret information into an unclassified document and leak it.)

In short, BLP says "read down, write up": read what is below, write above. Its purpose is to protect confidentiality.

Biba — Integrity¶

In 1977, Biba inverted BLP. This time the levels are trustworthiness/integrity levels (External < Application < Kernel). The rules are symmetric:

• "No read down": a subject cannot read an object less trustworthy than itself. (Business logic does not directly trust unvalidated external input.)
• "No write up": a subject cannot write to an object more trustworthy than itself. (A component that receives data from the network cannot corrupt a signed configuration.)

So Biba says "read up, write down" and protects integrity: dirty data cannot corrupt clean data.

Clark–Wilson — Commercial Integrity¶

In 1987, Clark and Wilson proposed a different integrity model for commercial systems such as banks. Instead of military levels, it is built on well-formed transactions and separation of duties:

• Constrained data items (CDI): data whose integrity must be preserved (an account balance).
• Transformation procedures (TP): only approved, well-formed transactions may change a CDI (no direct writes). For example, a balance can only change through a "deposit/withdraw" procedure.
• Integrity verification procedures (IVP): regularly check that the data is consistent ("debits = credits").
• Separation of duty: the person who initiates a transaction and the person who approves it are different people.

The spirit of Clark–Wilson transfers directly into today's software: touch data only through verified transactions, never directly; do not tie a critical step to a single person or a single path. It is the formal form of last week's "separation of privileges" principle.

Demo 03 — Compare the Models¶

  memur  (Gene) OKU operasyon(CokG)  DAC:VAR BLP:RED ...  => RED
  general(CokG) YAZ ilan     (Gene)  DAC:VAR BLP:RED ...  => RED
   ^ memur OKU operasyon: yukari okuma -> RED (gizli bilgiyi goremez)
     general YAZ ilan: asagi yazma -> RED (sizinti onlenir)

  aglayici(Dis ) YAZ kayit    (Uygu)  ... BIBA:RED  => RED
  islemci(Uygu) OKU gelen    (Dis )  ... BIBA:RED  => RED
   ^ aglayici YAZ kayit: yukari yazma -> RED (kirli veri temizi bozmasin)
     islemci OKU gelen: asagi okuma -> RED (guvenilmez girdiye guvenme)

Notice: DAC is VAR (the owner has granted permission) in both cases; it is the system that brings the mandatory model into play. Because the effective decision is DAC AND MAC, the model can still deny access even when the owner permits it. You can open the policy files (politika-gizlilik.txt, politika-butunluk.txt) and write your own rules.

12. Unix and Windows Access Control Models¶

These classic models did not stay on paper; the permission architecture of operating systems is their practical form.

The Unix Model (Recipe 2.1)¶

Unix implements DAC with user/group identities and permission bits. Every process has three identities: effective (used in permission checks), real (the actual owner), and saved (for temporarily dropping and later reclaiming privilege). Every file has three groups of permission bits — owner, group, others — each with read/write/execute:

In addition there are the setuid/setgid bits (the program runs with the authority of its owner) and the sticky bit (prevents deleting someone else's file in a shared directory like /tmp). A setuid root program runs with root authority no matter who runs it — powerful but dangerous; this is exactly why last week's "least privilege" is critical.

The Windows Model (Recipe 2.2)¶

Windows uses a more detailed ACL model. Every object (file, registry key, mutex) has a security descriptor. There are two lists:

• DACL (Discretionary ACL): holds the access rules — who can do what. It contains a series of ACEs (access control entries); each ACE is a SID (a user/group identity), a right, and an "allow / deny" flag.
• SACL (System ACL): holds the audit rules — which accesses get logged.

An important trap: a NULL DACL (a list with no entries at all) means "full rights for everyone" — never a good idea. Windows picks the best-matching ACE; "deny" entries are generally evaluated before "allow" ones.

Modern Windows also adds mandatory boundaries similar to Biba with integrity levels (Mandatory Integrity Control) and AppContainer — so formal models are still alive in practice.

Demo 06 — TOCTOU Race Condition¶

WSL / Linux (this demo only runs here): cd code/week-02/06-toctou && sh demo.sh (run ./build.sh inside code/ first). On Windows, .\demo.ps1 prints how to run it in WSL.

ADIM 1 — GUVENSIZ surum: once denetle, sonra ac (yaris acigi)
  guvensiz: 'SAHTE-KAYIT-...' -> calisma/gunluk.txt (yazildi)
  --- Sonuc: gizli_hedef.txt icerigi ---
    iceride onemli veri var
    SAHTE-KAYIT-tarafimizca-eklendi
  >>> SALDIRI BASARILI: yaziyi baska dosyaya yonlendirdik!

ADIM 2 — GUVENLI surum: O_NOFOLLOW ile tek adimda ac
  reddedildi: hedef sembolik bag (O_NOFOLLOW)
  >>> Saldiri engellendi: gizli_hedef.txt bozulmadi.

Demo 12 — Windows Access Control Algorithm: How Are ACEs Evaluated?¶

Windows evaluates a request to access an object by comparing the SIDs (users and groups) in the requesting process's access token against the ACEs in the object's DACL, in order (Recipe 2.2). The rule is simple, but the outcomes are surprising:

1. ACEs are examined in list order; an ACE belonging to a SID not in the token is skipped.
2. If a DENY ACE matching one of the requested rights is found, the request is denied immediately.
3. ALLOW ACEs accumulate the requested rights; once all are granted, the request is accepted.
4. If the list ends and rights are still missing, the request is denied (default deny).
5. Canonical order: explicit DENY → explicit ALLOW → inherited DENY → inherited ALLOW. Windows' own tools write ACEs in this order; an order broken by hand or by faulty code can cause a DENY to never be read at all.
6. A NULL DACL (no DACL at all) grants every right to everyone; an empty DACL (no ACEs) grants no right to anyone. The object's owner, however, can read and change permissions no matter what the DACL says.

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

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

== SENARYO: 1a - kitaptaki DACL, ayse Pazarlama uyesi ==
    1. RET  Herkes         TAM
    2. IZIN Pazarlama      YAZ
    3. IZIN Herkes         OKU
  Istek YAZ:
    ACE 1 RET  Herkes        -> eslesti; YAZ reddedildi
  => RED  (ACE 1: sonraki ACE'lere bakilmaz)
== SENARYO: 1b - ayni ACE'ler, IZIN once (kanonik degil) ==
    ACE 1 IZIN Pazarlama     -> verildi YAZ (eksik: -)
  => IZIN  (tum istenen haklar verildi)
== SENARYO: 2a - NULL DACL, istegi yapan yabanci bir hesap ==
  => IZIN  (TEHLIKE: SAHIP_AL ve IZIN_YAZ dahil!)
== SENARYO: 2b - BOS DACL, ayni yabanci hesap ==
  => RED  (eksik: OKU)
== SENARYO: 3b - kalitim kesildi (sil) ==
  => RED  (liste bitti; eksik: OKU)

In the first two scenarios the ACEs are identical, only their order differs: in canonical order ayse is denied, in the broken order the same request is accepted. The second step shows one of the most common mistakes programmers make: creating an object's security descriptor with a NULL DACL so that "everyone can access it" grants everyone not just read, but also the right to take ownership and change permissions. The correct approach is to write a DACL that explicitly grants the rights that are needed. The third step shows inheritance: explicit ACEs are evaluated before inherited ACEs; cutting inheritance and deleting the inherited ACEs can lead to an unexpected default deny.

Demo 13 — Unix Permissions, umask, and setuid Traps¶

Three subtleties of the Unix model (Recipe 2.1) explain most real-world bugs:

• The first matching class decides. The kernel first asks "is the requester the file's owner?"; if so, only the owner bits apply, and the group and other bits are never even looked at. If not the owner but a group member, only the group bits are used; if neither, the other bits are used.
• umask narrows a new file's permissions: actual permission = requested & ~umask. fopen() always requests 0666; if umask is 000, the file becomes writable by everyone. A sensitive file should be opened with open(..., 0600) (Recipe 2.7, Week 1).
• A setuid program runs with the authority of the file's owner, not the person running it. A program that does not know the distinction between real, effective, and saved user IDs can think it has "dropped" its privilege while leaving it recoverable through the saved identity (Recipe 1.3).

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

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

A) Cekirdek izin denetimi: ilk eslesen sinif karar verir
  surec   istek dosya         sahip:grup     izinler     sinif -> karar
  mehmet  yaz   rapor.txt     ayse:muhasebe  rw-r-----   grup -> RED
  ayse    oku   paradoks.txt  ayse:muhasebe  ---rwxrwx   sahip -> RED
  zeynep  oku   paradoks.txt  ayse:muhasebe  ---rwxrwx   diger -> IZIN
   ^ ayse paradoks.txt'yi OKUYAMAZ: sahip sinifi secildi ve
     sahip bitleri '---'; grup/diger bitlerine hic bakilmaz.
B) umask: gercek izin = istenen & ~umask (Tarif 2.7)
  istenen   umask 000    umask 022    umask 077
  0666      rw-rw-rw-    rw-r--r--    rw-------
C) setuid benzetimi: sahibi root olan setuid bir programi
   ayse (uid 1001) calistiriyor. exec: etkin=sakli=0 olur.
    seteuid(1001)                  r/e/s=1001/1001/0 g=1001 tamam

The paradoks.txt example runs against intuition: ayse, the file's owner, cannot read it, yet zeynep, who has no relation to it at all, can. The authentication logic of "first look at who you are, then apply only that class's rule" requires thinking through each class separately when writing permissions. The setuid step shows that a temporary drop done with seteuid() leaves the saved identity at 0, meaning the privilege can be reclaimed; a permanent drop requires changing all three identities with setresuid() and verifying the result.

Demo 14 — RBAC, Separation of Duty, and Clark–Wilson¶

The Clark–Wilson model's two core ideas are the well-formed transaction (only certified transactions may touch data) and separation of duty (whoever initiates a task cannot approve it). RBAC, meanwhile, grants authority to roles rather than to people; static separation of duty (SSD) forbids assigning one person to two conflicting roles, and dynamic separation of duty (DSD) forbids activating both of them at once in the same session.

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

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

== 1 - RBAC: rol atama ve gorev ayriligi (SSD/DSD) ==
[01] ATA cem GISE
     SSD(GISE,ONAYCI): cem ikisini birden tasiyamaz -> RED
[04] OTURUM deniz GISE,DENETCI
     DSD(GISE,DENETCI): ayni oturumda ikisi birden etkin olamaz -> RED
[05] OTURUM deniz DENETCI
     oturum acildi; etkin: DENETCI
== 2 - Clark-Wilson: CDI'ya yalniz sertifikali TP dokunur ==
== 3 - Gorev ayriligi: buyuk havaleye ikinci kisi onayi ==
[20] deniz IVP
     IVP defterden beklenen toplam 20250, bulunan 20250
== 4 - Hatali bir TP sertifikalanirsa IVP yakalar ==

The fourth step is the model's most instructive part: if the certifier certifies a faulty transaction, the enforcement rules (E1–E4) cannot notice it, because the transaction looks "authorised." What catches the error is the independently running IVP: the totals do not match the ledger. Lesson for the programmer: authority checking alone is not enough; you also need a mechanism that separately verifies the consistency of the data.

13. Classifying Software Security Vulnerabilities: CWE¶

When you find a vulnerability, you must name it so that others understand it, it is not rediscovered from scratch, and a countermeasure can be taken. The first tool is CWE (Common Weakness Enumeration): a numbered catalogue of weakness types, maintained by MITRE. If a CVE is a specific flaw in a specific product, CWE is its type.

The CWE Top 25 is the list of the 25 most common and most dangerous weaknesses of the year; it is computed from real CVE data by combining frequency and severity. It is a good first answer to a security programme's question "what should I look at first?" Out-of-bounds write (CWE-787), XSS (CWE-79), and SQL injection (CWE-89) have topped the list for years.

14. OWASP Top 10 and MASVS¶

CWE catalogues all weaknesses; OWASP, on the other hand, turns these into priority lists and verification standards for specific domains.

• OWASP Top 10: the ten most critical risk categories in web applications (e.g. broken access control, cryptographic failures, injection, insecure design). It is an awareness and prioritisation document; each item covers many CWEs.
• OWASP ASVS (Application Security Verification Standard): a detailed, levelled checklist for the web, answering the question "which checks must be passed to be considered secure?"
• OWASP MASVS (Mobile Application Security Verification Standard): the mobile counterpart of the same idea. Since this course focuses heavily on mobile protection, MASVS is especially important for us. Its categories (briefly): STORAGE, CRYPTO, AUTH (authentication), NETWORK, PLATFORM, CODE (code quality), and RESILIENCE (protection against reverse engineering and tampering). The test guide that accompanies MASVS is MASTG.

15. CVE and CVSS: Which Flaw, How Severe?¶

• CVE (Common Vulnerabilities and Exposures): the unique identifier of a specific flaw in a specific product, e.g. CVE-2014-0160 (Heartbleed). A CVE is a name, not a severity. A CVE belongs to one or more CWE types.
• CVSS (Common Vulnerability Scoring System): a system that turns a flaw's severity into a number between 0.0 and 10.0. It is maintained by FIRST. There are three groups of metrics: Base (the flaw's own properties, unchanging), Temporal (does exploit code exist, has a patch been released), Environmental (how important it is in your environment). In this course we will focus on the Base score.

CVSS v3.1's eight Base score metrics:

Demo 05 — CVSS v3.1 Base Score Calculator¶

Windows: cd code\week-02\05-cvss ; .\demo.ps1 · WSL/Linux: cd code/week-02/05-cvss && sh demo.sh. By hand: python3 cvss.py --ornekler (on Windows py -3 cvss.py --ornekler).

  1) Uzaktan, kimlik gerektirmeyen tam ele gecirme
  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    TEMEL PUAN = 9.8  |####################|  Kritik (Critical)

  2) Ayni ama KAPSAM degisti (kutu disina cikan etki) -> daha yuksek
  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    TEMEL PUAN = 10.0  |####################|  Kritik (Critical)

  4) Yerel yetki yukseltme (cihaz saldirganin elinde) -> yuksek
  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
    TEMEL PUAN = 7.8  |################....|  Yuksek (High)

Even with the same impact (C:H/I:H/A:H), a remote + unauthenticated flaw (9.8) scores higher than a local + privileged one (7.8); when the scope changes it goes up to 10.0. We convert scores into severity bands:

16. The Vulnerability Lifecycle and Responsible Disclosure¶

A flaw goes through a lifecycle from the moment it is discovered to the moment it is made public. How this cycle is managed determines how long users remain at risk.

Key concepts:

• Zero-day: a flaw the vendor does not yet know about, or for which there is no patch. The most dangerous situation, because there is no defence.
• Responsible disclosure (coordinated disclosure): the researcher reports the flaw to the vendor first, waits a reasonable period (usually 90 days) for a patch, then discloses it publicly. The goal is to protect users while also getting the vendor to act.
• Full disclosure: disclosing the flaw publicly right away. It pressures the vendor but puts users at risk; it is controversial.
• Bug bounty programmes: programmes in which companies reward researchers who responsibly report flaws. They encourage responsible disclosure.
• Patch gap: the moment a patch is released, the flaw becomes public; anyone can reverse-engineer the patch and learn the flaw. Users who do not update are vulnerable in this gap — WannaCry spread to machines that still had not updated after the patch had already come out.

17. Common Mistakes and Checklists¶

This week we covered four big topics together: malware and detection, attacker mindset and audit logging, access control models, and vulnerability classification and prioritisation. Below, for each cluster, you will find first the most common misconceptions, then a checklist you can use to test yourself. Every mistake item also includes a short answer to "why is this wrong?"; if you can explain every checklist item to a friend in your own words, you have learned that topic.

Malware and Detection¶

Attacker Mindset, Attack Trees, and Audit Logging¶

Access Control and Security Models¶

Vulnerability Classification and Prioritisation¶

18. Term Project: This Week (S4)¶

Last week you built the skeleton of your security guide's S4 — Threat model and attacker model section: you derived threats with STRIDE and wrote a rough attack table. This week you turn that table into something an assessor can read: every row will be named in a common language (CWE), measured (CVSS), and for your most critical asset the cheapest attack path will be shown with an attack tree.

Step-by-Step Method¶

1. Write the attacker models. Define the attacker before the threat; otherwise you will score the same threat with different assumptions on different rows. In this course's context there should be at least these three: a remote attacker, a malicious application on the same device, and the device owner (white-box) attacker.
2. Derive threats from the interfaces. For every row of your S3 interface table (client–server, application–library, library–local database...) ask STRIDE's six letters. Every S5 asset must appear in at least one threat; if it doesn't, either the asset is unnecessary or the table is incomplete.
3. Map to CWE. Name the threat's root cause (the weakness), not its consequence. "The key is stolen" is a consequence; the root cause might be "the key is hardcoded into the code" (CWE-321/CWE-798) or "the key stays exposed in memory" (CWE-316). Check the entry's "Mapping" note on cwe.mitre.org: some high-level entries are not recommended for mapping.
4. Build the CVSS vector according to the attacker model. The same weakness gives AV:N for a remote attacker and AV:L/PR:H for the device owner. Write which model you assumed in the column. Compute the score with Demo 05 or FIRST's calculator, and write the vector in full so the assessor can reproduce it.
5. Link the countermeasure and the section. Every threat's countermeasure is described in another section of the guide (S5, S7, S9, S10, S11, S12). The section column is also the basis of the S17 compliance matrix.
6. Justify the priority. Do not order priority by score alone; the cheapest path in the attack tree and the asset's value decide it together. Write the justification as a paragraph.

A Fully Filled-In Synthetic Example¶

The example below is written for the course's common example architecture, "a mobile payment application + a security library." The application manages the user interface, communication with the server, and the local database. The security library (native C) carries session keys, one-time payment key counters, and integrity/RASP checks. All values are made up; they exist to show the table format and the way of thinking.

S4.1 — Attacker Models

S4.2 — Threat Table (with CWE and CVSS v3.1 added)

All vectors are read with the CVSS:3.1/ prefix; the scores were computed with Demo 05.

S4.3 — Priority and Justification (example paragraph)

By base score, the order is T9 (8.8) → T3 (7.4) → T2/T7 (6.5). However, the attack tree (S4.4) for the "payment from someone else's account" goal shows the cheapest path is T7 (3 units), followed by T3 (6 units). Exploiting T9 requires high expertise (9 units in the tree). Therefore the priority order was set as T7 → T3 → T9 → T1. T1 and T4's low scores come from the fact that, in our attacker model (SM4), root is already in the attacker's hands; these two threats will be addressed together with the RASP and secure-erasure countermeasures in the midterm submission.

Attack Tree (Example)¶

Root goal: "Make a payment from someone else's account." Leaf costs are sample person-day effort. The T numbers in parentheses are the leaf's row in the threat table.

The same tree in Demo 04's input format (agac-s4.txt):

TARGET: Make a payment 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 the local DB and decrypt it   cost=8
      LEAF Code via a malicious link (T9)     cost=9
    LEAF Bypass device binding                cost=6
  AND Intercept 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 Change the transaction number (T7)   cost=2

The end of the output we get when we run this through Demo 04's calculator:

  CHEAPEST ATTACK = 3 units. The chain the defender must break
  first (the weakest point):

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

When we applied the countermeasures in order, the cheapest path changed as follows (the same program, with leaf costs updated):

This table is S4's strongest piece of evidence: two countermeasures raised the cheapest attack from 3 to 10 and showed, with a number, where the next investment should go (the key in memory: RASP, secure erasure, device binding). Notice: T9, the most severe row by CVSS, is not the cheapest path for this goal — this is exactly why the two tools are read together.

Grading Criteria¶

S4 is the main part of the security analysis criterion in the midterm submission. The table below is used for grading.

19. Class Activities¶

Activities are not graded; they exist to reinforce the topics in class. Each one's duration, group setup, and expected output are given. Which activity is done in which class hour is in the "Course flow" plan; anything that does not fit is left for the student's own study.

20. Code Reading Exercises: Find the Vulnerability¶

Each of the code snippets below has a vulnerability. Find its type (CWE) and its fix; the answers are in the hidden box.

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

uint32_t beklenen = 0x1a2b3c4d;
uint32_t bulunan  = crc32(kod_bolgesi, boyut);
if (bulunan != beklenen)
    return HATA;   /* tampered */
calistir();

struct kullanici k;
strncpy(k.ad, girdi, sizeof k.ad);
/* k.yonetici field is never assigned */
if (k.yonetici) ver_yonetici_paneli();

21. Work on Your Own¶

Not graded; it exists to reinforce the lesson. All of it is done on code/week-02, only on your own computer.

22. Self-Check¶

23. Sample Quiz-1-Style Questions¶

Quiz-1 (Week 8) contains short-answer and code-reading questions of this kind. Try them; verify the answers against the sections above.

1. Split the following types into two groups, "requires user interaction / does not require it": virus, worm, trojan horse, macro virus.
2. Write the base score and band of the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. (Hint: a typical XSS. Verify with Demo 05.)
3. Which model satisfies a system's requirement "no one without authorisation should see the confidential document"? Write its two rules.
4. What is the flaw in the access() then open() pattern (with its CWE number), and what is its one-line fix?
5. Why does a signature-based scanner miss a polymorphic sample? Which method catches it?

24. Resources and Further Reading¶

Course textbook — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Recipe 2.1 (the Unix access control model), 2.2 (the Windows access control model)
• Recipe 2.3 (checking a user's access to a file; TOCTOU)
• Recipe 12.1 (the problem of software protection — attacker and defender using the same methods)
• Recipe 13.11 (audit logging — the SACL/syslog context)

Open sources (may be cited by name)

• F. Cohen, "Computer Viruses — Theory and Experiments", 1984 (the definition of a virus and the detection limit).
• D. E. Bell, L. J. LaPadula, security model reports, 1973 (the confidentiality model).
• K. J. Biba, "Integrity Considerations for Secure Computer Systems", 1977 (the integrity model).
• D. Clark, D. Wilson, "A Comparison of Commercial and Military Computer Security Policies", 1987.
• B. Schneier, "Attack Trees", 1999.
• MITRE CWE and CWE Top 25; MITRE CVE; FIRST's CVSS v3.1 and v4.0 documents.
• OWASP Top 10, ASVS, MASVS, and MASTG.
• Real incidents (for date verification): Brain (1986), the Morris worm (1988), ILOVEYOU (2000), Code Red (2001), Stuxnet (2010), WannaCry (2017), NotPetya (2017).