Allow, deny ve inheritance: Etkili erişim kararını anlamak.

1. Core Mechanism / Temel mekanizma

Bu ders erişim kararının nasıl üretildiğini işler: istenen access mask, ACE'lerin sıralı değerlendirmesi, allow/deny etkileşimi ve inheritance. 05.02 access check'in var/yok kararını (DACL var mı, hak var mı) tanıttı; 05.03 bir descriptor'ı alan alan okumayı öğretti. Burada odak, birden çok ACE bir arada olduğunda sonucun sıraya ve inheritance'a göre nasıl belirlendiğidir. NULL ve empty DACL uç durumları da burada netleşir. Access check algoritmasının kaynağı How AccessCheck Works; ACE sıralaması Order of ACEs in a DACL belgesidir; ikisi de yorumlanmaz, olduğu gibi öğretilir.

Arabirimler ve belirtimler

• Requested access mask: erişim isteğinin talep ettiği haklar kümesi (ör. FILE_READ_DATA + FILE_WRITE_DATA); access check bu maskeye göre yürütülür.
• Remaining rights: istenen haklardan henüz allow ACE'siyle karşılanmamış olanlar; değerlendirme ilerledikçe azalır, sıfıra inince erişim verilir.
• Sıralı değerlendirme: DACL'deki ACE'ler göründükleri sırada incelenir; karar ilk belirleyici eşleşmede (yeterli allow toplandı ya da istenen bir hakka deny geldi) kesinleşir.
• Canonical order: tercih edilen sıra — explicit ACE'ler inherited'lardan önce; her grupta access-denied ACE'ler access-allowed'lardan önce.
• Inheritance: bir ACE explicit (nesnede doğrudan tanımlı) veya inherited (üst nesneden gelen, ID bayraklı) olabilir; canonical sırada inherited ACE'ler explicit'lerden sonra gelir.
• NULL DACL: DACL'in hiç bulunmaması (SDDL: NO_ACCESS_CONTROL); herkese full access anlamına gelir.
• Empty DACL: DACL vardır ama sıfır ACE içerir (SDDL: D:); allow ACE’leri üzerinden istenen hakları vermez. AD DS’te current owner için READ_CONTROL ve WRITE_DAC gibi haklar ayrıca örtük olabilir; SE_TAKE_OWNERSHIP_PRIVILEGE WRITE_OWNER doğurabilir.

Erişim kararı bir birikimdir

Access check, istenen access mask'i tek bir hak gibi değil, bir talep listesi gibi ele alır. Nesnenin DACL'i yoksa (NULL DACL) erişim doğrudan verilir. DACL varsa, sistem ACE'leri göründükleri sırada inceler ve talep edilen hakları biriktirir: her access-allowed ACE, eşleştiği trustee için istenen haklardan bazılarını 'karşılanmış' işaretler.

Karar iki yoldan biriyle kesinleşir. Eğer bir access-denied ACE, hâlâ karşılanmamış (remaining) istenen bir hakla eşleşen bir trustee için gelirse, erişim o noktada reddedilir. Eğer değerlendirme, istenen tüm hakları karşılayacak kadar allow topladıysa erişim verilir. İkisi de olmadan liste biterse, kalan istenen haklar için allow bulunamadığından erişim implicit olarak reddedilir. Kritik nokta: karar ilk belirleyici eşleşmede durur, bu yüzden ACE'lerin sırası sonucu belirleyebilir.

Aynı ACE'ler, farklı sıra, farklı sonuç

İki ACE düşünün: aynı gruba önce bir access-denied (write) ve bir access-allowed (full). Canonical sırada deny allow'dan önce yazılır: bir write isteğinde sistem önce deny'i görür, istenen write hakkıyla eşleşir ve erişimi reddeder. Bu, 'explicit deny explicit allow'u yener' sezgisinin mekanizma karşılığıdır — ama bu sezgi yalnız canonical sıra korunduğunda geçerlidir.

Aynı iki ACE non-canonical sırada (allow önce, deny sonra) saklanırsa sonuç değişir: write isteğinde sistem önce allow (full) ACE'sini görür, istenen write dahil tüm hakları karşılar ve erişimi verir — deny ACE'sine hiç ulaşılmaz. Windows'un grafik arayüzü DACL'leri her zaman canonical sırada yazar, ama descriptor'lar API veya elle non-canonical hale getirilebilir; access check depolanan sırayla çalıştığı için bu, sessiz ve tehlikeli bir davranış farkı üretir.

Explicit, inherited'ı geçer

Inheritance, canonical order'ın ikinci boyutudur. Tercih edilen sırada explicit ACE'ler (nesnede doğrudan tanımlı) her zaman inherited ACE'lerden (üst nesneden gelen, ID bayraklı) önce gelir. Bu, çok pratik bir sonuç doğurur: bir nesnede explicit bir allow varken, üst klasörden gelen inherited bir deny bu allow'dan sonra değerlendirilir.

Dolayısıyla explicit allow, inherited deny'e ulaşılmadan istenen hakkı karşılayıp erişimi verebilir — yani explicit allow, inherited deny'i geçer. Bu, 'deny her zaman kazanır' basitleştirmesinin ikinci istisnasıdır: kural deny'in allow'u değil, canonical sıranın explicit'i inherited'dan önce koymasıdır. Sonucu belirleyen, ACE'nin allow/deny türü kadar explicit/inherited konumu ve sırasıdır.

Hiç DACL ile boş DACL zıttır

İki uç durum sık karıştırılır. NULL DACL, nesnenin hiç DACL'i olmaması demektir; access check bu durumda erişimi kısıtlayacak hiçbir kayıt bulamaz ve herkese full access verir. SDDL'de bu D:NO_ACCESS_CONTROL ile gösterilir ve parser bunu ayrı bir uyarıyla işaretler.

Empty DACL ise nesnenin bir DACL'i olması ama içinde sıfır ACE bulunması demektir. Bu DACL, istenen haklar için hiçbir allow ACE sağlamaz ve ACE-temelli denetimde implicit deny üretir. AD DS'te current owner için READ_CONTROL ve WRITE_DAC gibi örtük haklar ayrıca tanımlıdır; SE_TAKE_OWNERSHIP_PRIVILEGE de WRITE_OWNER hakkı doğurabilir. Bu nedenle empty DACL, DACL üzerinden hak vermese de bağlam dışı biçimde “kimse hiçbir erişim alamaz” diye genellenmemelidir. SDDL'de bu yalnızca D: ile (ACE'siz) yazılır; NULL DACL’den anlamı zıttır.

Durum ve veri akışı

1. İstek gelir: caller bir requested access mask ile handle ister (ör. write içeren bir istek). Remaining rights = istenen tüm haklar.
2. NULL DACL fixture'ı (D:NO_ACCESS_CONTROL): DACL yok → değerlendirme yapılmadan full access verilir; remaining anlamsızdır.
3. Canonical fixture'ı ((D;;FW)(A;;FA), RID 2902): sıra deny→allow; write isteğinde ilk ACE deny FW remaining write ile eşleşir → erişim reddedilir; allow'a ulaşılmaz.
4. Non-canonical fixture'ı ((A;;FA)(D;;FW), RID 2902): sıra allow→deny; write isteğinde ilk ACE allow FA tüm remaining'i karşılar → erişim verilir; deny'e ulaşılmaz. Aynı ACE kümesi, ters sonuç.
5. Inheritance fixture'ı ((A;;FA)(D;ID;FW), RID 2902): explicit allow FA inherited deny FW'den önce; write remaining explicit allow ile karşılanır → erişim verilir; inherited deny geçilir.
6. Empty DACL fixture'ı (D:): DACL var, 0 ACE; DACL üzerinden allow yok → istenen haklar ACE-temelli denetimde implicit deny olur. AD DS owner/privilege hakları ayrıca uygulanabilir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: Bir DACL'e bir kullanıcı için access-denied ACE koymak, o kullanıcının o hakkı almasını kesin olarak engeller. Gerçekte sonuç ACE'lerin sırasına ve explicit/inherited konumuna bağlıdır: DACL non-canonical sırada (allow, deny'den önce) yazılırsa access check istenen hakkı karşılayan allow ACE'sini önce görüp erişimi verir ve deny ACE'sine hiç ulaşmaz; benzer biçimde explicit allow, inherited deny'i geçer.

Technical prerequisites

• Hedef nesnenin DACL'inin non-canonical sırada (access-allowed ACE, aynı hakka ait access-denied ACE'den önce) saklanabilmesi; bu GUI dışı API veya elle düzenlemeyle mümkündür.
• İzin incelemesinin ACE varlığına bakıp sırasını denetlememesi ('deny var, demek ki engellendi' varsayımı).
• Geniş kapsamlı bir allow ACE'sinin (ör. FullControl) istenen dar hakları da kapsaması, böylece sonraki deny'lerin etkisiz kalması.
• Inherited deny'lere güvenilip explicit allow'ların gözden kaçması; explicit'in inherited'dan önce değerlendirildiğinin bilinmemesi.

Exploitation mechanism / İstismar mekanizması

Access check ACE'leri depolanan sırayla değerlendirir ve ilk belirleyici eşleşmede durur (How AccessCheck Works). Canonical order (Order of ACEs in a DACL) tam da bu yüzden vardır: access-denied ACE'leri access-allowed'lardan, explicit ACE'leri inherited'lardan önce koyarak deny'lerin ve explicit kısıtların önce görülmesini sağlar. Bir DACL non-canonical sıraya sokulursa — örneğin bir kullanıcı için geniş bir allow ACE'si, onu kısıtlaması beklenen deny ACE'sinden önce yazılırsa — write isteği ilk ACE'de karşılanır ve deny ACE'sine hiç ulaşılmaz; sonuç, mevcut deny'e rağmen erişim verilmesidir. Aynı mantık inheritance'ta da işler: explicit allow inherited deny'den önce geldiği için explicit allow kazanır. Kapsam, hangi nesnelerin DACL'inin non-canonical veya beklenenden geniş olduğudur; engelleyici kontrol, DACL'lerin canonical sırada ve least-privilege ile tutulması, geniş allow ACE'lerinin daraltılması ve descriptor değişimlerinin (4670) izlenmesidir.

Deny'in varlığı yeterli değildir

Bir izin incelemesi 'bu kullanıcı için deny ACE'si var, öyleyse engellenmiş' diye sonuçlanırsa yanılabilir. Access check kararı, ACE'nin varlığına değil, istenen hakka göre hangi ACE'nin önce eşleştiğine bağlıdır. Non-canonical sırada bir allow ACE'si deny'den önce geldiğinde, istenen hakkı karşılar ve deny hiç değerlendirilmez.

Bu yüzden inceleme iki şeyi denetlemelidir: ACE'lerin sırası canonical mı (deny'ler ve explicit'ler önce mi) ve allow ACE'leri beklenenden geniş hak mı veriyor. NewSd/OldSd farkı (4670) bir descriptor'ın non-canonical hale getirilip getirilmediğini görünür kılabilir, ancak sıra analizi olayın dışında SDDL üzerinde yapılır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Bir network share isteğinde 5145, istenen hakları (AccessMask/AccessList) share access-check sonucundan (AccessReason ve ilgili ACE) ayırır. Bu alanlar tüm DACL’i içermez ve NTFS düzeyindeki grant’i kanıtlamaz.
• 5145 belgeye göre Failure olayı yalnız erişim file-share düzeyinde reddedildiğinde üretilir; NTFS düzeyinde reddedilen erişim 5145 Failure üretmez. Bu, share ile NTFS katmanının ayrı değerlendirildiğini gösterir.
• Bir DACL'in içeriği veya sırası değiştiğinde (ör. bir allow ACE'sinin deny'den öne alınması) bu, 4670 (Permissions on an object were changed) olarak OldSd/NewSd farkıyla kaydedilir; non-canonical sıraya geçiş bu iki SDDL karşılaştırılarak yüzeye çıkarılır.
• 4670 üretimi nesnenin SACL'indeki Change Permissions audit ACE'lerine ve ilgili audit alt kategorisine bağlıdır; bu kapsam yoksa descriptor değişimi sessiz kalır ve sıra bozulması olaydan görülmez.

Events and relevant fields

• 5145: AccessMask ve AccessList istenen hakları gösterir. AccessReason, istenen hak için share düzeyindeki grant/deny sonucunu ve ilgili ACE’yi açıklar. İstenen hak tek başına grant, anomali veya non-canonical DACL kanıtı değildir.
• 5145 SubjectLogonId, ShareName ve RelativeTargetName ile hangi oturumun hangi paylaşımda hangi kaynağa eriştiğini bağlar; requested vs granted farkı bu bağlamda değerlendirilir.
• 4670: OldSd ve NewSd SDDL'leri karşılaştırılarak bir DACL'in non-canonical sıraya sokulup sokulmadığı veya geniş bir allow ACE'sinin eklenip eklenmediği belirlenir; sıra analizi olay dışında yapılır.
• Olayın yokluğu “değişiklik olmadı” veya “erişim verildi” anlamına gelmez. 5145 paylaşım kontrolünü kapsar. Dosya/registry izin değişiminde 4670 için ilgili audit policy ve uygun SACL audit ACE’si gerekir; SACL’in kendisi değiştiğinde 4670 üretilmez. NTFS retlerini ve AD nesnelerinin audit yolunu ayrıca incele.

İstenen ile verileni karşılaştır

5145’i okurken isteği sonuçtan ayır: AccessMask ve AccessList istenen hakları, AccessReason paylaşım düzeyindeki grant/deny sonucunu ve ilgili ACE gerekçesini gösterir. Bunlar tam DACL veya NTFS erişim kararı değildir. ACE sırasını incelemek için gerçek descriptor’ı, bir değişikliği incelemek için ilgili 4670 OldSd/NewSd kayıtlarını ayrıca karşılaştır.

İkinci katman, kararın girdisi olan descriptor'ın kendisini izlemektir. 4670'in OldSd→NewSd farkı, bir DACL'in ne zaman non-canonical hale getirildiğini veya geniş bir ACE eklendiğini gösterebilir; ancak bu iki olay da kapsam sınırlıdır (5145 yalnız share, 4670 yalnız SACL kapsamı) ve yoklukları 'sorun yok' anlamına gelmez.

Detection logic · KQL

// Inventory / triage: all collected 5145 events, not an anomaly detector
SecurityEvent
| where EventID == 5145
| project TimeGenerated, Computer, SubjectLogonId, ShareName, RelativeTargetName, AccessMask, EventData

Query assumptions

• Bu sorgu geniş bir 5145 envanteri/triage görünümüdür. Rutin erişim kayıtlarının gelmesi beklenir; şüpheli grant veya non-canonical descriptor seçmez.
• SecurityEvent belgesinde sorgudaki sütunlar bulunur. AccessList ve AccessReason ham 5145 XML alanlarıdır; bu tablonun belgelenmiş üst düzey sütunları değildir. Saklanan EventData’yı veya doğrulanmış ingestion eşlemesini incele. Eşleme eksikliği, ret veya boş hak talebi anlamına gelmez.
• AccessMask ve AccessList isteği, AccessReason share access-check sonucunu anlatır. AccessMask’in dolu olması normal erişimi anomaliden ayırmaz.
• 5145 Failure, share düzeyindeki ret içindir; NTFS düzeyindeki ret 5145 Failure üretmez. Descriptor sırası için gerçek descriptor’ı ve ilgili değişiklik kanıtını ayrıca incele.
• Gerçek SIEM çalıştırması, veri kümesi, zaman penceresi veya ölçülmüş tespit kalitesi yoktur. Daraltma için doğrulanmış share/path, principal, beklenen haklar ve sonuç baseline’ı gerekir.

False positives

• Meşru geniş yetkilendirmeler (yönetici erişimi, uygulama servis hesapları) rutin olarak geniş AccessMask talep eder; tek olay kötü niyet göstermez.
• Paylaşım tabanlı yedekleme/tarama araçları çok sayıda 5145 üretir ve benign baseline olarak ayrılmalıdır.
• AccessReason kodları ortam ve dil paketine göre değişebilir; ham kod eşlemesine dayanan kurallar yanlış pozitif/negatif üretebilir.
• Olayın yokluğu güvenlik değildir: NTFS-düzeyi ret veya SACL kapsamı dışı descriptor değişimi bu olaylarda görünmez.

Hardening

• DACL'leri canonical sırada (deny'ler ve explicit ACE'ler önce) ve least-privilege ile tut; non-canonical sıraya sokulmuş veya beklenenden geniş allow ACE'leri içeren descriptor'ları düzenli olarak tara ve düzelt.
• Geniş kapsamlı allow ACE'lerini (ör. gereksiz FullControl) daraltarak sonraki deny'lerin ve inherited kısıtların etkisiz kalmasını önle; inheritance'ı bilinçli kur, gereksiz protected (P) DACL'lerden kaçın.
• Yüksek değerli nesnelerin SACL'ini descriptor değişimlerini yakalayacak biçimde yapılandır ve 4670 OldSd/NewSd farkını izleyerek non-canonical sıraya geçişleri işaretle; share erişim kararlarını 5145 ile gözle.
• NULL DACL (herkese full access) ve istenmeyen empty DACL durumlarını envanterle; kontrolleri uygulamadan önce audit hacmini ve iş etkisini pilot kapsamda ölç ve geri dönüş planı tut.

Örnekler üzerinde oku / Read the examples

O:BAG:BUD:(D;;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(D;;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:AI(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(D;ID;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:NO_ACCESS_CONTROL

O:BAG:BUD:

İki yanlış kanı / Two reality checks

Sanılan: Bir kullanıcı için hem allow hem deny ACE'si varsa, deny her zaman kazanır.

Gerçekte: Access check ACE'leri depolanan sırayla değerlendirir ve ilk belirleyici eşleşmede durur; sonuç sıraya bağlıdır. 'Deny kazanır' yalnız canonical sıra korunduğunda (access-denied ACE'ler access-allowed'lardan önce) doğrudur. DACL non-canonical sıraya sokulup allow ACE'si deny'den önce yazılırsa, istenen hakkı karşılayan allow önce görülür ve deny'e ulaşılmadan erişim verilir. Ayrıca canonical sırada explicit ACE'ler inherited'lardan önce geldiği için explicit allow, inherited deny'i geçer.

Sanılan: Bir nesnenin DACL'i boşsa (hiç izin tanımlı değilse) herkes erişebilir.

Gerçekte: NULL DACL ile empty DACL zıt anlamlıdır. NULL DACL (nesnenin hiç DACL'i yok; SDDL: D:NO_ACCESS_CONTROL) herkese full access verir. Empty DACL (DACL var ama 0 ACE; SDDL: yalnız D:) DACL üzerinden hiçbir allow hakkı içermez ve ACE-temelli denetimde implicit deny üretir. AD DS’te owner/privilege kaynaklı örtük haklar ayrıca uygulanabilir. 'Boş DACL' ifadesi bu ikisini karıştırır; erişim sonucu taban tabana zıttır.

Kaynaklar / Sources

• Microsoft · How AccessCheck Works (How DACLs Control Access to an Object)
  NULL DACL → full access; DACL varsa ACE'lerin sıralı değerlendirmesi; eşleşen access-denied reddeder, yeterli access-allowed verir, aksi halde implicit deny; karar ilk belirleyici eşleşmede durur
• Microsoft · Order of ACEs in a DACL
  Tercih edilen (canonical) sıra: explicit ACE'ler inherited'lardan önce; her grupta access-denied ACE'ler access-allowed'lardan önce; inherited ACE'ler inheritance sırasına göre
• Microsoft · Null DACLs and Empty DACLs
  NULL DACL herkese full access verir; empty DACL (0 ACE) DACL üzerinden allow hakkı sağlamaz. AD DS’te owner/privilege kaynaklı bazı örtük haklar ayrıca uygulanabilir.
• Microsoft · ACE strings
  SDDL ACE söz dizimi; A/D ACE türleri, FA/FW/FR rights kısaltmaları, ID (INHERITED_ACE) flag ve NO_ACCESS_CONTROL gösterimi
• Microsoft · Access Rights and Access Masks
  Requested access mask; generic ve standard hakların istek maskesinde toplanması ve access check'in bu maskeye göre yürütülmesi
• Microsoft · 4670(S) Permissions on an object were changed
  OldSd/NewSd (SDDL) alanları; DACL/owner değişiminin karşılaştırılması; SACL değişiminde üretilmez
• Microsoft · 5145(S, F) A network share object was checked
  Requested rights: AccessMask/AccessList; access-check results: AccessReason; share-only Failure scope
• Microsoft · [MS-ADTS] Null vs. Empty DACLs
  §5.1.3.3.1: empty DACL DACL üzerinden hak vermez; current owner için implied READ_CONTROL/WRITE_DAC; SE_TAKE_OWNERSHIP_PRIVILEGE ile WRITE_OWNER; BlockOwnerImplicitRights nüansı.
• Microsoft · SecurityEvent table columns
  AccessMask, EventData, EventID, Computer, SubjectLogonId, ShareName, RelativeTargetName; raw XML versus ingestion schema