Podatności nebula-mesh

Podatność w nebula-mesh umożliwia eskalację uprawnień poprzez brak odpowiedniej kontroli dostępu na wielu endpointach API. Każdy operator z kluczem API może uzyskać dostęp do zasobów innych operatorów.

nebula-mesh (wersje od 0.6.0 do przed 0.7.2) umożliwia operatorom bez uprawnień administratora (rola user) ustawienie allow_private: true na własnych subskrypcjach webhook (POST/PATCH /api/v1/webhook-subscriptions). Brakuje kontroli administracyjnej na tym polu. Podczas dostarczania webhooka, allow_private przełącza dyspozytora na niechroniony klient HTTP, omijając zabezpieczenia SSRF dla adresów prywatnych/pętli zwrotnej/link-local, co pozwala operatorowi o niskich uprawnieniach na zmuszenie serwera do żądań wewnętrznych adresów.

nebula-mesh przed wersją 0.7.1 ma lukę, gdzie odwołanie (revocation) jest jedynym mechanizmem izolacji skompromitowanego hosta. Ponieważ lista zablokowanych nie dociera do plików config.yml żadnego peera, zablokowany host zachowuje pełną dostępność do wszystkich peerów w swojej sieci przez okres do 30 dni (agent) lub 365 dni (mobile). Atakujący, który wykradnie host.key+host.crt, może uruchomić standardowe slackhq/nebula bezpośrednio, ignorując odpowiedzi agenta 403/410, i pozostać połączonym po odwołaniu hosta przez operatora.

nebula-mesh to samodzielnie hostowany panel sterowania dla Slack Nebula mesh VPN. Od wersji 0.3.0 do przed 0.5.0, ścieżka tworzenia hosta w interfejsie Web UI nebula-mgmt ignoruje zarówno ustawienie bezpieczeństwa enrollment_token_ttl dla całego serwera, jak i nadpisania per-network network_config.enrollment_token_ttl. API tworzenia hosta i ścieżki regeneracji tokenów używają skonfigurowanego resolvera TTL, ale POST /ui/hosts twardo koduje now.Add(24 * time.Hour) dla nowo utworzonych tokenów rejestracji agenta. W środowiskach, które celowo skracają czas życia tokenów rejestracji, każdy uwierzytelniony operator, który może utworzyć hosta przez Web UI, może nadal wygenerować token rejestracji nośnika ważny przez około 24 godziny. Problem został naprawiony w wersji 0.5.0.

nebula-mesh to samodzielnie hostowany panel sterowania dla Slack Nebula mesh VPN. Od wersji 0.2.0 do przed 0.5.0, gdy OIDC jest włączone, GET /ui/oidc/login jest osiągalny bez uwierzytelnienia i jest zarejestrowany poza trasami auth z limitem szybkości w Web UI. Każde żądanie tworzy nowy losowy stan OIDC i przechowuje go w mapie w pamięci przez 10 minut. Wygasłe stany są usuwane leniwie, ale nie ma limitu szybkości ani maksymalnego limitu żywych stanów na ścieżce alokacji. Zdalny klient bez uwierzytelnienia może zatem zwiększać OIDC.states przez pełny czas TTL stanu, ograniczony przepustowością żądań, a nie skonfigurowanymi limitami szybkości auth. Problem został naprawiony w wersji 0.5.0.

nebula-mesh przed wersją 0.3.8 ma lukę w obsłudze webowej, gdzie renderMobileBundle przekazuje rzeczywisty *pki.CAResolver do mobilebundle.Build. W Build, resolver.LoadByID odszyfrowuje prywatny klucz ed25519 CA do *pki.CAManager, ale Build nigdy nie wywołuje CAManager.Wipe() na żadnej ścieżce powrotu. W rezultacie, gdy żądanie mobilnego pakietu przechodzi przez web UI i Build zwraca (szczególnie przy błędzie), klucz prywatny CA pozostaje w pamięci Go, nieusunięty, aż do garbage collection. Atakujący, który może odczytać pamięć procesu (core dump, swap, skanowanie pamięci), może odzyskać klucz podpisujący CA, co pozwoliłoby na tworzenie dowolnych certyfikatów hosta dla sieci mesh.

nebula-mesh przed wersją 0.3.8 przechowuje tokeny sesji operatora w postaci jawnego tekstu w tabeli operator_sessions (kolumna token jest kluczem głównym). Token sesji to 32-bajtowa losowa wartość hex wysyłana bezpośrednio w ciasteczku i ważna przez 24 godziny. Każdy, kto może odczytać bazę danych (backup, snapshot, kopia pliku, lub wyciek na poziomie SQL), uzyskuje wszystkie aktywne tokeny sesji i może przejąć sesje operatora bez dodatkowego uwierzytelnienia.

nebula-mesh przed wersją 0.3.7 ma dwie luki autoryzacyjne: blocklista nie jest sprawdzana przy podpisywaniu/ponownej rejestracji certyfikatu (kluczowana po odcisku palca, więc ponowna rejestracja tworzy nowy odcisk), a odnowienie certyfikatu nie weryfikuje ponownie statusu operatora ani CA. Host, który nie powinien być już zaufany, może uzyskać nowy ważny certyfikat Nebula.

Nebula Mesh w wersjach 0.3.5 i niższych nie stosuje ograniczeń CA dla operatorów w interfejsie web UI, co pozwala uwierzytelnionemu operatorowi niebędącemu administratorem na dostęp do zasobów innych operatorów. Luka została częściowo zaadresowana w GHSA-598g-h2vc-h5vg, ale nie objęła interfejsu web.

nebula-mesh przed wersją 0.3.2 ustawia flagi HttpOnly i SameSite=Lax na ciasteczkach, ale nigdy nie ustawia flagi Secure. Pojedyncze żądanie w czystym tekście do origin (np. operator w LAN, błędnie wpisany URL, brak ścisłego wymuszania HTTP→HTTPS, błędna konfiguracja reverse proxy) ujawnia sesję.

W nebula-mesh przed wersją 0.3.2 nowo wygenerowany klucz API operatora był ujawniany w adresie URL przekierowania, co mogło prowadzić do wycieku w nagłówku Referer, historii przeglądarki lub logach proxy. Problem został naprawiony w wersji 0.3.2.

nebula-mesh w wersjach przed 0.3.2 nie sprawdza uprawnień administratora dla endpointu dziennika audytu. Każdy operator z kluczem API może odczytać pełny dziennik audytu, w tym dane innych dzierżawców.

W nebula-mesh przed wersją 0.3.3 wszystkie trasy /ui/* z metodami POST/PUT/PATCH/DELETE przetwarzają żądanie natychmiast po walidacji ciasteczka sesyjnego. Ustawienie SameSite=Lax nie chroni przed atakami z domen trzecich (np. nawigacje najwyższego poziomu, ataki z poddomen) ani przed atakami na trasę GET /ui/logout. Problem został naprawiony w wersji 0.3.3.

W nebula-mesh przed wersją 0.3.7 odszyfrowane klucze prywatne CA pozostają w stercie procesu po użyciu, ponieważ nie są zerowane przed zwolnieniem pamięci. Narusza to kontrakt pakietu keystore i może prowadzić do wycieku kluczy. Problem został naprawiony w wersji 0.3.7.

W projekcie nebula-mesh przed wersją 0.3.1 brakuje standardowych nagłówków bezpieczeństwa przeglądarki (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy) w ścieżkach odpowiedzi internal/web/ i internal/api/. Problem naprawiono w wersji 0.3.1.

W nebula-mesh przed wersją 0.3.2, w pliku internal/configgen/generator.go, pola ListenHost i TunDevice są interpolowane bez walidacji do szablonu text/template, co może prowadzić do wstrzykiwania kodu. internal/web/advanced.go akceptuje te pola tylko z usunięciem białych znaków, bez walidacji znaków lub kształtu.