Podatności WSO2 Identity Server

Podatność XXE w funkcji przepływu XACML w WSO2 Identity Server 5.1.0 przed WSO2-CARBON-PATCH-4.4.0-0231 pozwala zdalnym uwierzytelnionym użytkownikom z dostępem do funkcji XACML na odczyt dowolnych plików, wywołanie odmowy usługi, przeprowadzenie ataków SSRF lub inne nieokreślone skutki poprzez spreparowane żądanie XACML.

W podatności CVE-2016-4311 występuje luka CSRF w funkcji przepływu XACML w WSO2 Identity Server 5.1.0, która pozwala zdalnym atakującym na przejęcie uwierzytelnienia uprzywilejowanych użytkowników dla żądań przetwarzających żądania XACML.

W WSO2 Identity Server z magazynem użytkowników nieczułym na wielkość liter i bazą danych czułą na wielkość liter mogą wystąpić niezgodności w obsłudze wielkości liter nazw użytkowników. Powoduje to, że operacje unieważniania tokenów OAuth nie identyfikują poprawnie nazw z mieszaną wielkością liter, przez co tokeny nie są unieważniane.

Punkt końcowy uwierzytelniania WSO2 Identity Server nie zapewnia spójnej odpowiedzi systemu, gdy nazwa użytkownika nie istnieje, co pozwala atakującemu rozróżnić ważne i nieprawidłowe nazwy użytkowników. Różnica w odpowiedziach może być wykorzystana do wyliczenia istniejących kont użytkowników.

WSO2 Identity Server nie egzekwuje domyślnego czasu wygaśnięcia dla SMS-owych haseł jednorazowych (OTP) używanych w MFA. Nieużywane OTP pozostają ważne bezterminowo, co umożliwia atakującym przeprowadzanie ataków brute force przez wielokrotne zgadywanie kodu. Udany atak może prowadzić do obejścia MFA i przejęcia konta użytkownika.

Interfejs REST API do zarządzania typami sekretów nie izoluje poprawnie kontroli dostępu podczas usuwania typu sekretu. Logika kaskadowego usuwania nie przestrzega granic organizacyjnych, co prowadzi do usunięcia sekretów powiązanych z tym typem we wszystkich organizacjach. Eksploatacja może spowodować niezamierzone usunięcie sekretów w całym wdrożeniu, prowadząc do awarii konfiguracji, przerw w działaniu usług i warunków typu denial-of-service.

Gdy włączone jest logowanie wieloatrybutowe, interfejs logowania nie maskuje konsekwentnie istnienia kont użytkowników. Dla prawidłowych użytkowników serwer wyświetla ich kanoniczną nazwę użytkownika, a dla nieistniejących odsyła oryginalne dane wejściowe. Dzieje się tak niezależnie od konfiguracji validate_username. Ujawnienie prawidłowych nazw użytkowników zwiększa ryzyko ataków brute force, inżynierii społecznej i ukierunkowanego wycieku informacji.

Proces personifikacji użytkownika w WSO2 Identity Server nie zarządza poprawnie tokenami odświeżania związanymi z sesjami personifikowanymi. Pozwala to atakującemu, który uzyskał token dostępu dla personifikowanego użytkownika, wykorzystać grant tokena odświeżania do uzyskania nowych tokenów dostępu, przedłużając możliwość działania jako prawowity użytkownik. Atakujący może w ten sposób kontynuować działania w imieniu rzeczywistego użytkownika, kompromitując integralność logów i utrudniając śledzenie działań.

Nieużywane kody autoryzacyjne wydane usuniętym użytkownikom nie są prawidłowo unieważniane ani usuwane z systemu, co pozwala na ich potencjalne ponowne użycie. Jeśli atakujący posiada zarówno kod autoryzacyjny, jak i powiązane dane klienta (ID i sekret), może uzyskać tokeny dostępu w imieniu usuniętych użytkowników, co prowadzi do nieautoryzowanego dostępu do zasobów.

Mechanizm blokady konta nie uruchamia się, gdy dodatkowe magazyny użytkowników są niedostępne. Oprogramowanie nie utrzymuje spójnego stanu blokady, jeśli nie może osiągnąć wszystkich skonfigurowanych magazynów, co pozwala atakującemu na wielokrotne próby uwierzytelnienia z nieprawidłowymi danymi bez wyzwalania blokady.

Proces samodzielnej rejestracji użytkownika w wielu produktach WSO2 nie waliduje odpowiednio danych wejściowych, co pozwala na umieszczenie niezweryfikowanych danych w atrybutach użytkownika (claims). Te dane są następnie używane przez procesy downstream, co może prowadzić do różnych ataków.

Podatność w WSO2 Identity Server wynika z braku walidacji kontekstu organizacji podczas wykonywania adaptacyjnych przepływów uwierzytelniania. Złośliwy aktor z uprawnieniami do konfiguracji adaptacyjnego uwierzytelniania w jednej organizacji może wykorzystać tę funkcję do wykonania logiki uwierzytelniania w innych organizacjach i podorganizacjach, omijając granice autoryzacji.

W WSO2 Identity Server aktywne tokeny dostępu nie są unieważniane ani odwoływane po zablokowaniu konta użytkownika. Pozwala to na dalsze korzystanie z wcześniej wydanych, ważnych tokenów, co umożliwia zablokowanym kontom dostęp do chronionych zasobów.

Podatność na odbity XSS w procesie rejestracji konta w WSO2 Identity Server z powodu nieprawidłowego kodowania wyjścia. Atakujący może wstrzyknąć spreparowany payload, który jest odbijany w odpowiedzi serwera, umożliwiając wykonanie dowolnego JavaScript w przeglądarce ofiary.