Podatności WSO2

W produktach WSO2 mechanizm odświeżania tokenów (refresh token grant type) nie weryfikuje ponownie statusu konta przed wydaniem nowego tokenu dostępu. Pozwala to atakującemu uzyskać ważne tokeny dostępu dla kont użytkowników nawet po ich zablokowaniu w user store, omijając mechanizmy blokady konta.

Konsola zarządzania nieprawidłowo waliduje dane wejściowe związane z konfiguracją magazynów użytkowników JDBC. Słabość ta pozwala atakującemu dostarczyć specjalnie spreparowane dane wejściowe, które mogą prowadzić do wykonania dowolnego kodu na dotkniętym serwerze. Skuteczne wykorzystanie umożliwia atakującemu wykonanie dowolnego kodu z uprawnieniami produktu WSO2, co może doprowadzić do pełnego przejęcia systemu.

Brak wymuszenia uwierzytelniania w implementacji wzajemnego TLS (mTLS) używanej przez System REST APIs i usługi SOAP w wielu produktach WSO2. Z powodu nieprawidłowej walidacji uwierzytelniania opartego na certyfikatach klienta w niektórych domyślnych konfiguracjach, zaatakowane komponenty mogą zezwalać na nieuwierzytelnione żądania nawet przy włączonym mTLS. Udane wykorzystanie pozwala atakującemu z dostępem sieciowym do zaatakowanych punktów końcowych uzyskać uprawnienia administracyjne i wykonywać nieautoryzowane operacje.

Z powodu nieprawidłowej implementacji reguł kontroli dostępu produkt WSO2 przyjmuje dane wejściowe użytkownika dotyczące lokalizacji zasobu bez wymaganych ograniczeń walidacji. Nieuwierzytelniony atakujący może zmusić serwer do wykonywania żądań do dowolnych lokalizacji sieciowych, uzyskując dostęp do zasobów wewnętrznych i zewnętrznych.

Produkt WSO2 skonfigurowany do korzystania z zewnętrznego magazynu użytkowników nie odpowiednio ukrywa istnienia lub ważności nazw użytkowników podczas prób uwierzytelniania. To pozwala atakującemu na wielokrotne odpytywanie mechanizmu uwierzytelniania z różnymi zgadywanymi nazwami użytkowników, umożliwiając enumerację ważnych nazw użytkowników w zewnętrznym magazynie.

W produktach WSO2, po usunięciu ról wewnętrznych użytkownika, system nie unieważnia wcześniej wydanych tokenów uwierzytelniających. Użytkownik może zachować dotychczasowe uprawnienia nawet po ich odebraniu.

Class Mediator w produktach WSO2 nie waliduje ani nie sanityzuje właściwości messageContext używanych do dynamicznych wartości. Uwierzytelnieni użytkownicy mogą uzyskać dostęp do danych innych użytkowników lub modyfikować dane systemowe.

Gdy adapter wyjściowy Event Publisher jest skonfigurowany z nieistotnymi właściwościami, produkty logują te właściwości bez odpowiedniej walidacji lub sanityzacji wartości. Osoba z dostępem do plików logów 'wso2carbon' może uzyskać wrażliwe informacje, takie jak dane uwierzytelniające, co może prowadzić do nieautoryzowanego dostępu.

System akceptuje żądania uwierzytelniania bez wystarczającej walidacji, aby wymusić izolację dzierżawców (tenant isolation) przy użyciu Email OTP, SMS OTP lub Magic Link jako pierwszego czynnika. Może to prowadzić do ujawnienia danych osobowych użytkowników w różnych dzierżawcach.

Gdy skonfigurowane są dodatkowe magazyny użytkowników, resolver niejawnych skojarzeń nieprawidłowo inicjalizuje z dodatkowego magazynu i pomija główny magazyn podczas wyszukiwania i sprawdzania unikalności. Może to prowadzić do skojarzenia podmiotu z niezamierzonym kontem lokalnym, jeśli ten sam atrybut (np. nazwa użytkownika) istnieje w obu magazynach.

Mechanizm obsługi zdarzeń throttlingu w wielu produktach WSO2 akceptuje dostarczane przez użytkownika ładunki JSON bez wystarczającej walidacji ich struktury i zawartości. Pozwala to nieuwierzytelnionemu zdalnemu atakującemu na wstrzyknięcie złośliwych danych JSON, co może prowadzić do trwałej odmowy usługi.

W wielu produktach WSO2 występuje luka typu reflected cross-site scripting (XSS) w punktach końcowych uwierzytelniania z powodu braku kodowania danych wyjściowych. Złośliwy aktor może wstrzyknąć dowolne ładunki JavaScript do punktu końcowego uwierzytelniania, które są odzwierciedlane w odpowiedzi, umożliwiając ataki oparte na przeglądarce. Wykorzystanie może skutkować przekierowaniem na złośliwe witryny, manipulacją interfejsem lub nieautoryzowanym dostępem do danych z przeglądarki ofiary; jednak pliki cookie sesji są chronione flagą httpOnly, co ogranicza przejęcie sesji tą drogą.

W wielu produktach WSO2 występuje podatność polegająca na dowolnym przesyłaniu plików z powodu niewłaściwej walidacji nazw plików dostarczanych przez użytkownika w endpointcie usługi SOAP BPEL uploader. Złośliwy aktor z uprawnieniami administracyjnymi może przesłać dowolne pliki do lokalizacji kontrolowanej przez użytkownika na serwerze.

W wielu produktach WSO2 z włączonym Multi-Attribute Login występuje podatność umożliwiająca enumerację nazw użytkowników. System zwraca odrębny komunikat błędu "User does not exist" niezależnie od ustawienia validate_username, co pozwala atakującemu rozpoznać istniejące konta. Może to ułatwić ataki brute-force, phishing i inżynierię społeczną.

W wielu produktach WSO2 z włączonym uwierzytelnianiem FIDO występuje obejście uwierzytelniania. Po usunięciu konta użytkownika system nie usuwa powiązanych danych rejestracji FIDO, więc nowe konto o tej samej nazwie może zostać powiązane z wcześniej zarejestrowanym urządzeniem FIDO. Może to pozwolić usuniętemu użytkownikowi na podszycie się pod nowe konto.

Uwierzytelniona podatność przechowywanego cross-site scripting (XSS) występuje w wielu produktach WSO2 z powodu niewłaściwej walidacji danych wejściowych podczas przesyłania dokumentów API w portalu Publisher. Użytkownik z uprawnieniami wydawcy może przesłać spreparowany dokument API zawierający złośliwy JavaScript, który jest później renderowany w przeglądarce podczas dostępu innych użytkowników. Udany atak może skutkować przekierowaniem na złośliwe strony, nieautoryzowanymi modyfikacjami interfejsu lub eksfiltracją danych dostępnych w przeglądarce. Jednak wrażliwe pliki cookie związane z sesją są chronione flagą httpOnly, co zapobiega przejęciu sesji.

W wielu produktach WSO2 występuje podatność na odbite skryptowanie krzyżowe (reflected XSS) z powodu niewystarczającego kodowania danych wyjściowych w komunikatach błędów generowanych przez żądanie walidacji połączenia z magazynem użytkowników JDBC. Złośliwy aktor może wstrzyknąć specjalnie spreparowany ładunek do żądania, powodując wykonanie dowolnego kodu JavaScript przez przeglądarkę w kontekście podatnej strony. Może to umożliwić manipulację interfejsem, przekierowanie do złośliwych witryn lub eksfiltrację danych z przeglądarki, jednak ponieważ wszystkie wrażliwe pliki cookie sesji są chronione flagą httpOnly, przejęcie sesji nie jest możliwe.