Podatności FileRise

FileRise przed wersją 3.28.0 zawiera podatność eskalacji uprawnień, która pozwala uwierzytelnionym atakującym z niskimi uprawnieniami uzyskać nieautoryzowany dostęp do odczytu i zapisu poprzez wykorzystanie nieprawidłowej izolacji sesji między interfejsem WebDAV a kontekstem sesji aplikacji webowej. Atakujący mogą połączyć ważne poświadczenia Basic-Auth z aktywnym plikiem cookie PHPSESSID administratora, aby obejść granice autoryzacji.

FileRise przed wersją 3.16.0 jest podatny na path traversal w punkcie końcowym przesyłania plików do folderu współdzielonego (/api/folder/uploadToSharedFolder.php), co prowadzi do dowolnego zapisu plików i przejęcia konta administratora. Walidacja nazwy pliku przez FolderController przepuszcza sekwencje zakodowane w URL.

FileRise to samodzielnie hostowany menedżer plików. Od wersji 3.9.0 do 3.22.0 czyste instalacje manualne bez PERSISTENT_TOKENS_KEY lub metadata/persistent_tokens.key mogą aktywować opublikowany klucz zgodności legacy. Jeśli atakujący zdobędzie pliki kont lub konfiguracji zawierające szyfrogram, znany klucz zapasowy umożliwi odszyfrowanie sekretów TOTP lub poświadczeń. Problem naprawiono w wersji 3.22.0.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise zwracał zapisaną wartość branding.footerHtml przez nieuwierzytelnione publiczne API konfiguracji witryny bez sanityzacji po stronie serwera. Frontend FileRise sanityzuje tę wartość przed renderowaniem, ale surowy HTML był eksponowany przez API. Administrator musi najpierw zapisać złośliwą wartość stopki. Problem naprawiono w wersji 3.21.0.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise śledzi nieudane logowania tylko na podstawie kombinacji adresu IP źródła i nazwy użytkownika. Zdalny nieuwierzytelniony atakujący może rotować nazwy użytkowników, aby uzyskać świeży budżet prób dla każdej nazwy, umożliwiając password spraying z jednego źródła poza zamierzonym limitem. Problem naprawiono w wersji 3.21.0.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise egzekwuje disableFormLogin, disableBasicAuth i disableOIDCLogin w interfejsie klienta, ale niekonsekwentnie w odpowiednich przepływach uwierzytelniania po stronie serwera. Użytkownik z ważnymi poświadczeniami dla wyłączonej metody może wywołać jej endpoint backendu bezpośrednio i uwierzytelnić się mimo polityki administratora. Problem naprawiono w wersji 3.21.0.

W FileRise przed wersją 3.20.0 punkt końcowy /api/file/snippet.php nie stosuje standardowej kontroli uwierzytelnionej sesji przed przetwarzaniem żądań podglądu krótkich tekstów. Endpoint nadal wykonuje kontrole ACL, więc typowe instalacje nie ujawniają nieuwierzytelnionego odczytu dowolnych plików, ale nieuwierzytelnione żądania docierają do oceny ACL zamiast natychmiastowej odpowiedzi 401. Jedynie nietypowe nagłówki proxy lub błędna konfiguracja ACL mogą pozwolić żądaniom wejść w obsługę ścieżek i zawartości plików.

FileRise przed wersją 3.19.0 nie odrzuca segmentów ścieżki typu ".." w parametrze folderName przed utworzeniem katalogu przez FolderModel::createFolder(). Uwierzytelniony użytkownik z niskimi uprawnieniami, ważnym tokenem CSRF oraz prawem tworzenia lub właściciela katalogu nadrzędnego może wysłać segmenty traversal do POST /api/folder/createFolder.php i utworzyć katalogi poza UPLOAD_DIR.

W FileRise przed wersją 3.18.0 ścieżki folderów są spłaszczane do nazw plików metadanych poprzez zastępowanie separatorów i spacji myślnikami, przez co różne foldery (np. team/docs i team-docs) mogą współdzielić jeden plik metadanych. Użytkownik o niskich uprawnieniach, który kontroluje kolidujący folder i zna nazwę pliku docelowego, może zmodyfikować metadane, sprawić że cudzy plik wygląda na jego własny, a następnie go odczytać i zmodyfikować.

W FileRise przed wersją 3.18.0 udostępnione foldery z możliwością wysyłania oraz linki tylko do wysyłania nie odrzucają nazwy pliku docelowego, która już istnieje. Nieuwierzytelniony gość z ważnym tokenem udostępniania i hasłem może wysłać plik o tej samej nazwie i po cichu zastąpić jego zawartość, zachowując oryginalne metadane. Ten sam problem dotyczy zwykłych uwierzytelnionych wysyłek przez /api/upload/upload.php oraz użytkowników tylko do wysyłania bez prawa edycji istniejącego pliku.

FileRise przed wersją 3.16.0 przechowuje flagę isAdmin w tokenach remember-me i przywraca tę nieaktualną wartość podczas automatycznego logowania, zamiast odczytywać bieżącą rolę konta z users.txt. Użytkownik, któremu wydano token, gdy był administratorem, może zachować uprawnienia administratora po degradacji, a rotacja tokenów kopiuje ten nieaktualny przywilej do każdego nowego tokenu.

W FileRise przed wersją 3.16.0 pusty lub brakujący plik users.txt jest traktowany jako świeża instalacja, nawet jeśli konfiguracja została już wcześniej ukończona. Jeśli utrata danych, obcięcie lub inna awaria opróżni magazyn użytkowników, nieuwierzytelniony zdalny atakujący może wykryć ponowne otwarcie trybu konfiguracji i utworzyć kolejne konto administratora. Aplikacja nie miała trwałego znacznika ukończenia konfiguracji niezależnego od modyfikowalnego magazynu użytkowników.

FileRise przed wersją 3.16.0 nie stosuje UploadNamePolicy::isAllowedForWrite() przed zapisem wpisów przez ZipArchive::extractTo() do katalogu docelowego. Uwierzytelniony użytkownik z uprawnieniami do przesyłania i rozpakowywania może umieścić zablokowane rozszerzenie, takie jak plik z rodziny PHP, w archiwum ZIP i spowodować jego zapis na dysku, nawet gdy zwykłe przesyłanie odrzuca taką nazwę pliku.

W FileRise przed wersją 3.16.0, gdy administrator włączył WebDAV, uwierzytelnianie Basic w FileRise WebDAV sprawdza tylko nazwę użytkownika i hasło przez AuthModel::authenticate() i nie wymusza skonfigurowanego czynnika TOTP. Atakujący znający prawidłowe poświadczenia podstawowe konta z włączonym TOTP może uwierzytelnić się w usłudze WebDAV bez drugiego czynnika i korzystać z uprawnień plikowych konta. Ścieżka logowania w przeglądarce wymusza TOTP, ale osobne wywołanie zwrotne public/webdav.php tego nie robiło.

W FileRise przed wersją 3.16.0 wdrożenia z włączonym AUTH_BYPASS ufają skonfigurowanemu nagłówkowi tożsamości reverse-proxy bez weryfikacji, że żądanie pochodzi z FR_TRUSTED_PROXIES. Gdy port backendu jest osiągalny bezpośrednio, nieuwierzytelniony atakujący może podać X-Remote-User i uzyskać sesję dla wskazanego konta, w tym konta administratora, bez hasła i MFA. Wada dotyczy tylko wdrożeń z włączonym uwierzytelnianiem przez nagłówki proxy i wystawioną niezaufaną ścieżką do backendu.

FileRise przed wersją 3.23.0 waliduje nazwy wpisów archiwum, ale rozpakowuje je bezpośrednio do docelowego katalogu, zanim zweryfikuje rozwiązane ścieżki. Jeśli w katalogu docelowym istnieje dowiązanie symboliczne do katalogu poza katalogiem głównym magazynu, uwierzytelniony użytkownik bez uprawnień administratora z prawem rozpakowywania może umieścić wpis archiwum pod tym dowiązaniem i nadpisać lub usunąć plik zewnętrzny.

W FileRise przed wersją 3.23.0 uwierzytelniona tożsamość OIDC jest mapowana na konto lokalne przy użyciu zmiennych roszczeń preferred_username lub email, bez wymogu email_verified. Atakujący mogący uzyskać od dostawcy roszczenie kolidujące z istniejącą nazwą użytkownika może zalogować się jako to konto, w tym jako wbudowany administrator, nawet gdy automatyczne tworzenie kont jest wyłączone.

W FileRise 3.22.0 operacja /api/file/saveFile.php akceptuje segmenty kropki i podwójnej kropki w kontrolowanym przez atakującego parametrze folderu, zanim dziedziczenie ACL oceni niekanoniczny łańcuch. Uwierzytelniony użytkownik bez uprawnień administratora z ważnym tokenem CSRF i odziedziczonym prawem edycji może tworzyć pliki poza autoryzowanym folderem, a przy odpowiednich poświadczeniach backendu także poza skonfigurowanym katalogiem głównym WebDAV.

FileRise przed wersją 3.23.0 pozwala uwierzytelnionej sesji z ważnym tokenem CSRF wyłączyć TOTP bez ponownej pełnej autoryzacji lub rozpocząć rejestrację, gdy konto nie ma jeszcze sekretu TOTP. Nowo wygenerowany sekret jest zapisywany i aktywowany przed weryfikacją kodu TOTP, co pozwala atakującemu kontrolującemu istniejącą sesję wyłączyć drugi czynnik lub go zarejestrować.

FileRise przed wersją 3.23.0 weryfikuje ważność kodu TOTP w akceptowanym oknie czasowym, ale nie rejestruje, że dane konto i krok czasowy już zostały pomyślnie użyte. Atakujący posiadający ważne podstawowe poświadczenie ofiary i przechwytujący kod TOTP po jego użyciu może odtworzyć ten kod z innej sesji logowania przed zamknięciem okna.

FileRise przed wersją 3.23.0 w /api/folder/renameFolder.php autoryzuje uwierzytelnionego użytkownika bez uprawnień administratora i bez zakresu folderu z ważnym tokenem CSRF względem folderu źródłowego, ale nie autoryzuje niezależnie zmienionego folderu nadrzędnego docelowego. Użytkownik będący właścicielem folderu źródłowego może przenieść to drzewo pod folder innego użytkownika lub do katalogu głównego, a operacja przepisuje rekordy własności i ACL na nową ścieżkę.

W FileRise przed wersją 3.23.0 nieudane próby weryfikacji TOTP są przechowywane w $_SESSION, co pozwala atakującemu posiadającemu ważne podstawowe poświadczenia konta na restart procesu logowania w nowej sesji i przywrócenie limitu prób. Umożliwia to dalsze zgadywanie kodów TOTP poza zamierzonym limitem pięciu prób.

W FileRise przed wersją 3.15.0 publiczne linki do udostępnionych folderów z włączonym przeglądaniem podfolderów mogą podążać za dowiązaniem symbolicznym wewnątrz udostępnionego folderu do katalogu sąsiedniego w katalogu głównym uploadu. Nieuwierzytelniony posiadacz ważnego tokenu udostępniania może użyć listowania folderu, bezpośredniego pobierania lub tworzenia ZIP, aby uzyskać dostęp do plików poza faktycznie udostępnionym folderem.

FileRise przed wersją 3.14.0 uwierzytelnia żądania do obsługi tworzenia plików i linków udostępniania, ale nie wymusza sprawdzania tokenu CSRF używanego przez sąsiednie operacje zmieniające stan. Endpointy POST /api/file/createFile.php oraz /api/file/createShareLink.php nie odrzucają brakującego lub nieprawidłowego nagłówka X-CSRF-Token. Żądanie z sesją zalogowanego użytkownika może utworzyć pusty plik lub link udostępniania z uprawnieniami tego użytkownika, choć domyślne ciasteczko SameSite=Lax ogranicza zwykłe cross-site POST.

FileRise to samodzielnie hostowany menedżer plików internetowych z obsługą wielu plików, edycją i operacjami wsadowymi. W wersjach przed 2.2.3 występuje podatność typu stored XSS wynikająca z niewłaściwego obsługi przesyłanych plików SVG; aplikacja akceptuje pliki SVG bez sanityzacji lub ograniczania osadzonego kodu skryptowego, co pozwala na wykonanie złośliwego skryptu w kontekście aplikacji.

FileRise w wersji 1.4.0 ma regresję, która pozwala na wnioskowanie o widoczności/własności folderów na podstawie ich nazw. Użytkownicy z niskimi uprawnieniami mogli widzieć lub wchodzić w interakcje z folderami pasującymi do ich nazwy użytkownika, a w niektórych przypadkach z zawartością innych użytkowników. Problem naprawiono w wersji 1.5.0, która wprowadza jawne listy ACL dla folderów i rygorystyczne kontrole po stronie serwera.

FileRise przed wersją 1.4.0 ma wadę logiki biznesowej w obsłudze plików/folderów, która pozwala użytkownikom z niskimi uprawnieniami na nieautoryzowane operacje (przeglądanie/usuwanie/modyfikację) na plikach utworzonych przez innych użytkowników. Przyczyną było wnioskowanie o własności/widoczności na podstawie nazw folderów oraz brak kontroli autoryzacji po stronie serwera. Jest to wzorzec IDOR. Poprawiono w wersji 1.4.0 i wzmocniono w 1.5.0.