Security descriptor, owner, DACL, SACL ve ACE: Bir izin kaydını okumak.

1. Core Mechanism / Temel mekanizma

Bu ders bir security descriptor'ı alan alan okumayı öğretir: owner/primary group SID'leri, DACL, SACL ve control bit'ler ile bir ACE'nin type/flags/rights/trustee bileşenleri. Grupların token'a toplanması 05.01'de, authentication/authorization ayrımı 05.02'de; allow/deny sıralaması ve inheritance'ın erişim kararına etkisi 05.04'te işlenir. Buradaki odak bir izin kaydını doğru okumak — hangi alanın neyi söylediğini ayırmak — ve meta-control ile data-access ayrımını görmektir. Binary marshalling ayrıntısı MS-DTYP'a bırakılır; burada SDDL string gösterimi ve alan anlamı incelenir.

Arabirimler ve belirtimler

• Security descriptor: bir securable object'in güvenlik bilgisini taşıyan yapı; owner SID, primary group SID, DACL, SACL ve control bit'lerden oluşur.
• Owner SID: nesnenin sahibi; SDDL'de O: ile gösterilir. Primary group SID: SDDL'de G: ile gösterilir (POSIX uyumluluğu için taşınır, Windows erişiminde tali roldedir).
• DACL (D:): hangi trustee'lere hangi hakların allow/deny edildiğini belirleyen ACE listesi; erişim kararını üretir.
• SACL (S:): hangi erişim denemelerinin audit kaydı ürettiğini belirleyen ACE listesi; erişim vermez, audit üretir.
• ACE alanları: type (ör. A=access-allowed, D=access-denied, AU=system-audit), flags (inheritance vb.), rights (access mask), object/inherit GUID ve trustee SID.
• Meta-control hakları: READ_CONTROL (descriptor'ı okuma, SACL hariç), WRITE_DAC (DACL'i değiştirme), WRITE_OWNER (owner'ı değiştirme); bunlar nesnenin izin yapısını yönetir.
• Control bit'ler: SDDL'de DACL/SACL üzerindeki P (protected), AI (auto-inherited), AR (auto-inherit-required) bayrakları; descriptor'ın inheritance davranışını niteler.

Bir security descriptor beş parçadan oluşur

Bir securable object'in güvenlik bilgisi tek bir security descriptor'da toplanır. Bu yapı beş tür bilgi taşıyabilir: nesnenin owner ve primary group SID'leri, erişimi belirleyen bir DACL, audit üretimini belirleyen bir SACL ve descriptor'ın anlamını niteleyen bir dizi control bit. SDDL string gösteriminde bu parçalar sırasıyla O:, G:, D: ve S: önekleriyle yazılır.

Owner alanı önemlidir çünkü sahiplik, nesnenin izin yapısını yönetme hakkıyla ilişkilidir. Primary group alanı çoğu Windows erişim senaryosunda tali roldedir (POSIX uyumluluğu için taşınır). Asıl iş DACL ve SACL'de döner: biri 'kim neye erişebilir', diğeri 'hangi erişim denemesi iz bırakır' sorusunu yanıtlar.

Bir ACE'yi alan alan okumak

Bir ACL, ACE'lerin (access control entry) listesidir; her ACE bir trustee'yi ve o trustee için allow/deny/audit edilen hakları belirtir. SDDL'de bir ACE parantez içinde altı temel alanla yazılır: ace_type (A allow, D deny, AU system-audit), ace_flags (inheritance ve audit bayrakları), rights (access mask kısaltmaları veya hex), object_guid, inherit_object_guid ve trustee (SID veya kısaltma).

Rights alanı access mask'i taşır: GR/GW/GX gibi generic, RC/WD/WO/SD gibi standard, FR/FW/FA gibi file-specific kısaltmalar veya 0x... biçiminde ham hex. Trustee alanı ise ACE'nin kime uygulandığını söyler; ada değil SID'e bağlanır (03.03). Bir izin kaydını okumak, tam olarak bu alanları tek tek çözüp 'kim, hangi hakkı, allow mı deny mi audit mi' sorusunu yanıtlamaktır.

DACL erişimi, SACL audit'i belirler

DACL ile SACL aynı ACE söz dizimini kullanır ama işlevleri tamamen ayrıdır. DACL, bir process nesneye eriştiğinde erişimin verilip verilmeyeceğini belirler; sistem DACL'deki ACE'leri istenen haklara göre inceler. SACL ise hiçbir erişim vermez; yalnız hangi erişim denemelerinin (başarılı, başarısız ya da her ikisi) security event log'a kayıt üreteceğini belirler.

Bu ayrım pratikte sık karıştırılır. Bir SACL audit ACE'si eklemek kimseye erişim vermez; bir DACL allow ACE'si eklemek hiçbir audit üretmez. İki liste bağımsızdır: bir nesnede erişim geniş ama audit hiç olabilir, ya da tersine erişim dar ama her deneme kaydediliyor olabilir. Bir izin kaydını okurken hangi parçada olduğunuzu bilmek — D: mi S: mi — anlamı belirler.

Kontrol hakkı, veri hakkından güçlüdür

Standard access rights arasında iki tanesi descriptor'ın kendisini yönetir: WRITE_DAC, nesnenin security descriptor'ındaki DACL'i değiştirme hakkıdır; WRITE_OWNER ise owner'ı değiştirme hakkıdır. READ_CONTROL, descriptor'ı (SACL hariç) okuma hakkıdır. Bunlar 'veri' hakları değil, 'kontrol' haklarıdır: neye erişileceğini değil, kimin neye erişebileceğini kimin belirleyeceğini yönetirler.

Bu yüzden bir izin kaydını okurken WRITE_DAC veya WRITE_OWNER içeren bir ACE'yi görmek, sıradan bir Read/Write ACE'sinden daha dikkat gerektirir. WRITE_DAC taşıyan bir trustee, DACL'i yeniden yazıp kendine istediği veri hakkını verebilir; WRITE_OWNER taşıyan bir trustee owner'ı değiştirebilir. İzleyeceğimiz descriptor'da bu iki hak hem bir DACL ACE'sinde hem de bir SACL audit ACE'sinde görünecek — biri riski taşır, diğeri o riski izler.

Durum ve veri akışı

1. Descriptor'ın O: alanı okunur: owner Domain Admins (DA) alias'ı; nesnenin izin yapısını yönetme yetkisiyle ilişkili sahiplik.
2. G: alanı okunur: primary group Domain Users (DU); Windows erişiminde tali rol.
3. D: alanındaki ACE'ler tek tek çözülür: Built-in Administrators için File All (FA) allow; Domain Users (RID 513) için okuma-yürütme sınıfı hex maske (0x1200a9) allow; bir delege principal (RID 2814) için READ_CONTROL + WRITE_DAC (RCWD) allow.
4. RCWD ACE'si meta-control olarak işaretlenir: RID 2814 principal'ı DACL'i yeniden yazabilir, yani kendine herhangi bir veri hakkını verebilir.
5. S: alanındaki audit ACE okunur: Everyone (WD) için WRITE_DAC/WRITE_OWNER denemelerinde Success audit (AU;SA;WDWO) — descriptor değişikliği girişimlerini izleyen bir SACL girdisi.
6. Sonuç: aynı descriptor'da hem meta-control taşıyan bir DACL ACE'si hem de o meta-control kullanımını audit'leyen bir SACL ACE'si vardır; erişim (D) ile izleme (S) ayrı okunur.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: Bir izin kaydında yalnız Read/Write gibi veri hakları önemlidir; WRITE_DAC veya WRITE_OWNER 'sadece yönetim ayrıntısı'dır. Gerçekte bu meta-control hakları, DACL'i yeniden yazma veya owner'ı değiştirme yeteneği verdiğinden, mevcut veri ACE'lerinden bağımsız olarak nesne üzerinde tam kontrol yoluna açılır.

Technical prerequisites

• Bir principal'ın hedef nesnede WRITE_DAC (DACL'i değiştirme) veya WRITE_OWNER (owner'ı değiştirme) hakkı taşıması.
• Bu meta-control hakkının fark edilmemesi veya 'düşük riskli delegasyon' sanılması; izin incelemesinin yalnız veri haklarına bakması.
• Descriptor değişikliklerini izleyen SACL ve olay kaydının bulunmaması, böylece DACL/owner değişiminin sessiz kalması.
• Delegasyonun geniş kapsamda (ör. çok sayıda nesneye) verilmiş olması, meta-control'un etkisini genişletmesi.

Exploitation mechanism / İstismar mekanizması

WRITE_DAC, nesnenin DACL'ini değiştirme hakkıdır; WRITE_OWNER ise nesnenin owner'ını değiştirmeye izin verir. Windows'ta owner varsayılan olarak WRITE_DAC alabilir ve böylece DACL'i düzenleyebilir; fakat OWNER RIGHTS ACE'leri bu örtük owner haklarını belirleyebilir, ayrıca bazı AD computer object senaryolarında BlockOwnerImplicitRights koşulları uygulanır. Bu yüzden WRITE_OWNER veri erişimi değildir ve tek başına her nesnede DACL'i değiştirme garantisi vermez; hedef nesnenin türü ve descriptor'ı incelenmelidir. Bir izin kaydını okurken şu iki soruyu ayrı tut: 'bu principal şu an hangi veriye erişebiliyor' ve 'bu principal izin yapısının kontrolünü hangi koşullarda ele geçirebilir'. Kapsam, hedef nesnenin owner-rights kurallarıyla birlikte hangi principal'ların hangi nesnelerde WRITE_DAC/WRITE_OWNER taşıdığıdır; engelleyici kontrol, meta-control haklarını least-privilege ile sınırlamak, gereksiz sahiplikleri gözden geçirmek ve DACL/owner değişimlerini uygun SACL/audit kapsamıyla izlemektir.

İzin kaydında en tehlikeli alan hangisi

Bir izin kaydını incelerken göz çoğu zaman FullControl/Modify gibi veri haklarına takılır. Oysa WRITE_DAC doğrudan DACL'i yeniden yazma hakkıdır; WRITE_OWNER da owner'ı değiştirebilir ve Windows'ta owner varsayılan olarak WRITE_DAC alabilir. Bu yol OWNER RIGHTS ACE'leriyle ve bazı AD computer object koşullarıyla sınırlandırılabildiğinden, her nesne için etkisi descriptor ve nesne türüyle birlikte değerlendirilmelidir.

Bu yüzden değerlendirme iki soruyu ayırmalıdır: 'bu principal şu an hangi veriye erişebiliyor' ve 'bu principal izin yapısını hangi koşullarda değiştirebilir'. WRITE_DAC varsa DACL yönetim yolu açıktır; WRITE_OWNER varsa hedef nesne için owner'ın örtük hakları ayrıca kontrol edilmelidir. Meta-control ACE'lerini veri haklarından ayrı işaretlemek, olası kontrol yolunu ve sınırlarını görünür kılar.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Bir nesnenin izinlerinin (DACL veya owner) değişmesi 4670 (Permissions on an object were changed) olarak kaydedilir; olay OldSd ve NewSd alanlarında değişimden önceki ve sonraki security descriptor'ı SDDL olarak taşır, böylece fark okunabilir.
• 4670, SACL’in kendisi değiştiğinde üretilmez. File-system veya registry nesnelerinin SACL değişimi için 4907’ye bakılır; 4907 Active Directory nesneleri için üretilmez.
• 4670 üretilmesi için nesnenin SACL'inde uygun audit ACE'leri gerekir: dosya nesnesinde 'Change Permissions' ve/veya 'Take Ownership', registry key'de 'Write DAC' ve/veya 'Write Owner' denemelerini audit'leyen girdiler. SACL bunları kapsamıyorsa olay hiç üretilmez.
• Bu yüzden bir descriptor değişiminin izlenmesi iki koşula bağlıdır: doğru SACL kapsamı (S: alanının değişimi tetikleyecek audit ACE'leri içermesi) ve ilgili audit alt kategorisinin (Audit File System/Registry) etkin olması.

Events and relevant fields

• 4670: OldSd ve NewSd SDDL string'leri karşılaştırılarak hangi ACE'nin eklendiği/çıkarıldığı veya owner'ın değiştiği belirlenir; ObjectName ve HandleId hangi nesnenin değiştiğini verir, SubjectUserSid değişikliği yapan principal'ı gösterir.
• 4670'in NewSd'sinde bir WRITE_DAC/WRITE_OWNER (WD/WO) ACE'sinin eklenmesi, meta-control'un genişlediğinin doğrudan kanıtıdır ve OldSd ile farkı bunu görünür kılar.
• 4907, desteklenen file-system/registry nesnelerinde SACL değişiminin OldSd/NewSd farkını gösterir. AD nesnesindeki audit kapsamını izlemek için bu Event ID’yi genelleme; DC’nin Directory Service audit yolunu ve gerçek descriptor durumunu ayrıca incele.
• 4670 üretiminin SACL'e bağlı olması nedeniyle olayın yokluğu 'değişiklik olmadı' demek değildir; SACL doğru audit ACE'lerini içermiyorsa değişim sessizce gerçekleşebilir.
• AD DS’te 4662, Audit Directory Service Access ve işleme uyan object SACL koşuluyla DC’de üretilir; ObjectName, AccessMask ve Properties işlem bağlamını gösterir. Bu kayıt tek başına eski/yeni descriptor farkı değildir.

Değişimi doğru kanaldan izle

Önce nesne türünü ve değişen parçayı seç. Bu dersteki dosya örneğinde DACL/owner değişimi için 4670 OldSd/NewSd karşılaştırılır; SACL değişimi için 4907 kullanılır. 4907, AD nesnelerinde üretilmez. Bir dosya audit şemasını OU veya user nesnesine aynen taşımak yanlış kanıt beklentisi doğurur.

4670’in üretilmesi için ilgili audit alt kategorisi ve nesnede uygun audit ACE’si gerekir. SACL burada değişen parça değil, olayın üretim koşuludur. AD DS’te DC’nin Directory Service Access/4662 yolunu, object SACL’i ve güncel descriptor’ı birlikte incele; bir işlem kaydını eksiksiz descriptor farkı sayma.

Detection logic · XPath

*[System[EventID=4670] and EventData[Data[@Name='ObjectType']='File']]

Query assumptions

• İfade tek bir Windows Event Log belgesinde File nesneleri için 4670 permission-change olaylarını seçer; OldSd/NewSd farkı ayrıca (XPath dışında) karşılaştırılmalıdır.
• Named-field seçimi yalnız EventData/Data/@Name değerleri ObjectType/OldSd/NewSd adlarıyla düzleştiriliyorsa çalışır; backend eşlemesi doğrulanmalıdır.
• 4670 üretimi nesnenin SACL'inde Change Permissions/Take Ownership audit ACE'lerine ve Audit File System alt kategorisine bağlıdır; bunlar yoksa olay hiç oluşmaz.
• Sorgu bu oturumda gerçek bir host veya SIEM üzerinde çalıştırılmadı; eşik, veri kümesi ve zaman penceresi yoktur; SACL değişimleri 4907 ile ayrı izlenmelidir.

False positives

• Meşru yönetim işlemleri (izin düzeltmeleri, migrasyon, uygulama kurulumları) rutin olarak 4670 üretir; tek olay kötü niyet göstermez.
• Toplu ACL düzeltme araçları çok sayıda 4670 üretebilir; bunlar benign baseline olarak ayrılmalıdır.
• OldSd/NewSd farkı incelenmeden yalnız olay sayımına bakmak yanıltır; asıl sinyal eklenen meta-control (WD/WO) ACE'lerindedir.
• Olayın yokluğu güvenlik değil; SACL uygun audit ACE'lerini içermiyorsa veya alt kategori kapalıysa değişiklikler kaydedilmez.

Hardening

• WRITE_DAC ve WRITE_OWNER haklarını ve gereksiz sahiplikleri least-privilege ile sınırla; hangi principal'ların hangi nesnelerde bu meta-control'ü taşıdığını envanterle ve azalt.
• Yüksek değerli nesnelerin SACL'ini descriptor değişimlerini yakalayacak biçimde yapılandır (Change Permissions/Take Ownership audit ACE'leri) ve Audit File System/Registry alt kategorilerini etkinleştir.
• 4670 (DACL/owner değişimi) ve 4907 (SACL değişimi) olaylarını ayrı ayrı izle; özellikle NewSd'ye WD/WO ACE eklenmesini ve audit kapsamının daraltılmasını öncelikli işaretle.
• Kontrolleri uygulamadan önce pilot kapsamda audit hacmini ve iş etkisini ölç; SACL genişletmesinin log hacmini yönetilebilir tuttuğunu doğrula ve geri dönüş planı tut.

Örnekler üzerinde oku / Read the examples

O:DAG:DUD:(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-1002233445-2244556677-3366778899-513)(A;;RCWD;;;S-1-5-21-1002233445-2244556677-3366778899-2814)S:(AU;SA;WDWO;;;WD)

İki yanlış kanı / Two reality checks

Sanılan: Bir izin kaydında SACL'e ACE eklemek, ilgili kullanıcılara o kaynağa erişim verir.

Gerçekte: Audit ACE’si erişim vermez; uygun audit policy ile belirli erişim denemelerinin kaydını sağlar. DACL discretionary erişim haklarını belirler. Bununla birlikte token privilege’ları ve diğer uygulanabilir kontroller de erişim sonucuna etki edebilir: burada sıradan, ilgili bypass privilege’ı etkin olmayan dosya isteğini inceliyoruz. Audit kapsamını genişletmek ile izin vermek ayrı işlemlerdir.

Sanılan: Bir kullanıcının bir dosyaya Read/Write hakkı yoksa, o dosyada hiçbir şey yapamaz; WRITE_DAC gibi haklar önemsiz yönetim ayrıntılarıdır.

Gerçekte: WRITE_DAC nesnenin DACL'ini değiştirme, WRITE_OWNER ise owner'ı değiştirme hakkıdır (Standard Access Rights). Bu meta-control hakları veri erişimi vermez ama izin yapısını yönetir: WRITE_DAC taşıyan bir principal, mevcut DACL kendisine hiçbir veri hakkı vermese bile DACL'i yeniden yazıp kendine istediği hakkı ekleyebilir. Bu yüzden bir izin kaydında bu haklar, sıradan Read/Write'tan daha yüksek riskle değerlendirilmelidir.

Kaynaklar / Sources

• Microsoft · Security Descriptors
  Security descriptor bileşenleri: owner ve primary group SID'leri, DACL, SACL ve control bit'ler; SECURITY_DESCRIPTOR yapısı
• Microsoft · Access Control Lists
  DACL erişimi belirler, SACL audit üretimini belirler; ACL bir ACE listesidir; her SACL ACE'si success/failure audit üretimini belirtir
• Microsoft · Access Control Entries
  ACE bir trustee'yi ve o trustee için allow/deny/audit edilen hakları belirtir; ACE alan yapısı
• Microsoft · Standard Access Rights
  READ_CONTROL (descriptor'ı okuma, SACL hariç), WRITE_DAC (DACL'i değiştirme), WRITE_OWNER (owner'ı değiştirme), DELETE tanımları
• Microsoft · ACE strings
  SDDL ACE söz dizimi; A/D/AU ACE türleri, RC/WD/WO/SD/FA rights kısaltmaları ve trustee SID alias'ları (DA/BA/DU/WD)
• Microsoft Open Specifications · [MS-DTYP] SECURITY_DESCRIPTOR
  SECURITY_DESCRIPTOR control flag'leri (SE_DACL_PRESENT, SE_DACL_PROTECTED, SE_DACL_AUTO_INHERITED, SE_SELF_RELATIVE) ve OwnerSid/GroupSid/Sacl/Dacl alanları
• Microsoft · 4670(S) Permissions on an object were changed
  OldSd/NewSd (SDDL) alanları; 'does not generate if the SACL was changed'; SACL'de Change Permissions/Take Ownership audit ACE gereksinimi; Audit File System/Registry
• Microsoft · 4907(S) Auditing settings on object were changed
  File/registry SACL changes; not generated for Active Directory objects.
• Microsoft · Owner of a New Object
  Owner implicitly has WRITE_DAC; WRITE_OWNER access can set a valid user/group SID as owner
• Microsoft · [MS-ADTS] Blocking Implicit Owner Rights
  AD-specific conditions where implicit owner READ_CONTROL/WRITE_DAC rights can be blocked for certain computer objects and OS versions
• Microsoft · Event 4662
  DC; ObjectName/AccessMask/Properties operation context, matching SACL; not full descriptor diff.
• Microsoft · Audit Directory Service Access
  Directory Service Access audit subcategory and SACL-matched operations.
• Microsoft · Managing privileges in a file system
  Caller holds and enables privilege; SeBackupPrivilege/SeRestorePrivilege defined file operations, not a universal DACL-only outcome.