Podatności Snipe-IT

Snipe-IT przed wersją 8.6.2 zawiera podatność XSS (zapisanego) w nazwie producenta lub dostawcy. Specjalnie spreparowana nazwa może wykonać JavaScript w przeglądarce uwierzytelnionego użytkownika podczas przeglądania strony szczegółów producenta lub dostawcy, potencjalnie ujawniając dane lub umożliwiając działania w kontekście sesji.

Snipe-IT przed wersją 8.6.3 umożliwia każdemu aktywowanemu kontu odczyt rekordów konserwacji dla zasobów w tej samej firmie bez wymaganych uprawnień. Brak autoryzacji w metodzie show() kontrolera MaintenancesController ujawnia dane takie jak tagi zasobów, dostawcy, koszty zakupu, notatki i daty.

Snipe-IT przed wersją 8.6.3 ma podatność, która pozwala ograniczonemu użytkownikowi na uzyskanie losowej nazwy pliku EULA innego użytkownika i pobranie podpisanego pliku. Trasy /stored-eula-file/{filename} i /account/stored-eula-file/{filename} nie egzekwują spójnie uprawnień właściciela i autoryzacji docelowego użytkownika.

Snipe-IT przed wersją 8.6.3 ma podatność, która pozwala użytkownikowi z ograniczeniem do firmy w trybie FMCS floater na dostęp do użytkowników z company_id równym null. Szerokie zapytania API i masowe akcje webowe nie egzekwują spójnie isCurrentUserHasAccess, co może ujawnić dane osobowe i przypisane licencje, a także umożliwić modyfikację profili i usuwanie użytkowników.

Snipe-IT przed wersją 8.4.1 umożliwia uwierzytelnionemu użytkownikowi z ogólnym uprawnieniem edycji zasobów usuwanie plików dołączonych do zasobów spoza jego własności lub firmy. Metody destroy() autoryzują aktualizację względem klasy obiektu zamiast konkretnego wystąpienia, co prowadzi do niebezpiecznego bezpośredniego odwołania do obiektu.

Snipe-IT przed wersją 8.6.0 umożliwia uwierzytelnionemu użytkownikowi z uprawnieniem users.create nadanie uprawnień administratora podczas tworzenia nowego użytkownika. Metoda store() usuwa uprawnienie superużytkownika, ale nie usuwa uprawnienia administratora, co pozwala na uzyskanie przywilejów administracyjnych.

Snipe-IT przed wersją 8.4.1 umożliwia nie-superadministratorowi bezpośrednie przesłanie company_id w metodzie update() kontrolera BulkAssetsController, bez użycia Company::getIdForCurrentUser(). Pozwala to na przenoszenie zasobów między firmami, łamiąc izolację wielodostępową.

Snipe-IT przed wersją 8.5.0 umożliwia użytkownikowi z uprawnieniem edycji innych użytkowników zresetowanie weryfikacji dwuetapowej superadministratora. Endpoint postTwoFactorReset() autoryzuje dostęp do aktualizacji, ale nie egzekwuje canEditAuthFields przed wyczyszczeniem two_factor_secret i two_factor_enrolled.

Snipe-IT przed wersją 8.6.1 umożliwia użytkownikowi z uprawnieniem importu nadpisanie adresu e-mail nie-administratora w trybie aktualizacji CSV, a następnie zażądanie resetu hasła w celu przejęcia konta. Mimo że UserImporter usuwa nieautoryzowane pola, ItemImporter odtwarza je z surowego wiersza CSV, a ścieżka importu nie wymaga uprawnienia users.edit.

Snipe-IT przed wersją 8.6.1 ma podatność w punkcie końcowym POST /two-factor, który nie ma ograniczeń tempa, blokady ani licznika prób. Pozwala to atakującemu z ważnymi poświadczeniami na nieograniczone zgadywanie kodów TOTP, a także umożliwia wyłączenie 2FA bez ponownej weryfikacji OTP w niektórych trybach.

Snipe-IT przed wersją 8.6.0 zawiera obejście autoryzacji (niebezpieczne bezpośrednie odwołanie do obiektu) w punkcie końcowym anulowania żądania wypożyczenia zasobu. Wartości cancel_by_admin i requestingUser są odczytywane z segmentów ścieżki URL kontrolowanych przez użytkownika i używane bez kontroli autoryzacji po stronie serwera, więc każdy uwierzytelniony użytkownik z niskimi uprawnieniami może podać niepustą wartość cancel_by_admin, aby ominąć kontrolę własności żądania i anulować oczekujące żądanie wypożyczenia innego użytkownika. Ponieważ identyfikatory zasobów i użytkowników są sekwencyjnymi liczbami całkowitymi, atakujący może je wyliczyć, aby anulować wszystkie oczekujące żądania wypożyczenia, zakłócając przepływ pracy z żądaniami zasobów. Problem został naprawiony w Snipe-IT 8.6.0.

W Snipe-IT przed wersją 8.6.2, endpoint usuwania raportu niezaakceptowanych aktywów autoryzuje jedynie raporty.view i usuwa rekordy CheckoutAcceptance::pending()->find($acceptanceId) po globalnym ID bez sprawdzania dostępu do powiązanego aktywa. Pozwala to użytkownikowi raportów z jednej firmy na usuwanie rekordów oczekujących akceptacji dla innej firmy.

W Snipe-IT przed wersją 8.6.2, w pliku default.blade.php, ustawienia kolorów nagłówka i powiązanych elementów marki są renderowane w bloku CSS z niewystarczającym kodowaniem HTML dla kontekstu CSS. Umożliwia to superadministratorowi wstrzyknięcie dowolnego CSS, który wpływa na uwierzytelnionych użytkowników przy kolejnych ładowaniach stron, gdy Content Security Policy jest wyłączone.

W systemie Snipe-IT przed wersją 8.6.2 stwierdzono podatność w procesie zwrotu pojedynczej licencji. Stary punkt końcowy autoryzuje akcję za pomocą uprawnienia do przypisywania licencji zamiast do ich zwalniania, co umożliwia użytkownikowi z prawem do przypisywania licencji, ale bez prawa do ich odbierania, bezpośrednie zwrócenie przypisanego miejsca licencyjnego innemu użytkownikowi lub zasobowi.

W Snipe-IT przed wersją 8.6.1, endpoint API Importera umożliwia użytkownikowi z uprawnieniami do importu CSV i ważnym kluczem API nadpisanie wartości created_by pliku importu, co pozwala na nieautoryzowaną modyfikację metadanych własności importu.

W Snipe-IT przed wersją 8.6.2 uwierzytelniony użytkownik z uprawnieniami importu i aktualizacji zasobów może umieścić w polu obrazu zasobu ciąg do przechodzenia po katalogach podczas importu CSV, a następnie wywołać usunięcie obrazu, co pozwala na usunięcie dowolnych plików dostępnych dla procesu serwera.

Snipe-IT przed wersją 8.6.2 zawiera podatność polegającą na niewystarczającym filtrowaniu przesyłanych plików SVG. Niskouprzywilejowany użytkownik może przesłać aktywną zawartość XHTML lub XML, która jest następnie serwowana w tym samym źródle (same-origin) i wykonuje JavaScript w przeglądarce ofiary.

W Snipe-IT przed wersją 8.6.2, metody UsersController::show() i printInventory() autoryzują jedynie podgląd użytkownika przed załadowaniem i wyświetleniem przypisanych licencji, akcesoriów i materiałów eksploatacyjnych. Umożliwia to uwierzytelnionemu użytkownikowi z uprawnieniem users.view zobaczenie metadanych kosztów i zamówień z modułów, do których bezpośrednie uprawnienia by mu zabroniły.

Podatność w Snipe-IT przed wersją 8.6.2 pozwala atakującemu na przejęcie kontroli nad przekierowaniem po edycji użytkownika. Poprzez ustawienie nagłówka Referer, atakujący może zmusić aplikację do przekierowania ofiary na zewnętrzną, złośliwą stronę.

Snipe-IT przed wersją 8.5.0 przechowuje nagłówek User-Agent z żądania w dzienniku akcji, a następnie zapisuje go do raportu CSV bez odpowiedniego escapowania formuł. Umożliwia to niskouprzywilejowanemu, uwierzytelnionemu użytkownikowi wstrzyknięcie złośliwej formuły, która może zostać wykonana po otwarciu pliku CSV w arkuszu kalkulacyjnym.

W Snipe-IT przed wersją 8.6.0, w metodzie UsersController::update() brakujące pole uprawnień w żądaniu jest przetwarzane przez akcje NormalizePermissionsPayloadAction i PreserveUnauthorizedPrivilegedPermissionsAction w sposób, który może nadpisać uprawnienia docelowego użytkownika niekompletnym zestawem. Pozwala to administratorowi modyfikującemu innego administratora lub użytkownikowi z uprawnieniem users.edit modyfikującemu zwykłe konto na usunięcie uprawnień administracyjnych lub szczegółowych.

Podatność w Snipe-IT przed wersją 8.6.2 umożliwia autoryzowanemu użytkownikowi przeniesienie rekordu konserwacji na zasób spoza zakresu jego firmy. Dzieje się tak, ponieważ żądania PATCH lub PUT do /api/v1/maintenances/{maintenance_id} nie ponownie autoryzują nowo dostarczonego identyfikatora zasobu (asset_id).

Snipe-IT przed wersją 8.6.2 zawiera podatność w punkcie końcowym POST /api/v1/kits/{kit_id}/licenses, która pozwala użytkownikowi z niskimi uprawnieniami na przypisanie licencji do zestawu (kitu) bez odpowiedniej autoryzacji. Brakuje walidacji dostępu do obiektu licencji, co umożliwia nieautoryzowane powiązanie licencji z zestawem.

Snipe-IT przed wersją 8.6.0 zawiera podatność w punkcie końcowym POST /account/request/{itemType}/{itemId}/{cancel_by_admin?}/{requestingUser?}, gdzie parametr cancel_by_admin jest akceptowany bez odpowiedniej autoryzacji. Uwierzytelniony użytkownik może podać identyfikator ofiary i po cichu anulować jej oczekujące żądania zasobów.

W Snipe-IT przed wersją 8.5.0 w metodzie displaySig kontrolera ActionlogController brakuje sanityzacji parametru filename, co pozwala uwierzytelnionemu atakującemu na wyjście poza zamierzony katalog i odczyt dowolnych plików dostępnych dla procesu serwera WWW.

W Snipe-IT przed wersją 8.6.2, przy włączonej pełnej obsłudze wielu firm (Full Multiple Companies Support) i opcji scope_locations_fmcs, endpoint API do tworzenia lokalizacji wykrywa niezgodność firm między lokalizacją nadrzędną a podrzędną, ale nie przerywa operacji, umożliwiając utworzenie lokalizacji podrzędnej w innej firmie niż nadrzędna.

Snipe-IT przed wersją 8.6.2 nie oczyszczał URI javascript: w hiperłączach Markdown, co pozwalało użytkownikowi z uprawnieniem assets.edit na umieszczenie złośliwego linku w polu niestandardowym typu textarea. Gdy inny użytkownik otworzy stronę szczegółów zasobu i kliknie link, wykona się dowolny kod JavaScript.

W Snipe-IT przed wersją 8.6.2 uwierzytelniony użytkownik niebędący administratorem, posiadający uprawnienia users.view i users.edit (ale bez users.delete), może wysłać bezpośrednie żądanie POST do /users/bulksave z parametrem delete_user=1. Powoduje to miękkie usunięcie innego nieadministracyjnego użytkownika, ponieważ kontroler BulkUsersController::destroy() autoryzuje jedynie operację aktualizacji.

W Snipe-IT przed wersją 8.6.2, w API akcesoriów podczas tworzenia rekordu dochodzi do masowego przypisania parametrów żądania do modelu Accessory, w tym pola company_id. Umożliwia to niskouprzywilejowanemu, uwierzytelnionemu użytkownikowi z jednej firmy tworzenie rekordów akcesoriów w innej firmie, gdy włączona jest opcja Pełne Wsparcie Wielu Firm.

W systemie Snipe-IT przed wersją 8.6.1 brakuje autoryzacji dla punktu końcowego GET /api/v1/{object}/selectlist. Każdy zalogowany użytkownik, niezależnie od uprawnień, może pobrać listę wszystkich kont użytkowników, ujawniając nazwy użytkowników, wyświetlane nazwy, numery pracowników i identyfikatory.

Snipe-IT przed wersją 8.6.1 posiada podatność polegającą na braku autoryzacji przed generowaniem tymczasowego URL-a do obrazów przechowywanych w S3. Uwierzytelniony użytkownik znający nazwę pliku sygnatury może uzyskać 5-minutowy podpisany URL S3, ponieważ kod dla S3 zwraca wynik przed wywołaniem funkcji `authorize()` używanej dla plików lokalnych.

Snipe-IT przed wersją 8.6.0 zawiera podatność, która pozwala niebędącemu administratorem użytkownikowi z uprawnieniem granularnym `users.edit` na zablokowanie wszystkich administratorów poprzez edycję flag `activated` i `ldap_import`. Wersja 8.6.0 zawiera poprawkę.

Snipe-IT przed wersją 8.4.1 zawiera podatność na otwarte przekierowanie (open redirect) poprzez niezweryfikowane nagłówek HTTP Referer przechowywany w zmiennej sesji. Atakujący może przekierować użytkowników do złośliwych witryn.

Snipe-IT to system zarządzania aktywami IT i licencjami. Przed wersją 8.4.1, uwierzytelniony użytkownik z uprawnieniem tylko users.edit może eskalować swoje uprawnienia do administratora, wysyłając żądanie PATCH do /api/v1/users/{id} z permissions[admin]=1. Kontroler API usuwa tylko klucz superuser z tablicy uprawnień, umożliwiając ustawienie admin i wszystkich innych kluczy uprawnień przez każdego użytkownika, który może aktualizować użytkowników. Podatność naprawiona w wersji 8.4.1.

Snipe-IT przed wersją 8.4.1 zawiera podatność na XSS w kolumnie notatek (notes) dla użytkowników z dostępem do widoku komponentów. Brak odpowiedniego escapowania umożliwia wstrzyknięcie skryptów.

Podatność na atak XSS w systemie zarządzania aktywami Snipe-IT w wersjach od 8.3.0 do 8.3.1. Uwierzytelniony atakujący z minimalnymi uprawnieniami może wstrzyknąć dowolny kod JavaScript przez pola "Imię" i "Nazwisko". Kod wykonuje się przy przeglądaniu raportu aktywności lub profilu przez innych użytkowników z odpowiednimi uprawnieniami, o ile profil nie ma ustawionej wyświetlanej nazwy.

W Snipe-IT przed wersją 8.3.4 odkryto podatność na trwały atak XSS w polu "Kraj" w lokalizacjach. Umożliwia ona uwierzytelnionemu użytkownikowi z niskimi uprawnieniami wstrzyknięcie kodu JavaScript, który wykona się w sesji innego użytkownika.

Podatność XSS w Snipe-IT przed wersją 8.3.4 umożliwia niskouprzywilejowanemu, uwierzytelnionemu użytkownikowi wstrzyknięcie JavaScript, który wykonuje się w sesji administratora, co prowadzi do eskalacji uprawnień.