Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa alarmują o dużej skali ekspozycji interfejsów Baseboard Management Controller (BMC) dostępnych bezpośrednio z internetu. Problem dotyczy wdrożeń IPMI 2.0, w których jeszcze przed skutecznym uwierzytelnieniem można uzyskać materiał kryptograficzny powiązany z hasłem administratora.
W praktyce oznacza to, że napastnik nie musi prowadzić klasycznego brute force przeciwko urządzeniu. Wystarczy dostęp do usługi IPMI, aby pobrać odpowiedź użyteczną w ataku offline i następnie lokalnie odtwarzać hasło bez dalszej interakcji z celem.
W skrócie
- Badanie wykazało 36 872 hosty z publicznie dostępnym IPMI.
- 24 650 z nich ujawniało dane pochodne od hasła jeszcze przed logowaniem.
- Źródłem problemu jest znana od lat słabość CVE-2013-4786 związana z mechanizmem RAKP w IPMI 2.0.
- Atakujący z dostępem do UDP/623 może pozyskać odpowiedź HMAC i prowadzić zgadywanie haseł offline.
- Największe ryzyko dotyczy środowisk z hasłami fabrycznymi, słabymi lub przewidywalnymi.
Kontekst / historia
BMC to dedykowany kontroler zarządzania osadzony na płycie głównej serwera. Odpowiada za zadania out-of-band, takie jak zdalne uruchamianie i wyłączanie systemu, dostęp do konsoli, instalację systemu operacyjnego, aktualizacje firmware czy odzyskiwanie po awarii.
Z perspektywy bezpieczeństwa jest to jeden z najbardziej wrażliwych komponentów infrastruktury. BMC działa poza systemem operacyjnym hosta i posiada uprzywilejowaną pozycję wobec całej platformy serwerowej, dlatego jego przejęcie może mieć znacznie poważniejsze skutki niż kompromitacja zwykłego panelu administracyjnego.
Słabość oznaczona jako CVE-2013-4786 została opisana już w 2013 roku i dotyczy samego sposobu działania uwierzytelniania RMCP+ w IPMI 2.0. Mimo upływu lat problem pozostaje aktualny, ponieważ wiele organizacji nadal wystawia interfejsy zarządzania do internetu, a współczesne akceleratory GPU znacząco przyspieszają łamanie słabych haseł.
Analiza techniczna
Rdzeniem problemu jest mechanizm RAKP używany podczas negocjacji sesji IPMI 2.0. W określonych warunkach BMC odsyła odpowiedź zawierającą HMAC-SHA1 wyliczony z użyciem hasła konta oraz parametrów sesji znanych stronie inicjującej połączenie.
Jeżeli usługa IPMI jest osiągalna przez UDP/623, napastnik może pobrać taki materiał bez wcześniejszego zalogowania. To zasadniczo zmienia charakter zagrożenia: zamiast ataku online ograniczanego przez blokady, opóźnienia czy monitoring, pojawia się możliwość nieograniczonego testowania kandydatów na hasło lokalnie, we własnym środowisku.
W praktyce szczególnie narażone są instalacje korzystające z haseł fabrycznych, słownikowych, powtarzalnych lub tworzonych według przewidywalnych schematów. Dodatkowym problemem jest obecność standardowych nazw kont administracyjnych, takich jak ADMIN czy root, a w części przypadków także reakcja urządzeń na pustą nazwę użytkownika.
Kompromitacja BMC może dać napastnikowi dostęp poniżej warstwy systemu operacyjnego. Otwiera to drogę do zdalnego zarządzania serwerem, modyfikacji ustawień startowych, zmian firmware, utrzymywania persystencji po reinstalacji systemu oraz prowadzenia dalszego ruchu bocznego w infrastrukturze.
Konsekwencje / ryzyko
Ekspozycja BMC do internetu niesie ryzyko nieproporcjonalnie większe niż w przypadku typowych interfejsów administracyjnych. Uzyskanie dostępu do kontrolera zarządzania może umożliwić pełne przejęcie serwera, zdalne restartowanie, dostęp do konsoli, podmianę obrazów rozruchowych oraz osadzenie złośliwego kodu na poziomie firmware.
W środowiskach centrów danych, usług bare-metal i platform obsługujących obciążenia AI skutki mogą wykraczać poza pojedynczy host. Jeden podatny interfejs zarządzania może stać się punktem wejścia do segmentów infrastruktury o wysokim poziomie zaufania, zwiększając ryzyko ransomware, sabotażu operacyjnego oraz trudnych do wykrycia działań posteksploatacyjnych.
Szczególnie niepokojące jest to, że mowa o problemie znanym od wielu lat. Jego praktyczna wykorzystywalność wynika nie tyle z nowości technicznej, ile z utrzymujących się błędów konfiguracyjnych, braku segmentacji sieci zarządzającej i pozostawiania słabych poświadczeń na krytycznych urządzeniach.
Rekomendacje
Najważniejszym działaniem obronnym powinno być całkowite usunięcie interfejsów BMC z publicznego internetu. Dostęp do IPMI należy ograniczyć do wydzielonej sieci zarządzającej, a port UDP 623 blokować na granicy sieci organizacji.
- Przeprowadzić pełną inwentaryzację interfejsów out-of-band i sprawdzić, czy nie są osiągalne publicznie.
- Natychmiast zmienić hasła fabryczne i wymusić silne, unikalne poświadczenia dla każdego BMC.
- Wyłączyć zbędne funkcje i starsze tryby IPMI, jeśli nie są wymagane operacyjnie.
- Stosować dostęp przez VPN, bastion hosty oraz listy ACL zamiast bezpośredniej ekspozycji do internetu.
- Monitorować ruch administracyjny i objąć BMC regularnym audytem konfiguracji oraz hardeningiem.
- Traktować warstwę zarządzania sprzętem jako zasób krytyczny i ograniczyć liczbę uprzywilejowanych administratorów.
W organizacjach o podwyższonym profilu ryzyka BMC powinny być objęte takimi samymi rygorami bezpieczeństwa jak inne systemy klasy Tier 0. Obejmuje to ścisłe logowanie dostępu, kontrolę zmian, testy bezpieczeństwa firmware i bieżące wykrywanie prób nieautoryzowanej aktywności.
Podsumowanie
Przypadek 24 650 publicznie dostępnych interfejsów BMC ujawniających hashe IPMI przed logowaniem pokazuje, że wieloletnie słabości protokołów zarządzania nadal mogą stanowić realne zagrożenie. Problem wynika zarówno z ograniczeń samej specyfikacji IPMI 2.0, jak i z błędnej ekspozycji usług administracyjnych oraz utrzymywania słabych poświadczeń.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona serwerów nie kończy się na systemie operacyjnym i narzędziach EDR. Warstwa out-of-band, firmware oraz kontrolery BMC muszą być chronione z taką samą dyscypliną jak pozostałe elementy infrastruktury krytycznej.