BMC i CVE-2013-4786: 24 tys. interfejsów ujawnia hashe przed logowaniem
22-letni problem IPMI 2.0 nadal wystawia płaszczyznę zarządzania serwerami. Wyjaśniamy RAKP, łamanie offline i bezpieczną izolację BMC.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 4 sierpnia 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Chmura, infrastruktura i DevSecOps
Baseboard Management Controller (BMC) działa nawet wtedy, gdy system operacyjny serwera jest wyłączony. Pozwala zmieniać firmware, montować wirtualne nośniki, otwierać konsolę i restartować host. Właśnie dlatego nowy pomiar firmy Lava jest niepokojący: spośród niemal 37 tys. internetowych interfejsów zarządzania używających IPMI ponad 24 tys. miało ujawniać materiał umożliwiający łamanie hasła offline przed zalogowaniem.
Rdzeniem problemu jest CVE-2013-4786, konsekwencja projektu uwierzytelniania IPMI 2.0 wprowadzonego w 2004 r. To nie nowy zero-day i zwykle nie istnieje jedna poprawka, która zachowa pełną zgodność protokołu. Problemem operacyjnym jest to, że uprzywilejowana płaszczyzna out-of-band nadal jest wystawiona do internetu i chroniona przewidywalnymi lub powtarzanymi hasłami.
Dlaczego RAKP ujawnia materiał do zgadywania
W procesie Remote Authenticated Key-Exchange Protocol (RAKP) BMC zwraca HMAC-SHA1 obliczony z użyciem hasła konta oraz parametrów sesji znanych klientowi. Opis CVE w NVD wskazuje, że zdalny, nieuwierzytelniony użytkownik może pozyskać ten HMAC z odpowiedzi RAKP message 2.
Napastnik nie otrzymuje hasła wprost. Dostaje jednak wartość, wobec której może testować kandydatów lokalnie, bez kolejnego kontaktu z serwerem. Mechanizmy blokady konta, rate limiting i logi kolejnych nieudanych logowań nie widzą milionów prób wykonywanych na sprzęcie atakującego. Nowoczesne GPU skracają czas sprawdzenia słabych haseł.
W wielu implementacjach IPMI, Redfish i panel WWW korzystają z tej samej bazy użytkowników. Hasło odzyskane z RAKP może więc otworzyć wygodniejszy interfejs HTTPS lub API, nie tylko UDP 623.
Co pokazał internetowy pomiar
Lava informuje o niemal 37 tys. widocznych z internetu interfejsów z IPMI i ponad 24 tys. odpowiedzi ujawniających hashe pochodne od hasła. Badacze znaleźli 6 240 hostów akceptujących pustą nazwę użytkownika ze słabym hasłem oraz 2 340 z nazwanymi kontami, takimi jak Admin lub root, których hasła występowały w publicznych słownikach.
Firma zwraca również uwagę na fabryczne formaty haseł o ograniczonej, przewidywalnej strukturze. Nie oznacza to, że każdy z 24 tys. hostów został przejęty ani że każde hasło da się odzyskać. Liczba opisuje powierzchnię podatną na test offline, a skuteczność zależy od siły konkretnego sekretu.
Dlaczego BMC jest tak cennym celem
Kompromitacja BMC znajduje się poniżej zwykłej kontroli endpointu. Napastnik może obserwować rozruch, zmienić ustawienia, dostarczyć obraz systemu lub zachować dostęp po reinstalacji OS. Ruch zarządzania bywa słabiej monitorowany niż sieć produkcyjna, a konto fabryczne może przetrwać wiele cykli życia serwera.
Dla centrów danych i klastrów GPU ryzyko rośnie przez powtarzalność konfiguracji. Jedna reguła firewalla, wspólny wzorzec hasła lub sklonowany obraz zarządzania może wystawić całą partię urządzeń.
Plan zabezpieczenia płaszczyzny out-of-band
- Zeskanuj własne zakresy zewnętrzne pod kątem UDP 623, Redfish i paneli BMC. Nie zakładaj, że „nikt nie zna adresu”.
- Usuń BMC z internetu. Umieść je w osobnym segmencie zarządzania dostępnym przez bastion lub VPN z MFA.
- Wyłącz IPMI over LAN, jeśli nie jest wymagane. Preferuj nowsze, poprawnie skonfigurowane mechanizmy Redfish przez TLS, ale nie współdziel słabego konta z IPMI.
- Usuń konta domyślne, ustaw losowe i unikalne hasła dla każdego urządzenia oraz przechowuj je w managerze sekretów.
- Zaktualizuj firmware BMC i przejrzyj konfigurację szyfrów, certyfikatów i integracji katalogowej.
- Ogranicz kierunki komunikacji, loguj użycie konsoli, zmiany firmware’u i tworzenie kont; eksportuj logi poza BMC.
- Po podejrzeniu przejęcia nie ufaj wyłącznie reinstalacji hosta. Zweryfikuj firmware i łańcuch rozruchu zgodnie z procedurą producenta.
Zasady segmentacji opisujemy w materiale zero trust i bezpieczeństwo sieci, a rotację w zarządzaniu sekretami Vault/KMS.
Fakty źródłowe a wnioski Breachroad
NVD dokumentuje mechanizm CVE-2013-4786. Lava podaje wyniki własnego pomiaru i testów haseł; SecurityWeek niezależnie omówił badanie. Publiczne dane nie potwierdzają kompromitacji wszystkich wykrytych systemów.
Wnioskiem Breachroad jest traktowanie BMC jako osobnej, krytycznej domeny tożsamości i monitoringu. Szkolenia cyberbezpieczeństwa dla administratorów pomagają budować bezpieczne procedury out-of-band, a audyt bezpieczeństwa IT może zweryfikować ekspozycję, segmentację, konta i proces odzyskania zaufania do firmware’u.


