Katalog podatności CVE

Rozszerzenie Joomla J2Store w wersjach 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7 używa przewidywalnego/możliwego do podrobienia tokenu dostępu do zamówienia. Każdy, kto zna sekret Joomla, może obliczyć ważny token dostępu dla dowolnego zamówienia bez jego składania, uzyskując dostęp gościa do szczegółów zamówienia i cyfrowych pobrań.

W rozszerzeniu Joomla J2Store każdy może oznaczyć dowolne zamówienie jako nieudane (Failed) bez uwierzytelnienia. Atakujący może masowo oznaczać oczekujące zamówienia jako nieudane, zakłócając przychody i wymuszając ręczne przetwarzanie, lub przywracać zrealizowane zamówienia do stanu FAILED, powodując zamieszanie operacyjne. W przeciwieństwie do wcześniejszego problemu z oszustwem potwierdzeń, nie jest wymagana żadna poprawna kwota płatności ani dane transakcji.

Concrete CMS przed wersją 9.5.3 jest podatny na Cross-Site Request Forgery (CSRF) w funkcji aktywacji szablonów stron motywu. Akcja activate_files() w kontrolerze Dashboard theme Inspect tworzyła rekordy PageTemplate z wartości pageTemplates[] dostarczonych przez atakującego bez walidacji tokena anty-CSRF. Zdalny atakujący mógł umieścić stronę, która automatycznie wysyłała sfałszowane żądanie POST; gdy zalogowany administrator ją odwiedził, żądanie wykonywało się w sesji administratora, zmieniając konfigurację witryny bez jego zgody.

W Concrete CMS przed wersją 9.5.3 edytor masowej aktualizacji meta tagów SEO nie sprawdzał uprawnień do edycji poszczególnych stron przed zapisem. Akcja saveRecord() walidowała token CSRF per-strona, ale nie wywoływała canEditPageProperties() dla docelowej strony, więc użytkownik z dostępem do narzędzia SEO i możliwością podglądu (ale nie edycji) strony mógł zmienić jej meta tytuł, meta opis i URL handle, naruszając prezentację i żywe adresy URL chronionych treści.

Concrete CMS przed wersją 9.5.3 nie egzekwował autoryzacji per-strona podczas zmiany kolejności stron z mapy witryny. W kontrolerze sitemap Explore, zadania send_to_top i send_to_bottom wykonywane były po tylko ogólnym sprawdzeniu dostępu do mapy; kontroler ładował stronę wskazaną przez parametr cNodeID i zmieniał jej kolejność bez weryfikacji uprawnień do przenoszenia lub układania na tej konkretnej stronie. Uwierzytelniony użytkownik z dostępem do mapy, ale bez uprawnień do edycji lub układania, mógł przenieść stronę i zmienić globalną kolejność nawigacji.

Concrete CMS 8.5.3 do 9.5.2 umożliwiał grant odświeżania tokena OAuth 2.0 przy użyciu niezmodyfikowanego grantu League, który wydawał nowe tokeny dostępu z ważnego tokena odświeżania bez ponownego sprawdzania statusu aktywnego konta. Użytkownik, który uzyskał token odświeżania, gdy był aktywny, mógł kontynuować generowanie ważnych tokenów dostępu po dezaktywacji lub zawieszeniu (uIsActive=0), więc dezaktywacja konta nie odwoływała jego dostępu API.

Concrete CMS w wersjach poniżej 9.5.3 zawiera podatność Cross-Site Request Forgery w akcji reset() na stronie SEO Excluded Words w panelu administracyjnym. Akcja czyściła listę zastrzeżonych słów skonfigurowaną przez administratora, nie weryfikując tokenu anty-CSRF ani nie ograniczając żądania do metody POST. Atakujący mógł nakłonić uwierzytelnionego użytkownika z dostępem do SEO do odwiedzenia spreparowanej strony, co przywracało domyślną listę słów i po cichu zmieniało przyszłe generowanie slugów URL.

Concrete CMS w wersjach poniżej 9.5.3 nie weryfikuje tokenu anty-CSRF na endpointcie backendowym służącym do aranżacji bloków (akcja arrange() w Concrete\Controller\Backend\Page\ArrangeBlocks). Akcja wymuszała uprawnienia do edycji strony, ale nie sprawdzała tokenu, a jej trasa akceptowała dowolną metodę HTTP. Atakujący mógł nakłonić zalogowanego edytora treści do załadowania spreparowanej strony, która automatycznie wysyłała żądanie cross-site i zmieniała kolejność lub przenosiła bloki w wersji roboczej strony.

W rozszerzeniu Joomla J2Store metoda J2StoreModelOrderdownloads::getFilePath() budowała ścieżkę do zakupionego pliku cyfrowego, łącząc skonfigurowany folder załączników z zapisaną nazwą pliku produktu (product_file_save_name), używając jedynie JPath::clean() (które normalizuje separatory, ale nie rozwiązuje ani nie odrzuca segmentów ..) i zwykłego sprawdzenia JFile::exists(). Jeśli nazwa pliku zawierała segment przejścia ../, klient posiadający ważny token/pid mógł pobrać dowolny plik czytelny dla serwera WWW (np. configuration.php).

Rozszerzenie Joomla J2Store (wersje 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7) zawiera nieuwierzytelnioną podatność na ślepą iniekcję SQL w liście produktów sklepu. Atakujący może zdalnie wyodrębnić dowolne dane z bazy, takie jak rekordy klientów, zamówienia czy przechowywane tokeny, wykorzystując wnioskowanie boolean lub czasowe.

Nieprawidłowe przypisanie uprawnień w komponencie zarządzania użytkownikami w Webkul Bagisto 2.4.9 pozwala uwierzytelnionemu użytkownikowi backendu posiadającemu tylko uprawnienie settings.users.edit na eskalację do pełnego administratora. Endpoint aktualizacji użytkownika nie weryfikuje, czy aktor może przyznać żądaną rolę, nie zapobiega zmianie własnej roli i nie ogranicza przypisywania do ról, których zestaw uprawnień jest podzbiorem uprawnień aktora.

W Webkul Bagisto v2.4.9 nieprawidłowa walidacja parametru ilości w ścieżce dodawania do koszyka pozwala uwierzytelnionym atakującym obniżyć całkowitą wartość zamówienia poniżej legalnej ceny towarów podlegających wysyłce.

Problem w Webkul Bagisto 2.4.9 pozwala zdalnemu atakującemu uzyskać poufne informacje poprzez API add-to-cart oraz komponenty realizacji pobierania.

Rozszerzenie Joomla J2Store (wersje 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7) brakuje ochrony CSRF w kontrolerach koszyka, płatności i profilu. Sfałszowane żądanie wykorzystujące aktywną sesję ofiary może po cichu zmienić adres rozliczeniowy lub dostawy przed potwierdzeniem zamówienia, co może przekierować towary na adres atakującego.

W systemie Arista EOS, w pewnych okolicznościach, hasła współdzielone (shared secrets) dla skonfigurowanych serwerów TACACS+ mogą być przechowywane lub ujawniane w postaci jawnej. Problem dotyczy platform z tym systemem.

W systemie Arista EOS, w pewnych okolicznościach, hasła użytkowników mogą być zapisywane w postaci jawnej w plikach logów, gdy specjalistyczne, niestandardowe poziomy śledzenia debugowania są wyraźnie włączone. Wykorzystanie wymaga już posiadania uwierzytelnionego lokalnego dostępu administracyjnego do powłoki urządzenia.

W systemie Arista EOS, w pewnych okolicznościach, prywatne klucze mogą być zapisywane w postaci jawnej w plikach logów, gdy specjalistyczne, niestandardowe poziomy śledzenia debugowania są wyraźnie włączone. Wykorzystanie wymaga już posiadania uwierzytelnionego lokalnego dostępu administracyjnego do powłoki urządzenia.

W systemie Arista EOS na platformach z podwójnymi kartami przełącznika i skonfigurowanymi przychodzącymi listami ACL Security na przełączanych interfejsach wirtualnych (SVI) w trybie współdzielonym, restart agenta przekazywania pomocniczej karty przełącznika lub włożenie pomocniczej karty przełącznika może spowodować, że listy ACL Security na współdzielonych SVI przestaną działać. Może to skutkować nieprawidłowym zachowaniem zezwalania/odrzucania pakietów.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 dekoder fragmentów (chunk decoder) w Ember przycina token rozmiaru fragmentu i akceptuje wiodące znaki plus lub minus zamiast wymagać co najmniej jednej cyfry szesnastkowej zakończonej wymaganym CRLF. Gdy pośrednik przekazuje dane fragmentaryczne bez ponownego kodowania i interpretuje nieprawidłowe granice fragmentów inaczej, nieuwierzytelniony atakujący może przeprowadzić przemyt żądań TE.TE, omijając kontrolę pośrednika, zatruwając pamięci podręczne lub przejmując kolejkę żądań.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 oprogramowanie pośredniczące klienta CookieJar przechowuje atrybut Domain pliku cookie odpowiedzi bez sprawdzenia, czy pasuje on do hosta, który dostarczył plik cookie, ani bez odrzucania sufiksów publicznych. Złośliwy lub przejęty serwer kontaktowany przez ten sam CookieJar może zasadzić plik cookie dla innej domeny, a następnie jar wysyła ten plik cookie do domeny ofiary, umożliwiając utrwalenie sesji lub nadpisanie wrażliwych plików cookie.