Active Directory Servis Hesaplarının Güvenliği

Servis hesapları Active Directory ortamındaki MSSQL, IIS, EXCHANGE, SAP vb. uygulamaların yönetilmesi ve Kerberos kimlik doğrulama protokolündeki servis biletlerinin (Service Ticket) oluşturulması ve doğrulanması için kullanılmaktadır. Servislerin sorunsuz çalışması için bu tip hesaplar çoğunlukla gerektirdiğinden fazla yetkilerle donatılmakta veya direkt bir yetkili grup (Administrators, Domain Admin vb.) içerisine alınmaktadır. Bu durum da bu hesaplarının Active Directory ortamındaki riskini ve etkisini oldukça arttırmaktadır.

Service Principal Name ise Active Directory ortamındaki servisleri tanımlamak için kullanılan isimlerdir. Bu isimler aynı etki alanı (domain) içerisinde benzersiz şekilde yapılandırılmaktadır. Her servise ait SPN değeri o servisi yöneten hesapla ilişkilendirilerek Kerberos protokolü sırasında kullanılmaktadır. Bu SPN değerleri atandıkları hesapların ServicePrincipalName değerinde (attribute) tutulmaktadır. Bu değerler Active Directory Users and Computers, ADExplorer veya Powershell ile görülebilmektedir. SPN değerleri aşağıdaki gibi farklı formatlarda olabilmektedir.

Active Directory ortamındaki SPN değerleri ve bu değerleri yöneten hesaplar aşağıdaki komutlar ile tespit edilebilmektedir.

Kerberoasting TTP Özet Kartı

Kerberos protokolünde kullanıcı bir servise erişmek için öncelikle KDC (Key Distribution Center)’den TGT (Ticket Granting Ticket) biletini daha sonra da bu bileti kullanarak yine KDC üzerinden erişmek istediği servise ait ST (Service Ticket) biletini almaktadır. Daha sonra bu biletle servisin koştuğu sunucuya istek yaparak servise erişim sağlamaktadır. Bu süreçte güvenlik açısından önemli iki nokta bulunmaktadır.

Kerberos Protokol Adımları

Saldırganlar bu iki noktadan faydalanarak Kerberoasting adlı saldırıyı gerçekleştirebilmektedirler. Bu saldırı için öncelikle herhangi bir domain kullanıcısı kullanılarak hedef servise ait bilet elde edilmektedir. Elde edilen bu bilet servis kullanıcısının parola özeti ile şifrelendiğinden bu bilete çevrimdışı parola kırma saldırısı (offline brute force) uygulanabilmektedir. Eğer parola gerekli uzunlukta belirlenmemişse parolanın açık (plain text) haline kolayca ulaşılabilmektedir. Elde edilen servis kullanıcısı parolası ile de domain ortamında yatayda veya dikeyde yayılım sağlanabilmektedir.

Hem az önce bahsettiğimiz Kerberoasting saldırısında, hem kaba kuvvet (Brute Force) hem de Password Spray saldırılarında hesapların parolalarının tahmin edilebilirliği en önemli noktalardan birisidir. Eğer servis kullanıcılılarının parolaları uzun/karmaşık olarak belirlenmezse ve belirli aralıklarla değiştirilmezse yüksek bir ihtimalle gerçek bir saldırı sırasında ele geçirilecektir.

Servis hesapları, uygulamaların çalışması sırasında herhangi bir sorunla karşılaşmamak adına çoğunlukla gerektiğinden fazla yetkilerle donatılmaktadırlar. Servis hesaplarına bu yetkilerin kolayca verilmesi için, hesaplar bir yönetici gruba (Administrators, Domain Admins vb.) veya sunucudaki yerel yönetici (Local Administrators) grubuna eklenmektedir. Eğer servis kullanıcıları bu şekilde yetkilendirilirse yukarıda belirtilen saldırılar sonucunda saldırgan kolayca yetkisini yükseltebilir ve tüm domain ortamını ele geçirebilir.

Aşağıdaki görselde de MSSQL servisini yöneten mssql.admin kullanıcısı hem Domain Admins grubuna hem de WS01 bilgisayarında Local Administrators grubuna eklenmiştir. Bu senaryoda saldırgan WS01 bilgisayarını ele geçirdiğinde kolayca Domain Admin yetkilerini de ele geçirmiş olacaktır.

mssql.admin kullanıcısının Domain Admin ve Local Administrators grup üyelikleri

Access Control Entry değerleri, Active Directory ortamındaki objeler üzerindeki erişim yetkilerini, yani hangi objenin hangi objeye hangi detayda erişebileceğini kontrol etmek üzere detaylı olarak tasarlanmış güvenlik mekanizmasıdır. Bu şekilde detaylı tasarlanması nedeniyle yönetilmesi çok zor, saldırganlar tarafından hedef alınması ise bir o kadar kolaydır. Servis hesapları yetkili gruplarda bulunmasa bile yanlış ACE tanımlamaları ile admin yetkilerine erişebilir veya tam tersi bir şekilde yetkisiz kullanıcılar servis hesapları üzerinde etki oluşturulabilmektedir. Saldırganlar da bu tip yanlış yapılandırılmış ACE değerlerini kullanarak veya kendileri arka kapı oluşturmak amacıyla ACE değerleri oluşturarak domain ortamını ele geçirebilir ve ortamda kalıcılık sağlayabilirler.

Örneğin, aşağıdaki görselde mssql.admin kullanıcısı üzerinde yapılan bir değişiklik ile Domain Users grubundaki tüm kullanıcılara bu hesabın parola resetleme (Reset Password) yetkisi verilmiştir.

mssql.admin üzerindeki Reset Password ACE değişikliği

Aşağıdaki görselde de benzer şekilde, mssql.admin kullanıcısına yetkili bir kullanıcı olan furkan.ozer‘in sahipliğini değiştirme (Modify Owner) yetkisi verilmiştir. Bu yetki ile de objenin sahibi değiştirilerek obje üzerinde istenen değişiklikler yapılabilmektedir.

furkan.ozer kullanıcısı üzerinde Modify Owner ACE değişikliği

Son olarak aşağıdaki arayüzde yanlış yapılandırılan Access Control Entry değerleri nedeniyle oluşan saldırı yolu (Attack Path) görülebilmektedir.

ACE değişiklikleri ile Domain Users grubundan furkan.ozer kullanıcısına oluşan saldırı yolu

Managed Service Account (MSA) Windows Server 2008 R2 ile Group Managed Service Account (GMSA) ise Windows Server 2012 R2 sürümü ile duyurulan ve servis hesaplarının yönetimini, parola değişimini otomatize hale getiren objelerdir. GMSA, MSA’dan farklı olarak birden fazla sunuculu (cluster) yapılarda da kullanılabilmektedir. Bu makalede de daha güncel olduğundan GMSA hesabının yapılandırılması anlatılacaktır.

• GMSA hesabının parolası KDC tarafından 120 karakter uzunluğunda belirlenmekte ve 30 günde bir otomatize olarak güncellenmektedir. Bu güncelleme sırasında sunucu tarafında hiçbir manuel işleme gerek kalmamaktadır.
• GMSA parolaları otomatize bir şekilde belirlendiğinden ortamdaki Parola Politikası’ndan (Password Policy) ve Fine Grained Password Politikaları’ndan etkilenmezler.
• Ayrıca GMSA hesaplarının normal servis hesaplarındaki gibi Interactive Logon yetkileri bulunmamakta ve özel olarak atanmadıkça yüksek yetkiye de sahip değildirler. Fakat bu hesaplar da farklı riskler barındırmaktadır, bu riskleri de farklı bir makalede ele alacağız.
• GMSA hesapları servisler dışında zamanlanmış görevlerde de kullanılabilmektedir. Fakat zamanlanmış görevlerde kullanım için GMSA hesabına Logon as batch job yetkisinin verilmesi gerekmektedir.

GMSA hesabı oluşturmak için çoğunlukla Powershell ve ActiveDirectory modülü kullanılmaktadır. Fakat bu yöntemin yanı sıra CJWDEV firmasına ait Managed Service Accounts GUI uygulaması ile de bu işlemler gerçekleştirilebilir.

GMSA oluşturabilmek için öncelikle KDS Root Key oluşturulması gerekmektedir. Bu anahtarın bir domain ortamında bir kez oluşturulması yeterlidir.

Etki alanındaki KDS Root Key objesinin sorgulanması

Etki alanında KDS Root Key objesinin oluşturulması

GMSA hesaplarının kullanılacağı sunucuları daha kolay ve dinamik bir şekilde yönetmek için hesapların kullanılacağı bilgisayarlar bir grup altında toplanabilirler. Bu sayede GMSA objesi üzerinde herhangi bir değişiklik yapmadan gruba ekleme çıkarma yapılarak servisler yönetilebilmektedir. Fakat bu işlem önerilse de GMSA kullanımı için zorunlu değildir.

GMSA hesabının kullanılacağı bilgisayarlar için oluşturulan grup

Bu işlemler tamamlandıktan sonra aşağıdaki komutlar kullanılarak GMSA hesabı oluşturulabilmektedir.

GMSA hesabının Powershell ActiveDirectory modülü kullanılarak oluşturulması

GMSA oluşturulduktan sonra Active Directory Users and Computers uygulaması arayüzünden görülebilmektedir.

GMSA hesabı oluşturulduktan sonra servisin koştuğu sunucuda oturum açılır ve aşağıdaki komutlar çalıştırılır.

GMSA hesabının servisin koştuğu sunucu üzerine kurulması

GMSA hesabı serviste kullanılırken parola girilmesine gerek kalmamaktadır.

1. SPN’e sahip servis hesapları tespit edilmeli ve dokümante edilmelidir. Bu işlem referanslardaki Find-ServiceAccounts.ps1 betiği ile gerçekleştirilebilmektedir.
2. Bunun yanı sıra sunucularda manuel olarak kullanılan servis hesapları referanslardaki Find-LocalServiceAccounts.ps1 betiği ile tespit edilmeli ve dokümante edilmelidir.
3. Tespit edilen tüm servis hesapları çalışan servisin önemine göre önceliklendirilmeli ve sırayla uygun olan servisler için GMSA hesapları oluşturulmalıdır.
4. Oluşturulan hesaplar gerekli servislere atandıktan sonra eski servis hesapları öncelikle üye ise yetkili gruplardan çıkarılmalı daha sonra da disable edilmeli veya silinmelidir.
5. Eğer servis hesapları yerine GMSA kullanılamıyorsa;
   a. Öncelikle servis hesabının üye olduğu gruplar incelenmeli ve hesap yönetici gruplardan çıkarılmalıdır. Hesaba servisin ihtiyacı olan en az yetkiler verilmelidir.
   b. Bu tip servis hesapları için Fine Grained Password Policy kullanılarak özel politikalar oluşturulmalı ve uzun/karmaşık parolalar belirlenmelidir.
   c. Servis hesabı üzerindeki Access Control Entry’ler incelenerek bu hesap üzerinde etki yapabilecek farklı bir objenin oluşması engellenmelidir.
   d. Servis hesabı için Active Directory ortamındaki diğer objelere tanımlanmış Access Control Entry’ler incelenmeli ve gereksiz girdiler silinmelidir.

• https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
• https://azurecloudai.blog/2020/04/15/create-a-group-managed-service-account-gmsa/
• https://gitlab.com/forestallio/manage-serviceaccount/-/blob/master/Find-ServiceAccounts.ps1
• https://gitlab.com/forestallio/manage-serviceaccount/-/blob/master/Find-LocalServiceAccounts.ps1