Kerberos Nedir ? Kerberos'un Zaafiyeti Kullanılarak Yapılabilecek Ataklar Nelerdir ?

Merhaba Arkadaşlar,

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 -> Client

AS-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.

AS, Clienta Kriptolanmış TGT'yi ve bunun yanında da "Principal Service","Timestamp","Lifetime" ve "Session Key" i gönderir.
"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 -> TGS

Client, 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 -> Client

 TGS, 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 -> Server

Client, 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 -> Client

Server 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...

HTTPS Nasıl Çalışır ?

HTTPS - Nedir ? Nasıl Çalışır ?

Merhaba Arkadaşlar,
Geçtiğimiz günlerde birkaç Offensive Security ile ilgilenen arkadaş ile yapmış olduğum HTTPS üzerine bir sohbet üzerine ve HTTPS'in aslında çok yanlış anlaşıldığını farketmemle birlikte yazının konusu belli oldu.

Öncelikle birkaç temel terimden bahsedelim daha sonra HTTPS hakkında bilgi vermeye çalışalım.

Hash Algorithm: Security terimi olan Hash Algortihm'in temel amacı "Integrity" i sağlamaktır. Yani benim elimde bir 10 Bbyte lık bir data var.
Bu datayı istemciye göndermeden önce bir Hash Algoritmasına(MD5, SHA1 vb.) sokuyorum ve bana bir değer üretiyor. Üretilen değer 128 bitlik bir hash değeri.
Bu 128 Bitlik Hash(1) değerini datanın sonuna ekledikten sonra [Data+Hash(1)] şeklinde istemciye gönderiyorum. Daha sonra istemci Datayı aynı Hash Algoritmasına
sokuyor ve çıkan Hash(2) değeri ile göndericinin göndermiş olduğu Hash(1) değerini kıyaslıyor. Kullanılan Hash Algoritmaları evrensel olduğu için aynı data için
üretmiş olduğu değer dünyanın her yerinde aynıdır ve işin daha da güzel tarafı eğer data içerisindeki 1 bit bile değişirse (Bit 1 iken 0 ya da 0 iken 1 olursa)
çıkan Hash değeri bambaşka bir hal alır, baştan aşağıya değişir. Sonuç olarak kıyaslanan Hash(1) ve Hash(2) aynı ise data bolzulmadan ya da bir saldırgan tarafından
değiştilmeden gelmiştir. Data güvenilirdir.

Symmetric Key Algorithm: Symmetric Key Algorithm gönderilen Datanın tek bir anahtar ile kriptolandığı ve sadece aynı anahtar tarafından dekript edildiği algoritmadır. DES, 3DES, AES vb.
bu kriptolama algoritmalarına örnektir. Temel amacı "Confidentiality" i sağlamaktır. Bu kritolamayı yapan anahtar "Secret Key" olarak isimlendirilir ve gönderici
ile istemci arasında data transferi öncesinde güvenli bir yol ile paylaşılmalıdır. (Symmetric Encryption sağlandı.)

Asymmetric Key Algorithm: Asymmetric Key Algorithm gönderilen Datanın 1 anahtar tarafından kriptolandığı ve farklı bir anahtar tarafından da dekript edildiği algoritmadır.
Bu anahtarlar "Public Key" ve "Private Key" olarak adlandırılmaktadır. Public Key'in kriptoladığı
Data dünyada sadece Private Key tarafından dekript edilebilir.
Private Key'in kriptoladığı Data ise sadece Public Key tarafından dekript edilebilir. Diffie-Hellman, RSA vb. algoritmalar Asymmetric-Key Algoritmalara örnek olarak
verilebilir. Temel amacı "Confidentiality" i sağlamaktır. (Asymmetric Encryption sağlandı.)

PKI (Public Key Infrastructure): Güvenilir olmayan ortam üzerinden Symmetric Encryption için kullanılacak olan "Secret Key" in paylaşılması için kurulmuş olan sistemdir.
Ayrıca Sertifikaları imzalamak için de kullanılır. Pratik kullanımından birazdan behsedilecektir.   

Bugün internette yapmış olduğumuz alışveriş, bankacılık işlemleri, ödeme vb. birçok işlemin kötü 3. şahıslar tarafından çalınmasının karşısındaki en büyük
engel olan HTTP'nin SSL veya TLS protokolleri kullanılarak çalıştırılması, yani HTTPS hakkında konuşacağız.
HTTP'de yapılan data alışverişi Cleartext(kriptosuz), HTTPS ile yapılan data alışverişi ise Ciphertext(kriptolu) olarak gerçekleşir.

HTTPS
Peki HTTPS tam olarak nasıl çalışıyor da faturalarımız, kredi kartlarımız, sosyal medya hesaplarımızı ona emanet edebiliyoruz.

İlk olarak bir kullanıcı browserına https://www.losev.org.tr yazıyor.

HELLO

Kullanıcı bilgisayarı tarafından LOSEV'in Web Serverına "ClientHello" mesajı gönderilir. Bu mesaj, clientın hangi SSL versiyonunu desteklediğini ve hangi
"Cipher Suite" in kullanılacağı bilgisini içerir. Cipher Suite, Client tarafından desteklenen PKI, Symmetric Algoritma ve Hash Algoritmalarının listesi şeklinde
düşünülebilir.
ClientHello paketini alan Web Server, ServerHello paketi hazırlar ve Clienta gönderir. ServerHello paketi hangi PKI, Symmetric Algoritma ve Hash Algoritmasının
kullanılacağını seçer.

Sertifika Paylaşımı

Server Clienta SSL Sertifikasını gönderir.(Digital Certificate) Bu sertifika, Server Domain bilgisi, Public Key, Sertifikanın hangi şirkete ait olduğu,
Digital imza (Digital Signature) ve Sertifikanın ne zamana kadar geçerli olduğu bilgisini içerir.






















Digital Sertifika evrensel olarak güven kazanmış Trusted CA ler tarafından verilir.(Comodo,GeoTrust vb.) Yani bir şirket belirli bir prosedüre göre başvuru
işlemini gerçekleştirir. Prosedürün işleyişine göre Public Key, şirket bilgileri gibi bilgiler Trusted CA ile paylaşılır ve Trusted CA de şirket için bir
Digital sertifika üretir. Burada dikkat edilmesi gereken bilgi şu şekildedir; Trusted CA ile sadece Public Sertifika paylaşımı yapılıyor Web Serverın Private Key'i
şirket tarafından kimse ile paylaşılmıyor. Yani bizim asıl gizliliğimizi sağlayan anahtar Web Serverımızda ve başka kimse tarafından bilinmiyor.
Trusted CA tarafından üretildikten sonra şirketimizle paylaşılan sertifikayı bir inceleyelim.
Foto Digital Cer Val.

Yukarıdaki şekilde bir Digital Sertifika var bu sertifikanın Domain Name, Şirket Bilgisi, Public Key gibi kısımların bulunduğu kısım bir X Hash Algoritmasına sokuluyor.
Çıkan değer Hash1 olsun. Daha sonra Trusted CA Hash1 değerini dünyada sadece kendisinin bildiği Private Key ile kriptoluyor ve Digital Sertifikanın
en alt kısmına ekleyerek sertifika oluşturma işlemini tamamlıyor. Bu Digital Sertifika, Trusted CA'e başvuru yapan şirkete teslim ediliyor. Burada
şunu unutmadan söyleyelim; Hash1 değeri oluşturulup Trusted CA tarafından sadece kendisinin bildiği ultra gizli private key ile kriptolanması işlemi
imzalama işlemidir. Kriptolanmış Hash1 Digital Signature olarak adlandırılır. Bu Digital Signature dünyadaki kabul görmüş bütün browserların sahip olduğu Public Key
sayesinde Dekript edilebilir. Yani browserlarımıza Trusted CA lerin Public Keyleri defaultta yüklü olarak gelir.

LOSEV'in WEB Serverına ait Digital Sertifika, Trusted CA tarafından verilmişti. Şimdi de WEB Server tarafından clienta gönderiliyor. Client öncelikle sertifikanın,
Digital Signature ile diğer kısmını birbirinden ayırır. Bunu Digital Signature ve A(Digital Signature dışındaki kısmı böyle isimlendirdik)
şeklinde böldüğünü farzedelim. A; Domain Name, Şirket Bilgisi, Public Key gibi değerlerin bulunduğu kısımdır.
Yukarıda Trusted CA tarafından, X Hash algoritmasına sokulmuştu.
Clientta aynı şekilde A'yı X Hash algoritmasına sokuyor. Çıkan değeri Hash2 olarak adlandıralım. 
Digital Signature; Hash1'in, Trusted CA'in Private Keyi ile kriptolanması sonucu oluşmuştu. Asymmetric Kriptonun çalışması nasıldı? Private Key ile kriptolanan
sadece onun Public Key i ile Dekript edilebilirdi. Bu mantığa göre Trusted CAlerin browserda Public Keyinin yüklü olduğunu söylemiştik. Digital Signature
clientın browserında yüklü olan Public Key ile Dekript edildi. Şu an Hash1 değerine ulaştık. Hash1 ile Hash2 aynı ise herhangi bir tehlike altında değiliz demektir.
Yani sertifika yolda bir saldırgan tarafından değiştirlmedi ya da doğal sebeplerden bolzulmadı diyebiliriz.

Eğer bir saldırgan sertifikanın Public Keyini değiştirip, kendisinin dekript edebildiği yani, Private Keyine sahip olduğu bir Public Key yerleştirirse
client bu sertifikayı alıp Digital Signature'u ile değiştirildiğini hemen farkedecektir. Çünkü saldırgan Trusted CA'in Private Keyine sahip olmadığı için
Digital Signature ı doğru oluşturamayacak ya da Digital Signature'ı hiç değiştirmezse de, Hash2 ile Hash1 farklı olacağından kendisini ele verecektir.

Secret Key Değişimi
 
Şu ana kadar Server ile kullanılacak metodları konuştuk sonrasında LOSEV WEB Serverdan Digital Sertifikayı aldık ve Digital Signature kontrolüyle
bunun gerçekten LOSEV'e ait olduğuna emin olduk. Şimdi Client bir Secret Key üretip onu Server ile paylşacaktır. Bu Secret Key ile yapılacak olan
bütün data alışverişi Server ve Client tarafından kriptolanacaktır ve yine aynı Secret Key tarafından server ve client tarafından dekript edilecektir. Yani
asıl data trafiği symmetric algoritma kullanılarak yapılacaktır. Client tarafından üretilen bu Secret Key sadece server ve client tarafından bilinecektir.
Peki nasıl ? Client Secret Key i ürettikten sonra, server tarafından Digital Sertifika içerisinde gönderilen Public Key i kullanarak kriptolayacaktır.
Public Key ile kriptolanan bu Secret Key dünyada sadece Private Key tarafından dekript edilebilir. Bu Private Key'de LOSEV WEB Serverda bulunmaktadır.
Kötü niyetli kişiler tarafından aradaki hat dinleniyor olsa bile Private Key e sahip olmadıkları için dekript edemeyecekler.
Artık Server ve Client Secret Key e sahip. Symmetric Algoritma, Asymmetric Algoritmaya göre daha hızlı çalıştığı için tercih ediliyor ve Data alışverişi
bu algoritma ile sağlanıyor.

HTTPS bir trafiği dinlemenin tek yolu kullanıcı bilgisayarına bir şekilde kendi Public Sertifikanı Trusted CA olarak yüklemektir.
Firewall üzerinden SSL Inspection yapmak isterseniz, Private Sertifikayı Firewall'a, Public Sertifikayı Trusted CA olarak clientlara yükleyebilirsiniz.