Güvenlik araştırmacısı, Microsoft'un BitLocker'a bir arka kapı eklediğini söyleyerek exploit'i yayımladı

 (techspot.com)
2 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Güvenlik araştırmacısı Nightmare-Eclipse, YellowKey'i yayımlayarak BitLocker tam birim şifrelemesinin parola olmadan aşılabildiğini açıkladı
  • YellowKey, FsTx klasörü Windows uyumlu bir dosya sistemine sahip USB sürücüye kopyalandıktan sonra WinRE'de belirli bir sıralama izlenerek yeniden üretilebiliyor
  • Süreç tamamlandığında bir komut kabuğu açıldığı ve BitLocker korumalı birimlerde gezinme, kopyalama ve dosya işlemleri yapılabildiği aktarılıyor
  • Nightmare-Eclipse, bu atlatma davranışının yalnızca resmî WinRE imajında görüldüğünü belirterek kasıtlı bir arka kapı olasılığını gündeme getiriyor
  • Etkilenen sürümlerin Windows 11, Server 2022, Server 2025 olduğu, Windows 10'un ise etkilenmediği ekleniyor

YellowKey'in çalışma koşulları

  • Güvenlik araştırmacısı Nightmare-Eclipse, YellowKey'i yayımlayarak BitLocker'ın tam birim şifrelemesinin tamamen aşılabildiğini açıkladı
  • YellowKey, ekli FsTx klasörü NTFS, FAT32, exFAT gibi Windows uyumlu dosya sistemleriyle biçimlendirilmiş bir USB sürücüye kopyalanarak yeniden üretilebiliyor
  • USB sürücü olmadan da FsTx dosyaları Windows EFI bölümüne kopyalanıp şifreli disk sistemden geçici olarak ayrılırsa çalışabildiği aktarılıyor
  • Ardından BitLocker ile korunan sistem yeniden başlatılıp Windows Recovery Environment(WinRE) içine girildikten sonra belirli bir giriş sırası izlenmeli
  • İşlem doğru şekilde tamamlanırsa bir komut kabuğu açılıyor ve parola olmadan BitLocker korumalı birimlerde gezinme, kopyalama ve diğer dosya işlemleri yapılabildiği belirtiliyor

Arka kapı şüphesinin dayanakları

  • Nightmare-Eclipse, YellowKey'in daha önce bilinmeyen bir güvenlik hatası olarak görülmeyecek kadar sıra dışı olduğunu ve Microsoft'un BitLocker veri koruma sistemine meşru bir arka kapı yerleştirmiş olabileceğini öne sürüyor
  • Gerekçe olarak, soruna yol açan bileşenlerin yalnızca resmî WinRE imajında bulunmasını gösteriyor
  • Aynı bileşenlerin standart Windows kurulum imajında da yer aldığı, ancak gerçek sistemlerde gözlenen BitLocker atlatma davranışının ortaya çıkmadığı belirtiliyor
  • Nightmare-Eclipse, “Bunun kasıtlı olduğu gerçeği dışında bir açıklama düşünemiyorum” dedi ve Windows 10'un etkilenmediğini, yalnızca Windows 11, Server 2022, Server 2025 sürümlerinin etkilendiğini ekledi

Dış doğrulama ve ek yayımlar

  • Üçüncü taraf araştırmacıların, Nightmare-Eclipse'in GitHub materyallerinde anlatılan yöntemle YellowKey'in çalıştığını doğruladığı aktarılıyor
  • Nightmare-Eclipse, yetki yükseltmeye imkân tanıdığı belirtilen ikinci exploit GreenPlasma'yı da yayımladı
  • GreenPlasma için SYSTEM düzeyinde erişim sağlayan tam kavram kanıtı kodu paylaşılmadı; ancak gelecek ayki Patch Tuesday öncesinde ek ayrıntıların açıklanabileceği ima edildi

Azaltma yönü

  • YellowKey'in arka kapı benzeri davranışına ilişkin şüpheleri azaltmanın görece basit olduğu belirtiliyor
  • Güvenlik uzmanları, yalnızca tek bir şifreleme sistemine güvenilmemesini ve iyi incelenmiş tam disk şifreleme alternatiflerinin de değerlendirilmesini öneriyor
  • Örnek olarak VeraCrypt veriliyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • Bu açığı bulan araştırmacı Nightmare-Eclipse'in yazılarına bakınca, olayın neredeyse bir haftadır sürdüğü anlaşılıyor
    12 Mayıs 2026 Salı günü “bu kez iki açık var [YellowKey] [GreenPlasma] [...] bir sonraki Patch Tuesday'de Microsoft'u büyük bir sürpriz bekliyor” dedi, 13 Mayıs 2026 Çarşamba günü ise “tüm hikâyeyi açıklayabildiğimde insanlar patlamamın oldukça makul olduğunu görecek ve bu Microsoft için hiç de iyi görünmeyecek” diye yazdı
    Yazarın blogu: https://deadeclipse666.blogspot.com/
    Mart 2026'daki ilk yazıda da “birileri anlaşmamızı bozdu, ben ise parasız kaldım ve evimi kaybettim. Bunun böyle olacağını bilmelerine rağmen beni sırtımdan bıçakladılar. Bu benim kararım değil, onların kararı” tarzı ifadeler var
    Buna nasıl bakmak gerektiğinden emin değilim ama bir içeriden birinin fiilen “sızdırması” gibi de geliyor ve başkaları da sonuçları yeniden üretebiliyor gibi görünüyor

    • İçeriden biri olmaktan ziyade, Microsoft ile açık ifşa süreci yürütürken bir nedenle öfkelenip bunu yayımlamış gibi okunuyor
    • Bu konu HN'de zaten birkaç kez tartışıldı, örneğin burada: https://news.ycombinator.com/item?id=48130519
      Bunun bir backdoor olup olmadığı, sonuçta her zamanki “bug mı backdoor mu” bakışınıza bağlı ve teknoloji medyasının sevdiği türden “Microsoftsa 1, BitLocker hacklendi” diye özetlenecek basit bir hikâye değil
      Özünde mesele, Windows Recovery Environment WinRE içindeki NTFS transaction log replay işlevindeki bir bug; bu sayede harici bir volume'deki NTFS transaction log'u okunup mount edilmiş dosya sistemine uygulanabiliyor. Bunun sonucu olarak saldırgan WinRE kimlik doğrulamasını atlatabiliyor
      PIN veya parola olmadan kullanılan BitLocker'da herhangi bir kimlik doğrulama atlatması, disk şifrelemesini de atlatmak anlamına geliyor. Çünkü bootloader diski zaten unseal ediyor; aynı yapısal “kusur” aynı ayardaki Linux için de geçerli. Örneğin Ubuntu kurulumundaki nispeten yeni Hardware Disk Encryption kutucuğu kullanıldığında da durum aynı
      Ek kanıt olmadan, NTFS transaction log meselesinin yerleştirilmiş bir backdoor mu yoksa sıradan bir enum bug'ı mı olduğu, exploit geliştirmede sık görülen komplo seviyesiyle ilgili. Bana göre makul bir bug gibi görünüyor; boot sırasında unseal zafiyeti zaten iyi bilinen ve bariz bir şey, o yüzden bunu dünyayı sarsacak bir ifşa olarak görmüyorum ama ilginç bir bug olduğu kesin
    • Gerçekte ne yaşandığını ve bu kişinin neden böyle M$'ı ifşa etme noktasına geldiğini anlatan blog yazısını bir an önce okumak istiyorum

  • Daha iyi bir özet: https://infosec.exchange/@wdormann/116565129854382214
    Yayımlanan exploit, PIN kullanan BitLocker'ı etkilemiyor. PIN yoksa BitLocker zaten güvenli değil
    Asıl yazar, PIN olsa da çalışan bir exploit'i olduğunu iddia ediyor ama henüz bunun kanıtını sunmadı

    • Şirketiniz PIN zorunlu tutuyor mu? Daha da önemlisi, şirketinizin para ödediği siber sigorta şirketi PIN istiyor mu?
      BitLocker için PIN zorunlu kılan bir şirket görmedim
    • BitLocker'da PIN'in bir seviye üstü de var; açılışta kullanılan anahtarı taşıyan bir USB stick ayarlanabiliyor. Veri cihazda saklanmadığı için bunun bu saldırıya karşı güvenli olması gerekir gibi görünüyor
    • PIN'li sürüm iddiasının doğru olduğunu varsayarsak, neden PIN'li sürüm yerine zayıflatılmış, işe yaramaz sürümü yayımladığı ilginç. Aklıma birkaç şey geliyor ama hiçbirinin dayanağı yok

  • Kaynak: https://infosec.exchange/@wdormann/116565129854382214
    “Tipik bir WinRE oturumunda X:\Windows\System32 dizini vardır ve içinde winpeshl.ini dosyası bulunur”
    “Ama YellowKey exploit'inde, USB sürücüsündeki Transactional NTFS parçalarının başka bir sürücüdeki winpeshl.ini dosyasını silebildiği görülüyor”
    İlginç. Bu ortamı iyi bilmiyorum ama safça düşününce mesele dosya handle'ı oluşturma ya da aktarma sorunu olabilir mi? Öyleyse WinRE yeniden başlatılırken neden klavye girişi gerekiyor?
    Bunun ne kadar yamanabileceğini de merak ediyorum. Sayısız WinRE USB sürücüsüne dokunmak mümkün olmayacaktır; acaba BitLocker tarafında erişim izinleri güncellenebilir mi? Şifre çözme/yeniden şifreleme gerekir mi? Görünen o ki daha çok şey çıkacak

    • Eksik kalan nokta, WinRE'nin neden yetki sahibi olduğu. Windows, şifre çözme anahtarını TPM'e koyuyor, böylece WinRE kurtarma anahtarı olmadan da diski çözebiliyor
      Bu yüzden saldırı Ubuntu live CD gibi bir şeyle boot etmekten değil, özellikle WinRE gerektiriyor
      Ayrıca mevcut tüm WinRE USB sürücülerini yamalamak gerekmiyor. Secure Boot imzası iptal edilirse TPM doğrulamasını geçemez ve dolayısıyla hiçbir diski çözemez

  • “Güvenlik uzmanları genel olarak tek bir şifreleme sistemine bel bağlamamayı ve VeraCrypt gibi iyi incelenmiş tam disk şifreleme alternatiflerini değerlendirmeyi önerir”
    Eğer FDE'ye bir backdoor koydularsa, insanlara doğrudan Windows kullanmayı bırakıp Linux'a geçmelerini söylemek daha mantıklı olur
    FDE'ye backdoor koydularsa, işletim sisteminin kendisinde de yalnızca bir tane olmadığını varsaymak gerekir. Kapalı kaynak yazılımlara hiç güvenilmemeli; düzgün denetlenmemiş açık kaynaklara da güvenilmemeli

    • Genelde Microsoft ürünleri kullanmıyorum ama kendi bilgisayarında bile VeraCrypt çalıştırmazdım
    • Ya da açık kaynak olan VeraCrypt gibi bir şey kullanırsın

  • Bu, BitLocker'a özgü bir sorundan çok oturum açma atlatma meselesi gibi görünüyor. PIN olmadan TPM'e dayanıldığında çözme işlemi otomatik oluyor
    Normalde saldırganın oturum açma ekranını geçememesi gerekir, dolayısıyla sorun olmamalı; ancak bu exploit kurtarma ortamında sınırsız bir shell elde etmenin yolunu gösteriyor gibi duruyor
    Araştırmacı PIN'i de atlatan bir yöntem olduğunu söylüyor ama henüz yayımlamadı

    • İfşa sürecinden ödül çıkmadığı için, para verecek birine satmanın daha iyi olacağını düşünmüş olabilir

  • Güvenlik uzmanları “Microsoft ürün güvenliği” rollerini ne zaman reddetmeye başlayacak acaba? Ben o noktaya çoktan geldim
    Microsoft ürün güvenliği, MS'in çılgın teknik borcu ve açgözlülüğünün bir sonraki dalgasında yeniden çökene kadar insanı meşgul eden bir işten ibaret. Artık bir de backdoor var

    • O bir “güvenlik” rolü değil, compliance rolü. Kurumsal müşterilerin çoğunun gerçekten önemsediği tek şey bu
      Tüm compliance kurallarını yerine getirmiş, MS etkisindeki “best practice”leri izlemiş oluyorsun; böylece ne olursa olsun sorumluluk sende kalmıyor
    • iOS da varsayılan olarak uçtan uca şifrelenmemiş iCloud yedekleri oluşturuyor; bu yüzden kolluk kuvvetleri sohbetleri, tarayıcı geçmişini vb. talep edebiliyor. Signal bunun dışında kalıyor
      Uçtan uca şifreli yedekler için ADP'yi açabilirsin ama konuştuğun kişilerin bunu açmamış olması muhtemel, dolayısıyla pek yardımcı olmayabilir
      Microsoft'u savunmaya çalışmıyorum; söylemek istediğim, bu şirketlerin hepsinin PRISM'in bir parçası olduğudur
    • Kurumsal pazarda bununla kazanılan para o kadar büyük ki, insanların sırf uğraştırıcı diye işi reddetmeye başlayacağını sanmıyorum
    • “Artık bir de backdoor var” mı? “Artık” mı?
      Geçmişte Windows NT'nin bir sürümü yanlışlıkla debug symbols açık halde çıktığında, Microsoft'un “yedek anahtar” dediği anahtarın adının neden ..._NSAKEY olduğundan bahsedelim mi
      Sadece bir kez, gerçekten sadece bir kez Windows debug symbols açık halde yayımlandı ve tesadüfen şifreleme anahtarının adı “NSAKEY” çıktı
      Elbette devletin yanlışlarını görmezden gelmeye devam edenler bunun tamamen normal olduğunu söyleyecek ve o dönem Microsoft'un özenle hazırladığı “backdoor değil” savunmasını aynen tekrarlayacaktır

  • Exploit'i biraz daha inceleyince, bunun yalnızca TPM modundaki BitLocker'ı hedeflediği görülüyor. Yani pre-boot authentication gibi bir şey yok
    Secure Boot boot zincirini doğruladığında TPM şifreleme anahtarını kendiliğinden veriyor. Fiziksel erişim varsa büyük bir fark kalmıyor
    İstersen exploit yüklü bir USB ile boot edip acil shell alırsın, istersen 5 dolarlık bir mikrodenetleyici alıp anakarttaki belirli pinlere lehim yaparak TPM anahtarını sniff edersin
    Microsoft genel olarak güvensiz bir şeyi tam disk şifreleme diye satıyor. Bir flash sürücüye exploit koyup shell alarak dosyaları tarayıp kopyalayabilecek biri, bir mikrodenetleyici alıp YouTube'da lehim videosu izleyerek bunu da yapabilir
    Dolayısıyla sorun “exploit”in kendisi değil, Microsoft'un sattığı sahte güvenlik hissi

    • “Boot edilebilir bir stick ile acil shell'e girmek” yöntemi işe yaramaz. TPM, anahtarı yalnızca “onaylı” bir işletim sistemi boot ettiğinde verir; daha spesifik olarak, şifreleme anahtarının bağlı olduğu PCR state eşleşmelidir
      5 dolarlık mikrodenetleyiciyle belirli pinlere lehim yapıp TPM anahtarını sniff etmek yalnızca dTPM'de mümkündür. fTPM buna açık değildir ve dTPM'den çok daha yaygındır
    • Ubuntu da birkaç sürüm önce TPM tabanlı FDE sundu. O zaman da aklımdan aynı şey geçtiği için kullanmamaya karar verdim
      Boot sırasında bir passphrase yazmak zaten kas hafızası haline gelmiş durumda ve güvenilebilecek kadar basit bir güvenlik sağlıyor
      Anakart olmadan da veriyi kurtarabiliyorsun
      Günlük kullanım için, evil maid saldırılarını önlemek adına Secure Boot+TPM+passphrase birleşimi bir slot ve yanında bir yedek passphrase slot'u olan hibrit bir yapı makul olabilir
    • TPM+PIN exploit'i olduğunu da iddia ediyor ama bunun güvenilir olup olmadığını görmek lazım
      https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
    • Linux LUKS da tam olarak aynı şekilde yapılandırılabilir
      Bu, BitLocker'a yönelik bir saldırıdan çok Secure Boot zincirine yönelik bir saldırı gibi görünüyor
      PIN'siz kilit açmanın değeri, tehdit modelinin disk imhası, diskin sökülmesi veya TPM ile diskin birbirinden ayrılması gibi durumlarla sınırlı olduğunda ortaya çıkar
      Cihaz düzenli olarak birden fazla kullanıcı tarafından kullanılıyorsa PIN girmek rahatsız edici ya da imkânsız olabilir. Bu yüzden erişim doğrulama kontrolü güvenilen işletim sistemi bileşenlerine devredilmiş olur
    • Oldukça ciddi bir bug ama BitLocker yine de tam disk şifrelemedir. Sadece kimlik doğrulama atlatılabiliyor

  • “TrueCrypt kullanımı güvenli değildir ve düzeltilmemiş güvenlik sorunları içerebilir” cümlesini hatırlayan var mı? ;)

    • TrueCrypt/VeraCrypt akla geliyor. Muhtemelen daha güvenli bir şifreleme çözümü olma ihtimali yüksek. Bu olaydan sonra kesinlikle daha güvenli görünüyor