Bugün Kerberos Authentication hakkında konuşacağız. Kerberos Yunan mitolojisinde 3 başlı bekçi köpeği anlamına gelmektedir ve bu authetication sistemi de adını bununla ilişkili olarak almıştır. Kerberos'un çalışma sistemi sayesinde, WAN'da yani saldırıya açık olan bir networkte, bir servera login olurken passwordumuzu cleartext ya da kriptolu olarak aktarmamıza gerek yoktur. Bu da ilk aşamada passwordumuzu riske atmayacağımız anlamına geliyor. Kerberos sayesinde userın, passwordunu güvenli olmayan network aracılığıyla, remote servera giriş yapmasına gerek yoktur. Aracı bir server ile bu erişim daha güvenli bir şekilde ticketlar sayesinde sağlanabilir.
Peki Kerberos Nasıl Çalışır ?
1-> Client -> AS
İlk olarak user kendi bilgisayarına login olduktan sonra bir (AS-REQ) paketi otomatik olarak yola çıkar. Bu paket, KDC'ye yani Key Distribution Center'a doğru gönderilir.
KDC, Ticket ve key dağıtım merkezi olarak düşünülebilir. Genelde Domain Controller'ın içerisindedir. "Authentication Service" ve "Ticket Granting Service" dan oluşmaktadır.
User login olduktan sonra gönderilen AS-REQ paketi, username, erişilmek istenen service, Client'ın IP Adresi ve istenilen Ticket'ın geçerlilik süresi ile ilgili bilgileri içerir.
Principal Client: Bağlanmak isteyen Asim userının asim@yildiz.com şeklindeki halidir.
Principal Service: Bağlanılmak istenilen server ve service bilgisidir. FTP/ftp.abc.com@abc.com
IP_list: Clientın IP Adresidir.
Lifetime: Ticket Granting Ticket'ın ne kadar süre geçerli olması istendiğini gösteren kısımdır.
AS-REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )
AS-REQ kriptosuz şekilde gönderilir.
2-> AS -> ClientAS-REQ KDC'nin içerisindeki Authentication Service a ulaştı. Paketin içerisindeki "time stamp" kontrol edildi ve default geçerlilik süresi 5 dakika olan bu isteğin
hala geçerli olup olmadığı kontrol edildi. Geçerli ise süreç devam edecektir değil ise sonlandırılacaktır. AS ve Client ın zamanı senkron olmalıdır. Yani aynı
NTP (Network Time Protocol) Server tarafından, Client ve KDC'nin bilgisayar saat ve tarihini çekiyor olması en sağlıklısıdır.
AS, Client tarafından gönderilen paketi inceledikten sonra bu bilgileri de kullanarak bir ticket oluşturacaktır.
Bu ticket ın adı Ticket Granting Ticket dır. İçerisinde Client User bilgisi,Client IP Adres bilgisi, Lifetime, Session Key(!) gibi bilgiler bulunmaktadır. Aşağıdaki
şekilde TGT paket içeriğini görebilirsiniz. TGT, "KRBTGT" user ının password hash i kullanılarak kriptolanır. KRBTGT user ı DC tarafından otomatik olarak oluşturulan
bir user dır. Password u admin tarafından değiştirilmediği sürece aynı kalır ve gizliliği yüksek derecede önem arz eder. DC database inde passwordleri hashli şekilde tutar.
"Principal Service","Timestamp","Lifetime" ve "Session Key" , Client a login olan user ın password hash iyle kriptolanarak gönderilir.
Yani AS tarafından Clienta gönderilen AS-REP şu şekildedir;
AS_REP = { PrincipalService , Timestamp , Lifetime , SessionKeyTGS }UserPasswordHashKey
{ TGT }KRBTGTPasswordKeyHash
3->Client -> TGSClient, AS tarafından gönderilen paketteki TGT'yi dekript edemediği için kriptolu şekilde cash ine atar. Daha sonra kendi user hash ini kullanarak
"Principal Service","Timestamp","Lifetime" ve "Session Key" datalarının bulunduğu kısmı dekript eder.(Symmetric Encryption)
Timestamp değerini kontrol ederek gelen paketin geçerli zaman aralığında gelip gelmediğini kontrol eder. Aynı zamanda timestamp bilgisini
okuyabilmesi gönderici olan AS in legal ve görüşmek istediği server olduğunun kanıtı mahiyetindedir.
Client AS'den aldığı TGT'yi ve bir "authenticator" ile Principal Service ve LifeTime bilgisini TGS'e gönderir.
Authenticator, "Principal Client" ve "Time Stamp" in AS tarafından alınan session key ile kriptolanması sonucu oluşturulan pakettir.
TGS'e gönderilen paket şu şekildedir;
Authenticator = { PrincipalClient , Timestamp }SessionKeyTGS
TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }KRBTGTKey
4->TGS -> ClientTGS, Client tarafından gönderilen paketi aldıktan sonra KRBTGT userının password hashiyle TGT'nin içerisini açar. TGT'nin içerisindeki session key i
çıkarttıktan sonra bu session key ile Authenticator ı açar ve "time stamp" i kontrol ederek TGT'nin hala geçerli olup olmadığını kontrol eder. Daha sonra authenticator
içerisindeki Client Principal ile TGT içerisindeki Client Principal ın birbiriyle eşleşip eşleşmediğini kontrol eder.
Buraya kadar her şey yolundaysa TGS, "service ticket" üretebilir.
Client ile bu Clientın erişmek istediği Server arasındaki güven ilişkisini kuracak olan aracı paket "Service Tickettır". İçerisinde "Service Principal",
"User Principal", "Client IP","time stamp","lifetime(TGT içerisindeki Lifetime)","TGS Session Key" bulunur.
ServiceTicket = ( PrincipalClient , PrincipalService , IP_list , Timestamp , Lifetime , SessionKeyService )
Daha sonra TGS-Reply paketi hazırlanabilir. Bu paketin "Service Ticket" kısmı tamamdır ve Client ın erişmek istediği Server ın, Computer Account passwordunun
hashiyle kriptolandıktan sonra TGS-REP paketinin içerisine yerleştirilmiştir. Sırada TGS-REP paketinin geri kalanını oluşturabiliriz;
"Principal Service","time stamp","Liftime","Service Session Key" TGS-REP paketinin geri kalanıdır ve daha önce Client tarafında kullanılan
"TGS Session Key" ile kriptolanmıştır. TGS-REP paketi aşağıdaki gibidir;
TGS-REP = { PrincipalService , Timestamp , Lifetime , Service Session Key}SessionKeyTGS { ServiceTicket }ServerComputerAccountPassHashKey
TGS-REP paketi artık Clienta gönderilebilir.
5->Client -> ServerClient, TGS Session Key ile kriptolanmış kısmı aynı sesion key e sahip olduğu için dekript etti ve "Service Session Key" i kaydetti ve Service Ticket'ı da
kriptolu şekilde (çünkü dekript edecek key e sahip değildir)cache ine attıktan sonra AP-REQ paketini hazırlamaya başladı. AP-REQ Paketi Servera login olmak
isteyeceği ve Server ile authentication ın yapılacağı kısımdır. İlk olarak bir Authenticator oluşturulacaktır. Authenticator "Service Principal" ve "time stamp"
içerir. "Service Principal" ve "time stamp" TGS'den alınan SessionKeyService ile kriptolanarak Authenticator oluşturulmuş oldu.
Authenticator = { PrincipalClient , Timestamp }SessionKeyService
Daha sonra TGS'den alınmış olan Service Ticket ve Authenticator birleştirilerek APP-REQ oluşturulmultur.
AP-REQ = Authenticator { Service Ticket } ServerComputerAccountPassHashKey
6->Server -> ClientServer AP-REQ paketini aldığı zaman "Service Ticket" ı açar ve içerisindeki "Service Session Key" i çıkartır. Daha sonra bu Session Key ile Authenticator ı
dekript eder ve "time stamp" bilgisini okur. Eğer geçerli ise yani "Service Ticket" ın içerisindeki "time stamp" ile Authenticator ın içerisindeki uyumlu ise
Client ın erişimi Server tarafından onaylanır.
Özetlemek gerekirse;
Bir Client, bir Server'a güvensiz bir networkten erişmek için, kendisinin key bilgisine sahip başka bir onay sunucusuna ihtiyaç duyar.Buna KDC deriz ve genellikle Domain Controller ın içerisine gömülü şekildedir. Client bir AS-REQ paketi hazırlar ve içerisinde erişmek istediği service,
erişmek isteyen user (Client makinesine login olan kişi), Client IP Adresi ve ne kadar süre geçerli bir Ticket istediğini, KDC içerisindeki AS'e kriptolamadan yollar.
AS, TGT şeklinde bir ticket hazırlar ve bunu DC'de default olarak bulunan KRBTGT user ının password hashiyle kriptolar. TGT içerisinde Principal Client,
Principal Service, Lifetime, TimeStamp, Client IP ve TGS Session Key'i içerir. "Principal Service","TimeStamp","LifeTime" ve TGS tarafından üretilen
"Session Key" dörtlüsü Client user ının passord hashiyle kriptolanır ve kriptolu TGT ile birleştirilerek AS-Reply paketi oluşturulmuştur, Client a gönderilir.
Client AS-REP'i dekript eder(TGT Hariç) ve "TimeStamp" ini kontrol eder. TimeStamp geçerli ise Kriptolu TGT'yi cachine atar. Client "Principal Client" ve "TimeStamp"
i AS'den almış olduğu TGS Session Key ile kriptolar(authenticator oluşturdu), kriptolu TGT'yi de bu Authenticator a ekledikten sonra KDC'nin içerisindeki TGS'e
gönderir. TGS, TGT'yi dekript eder ve TGS Session Key'i çıkartır daha sonra Authenticator ı dekript ederek timestamp değerini kontrol eder. Eğer geçerli ise
"Service Ticket" oluşturur. "Principal Client","Principal Service","LifeTime","Service Ticket,"TimeStamp","Client IP" ve "Service Session Key" in bilgilerini
içeren bir "Service Ticket" oluşmuştur. "Service Ticket" erişilmek istenen Server ın Computer Account password hashiyle kriptolandıktan sonra
"Principal Client","TimeStamp","LifeTime" ve "Service Session Key" bilgileride TGS Session Key ile kriptolanarak, tek parça şeklinde Client a gönderilir.
Client TGS Session Key ile ikinci kısmı dekript ederek "Service Session Key" i çıkarttı. Şimdi bu session key ile kriptolaycağı bir authenticator oluşturacaktır.
Authenticator "TimeStamp" ve "Principal Service" bilgisini içerir. "Authenticator" ve "Kriptolu Service Ticket" , APP-REP adı altında Server'a gönderilir.
Server, computer account password hashiyle "Service Ticket" ı açar ve içerisindeki "Service Session Key" i çıkartarak Authenticator ı dekript eder.
Authenticator içerisindeki "TimeStamp" geçerli ise login işlemi için onay verilir.
Sistem ile ilgili bir takım çıkarımlar yapalım. Bir Domain deki TGT üretmeye yetkili kişi tüm izinleri veren kişidir denilebilir. Çünkü geçerli bir TGT ye
sahip bir client, TGS den Server a erişmek için kullanacağı Ticket ı isteyebiliyor. TGT kriptolu aktarıldığı için sistem güvenli ve sadece kripto edebilen
DC sistemin güvenli çalışmasını sağlıyor. Ancak bir şekilde TGT'yi kriptolamak için kullanılan "KRBTGT" user ının password hash i çalınırsa, çalan kişi
istediği Server a login olabilecektir. Bir kişinin TGT yi kriptolayan password hash ini çalabilmesi için DC'ye bir şekilde login olması gerekir.
Bu durumda ilk hedef "Domain Admin" olan bir user ın passwordunu çalmak ya da bir şekilde kullandığı bilgisayara erişim sağlamaktır.
Yetkili bir User ın makinesine bir şekilde login olan saldırgan kullanıcının bütün hashlerini çalar. Hash konusunu biraz açmak gerekirse bilgisayarlar bir yere login olurken passwordleri hash e dönüştürülerek gönderilir ve aynı zamanda bilgisayarlar
passwordlerini lokallerinde hash li olarak tutarlar. Ayrıcalıklı bir user ın Password Hash i elde edilirse, bu user ın giriş izni olan server lara, saldırgan da
girebilir.Bu atak "Pass the Hash" atak olarak adlandırılır. O zaman bir hacker, Domain Admin olan bir kişinin password hashini çaldıktan sonra Active Directory'e
login olabilir. Kişi AD ye login olduktan sonra Hash Havuzunu tamamını çekerek KRBTGT password hashini de çalar. Günün sonunda hacker istediği TGT'yi oluşturacaktır
ve bu TGT da belirtmiş olduğu Client ile dilediği server a erişecektir. İşte bu oluşturulan LifeTime uzun süreli (10 yıl) olan ticketlara Golden Ticket denir.
Golden Ticket sayesinde hacker ağda farkedilmeden istediği makineye login olabilecektir.
Kerberos ile ilgili yazımız bu kadar. Bir başka yazı da görüşmek üzere...
Elinize sağlık hocam, çok güzel anlatmışsınız.
YanıtlaSil