Jak dwóch naszych rodaków uparło się by odblokować BIOS laptopa


To jedna z najlepszych historii, jakie kiedykolwiek słyszeliśmy. Jest w niej hakowanie sprzętu, inżynieria wsteczna, kryptografia i godny podziwu upór dwóch panów, którzy bardzo chcieli odblokować laptopa Toshiby. I zajęło im to tylko trzy lata.

Historię pierwszy raz mieliśmy przyjemność usłyszeć na żywo prawie rok temu, na konferencji Security PWNing 2017. Temat był jednak na tyle złożony, że z publikacją artykułu czekaliśmy na publikację nagrania prezentacji, by zweryfikować, czy wszystko dobrze zapamiętaliśmy. Nagranie jest już dostępne, więc czas na opisanie tej niecodziennej podróży dwóch fanatyków.

Początki historii

Jeśli macie 50 minut, to warto obejrzeć oryginalne nagranie. Niestety ścieżka głosowa przynajmniej częściowo nie pochodzi z mikrofonów prelegentów, przez co nie jest to najłatwiejsze. Ale, jak mówią Chińczycy, lepszy ryż niż niż – nagranie poniżej, a pod nim wersja dla osób, które nie mają 50 minut wolnego lub cierpią, słuchając dudnienia słabego nagrania. My przecierpieliśmy dla Was.

Bohaterami historii są Michał „Redford” Kowalczyk, Sergiusz „q3k” Bazański oraz laptop Toshiba Portégé R100. Do Sergiusza zgłosił się kiedyś ktoś z prośbą o zresetowanie hasła w laptopie. To pozornie łatwe zadanie okazało się jednak całkiem skomplikowane. Chodziło hasło na poziomie BIOSu, którego nie imała się żadna popularna sztuczka typu zworki, baterie i inne triki sprzętowe. Internet jednak podpowiedział, że naciśnięcie kombinacji Ctrl+Tab Ctrl+Enter wywołuje tryb serwisanta, który umożliwia ominięcie hasła. Na ekranie pojawia się jednak pytanie w postaci „Challenge Code”, na który trzeba odpowiedzieć podając „Response Code”. Brzmi jak zadanie dla hakera. Właściciel laptopa na tym etapie zrezygnował, ale Sergiusz dopiero się rozkręcał, więc pozyskał z Allegro trzy takie same zablokowane laptopy oraz współpracę Michała i zabrali się do pracy.

Postanowili zacząć od uzyskania dostępu do kodu BIOSu. Nie mogli go uzyskać z pamięci systemu operacyjnego zablokowanego komputera. Można też było dumpować zawartość kości po wylutowaniu – ale po co, skoro w sieci są aktualizacje BIOSu? Michał pobrał zatem ze strony producenta odpowiednie pliki i poddał analizie. Zidentyfikował plik zawierający kod BIOSu, lecz zawierał on skompresowane dane w nieznanym formacie. Mógł przeanalizować kod programu aktualizującego, lecz ten był stworzony w architekturze 16-bitowej, która jest niezbyt przyjemna do analizowania. Udało mu się jednak znaleźć nowszy aktualizator, 32-bitowy – a z tym mógł już sobie prosto poradzić. Michał napisał krótki program wykorzystujący funkcje odnalezionego aktualizatora i odpakował interesujący ich plik aktualizacji BIOSu.

Gdy Michał męczył się z plikiem aktualizacji, Sergiusz kombinował ze zrzuceniem zawartości kości flash. Historię tego jak płytkę przygotował, wytrawił, układ wylutował, wlutował i podłączył polecamy miłośnikom takich kombinacji. Wyglądało to tak:

Dumpowanie było obarczone z wielu powodów błędami, dlatego zostało przeprowadzone kilkadziesiąt razy i wartości prawidłowe dla każdego bajtu zostały ustalone w drodze wyboru tych, które występowały najczęściej.

Co ciekawe, prace nad odpakowaniem aktualizacji i zrzucaniem zawartości kości zakończyły się tego samego dnia, więc badacze mogli porównać wyniki swoich prac i okazało się, że tylko jeden bajt w dumpowanej pamięci był błędny.

Czas na analizę

Mamy zatem plik o rozmiarze ok. 500 KB, w którym trzeba znaleźć odpowiedni fragment kodu odpowiedzialny za obliczanie prawidłowego kodu odpowiedzi na pytanie systemu. Problemem zajął się Michał. Nie będziemy Was zabierać tu na wycieczkę drogą, którą pokonał Michał, bo to dla nas zbyt skomplikowane (pozdrawiamy czytelników trzeciego tomu podręczników Intela) – chętnych odsyłamy do ok. 14:30 w filmie. Nauczycie się przy okazji, co dzieje się w momencie uruchamiania procesora.

Po wykonaniu wszystkich niezbędnych magicznych zabiegów Michał zlokalizował fragment kodu wyświetlający pytanie o kod odblokowujący BIOS. Okazało się jednak, że wszystkie elementy procesu podawania hasła trafiały do jednej funkcji, która wysyła je na pewne porty i z nich otrzymuje odpowiedzi. Dalsza analiza pokazała, że porty te odpowiadają za komunikację z innym układem scalonym, który prawdopodobnie odpowiada za sprawdzanie poprawności hasła lub odpowiedzi w schemacie challenge-response. Tym innym układem okazał się kontroler klawiatury, pełniący także przy okazji kilka innych funkcji. To zatem tam trzeba było teraz szukać kodu odpowiedzialnego za odblokowanie laptopa.

Drugi układ

Niestety nie udało się znaleźć odpowiednich aktualizacji oprogramowania dla tego modelu. Na szczęście jednak dostępne były aktualizacje dla układu z bardzo podobnego modelu komputera, Toshiba Portégé S100. Okazało się jednak, że kod aktualizacji jest wgrywany bezpośrednio do kontrolera klawiatury, który rozpakowuje go sam, bez jego wcześniejszego rozpakowywania w systemie operacyjnym. Dzięki temu algorytm pakujący/szyfrujący nigdy nie musi opuszczać aktualizowanej kości. testy statystyczne kodu pokazały, że kod jest raczej szyfrowany, niż kompresowany. Zadanie dla Sergiusza.

Sergiusz ponownie musiał przygotować odpowiednią płytkę, wylutować oryginalny układ, wlutować i zrzucić jego zawartość. Dumpowanie okazało się jednak z wielu powodów bardzo utrudnione. Wyjaśnienie jest długie, ale wniosek był jeden – bez znajomości tajnego klucza zrzucenie zawartości kości będzie niemożliwe. Sergiusz zaczął zatem szukać innej drogi.

Po kilku próbach znanych ataków zauważył, że istnieje możliwość odgadnięcia klucza. Otóż jeśli testował wszystkie możliwe kombinacje pierwszego bajtu klucza, to przy jednej z nich układ odpowiadał o 3 mikrosekundy dłużej. To pomogło, w wielu próbach, ustalić zawartość całego klucza, bajt po bajcie. Mając klucz mogli zrzucić kod układu. Znaleźli w nim między innymi kod sprawdzający klucz bajt po bajcie, który po pierwszej niezgodności kończył sprawdzanie, co powodowało różnicę w czasie odpowiedzi wykorzystaną w ataku.

Analiza kodu znowu nie była prosta – ale wyjaśnienie jej zawiłości zostawiamy Michałowi, bo nikt tego nie zrobi lepiej. Gdy Michał dotarł już do kodu odpowiedzialnego za weryfikację poprawności hasła, trochę się przestraszył, ponieważ ponownie znajdowało się ta wywołanie do innego układu. Na szczęście ten układ okazał się tylko EPROMem, który przechowywał skróty MD5 hasła użytkownika. To jednak nie było głównym celem badania – konieczność wylutowania układu z płyty sprawia, ze atak na hasło jest mało praktyczny. Celem było uzyskanie możliwości odblokowania dowolnego laptopa, czyli analiza kodu challenge-response.

Kod okazał się być nietrywialny, ale możliwy do analizy. Było trochę danych losowych, trochę powiązanych ze sprzętem, do tego XOR i dedykowany 64-bitowy szyfr blokowy używający kluczy zapisanych na stałe w oprogramowaniu. Nasi bohaterowie przepisali kod w Pythonie i uzyskali w ten sposób możliwość generowania prawidłowych kodów w schemacie challenge-response, co pokazali na żywo w trakcie prezentacji.

Oklaski były w pełni zasłużone.

Tego nie było jednak Michałowi i Sergiuszowi dosyć – ponieważ po drodze zostawili nierozszyfrowany plik aktualizacji kontrolera klawiatury. Układ używał kryptografii symetrycznej, zatem posiadając jego klucze mogli uzyskać dostęp do kodu. Pobrali zatem aktualizacje oprogramowania dla nowszych modeli laptopów i zorientowali się, że algorytmy i klucze pozostawały bez zmian co najmniej od 14 lat. Po co zmieniać kod, który działa? W ten oto sposób Michał i Sergiusz mogli odblokować dowolny, najnowszy laptop Toshiby oraz stworzyć złośliwe oprogramowanie układu kontrolera klawiatury, na przykład umieszczając tam niezauważalną dla użytkownika tylną furtkę.

Cała operacja zajęła Michałowi i Sergiuszowi trzy lata – choć, jak sami przyznali, większość tego czasu stanowiło oczekiwanie przez Michała aż Sergiusz wylutuje co trzeba. Toshiba obiecała aktualizację oprogramowania usuwającą możliwość przełamania zabezpieczeń BIOSu i atakowania kontrolera klawiatury. Michałowi i Sergiuszowi należą się oklaski i wyrazy uznania – dla takich prezentacji warto chodzić na konferencje. Tu znajdziecie ich slajdy w wersji anglojęzycznej. Prosimy o więcej! A okazja już wkrótce – bo kolejna edycja PWNing już 19-20 listopada 2018.

Oprócz prezentacji Sergiusza i Michała możecie także zobaczyć inne nagrania z zeszłorocznej edycji:



Source link

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *