org.owasp:dependency-check-maven. Narzędzie to pomaga wychwycić znane podatności, które dotyczą naszej aplikacji tylko dlatego, że korzystamy z konkretnej wersji zależności (biblioteki, frameworka), która zawiera błąd bezpieczeństwa. Błędy te zaliczają się do kategorii A06 (przed 09.2021 - A09) z listy OWASP TOP 10 (https://owasp.org/www-project-top-ten/). Swoją drogą polecam każdemu przeskanowanie swoich projektów takim skanerem aby zobaczyć jak wiele niebezpieczeńsw pociąga za sobą beztroskie korzystanie z mnóstwa bibliotek. Względne bezpieczeństwo daje nam tylko przypadek spowodowany tym, że akurat nie korzystamy z jakiejś konkretnej funkcjonalności. Tak będzie i w moim przypadku :).
CVE-2021-22119
Dokładny opis błędu można znaleźć m.in. tu https://nvd.nist.gov/vuln/detail/CVE-2021-22119.Dlaczego skupiłem się na tym zgłoszeniu? Bo w pewnym momencie pojawiło się jako nowa, świeża podatność w projekcie, który pod tym względem monitorowałem. Postanowiłem przyjrzeć się problemowi głębiej w celu upewnienia się, że projekt jest niezagrożony.
Jakiej zależności dotyczy problem? Spring Security w wersjach 5.5.x (<5.5.1), 5.4.x (<5.4.7), 5.3.x (<5.3.10) i 5.2.x (<5.2.11). Wersje te są podatne na atak DoS (Denial of Service). Może on wystąpić w przypadku gdy korzystamy z uwierzytelniania z użyciem protokołu OAuth 2.0, koniecznie w trybie Authorization Code. Czyli częsty sposób wykorzystania gdy chcemy pozwolić zalogować się użytkownikowi do naszego serwisu korzystając jednej z popularnych platform (jak Facebook, Github, Google, itd..). Możliwe jest całkowite wykorzystanie dostępmych zasobów aplikacji i w efekcie doprowadzenie do jej zatrzymania.
Zasadę działania OAuth 2.0 w trybie Authorization Code najlepiej przypomnieć za pomocą diagramu sekwencji:
Pierwszym krokiem w sekwencji pozyskania dostępu do zasobu chronionego jest wysłanie żądania Authorization Request, które na diagramie zaznaczono przez pogrubienie. Efektem tego żądania jest przekierowanie użytkownika na stronę pozwolającą nadać dostęp do zasobu. To właśnie to żądanie nas interesuje. Okazuje się, że implementacja Spring Security we wskazanych wyżej wersjach pozwala generować mnóstwo kolejnych żądań w ramach jednej sesji HTTP, zapisując je w pamięci aplikacji. Będą one trwały w pamięci dopóki cały proces autoryzacji nie zostanie ukończony. A wcale nie trzeba go przecież ukończyć.
Poprawka jaka powstała polega na zmianie domyślnego zachowania, które domyślnie nie pozwala generować wielu żądań w ramach jednej sesji, a zamiast tego zastępuje każde poprzednie żądanie kolejnym. Kod odpowiedzialny za całę to zachowanie można dojrzeć w następującej metodzie: org.springframework.security.oauth2.client.web.HttpSessionOAuth2AuthorizationRequestRepository#saveAuthorizationRequest.
public void saveAuthorizationRequest(OAuth2AuthorizationRequest authorizationRequest, HttpServletRequest request, HttpServletResponse response) {
Assert.notNull(request, "request cannot be null");
Assert.notNull(response, "response cannot be null");
if (authorizationRequest == null) {
this.removeAuthorizationRequest(request, response);
} else {
String state = authorizationRequest.getState();
Assert.hasText(state, "authorizationRequest.state cannot be empty");
Map<String, OAuth2AuthorizationRequest> authorizationRequests = this.getAuthorizationRequests(request);
authorizationRequests.put(state, authorizationRequest);
request.getSession().setAttribute(this.sessionAttributeName, authorizationRequests);
}
}
public void saveAuthorizationRequest(OAuth2AuthorizationRequest authorizationRequest, HttpServletRequest request, HttpServletResponse response) {
Assert.notNull(request, "request cannot be null");
Assert.notNull(response, "response cannot be null");
if (authorizationRequest == null) {
this.removeAuthorizationRequest(request, response);
} else {
String state = authorizationRequest.getState();
Assert.hasText(state, "authorizationRequest.state cannot be empty");
if (this.allowMultipleAuthorizationRequests) {
Map<String, OAuth2AuthorizationRequest> authorizationRequests = this.getAuthorizationRequests(request);
authorizationRequests.put(state, authorizationRequest);
request.getSession().setAttribute(this.sessionAttributeName, authorizationRequests);
} else {
request.getSession().setAttribute(this.sessionAttributeName, authorizationRequest);
}
}
}
Exploit
Żeby nikt nie musiał mi wierzyć na słowo, że problem istniał przygotowałem testową aplikację oraz kod, który wykorzystuje podatność. Całość udostępniłem na Githubie pod tym linkiem: https://github.com/mari6274/oauth-client-exploit.
W repozytorium znajdują sie 2 aplikacje. oauth-client to aplikacja Spring Boot, która udostępnia endpoint do uwierzytelniania się za pomocą OAuth 2.0. Ja test wykonywałem wykorzystując integrację z Github. W tym celu, do uruchomienia aplikacji konieczne jest dodanie 2 propertiesów:
spring.security.oauth2.client.registration.github.clientId: <tu twój clientId>
spring.security.oauth2.client.registration.github.clientSecret: <tu twój clientSecret>
Jak można łatwo zauważyć (np w zakładce network swojej przeglądarki), wykonanie żądania na udostępniony endpoint /user generuje serię przekierowań. Nas będzie interesować żądanie GET http://localhost:8080/oauth2/authorization/github. I ten adres jest właśnie celem ataku drugiej aplikacji exploit. Prosty kod java, który za pomocą klienta Apache HttpClient wykonuje w pętli tysiące żądań http. Dodatkowo podzielone jest to na kilka wątków. Każdy z nich tworzy własnego klienta, który korzysta z własnego połączenia (i sesji) http.
W celach łatwiejszego unaocznienia problemu aplikację oauth-client uruchomiłem z ograniczonym zasobem pamięci: -Xmx256m. Poniżej screeny z wyników testu wersji Spring Security 5.4.1:
Widać, że w wersji zawierającej błąd aplikacja w ciągu zaledwie jednej minuty została wysycona z zasobów pamięci, zaczęła generować błedy java.lang.OutOfMemoryError i zatrzymała się. Wykresy zużycia zasobów dla aplikacji korzystającej z wersji zależności bez błędu wskazuja natomiast na jej stabilne zachowanie - zarówno pod kątem użycia pamięci jak i CPU.
Komentarze
Prześlij komentarz