Windows Debugging 206

Güvenlik her sistemin önemli bir bakis açisidir. Güvenlik tasarimin alt katmanlarindan itibaren farkli noktalarda uyarlanmak zorundadir ve çok sayida imkân ve zorunluluklar getirir. Kitabin ilk bölümü birçok konu arasinda güvenlikten de söz ediyordu ve özetleyecek olursak: Güvenlik de isletim sisteminin temel sütunlarindan biridir. Objeler üzerinde üç farkli güvenlik konsepti uyarlanir.

Ilki discretionary dir. Bu hepimizin kullandigi haklar ve paylasim haklaridir. Yani bir kullanici, kullanici adi ve sifresi ile logon seklinde authenticated olduktan sonra farkli kaynaklara authorized olur. Bu authentication ve authorization Windows güvenliginin temelidir. Yani sahis tanima ve sahisin haklarina göre kendisinin sistemde hareket kabiliyetini saglamak. Korunan kaynaklarin listesini sayfa 458 de bulabilirsiniz.

Priviledged acess control, discretionaryin üstüne gelen yapidir. Örnegin artik kullanilmayan bir kullanici hesabin sadece onun hakki olan dosyalarinin kurtarilmasi gibi durumlarda devreye girer. Yani, admin o dosyalarin ownership ligini üstüne alabilir ve sonra haklari istedigi gibi degistirebilir.

Objeleri son koruyan katman da mandatory integrity control dur. Bu da örnegin User Account Control, UAC dir.

Burada özel durumlar da mevcuttur. Örnegin kitabin besinci bölümü protected process lerden söz eder. Debug priviledge i olan herhangi bir process diger processlere tamamen erisebilir ve degisiklikler yapabilir. Kisaca admin hakki olan bir kullaniciya sistemde çalisan bütün processlere hak vermis oluruz. Bu ancak mesela protected media rights ile çakisir. Media Foundation API sini kullanarak Windows Media sertifikasi olan dosyalar ile çalisan processler bu sekilde korunabilir. Yani protected processlere admin in erisimide böylece kisitlanmaktadir. Burada örnegin audiodg.exe bir protected process dir. Böylece korunan media larin örnegin riplenmesi önlenir.
System processi de kernel ile farkli islemler yaptigindan dolayi ve integrity si korunmasi gerektiginden dolayi bir protected process dir. Bir process i protected yapmak aslinda sadece kendi Eprocess blogunda bir flag i set etmektir. Bu flag kernel de oldugu için, diger aygit sürücülerin erisimine açiktir. Ancak bu yönde ilerlemek o sürücünün ‘malicious’ algilanmasini saglayacaktir. Burada o sürücünün yüklenmesi engellenebilir veya durum o sistemde örnegin ses sorunlarina kadar gidebilir. Basitçe, korunmakta olan bir medyayi sadece güvenilir sürücüler oynatabilir. Örnegin bir debugger ile o sürücüye baglanirsaniz sistemin ses oynatma kabiliyetini geçici durdurmus olabilirsiniz. Digital medya korunmasi kanuni bir gereksinimidir ve en temelinde digital millenium copyright act ine dayanir.

Bilgisayar sistemlerin güvenliginin standardize edilmesi trusted computer evaluation criteria ile baslamistir. Burada sistemler yerine getirdikleri gereksinimlere göre siniflandirilirlar. Windows çogu sistem gibi C2 seviyesindedir. Bu normal kullanim için en uygun güvenlik seviyesidir ve genel isletim sistemlerin çogu C seviyesindedir, B ve A seviyesindeki sistemler sadece savuma sanayisinde bulunabilir.

Windows da authentication (secure logon facility) ve authorization (discretionary access control) vardir. Yani kullanici login olur ve login oldugu kullanicinin haklari bazinda sistemde hareket eder. Ayrica farkli kaynaklar için Security Auditing açilabilir. Object reuse protection ile bu ilk dört nokta ile Windows C2 seviyesine gelir. Sonuncusu örnegin A kullanicisinin silmis oldugu bir dosyanin B kullanicisi tarafindan herhangi bir sekilde erisebilmesini engeller.

Windows ayrica B seviyesinden de iki noktayi tam yerine getirir. Ilki Trusted Path Functionality dir.Secure attention sequence, SAS (ctrl+alt+delete) sayesinde hep Windows un kendi logon ekrani, Winlogon.exe in logonUI si gelir ve burada baska bir user mode process in araya girmesi imkansizdir. Ayrica SAS zaten yüksek keyboard IRQL seviyesinde gelir. Yani burada baskasinin kernel seviyesinde araya girmesi de imkânsizdir. SAS in amaci budur. Ancak sisteme sürücü kurma yetkisi olan bir kullanici degisik sürücüleri bilinçli veya bilinçsiz kurabilir ve böylece malicious bir filter sürücüsü kendisini sistemde daha farkli yerlere de attach edebilir.
Genuine bir isletim sisteminde, örnegin Windows Defender arti antivirüs de çalistiginda, sistemi bu tarz threat lere karsi çok iyi koruyabiliriz.

Kisaca güvenlik altyapisi sistemi dis etkenlerden çok iyi koruyabilir, ama eger kullanici/admin kernelde çalisacak bir tehlikeli sürücü kurarsa, sistemin yapabilecegi çok sey kalmayabilir. Bir asamadan sonra sistem admin e güvenmek zorundadir. Burada güvenlik yazilimlari bu tarz kullanici hatalarindan koruyabilirler.

Isletim istemi güvenlik ile ilgili kullanici yanilmalari ve hatalarindan integrity mekanizmalari ile korunur: UAC, Internet explorer protected mode (PMIE) ve User Interface Privilege Isolation (UIPI). Burada bir integrity level degeri kullanilir ve asagida sözü geçen Security Reference Monitör, bir erisim isteginin nereden geldigini belirleyebilir.
Böylece discretionary yapinin üstünde mandatory yapinin nasil çalistigini anlayabiliriz. Yani bir güvenlik katmani daha getirerek burada da hak bilgileri tutabiliriz. Örnegin kurulum hakkina sahip bir kullanici kurulum exe sini baslattiginda UAC devereye girer, yani bir güvenlik katmanindan daha geçeriz. Kurulum yapma hakki sadece ilk katman için geçerlidir. UAC ayarlari bundan bagimsizdir.

En nihayetinde ama güvenlik sunucunuzun bulundugu ortam ile baslar. Temel bakis açilari için Enterprise Security Best Practices makalesini incelemenizi ve Microsoft Security Response Center sayfasini ziyaret etmenizi öneririm.

Diger Windows un sundugu B seviyesi gereksinimlerinden biri de Trusted facility management dir. Bu da print veya backup gibi farkli admin gruplarina admin kullanicisinin bölünebilmesini saglar. Yani sadece bir her seye tam hakki olan bir admin kullanici tipi yoktur.

SAS in çagirdigi Winlogon.exe ve logonUI ile logon oluruz ve bu kullanici kontekstinde çalisan ilk processi çalistirir.
Buradan sonra biometric cihaz veya smartcard gibi farkli credential provider lar devreye giriyor olabilirler. Bunlar logonui de çalisan COM objeleridir. Bunlar mesela authui.dll veya SmartcardCredentialProvider.dll lerdir.

Winlogon, interactive logon manager dir, ayrica netlogon.dll, network logon servisimiz vardir. Kendisi ile DC ye secure channel baglanti kurup, domaine logon olabiliriz veya farkli güvenlik ile ilgili isteklerde bulunabiliriz.

Lsass.exe lsasrv.dll beraberinde kullanicilar ile ilgili tanimlanmis policy lerin uygulanmasini saglar ve bunun ile ilgili auditleri iletir. Local security authority subsistemi bunun için HKLM\Security altindaki lsass policy veritabanini kullanir.

Lsass.exe ayrica samsrv.dll i çagirir. Böylece SAM, security accounts manager in lokaldeki kullanici adlari/sifreleri ve gruplamalari ile ilgili gerekli kodlar çalistirilabilir. Domain üyesi sunucularda SAM veri tabani kullanilir ve bu HKLM\SAM altinda tutulur. Domain controllerlarda SAM sadece sistem admin kullanicisinin recovery bilgisi ve sifresinden sorumludur. Bildiginiz gibi DC de lokal kullanici aslinda yoktur.

Domain controller larda lsass.exe ayrica ntdsa.dll i de yükler. Bu active directory için temeldir; bütün domain in bilgilerinin tutulmasi gerekir. Active directory kitabin 12inci bölümünde detayli tartisilmaktadir.

Kernel tarafindaki güvenlik yapilari ile lsass arasindaki LPC iletisimi kernel security device driver, ksecdd.sys ile yapilabilir. Örnegin kernelde çalisan encrypting file system, efs.sys bu sürücüyü kullanir.

En temel güvenlik de mimari olarak ntoskrnl.exe de security reference monitor, SRM ile uyarlanir.

Üçüncü bölümde sözü geçen object manager güvenlikte önemli bir rol üstlenir. Farkli kaynaklara kernelden user mode tarafina erisim saglanir ve ondan object manager kernel tarafinda güvenlik konusunda büyük önem tasir. Bir thread bir objeye erismek istediginde bastan yapilacak, islemleri belirlemek zorundadir. Object manager SRM i çagirir ve bu güvenlik ayarlarini kontrol ettikten sonra threade erisim hakki processin handle tablosuna hak detaylari ile beraber kayit edilerek verilir.

Deafult güvenlik ayarlari örnegin file objelerinde farklidir. Burada file bazinda güvenlik ayarlari belirleyebiliriz ve erisimde bu detaylari ntfs.sys den aliriz. Yani örnegin mutex ve semaphore gibi objelerin default üstüne yazilamaz güvenlik yaralari vardir. Mesela bir objeye bir handle bir processe read olarak verilmisse, bu processin baska bir threadi bu handle in hakkini tabloda write a çeviremez. Yeni handle istenilmesi gerekir. Ama overwrite edilebilen ntfs güvenlik ayarlari gibi obje güvenlik ayarlari da vardir. Kullanici objesinin de haklari degistirilebilir örnegin.

Çok yardimci olabilen bir mekanizma impersonation dir. Bir thread normalde bagli oldu processin güvenlik konteksinde çalisir ve o da kendisinin veli processinkini almistir vs. Impersonation ile bir thread farkli bir güvenlik konteksinde çalisabilir. Burada dikkat edilmesi nokta, burada hak yükseltmesi söz konusu oldugunda, bundan indirect diger threadlerin de faydanabilmeleri. Process deki handle tablosuna bütün threadlerin erisim hakki esittir. Yani bir impersonating thread bir objeye erisim saglarsa, bu handle tablosuna kayit edilir ve ayni processin diger handle lari da ayni objeye erisim hakkina sahip olurlar. Bu sekilde de ama bütün processin ve threadlerinin haklarini temelde düsük tutarak ve sadece bir threadin hak seviyesini bir islem için geçici artirarak çalismamiz mümkün olur. Herkes ve her sey için ilgili haklari hep islevsel engel olmayacak sekilde mümkün oldugunca düsük tutmak gerekir. Impersonation burada çok kolay bir yardim aracidir.

Güvenlik yapisinda bilgisayar ve kullanicilar gibi ayri tutulmasi gereken farkli varliklar, entity ler mevcuttur. Bunu her birine benzersiz security identifier, SID vererek yapariz. SID in uzunlugu farkli olabilir, ama örnegin bütün kullanicilarin, kullanici gruplarin ve bilgisayarlarin bir SID degeri vardir. Kullanici yaratildiginda veya bir sistem kuruldugunda hemen bir SID degeri de olusturulur.

Duyacaginiz Ikinci temel güvenlik terimi de belirteç, Token dir. Iste bu da kullanicinin güvenlik ile ilgili bilgilerini tutugumuz yapidir. Tokenlarin da LUID, lokal ID leri vardir. Bu degerler hakkinda bilgileri kitapta sayfa 461 inden itibaren bulabilirsiniz. Yani varliklari belirleyen benzersiz ID leri vardir ve objelerin haklarini özetleyen yine benzersiz ID li belirteçleri vardir. Impersonation da tokenlar ile yapilir. Özellikle networksel islemlerde daha düsük hak seviyesi istenildiginde, istenilen seviyeye göre restricted veya filtered admin tokenlari kullanilabilir.

Objelerin güvenlik ayarlari security descriptor lar ile tutulur. Burada en bilinen herhalde discretionary access contol list, DACL lardir. Örnegin dosyalain güvenlik yarlari bu sekilde tutulur. Söz ettigimiz gibi bir objeye erisebilmek için mandatory ve discretionary Access check leri geçmemiz gerekir.

Burada özel durum örnegin backupdir. Burada bütün dosyalara bir kullanicinin haklari eklenmez. Bir kullaniciya bir priviledge, bir ayricalik verilir. Bazi super priviledge larin verilmesi bir kullaniciyi bir ‘süper kullanicisi’ yapabilir. Örnegin debug programs priviledge i bunlardan biridir. Tam listeyi sayfa 510 da bulabilirsiniz.
Audit, security yapisinin bir sütunudur. Geriye dönük islemleri kontrol etmemizi mümkün kilar.

Bu sadece bir konsept özetiydi. Çok daha fazla güvenlik yapisi ile ilgili konulari ve detaylari Windows Internals 5th ed. Chapter 6 ‘Security’ de bulabilirsiniz: https://technet.microsoft.com/en-us/sysinternals/bb963901

Eger kendinizi Windows mimarisinde veya sistem/sürücü yazilimcisi yönünde gelistirmek istiyorsaniz veya isletim sisteminin bir referans kitabina ihtiyaciniz varsa bu kitabi incelemenizi öneririm.

https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act Digital Millennium Copyright Act
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria Trusted Computer System Evaluation Criteria
https://technet.microsoft.com/en-us/library/dd277328.aspx Enterprise Security Best Practices
https://www.microsoft.com/security/msrc/default.aspx Microsoft Security Response Center

Basar Güner

Sr. Support Engineer, Microsoft