Windows Servislerinin İnternet Olmayan Sunucuda Çalışmaması

Bu yazımızda kendi yazdığımız windows servislerinin çalışmamasında yapılabilecek bazı kontroller ve bu kontroller işe yaramadığında yapılabilecek işlemler yer almaktadır.

“Lokalde çalışıyor”, “önceden çalışıyordu”, “başka sunucuda çalışıyor” önermelerine karşı kanıt yoluyla yanlışlama ve sorunun tespiti ile çözümü hakkında kısa bir yazı.

Problem

Bir sunucuya yeni kurulan windows servisi çalışmıyor. Servis yöneticisinden ilgili servis başlatılmak istenildiğinde zamanaşımına uğrayarak hata veriyor.

Şüphe I

Servis başladığında veritabanına hangi ayarlar ile başladığını kaydediyor. Servisin başlarken ilk yaptığı işlerden biri veritabanı ile ilgili bir işlem olduğundan ve bahsedilen kaydın da veritabanında bulunmamasından dolayı ilk olarak veritabanı erişiminden kaynaklı hata olduğu şüphesi oluştu. Daha önce aynı veritabanına ulaşan kullanıcı nasıl olur da erişemez hale gelirdi gibi soruları sormamak gayet doğaldır. Müşteri tarafından yapılabilecek işlemlerde sınır aramamak gerekir. Kullanıcı değişmiş haber verilmemiş olabilir, şifre değişmiş haber verilmemiş olabilir, veritabanı değişmiş haber verilmemiş olabilir, integrated authentication kullanıldığı için windows kullanıcısının şifresi zamanaşımına uğramış, değişmesi gerekiyor olabilir. Neyse ki bu gibi şüpheleri elemek nispeten kolay bir takım işlemler gerektiriyor.

Veritabanında sorun olmadığı tespit edildi, kullanıcılar ile ilgili değişen bir detaya da rastlanmadı.

Şüphe II

Veritabanında sorun yoksa ve servisin ilk yaptığı işlerden biri veritabanına bağlanmak ise servisin başlayıp durmasından çok hiç başlamamış olmasından şüphelenmek gerekir.

Servislerimiz bir preprocessor tanımı sayesinde “Debug” konfigürasyonunda derlendiğinde komut satırı uygulaması olarak, “Release” konfigürasyonunda derlendiğinde ise windows servisi olarak bir imaj(exe dosyası) oluşturuyor. Servislerin yanlışlıkla “Debug” modunda derlenerek sunucuya kurulduğu şüphesi oluştu.

Yapılan dosya karşılaştırma kontrollerinden sonra sunucudaki windows servisi uygulamasının “Release” konfigüyasyonunda derlenerek sunucuya yüklendiği tespit edildi.

Şüphe III

Kainattan şüphelenildi, fazla zaman kaybetmeden işletim sisteminden şüphelenildi. Uygulama çalışıyor muydu yoksa proses dahi oluşturulamadan hata mı alınıyordu? Bu önermenin karşılığını bulabilmek için eski dostumuz “Görev Yöneticisi” yardımımıza koşuyor. Görev yöneticisi açıkken windows servisi ile ilişkili bir prosesin yaratıldığını, hata almadan hemen önce de öldürüldüğünü yakalayabildik. Bu durumda proses başladıktan sonra fakat kontrol .NET’e geçemeden önce alınan bir hata ile karşı karşıyaydık.

Tespit I

Windows servisi başlarken .NET’e geçmeden hata alıyor. Hatanın doğrudan uygulama kaynaklı olmadığı da “Şüphe II” başlığında tespit edilmişti. Prosesin hafıza dökümünün(memory dump) incelenmesine karar verildi.

Hafıza dökümünün alınması

Görev yöneticisinden ilgili prosese sağ tıklanarak “Full Memory Dump” alınır. Daha sonra dosya, Windows Debugging Tools yüklü olan, sunucudan ayrı bir bilgisayara aktarılarak incelenebilir. Sunucu 64-bit ise, incelemenin yapılacağı bilgisayarın da en az 64 bit olması gerekmektedir.

Yardımımıza koşacak olan uygulama, windows kernel debugger, namı diğer ntsd, namı diğer cdb. Arayüz sevenler windbg kullanabilir, biraz daha rahat ama yine de dosyayı açtıktan sonra komut satırında devam etmek gerekiyor. Bu noktadan sonra windbg, debugger anlamında kullanılmıştır.

Bellek Dökümünün İncelenmesi

SoS’u WinDbg’ye yüklemeden önce analiz edilen her bellek dökümünde kontrol edilmesi gereken alanları inceliyoruz.

Dosyayı WinDbg’ye yüklediğimizde aşağıdaki gibi bir ekran bizi karşılamalıdır.

image

Bellek dökümünü kotarılmamış istisnai durumdan(unhandled exception) oluşmadığı için, manuel olarak alındığı için doğrudan aktif thread’in call stack’ini inceleyebiliriz.

Aktif thread’in stack trace’ini görmek için kb yazıp entera basıyoruz.

Adreslere, parametre değerlerine ve metod içerisindeki satırlara dikkat etmeden akışı sezmeye çalışıyoruz. İncelediğimiz call stack, 4 farklı gruptan çağrı içeriyor. En üstteki NtWaitForSingleObject, en son girilen metodu gösteriyor, en alttaki RtlUserThreadStart ise bulunulan thread için ilk çalıştırılan metodu gösteriyor.

Stack traceini kabaca inceleyecek olursak:

  1. İlk grup koyu mavi, thread’i başlatıp kontrolü WinMain metoduna aktaracak olan işletim sistemi metodları. WinMain, .NET uygulamalarında hemen mscoree.dll içindeki CorExeMain metodunu çağırarak kontrolü .NET’e devreder. (Adına WinMain denmesine rağmen önemli olan adresi olduğu için adı farklı olabilir. )
  2. İkinci grup turuncular, .NET’in windows servisimizi çalıştırırken harcadığı çabaların bir kısmını içermektedir.
    1. CorExeMain’den sonra AppDomain yüklenir.
    2. ClassLoader, .NET Main entry point metodunun hangi sınıfta olduğunu bulup ilgili MSIL kodlarını derlemek ister.
    3. PreJit (JIT-derleme öncesi) Main metodunu derlemek üzere harekete geçer.
    4. Hangi assembly’de olduğu bulunan metod, hafızaya yüklenerek derlenecektir.
    5. Assembly hafızaya yüklemeden önce imza kontrolleri yapılır (DoLoadSignatureChecks) (Şüphe IV bu noktada oluşmaya başlıyor)
    6. mscorsec modülü, yayıncıyı bulmak ister. (GetPublisher)
  3. Üçüncü grup bordolar, mscorsec modülünün isteği üzerine yüklenen wintrust ve ardından gelen crypt32 ve cryptnet modüllerini içerir.
    1. Wintrust modülü, WinVerifyTrust metodu ile yüklenmek istenen assembly’lerin Authenticode imzalı olanlarının güvenilirlik kontorlü yapılır.  Authenticode, .NET’ten bağımsız olan, Microsoft’un exe ve dll’ler için sunduğu HTTPS/SSL olarak düşünülebilir.
    2. crypt32’de bir takım sertifika kontrolü görünüşlü metodların çağrıldığı aşikar.
    3. cryptnet modülü ise webden bir bilgi indirmeye çalışıyor. (Şüphe IV bu noktada oluştu)
  4. Dördüncü grup açık maviler, muhtemelen bir grup IRP(I/O Request Packet)’nin tamamlanmasını senkron olarak bekleyen cryptnet aksamlarına bağlılar.

0:000> kb RetAddr : Args to Child : Call Site 000007fe`fd5710dc : 000007fe`fdebc943 00000000`775c5133 00000000`0018bf68 00000000`00000000 : ntdll!NtWaitForSingleObject+0xa 000007fe`faf9a06a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`000003f8 : KERNELBASE!WaitForSingleObjectEx+0x79 000007fe`faf976da : 00000000`00000000 000007fe`fafabc04 00000000`199a7520 00000000`00003a98 : cryptnet!CryptRetrieveObjectByUrlWithTimeout+0x263 000007fe`fd6948b0 : 00000000`04205004 00000000`00000000 00000000`04205004 000007fe`00003a98 : cryptnet!CryptRetrieveObjectByUrlW+0x20f 000007fe`fd6947de : 00000000`04205004 00000000`00000001 00000000`00000000 00000000`199a7520 : crypt32!ChainRetrieveObjectByUrlW+0x80 000007fe`fd71b5a1 : 00000000`19982a60 00000000`00000000 00000000`00000048 00000000`199a7520 : crypt32!CCertChainEngine::RetrieveAuthRootAutoUpdateObjectByUrlW+0x135 000007fe`fd71bd14 : 00000000`00000006 00000000`1997e7c0 00000000`00000000 000007fe`00000000 : crypt32!CCertChainEngine::WireRetrieveAutoUpdateCab+0x151 000007fe`fd6a9b14 : 00000000`00000000 00000000`0018c240 00000000`00000000 01cdc27c`e93fbf58 : crypt32!CCertChainEngine::GetTimeValidDisallowedCertAutoUpdateCtl+0xe8 000007fe`fd66f046 : 00000000`19982a60 00000000`1997e7c0 00000000`00000000 00000000`19947700 : crypt32!CCertChainEngine::GetChainContext+0x7e 000007fe`fd5e4f70 : 00000000`19982a60 00000000`1997e7c0 00000000`19984094 00000000`48000001 : crypt32!CertGetCertificateChain+0x100 000007fe`fd5e4ccf : 00000000`0018c3a0 00000000`00000000 00000000`0018c348 00000000`00000000 : wintrust!_WalkChain+0x2b2 000007fe`fd5e1f56 : 00000000`00000000 00000000`00000000 00000000`0018c620 00000000`0018c460 : wintrust!WintrustCertificateTrust+0xea 000007fe`fd5e1057 : 00000000`0018c620 000007fe`f9805d23 00000000`00000000 00000000`00000000 : wintrust!WTHelperGetFileHash+0x48e 00000642`ffaf7ed1 : 00000000`0028b7d0 00000000`00000003 00000000`00000000 00000000`00000000 : wintrust!WinVerifyTrust+0x70 000007fe`f7a98aac : 00000000`0028b7d0 00000000`00000000 00000000`00000003 00000000`0018c6f8 : mscorsec!GetPublisher+0x139 000007fe`f77e0ae7 : 00000000`1993c440 000007fe`f77ff322 00000000`00000000 00000000`0018c6f8 : mscorwks! ?? ::FNODOBFM::`string'+0x4499c 000007fe`f77cd94d : 00000000`0000002a 00000000`00000000 00000000`00000000 00000000`00000000 : mscorwks!PEAssembly::DoLoadSignatureChecks+0x37 000007fe`f77d9f80 : 00000000`1993c440 00000002`00000000 00000000`19951320 00000000`0028b6d0 : mscorwks!PEAssembly::PEAssembly+0x12d 000007fe`f77e6481 : 00000000`0000000b 00000000`002444a0 ffffffff`fffffffe 00000000`0025c9b0 : mscorwks!PEAssembly::DoOpen+0x11c 000007fe`f770afda : 00000000`19951320 00000000`0018cc88 00000000`00000000 000007fe`00000000 : mscorwks!PEAssembly::Open+0x71 000007fe`f76fb08a : 00000000`002434f0 00000000`0018cef0 00000000`00000001 00000000`19936ad0 : mscorwks!AppDomain::BindAssemblySpec+0x266 000007fe`f771ee20 : 00000000`1993c0c0 00000000`00000001 00000000`00000000 00000299`00160025 : mscorwks!PEFile::LoadAssembly+0xae 000007fe`f778df38 : 00000000`0025c9b0 00000000`00279170 000007fe`00000022 00000299`00160025 : mscorwks!Module::LoadAssembly+0x120 000007fe`f7768123 : 00000000`02000048 00000008`8f855083 00000000`0018d450 00000000`00000000 : mscorwks!Assembly::FindModuleByTypeRef+0xec 000007fe`f7787490 : 00000000`00000000 00000000`0018d558 00000000`010b6200 000007fe`00000000 : mscorwks!ClassLoader::LoadTypeDefOrRefThrowing+0x4a3 000007fe`f776e76f : 000007ff`00027cd8 00000000`00000001 00000000`0a000039 00000000`0018d880 : mscorwks!ClassLoader::LoadTypeDefOrRefOrSpecThrowing+0x58 000007fe`f776dfc4 : 000007ff`00029710 000007ff`00000006 00000000`010bc6bc 00000000`00000000 : mscorwks!MemberLoader::GetDescFromMemberDefOrRefThrowing+0x51f 000007fe`f776d698 : 00000000`00000001 00000000`0a000039 00000000`5df3edc8 000007fe`f774ca03 : mscorwks!MemberLoader::GetMethodDescFromMemberDefOrRefOrSpecThrowing+0xd4 000007fe`f77642d0 : 00000000`0018e2a0 000007ff`000296b8 000007ff`00000001 00000000`00000001 : mscorwks!CEEInfo::findMethodInternal+0x218 000007fe`f8037659 : 00000000`19e3b818 00000000`0a000039 00000000`0018de00 00000000`00000000 : mscorwks!CEEInfo::findMethod+0xf0 000007fe`f8030ab5 : 00000000`0018de00 00000000`00000028 00000000`0a000039 00000000`0000001e : mscorjit!GenIR::GenIR_FgCall+0x149 000007fe`f803ad43 : 00000000`19e20100 00000000`19e202d8 00000000`5df36074 00000000`0018de00 : mscorjit!ReaderBase::fgBuildPhase1+0x2a5 000007fe`f8018597 : 00000000`00000000 00000000`0018de00 00000000`00000000 00000000`00000000 : mscorjit!ReaderBase::fgBuildBasicBlocksFromBytes+0x93 000007fe`f7feed71 : 00000000`0018e2b8 00000000`19920540 00000000`00100010 00000000`010b8efc : mscorjit!ReaderBase::MSILToIR+0xa7 000007fe`f7fe51e0 : 00000000`0025c9b0 00000000`19951b90 00000000`00274f00 00000000`010b8886 : mscorjit!THX_dop2+0x2a1 000007fe`f77be279 : 00000000`1991d9b0 000007ff`00029710 000007ff`00029710 000007ff`000296b8 : mscorjit!PreJit::compileMethod+0xc0 000007fe`f77a94d2 : 00000000`19920540 000007ff`00029710 00000000`0018e400 00000000`00100010 : mscorwks!invokeCompileMethodHelper+0xd1 000007fe`f77a95c5 : 00000000`00000000 000007ff`000296b8 00000000`00000000 000007fe`00000000 : mscorwks!invokeCompileMethod+0x72 000007fe`f77963cb : 00000000`19920540 00000000`0018e2b8 00000000`00000003 00000000`00100010 : mscorwks!CallCompileMethodWithSEHWrapper+0xbd 000007fe`f7796a1a : 00000000`19930ed0 00000000`00000000 00000000`00000000 00000000`00000000 : mscorwks!UnsafeJitFunction+0x25b 000007fe`f7c30d5c : 000007ff`000296b8 00000002`00000000 00000000`00000000 00000000`00000000 : mscorwks!MethodDesc::MakeJitWorker+0x1ea 000007fe`f777de2a : 48cf9094`0b9ee7b6 00000000`0023d320 00000000`00000000 000007ff`000296b8 : mscorwks!MethodDesc::DoPrestub+0x54c 000007fe`f78c0167 : 00000000`01376fb8 00000000`012e2fa0 00000000`013777c8 00000000`0025c9b0 : mscorwks!PreStubWorker+0x1fa 000007ff`001a0829 : 00000000`013777c8 88cf90a4`cf27b7b6 00000000`00000002 00000000`00000000 : mscorwks!ThePreStubAMD64+0x87 000007ff`001a028f : 00000000`012e2fa0 00000002`18711a00 00000000`0018eba0 00000000`0136cf58 : 0x000007ff`001a0829 000007ff`001a0161 : 00000000`012e2fa0 000007ff`000233d0 00000000`0025fac0 00000000`000000d0 : 0x000007ff`001a028f 000007fe`f78c0282 : 000007ff`000239b8 000007fe`f7773d09 00000000`00000000 000007ff`000239a8 : 0x000007ff`001a0161 000007fe`f77a4363 : 00000000`00000000 000007fe`0000006b 000007fe`f7676a30 00000000`00000000 : mscorwks!CallDescrWorker+0x82 000007fe`f7c9b751 : 00000000`0018edb8 00000000`00000000 00000000`00000001 00000000`00000000 : mscorwks!CallDescrWorkerWithHandler+0xd3 000007fe`f780b097 : 00000000`00000000 000007ff`000239a8 00000000`00000000 00000000`0018f220 : mscorwks!MethodDesc::CallDescr+0x2b1 000007fe`f782e1fc : 00000000`00000000 00000000`00000000 00000010`009a0019 00000000`00000000 : mscorwks!ClassLoader::RunMain+0x22b 000007fe`f7d87a2d : 00000000`0018f810 00000000`00000000 00000000`0026b798 00000000`00000200 : mscorwks!Assembly::ExecuteMainMethod+0xbc 000007fe`f783bd17 : 00000000`00000000 00000000`00000000 00000000`00000000 000007fe`f7858442 : mscorwks!SystemDomain::ExecuteMainMethod+0x47d 000007fe`f781e1c4 : ffffffff`fffffffe 00000000`00000000 0000c275`00000000 00000000`00000000 : mscorwks!ExecuteEXE+0x47 000007fe`f9763309 : ffffffff`ffffffff 00000000`0025c9b0 00000000`00000000 00000000`0018fad8 : mscorwks!CorExeMain+0xac 000007fe`f97f5b21 : 000007fe`f781e118 000007fe`f97632c0 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0x41 00000000`7736652d : 000007fe`f9760000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!CorExeMain_Exported+0x57 00000000`7759c521 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

Şüphe IV

Windows servisi başlatılırken bazı aksamlar internete erişmeye çalışıyor. Windows servisinin hata verdiği sunucuda internet erişimi olmadığı için hemen cevap alamayan aksamlar, kendi zamanaşımlarından önce service control utility(services.msc, sc.exe) uygulamasını zamanaşımına uğratıyor.

Tespit II

Windows servisi işletim sistemi tarafından başlatılırken uygulama ve referansları üzerinde Authenticode dijital imza kontrolü yapılırken internete erişmek istiyor. Bu erişim başarısız olduğundan CryptRetrieveObjectByUrlWithTimeout metoduna geçilen zamanaşımı süresi geçene kadar thread bu metoddan çıkamıyor.

Zamanaşımı süresi, varsa kayıt defterindeki HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout alanından gelecektir. Varsayılan kurulumlarda ServicesPipeTimeout  anahtarı yoktur ve Microsoft kaynaklarında bu değer için kesin bir rakam verilmemekle birlikte “30 saniyeden az” olduğundan bahsedilmektedir.

CryptRetrieveObjectByUrlWithTimeout metoduna geçilen timeout süresi, hex olarak 0x3a98 olup ondalık 15000 değerine karşılık gelmektedir. Bu değerin de 15 saniye olduğu düşünülebilir. Neden kesin yazmıyorum, çünkü CryptRetrieveObjectByUrlWithTimeout metodunun erişebildiğim bir dokümantasyonu yok. Rusça bir kaynakta geçen CryptRetrieveObjectByUrlW metodunun parametre sıralaması ile CryptRetrieveObjectByUrlWithTimeout  parametre sıralamasının en azından timeout değerine kadar aynı olduğunu varsaydım.

Windows, Authenticode kontrolü yapmak zorunda mı?

Windows’u bırakalım, .NET yapmak zorunda mı? .NET’te authenticode mekanizmasını baypas etmenin en az bir yolu var, o da app.config dosyasına yerleşecek bir adet generatePublisherEvidence anahtarı.

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Ama-fakat güvenlik? Microsoft, .NET uygulamalarında Authenticode yerine strong-name signing tavsiye ediyor.

Peki ya uygulamamız native windows uygulaması olsaydı?

Native windows uygulamalarında toptan çözüm olarak domain policyler ile gelebilen SRP ayarlarında değişikliğe gidilebilir. Bu değişiklik, Internet Explorer vasıtası ile de yapılabilir. İşaretli checkbox boş olmalıdır. Dikkat, bu ayar çalınmış sertifikaların kullanıldığı farklı güvenlik zafiyetlerine davetiye çıkartabilir.

image

Meraklısına

Hangi URL Çağrılıyor?

Bir url çağrılıyor ama nasıl bir url, her uygulama hangi URL’i çağırıyor sorusunun cevabını alabilmek için CryptRetrieveObjectByUrlWithTimeout metodunun 3. parametresinin gösterdiği adrese unicode olarak bakmak yeterli.

0:000> du 00000000`199a7520
00000000`199a7520  "http://ctldl.windowsupdate.com/m"
00000000`199a7560  "sdownload/update/v3/static/trust"
00000000`199a75a0  "edr/en/disallowedcertstl.cab"

Hedef URL: http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab

Not: Farklı URL’ler ile de karşılaşıldı.

Hangi Assembly Yüklenmek İstenirken Hata Alınıyor?

Peki bu URL’in çağrılmasına hangi assembly sebep olmuş? Proses imajı mı yoksa referans verilen assembly’lerden biri mi?

mscorsec modülünün GetPublisher metoduna verilen ilk parametreye baktığımızda zanlının Enterprise Library‘nin bir bileşeni olduğunu görüyoruz.

0:000> du 0000000`0028b7d0
00000000`0028b7d0  "D:\XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
00000000`0028b810  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX\Mi"
00000000`0028b850  "crosoft.Practices.EnterpriseLibr"
00000000`0028b890  "ary.ExceptionHandling.dll"

Sonuç

Windows servisine yeni dahil edilen, Authenticode imzalı dll’lerden oluşan Enterprise Library 5.0 bileşenlerinin yüklenirken Authenticode sertifika geçersizlik listelerinin yüklenmek istenmesi neticesinde alınan zamanaşımının neden olduğu service controller zamanaşımı dolayısıyla, Enterprise Library 5.0 referansı olan hiç bir windows servis internet bağlantısı olmayan sunucumuzda çalışmıyordu.

Authenticode imza kontrolü, app.config’e generatePublisherEvidence anahtarı eklenerek baypas edildi.

  • “lokalde çalışıyor”: Windows servisinin geliştirme ortamında internet erişimi mevcut olduğunda Authenticode kontrolleri zamanaşımına yol açmıyordu.
  • “önceden çalışıyordu”: Uygulamada yapılan yükseltme ile Enterprise Library’nin 5.0 sürümüne geçildi. Bu geçişten önce dll’ler Authenticode imzalı olmadığından Authenticode kontrolü yapılmıyordu.
  • “başka sunucuda çalışıyor”: “Başka sunucu” internet erişimli olduğundan Authenticode kontrolü yapılmıyordu

q.e.d.