Badacze bezpieczeństwa ostrzegają, że tysiące wystawionych do internetu kontrolerów zarządzania serwerami nadal jest podatnych na lukę sprzed dziesięcioleci, która może pozwolić atakującym odzyskać poświadczenia i uzyskać uprzywilejowany dostęp do sprzętu w centrach danych.
Badacze z firmy Lava znaleźli 36 872 usługi IPMI wystawione do internetu, z których 24 650 zwracało materiał uwierzytelniający wyprowadzony z hasła jeszcze przed logowaniem z powodu CVE-2013-4786, od dawna znanej słabości protokołu uwierzytelniania IPMI 2.0. Ponad 30% zwróconych haszy było powiązanych z hasłami, które dało się odzyskać za pomocą popularnych słowników lub przewidywalnych formatów haseł fabrycznych.
Problem dotyczy Baseboard Management Controllers, czyli BMC — małych procesorów zarządzających wbudowanych w serwery, które pozwalają administratorom zdalnie sterować sprzętem, nawet gdy system operacyjny jest wyłączony lub nie odpowiada.
Dlaczego BMC mają tak duże uprawnienia
BMC to nie jest kolejny interfejs zarządzania.
Działa poniżej systemu operacyjnego i może kontrolować podstawowe funkcje serwera, takie jak cykliczne wyłączanie i włączanie zasilania, zdalny dostęp do konsoli, montowanie nośników wirtualnych, aktualizacje oprogramowania układowego, telemetria sprzętowa i niskopoziomowa konfiguracja platformy. Lava opisuje BMC jako jeden z najbardziej uprzywilejowanych punktów kontroli w centrum danych.
Dlatego przejęcie BMC jest szczególnie niebezpieczne.
Jeśli atakujący uzyskają dostęp do BMC, mogą być w stanie kontrolować serwer spod warstwy systemu operacyjnego. Tradycyjne narzędzia bezpieczeństwa punktów końcowych mogą nie widzieć takiej aktywności, ponieważ monitorują głównie system operacyjny, jądro, kontenery i obciążenia — a nie procesor zarządzający poza pasmem, który działa obok nich.
20-letnia słabość
Sednem problemu jest CVE-2013-4786, podatność w przebiegu uwierzytelniania IPMI 2.0.
Nieuwierzytelniony atakujący, który ma dostęp do portu UDP 623, może zażądać od BMC odpowiedzi uwierzytelniającej. Taka odpowiedź może zawierać materiał wyprowadzony z hasła, co pozwala atakującemu wynieść hasz i próbować zgadywać hasła offline, bez wielokrotnej interakcji z atakowanym systemem.
Jest to istotne, ponieważ łamanie haseł offline jest znacznie trudniejsze do wykrycia niż zwykłe zgadywanie haseł przy logowaniu.
Zamiast generować tysiące nieudanych prób logowania do BMC, atakujący może jednorazowo przechwycić materiał uwierzytelniający i sprawdzać kandydatów na hasło gdzie indziej.
Prawdziwym problemem stają się słabe, ponownie używane, fabryczne lub przewidywalne hasła.
Co ustalili badacze
Skan Lava wykrył dużą liczbę wystawionych i słabo skonfigurowanych systemów.
Wśród przetestowanych punktów końcowych BMC dostępnych z internetu:
- zidentyfikowano 36 872 wystawionych hostów IPMI
- 24 650 zwróciło co najmniej jedną odpowiedź RAKP przed uwierzytelnieniem klienta
- 6 240 akceptowało puste nazwy użytkowników ze słabymi kandydatami na hasło
- 2 340 miało nazwane konta, takie jak
ADMINlubroot, pasujące do popularnych słowników haseł
W wielu przypadkach pasujące hasła zostały szybko znalezione podczas analizy offline. Lava twierdzi, że nie użyła odzyskanych haseł do uwierzytelniania w podatnych BMC.
Unikalne hasła fabryczne nie zawsze wystarczą
Ważną lekcją z tego badania jest to, że „unikalne hasło fabryczne” nie oznacza automatycznie „bezpieczne”.
Niektóre systemy Supermicro używają fabrycznego hasła w formacie dziesięciu wielkich liter. Brzmi to mocniej niż współdzielone domyślne poświadczenia, ale Lava ustaliła, że tak ograniczony format nadal może być praktycznie łamalny w ukierunkowanych scenariuszach przy użyciu nowoczesnego sprzętu GPU.
Badacze przetestowali też w laboratorium format hasła fabrycznego HPE iLO i stwierdzili, że przy użyciu sprzętu GPU przestrzeń kandydatów można przeszukać bardzo szybko dla każdej przechwyconej odpowiedzi.
Problemem nie są wyłącznie słabe hasła.
To połączenie przewidywalnych formatów haseł, wystawionego IPMI i wady protokołu, która umożliwia łamanie haseł offline.
Dlaczego to ważne dla infrastruktury AI i GPU
Ryzyko jest szczególnie poważne dla nowoczesnej infrastruktury AI i GPU.
Centra danych AI często zawierają dużą liczbę cennych serwerów GPU połączonych przez współdzielone sieci zarządzania, systemy provisioningu, magazyny danych i narzędzia orkiestracji. Lava ostrzega, że pojedynczy przejęty BMC w takich środowiskach może stać się drogą do kolejnych hostów, współdzielonej infrastruktury i potencjalnie szerszego przejęcia płaszczyzny zarządzania.
Jest to szczególnie ważne dla dostawców GPU typu bare metal i środowisk „neocloud”, w których obciążenia klientów mogą działać na dedykowanych serwerach, ale płaszczyzna zarządzania dostawcy nadal obejmuje wiele systemów.
Jeśli sieci BMC są słabo segmentowane lub w niewielkim stopniu monitorowane, jeden wystawiony kontroler może stać się uprzywilejowanym przyczółkiem.
Dowody rzeczywistych ataków
To nie jest wyłącznie teoretyczna ekspozycja.
Lava poinformowała o znalezieniu dowodów, że wystawione interfejsy BMC były już celem ataków. W jednym przypadku badacze znaleźli wystawioną do internetu stronę logowania HPE iLO, która wyświetlała żądanie okupu w panelu Security Notice, co sugeruje nieautoryzowany dostęp do interfejsu zarządzania.
Dark Reading podał również, że Lava znalazła przejęte systemy powiązane z dużym producentem komponentów motoryzacyjnych, z wystawionymi serwerami wyświetlającymi komunikaty ransomware i żądania zapłaty.
Oznacza to, że obrońcy powinni traktować wystawione BMC jako pilny problem, a nie zapomniany pozostały element administracyjny.
Co mogliby zrobić atakujący
Przejęty BMC może dać atakującym niebezpiecznie wysoki poziom kontroli.
Możliwe skutki obejmują:
- zdalny dostęp do konsoli
- kontrolę zasilania serwera
- nadużycie nośników wirtualnych
- manipulację oprogramowaniem układowym
- niskopoziomowe zmiany konfiguracji
- utrzymanie dostępu poniżej systemu operacyjnego
- ruch boczny przez sieci zarządzania
- dostęp do systemów provisioningu i wewnętrznych systemów zarządzania
- przygotowanie ransomware lub zakłócenie odtwarzania
W najgorszych scenariuszach odzyskanie sprawności może wymagać ponownego wgrania oprogramowania układowego, weryfikacji na poziomie platformy, naprawy z pomocą dostawcy, a nawet wymiany sprzętu, jeśli nie da się przywrócić zaufania do warstwy zarządzania.
Dlaczego tradycyjny monitoring może to przeoczyć
Większość monitoringu bezpieczeństwa koncentruje się na systemie operacyjnym i warstwie aplikacji.
BMC znajdują się poza tą granicą.
Mogą mieć własne interfejsy sieciowe, poświadczenia, oprogramowanie układowe, logi i protokoły zarządzania. Jeśli te systemy nie są monitorowane osobno, atakujący mogą działać w martwym punkcie.
Dlatego BMC należy traktować jako część krytycznego obwodu bezpieczeństwa, a nie jako proste narzędzia sprzętowe.
Centrum danych jest tak bezpieczne, jak jego płaszczyzna zarządzania.
Co powinny zrobić organizacje
Pierwszy i najważniejszy krok jest prosty: IPMI nie powinno być osiągalne z publicznego internetu.
Lava zaleca blokowanie portu UDP 623 na brzegu sieci, zastępowanie haseł fabrycznych podczas provisioningu, wyłączanie przestarzałych lub słabych opcji, takich jak IPMI 1.5, zestaw szyfrów 0, konta anonimowe i uwierzytelnianie NONE, oraz ograniczanie dostępu do BMC do prywatnych sieci zarządzania, VPN, hostów bastionowych lub innych kontrolowanych ścieżek administracyjnych.
Organizacje powinny również:
- izolować BMC w dedykowanych sieciach zarządzania
- stosować ścisłe listy ACL do interfejsów zarządzania
- rotować domyślne i ponownie używane poświadczenia BMC
- monitorować logi BMC i aktywność w sieci zarządzania
- zinwentaryzować wszystkie wystawione interfejsy IPMI, Redfish, iLO, iDRAC, XClarity i BMC Supermicro
- sprawdzić wersje oprogramowania układowego i wytyczne dostawców
- wyłączyć nieużywane funkcje zdalnej konsoli i nośników wirtualnych
- traktować przejęcie BMC jako incydent na poziomie platformy
Tam, gdzie jest to obsługiwane, Redfish przez TLS powinien być używany wyłącznie wewnątrz izolowanych sieci zarządzania — nie wystawiany bezpośrednio do publicznego internetu.
Podsumowanie
Ekspozycja tysięcy BMC pokazuje, że stare słabości infrastruktury mogą pozostawać niebezpieczne przez dziesięciolecia.
CVE-2013-4786 nie jest nowa, ale nowoczesne łamanie haseł na GPU, przewidywalne formaty haseł fabrycznych i publicznie wystawione interfejsy zarządzania sprawiają, że na nowo nabiera znaczenia w skali centrów danych.
Kontrolery zarządzania serwerami nie są systemami drugorzędnymi. To uprzywilejowane płaszczyzny kontroli.
Jeśli atakujący je przejmą, mogą działać poniżej systemu operacyjnego, omijać wiele tradycyjnych mechanizmów kontroli i potencjalnie przemieszczać się po sieci zarządzania centrum danych.
Organizacje powinny usunąć BMC z publicznego internetu, rotować poświadczenia fabryczne, izolować sieci zarządzania i stale monitorować tę warstwę jak infrastrukturę krytyczną.
