Yakın zamanda Microsoft'tan gelen bir "Altın Anahtar" sızıntısı ve bir Hata Ayıklama modunun varlığı, Windows cihazlarda güvenli önyüklemenin devre dışı bırakılmasına izin verdi. Okumaya devam etmek!
Windows tabanlı işletim sistemleri artık mobil ortamda varsayılan ve en iyi seçenek değil. Android'in Açık Kaynak doğası, OEM'lerde pek çok hayran buldu ve sonuç olarak, bugünlerde giderek daha az sayıda telefon Windows kullanıyor.
Ancak günlük yaşamınızda hala Windows cihazı kullanmaya devam edenler arasındaysanız size küçük bir haberimiz var. İyi ya da kötü, bu sizin duruşunuza ve bu haberin kullanım senaryolarına ilişkin yorumunuza bağlı olacaktır.
Tarafından bildirildiği gibi Ars Teknik Ve Kayıt kaynaklı bir haberle başınızı ağrıtması muhtemel web sitesi (şaka yapmıyorum), birkaç geliştirici (@never_released Ve @TheWack0lian), Microsoft'un hata ayıklama amacıyla oluşturduğu bir arka kapının, Windows aygıtlarında güvenli önyüklemeyi devre dışı bırakma olanaklarını açtığını keşfetti.
Güvenli Önyükleme ve nedir?
Bir Windows aygıtını ilk kez başlattığınızda, önyükleme prosedürü şu genel sıraya göre gerçekleşir: UEFI (BIOS'un yerine geçen Birleşik Genişletilebilir Ürün Yazılımı Arayüzü) -> Önyükleme Yöneticisi -> Önyükleme Yükleyici -> Pencereler. UEFI, Güvenli Önyükleme işlevinin mevcut olduğu yerdir. Adından da anlaşılacağı gibi Güvenli Önyükleme, dijital imzalar gerektirerek güvenliği artırmayı hedefliyor sonraki adımlarda. Temel olarak, önyükleyici, UEFI'nin beklediği anahtarlarla imzalanmamışsa, cihazınızın önyükleme prosedürü tamamlanmayacaktır.
Güvenli Önyükleme isteğe bağlı bir özelliktir ancak Microsoft, Windows 8 ve sonrasında Windows sertifikası almayı zorunlu hale getirmiştir. Buradaki mantık, Güvenli Önyüklemenin kötü amaçlı yazılım yazarlarının önyükleme prosedürüne kod eklemesini zorlaştırmasıydı. Ancak Güvenli Önyüklemenin bir yan etkisi, Windows makinelerde çift önyüklemeyi biraz karmaşık hale getirmesiydi; ya ikinci işletim sisteminin ve onun tüm ön koşullarının da dijital olarak imzalanması gerekir ya da Güvenli Önyüklemenin engelli. Bununla ilgili pek çok başka sorun var ve deneyimli ikili önyüklemeciler bunlar hakkında benim bir paragrafta açıklayabileceğimden daha fazlasını biliyor olacak.
Artık Güvenli Önyüklemenin kullanıcı istese bile devre dışı bırakamayacağı bazı cihazlar var. Bu, konumuzun tüm Windows aygıtlarında (dahil) büyük ölçüde daraltıldığı alandır. masaüstü bilgisayarlar) Windows Phone cihazları, Windows RT cihazları, bazı Surface cihazları ve hatta gibi belirli Windows cihazlarına HoloLens. Bu son kullanıcı cihazları Güvenli Önyükleme kilitli, yani bir son kullanıcı Güvenli Önyükleme ile ilgili hususları değiştiremez veya devre dışı bırakamazve buna ek olarak Microsoft tarafından son kullanıcı için izin verilmeyen şekillerde işletim sistemine dokunamazlar.
Ancak devam eden resmi geliştirme amaçları doğrultusunda Güvenli Önyükleme'nin biraz gevşetilmesi gerekiyor. Güvenli Önyüklemenin kilitli olduğu cihazlarda, Güvenli Önyüklemeyi devre dışı bırakmaya gerek kalmadan yetkili geliştirmeye yardımcı olabilecek Güvenli Önyükleme İlkeleri mevcuttur. Araştırma yapan kullanıcıların da belirttiği gibi, bu Güvenli Önyükleme Politikası dosyası, Windows için önyükleme işleminin başında Önyükleme Yöneticisi tarafından yüklenir. Politika dosyaları ayrıca, diğer şeylerin yanı sıra politikanın kendisi için yapılandırmaları da içerebilen kayıt defteri kurallarını da içerebilir. Yine, Politika dosyasının imzalanması gerekir ve bu değişiklikleri yalnızca Microsoft'un sağlayabileceğinden emin olmak için başka hükümler de mevcuttur.
İmzalama öğesi aynı zamanda başvuru sırasında kullanılan DeviceID adı verilen şeye de dayanır. Benim için çok açık olmayan birkaç kısım olduğundan, açıklamayı burada blog yazısına bırakıyorum:
Ayrıca DeviceID diye bir şey var. Bu, bazı UEFI PRNG çıktılarının tuzlanmış SHA-256 karma değerinin ilk 64 bitidir. Windows Phone'da ve Windows RT'de ilkeler uygulanırken kullanılır (mobilestartup bunu Phone'da ayarlar ve SecureBootDebug.efi, RT'de ilk kez başlatıldığında). Telefonda politikanın, DeviceID'nin onaltılık biçimini de içeren dosya adı ile EFIESP bölümünde belirli bir yerde bulunması gerekir. (Redstone ile bu, bootmgr tarafından ayarlanan ve yalnızca ham UEFI PRNG çıkışı olan Kilit Kimliği olarak değiştirildi).
Temel olarak, bootmgr politikayı yüklendiğinde kontrol eder; eğer bootmgr'ın çalıştığı cihazın DeviceID'siyle eşleşmeyen bir DeviceID içeriyorsa politikanın yüklenmesi başarısız olur. Test imzalamanın etkinleştirilmesine izin veren herhangi bir politika (MS, bu Perakende Cihaz Kilidini Açma / RDU politikalarını çağırır ve bunları yüklemek bir cihazın kilidini açıyor), bir DeviceID'ye kilitlenmesi gerekiyor (Redstone'da UnlockID ve üstünde). Aslında, buna benzer birkaç politikam var (Windows Phone üretim sertifikası tarafından imzalanmış), burada tek fark, dahil edilen DeviceID ve imzadır. Yüklü geçerli bir politika yoksa, bootmgr, kaynaklarında bulunan varsayılan politikayı kullanmaya geri döner. Bu politika, BCD kurallarını kullanarak test imzalamayı vb. etkinleştirmeyi engelleyen politikadır.
İşlerin ilginçleştiği kısım burası. Windows 10 v1607'nin geliştirilmesi sırasında Microsoft, dahili test ve hata ayıklama amacıyla yeni bir tür Güvenli Önyükleme Politikası (kısa olması açısından bundan sonra SBP olarak anılacaktır) oluşturdu. Bu politika, DeviceID'nin bulunmadığı doğası gereği "tamamlayıcıdır" ve ayarlarının mevcut bir Önyükleme Politikasıyla birleştirilmesine neden olur. Önyükleme Yöneticisi eski SBP türlerini yükler, ardından imzasını ve orijinalliğini doğrular ve ardından bu ek önyükleme politikalarını yükler. Buradaki sorun, ek politikanın kendisi hakkında daha fazla doğrulamanın olmamasıdır. Ayrıca, Windows 10 v1511'den önceki Önyükleme Yöneticileri bu politikaların tamamlayıcı niteliğinin varlığından haberdar değildir ve bu nedenle, tamamen geçerli ve imzalı bir politika yüklemişler gibi tepki verin. Tekrar ediyorum, bu davranış muhtemelen dahili geliştirmeyle ilgiliydi, dolayısıyla geliştiricilerin her işletim sistemi sürümünü ve cihazda yapmak zorunda oldukları küçük değişiklikleri imzalamaları gerekmemeliydi.
Bu SBP, temelde imza kontrollerinin amacını geçersiz kıldığı için "Altın Anahtar" olarak adlandırılıyor. Bu SBP, devre dışı bırakılmış bir durumda olmasına rağmen, perakende cihazlarda istemeden de olsa gönderildi. Geliştiriciler bu SBP'yi buldular ve bulgularını duyurdular. Artık SBP olabilir internette dolaşırken buldum, bu özel zip SBP'yi Windows RT cihazlarına yüklemek için kullanılıyor.
Bu ne anlama gelir?
Ek bir SBP yüklediyseniz imzasız sürücüleri yüklemenize izin vermek için Windows için test imzalamayı etkinleştirebilirsiniz. Ayrıca, bu Politikalar, önyükleme prosedüründe Önyükleme Yöneticisi aşamasından önce devreye girdiğinden, tüm siparişin güvenliğini tehlikeye atabilir ve yetkisiz (okuma kendinden imzalı) kod çalıştırabilirsiniz. Bu, Windows'un bazı kısımlarını yetkisiz olarak değiştirmek isteyen kullanıcılar ve benzer şekilde kötü amaçlı yazılım yaratıcıları için birçok olasılığın önünü açar.
Bu bulgunun yazarları tüm fiyaskonun ironisine odaklanıyor. Microsoft, yetkisiz değişiklikleri uzak tutmak için belirli cihazlarda Güvenli Önyüklemeyi kilitledi, ancak daha sonra geliştirme ve hata ayıklamaya devam etmelerine izin vermek için bir arka kapı oluşturdu. Ancak bu arka kapı, Windows çalıştıran tüm cihazlarda Güvenli Önyüklemenin devre dışı bırakılmasının önünü açarak tüm çileyi anlamsız hale getiriyor.
Artık istekli kullanıcılar Linux dağıtımlarını (ve muhtemelen Android'i) yalnızca Windows'lu Tabletlere yüklemekle kalmıyor ve İsteksiz kullanıcılar, telefonlarına fiziksel erişimi tehlikeye atarlarsa kötü amaçlı önyükleme kitleri de yükleyebilir. cihaz. Birincisi havaya sıçrayabileceğimiz bir şey olsa da ikincisi pek fazla güven vermiyor. Her iki yönde de geçerli ve bize güvenliğin neden iki ucu keskin bir kılıç olduğunu gösteriyor. Dahası, SBP doğası gereği evrenseldir ve mimariden bağımsız olarak herhangi bir cihazda kullanılmasına izin verir. Güvenli Önyüklemenin kolayca kapatılabileceği masaüstü bilgisayarlar için özellikle kullanışlı değildir, ancak Güvenli Önyükleme ile uğraşamayacağınız cihazlar için çok geniş bir kapsama sahiptir.
Peki çözüm nedir?
Microsoft bazı yamalar yayınladı ancak geliştiriciler sorunun tamamen çözülmediği konusunda ısrar ediyor. Bu yamalara göz atabilirsiniz (MS16-094 Ve MS16-100) ve ardından konuyu okuyun Blog yazısı sorunu neden çözmedikleri konusunda. Eğer bunlar doğruysa, bu soruna yönelik bir düzeltme veya yama görünmüyor ancak bu, Microsoft'un yola daha fazla engel koymaya çalışmasını engellemeyecek.
Sırada ne var?
Bir olasılıklar dünyası var ve bunlardan bazıları Windows Forumlarımızda hazırlanıyor. Forumlarımıza göz atabilirsiniz Windows Phone 8 Geliştirme ve Hackleme ve forumlarımız Windows 8, Windows RT ve Yüzey Geliştirme ve Bilgisayar Korsanlığı. Ayrıca bulabilirsiniz bazı cihazlar için talimat konuları, diğer kullanıcıların da aynı şeyi tartıştığı yer.
Bu hata ayıklama arka kapısının varlığı ve SBP'nin sızıntısı yalnızca üçüncü taraflar için önemli değildir. Kilitli Windows cihazlarının geliştirilmesi, aynı zamanda kasıtlı olarak kilitlenirse neler olabileceğine dair bize sert bir hatırlatma da gösteriyor. arka kapılar kaldı. Son zamanlarda güvenlik konusundaki odak noktası, soruşturma kurumlarının yasal soruşturma amaçlarına yardımcı olmak için kullanılacak bu tür arka kapıların varlığı için baskı yapmasına yöneldi. Ancak er ya da geç bu yöntemler irade yanlış ellere düşmek. Suçla mücadele ve adalete yardım aracı olarak kullanılması amaçlanan şey, bir gün bizzat suçun aracı haline gelecektir.
Debug SBP'nin sızıntısı hakkında düşünceleriniz neler? Bunlar gibi "Altın Anahtarların" var olması gerektiğini düşünüyor musunuz? Aşağıdaki yorumlarda bize bildirin!