AD CS Bölüm 4: Kataloğun Geri Kalanı ve Nasıl Kilitleneceği

Subject konusunun ötesindeki katalog

Bölüm 1 AD CS’yi bir şablonun yanıtladığı dört soru olarak çerçeveliyordu: kim kaydolabilir, subject’i kim sağlar, sertifika ne için kullanılabilir ve bir kimliğe nasıl eşlenir. Bölüm 2 ve Bölüm 3 subject sağlama ailesini — yani tacın mücevherlerini — kapsadı. Bu bölüm kataloğun geri kalanını ele alıyor ve sonunda hepsini tek bir sıkılaştırma kontrol listesinde topluyor. Amaç, tek tek teknikleri ezberletmek değil; hangi hatanın hangi soruya karşılık geldiğini göstermek.

ESC2: “her şey” anlamına gelen bir EKU

ESC1 hangi EKU’yu taşıdığı için tehlikelidir. ESC2 ise hiçbir EKU taşımadığı ya da “Any Purpose” EKU’su taşıdığı için tehlikelidir. Böyle bir sertifika adeta açık çektir: Client Authentication için de, bir subordinate CA için de, talep edenin istediği her şey için de kullanılabilir. Onu bir -upn ile istediğinde, tıpkı bir ESC1 gibi Domain Admin sertifikasına dönüşür:

$ certipy-ad req -u [email protected] -p fr3edom -ca ESSOS-CA -template ESC2 \
    -upn [email protected] -target braavos.essos.local -dc-ip 192.168.56.12
[*] Successfully requested certificate
[*] Got certificate with UPN '[email protected]'

Düzeltme ESC1 ile aynıdır: any-purpose EKU’yu ve kayıt haklarını sök. Ama tanıma aşaması farklıdır, çünkü burada açıkça “yanlış” görünen bir yapılandırma yoktur; yalnızca sınırsız bırakılmış, fazla esnek bir şablon vardır. Çoğu denetimde gözden kaçan da tam olarak bu tür “fazla izin verici” ayarlardır. Bir şablonun yalnızca bariz biçimde yanlış görünmesini beklemek, denetimde en sık yapılan hatadır; asıl risk, doğru görünen ama sınırı olmayan yapılandırmadır.

ESC3: kayıt temsilcisi senin için tırmanır

Bir kayıt temsilcisi (Certificate Request Agent EKU’su), başka kullanıcılar adına sertifika kaydı yapabilen özel yetkili bir hesaptır. ESC3-CRA, bu EKU’yu herhangi bir Domain User’a verir. Önce temsilci olarak kaydolursun, sonra o sertifikayı daenerys.targaryen adına sertifika istemek için kullanırsın:

$ certipy-ad req -u [email protected] -p fr3edom -ca ESSOS-CA -template ESC3-CRA \
    -target braavos.essos.local -dc-ip 192.168.56.12
[*] Successfully requested certificate
[*] Got certificate with UPN '[email protected]'
[*] Saving certificate and private key to 'missandei.pfx'

Temsilci sertifikası basamak taşıdır; ondan daenerys adına yapılan bir istek onun sertifikasını üretir. ESC3, ESC1’in daha eski ve Kerberos gerektirmeyen kuzenidir. Hedef şablon doğrudan kaydolmayı engellediğinde ama bir temsilciye güvendiğinde önem kazanır; yani ESC1’in “kendi subject’ini seç” yolunu kapatmak tek başına yeterli değildir.

ESC9 ve kimlik eşleme ailesi

ESC1-8’in hepsi hangi sertifikayı aldığını değiştirir. ESC9 farklıdır: sertifika gerçektir ama NoSecurityExtension taşır — yani SID yoktur — bu yüzden KDC onu UPN ile eşlemeye geri düşer. Bir kullanıcının userPrincipalName değerini de değiştirebiliyorsan (bir GenericWrite yeterlidir), UPN’leri çakıştırır ve o kullanıcı olarak kimlik doğrularsın. Bu, Bölüm 2’deki ESC1 sertifikamızın “no object SID” ile çalışmasını sağlayan zayıf bağlama zayıflığının aynısıdır: bu lab’ın KDC’si güçlü bağlamayı zorunlu kılmaz. Yani sertifikanın gerçek olması tek başına güvenlik sağlamaz; önemli olan, sertifikanın hangi kimliğe bağlandığının sağlam biçimde doğrulanmasıdır.

Bu ailenin geri kalanı da aynı geri düşüş mekanizmasıyla ilgilidir. ESC11, ICPR (RPC) isteklerinde şifreleme gereksinimini kaldırır; ESC8 ise web enrollment’ı HTTP üzerinden açar. İkisi de taşıma düzeyindedir ve ikisi de relay vektörüdür: CA’ya doğru bir NTLM kimlik doğrulaması zorlar, ardından CA’nın kurban adına sertifika üretmesini sağlarsın. ESC15 ve ESC17, WebServer şablonundaki tarihsel kazalar sonucu ortaya çıkmış girdilerdir (schema-v1 EKU uyuşmazlığı ve server-auth subject sağlama). Bunların hiçbiri yeni bir fikir değildir; her biri kimlik eşlemesinin ya da taşımanın kötüye kullanılmasına izin veren farklı bir yoldur.

Relay ailesini (ESC8/ESC11) bu Kali kutusundan demo edemedim, çünkü lab alt ağına bridged değil routed bağlı; zorlanan bir makinenin benim dinleyicime dönüş yolu yok. Yapılandırma gerçektir (ESC8: Web Enrollment over HTTP, ESC11: encryption not enforced) ve Bölüm 1’de numaralandırılmıştır. İstismar ise saldırganın aynı L2 segmentinde olmasını gerektirir. Bu ayrımı belirtmek önemli: yapılandırmanın varlığını kanıtlamak ile onu ağ üzerinden sömürmek aynı şey değildir. Bir denetimde hangi kanıtı topladığını net söylemek, abartılı bir iddiadan her zaman daha değerlidir.

Kilitlemek: dört soru, yanıtlanmış

Bu serideki her ESC, Bölüm 1’in dört sorusundan birinin yanlış yanıtlanmasıdır. Yani iyileştirme, aynı dört soruya doğru yanıtları vermekten ibarettir:

Buna taşıma satırını da ekle: HTTP web enrollment’ı (ESC8) kapat, ICPR şifrelemesini zorunlu kıl (ESC11) ve — hepsinden önce — Enterprise CA sunucusunu nerede durursa dursun Tier 0 olarak ele al. Bir CA, sertifika üretebildiği her orman için fiilen kimlik kaynağıdır; bu yüzden onu sıradan bir uygulama sunucusu gibi değerlendirmek, tüm sertifika zincirini riske atmak demektir.

Seriyi kapatırken

Dört yazı, tek sonuç: bir sertifika bir kimlik bilgisidir ve bir şablon bayrağı bir saldırı yüzeyi kararıdır. Taksonomiden çok, kurduğu içgüdü önemlidir: EnrolleeSuppliesSubject: True, Any Purpose ya da User Specified SAN: Enabled gördüğün anda, hangi sorunun yanlış yanıtlandığını bildiğin için bir Domain Admin sertifikasının tek bir istek uzağında olduğunu da bilirsin. Bu, araçlar değişse bile işe yarayan kalıcı bir bakış açısıdır. Yeni bir ESC numarası duyduğunda paniğe kapılmak yerine tek bir soru sor: bu teknik dört sorudan hangisini atlıyor? Cevap genellikle iyileştirmeyi de beraberinde getirir.

Kanıt ve sınırlar

Kalan ESC şablonları (ESC2, ESC3, ESC8, ESC9, ESC11) izole GOAD laboratuvarındaki ESSOS-CA ve SEVENKINGDOMS-CA üzerinde numaralandırılmıştır. Ağ relay primitifleri (ESC8/ESC11) ise saldırı makinesi lab segmentine bridged değil routed bağlı olduğu için dört soruluk sıkılaştırma matrisiyle birlikte mimari düzeyde analiz edilmiştir. Yani bu tekniklerin yapılandırma kanıtı gerçek, ağ üzerinden sömürü kanıtı ise bu ortamın sınırları nedeniyle yoktur.

Referanslar

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• The Hacker Recipes, AD CS: thehacker.recipes/ad/movement/adcs
• SpecterOps, Certified Pre-Owned: posts.specterops.io
• Microsoft, AD CS Overview: learn.microsoft.com
• MITRE ATT&CK, Steal or Forge Authentication Certificates (T1649): attack.mitre.org/techniques/T1649