Servis Hesapları ve Service Principal Name

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.

Active Directory ortamında hesap kelimesi hem kullanıcılar (user) hem de bilgisayarlar (computer) için kullanılmaktadır. Yani bir servisi kullanıcı hesabı yönetebileceği gibi bilgisayar hesapları da yönetebilmektedir.

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.

{Service Name} / {Host FQDN or NETBIOS Name} / {Port} / {Instance Name}

  • MSSQLSVC/SQLSRV01.fslab.local:1433:instance
  • MSSQLSVC/SQLSRV01.fslab.local:1433
  • MSSQLSVC/SQLSRV01.fslab.local
  • MSSQLSVC/SQLSRV01

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

Servis Hesapları Üzerindeki Riskler

1. Kerberoasting

Kerberoasting TTP Card

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.

  • 1. Kullanıcı KDC servisinden servis biletini alırken herhangi bir yetkilendirme (authorization) kontrolü yapılmamaktadır. Bu nedenle domain ortamındaki herhangi bir kullanıcı erişim yetkisi olmasa dahi ilgili servise ait bileti KDC servisinden alabilmektedir. Yetkilendirme kontrolü kullanıcının servise eriştiği sırada yapılmakta, eğer servise erişim yetkisi bulunmuyorsa son aşamada red cevabı almaktadır.

  • 2. Kullanıcının KDC servisinden aldığı servis bileti o servisi yöneten yani o servise ait SPN’e sahip kullanıcının parola özeti (NTHash) ile şifrelenmektedir. Kullanıcı bu nedenle bu biletin içeriği okuyamamaktadır. Bilet, servisin koştuğu sunucuya iletildiğinde servis kullanıcısının parola özeti kullanılarak deşifre (decrypt) edilmekte ve içeriği kontrol edilmektedir.

Kerberos Protocol

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.

2. Parola Politikası

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.

3. Gereksiz/Geniş Yetkilendirme

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.

ServiceAccount Group Memberships

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

3. Tehlikeli/Şüpheli Access Control Entry Değerleri

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.

Domain Users Group ACL

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.

mssql.admin Suspicious ACL

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.

Attack Path

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

Group Managed Service Account

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.

KDS Root Key ve GMSA parolaları Windows Server 2012/R2 veya daha üstü işletim sistemine sahip Domain Controller sunucuları tarafından gerçekleştirilebilmektedir.
GMSA kurulumunda gerekli şema değişiklikleri için Active Directory şema versiyonunun minimum Windows Server 2012 olması gerekmektedir.
GMSA hesabı kullanılacak sunucuların işletim sistemi Windows Server 2012 ve üzeri veya Windows 8 ve üzeri olmalıdır. Ayrıca gerekli işlemlerin yapılabilmesi için bu sistemlerde Powershell ActiveDirectory modülünün yüklü olması gerekmektedir.

GMSA Hesabının Oluşturulması

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

Eğer daha önce KDS Root Key objesini oluşturduysanız tekrar oluşturmanıza gerek yoktur.
KDS Root Key objesini sadece ana (root) domainde oluşturmanız yeterlidir. Child domain üzerinde bu obje oluşturulamamaktadır.
Aşağıdaki Root Key oluşturma fonksiyonunu çalıştırdıktan sonra KDS Root Key objesinin Domain Controller arasında sağlıklı bir şekilde replike edilmesi için 10 saat beklenilmesi gerekmektedir.
Getkdsrootkey

Etki alanındaki KDS Root Key objesinin sorgulanması

Adddsrootkey

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.

Eğer bu şekilde bir grup oluşturup servis hesabının kullanılacağı sunucuları bu gruba eklerseniz grup üyeliğinin etkinleşebilmesi için sunucuları yeniden başlatmanız gerekmektedir.
GMSA Service Group

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.

AddServiceAccount

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

Komuttaki PrincipalsAllowedToRetrieveManagedPassword parametresine GMSA hesabının kullanılacağı sunucu isimleri veya bu sunucuların üye olduğu grup ismi verilmektedir. Parametre isminden de anlaşılacağı üzere bu sunucular GMSA hesabının parolasını okuma ve kullanma yetkisine sahip olmaktadır. Bu nedenle bu parametre doğru bir şekilde konfigüre edilmeli farklı hesapların bu parametreye yazılarak GMSA parolasını elde etmesine izin verilmemelidir. Ayrıca bu parametreye grup değeri verildiyse grup üyelerinin değişimi izlenmelidir.
GMSAinADUC

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.

InstallADServiceAccount

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

Logon as service

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

Alınması Gereken Önlemler

  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.

Referanslar

Share This Article, Secure Your Friends!