Spring4Shell nadużywany w kampanii popychającej Mirai
Implementacje oparte na Javie wydają się być darem, który wciąż daje. Od czasu do czasu pojawiają się doniesienia o trwających próbach wykorzystania Log4j, luki, o której wszyscy myśleli zimą, teraz nadchodzą wiadomości o aktywnym wykorzystaniu najnowszej istotnej luki w bibliotece Spring Core Java.
Uzbrojone złośliwe oprogramowanie Mirai używane w kampanii
Kampania ataków przy użyciu Spring4Shell jest monitorowana przez dwie oddzielne firmy zajmujące się badaniem bezpieczeństwa. Teraz zespoły badawcze zauważają, że stary znajomy wykorzystuje lukę Spring4Shell.
Obie firmy zajmujące się bezpieczeństwem zauważyły, że uzbrojona wersja złośliwego oprogramowania Mirai, powszechnie kojarzonego z wykorzystaniem botnetów, była wykorzystywana do aktywnego wykorzystywania luki Spring4Shell.
Badając systemy podatne na nową kampanię, zmuszającą Mirai do nadużywania Spring4Shell, badacze zauważyli szereg cech występujących w systemach podatnych na eksploatację. Obejmują one obecność frameworka Spring, uruchamianie poprawek przed wersją 5.2.20 oraz aktualizację JDK do wersji 9 lub nowszej. Wiadomo, że luka Spring4Shell nie dotyczy platform ze starszym zestawem Java Development Kit, takim jak JDK 8.
Apache Tomcat i specyficzne konfiguracje wiązania parametrów Spring, ustawione na używanie niepodstawowego typu parametrów, również należą do funkcji specyficznych dla podatnych systemów.
Pierwsze próby wykorzystania wady i przesunięcia daty Mirai na koniec marca
W ostatnim dniu marca 2022 roku honeypoty obsługiwane przez naukowców wykryły pierwsze próby włamań.
Ataki wykorzystujące uzbrojone złośliwe oprogramowanie Mirai na systemy podatne na działanie Spring4Shell koncentrowały się głównie na celach zlokalizowanych w Singapurze i regionie.
Badacze spodziewają się, że ataki próbujące wykorzystać lukę Spring4Shell tylko zwiększą się w ciągu najbliższych miesięcy, ponieważ usterka została dobrze udokumentowana, a szczegóły są dostępne również dla cyberprzestępców. Łatanie pozostaje tak samo istotne jak zawsze, ale podobnie jak w przypadku Log4j, problemem nie jest tu łatanie, ale sama liczba systemów, w których działa kod podatny na ataki. W tym sensie nawet 1% niezałatanych systemów na miliony stanowi znaczną liczbę potencjalnych celów dla exploita.