Niedawny wyciek „Złotego klucza” firmy Microsoft w połączeniu z obecnością trybu debugowania umożliwił wyłączenie bezpiecznego rozruchu na urządzeniach z systemem Windows. Czytaj!
Systemy operacyjne oparte na systemie Windows nie są już domyślnym i najpopularniejszym wyborem na scenie mobilnej. Otwarty charakter Androida znalazł wielu fanów wśród producentów OEM, w wyniku czego coraz mniej telefonów korzysta obecnie z systemu Windows.
Jeśli jednak należysz do osób, które nadal na co dzień korzystają z urządzenia z systemem Windows, mamy dla Ciebie dobrą wiadomość. Dobre czy złe, to zależy od twojego stanowiska i interpretacji przypadków użycia tych wiadomości.
Jak donosi Ars Technica I Rejestr z wiadomościami pochodzącymi od a strona internetowa, która prawdopodobnie przyprawi Cię o ból głowy (nie żartuję), kilku programistów (@nigdy_wydany I @TheWack0lian) odkryli, że backdoor, który Microsoft włączył do celów debugowania, otworzył możliwości wyłączenia bezpiecznego rozruchu na urządzeniach z systemem Windows.
Bezpieczny rozruch i co to jest?
Podczas pierwszego uruchomienia urządzenia z systemem Windows procedura uruchamiania przebiega w następującej ogólnej kolejności: UEFI (Unified Extensible Firmware Interface, który zastępuje BIOS) -> Boot Manager -> Boot Loader -> Okna. UEFI to miejsce, w którym dostępna jest funkcja bezpiecznego rozruchu. Jak sama nazwa wskazuje z Bezpieczny rozruch, ma na celu poprawę bezpieczeństwa poprzez wymaganie podpisów cyfrowych na kolejnych etapach. Zasadniczo, jeśli program ładujący nie jest podpisany kluczami, jakich oczekuje UEFI, procedura uruchamiania urządzenia nie zostanie zakończona.
Bezpieczny rozruch to funkcja opcjonalna, ale firma Microsoft wprowadziła obowiązek jej włączenia w celu uzyskania certyfikatu systemu Windows od wersji Windows 8 i nowszych. Powodem było to, że Secure Boot utrudni autorom złośliwego oprogramowania wstawienie kodu do procedury rozruchu. Jednak efektem ubocznym Bezpiecznego rozruchu było to, że nieco skomplikowało to podwójny rozruch na komputerach z systemem Windows, ponieważ albo drugi system operacyjny i wszystkie jego wymagania wstępne również muszą być podpisane cyfrowo, albo konieczne będzie Bezpieczne uruchamianie wyłączony. Jest z tym wiele innych problemów i doświadczeni miłośnicy dual-bootów wiedzieliby o nich więcej, niż mógłbym wyjaśnić w jednym akapicie.
Obecnie istnieje kilka urządzeń, na których użytkownik nie może wyłączyć funkcji Secure Boot, nawet gdyby chciał. Jest to obszar, w którym nasza tematyka zostaje drastycznie zawężona na wszystkich urządzeniach z systemem Windows (w tym komputery stacjonarne) do określonych urządzeń z systemem Windows, takich jak urządzenia z systemem Windows Phone, urządzenia z systemem Windows RT, niektóre urządzenia Surface, a nawet HoloLens. Te urządzenia użytkowników końcowych mają Bezpieczny rozruch zablokowany, co oznacza, że użytkownik końcowy nie może modyfikować ani wyłączać aspektów związanych z Bezpiecznym rozruchem, a co za tym idzie, nie mogą dotykać systemu operacyjnego w sposób nieautoryzowany przez firmę Microsoft dla użytkownika końcowego.
Jednak na potrzeby ciągłego oficjalnego rozwoju Secure Boot musi trochę rozluźnić się. Na urządzeniach z zablokowaną funkcją Bezpieczny rozruch istnieją zasady bezpiecznego rozruchu, które mogą pomóc w autoryzowanym programowaniu bez konieczności wyłączania funkcji Bezpieczny rozruch. Jak wspominają badający użytkownicy, ten plik zasad bezpiecznego rozruchu jest ładowany przez Menedżera rozruchu na początku procesu uruchamiania systemu Windows. Pliki zasad mogą również zawierać reguły rejestru, które z kolei mogą zawierać między innymi konfiguracje samej polityki. Ponownie plik zasad musi zostać podpisany i istnieją inne postanowienia zapewniające, że tylko firma Microsoft może zapewnić te zmiany.
Element podpisujący opiera się również na tak zwanym identyfikatorze urządzenia, który jest używany podczas stosowania. Pozwolę, aby post na blogu wyjaśnił tutaj, ponieważ jest kilka części, które nie są dla mnie tak jasne:
Istnieje również coś takiego jak DeviceID. To pierwsze 64 bity solonego skrótu SHA-256 niektórych danych wyjściowych UEFI PRNG. Jest używany podczas stosowania zasad w systemie Windows Phone i Windows RT (mobilestartup ustawia go na telefonie, a plik SecureBootDebug.efi jest uruchamiany po raz pierwszy w systemie RT). W telefonie polityka musi znajdować się w określonym miejscu na partycji EFIESP z nazwą pliku zawierającą identyfikator urządzenia w postaci szesnastkowej. (W przypadku Redstone zmieniono to na UnlockID, który jest ustawiany przez bootmgr i jest po prostu surowym wyjściem UEFI PRNG).
Zasadniczo bootmgr sprawdza politykę podczas ładowania. Jeśli zawiera identyfikator urządzenia, który nie jest zgodny z identyfikatorem urządzenia, na którym działa bootmgr, załadowanie polityki nie powiedzie się. Wszelkie zasady umożliwiające włączenie podpisywania testowego (MS nazywa te zasady dotyczące odblokowania urządzeń detalicznych/RDU i do ich zainstalowanie oznacza odblokowanie urządzenia), ma być przypisane do identyfikatora urządzenia (UnlockID na Redstone i powyżej). Rzeczywiście, mam kilka takich polityk (podpisanych certyfikatem produkcyjnym Windows Phone), w których jedynymi różnicami są zawarte ID urządzenia i podpis. Jeśli nie ma zainstalowanej prawidłowej polityki, bootmgr powróci do korzystania z domyślnej polityki znajdującej się w jego zasobach. Ta polityka blokuje możliwość podpisywania testów itp. przy użyciu reguł BCD.
To jest ta część, w której robi się ciekawie. Podczas opracowywania systemu Windows 10 v1607 firma Microsoft stworzyła nowy typ zasad bezpiecznego rozruchu (odtąd dla zwięzłości nazywanych SBP) na potrzeby wewnętrznych testów i debugowania. Polityka ma charakter „uzupełniający” i nie zawiera identyfikatora urządzenia, co powoduje połączenie jej ustawień z istniejącą polityką rozruchu. Menedżer rozruchu ładuje starsze typy protokołu SBP, następnie sprawdza jego podpisanie i autentyczność, a następnie ładuje dodatkowe zasady rozruchu. Problem polega na tym, że nie ma dalszej weryfikacji samej polisy dodatkowej. Ponadto menedżery rozruchu starsze niż Windows 10 v1511 nie wiedzą o istnieniu uzupełniającego charakteru tych zasad, a zatem reagują tak, jakby załadowali całkowicie ważną i podpisaną polisę. Ponownie, takie zachowanie było prawdopodobnie spowodowane wewnętrznym rozwojem, więc programiści nie powinni byli podpisywać każdej wersji systemu operacyjnego i drobnych zmian, które musieli wprowadzać na urządzeniu.
Ten SBP nazywany jest „złotym kluczem”, ponieważ zasadniczo niweczy cel kontroli podpisów. Ten SBP został przypadkowo dostarczony na urządzenia detaliczne, aczkolwiek w stanie dezaktywowanym. Twórcy znaleźli ten SBP i udostępnili swoje ustalenia. Teraz SBP może być znalezione krążące po internecie, przy czym ten konkretny plik zip jest używany do instalowania SBP na urządzeniach z systemem Windows RT.
Co to znaczy?
Jeśli załadowałeś dodatkowy plik SBP, możesz włączyć podpisywanie testów dla systemu Windows, aby umożliwić ładowanie niepodpisanych sterowników. Co więcej, ponieważ zasady te wchodzą w życie przed etapem Boot Managera w procedurze rozruchu, możesz naruszyć bezpieczeństwo całego zamówienia i uruchomić nieautoryzowany (czytaj z podpisem własnym) kod. Otwiera to wiele możliwości zarówno dla użytkowników zamierzających modyfikować części systemu Windows w sposób wykraczający poza autoryzację, jak i dla twórców złośliwego oprogramowania.
Autorzy tego ustalenia skupiają się na ironii całego fiaska. Firma Microsoft zablokowała opcję Bezpiecznego rozruchu na niektórych urządzeniach, aby zachować daleko idące nieautoryzowane zmiany, ale następnie dodała backdoora, aby umożliwić dalszy rozwój i debugowanie. Ale to właśnie backdoor toruje drogę do wyłączenia bezpiecznego rozruchu na wszystkich urządzeniach z systemem Windows, przez co całe to doświadczenie staje się bezcelowe.
Chętni użytkownicy mogą teraz nie tylko instalować dystrybucje Linuksa (i ewentualnie Androida) na tabletach obsługujących wyłącznie system Windows i Na telefonach niechciani użytkownicy mogą również zainstalować złośliwe bootkity, jeśli naruszą fizyczny dostęp do swoich danych urządzenie. O ile w przypadku tego pierwszego możemy wznieść się w powietrze, to drugie nie budzi zbytniej pewności siebie. To działa w obie strony i pokazuje nam, dlaczego bezpieczeństwo to miecz obosieczny. Co więcej, SBP ma charakter uniwersalny, umożliwiając jego użycie na dowolnym urządzeniu, niezależnie od architektury. Nie jest to szczególnie przydatne w przypadku komputerów stacjonarnych, na których można łatwo wyłączyć Bezpieczny rozruch, ale ma ogromne możliwości w przypadku urządzeń, w których nie można bawić się Bezpiecznym rozruchem.
Więc jakie jest rozwiązanie?
Microsoft wypuścił kilka poprawek, ale programiści twierdzą, że problem nie został całkowicie rozwiązany. Możesz sprawdzić te poprawki (MS16-094 I MS16-100), a następnie przeczytaj dalej post na blogu się, dlaczego nie rozwiązują problemu. Jeśli są prawidłowe, nie widać rozwiązania tego problemu ani łatki, co jednak nie powstrzymuje Microsoftu od prób umieszczania kolejnych przeszkód na drodze.
Co następne?
Możliwości jest mnóstwo, a niektóre z nich rodzą się na naszych forach Windows. Możesz sprawdzić nasze fora na Rozwój i hakowanie systemu Windows Phone 8 i nasze fora Windows 8, Windows RT oraz rozwój i hakowanie powierzchni. Można również znaleźć wątki instruktażowe dla niektórych urządzeń, gdzie inni użytkownicy dyskutują o tym samym.
Obecność tego backdoora do debugowania i wyciek SBP są ważne nie tylko dla strony trzeciej rozwoju zablokowanych urządzeń z systemem Windows, pokazują nam także ponure przypomnienie tego, co może się stać, jeśli jest to działanie celowe pozostały tylne drzwi. Ostatnio skupiono się na bezpieczeństwie w kierunku agencji dochodzeniowych nalegających na obecność takich tylnych drzwi, które mogłyby pomóc im w dochodzeniowych celach prawnych. Ale prędzej czy później te metody będzie wpaść w niepowołane ręce. To, co ma służyć jako narzędzie walki z przestępczością i wspomagania wymiaru sprawiedliwości, pewnego dnia stanie się narzędziem samej zbrodni.
Jakie są Twoje przemyślenia na temat wycieku Debug SBP? Czy uważasz, że takie „Złote Klucze” powinny istnieć? Daj nam znać w komentarzach poniżej!