Wprowadzenie do problemu / definicja
W wersji Duplicati 2.2.0.3 ujawniono groźną podatność bezpieczeństwa prowadzącą do wycieku konfiguracji JWT, w tym klucza SigningKey używanego do podpisywania tokenów dostępowych. Błąd dotyczy interfejsu API serwera i umożliwia obejście mechanizmu ochrony wrażliwych ustawień konfiguracyjnych.
W praktyce oznacza to, że uwierzytelniony użytkownik może pozyskać sekret wykorzystywany do podpisywania tokenów, a następnie wygenerować własny token administracyjny. Taki scenariusz prowadzi do pełnej eskalacji uprawnień w podatnej instancji aplikacji.
W skrócie
- Podatność dotyczy Duplicati 2.2.0.3 oraz wcześniejszych podatnych wydań.
- Problem wynika z obejścia ochrony konfiguracji JWT poprzez użycie alternatywnej wielkości liter w nazwie parametru.
- Atakujący może odczytać SigningKey, Authority i Audience.
- Uzyskane dane pozwalają wygenerować ważny token JWT z uprawnieniami administratora.
- Skutkiem jest pełne przejęcie panelu zarządzania Duplicati.
Kontekst / historia
Duplicati to popularne narzędzie do tworzenia kopii zapasowych, często używane w środowiskach self-hosted, na serwerach domowych oraz we wdrożeniach kontenerowych. Aplikacja udostępnia interfejs WWW oparty na serwerowym API i mechanizmie tokenów dostępowych, co sprawia, że ochrona warstwy uwierzytelniania ma kluczowe znaczenie dla bezpieczeństwa całego systemu.
Publicznie opisany proof-of-concept wskazuje, że problem został powiązany z błędem walidacji nazwy ustawienia po stronie serwera. Z ujawnionych informacji wynika również, że przygotowano poprawkę w repozytorium projektu, a sama podatność została zgłoszona w ramach odpowiedzialnego procesu ujawnienia.
Analiza techniczna
Źródłem podatności jest niespójna obsługa identyfikatora ustawienia konfiguracyjnego odpowiedzialnego za dane JWT. Mechanizm ochronny blokuje dostęp do wpisu „jwt-config”, jednak porównanie nazwy okazuje się wrażliwe na wielkość liter. W rezultacie żądanie odwołujące się do wariantu „JWTConfig” może przejść przez kontrolę dostępu, mimo że logicznie wskazuje ten sam zasób.
Scenariusz ataku jest relatywnie prosty. Najpierw napastnik loguje się jako zwykły użytkownik i uzyskuje prawidłowy token dostępu. Następnie wysyła żądanie do endpointu ustawień serwera z odpowiednio zmodyfikowaną nazwą parametru. Odpowiedź może zawierać SigningKey, Authority oraz Audience, czyli komplet informacji potrzebnych do lokalnego wygenerowania nowego tokenu JWT podpisanego algorytmem HS256.
Z perspektywy bezpieczeństwa jest to szczególnie niebezpieczne, ponieważ aplikacja ufa tokenowi na podstawie poprawnego podpisu i zgodności parametrów warstwy JWT. Jeżeli atakujący zna sekret podpisujący, granica zaufania przestaje działać. Publiczny proof-of-concept pokazuje, że po wygenerowaniu sfałszowanego tokenu można skutecznie wykonywać żądania administracyjne, co potwierdza pełne przejęcie uprawnień.
Technicznie problem łączy dwa krytyczne obszary: błąd autoryzacji na poziomie API oraz wyciek sekretu kryptograficznego. Taka kombinacja jest wyjątkowo groźna, ponieważ umożliwia nie tylko jednorazowe obejście kontroli dostępu, ale także trwałą eskalację uprawnień aż do momentu zmiany sekretu JWT.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest pełne przejęcie panelu administracyjnego Duplicati przez osobę posiadającą dowolny ważny poziom uwierzytelnienia w podatnej instancji. W zależności od konfiguracji może to oznaczać dostęp do harmonogramów backupu, ścieżek lokalnych, konfiguracji zdalnych magazynów danych, metadanych zadań oraz operacji przywracania lub modyfikowania kopii zapasowych.
Ryzyko znacząco rośnie w środowiskach, w których interfejs WWW jest wystawiony do sieci lokalnej lub Internetu, działa bez dodatkowej ochrony reverse proxy albo obsługuje wielu użytkowników o różnym poziomie zaufania. W takich przypadkach nawet konto o ograniczonych możliwościach może stać się punktem wyjścia do pełnej kompromitacji systemu.
Istotnym problemem operacyjnym jest również to, że po ujawnieniu SigningKey zwykły reset sesji użytkowników może nie wystarczyć. Dopóki aplikacja akceptuje ten sam sekret JWT, napastnik może generować kolejne ważne tokeny. Oznacza to konieczność nie tylko aktualizacji oprogramowania, ale także rotacji sekretów oraz przeglądu logów pod kątem nadużyć.
Rekomendacje
Administratorzy powinni w pierwszej kolejności ustalić, czy ich instancja Duplicati korzysta z wersji 2.2.0.3 lub wcześniejszej podatnej gałęzi. Jeżeli tak, należy niezwłocznie wdrożyć wersję zawierającą poprawkę lub aktualizację rekomendowaną przez producenta.
Po aktualizacji warto przeprowadzić reset konfiguracji JWT, aby unieważnić wcześniej ujawniony SigningKey. Samo zakończenie aktywnych sesji nie daje pełnej gwarancji bezpieczeństwa, jeśli sekret pozostaje bez zmian. Dodatkowo należy przeanalizować logi aplikacyjne i serwera proxy pod kątem nietypowych odwołań do endpointów ustawień oraz anomalii związanych z tokenami Bearer.
- ograniczyć ekspozycję interfejsu WWW wyłącznie do zaufanych hostów lub sieci zarządzającej,
- wymusić dodatkową warstwę dostępu przez reverse proxy, VPN lub segmentację sieci,
- zminimalizować liczbę kont posiadających dostęp do instancji,
- regularnie rotować sekrety oraz hasła administracyjne,
- monitorować żądania kierowane do wrażliwych endpointów API,
- prowadzić okresowe testy bezpieczeństwa obejmujące przypadki związane z normalizacją nazw i wielkością liter.
Dobrą praktyką jest także traktowanie każdego wycieku sekretów JWT jako pełnoprawnego incydentu bezpieczeństwa, wymagającego potwierdzenia zakresu kompromitacji, wymiany poświadczeń i ponownej oceny zaufania do systemu.
Podsumowanie
Podatność ujawniona w Duplicati 2.2.0.3 pokazuje, że nawet pozornie drobny błąd związany z walidacją wielkości liter może doprowadzić do pełnego obejścia mechanizmów bezpieczeństwa. W tym przypadku konsekwencją jest nie tylko odczyt pojedynczego ustawienia, ale ujawnienie klucza podpisującego JWT, co bezpośrednio umożliwia fałszowanie tokenów i przejęcie roli administratora.
Dla organizacji i użytkowników indywidualnych oznacza to potrzebę szybkiej aktualizacji, rotacji konfiguracji JWT oraz weryfikacji, czy interfejs zarządzający Duplicati nie był nadużywany. To również ważne przypomnienie, że dostęp do sekretów kryptograficznych musi być chroniony w sposób odporny na błędy implementacyjne i niespójności w obsłudze danych wejściowych.