Podatności Psono Server

Psono Server CE i EE w wersjach 4.0.33–7.2.3 porównywał ścieżkę żądania dla endpointu bulk-secret-read z zakodowaną ścieżką bez prefiksu. W konfiguracjach z URL_PREFIX porównanie zawodziło i żądanie POST było autoryzowane z uprawnieniem zapisu zamiast odczytu, co pozwalało uwierzytelnionemu atakującemu z kluczem API bez uprawnień odczytu na pobranie zaszyfrowanych sekretów i nonces.

Psono Server CE i EE w wersjach 0.1.0–7.2.3 akceptował hosta kontrolowanego przez użytkownika przy konfiguracji osobistego urządzenia Duo i przekazywał go do klienta Duo bez listy dozwolonych i jawnego limitu czasu. Uwierzytelniony atakujący mógł spowodować połączenie serwera z wybranymi hostami przez HTTPS na porcie 443 i rozróżnić tryby błędów, tworząc wyrocznię wewnętrznego DNS i osiągalności usług.

Psono Server CE i EE w wersjach 3.1.0–7.2.3 nie zużywał zapisanego wyzwania WebAuthn po weryfikacji asercji. Nieuwierzytelniony atakujący posiadający hasło użytkownika i jedną przechwyconą ważną asercję WebAuthn mógł ją odtworzyć z osobnymi tokenami logowania, omijając drugi czynnik WebAuthn.

Psono Server (CE i EE) w wersjach 1.0.0–7.2.3 nie wymuszał kierunku poświadczeń transferu plików w operacjach repozytorium plików. Uwierzytelniony atakujący z dostępem tylko do odczytu mógł przedstawić transfer pobierania do endpointu wysyłania, uzyskać podpisany URL wysyłania dla wybranego klucza obiektu i dołączyć fragment do pliku właściciela.

Psono Server w wersjach 5.3.5–7.2.3 używał klasy uprawnień, która nie wymuszała zakresu zapisu tokenu przy zgłaszaniu kodu urządzenia. Uwierzytelniony atakujący z sesją opartą na ograniczonym kluczu API mógł zgłosić kontrolowany przez siebie kod urządzenia i uzyskać pełną sesję odczytu i zapisu ważną do 365 dni.