Katalog podatności CVE

Podatność w Cisco Expressway Series wynika z niewystarczających kontroli autoryzacji żądań HTTP podczas provisioningu Mobile and Remote Access (MRA). Nieuwierzytelniony zdalny atakujący może wysłać spreparowane żądanie URL, aby uzyskać dostęp do informacji, do których nie ma uprawnień. Dotyczy to urządzeń Expressway-C i Expressway-E.

Aplikacja Girafit camera (Android i iOS) w wersji 1.9.1 i wcześniejszych oraz urządzenia Girafit camera zawierają podatność zapisanych na stałe danych uwierzytelniających, która pozwala atakującym uzyskać współdzieloną nazwę użytkownika TURN poprzez dekompilację aplikacji lub przechwycenie niezaszyfrowanego ruchu sieciowego podczas rejestracji podglądu na żywo. Atakujący mogą wyodrębnić statyczną nazwę użytkownika TURN i token sesji, które są identyczne we wszystkich instalacjach i niepowiązane z żadnym użytkownikiem ani urządzeniem.

Wiele produktów Cisco jest dotkniętych podatnością w funkcji dekapsulacji tuneli GRE silnika Snort 3 Detection Engine. Nieuwierzytelniony zdalny atakujący może wysłać spreparowany ładunek GRE, powodując nieoczekiwany restart silnika i prowadząc do obejścia zabezpieczeń lub odmowy usługi.

Podatność w silniku dekompresji VBA (Visual Basic for Applications) w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na nieoczekiwany restart silnika detekcji Snort 3, powodując odmowę usługi (DoS). Przyczyną jest nieprawidłowe sprawdzanie zakresów podczas dekompresji danych VBA kontrolowanych przez użytkownika. Wysłanie spreparowanych danych VBA może doprowadzić do przepełnienia stosu i stanu DoS.

Podatność w silniku detekcji Teredo w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów Teredo przez Snort 3. Wysłanie spreparowanego pakietu Teredo do urządzenia docelowego może wywołać nieoczekiwany restart i stan DoS.

Podatność w silniku detekcji GRE (Generic Routing Encapsulation) w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów GRE przez Snort 3. Wysłanie spreparowanego pakietu GRE do urządzenia docelowego może wywołać nieoczekiwany restart i stan DoS.

Podatność w silniku detekcji NetFlow w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów UDP Netflow Protocol przez Snort 3. Wysłanie pojedynczego spreparowanego pakietu Netflow przez ustanowione połączenie może wywołać nieoczekiwany restart i stan DoS.

Podatność w dekoderze SMTP MIME w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3. Przyczyną jest brak sprawdzania błędów podczas parsowania pól MIME w nagłówku SMTP. Wysłanie spreparowanych pakietów SMTP przez ustanowione połączenie może wywołać nieoczekiwany restart i stan odmowy usługi (DoS).

W projekcie oretnom23 file-management-system-php (do wersji 2e3c1ebe60f121e8df4fb3f544f0e9591d9a01e4) funkcja delete_folder w pliku ajax.php (komponent AJAX Handler) nie wymaga uwierzytelnienia przy manipulacji argumentem ID. Podatność można wykorzystać zdalnie, a publiczny exploit jest już dostępny.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 żądania otwarcia zewnętrznych adresów URL protokołów mogły być przypisane do innego dokumentu niż ten, który je zainicjował. Powodowało to, że parametr requestingUrl przekazywany do session.setPermissionRequestHandler wskazywał zaufaną treść dla żądania pochodzącego z niezaufanej treści.

Electron to framework do tworzenia aplikacji desktopowych. W wersjach przed 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 sprawdzanie uprawnień hid i usb wykonywane z iframe powodowało, że setPermissionCheckHandler otrzymywał origin i szczegóły ramki najwyższego poziomu zamiast ramki żądającej. Aplikacja, która delegowała hid lub usb do niezaufanego iframe cross-origin i zezwalała na dostęp do urządzeń na podstawie logiki origin, mogła przyznać tej osadzonej ramce dostęp przeznaczony dla strony najwyższego poziomu.

Biblioteka klienta Slack Morphism w wersjach 1.0.0–2.27.0 ujawnia poprawny HMAC żądania Slack, gdy weryfikacja podpisu się nie powiedzie. Dla nieprawidłowego żądania biblioteka oblicza poprawny podpis dla kontrolowanego przez atakującego znacznika czasu i treści i zapisuje go w SlackEventWrongSignatureError.generated_hash, a domyślny handler błędów Axum loguje tę wartość. Atakujący mogący dotrzeć do endpointu callback i czytać logi może użyć weryfikatora jako oracle HMAC i w ciągu pięciu minut odesłać żądanie z poprawnym podpisem.

W frameworku Electron żądania uprawnień pointerLock z niektórych iframe'ów cross-origin powodowały, że session.setPermissionRequestHandler() otrzymywał requestingUrl i isMainFrame ramki najwyższego poziomu zamiast wartości ramki żądającej. Aplikacja osadzająca niezaufaną zawartość iframe i przyznająca pointer lock na podstawie pochodzenia żądania mogła przyznać uprawnienie w imieniu strony najwyższego poziomu. Problem naprawiono w wersjach 42.11.9, 43.7.6, 44.5.0 i 45.0.0-alpha.13.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.6 strony otwierane w nowym oknie z linków były traktowane jako nawigacje zainicjowane przez aplikację, zamiast zachowania strony zawierającej link jako inicjatora. Powodowało to, że żądanie najwyższego poziomu mogło zostać zaklasyfikowane jako same-site, wysyłając ciasteczka SameSite=Strict i nie ujawniając inicjatora w Sec-Fetch-Site.

W hMailServer 6.0.0 do 6.3.6 akcja usuwania załączników przez antywirusa nie kończy się bezpieczną odmową, co pozwala zdalnemu nieuwierzytelnionemu atakującemu na dostarczenie do skrzynki odbiorcy wiadomości uznanej przez skaner za zainfekowaną w niezmienionej postaci. Gdy skanowanie jest włączone, a akcja ustawiona na usuwanie załączników i dostarczanie tekstu, serwer zachowuje jedną część tekstową i zastępuje załączniki notatką. Wiadomość, której jedyna część nie jest tekstem, nie ma części do wyodrębnienia i jest dostarczana bez zmian.

Podatność w hMailServer (wersje 6.0.0–6.3.6) polega na niewystarczającym zachowaniu oryginalnego nadawcy przy przekazywaniu wiadomości. W wyniku tego zdalny, nieuwierzytelniony atakujący może wysłać wiadomość z adresem From w domenie hostowanej przez serwer, a serwer przekaże ją dalej w taki sposób, że u odbiorców przejdzie ona kontrolę SPF i DMARC dla tej domeny, mimo że oryginalnie nie przeszła DMARC.

W hMailServer w wersji od 6.2.25 do 6.3.6 brakuje autoryzacji w trasie REST metrics, co pozwala uwierzytelnionemu użytkownikowi z uprawnieniami ograniczonymi do nazwanych domen odczytać historię ruchu całego serwera. GET /api/v1/metrics/history zwraca liczniki ruchu z ostatnich 30 dni, które są ogólnoserwerowe i nie zawierają informacji o domenie.

Brak autoryzacji w trasach REST do zarządzania rolami w Progressive Robot hMailServer 6.3.4 do 6.3.6 pozwala zdalnemu uwierzytelnionemu użytkownikowi, którego poświadczenia są ograniczone do nazwanych domen, modyfikować rolę niestandardową posiadaną przez konta w innych domenach oraz tworzyć i usuwać role. Trasy tworzenia, aktualizacji i usuwania roli wymagają uprawnienia manage_roles, które posiada tylko rola serveradmin; jednak klucz API o pełnym zakresie wydany dla nazwanych domen oraz serveradmin przypisany z listą domen są ograniczone do tych domen i posiadają manage_roles. Bramka autoryzacji nie odrzuciła tych tras dla ograniczonych poświadczeń, a trasa nie wskazywała domeny, więc poświadczenie jednego tenanta mogło podnieść lub obniżyć uprawnienia roli niestandardowej przypisanej w innych tenantach.

W hMailServer w wersjach 6.0.0–6.3.6 użyto mniej zaufanego źródła adresu koperty przy pobieraniu z konta zewnętrznego. Umożliwia to zdalnemu nieuwierzytelnionemu atakującemu wysłanie wiadomości w imieniu domeny hostowanej przez serwer z adresem koperty w tej domenie, dzięki czemu przechodzi ona kontrolę SPF i DMARC u odbiorców. Serwer przyjmował adres z nagłówka From jako adres koperty dla wiadomości pobranych przez POP3/IMAP, a przekierowanie takiej wiadomości na zewnątrz zachowywało ten adres, który Sender Rewriting Scheme pozostawiał bez zmian dla domeny hostowanej.

Nieprawidłowa autoryzacja w Sender Rewriting Scheme (SRS) w Progressive Robot hMailServer 6.2.1 do 6.3.6 pozwala zdalnemu atakującemu na przekazywanie poczty przez serwer na zewnętrzne adresy. Gdy SRS jest włączony, serwer przepisuje kopertę nadawcy na podpisany adres SRS w domenie przekazującej i przekazuje odbicie na ten adres z powrotem do oryginalnego nadawcy; jednak każdą wiadomość na prawidłowy adres SRS, niezależnie od nadawcy, traktował jako dostarczenie do lokalnego odbiorcy, więc reguły przekazywania i wymagane uwierzytelnianie SMTP nie były stosowane, a wiadomość była dostarczana na zewnętrzny adres zakodowany w adresie SRS. Każdy posiadający prawidłowy adres SRS serwera mógł przez 21 dni zlecać serwerowi przekazywanie poczty na adres, który koduje.