Jak wykryć i zmniejszyć lukę w zabezpieczeniach związaną z eskalacją uprawnień Intel w systemie Linux (CVE-2017-5689)?


26

Według centrum bezpieczeństwa firmy Intel z 1 maja 2017 r. Istnieje krytyczna luka w procesorach Intela, która może pozwolić osobie atakującej na uzyskanie uprawnień (eskalacja uprawnień) przy użyciu AMT, ISM i SBT.

Ponieważ AMT ma bezpośredni dostęp do sprzętu sieciowego komputera, ta luka sprzętowa umożliwi osobie atakującej dostęp do dowolnego systemu.

W technologii Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM) i Intel® Small Business Technology w wersjach oprogramowania 6.x, 7.x, 8.x 9.x, 10 występuje luka w zabezpieczeniach .x, 11.0, 11.5 i 11.6, które mogą pozwolić nieuprzywilejowanemu atakującemu przejąć kontrolę nad funkcjami zarządzania zapewnianymi przez te produkty. Ta luka nie występuje na komputerach osobistych z procesorami Intel.

Firma Intel wydała narzędzie do wykrywania dostępne dla systemów Windows 7 i 10. Korzystam z informacji z dmidecode -t 4witryny firmy Intel i przeszukując witrynę firmy Intel, z której korzystam, korzysta z mojego procesora Intel® Active Management Technology (Intel® AMT) 8.0.

Dotyczy produktów:

Problem zaobserwowano w oprogramowaniu Intel do zarządzania w wersji 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5 i 11.6 dla technologii Intel® Active Management, Intel® Small Business Technology i Intel ® Standardowe zarządzanie. Nie ma to wpływu na wersje wcześniejsze niż 6 lub 11.6.

Opis:

Nieuprzywilejowany lokalny atakujący może zapewnić funkcje zarządzania, uzyskując nieuprzywilejowane uprawnienia sieciowe lub lokalne systemu na jednostkach SKU do zarządzania Intel: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM) i Intel® Small Business Technology (SBT)

Jak mogę łatwo wykryć i zmniejszyć lukę w zabezpieczeniach związaną z eskalacją uprawnień Intel w systemie Linux?


1
Sprawa jest jeszcze bardziej skomplikowana, gdy wielu z nas korzysta z maszyn wirtualnych; czy dla prawdziwych maszyn wystarczy skanować w poszukiwaniu obecności usługi na UDP 16992? +1
Rui F Ribeiro

2
Kroki zapobiegawcze: użyj SPARC (wiem, wiem, nie jest to możliwe rozwiązanie). Zdobądź +1
Lis

3
@ Fox dość zabawnie, że procesor ME w procesorach Intela jest obecnie SPARC ;-).
Stephen Kitt

2
@StephenKitt Naprawdę? Być może będę musiał przemyśleć swoje stanowisko w sprawie układów Intela! Prawie wszystkie moje maszyny to PPC lub SPARC, więc muszę przyznać, że moje nastawienie jest prawdziwe
Fox

Odpowiedzi:


18

Najczystszym postem, jaki widziałem na ten temat, jest Matthew Garrett (łącznie z komentarzami).

Matthew wydał teraz narzędzie do lokalnego sprawdzania systemu: zbuduj go, uruchom

sudo ./mei-amt-check

i poinformuje, czy AMT jest włączony i udostępniony, a jeśli tak, to wersje oprogramowania układowego (patrz poniżej). Plik README zawiera więcej szczegółów.

Aby przeskanować sieć w poszukiwaniu potencjalnie wrażliwych systemów, przeskanuj porty 623, 624 oraz 16992 do 16993 (zgodnie z opisem we własnym dokumencie firmy Intel dotyczącym łagodzenia skutków ); na przykład

nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24

przeskanuje sieć 192.168.1 / 24 i zgłosi stan wszystkich hostów, które odpowiedzą. Możliwość połączenia z portem 623 może być fałszywie dodatnia (inne systemy IPMI używają tego portu), ale każdy otwarty port od 16992 do 16995 jest bardzo dobrym wskaźnikiem włączonego AMT (przynajmniej jeśli odpowiednio zareagują: z AMT, to znaczy odpowiedź HTTP na 16992 i 16993, ta ostatnia z TLS).

Jeśli zobaczysz odpowiedzi na portach 16992 lub 16993, połączenie z nimi i żądanie /HTTP spowoduje zwrócenie odpowiedzi z Serverwierszem zawierającym „Intel (R) Active Management Technology” w systemach z włączoną obsługą AMT; ta sama linia będzie również zawierać używaną wersję oprogramowania układowego AMT, którą można następnie porównać z listą podaną w poradniku Intela, aby ustalić, czy jest podatna na ataki.

Zobacz odpowiedź CerberusSec na link do skryptu automatyzującego powyższe.

Istnieją dwa sposoby „poprawnego” rozwiązania problemu:

  • zaktualizuj oprogramowanie wewnętrzne, gdy producent Twojego systemu dostarczy aktualizację (jeśli w ogóle);
  • unikaj używania portu sieciowego zapewniającego AMT, albo używając interfejsu sieciowego nieobsługującego AMT w twoim systemie, albo używając adaptera USB (wiele stacji roboczych AMT, takich jak systemy C226 Xeon E3 z portami sieciowymi i210, ma tylko jeden AMT- zdolny interfejs sieciowy - reszta jest bezpieczna; pamiętaj, że AMT może działać przez Wi-Fi, przynajmniej w systemie Windows, więc korzystanie z wbudowanego Wi-Fi może również prowadzić do kompromisu).

Jeśli żadna z tych opcji nie jest dostępna, jesteś na terytorium ograniczającym ryzyko. Jeśli Twój system obsługujący technologię AMT nigdy nie został przygotowany na AMT, jesteś w miarę bezpieczny; włączenie AMT w tym przypadku najwyraźniej może być wykonane tylko lokalnie i, o ile wiem, wymaga użycia oprogramowania układowego lub oprogramowania systemu Windows. Jeśli funkcja AMT jest włączona, możesz ją ponownie uruchomić i użyć oprogramowania układowego, aby ją wyłączyć (naciśnij, CtrlPgdy podczas uruchamiania wyświetlany jest komunikat AMT).

Zasadniczo, chociaż luka w zabezpieczeniach jest dość paskudna, wydaje się, że nie dotyczy to większości systemów Intel. W przypadku własnych systemów z systemem Linux lub innym systemem operacyjnym podobnym do Uniksa eskalacja prawdopodobnie wymaga fizycznego dostępu do systemu, aby umożliwić AMT w pierwszej kolejności. (Windows to inna historia.) W systemach z wieloma interfejsami sieciowymi, jak zauważył Rui F Ribeiro , powinieneś traktować interfejsy obsługujące AMT w taki sam sposób, jak traktujesz dowolny interfejs administracyjny (obsługujący IPMI lub interfejs hosta) hiperwizora maszyny wirtualnej) i odizoluj go w sieci administracyjnej (fizycznej lub VLAN). Nie można polegać na hoście, aby się chronić: iptablesitp. Są tutaj nieskuteczne, ponieważ AMT widzi pakiety przed systemem operacyjnym (i zatrzymuje pakiety AMT dla siebie).

Maszyny wirtualne mogą komplikować sprawy, ale tylko w tym sensie, że mogą mylić AMT, a tym samym generować mylące wyniki skanowania, jeśli AMT jest włączony. amt-howto(7)podaje przykład systemów Xen, w których AMT używa adresu podanego DomU przez DHCP, jeśli taki istnieje, co oznacza, że ​​skanowanie pokazałoby AMT aktywne w DomU, a nie Dom0 ...


Czy nie ma lokalnego sposobu na wykrycie AMT z Linuksa na komputerze? Używasz /proc/cpuinfolub dmidecode?
dolmen

Czy to oznacza, że ​​jeśli system nie zareaguje na żaden z tych portów, jest bezpieczny przed tą luką lub może nadal być wykorzystywany lokalnie?
comfreak

Ograniczanie ryzyka w laptopach może przybierać formę korzystania z kart sieciowych USB zamiast wbudowanych.
Michael Mol

1
Piszesz „uwaga, że ​​AMT może działać przez Wi-Fi, przynajmniej w systemie Windows”. Myślałem, że ta luka działa niezależnie od systemu operacyjnego?
wurtel

1
@wurtel ta luka jest niezależna od systemu operacyjnego w przypadku interfejsów przewodowych, ale w Wi-Fi wydaje się, że AMT potrzebuje współpracy ze sterownikiem działającego systemu operacyjnego: nie przechwytuje pakietów, polega na przekazywaniu odpowiednich pakietów przez system operacyjny (jak rozumiem - zauważ, że nie testowałem tej strony).
Stephen Kitt

8

Samo wykrycie otwartych portów dla tej usługi jest niewystarczające, nie oznacza to, czy dotyczy to wersji, czy nie. Nasz zespół stworzył skrypt python dostępny na naszym githubie: CerberusSecurity / CVE-2017-5689, który wykrywa, czy system docelowy jest podatny na atak zdalny.

Przykładowe użycie:

python CVE_2017_5689_detector.py 10.100.33.252-255

Powinno to umożliwić sprawdzenie, czy można zdalnie wykorzystać. Jeśli jesteś zainteresowany, napisaliśmy również krótki post na blogu pod adresem http://cerberussec.org/ z naszym omówieniem tej luki.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.