În modulul Spring Core, livrat în cadrul framework-ului Spring Framework, a fost identificată o vulnerabilitate critică 0-day, care permite unui atacator remote neautentificat să execute codul său pe server. Este încă neclar cât de devastatoare pot fi consecințele problemei identificate și dacă atacurile vor fi la fel de masive ca în cazul vulnerabilității din Log4j 2. Vulnerabilității i s-a atribuit numele de cod Spring4Shell, dar identificatorul CVE nu a fost încă alocat. În Spring Framework, problema rămâne nerezolvată, iar pe internet sunt deja disponibile mai multe prototipuri funcționale de exploatare (1, 2, 3, 4). Problema este agravată de faptul că multe aplicații Java enterprise bazate pe Spring Framework rulează cu privilegii root, iar vulnerabilitatea permite compromiterea completă a sistemului.
Potrivit unor estimări, modulul Spring Core este utilizat în 74% dintre aplicațiile Java. Pericolul vulnerabilității este diminuat de faptul că sunt afectate doar aplicațiile care folosesc adnotarea „@RequestMapping” la conectarea handler-elor de cereri și legarea parametrilor formularilor web în formatul „name=value” (POJO, Plain Old Java Object), în loc de utilizarea JSON/XML.
Care anume aplicații Java și framework-uri sunt afectate de problemă nu este încă clar. Vulnerabilitatea blochează adăugarea în lista neagră a câmpurilor „class”, „module” și „classLoader” sau utilizarea unei liste albe explicite de câmpuri permise. Exploatarea vulnerabilității este posibilă doar cu utilizarea Java/JDK 9 sau a unei versiuni mai noi. Problema este cauzată de posibilitatea de a ocoli protecția împotriva vulnerabilității CVE-2010-1622, reparată în Spring Framework încă din 2010 și legată de executarea handler-ului classLoader la analizarea parametrilor cererii.
Funcția exploitului constă în trimiterea unei cereri cu parametrii „class.module.classLoader.resources.context.parent.pipeline.first.*”, procesarea cărora duce la crearea unui fișier jsp în mediul de bază Apache Tomcat și la scrierea în acest fișier a codului specificat de atacator. Fișierul creat devine accesibil pentru cereri directe și poate fi folosit ca web shell. Pentru a ataca o aplicație vulnerabilă în mediul Apache Tomcat, este suficient să trimiteți o cerere cu parametrii corespunzători folosind utilitarul curl. curl -v -d „class.module.classLoader.resources.context.parent.pipeline.first.pattern=cod_de_inserat_in_fisier&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
Problema discutată în Spring Core nu trebuie confundată cu vulnerabilitățile descoperite recent, CVE-2022-22963 și CVE-2022-22950. Prima problemă afectează pachetul Spring Cloud și a fost remediată în versiunile 3.1.7 și 3.2.3. A doua problemă se regăsește în Spring Expression și a fost corectată în Spring Framework 5.3.17. Acestea sunt vulnerabilități complet diferite. Despre noua vulnerabilitate, dezvoltatorii Spring Framework nu au făcut deocamdată nicio declarație și nu au publicat nicio corecție.
Ca măsură temporară de protecție, se recomandă utilizarea în cod a unei liste negre de parametri de cerere neacceptați: 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); } }
Sursa: opennet.ro
