Linuxfabrik monitoring-plugins 6.0.0 z luką SSRF: możliwy wyciek poświadczeń Redfish - Security Bez Tabu

Linuxfabrik monitoring-plugins 6.0.0 z luką SSRF: możliwy wyciek poświadczeń Redfish

Cybersecurity news

Wprowadzenie do problemu / definicja

W pakiecie Linuxfabrik monitoring-plugins wykorzystywanym do monitorowania systemów i urządzeń wykryto podatność typu SSRF, czyli Server-Side Request Forgery. Tego rodzaju błąd pozwala aplikacji wykonywać żądania HTTP do lokalizacji wskazanych przez atakującego, co w środowiskach administracyjnych może prowadzić nie tylko do dostępu do zasobów wewnętrznych, ale również do ujawnienia tokenów i nagłówków uwierzytelniających.

W opisywanym przypadku problem dotyczy integracji z interfejsem Redfish, powszechnie używanym do zarządzania sprzętem serwerowym i kontrolerami BMC. Luka występuje w Linuxfabrik monitoring-plugins w wersji 6.0.0 i starszych, a poprawkę wskazano w wydaniu 6.0.1.

W skrócie

Najważniejszy problem polega na błędnej obsłudze pola @odata.id w odpowiedziach Redfish. Specjalnie spreparowana wartość może sprawić, że kolejne żądanie zostanie wysłane nie do zaufanego kontrolera BMC, lecz do hosta kontrolowanego przez atakującego.

  • Podatność dotyczy Linuxfabrik monitoring-plugins do wersji 6.0.0 włącznie.
  • Błąd umożliwia scenariusz SSRF połączony z wyciekiem poświadczeń.
  • Zagrożone mogą być tokeny sesyjne oraz nagłówki autoryzacyjne używane w komunikacji z Redfish.
  • Wersja 6.0.1 została wskazana jako wydanie zawierające poprawkę.

Kontekst / historia

Linuxfabrik monitoring-plugins to zestaw wtyczek wykorzystywanych do nadzoru nad infrastrukturą IT, w tym urządzeniami udostępniającymi API Redfish. Standard Redfish jest szeroko stosowany w zarządzaniu serwerami, dlatego wszelkie błędy w integracjach z tym interfejsem mają istotne znaczenie dla bezpieczeństwa operacyjnego.

Publiczny opis problemu powiązano z advisory GHSA-96fx-pqc3-28xv. Udostępniony materiał obejmuje również demonstracyjny proof of concept, który pokazuje, że podatność nie wymaga klasycznego przekierowania HTTP. Wystarczająca okazuje się manipulacja danymi zwracanymi przez API, jeśli aplikacja traktuje je jako zaufane odniesienia do kolejnych zasobów.

Analiza techniczna

Źródłem problemu jest sposób interpretacji pola @odata.id w odpowiedzi JSON zwracanej przez Redfish. W poprawnym scenariuszu wartość ta powinna wskazywać ścieżkę zasobu znajdującego się w obrębie już zaufanego endpointu. Jeżeli jednak aplikacja akceptuje wartość bez wiodącego ukośnika, może dojść do niezamierzonej zmiany hosta docelowego dla następnego żądania.

Mechanizm ataku można opisać następująco:

  • wtyczka łączy się z prawidłowym endpointem Redfish kontrolera BMC,
  • tworzona jest sesja i pobierany jest token uwierzytelniający,
  • aplikacja analizuje odpowiedź JSON zawierającą odwołania do kolejnych zasobów,
  • spreparowane pole @odata.id kieruje logikę aplikacji do zewnętrznego hosta,
  • wtyczka wykonuje nowe żądanie do lokalizacji kontrolowanej przez atakującego,
  • do żądania mogą zostać dołączone wcześniej używane nagłówki, takie jak X-Auth-Token lub Authorization.

To oznacza połączenie klasycznego SSRF z ryzykiem przekazania sekretów poza zaufaną granicę komunikacji. Z perspektywy obrońcy szczególnie ważne jest to, że podatność nie polega wyłącznie na możliwości pobrania danych z innego adresu, lecz na realnym wycieku poświadczeń używanych do zarządzania infrastrukturą.

Konsekwencje / ryzyko

Skutki tej luki mogą być poważne zwłaszcza tam, gdzie monitoring korzysta z kont uprzywilejowanych lub ma dostęp do odseparowanej sieci zarządzającej. Utrata tokenów sesyjnych Redfish może prowadzić do przejęcia sesji administracyjnej albo dalszej eskalacji działań w środowisku.

  • ujawnienie poświadczeń do kontrolerów BMC,
  • przejęcie aktywnej sesji zarządzającej,
  • nieautoryzowany dostęp do telemetrii i konfiguracji urządzeń,
  • możliwość pivotingu do innych segmentów sieci administracyjnej,
  • osłabienie separacji między monitoringiem a płaszczyzną zarządzania.

Praktyczny wpływ podatności zależy od poziomu uprawnień używanych kont, możliwości podstawienia odpowiedzi, polityki ruchu wychodzącego oraz zakresu zaufania, jakim objęto dane zwracane przez API Redfish.

Rekomendacje

Podstawowym krokiem powinno być ustalenie używanej wersji pakietu i niezwłoczna aktualizacja do wydania zawierającego poprawkę. Sama aktualizacja nie powinna jednak być jedynym działaniem, ponieważ incydent pokazuje szerszy problem związany z nadmiernym zaufaniem do danych wejściowych pochodzących z interfejsów zarządzania.

  • zaktualizować Linuxfabrik monitoring-plugins do wersji 6.0.1 lub nowszej,
  • przeprowadzić przegląd integracji korzystających z Redfish,
  • ograniczyć ruch wychodzący z hostów monitoringu wyłącznie do zaufanych adresów i portów,
  • wdrożyć listy dozwolonych hostów dla połączeń do kontrolerów BMC,
  • uniemożliwić przekazywanie nagłówków autoryzacyjnych do niezaufanych lokalizacji,
  • monitorować logi pod kątem nietypowych połączeń wychodzących,
  • stosować zasadę minimalnych uprawnień dla kont i tokenów Redfish,
  • rotować sekrety, jeśli istnieje podejrzenie ich ekspozycji.

Z perspektywy projektowej kluczowe jest rygorystyczne walidowanie wartości @odata.id oraz wymuszenie, by identyfikatory zasobów były interpretowane wyłącznie jako ścieżki w obrębie już uwierzytelnionego hosta. Dodatkowo logika przenoszenia nagłówków autoryzacyjnych powinna być ściśle związana z konkretnym hostem docelowym.

Podsumowanie

Podatność w Linuxfabrik monitoring-plugins pokazuje, jak niewielki pozornie błąd w obsłudze referencji API może doprowadzić do poważnego naruszenia bezpieczeństwa. W tym przypadku SSRF może skutkować wyciekiem tokenów i nagłówków uwierzytelniających używanych do komunikacji z BMC przez Redfish, co czyni problem szczególnie istotnym dla administratorów środowisk serwerowych.

Dla organizacji korzystających z tego pakietu priorytetem powinna być szybka aktualizacja, ograniczenie zaufania do danych zwracanych przez API oraz wzmocnienie kontroli nad ruchem wychodzącym z systemów monitoringu.

Źródła

  1. Exploit Database – Linuxfabrik monitoring_plugins_6.0.0 – SSRF – Multiple webapps Exploit
    https://www.exploit-db.com/exploits/52653
  2. GitHub Advisory – GHSA-96fx-pqc3-28xv
    https://github.com/advisories/GHSA-96fx-pqc3-28xv
  3. Linuxfabrik monitoring-plugins – repository
    https://github.com/Linuxfabrik/monitoring-plugins
  4. DMTF Redfish Standard – overview
    https://www.dmtf.org/standards/redfish
  5. OWASP – Server Side Request Forgery Prevention Cheat Sheet
    https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html