Barracudaforskare har märkt en stadig ström av attacker som försöker utnyttja log4j-sårbarheten sedan den hittades. Det som är intressant är var de flesta attackerna kommer från.
Log4Shell, en exploatering riktad mot det ofta använda Apache Log4j-biblioteket, har inte visat några tecken på att sakta ner som ett populärt mål för hackare sedan upptäckten i december, sa forskare vid Barracuda Networks.
Log4Shell är ungefär lika kritisk som en kritisk sårbarhet kan bli. Den fick 10 av 10 av National Institute of Standards and Technologys allvarlighetsskala, och med goda skäl: den riktar sig till ett bibliotek som nästan alla Java-applikationer använder för att logga förfrågningar, och allt som krävs för att utlösa det är en skadlig sträng från angriparen .
SER: Google Chrome: Säkerhets- och användargränssnittstips du behöver veta (TechRepublic Premium)
Måste läsa säkerhetstäckning
Sedan upptäckten i december, sade Barracuda Senior Product Marketing Manager för applikationer och molnsäkerhet Tushar Richabadas, “volymen attacker som försöker utnyttja dessa sårbarheter har förblivit relativt konstant med några fall och toppar under de senaste två månaderna.”
Här är det märkliga: 83 % av attackerna som har försökt utnyttja Log4Shell har sitt ursprung i USA.
Anatomin hos Log4Shell-attacker
Barracuda sa att de hämtade data från attacker från den 10 december 2021 för att få en fullständig titt på hur Log4Shell har använts sedan upptäckten. Som nämnts ovan hittade forskarna en del intressanta data när de tittade på angriparens IP:er: Majoriteten kommer från USA, medan resten kommer från Japan (10%), Tyskland och Nederländerna (3%) och Ryssland (1%).
Richabadas noterade att en attack som härrör från en viss IP inte betyder att angriparen är geografiskt placerad på den platsen, särskilt eftersom Barracuda fann att hälften av attackerna med ursprung i USA kom från AWS, Azure och andra molndatacenter.
“Molntjänster ger bara enkel tillgång till tillfälliga IP-adresser som har ett gott rykte och som sannolikt inte kommer att vara geografiska eller rykte blockerade,” sa Richabadas. Dessutom noterade han att faktiska nyttolaster troligen levererades från andra komprometterade webbplatser eller virtuella privata servrar. Dessa IP-adresser är vanligtvis kodade i Base64 för att ytterligare fördunkla dem, vilket gör det svårare att avgöra var nyttolasten kommer från.
När det gäller vad angripare gör när de väl har lyckats använda Log4Shell-utnyttjandet, pekade Barracuda ut fyra exempel: Ett relativt ofarligt skämt, kryptominerande skadlig kod, DDoS-skadlig programvara och VMware-inriktad skadlig programvara.
Det första är, beroende på hur man ser på det, ett ganska godartat men ändå informativt trick: Rick-Rolls användare när en viss uppsättning villkor är uppfyllda. I motsats till den där “attacken”, som faktiskt kan anses vara användbar ur ett “tack för att du låter oss veta”-perspektiv, är de andra som Barracuda beskriver avgjort mindre “hjälpsamma”.
SER: Lösenordsintrång: Varför popkultur och lösenord inte blandas (gratis PDF) (TechRepublic)
Monero kryptominerande skadlig kod har hittats, liksom skadlig programvara som riktar sig mot VMware-installationer, initierar DDoS-attacker och installerar en mängd olika botnätskadliga program, varav den vanligaste har varit IoT-enheten riktad mot Mirai botnet.
Typerna av attacker kan också ge en ledtråd om vad som kommer inom den närmaste framtiden för cybersäkerhet, sa Richabadas. “Förekomsten av DDoS botnet malware verkar tyda på att hotaktörer arbetar för att bygga ut ett stort botnät för framtida användning, och det bör finnas en förväntan på stora DDoS attacker inom en snar framtid.”
Att skydda sig mot Log4Shell är verkligen enkelt
Det finns en enkel fix som helt skulle kunna ta bort denna risk från din cybersäkerhetskalkyl: Patcha till den senaste versionen av Log4j, som tar hand om problemet.
Det är inte alltid möjligt i produktionsmiljöer, så om du inte kan patcha nu finns det steg du kan vidta för att avgöra om dina system är sårbara för Log4Shell, såväl som olika saker som kan göras för att minimera din Log4Shell-exponering … tills du faktiskt kan installera patchen, vilket borde vara ditt slutliga mål.
