Niezałatana luka w Spring pozwala na zdalne wykonanie kodu

Wśród Developerów Javy niezmienną popularnością cieszy się framework Spring. Jak dowodzą kolejne odsłony Badania Społeczności IT dominacja Springa jest niezaprzeczalna. Z tegorocznej odsłony dowiedzieliśmy się, że, korzysta z niego aż 74% wszystkich programistów pracujących z Javą. Dla nich, jak i dla końcowych użytkowników, mamy złe wieści – w Springu odnaleziono lukę 0-day, która – choć jeszcze niesklasyfikowana – ma zadatki na status krytycznej.

Spring4Shell

Luka otrzymała sygnaturę CVE-2010-1622, lecz przylgnęła już do niej nazwa Spring4Shell, co ma być oczywiście nawiązaniem do podatności Log4j/Log4Shell, o której więcej pisaliśmy tutaj. Poza nazwą na próżno szukać tu jednak innych analogii: porównanie zarówno samych wektorów ataku, jak i exploitów, wskazuje, że Spring4Shell to zupełnie inna para kaloszy.

Nie oznacza to jednak, że luka w Spring jest niegroźna. Wręcz przeciwnie. Pozwala bowiem na zdalne wykonanie kodu i przejęcie aplikacji. Co gorsza, podatność to „prawdziwa” luka dnia zerowego. Dostępny jest już proof-of-concept, a nie pojawiła się jak dotąd aktualizacja Springa, która mogła stanowić rozwiązanie problemu. 

Aby zdać sobie sprawę z powagi sytuacji, podsumujmy – Spring to najpopularniejszy javowy framework, luka jest jawna, dostępne są PoC na jej wykorzystanie, łatki ani widu, ani słychu. Niewiele stoi więc na przeszkodzie, by atakujący mogli wykorzystywać Spring4Shell już teraz „w dziczy”, czyli przeciw działającym właśnie w Sieci aplikacjom webowym przygotowanym w Springu, z których korzystają trudna do oszacowania liczba użytkowników.

Spring4Shell – jak przebiega atak?

Według danych dostarczonych przez firmę Preatorian, do powodzenia ataku wystarczy wysłać odpowiednio spreparowane żądanie HTTP do kontrolera formularzy, jednak pod warunkiem, że endpoint ma włączony DataBinder, np. żądanie POST, które automatycznie dekoduje dane z żądania typu body. 

Problem tkwi w tym, że Spring Beans wykorzystywana jest klasa CachedIntrospectionResults, która numeruje właściwości dostępne do ustawienia w formularzu przesłanym przez użytkownika, wykorzystuje java.beans.Introspector.getBeanInfo() bez określenia klasy Stop. To zaś sprawia, że dla specyficznej klasy właściwości są dostępne do ustawienia przez żądanie HTTP. Wystarczy odpowiednio spreparować request, by nadpisać zerowy element tablicy własnym URL-em. O szczegółach exploita przeczytać można tutaj.

Jak się zabezpieczyć?

Jak już wspomniano w momencie przygotowywania artykułu, wciąż nie jest dostępna aktualizacja bezpieczeństwa dla Springa. Wiemy natomiast, że podatne są wszystkie aplikacje, które wykorzystują JDK w wersji 9 i nowszych. Specjaliści z Praetorian przygotowali tymczasowe rozwiązanie, jednak nieznana jest jego skuteczność, zwłaszcza że w perspektywie mamy kolejne wariacje Spring4Shell. Szczegóły dostępne są tutaj.