Spring4Shell zlorabljen v kampanji potiska Mirai
Zdi se, da so implementacije, ki temeljijo na Javi, darilo, ki še naprej daje. Z občasnimi poročili o nenehnih prizadevanjih za izkoriščanje Log4j , ranljivosti, o kateri so bili vsi v mislih pozimi, zdaj prihajajo novice za aktivno izkoriščanje najnovejše pomembne ranljivosti, odkrite v knjižnici Spring Core Java.
V kampanji uporabljena oborožena zlonamerna programska oprema Mirai
Napadno kampanjo z uporabo Spring4Shell spremljata dve ločeni podjetji za raziskave varnosti. Zdaj raziskovalne skupine opazijo starega znanca, ki se uporablja za izkoriščanje ranljivosti Spring4Shell.
Obe varnostni podjetji sta opazili, da se za aktivno izkoriščanje napake Spring4Shell uporablja oborožena različica zlonamerne programske opreme Mirai , ki je običajno povezana z uporabo botneta.
Ko so raziskovalci preučevali sisteme, ki so ranljivi za novo kampanjo, ki je Mirai prisilila k zlorabi Spring4Shell, so raziskovalci opazili številne lastnosti, ki jih najdemo v sistemih, ki so dovzetni za izkoriščanje. Ti vključujejo prisotnost okvirja Spring, popravke, ki se izvajajo pred 5.2.20, in JDK, posodobljen na različice 9 ali novejše. Znano je, da napaka Spring4Shell ne vpliva na platforme, ki izvajajo starejši Java Development Kit, kot je JDK 8.
Apache Tomcat in posebne konfiguracije vezave parametrov Spring, ki so nastavljene za uporabo neosnovnega tipa parametra, sodijo tudi med funkcije, značilne za ranljive sisteme.
Prvi poskusi zlorabe napake in prestavitev zmenka Mirai na konec marca
Mede, ki jih upravljajo raziskovalci, so prve poskuse vdora zaznale zadnji dan marca 2022.
Napadi z uporabo oborožene zlonamerne programske opreme Mirai na sisteme, ranljive za Spring4Shell, so bili večinoma osredotočeni na cilje v Singapurju in regiji.
Raziskovalci pričakujejo, da se bodo napadi, ki poskušajo izkoristiti ranljivost Spring4Shell, v naslednjih mesecih le povečali, saj je bila napaka dobro dokumentirana, podrobnosti pa so na voljo tudi akterjem groženj. Popravki ostajajo tako bistveni kot vedno, vendar podobno kot v primeru Log4j tukaj ni težava v popravkih, temveč v samem številu sistemov, ki izvajajo ranljivo kodo. V tem smislu je celo 1 % nepokrpanih sistemov od milijonov veliko število možnih tarč za izkoriščanje.