Osoby odpowiedzialne za utrzymanie oprogramowania open source do wizualizacji danych Apache Superset opublikowali poprawki mające na celu załatanie luki oznaczonej jako CVE-2023-27524 która mogłaby prowadzić do zdalnego wykonania kodu (Remote Code Execution).

Luka oznaczona jako CVE-2023-27524 (uzyskała wynik CVSS na poziomie 8.9), dotyczy wersji do 2.0.1 włącznie i dotyczy użycia domyślnego klucza SECRET_KEY, który może zostać wykorzystany przez osoby atakujące w celu uwierzytelnienia i uzyskania dostępu do nieautoryzowanych zasobów na instancjach udostępnionych w internecie.

Warto zauważyć, że luka nie wpływa na instancje Superset, które zmieniły domyślną wartość konfiguracji SECRET_KEY na bardziej kryptograficznie bezpieczny losowy ciąg.

Badacze z Horizon3.ai, firmy zajmującej się cyberbezpieczeństwem, stwierdzili, że SECRET_KEY ma domyślną wartość „\x02\x01thisismyscretkey\x01\x02\e\y\y\h”. Stwierdzili również, że 918 z 1288 publicznie dostępnych serwerów korzystało z domyślnej konfiguracji w październiku 2021 r.

Znając klucz, atakujący mógłby zalogować się na serwery jako administrator, sfałszować sesyjny plik cookie i następnie przejąć kontrolę nad systemami.

W styczniu 2022 r. osoby odpowiedzialne za utrzymanie, podjęły próbę rozwiązania problemu, zmieniając wartość SECRET_KEY na „CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET” w kodzie Pythona wraz z instrukcjami użytkownika, tak aby go zastąpić.

Badacze zHorizon3.ai stwierdzili ponadto, że znaleźli dwie dodatkowe konfiguracje SECRET_KEY, którym przypisano wartości domyślne „USE_YOUR_OWN_SECURE_RANDOM_KEY” i „thisISaSECRET_1234”.

Rozszerzone wyszukiwanie przeprowadzone w lutym 2023 r. przy użyciu tych czterech kluczy ujawniło 3176 instancji, z których 2124 korzystało z jednego z kluczy domyślnych. Niektóre z tych, których to dotyczy, to duże korporacje, małe firmy, agencje rządowe i uniwersytety.

W kwietniu 2023 r. opublikowano nową aktualizację (wersja 2.1), aby załatać lukę w zabezpieczeniach, uniemożliwiając całkowite uruchomienie serwera, jeśli jest skonfigurowany z domyślnym kluczem SECRET_KEY.

„Ta poprawka nie jest jednak niezawodna, ponieważ nadal można uruchomić Superset z domyślnym kluczem SECRET_KEY, jeśli jest on zainstalowany za pomocą dockerfile lub helm template” — powiedział Sunkavally.

„Docker file zawiera nowy domyślny SECRET_KEY z TEST_NON_DEV_SECRET, z którym, jak podejrzewamy, niektórzy użytkownicy nieświadomie uruchomią Superset. Niektóre konfiguracje ustawiają również admin/admin jako domyślne poświadczenie dla administratora”.

Badacze z Horizon3.ai udostępnili również skrypt (w Python), którego można użyć do określenia, czy instancje Superset są podatne na lukę.

„Powszechnie przyjmuje się, że użytkownicy nie czytają dokumentacji, a aplikacje powinny być zaprojektowane tak, aby zmusić użytkowników do podążania ścieżką, na której nie mają innego wyboru, jak tylko domyślnie zapewnić bezpieczeństwo” — podsumował Sunkavally. „Najlepszym podejściem jest odebranie użytkownikom możliwości wyboru i wymaganie od nich podejmowania celowych działań, aby celowo czuć się niepewnie”.

Jaki z tego wniosek? Należy dokładnie przeczytać dokumentację, zanim podejmie się jakieś konkretne decyzje co do budowy architektury. Zawsze trzeba pamiętać o stosowaniu dobrych praktyk bezpieczeństwa, a gdy się czegoś nie wie, to ponownie sprawdzić, dopytać i oddać do testów bezpieczeństwa. Na pewno zwiększy to znacząco bezpieczeństwo systemów i aplikacji.

źródło: https://thehackernews.com/2023/04/apache-superset-vulnerability-insecure.html