LDAP ile dizini okumak: Search base, scope, filter ve erişilebilir öznitelikler.

1. Core Mechanism / Temel mekanizma

Bu ders LDAP Search operation'ı RFC 4511 §4.5.1 üzerinden alan alan ele alır: SearchRequest'in baseObject, scope, derefAliases, sizeLimit, timeLimit, typesOnly, filter ve attributes bileşenleri. Attribute seçim listesinin özel durumları (boş liste, '*', '1.1') §4.5.1.8'de tanımlıdır. Filtre kodlamasının context tag'leri (equalityMatch [3], present [7]) aynı bölümdedir. AD'nin sunucu-taraflı sonuç sınırları (ör. MaxPageSize ve paged results control mekanizması) kavramsal olarak anılır ama belirli sürüm sayıları uydurulmaz; erişim kararının ACE düzeyi mantığı ise ayrı bir derse bağlanır.

Arabirimler ve belirtimler

• baseObject: aramanın başlayacağı DN; aramanın kökü buradan belirlenir (RFC 4511 §4.5.1.1).
• scope: baseObject(0) yalnız o giriş, singleLevel(1) doğrudan alt nesneler, wholeSubtree(2) tüm alt ağaç (RFC 4511 §4.5.1.2).
• filter: nesnelerin eşleşme koşulu; equalityMatch, present, substrings, and/or/not gibi CHOICE alternatifleri (RFC 4511 §4.5.1.7).
• attributes: eşleşen entry'den istenen alanlar. Boş liste veya '*' tüm user attribute'larını ister; operational attribute'lar ayrıca ismen istenir. Yalnız '1.1' hiçbir attribute istemez; entry'nin DN'i yine dönebilir.
• typesOnly: TRUE ise yalnız attribute adları, değerler olmadan döner (RFC 4511 §4.5.1.6).
• sizeLimit/timeLimit: istemcinin istediği üst sınırlar; sunucu kendi üst sınırını ayrıca dayatabilir (RFC 4511 §4.5.1.4–5).
• paged results: büyük sonuç kümelerini parça parça almak için kullanılan control; tek istekte dönen nesne sayısını sunucu sınırlar.

Bir search'ü tanımlayan beş karar

Bir LDAP aramasında önce baseObject başlangıç nesnesini, scope incelenecek nesneleri belirler. Filter bu adayların hangilerinin eşleşeceğini; attributes ise eşleşen entry'lerden hangi alanların isteneceğini söyler. Okuma izinleri de sonucu süzer. Bu seçimleri birbirinden ayırmadan boş bir yanıtın nedenini anlayamayız.

Bu ayrım pratik bir sonuç doğurur: aynı dizinde aynı kullanıcı, farklı scope veya filtre ile çok farklı sonuç kümeleri alır. 'Bu veriye erişilebiliyor mu?' sorusu, kullanılan search parametreleri belirtilmeden eksik bir sorudur.

sizeLimit tüm arama için istenen entry sınırıdır; 0, istemcinin ek sınır koymadığını söyler. Sunucu yine kendi limitlerini uygulayabilir. Paged Results Control ilk SearchRequest'e eklenir. Sonraki sayfa sunucunun cookie'siyle, aynı arama parametreleri kullanılarak istenir. Sayfa boyutu ile toplam sonuç sınırı farklıdır: sayfalama izin vermez, yönetim limitlerini ortadan kaldırmaz.

İstenen attribute listesi bir sözleşmedir

attributes, eşleşen entry'den hangi alanların isteneceğini belirtir. Boş liste veya '*' tüm user attribute'larını ister. Operational attribute'lar ayrıca ismen istenir; '*' tek başına onları kapsamaz. Yalnız '1.1' hiçbir attribute istemez. Bu, eşleşen nesneleri silmez: SearchResultEntry'nin DN'i gelir ama attribute listesi boş olur. typesOnly TRUE ise istenen ve okunabilen attribute adları gelir, değerleri gelmez.

Önemli bir sınır: tüm user attribute'ları istense bile, erişim kontrolleri veya başka kısıtlar nedeniyle bazı attribute ve değerler sonuçta yer almayabilir (RFC 4511 §4.5.1.8). Yani 'istedim ama gelmedi' her zaman 'yok' demek değildir; 'bu bağlamda okumana izin verilmedi' de olabilir.

Yukarıdaki ağaçta People'ı seç: baseObject yalnız People; singleLevel Kayra, Deniz ve Teams; wholeSubtree bunlarla birlikte People ve Teams'in altındaki ResearchTeam'i kapsar. '(mail=*)' filtresinde mail alanı bulunmayan nesneler FALSE verir. Deniz.mail bu okuma bağlamında görünmüyorsa AD filtre için de onu yok sayar. Şemada tanınmayan bir attribute ise Undefined verebilir. FALSE ile Undefined farklı nedenlerdir; ikisi de eşleşme değildir.

Örnek istek: alan alan bir SearchRequest

Bu dersin artifact'i sentetik bir SearchRequest'i byte düzeyinde gösterir: baseObject 'DC=outreason,DC=example', scope wholeSubtree(2), derefAliases neverDerefAliases(0), sizeLimit 0 (istemci sınırı yok), timeLimit 30 saniye, typesOnly FALSE ve filter olarak equalityMatch (sAMAccountName=kayra). İstenen attribute listesi cn, mail ve memberOf'tur.

Kodlamada filter'ın equalityMatch [3] context tag'iyle (0xA3) taşındığını, içindeki AttributeValueAssertion'ın attributeDesc ve assertionValue OCTET STRING'lerinden oluştuğunu görürsünüz. Bu, filtre söz diziminin ('(sAMAccountName=kayra)') aslında yapılandırılmış bir ASN.1 ağacına karşılık geldiğini somutlaştırır.

Okumak ile kontrol etmek aynı hak değildir

Bir attribute'u LDAP ile okuyabilmek, ilgili nesnede onu değiştirebileceğiniz anlamına gelmez. Attribute okumada RIGHT_DS_READ_PROPERTY, yazmada çoğunlukla RIGHT_DS_WRITE_PROPERTY; bazı işlemlerde ise işleme özgü validated-write veya control-access hakları değerlendirilir. Bu hakların ACE'leri attribute/property-set ya da nesne kapsamıyla sınırlandırılabilir ([MS-ADTS] Access Checks, Validated Writes ve Property Set). Örneğin group membership'i okuyabilmek, `member` attribute'unu güncelleme yetkisi kanıtı değildir.

Bu ayrım savunma ve saldırı değerlendirmesinde kritik: geniş okunabilirlik 'keşif' verir ama tek başına 'değiştirebilme' vermez. Bir sonucu raporlarken 'okundu' ile 'yazılabilir/kontrol edilebilir' ayrı ayrı belirtilmelidir.

Arama sonucu gerçekten tamam mı?

İki SearchResultEntry gelmesi aramanın başarılı bittiğini söylemez. Son SearchResultDone, resultCode ile operation sonucunu bildirir. sizeLimitExceeded (4) veya timeLimitExceeded (3) ile biten bir aramada gelen entry’ler kullanılabilir gözlemlerdir, fakat istenen kümenin tamamı oldukları söylenmez. Success bile yalnız verilen base, scope, filter ve visibility sınırında yorumlanır.

Simple paged results kullanılıyorsa bir sayfanın Done success sonucu bütün aramanın sonu değildir. Dönen opaque cookie boş değilse devam gerekir; tamamlanmış dizinin son cookie’si boştur. Cookie’nin içinden nesne sayısı veya güven bilgisi çıkarmayız. Sayfalar arasında dizin değişirse bir entry tekrar gelebilir veya sonuç dışında kalabilir; son cookie’nin boş olması tek bir ana ait snapshot garantisi vermez. Karşılaştırmada limit, ilk sayfa ve değişen dataset durumlarını ayrı incele.

Durum ve veri akışı

1. İstemci baseObject, scope, filter, istenen attribute listesi ve limitleri içeren bir SearchRequest oluşturur.
2. Sunucu baseObject'i bulur; scope'a göre değerlendirilecek nesne kümesini belirler.
3. Her aday nesne için filter üç değerli mantıkla (TRUE/FALSE/Undefined) değerlendirilir.
4. TRUE eşleşen nesneler için istenen attribute'lar, erişim kontrolleri süzdükten sonra SearchResultEntry olarak döner.
5. Paging kullanılıyorsa ilk istekte control bulunur; sonraki sayfa aynı arama ve sunucunun cookie'siyle istenir. Sayfa boyutu, aramanın toplam sizeLimit'ini veya erişim kontrollerini kaldırmaz.
6. İstemci dönen alanları 'okundu' olarak işler; yazma/kontrol hakkı bu okumadan çıkarılamaz.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Bir nesnenin attribute'larını LDAP ile okuyabiliyorsam, o nesne üzerinde anlamlı bir kontrol ya da değişiklik hakkım da vardır.

Technical prerequisites

• Dizini okuyabilen bir bind bağlamı; çoğu ortamda Authenticated Users birçok attribute'u okuyabilir.
• Geniş sonuç için uygun baseObject ve wholeSubtree scope; dar scope keşfi sınırlar.
• Okunmak istenen attribute için gerekli effective read hakkı; confidential attribute söz konusuysa READ_PROPERTY yanında CONTROL_ACCESS da gerekir.
• Bir write/control iddiası için, yapılmak istenen değişikliğe ve hedef attribute/nesneye uyan effective DACL ACE/right ayrıca doğrulanmalıdır.
• Sonuçları sayfalı almak için sunucu Paged Results Control'ı desteklemeli ve ortam politikası isteğe izin vermelidir; bu kontrol yönetim limitlerini veya ACL'leri bypass etmez.

Exploitation mechanism / İstismar mekanizması

Geniş read hakkı, uygun baseObject, wholeSubtree scope ve seçilmiş filter ile çok sayıda nesneyi sıralamayı sağlayabilir: users, groups, memberOf ve service-related attribute'lar görünür. Paged Results Control büyük sonuçları cookie ile sayfalara böler; RFC 2696 bu kontrolü sunucunun sonuç döndürme hızını yönetmek için tanımlar, hakları veya sunucu politikası limitlerini aşmak için değil. Okuma yine attribute-level access checks'e tabidir. Bir grubun üyeliğini okumak, grubun member attribute'unu değiştirebilme hakkı değildir. Hedef değişikliği mümkün saymadan önce o işlem için geçerli effective right/ACE kanıtlanmalıdır.

Keşiften eyleme atlarken kanıt gerekir

LDAP okuması, saldırgana zengin bir harita verir; bu haritadan 'hangi hesap değiştirilebilir?' sorusuna geçmek ayrı bir kanıt ister. Değiştirilebilirlik iddiası, hedef nesnenin DACL'inde okuyan principal'a verilmiş yazma veya control-access ACE'sine dayanmalıdır.

Pratikte bu, 'okunabilir' bulgularını ayrı, 'yazılabilir/kontrol edilebilir' bulgularını ayrı listelemek demektir. İki listeyi karıştırmak, keşif verisini olduğundan güçlü gösterir ve yanlış öncelik doğurur.

Kapsam değişir; erişim hakkı değişmez

Sentetik ağaçta aynı okuma bağlamını koruyup People altında singleLevel ile wholeSubtree'yi karşılaştır. ResearchTeam ikinci aramada aday olur; bu fark bir izin artışı değil, parent ilişkilerinin kapsam içine girmesidir. İstenen attribute listesini büyütmek de okunamayan Deniz.mail alanını açmaz.

Bir değerlendirmede baseObject, scope, filter, istenen alanlar ve limitler kaydedilmelidir. “Dizini okudu” tek başına hangi nesnelerin ve hangi alanların görüldüğünü açıklamaz. Yazma veya kontrol hakkı için ayrı erişim kanıtı gerekir.

Bu örneğin risk sınırı

Eksik bir arama sonucunu bütün effective izin yollarının envanteri saymak hatalı etki iddiası üretir. Read başarısı yazma yetkisi de vermez.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• LDAP search'ün kendisi (base/scope/filter) varsayılan güvenlik denetiminde ayrı bir olay olarak kaydedilmez; okuma denetimi nesne SACL'ine ve Audit Directory Service Access alt kategorisine bağlıdır (4662).
• 4662 yalnız denetlenen nesnede uygun SACL varsa üretilir ve erişilen class/attribute'u ObjectType/Properties GUID'leriyle gösterir; ancak LDAP sorgusunun filtresini veya scope'unu içermez.
• Bu nedenle 'kim geniş bir enumeration yaptı?' sorusu tek başına 4662 ile yanıtlanamaz; okuma denetimi ne yapıldığını değil hangi nesneye dokunulduğunu söyler.
• Uygulama görünürlüğü sınırlıdır: birçok LDAP okuması denetlenmeyen attribute'lar üzerinden geçtiği için hiç iz bırakmaz.

Events and relevant fields

• 4662 Provider'ı Microsoft-Windows-Security-Auditing, kanalı Security, Version 0'dır (Microsoft, 4662 belgesi).
• EventData'da SubjectUserSid, SubjectUserName, ObjectServer=DS, ObjectType (class bilgisi), ObjectName (erişilen nesnenin distinguished name'i), OperationType, AccessMask ve Properties alanları bulunur. Properties, erişim türünü ve ilgili class/property-set GUID'lerini içerebilir.
• Properties içindeki property/property-set GUID'leri erişim kapsamını gösterebilir; property set bir ACE ile birden çok attribute için izin tanımlayabilir. 4662 sonucu yine LDAP query değil, denetlenen nesne erişimidir.
• 4662, dönen sonuç kümesinin büyüklüğünü, sizeLimit'i veya paging davranışını raporlamaz.

Denetim 'ne okundu'yu değil 'neye dokunuldu'yu söyler

4662'nin gücü nesne/attribute düzeyinde erişimi kaydetmesidir; sınırı ise LDAP sorgusunun şeklini (base, scope, filter) taşımamasıdır. Bu yüzden 'geniş bir enumeration yapıldı mı?' sorusu, güvenlik olaylarıyla ancak dolaylı yanıtlanır: çok sayıda farklı nesneye kısa sürede erişim gibi desenler ipucu verir ama kesin değildir.

Doğru kurgu, hedefli SACL ile gürültüyü azaltmak ve mümkünse ağ/uygulama tarafı LDAP kayıtlarıyla desteklemektir. Okuma denetimini forest geneline yaymak, sinyali gürültüde boğar.

Değişiklik sonrası doğrulama

Sorgu parametreleri, entry sayısı, terminal resultCode, paging control ve cookie’nin boş olup olmadığını kaydet. Tek DC görünümünü forest genelindeki tüm nesnelerle veya sabit snapshot’la eşitleme.

Detection logic · XPath

*[System[EventID=4662] and EventData[Data[@Name='AccessMask']='0x10']]

Query assumptions

• Security kanalında yalnız AccessMask metni tam olarak 0x10 olan 4662 kayıtlarını seçer. 0x10 Read Property, 0x10000 DELETE’tir; %%1537 okuma kodu olarak kullanılmaz.
• Bu dar eşleşme birleşik maskeleri veya farklı metin biçimlerini kapsamaz. Daha geniş incelemede maskenin 0x10 biti sayısal olarak kontrol edilmelidir. Audit Directory Service Access ve işleme uyan SACL gerekir.
• 4662 baseObject, scope veya filter taşımaz. Bu seçim geniş enumeration kanıtı değildir; gerçek Windows Event Log veya SIEM üzerinde çalıştırılmadı.

False positives

• Yönetim araçları, dizin uygulamaları ve replikasyon rutin olarak denetlenen nesneleri okur ve 4662 üretir.
• Attribute düzeyi SACL geniş tutulursa normal iş yükünde büyük hacim oluşur.
• Tek 4662, sorgunun geniş bir keşif mi yoksa dar bir arama mı olduğunu ayırt etmez.
• Denetlenmeyen attribute'lar üzerinden yapılan okuma hiç olay üretmez; olay yokluğu enumeration olmadığını göstermez.

Hardening

• Okuma denetimini SACL ile yalnız yüksek değerli nesnelere ve hassas attribute'lara uygula; forest/domain geneli geniş okuma SACL'i yüksek hacim ve düşük sinyal üretir.
• Gerçekten gizli attribute'ları confidential (searchFlags confidential biti) işaretleyerek yetkisiz okumayı ACE düzeyinde engelle; uygulama uyumluluğunu pilotla doğrula.
• Sunucu tarafı sorgu sınırlarını (ör. MaxPageSize ve yönetim limitleri) ortam politikasına göre gözden geçir; tek sorguyla sınırsız sıralamayı zorlaştır.
• Anonim ve aşırı geniş okuma haklarını azalt; varsayılan izinleri en az ayrıcalık ilkesiyle hizala.
• Enumeration'ı yakalamak için güvenlik olayına ek olarak ağ/uygulama tarafı LDAP telemetrisini (mümkünse) değerlendir; tek kaynağa güvenme.

Örnekler üzerinde oku / Read the examples

30 5c 02 01 01 63 57 04 17 44 43 3d 6f 75 74 72
65 61 73 6f 6e 2c 44 43 3d 65 78 61 6d 70 6c 65
0a 01 02 0a 01 00 02 01 00 02 01 1e 01 01 00 a3
17 04 0e 73 41 4d 41 63 63 6f 75 6e 74 4e 61 6d
65 04 05 6b 61 79 72 61 30 14 04 02 63 6e 04 04
6d 61 69 6c 04 08 6d 65 6d 62 65 72 4f 66

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E08",
  "page1": {
    "entries": [
      "toy-A",
      "toy-B"
    ],
    "result": "success",
    "cookie": "opaque-1"
  },
  "page2": {
    "entries": [
      "toy-C"
    ],
    "result": "success",
    "cookie": ""
  },
  "limitedVariant": {
    "entries": [
      "toy-A"
    ],
    "result": "sizeLimitExceeded"
  }
}

İki yanlış kanı / Two reality checks

Sanılan: Tüm user attribute'larını istediğim (boş liste veya '*') bir search bana o nesnenin her alanını verir.

Gerçekte: '*' operational attribute'ları getirmez (onlar ismen istenmelidir) ve erişim kontrolleri bazı attribute/değerleri sonuçtan tamamen süzebilir. Dönmeyen bir alan 'yok' değil, 'bu bağlamda okunamadı' da olabilir (RFC 4511 §4.5.1.8).

Sanılan: Bir hesabın veya grubun attribute'larını LDAP ile okuyabiliyorsam, onu değiştirebilirim de.

Gerçekte: Okuma ve yazma farklı ACE'lere dayanır. memberOf'u veya bir attribute'u görmek, ilgili nesnede write ya da control-access hakkı olmadan değişiklik yapmaya yetmez; kontrol iddiası ayrıca DACL'den doğrulanmalıdır.

Kaynaklar / Sources

• RFC 4511 · LDAP: The Protocol
  §4.5.1 SearchRequest (baseObject/scope/derefAliases/sizeLimit/timeLimit/typesOnly/filter); §4.5.1.7 Filter ve equalityMatch [3]/present [7]; §4.5.1.8 AttributeSelection ve '*'/'1.1' özel durumları; §4.5.2 SearchResultEntry.
• RFC 4512 · LDAP: Directory Information Models
  §5.1 operational (root DSE) attribute'ların yalnız ismen istenince dönmesi; operational vs user attribute ayrımı.
• Microsoft · 4662(S, F) An operation was performed on an object
  Audit Directory Service Access; SACL koşulu, EventData alanları (ObjectType/Properties/AccessMask), sorgu şeklinin kaydedilmemesi.
• RFC 2696 · LDAP Control Extension for Simple Paged Results Manipulation
  Abstract and §3: pages/cookies manage the rate and continuation of search-result delivery; not an authorization or server-limit bypass.
• [MS-ADTS] · Access Checks
  §3.1.1.4.3: object/attribute visibility and RIGHT_DS_READ_PROPERTY; unreadable values are treated as absent in results and filters.
• [MS-ADTS] · Validated Writes
  §5.1.3.2.2: attribute write uses RIGHT_DS_WRITE_PROPERTY; validated writes have separate operation-specific rights/ACEs.
• [MS-ADTS] · Property Set
  §3.1.1.2.3.3: property-set GUID may be used in an ACE to grant/deny access across its member attributes; includes Group Membership set.
• Microsoft · Membership property set
  Group Membership rights-GUID and its property-set member list, including the Member attribute.
• Microsoft · Consuming Events (Windows Event Log)
  XPath 1.0 limitations: selectors must select Event nodes; supported child/attribute axes and comparison predicates.