Spring4Shell a fost abuzat în campania care îl împinge pe Mirai
Implementările bazate pe Java par a fi darul care continuă să ofere. Cu rapoarte ocazionale despre eforturile continue de a exploata Log4j , vulnerabilitatea care era în mintea tuturor în timpul iernii, acum vin știri pentru exploatarea activă a celei mai recente vulnerabilități semnificative descoperite în biblioteca Spring Core Java.
Malware Mirai înarmat folosit în campanie
Campania de atac folosind Spring4Shell este monitorizată de două firme separate de cercetare în domeniul securității. Acum, echipele de cercetare observă că o veche cunoștință este folosită pentru a exploata vulnerabilitatea Spring4Shell.
Ambele companii de securitate au observat că o versiune înarmată a programului malware Mirai , asociată în mod obișnuit cu utilizarea botnetului, a fost folosită pentru a exploata în mod activ defectul Spring4Shell.
La examinarea sistemelor vulnerabile la noua campanie care o împinge pe Mirai să abuzeze de Spring4Shell, cercetătorii au observat o serie de trăsături găsite în sistemele susceptibile de exploatare. Acestea includ prezența cadrului Spring, corecțiile care rulează înainte de 5.2.20 și JDK-ul actualizat la versiunile 9 sau mai noi. Se știe că defectul Spring4Shell nu afectează platformele care rulează Java Development Kit mai vechi, cum ar fi JDK 8.
Apache Tomcat și configurațiile specifice ale legării parametrilor Spring, setate să utilizeze un tip de parametru non-de bază, se numără și printre caracteristicile specifice sistemelor vulnerabile.
Primele încercări de a abuza de defect și de a împinge data cu Mirai la sfârșitul lunii martie
Honeypots operate de cercetători au detectat primele încercări de intruziune în ultima zi a lunii martie 2022.
Atacurile care desfășoară malware Mirai cu arme pe sisteme vulnerabile la Spring4Shell s-au concentrat în mare parte asupra țintelor situate în Singapore și regiune.
Cercetătorii se așteaptă ca atacurile care încearcă să exploateze vulnerabilitatea Spring4Shell să crească doar în volum în următoarele luni, deoarece defectul a fost bine documentat și detaliile sunt disponibile pentru ca și actorii amenințărilor să le poată observa. Corectarea rămâne la fel de esențială ca întotdeauna, dar similar cu cazul Log4j , problema aici nu este corecția, ci numărul mare de sisteme care rulează cod vulnerabil. În acest sens, chiar și 1% din sistemele nepatchate din milioane reprezintă un număr semnificativ de ținte potențiale pentru exploit.