Hash'ini Seven Kovboy Heykır'lara Karsi - Nass oluyor da oluyor?

"Windows Credential Editor ile Hash Passing - Nass oluyor da oluyor?" başlıklı yazımda hash ele geçirme ve kullanma için geliştirilmiş araçların en tehlikelilerinden biri olan Windows Credential Editor (WCE)'dan bahsetmiş, parolalar ne kadar uzun ve karmaşık olursa olsun çalınmalarının,kullanılmalarının ne kadar kolay hale geldiğini anlatmıştım. Pass-The-Hash ilk defa 1997'de Paul Ashton tarafından ortaya atılan bir fikir aslında, yeni değil. Ama biraz işletim sistemi'nin yapısı gereği biraz da kullanıcı kolaylığından feragat edememe kaygısı ile şu ana kadar engellenememiş,ortadan kaldırılamamış bir risk. Aynı zamanda bu yöntem özellikle sızma testlerinde orataya çıkan "domain admin parolasının ele geçirilmesi" gibi hurafelerin de kaynağı ve zaman içinde hash elde etme yöntemleri gelişti,artık işletim sistemi hafızasında saklanan hashler ve şifrelenmiş parolalar da kolaylıkla elde edilebiliyor. Yazının başlığı başka çağrışımlar yapmasın, Hash sevgisine vurgu yapmak ve biraz da eğlenceli olması için üstad Sadri Alışık'ın bu meşhur filmine gönderme yaptım :)

Windows işletim sistemi özelinde konuşacak olursak Microsoft, NT zamanından beri kullanıcı kimliğini doğrulamak için (authentication) çeşitli protokoller kullanıyor. Bu protokollerin en güveniliri Windows 2000 ile kullanılmaya başlanan Kerberos olsa da, Kerberos desteği olmayan uygulamaların,protokollerin ve 2000 öncesi işletim sistemlerin sorunsuz çalışabilmesi için NTLM,Digest gibi eski kimlik doğrulama protokolleri de bir yandan kullanılmaya devam ediyor. Microsoft'un SSP (Security Support Provider) de dediği bu doğrulama protokolleri de biz tembel ve nazik parmaklı kullanıcıları daha çok memnun edebilmek, her erişmek istediğimiz kaynak için kullanıcı adı/parola yazdırmamak adına credential dediğimiz kullanıcı adı ve parolalarımızı kimi zaman bilgisayarın registry kayıtlarında,kimi zaman SAM veritabanında,kimi zaman da LSASS (Local Security Authority SubSystem) process'inde olduğu gibi işletim sistemi hafızasında (memory) saklıyor ve kimlik doğrulama gerektiğinde ya da  token yenileme zamanı geldiğinde kayıtlı credentialları arka planda bize çaktırmadan gerekli servislere iletiyor. Çeşitli algoritmalarla hashlanan,şifrelenen parolaların saklandığı yerler de sır değil. Lokal kullanıcı hesapları için kayıtlı parolalar "%systemroot%\system32\config" altındaki SAM dosyasında ve "HKLM\SAM\SAM\Domains\Account\Users" registry yığınında (Resim 1) saklanırken, domaine dahil bilgisayarlarda interaktif oturum açan kullanıcı hesabı bilgileri "HKLM\SECURITY\Cache" registry yığını (hive)'nda (Resim 2) tutuluyor. "İnteraktif oturum" terimini aklınızda tutun çünkü yazının devamında ele geçirilen işletim sistemine nasıl erişmek gerektiğini anlatırken bol bol kullanacağım. SAM registry kayıtlarına yönetici yetkisiyle erişmekte pek sorun yok.Normal şartlar altında görünmeyen alt dizinler, SAM dizininde hesabınıza yetki verdikten sonra listeleniyor. Ama SAM dosyasına erişim bu kadar kolay değil. Lsas procesine dll enjekte etme gibi yöntemlerle işletim sistemi açıkken de bu dosyaya erişebiliyorsunuz ama genellikle tercih edilen yöntem bootable bir linux işletim sistemiyle bilgisayarı açtıktan sonra bu dosyayı kopyalamak ve bu offline kopya üzerinde tırmalamak.

Resim 1

Resim 2

Resim 1'deki ekran görüntüsünde "Users" boğumu altındaki dizinlerin isimleri kullanıcı hesaplarına atanan SID (Security Identifier) numaralarındaki RID (Relative ID) numaralarını içeriyor. Yani "0000040B" isimli dizinde "test" lokal kullanıcı hesabına ait kullanıcı bilgileri tutuluyor."40B",1035 RID numarasının hexadesimal düzendeki karşılığı. ( Resim 3) "F" ismiyle gösterilen registry kaydında kullanıcı hesabının son oturum açma anı, parolanın geçerlilik süresinin ne zaman dolacağı gibi bilgiler tutulurken,"V" ismiyle gösterilen kayıtta kullanıcı  adı, parolanın şifrelenmiş LM,NTLM hashleri,-parola geçmişi güvenlik amaçlı aktif hale getirildiyse- önceki parolaların hashleri gibi bilgiler tutuluyor.0x0C konumundaki değer kullanıcı adının ofset değerini,0x10 konumundaki değer ise kullanıcı adının uzunluğunu gösteriyor mesela,0x0C konumundaki değere 0xCC eklediğinizde elde edeceğiniz yeni konumda kullanıcı adı bilgisi tutuluyor.Resim 4'deki örnekte V binary verisinin 0x0C inci birbaşka deyişle onikinci byte'ı olan 0xBC değerine 0xCC eklediğinizde elde ettiğiniz değer 0x188 dir,aynı binary veri bloğunda 0x188'inci bytedan başlayan 8 byte boyunca kullanıcı adı değeri saklanır (Resim 5).Benzer şekilde hash bilgilerinin de tutulduğu yerler registry'nin bu alanlarındaki offset değerlerinden yararlanılarak hesaplanabilir.Creddump,hashdump,pwdump ve benzer bilumum dump yazılımlarının da yalan yanlış parola hash'leri elde edip pentester'ları hüsrana uğrattığı ve Ryan Reynolds ile Jonathan Claudius'un parmak bastığı nokta da tam burası. Bilgisayar ya da domain yöneticisinin parola geçmişi tutma/tutmama,LM hashi tutma/tutmama tercihine bağlı olarak bu alan değişkenlik gösteriyor ve bu noktayı dikkate almayan dumper araçları kullanıcısına tutarsız hashler gösteriyor. Dolayısıyla pentester dostlarımız çalışmaları sırasında bu tip araçlarla elde ettikleri hashleri kullanamazlarsa sebebi hashlerin yukarıda bahsettiğim şekilde düzgün hesaplanamamasıdır.

Resim 3

Resim 4

Resim 5

LM hashleri Windows Vista ve sonrasında gelen Windows işletim sistemlerinde varsayılan olarak tutulmuyor bir rivayete göre. Windows 2000 SP2 ve sonrası işletim sistemlerinde ise işletim sisteminin LM hash'i tutma özelliğini "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" yığınında "NoLMHash" isimli bir anahtar oluşturarak da aktif/pasif yapabiliyorsunuz. Bu şekilde LM hash'lerin tutulmasını engelleseniz dahi NT hashlerin saklanmasını engelleyemiyorsunuz,yine de artık ortlamlarımızda Windows 95-98 istemci işletim sistemleri bulunmadığına göre işletim sistemlerinde LM hashleri saklatmanın bir anlamı yok. Şunu da belirtmek isterim, yukarıda tarif edildiği şekilde "NoLMHash" anahtarı eklemiş olsanız da varlolan lokal kullanıcı hesapları,parolalarını değiştirmedikçe LM hash saklamaya devam eder. Yani bu registry değişikliğinden sonra lokal kullanıcı hesaplarının parolasını değiştirmelisiniz ki yeni parolanın sadece NT hash'i saklansın.SAM ve registry'de tutulduğunu bahsettiğim hash'ler ise aslında parolanın hash'inin şifrelenmiş halinin hash'i. Bu da şu demek oluyor; Registry veya SAM'den elde edilen hashlerden parolanın açık-seçik halini elde etmek için biraz yürek ve GB'larca gökkuşağı tablosu (rainbow table - türkçe karşılık komik oldu ) gerek. Zira yine Windows 2000 ve sonrası işletim sistemlerinde SAM veritabanı SYSKEY aracı ile birlikte bootkey denen bir anahtarla ve RC4 algoritmasıyla da şifreleniyor.Bu da sadece SAM veritabanını deşifre edebilmek için bu anahtarı da edinmek gerek anlamına geliyor.
Resim 2'de gösterilen ve bilgisayarda interaktif oturum açmış domain kullanıcı hesaplarına ait,tuzlanmış  ( salted ) ve 2 kere MD4 algoritmasıyla hash'lenmiş parola'nın "password verifier" denen bilgisinin tutulmasını ise Güvenlik Politikası ile ya da "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" yığını altındaki "CachedLogonsCount" anahtarının değerini düzenleyerek kontrol edebilirsiniz. Yine Windows 2000 ile gelen bu özellik, domain'e dahil bilgisayarın bir DC ile irtibat kuramaması halinde daha önce kaydettiği ( cached domain credentials ) kullanıcı hesaplarına, oturum açma hakkı tanır. Her ne kadar "password verifier" denen bu bilgi sadece kayıtlı olduğu işletim sistemi üzerinde kullanılabilse de bu tip bir ihtiyacınız yoksa bu sayıyı 0 ya da 1 yapın.
Diskte ve registry'de saklanan hash değerlerini kısıtlayarak ya da azaltarak sadece riski azalttık,yazının başında belirttiğim gibi bu riski ortadan kaldırmanın uygulanabilir bir yolu yöntemi yok ne yazık ki.Bunun nedeni de parola hash bilgilerinin ve bazen şifrelenmiş parolaların yine bazı kimlik doğrulama protokollerince ve kimlik doğrulama mekanizması bileşenlerince işletim sistemi hafızasında da tutulması. Hedef işletim sisteminde interaktif oturum açmış aktif kullanıcı hesabına ait parola mimikatz,wce gibi araçlar yönetici yetkisi ile kullanıldıklarında kolaylıkla öğrenilebiliyor. (bakınız Windows Credential Editor ile Hash Passing - Nass oluyor da oluyor? ) Özellikle Digest Authentication tarafından saklanan parola bilgisi deşifre edilerek açık haliyle görüntülenebiliyor. WCE'yi yazan firmanın önerdiği -fakat tavsiye edilmeyen- yöntemlerden biri olan Digest Authentication paketini işletim sisteminin kullanabileceği güvenlik paketleri listesinden çıkararak en azından Digest Authentication ile saklanan parolanın deşifre edilmesini engelleyebilirsiniz ama bu bile diğer kimlik doğrulama paketlerince ( SSP ) NTLM hashlerin hafızada tutulmasını engellemiyor.
Anahtar kelime "interaktif oturum açma" (interactive logon) ,yani fiziksel olarak bilgisayarın başına geçerek ya da RDP ve benzeri uzak terminal yönetim protokol ve yazılımlarıyla işletim sisteminde oturum açmak ya da "Run As" yöntemi kullanarak hedef bilgisayarda farklı kullanıcı hesap bilgileri kullanarak komut/uygulama çalıştırmak. Uzak bilgisayardan açılan oturumlara da "uzak interaktif oturum" (remoteinteractive), kimlik doğrulama için lokalde kayıtlı hash bilgileri kullanılıyorsa "CachedInteractive", kimlik doğrulama için lokalde kayıtlı hash bilgileri kullanılıyorsa ama oturum uzaktan açılıyorsa "RemoteCachedInteractive" gibi 12-13 adet oturum açma tipi var (Resim 6) özellikle yeni işletim sistemlerinde.Ama anahtar kelime "Interaktif", açtığınız oturum tipi interaktifse -ki bunu da Güvenlik olay kayıtlarından (Security Event Log) rahatlıkla anlayabilirsiniz - parolanızın ya da en kötü ihtimalle parolanızın hash'inin ele geçirilmesi an meselesi olabilir. Resim 7, DC'ye erişimi kopmuş domaindeki bir sunucuya RDP protokolü ve domain kullanıcı hesabı ile oturum açıldığında oluşturulan güvenlik olay kaydını gösteriyor. Oturum açma tipi "Logon Type" satırından anlaşılıyor. Interaktif oturum ile hafızaya alınan hash bilgileri oturum süresince saklanmaya devam ediyor.Bu nedenle özellikle RDP oturumlarını "Disconnect" ile değil de "Logoff" ile sonlandırmak önemli.

Resim 6

Resim 7

Interaktif oturum açma ile birlikte karşılaşılan riski, WMIC,psexec (-u anahtarı ile alternatif kullanıcı hesabı bilgisi kullanmadan),powershell (ps-remoting),MMC snap-in'ler gibi uzaktan yönetim için kullanılabilecek araçlar ile network oturum açarak (network logon) bertaraf edebiliyorsunuz,önerilen yöntem de bu. Bu nedenle DMZ gibi dış dünyaya daha fazla açık sunucularınızın yönetimi için bu araçları kullanmanız tavsiye ediliyor.Özellikle ele geçirildiğini,sızıldığını düşündüğünüz bir bilgisayara işletim sistemi açıkken ve izole etmeden müdahele edecekseniz bu noktayı aklınızdan çıkarmayın. Sorunu anlayım,çözeyim derken kullanıcı hesabınızın parolasını ya da hashlerini saldırganlara kaptırabilirsiniz.
Windows işletim sisteminin yapısı gereği bu saldırı yöntemini tamamen engellemenin mümkün olmadığını aklımızdan çıkarmayarak,yazı boyunca yeri geldiğinde değindiğim önlemleri Microsoft'un önerdiği yöntemlerle birlikte toparlayacak olursak;

• İstemci ve sunucu işletim sistemlerine fiziksel erişimi kısıtlayın. İstemci bilgisayarların CD-ROM,USB gibi arayüzlerden boot edilmesini engelleyecek önlemler alın. Bu arayüzleri fiziksel olarak kapatamıyor ya da kaldıramıyorsanız BIOS'a erişimi de kısıtlamayı ihmal etmeyin.
• Kullanıcılarınıza yönetici yetkisinde hesaplar kullandırmayın
• Servis hesaplarınıza ve planlanmış işleri ( scheduled tasks) çalıştırmak için kullandığınız hesaplara gereğinden fazla yetki vermeyin.
• Active Directory'de geniş yetkili kullanıcı hesapları için "Account is sensitive and cannot be delegated" seçeneğini işaretleyin.Bu özellik parola hash'leri gibi çalınabilen Kerberos token'larının başka bilgisayarlara erişim için kullanılmasını engeller.
• Sunucu ve istemci bilgisayarların lokal yönetici hesaplarına farklı parolalar vermeyi alışkanlık edinin.
• Risk altındaki sunucularınızda domain administrator gibi geniş yetkili kullanıcı hesaplarının oturum açmasını engelleyin
• Sunucularınızda interaktif oturumlar için timeout süreleri kullanın,bu sürelerin sonunda oturumların sonlandırılmasını zorlayın.
• Sunucularınızda ve istemci bilgisayarlarınızda LM hashlerin saklanmasını engelleyin, cache'lenen domain kullanıcı hesapları sayısını azaltın.
• Proxy sunucularınızda ya da firewall'larınızda yetkili hesapların internete erişimini engelleyin.
• Windows firewall'larınızda inbound trafiği engelleyin.
• Domain yöneticisi yetkisine sahip hesaplarınızda bir seferlik parolalar kullanın.
• Kritik sunucularınıza yönetim amaçlı erişimler için izole ve ayrı bilgisayarlar (jump servers) kullanın ve yönetim için network tipi oturumlar (network logon) kullanmaya özen gösterin. Aklınızın bir köşesinde her zaman "mı acaba?" sorusu olsun :) (Bakınız Mitigating Pass The Hash Attacks and Other Credential Theft Techniques sf 41-Tablo 7)
• Ve en önemlisi, işletim sistemi ve kurulu uygulamaların güvenlik güncellemelerini aksatmayın.

Kimlik doğrulama protokolleri,mekanizmaları işletim sistemlerinin en kapalı kutu bileşenleri ve yetkilendirme mekanizmalarıyla birlikte güvenliğin temelini oluşturuyor. Üreticiler ayrıntıları ne kadar gizlemeye ve korumaya çalışsa da tersine mühendislik uygulamalarıyla bu mekanizmaların çalışma prensipleri de zaman zaman gün ışığına çıkıyor. Bu ve ilgili önceki yazımda post-exploitation (çeşitli zaafiyetler kullanılarak sisteme sızıldıktan sonraki eylemler) yöntemlerinden biri olarak gösterilen ve uzun zamandır varlığından haberdar olduğumuz "hash passing" i, parola hash'lerinin hangi hallerde nerelerde saklandığını, daha yetkili hesaplar elde etme ve oluşturmada nasıl kullanılabildiğini,hash'lenmiş parolayı kullanabilme imkanı varken parola'nın kırılma,deşifre edilmesi gibi yöntemleri kullanmanın zaman kaybı olduğunu ve daha önemlisi hash'lerin yanlış ellere geçmesini engellemek için alınabilecek önlemleri anlatmaya çalıştım. Biraz karambole geldi ama,bu bilgiler ışığında ele geçirilmiş,ya da ele geçirildiğinden şüphelenilmiş bilgisayara müdahele için kullanılması gereken erişim yöntemlerini de unutmamanızı öneriyorum.
Hash'inizi sevin,koruyun çünkü saldırganlar seviyor :)

İlgili Yazılarım
Windows Credential Editor ile Hash Passing - Nass oluyor da oluyor?