I Spring Core-modulet, som leveres med Spring Framework, er der blevet opdaget en kritisk 0-dags sårbarhed, der giver en uautoriseret fjernangriber mulighed for at eksekvere sin kode på serveren. Det er endnu uvist, hvor katastrofale konsekvenser den opdagede problemstilling kan have, og om angrebene vil være så omfattende som i tilfælde af sårbarheden i Log4j 2. Sårbarheden er blevet tildelt kodeordet Spring4Shell, men der er endnu ikke tildelt et CVE-id. I Spring Framework forbliver problemet ubehandlet, og der findes allerede flere fungerende prototyper af exploits (1, 2, 3, 4) på internettet. Problemet forværres af, at mange erhvervslivets Java-applikationer baseret på Spring Framework kører med root-rettigheder, og sårbarheden muliggør en fuldstændig kompromittering af systemet.
Ifølge nogle estimater bruges Spring Core-modulet i 74% af Java-applikationerne. Faregraden ved sårbarheden mindske af, at kun applikationer, der bruger annoteringen «@RequestMapping» til at tilslutte anmodningsbehandlere og binde webformularens parametre i formatet «name=value» (POJO, Plain Old Java Object), er udsatte, i stedet for at anvende JSON/XML.
Hvilke specifikke Java-applikationer og rammeværk der er ramt af problemet er stadig uklart. Sårbarheden forhindrer tilføjelsen til blacklistede felter «class», «module» og «classLoader» eller brugen af en eksplicit hvid liste over tilladte felter. Udnyttelse af sårbarheden er kun mulig ved brug af Java/JDK 9 eller nyere versioner. Problemet stammer fra muligheden for at omgå beskyttelsen mod sårbarheden CVE-2010-1622, der blev rettet i Spring Framework tilbage i 2010 og er relateret til eksekvering af classLoader-handleren ved fortolkning af anmodningsparametre.
Eksploitens funktion indebærer at sende en forespørgsel med parametrene „class.module.classLoader.resources.context.parent.pipeline.first.*“, hvis behandling fører til oprettelsen af en jsp-fil i rodmiljøet Apache Tomcat og skrive den pågældende kode angivet af angriberen i denne fil. Den oprettede fil bliver tilgængelig for direkte anmodninger og kan bruges som en web shell. For at angribe en sårbar applikation i Apache Tomcat-miljøet er det tilstrækkeligt at sende en forespørgsel med bestemte parametre ved hjælp af curl-værktøjet. curl -v -d „class.module.classLoader.resources.context.parent.pipeline.first.pattern=kode_til_at_indsætte_i_filen &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
Det omhandlede problem i Spring Core bør ikke forveksles med de nyligt opdagede sårbarheder CVE-2022-22963 og CVE-2022-22950. Det første problem berører Spring Cloud-pakken og er blevet rettet i versionerne 3.1.7 og 3.2.3. Det andet problem findes i Spring Expression og er rettet i Spring Framework 5.3.17. Dette er principielt forskellige sårbarheder. Om den nye sårbarhed har udviklerne af Spring Framework endnu ikke afgivet nogen udtalelser eller offentliggjort nogen rettelse.
Som en midlertidig foranstaltning til beskyttelse anbefales det at bruge en sortliste af uacceptable forespørgselsparametre i koden: 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); } }
Kilde: opennet.ru
