Intel Management Engine: historia pewnej luki w zabezpieczeniach

Nie każdego jednak przekonują ogólniki. Hipotezy, że narzędzie teoretycznie może i jest niebezpieczne, ale jakoś nie widać żadnych epidemii, więc najwyraźniej nie jest tak źle, słychać w różnych formach dość często. Dlatego rozważania na temat niebezpieczeństw związanych z AMT, pozornie oczywistych, należy poprzeć przykładami konkretnych słabości. Tę rolę najlepiej spełni CVE-2017-5689, znana pod melodyjną nazwą "Silent Bob is Silent". Specyfika podatności doskonale obrazuje problemy z AMT, fatalny stan procedury dostarczania aktualizacji firmware'u oraz niemal ogólnobranżową, dziennikarską impotencję w wyjaśnianiu zagrożeń.

W maju 2017, firma Embedi (pod której internetowym adresem działa dziś malezyjskie kasyno) opublikowała skomplikowany technicznie acz niezbyt przystępny komunikacyjnie dokument PDF o odkrytym zagrożeniu. Dokument objaśniał, że Intel AMT oferuje panel zarządzający wystawiony przez protokół HTTPS (!), słuchający na portach 16992 i 16993. Panel oferował oczywiście uwierzytelnianie, ale przeprowadzał je nieprawidłowo (tryb digest authentication).

Posłanie pustego tokenu rzucało "błędne wyzwanie" metodyce kontroli dostępu, wskutek czego możliwy był dostęp administracyjny bez podawania hasła. Problem zidentyfikowano nie tylko empirycznie, ale także za pomocą analizy kodu asemblera na podstawie obrazu firmware wersji 9.0 Intel ME.

W opowiadaniu "Rozprawa" Stanisława Lema, android na pokładzie statku, planujący uśmiercenie załogi celem rozszerzenia władzy robotów, próbował zmusić kapitana do wydawania błędnych poleceń. Kapitan jednak w decydującym momencie milczał, doprowadzając zbuntowanego androida do terminalnej konfuzji i klęski. Gdy podczas uwierzytelnienia do Intel AMT Web Panelu użytkownik milczy (poda pusty łańcuch jako sekret), ME błędnie ocenia wiarygodność poświadczeń i pozwala na pełny dostęp, ujawniając zakres swoich technicznych możliwości.

Na podstawie takiego komunikatu oraz naszej dotychczasowej wiedzy o niskopoziomowym działaniu Intel ME, można spróbować określić skalę zagrożenia, mechanizm podatności oraz potencjalne mitygacje. Wszystko bowiem wskazywałoby na to, że sterownik wbudowanej karty sieciowej przechwytuje pakiety skierowane na dedykowane porty i jeżeli wykazują one odpowiednią charakterystykę, porywa je bezpośrednio do systemu MINIX w ME, zanim dotrą do systemu operacyjnego (dowolnego) na którym nic nie słucha.

Należałoby zatem wyciąć wszelki ruch docelowy sieci IP w protokole TCP i nagłówkiem inwokacji HTTPS na porty AMT. Każdy mądrzejszy switch to potrafi, oczywiście dedykowane zapory również. Skalę zagrożenia znamy, mechanizm działania również wydaje się być zrozumiały, potencjalne mitygacje także wydają się być w miarę wykonalne. Powinniśmy zatem dysponować pełnią narzędzi potrzebnych do rozwiązania problemu.

Tymczasem na scenę wchodzi Intel, Tenable oraz "publicystyka IT", dzięki którym zrozumienie zagadnienia staje się nieskończenie bardziej utrudnione.

W innym swoim dziele, tym razem w "Cyberiadzie", Lem zaprezentował koncepcję Demona Drugiego Rodzaju: spragnionych wiedzy poszukiwaczy zasypywał informacjami o niepodważalnej prawdziwości, lecz w morderczo nieproporcjonalnych skalach: dane nie tylko były w przeważającej większości trywialne, nieistotne lub powtórzone, lecz także były dostarczane w ilości całkowicie przytłaczającej, pozbawiając kompletnie możliwości skutecznego przeszukiwania.

Tak właśnie zaczęły wyglądać wyniki Google kilka dni po ogłoszeniu podatności. Najpierw do akcji wkroczyła renomowana firma Tenable, wydawca nieocenionego skanera bezpieczeństwa Nessus. Ustosunkowali się oni do ogłoszenia wydanego przez Intela, w którym (kuriozalnie) opisano mitygację polegającą na od-zaopatrzeniu (unprovision) AMT oraz... wyłączeniu jednej z usług w Windows. Skąd tu nagle ta usługa? Przecież to działa niezależnie od systemu!

Rzetelny opis wtyczki 97999 oraz towarzyszący jej wpis blogowy opisywał przygotowanie przez Tenable środowiska testowego i pada w nim stwierdzenie dotyczące konieczności posiadania usługi LMS. Komputery bez zainstalowanego LMS nie wykazywały podatności na lukę. Czyżby więc do wykorzystania luki nie był potrzebny (hipotetyczny) super-filtr na karcie sieciowej, kradnący pakiety za naszymi plecami, a jedynie zwykła, dziurawa usługa dla Windowsa? To o co ten krzyk? Wyłączyć i gotowe!

Zaczynały się piętrzyć pytania. Skoro chodzi tylko o jakąś usługę LMS, którą trzeba (nierzadko ręcznie) doinstalować do systemu z pękiem sterowników, to do czego służy narzędzie mitygujące dla Linuksa? Gdzie tak naprawdę jest luka, co ma do tego Windows, co robi usługa LMS i jak tak naprawdę wyłączyć ten web-panel do zarządzania zdalnego? Czy ktoś może odpowiedzieć na te pytania? Może Intel? Cóż, Intel na pewno myślał, że odpowiedział na wszystkie pytania, ponieważ wydał Przewodnik po implementowaniu mitygacji zagrożenia.

Przewodnik prawidłowo adresuje zagrożenie, acz w kwestii swojej treści wykazuje silną inspirację makulaturą. Proces usuwania zagrożenia składa się z trzech części:

Usunięcie konfiguracji ACM w układzie ME Zatrzymanie systemowej usługi LMS Nałożenie restrykcji dostępu do AMT

Opisuje też metodę sprawdzenia, czy usługa LMS dalej słucha, posługując się najbardziej podniosłymi z dostępnych słów:

Po czym pada polecenie netstat wypisujące porty w stanie LISTEN. Właśnie to polecenie było przytaczane w dziesiątkach innych stron jako metoda sprawdzenia, czy jest się zagrożonym. W połączeniu z niewyjaśnieniem, czym tak naprawdę jest usła LMS i jaka jest zależność między nią a ME, wiele osób wprowadzono w błąd. Zwłaszcza, że sam Tenable pisze coś, co można zrozumieć jako winę usługi Windows. Co powtórzyło bez zrozumienia bardzo wiele osób.

Tymczasem problem jest wieloczęściowy i tak naprawdę każdy z uczestników debaty miał na swój sposób rację. Słusznie twierdzili ludzie z Embedi, mówiąc że problem leży w firmware Intel ME. Nie kłamał również Intel, mówiący o tym, że należy wyłączyć zarówno panel, jak i usługę LMS. Wreszcie, rację miał Tenable, pokazujący jak LMS jest konieczny do wytworzenia podatności. No to o co tu w końcu chodzi?

Ta nieszczęsna usługa LMS to mechanizm komunikacji między przestrzenią użytkownika i systemem operacyjnym a układem Intel ME. Za pomocą warstwy translacji, usługa tłumaczy wywołania API na żądania dla sterownika Intel ME, pozwalając systemowi rozmawiać z usługami Intel AMT. Gdy uruchomiona, słucha na portach 16992-16995 i przekierowuje cały ruch bezpośrednio do stosu sieciowego systemu MINIX działającego w układzie Intel ME.

Gdy tej usługi nie ma, a płyta główna "wie", że pracuje na niej "głupi" system operacyjny, nierozumiejący istnienia ME, sama karta sieciowa będzie kradła pakiety i słała je do układu (zakładam, że nie zawsze i pod jakimiś magicznymi warunkami – pozdrawiam adeptów sztuki docierania do tej wiedzy!)

Gdy jednak system jest "mądry", jest on uświadamiany, że istnieje część ruchu docierająca do komputera o jego IP, który ma być przeznaczony do AMT. To sterownik ME decyduje, czy system jest "mądry". Ale to usługa LMS odpowiada na przekazywanie ruchu. A więc technicznie, to LMS "słucha", ale tak naprawdę jest lejkiem przekierowującym ruch do MINIX-a. I to w nim był błąd. Dlatego mitygacja Intela mówiła, żeby "odprovisionować" układ.

Czyli albo usunąć z niego opcję zdalnego zarządzania albo przestawić ją na martwą, jeżeli producent włączył ją domyślnie (to wykonalne). I żeby wyłączyć LMS, co nie "ogłupi" systemu, ale przestanie lać pakiety bezpośrednio do ME. Na wypadek, gdyby sieciowy SCS np. włączył AMT z powrotem. Wreszcie, mimo tych wyłączników, wciąż potrzebna była aktualizaca w postaci nowego firmware AMT.

To wszystko trudno jest wyjaśnić. Nawet bardzo dobre opracowania, jak artykuł F5. Nie wykładają jasno granic kompetencji, czyli tego gdzie jest serwer, co słucha i gdzie jest dziura. Liczba niuansów jest olbrzymia, zwłaszcza w przypadku LMS.

Podatność Silent Bob (CVE-2017-5689) jest genialnym studium tego, czym grożą dziury w Intel ME i dlaczego tak ważne jest to, żeby dało się ją wyłączyć. Możliwość ta jest jedną z nowości wersji... dwunastej.

W kolejnej części zajmiemy się aktualizowaniem wbudowanych kontrolerów i weryfikowaniem ich działania. Zalicza się do tego sprawdzenie, czy działa Intel AMT 🙂