Podatności Boruta

Biblioteka Boruta w języku Elixir zawiera lukę w mechanizmie izolacji, która pozwala nieuwierzytelnionemu atakującemu na rejestrację klientów OpenID Connect z uprawnieniami administracyjnymi. Brak listy dozwolonych pól powoduje, że atakujący może ustawić wrażliwe atrybuty, takie jak typy grantów, zakresy, wymuszanie PKCE czy czasy życia tokenów.

Podatność SSRF (Server-Side Request Forgery) w bibliotece Boruta (wersje od 2.3.2 do 2.3.7) pozwala nieuwierzytelnionemu atakującemu na zmuszenie serwera autoryzacyjnego OAuth/OpenID do wysyłania żądań HTTP do dowolnych URI, w tym do usług wewnętrznych i endpointów metadanych chmury. Podatność występuje w trzech ścieżkach kodu, które nie walidują odpowiednio docelowych URI.

Podatność na obejście uwierzytelniania przez przechwytywanie i odtwarzanie w bibliotece Boruta firmy malach-it umożliwia atakującemu, który uzyskał wcześniej ważne asercje JWT klienta, uwierzytelnienie jako klient OAuth po wygaśnięciu asercji. Boruta nie wymusza sprawdzania pola exp w asercjach JWT, co pozwala na ich wielokrotne użycie.

Boruta, samodzielny serwer autoryzacyjny implementujący OAuth 2.0 i OpenID Connect, przed wersją 0.10.0 logował wrażliwe wartości w dziennikach zdarzeń biznesowych. Mogły to być tokeny dostępu, odświeżania, autoryzacyjne, agenta, kody direct-post, tokeny ID, VP oraz tokeny przesyłane do punktów introspection lub revocation. Osoba z dostępem do logów mogła odzyskać te poświadczenia i używać ich do wygaśnięcia lub unieważnienia.

Boruta przed wersją 0.10.0 w kontrolerze UserSettingsController.update/2 atomizuje każdy klucz z ciała żądania przez String.to_atom/1 przed walidacją. Ponieważ String.to_atom trwale internuje atomy w tablicy atomów BEAM (domyślnie 1 048 576 atomów), każdy uwierzytelniony użytkownik może wysłać PUT /users/settings z nowymi kluczami, wyczerpując globalną tablicę atomów. Gdy tablica jest pełna, BEAM przerywa działanie, powodując awarię całego serwera OIDC. Problem naprawiono w wersji 0.10.0.