Sıfırdan Zirveye: AD ESC Zafiyetini Anlamak
- İbrahim Mert COŞKUN
- Dec 5
- 5 min read
Selamlar. Son zamanlarda yerel ağ testlerinde oldukça sık karşılaştığım bir zafiyetten bahsedeceğim. Bu zafiyet ile kısa sürede DC Admin hesabı ele geçirilse de aslında işin arka planını öğrenmek ve ilerlemek sektörel bir zorunluluk haline gelmiş bulunuyor. Bundan dolayı bu yazımda hem zafiyetin teknik analizini hem de örnek olarak nasıl sömürüldüğünü anlatan bir yazı olacak. Ancak şunu da belirtmekte fayda var: AD ESC zafiyeti aslında bir zincirleme durumu. Bu serinin ilk yazısı olduğu için bu aşamada "AD ESC1" zafiyetini anlatacağım. İlerleyen serilerde aynı kök nedenden kaynaklanan ama hem ismi hem de sömürülmesi farklı olan sertifika zafiyetlerinden bahsedeceğim.
Bir Sertifika Meselesi:
Active Directory Certificate Services (AD CS) saldırıları, son yıllarda sızma testlerinin ve Red Team operasyonlarının vazgeçilmezi haline geldi. SpecterOps'un "Certified Pre-Owned" araştırmasıyla popülerleşen bu saldırı vektörleri arasında, şüphesiz en yıkıcı ve en doğrudan olanı ESC1'dir. Bu yazıda, ESC1 zafiyetinin teknik anatomisini inceleyecek, neden kaynaklandığını anlayacak ve canlı bir laboratuvar ortamında adım adım nasıl sömürüldüğünü (PoC) göreceğiz.
Active Directory ortamlarındaki Yetki Yükseltme (Escalation of Privilege - ESC) zafiyetlerinin temelinde, genellikle Active Directory Sertifika Hizmetleri (AD CS) altyapısının yanlış yapılandırılması yatmaktadır. Bu zafiyetler, basitçe ifade etmek gerekirse, bir düşük yetkili kullanıcının veya makinenin, kendisi için tasarlanmamış bir sertifika şablonunu kullanarak yüksek yetkili bir kullanıcı (genellikle bir Hizmet Hesabı veya Yönetici) kimliğine bürünmesini sağlayan taktiksel bir saldırı zinciridir.
Sertifika Mekanizması ve Yanlış Yapılandırmanın Anatomisi:
Temelde, AD CS altyapısı bir Sertifika Yetkilisi (Certificate Authority - CA) olarak çalışır ve ağdaki kullanıcılar, makineler veya hizmetler için X.509 dijital sertifikaları düzenler. Bu sertifikalar, kimlik doğrulama, şifreleme ve dijital imzalama gibi kritik güvenlik işlevleri için kullanılır. Bu sürecin kalbi, sertifikaların hangi amaçlarla ve hangi koşullar altında verileceğini tanımlayan sertifika şablonlarıdır (Certificate Templates).
Sertifika Meselesinin Çalışma Şekli:
Bir kullanıcı (talep sahibi), CA'dan sertifika talep ettiğinde, bu talep belirli bir şablonu işaret eder.
CA, öncelikle talep sahibinin o şablonu kullanma iznine (enroll permission) sahip olup olmadığını kontrol eder.
Eğer izin varsa, CA şablonun kurallarını uygular. Bu kurallar arasında sertifikanın Kullanım Amacı (Extended Key Usage - EKU) yer alır. Örneğin, bir şablonun EKU'su İstemci Kimlik Doğrulama (Client Authentication) veya Akıllı Kart Oturum Açma (Smart Card Logon) olarak belirtilmiş olabilir. Bu, sertifikanın Active Directory'de kimlik doğrulaması için kullanılabileceği anlamına gelir.
CA, talep sahibinin kimliğini (örneğin Service Principal Name - SPN veya User Principal Name - UPN) içeren bir sertifikayı imzalar ve talep sahibine verir.
Neyin Yanlış Yapıldığı (Zafiyetin Doğuşu):
ESC zafiyetleri, işte bu sertifika şablonlarının ve CA üzerindeki erişim kontrol listelerinin (ACL'ler) yanlış yapılandırılmasından doğar.
Zayıf Talep İzni (Enroll Permission): En yaygın hata, genellikle daha az yetkili kullanıcı gruplarının (örneğin "Domain Users") Akıllı Kart Oturum Açma veya İstemci Kimlik Doğrulama gibi kritik EKU'lara sahip şablonlar için Talep Etme (Enroll) iznine sahip olmasıdır. Saldırgan, bu izni kullanarak kendi adına bir sertifika oluşturabilir.
Zayıf Kontrol Mekanizmaları: Sertifika şablonunun, talep sahibinin sertifika üzerindeki Konu Alternatif Adı (Subject Alternative Name - SAN) alanını belirlemesine izin vermesi (örneğin, şablonun
veya SAN bayrağının etkin olması) en tehlikeli durumdur. Talep sahibi (saldırgan), bu alanı kötüye kullanarak sertifikayı Domain Admin gibi yüksek yetkili bir hesabın kimliğiyle eşleştirebilir. Normalde, CA'nın sertifikayı basmadan önce bu alanın geçerliliğini sıkıca kontrol etmesi gerekir, ancak yanlış yapılandırılmış şablonlar bu kontrolü atlar.
Yüksek Yetkili Şablonlarda Gereken Düşük Güvenlikli EKU'lar: Bir saldırganın sertifika talebini yapabilmek için yalnızca bir düşük yetkili sertifikaya (örneğin yalnızca kimlik doğrulaması için kullanılan bir sertifika) ihtiyaç duymasına rağmen, bu düşük yetkili sertifika ile yüksek yetkili bir hesap kimliğine bürünmesini sağlayan bir şablonu talep edebilmesi.
Taktiksel Analiz:
Saldırgan, yanlış yapılandırılmış bu şablonları tespit ettikten sonra, kendi düşük yetkili hesabı adına, ancak sertifikanın SAN alanını hedeflediği yüksek yetkili hesabın UPN'si (Kullanıcı Asıl Adı) ile doldurarak bir sertifika talep etmektedi. CA, yanlış yapılandırma nedeniyle bu talebi kabul eder ve sertifikayı basar. Saldırgan, bu yeni sertifikayı kullanarak, Windows'un Kerberos kimlik doğrulama protokolünün sertifika tabanlı oturum açma mekanizması olan PKINIT'i kullanarak kendini yüksek yetkili hesap olarak tanıtıp Domain Controller'a erişim sağlayabilir ve böylece Etki Alanı Yönetimi (Domain Administrator) yetkilerini ele geçirebilir.
Toparlamak gerekirse aslında zafiyet şu 3 nedenden dolayı kaynaklanmaktadır. Bir şablonun ESC1 olabilmesi için şu 3 ayarın aynı anda yapılmış olması gerekir:
Client Authentication (İstemci Kimlik Doğrulaması): Sertifikanın sadece şifreleme için değil, giriş yapmak (logon) için kullanılabilir olması gerekir. (Extended Key Usage - EKU).
Enrollee Supplies Subject (Başvuran Konuyu Belirler): İşte en kritik ayar budur (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). Bu bayrak, sertifikayı isteyen kişinin (senin), sertifikanın kime ait olacağını (SAN - Subject Alternative Name) belirlemesine izin verir.
Düşük Yetkili Erişim İzni: "Domain Users" veya "Authenticated Users" grubunun bu şablondan sertifika talep etme (Enroll) hakkının olması.
Saldırıyı gerçekleştirmeye çalışırken sürekli olarak takıldığım ve yanlış yorumladığım için bazı noktalarda tıkanıyordum. Örnekler ve araştırmalar yaparak aslında bu süreci daha kolay hale getirdim. Tabii bu ezbere bir bilgi olmamalı ondan dolayı saldırıya geçmeden önce sıkça sorulan teknik detayları netleştirelim;
Certipy Çıktılarında Neyi Aramalıyız?
Keşif aşamasında Certipy aracı kullanıldığında, JSON veya text çıktısında şu kombinasyonu ararız:
Enrollee Supplies Subject: True
Extended Key Usage: Client Authentication (Veya Smart Card Logon vb.)
Enrollment Rights: DOMAIN\Domain Users
Kullanıcı ve UPN Detayı. Bu kısım benim saldırıda kafamı en çok karıştıran kısımdı. "Hangi kullanıcı ile saldırıyoruz?"
Saldırıyı başlatmak için herhangi bir düşük yetkili (Low-Priv) kullanıcı hesabı yeterlidir. Ele geçirdiğiniz basit bir domain kullanıcısı ile CA'ya "Authenticate" olursunuz.
Kısaca UPN gereklimi? Cevap evet. UPN (User Principal Name) Saldırı komutundaki -upn parametresi, olmak istediğiniz kişiyi belirtir. Yani Bob kullanıcısı ile giriş yapıp, -upn administrator@domain.local diyerek Administrator sertifikası talep edilebilir.
Bu ne anlama gelir? Bu değer aktifse, CA sunucusu kullanıcıya şunu der: "Senin kim olduğunla ilgilenmiyorum; bana sertifikanın kime ait olmasını istiyorsan (SAN - Subject Alternative Name), onu söylemen yeterli." Bu durumda, sıradan bir kullanıcı (örn: lowpriv_user), sertifika talep ederken "Bu sertifikayı Administrator için istiyorum" derse, CA sunucusu bunu sorgusuz sualsiz kabul eder.
En Sevdiğimiz Kısım: Let The Hunt Begin
Klasik hem template bulma hemde exploit aşamasında aşağıdaki tool'u kullanıyoruz:
Öncelikle elimizde bir AD kullanıcısı bilgileri olmalı. Bu durumda bulunduğumuz ağdan aynı zamanda CA sunucusuna da erişmemiz gerekmektedir. Daha inografik olması açısından komutları görsel olarak ilerliyorum
AD kullanıcımızın olduğunu varsayarak elimizdeki bilgiler ile etki alanındaki (Domain) hatalı yapılandırılmış sertifika şablonlarını arıyoruz. Sonucunda oluşturduğu dosyaya bi bakalım.
Bu noktada dikkat etmemiz gerekenler şunlardır:
Certipy çıktısı, auth adlı bir şablonun sömürülebilir olduğunu gösterir
Enrollee Supplies Subject: True. (Saldırganın, sertifikanın kime ait olacağını belirlemesine izin verilir.)
Client Authentication: True. (Sertifika ile Windows oturumu açma yetkisi verir.)
Requires Manager Approval: False. (Onay süreci otomatik olduğu için anında sömürü mümkündür.)
Enrollment Rights: ACME.LOCAL\Domain Users ve ACME.LOCAL\Authenticated Users. (Düşük yetkili hesapların kayıt hakkı vardır.)
Sömürü ve Sertifika Alma (Exploitation):
Saldırgan, bulduğu ESC1 zafiyetini kullanarak, kendi düşük yetkili hesabı üzerinden Administrator adına sertifika talep eder.
-template auth: Sömürülen şablon adı.
-upn Administrator@acme.local: Kimliğine bürünülen hedef (Domain Admin).
Sonuç: [+] Got certificate with UPN 'Administrator@acme.local' ve [+] Saved certificate and private key to 'administrator.pfx'. (Administrator kimliği ile sertifika başarıyla elde edilmiştir.)
Elde edilen .pfx dosyası, yönetici kimliğiyle Active Directory kaynaklarına erişim sağlamak için kullanılır. Sertifika, Kerberos oturumu açmak ve Administrator'ın NTLM hash'ini çekmek için kullanılır.
Certipy, .pfx dosyasını kullanarak Administrator adına geçerli bir Kerberos TGT'si alır ve bu TGT ile Administrator'ın NTLM hash'ini başarıyla çeker.
Buradan sonra yapmamız gerek tek şey .pfx dosyası ile doğrulamayı sağlamak olacaktır.
Bu saatten sonra DC'de erişim sahibiyiz. İster kullanıcı açın ve DC grubuna ekleyin ister impacket-secretdump kullanarak raporunuzu zenginleştirin. Bu saatten sonra süreç hayal gücünüze kalmış.
Sonuç:
Eğer elinizde bir AD kullanıcısı var ise kısa sürede DC admin hesabını ele geçirebileceğiniz güzel bir senaryo. Yetkili bir UPN ismi bulmak ise test sürecindeki ilerleme şeklinize göre değişmektedir. İster farklı kanallardan ele geçirirsiniz isterseniz de mitm6 saldırısı yaparak domain dump yaparsınız ve oradaki "Domain Admins" grubuna bağlı hesapları kullanarak sertifika talep edebilirsiniz. Yararlı olması dileğiyle.
Comments