Barracuda: log4j-bug wordt vooral ingezet voor botnets en ddos-aanvallen

De Log4Shell-kwetsbaarheid in Java-library log4j wordt in de praktijk vooral gebruikt om apparaten in botnets op te nemen en ddos-aanvallen uit te voeren. Beveiligingsbedrijf Barracuda zegt dat het vooral uitbuiting via het Mirai-botnet ziet, maar amper ransomware-infecties.

Barracuda baseert zich in een onderzoeksrapport op gevallen bij klanten waar misbruik van de kwetsbaarheid wordt gedetecteerd. Het gaat om Log4Shell, een aanval op Java-library log4j waar in december een bug in werd ontdekt. Die maakte het erg eenvoudig om een remote code execution uit te voeren en een systeem te infecteren. Hoewel er inmiddels een patch beschikbaar is voor de bug, waren veel beveiligingsonderzoekers bang voor grootschalige uitbuiting met ernstige gevolgen. Het zou via log4j bijvoorbeeld simpel zijn ransomware op een netwerk te zetten.

Uit het rapport van Barracuda blijkt nu dat het wel meevalt met die gevolgen. Het bedrijf zegt in de afgelopen maanden voornamelijk botnet- en cryptominingaanvallen te hebben gezien. Log4Shell wordt misbruikt om Monero-miners te installeren en om systemen op te nemen in botnets. Het gaat onder andere om het Mirai-botnet, maar ook Kinsing en XMRig. Dat gebeurde ook al kort na de openbaarmaking van de kwetsbaarheid; de enige aanvallen die in de eerste dagen voorkwamen waren botnetaanvallen.

Barracuda zegt wel een paar gevallen te hebben gezien van serieuzere cybercrimebendes die Log4Shell probeerden te misbruiken. De kwetsbaarheid wordt in dat geval voornamelijk ingezet om lateraal door een netwerk te bewegen, specifiek op VMware-installaties. "We zien niet veel voorbeelden van ransomware-aanvallen op VMware-installaties en verwachten dat dit eerder een dreiging van binnen is", schrijft het bedrijf.

Reacties (21)

[Marve79]

Ik denk dat het uiteindelijk wel meeviel met de kwetsbaarheid. Veel bedrijven draaien dit enkel intern. Niemand heeft een vcenter console naar buiten open staan en als er al log4j apps publiekelijk open staan dan zit hier vaak nog een reverse proxy tussen al dan niet met 2FA.

[_JGC_]

Denk dat je dat onderschat. Voorbeeldje is Apache Solr of ElasticSearch die gebruikt worden om een database te indexeren en makkelijk doorzoekbaar te maken. Die services hang je meestal niet aan het internet maar gebruik je intern voor je website. Genoeg omgevingen waarbij die services zelf wel gewoon het internet op kunnen. Een zoekstring vanaf de website die niet gestript wordt van wazige tekens is dan voldoende om rotzooi binnen te halen via Log4J en JNDI.

Wel heb ik meer last gehad van de paniek rond die bug dan de bug zelf. Bedrijven met Windows 2008 webservers die al tig jaar geen updates gehad hebben moeten ineens gescand worden op de aanwezigheid van Log4J terwijl die bedrijven helemaal niks met Java doen...

[Marve79]

Precies dat, ik zie overal nog 2008/2003/XP systemen zo lek als een mandje en dan moet er vanuit management ineens worden gescanned op log4j.

[FreezeXJ]

Dat is juist de kans om die dingen te (laten) vervangen/isoleren, want je kunt niks garanderen. Never waste a good crisis...

[CAPSLOCK2000]

Ik ben het erg eens met al je punten. Log4j is een gemene bug die eenvoudig misbruikt kan worden en 'op afstand' kan doorwerken in andere systemen.

Wel heb ik meer last gehad van de paniek rond die bug dan de bug zelf. Bedrijven met Windows 2008 webservers die al tig jaar geen updates gehad hebben moeten ineens gescand worden op de aanwezigheid van Log4J terwijl die bedrijven helemaal niks met Java doen...

Ik kan ook beamen dat er deze keer fors is gereageerd. Ik ga daar op zich niet over klagen, de bug is er erg genoeg voor. Volgens mij heeft het veel te maken met de timing, vlak voor kerst. Dat is hét moment voor hackers om toe te slaan omdat iedereen vakantie heeft. Dan is er minder toezicht, minder tijd om te reageren en meer tijd dat de baas "gewoon" betaalt zodat kerst niet in het water valt.
Zeker na de ransomware aanval op de universiteit van Maastricht is daar in Nederland veel aandacht voor.

De keerzijde is dat allerlei mensen zich er mee zijn gaan bemoeien die normaal niks aan IT-beveliging doen en dat geeft natuurlijk niet de beste resultaten. Ook bij ons zag ik dat er veel werk is gestoken in de verkeerde systemen alleen omdat een of andere tussenmanager van een andere afdeling iets had gehoord dat de tennisleraar van z'n buurvrouw in de krant had gelezen.

Ik ben blij met de aandacht voor de bug, die aandacht is het probleem niet.
Het echte probleem is hoeveel organisaties er hebben zitten slapen waardoor de aandacht voor log4j buiten proportie lijkt omdat er zoveel paniek over was.

Deze thread staat vol met mensen die klagen over de antieke systemen die ze nog moeten beheren. Die systemen hadden natuurlijk opgeruimd moeten worden. Als dat om wat voor reden niet kan dan zou je al andere maatregelen getroffen moeten hebben om het probleem klein te houden. En je zou sowieso een goed beeld moeten hebben van wat je in huis hebt zodat je bij problemen gericht kan zoeken.

Daar moet ik wel bij zeggen dat niet altijd direct duidelijk is of een systeem ergens log4j gebruikt, het kan behoorlijk verborgen zijn. Een brede scan doen is op zich een goed idee, maar aan het begin van een crisis heb je daar geen tijd voor, zeker als je het gereedschap nog niet klaar hebt staan.

Het frustrerende is dat een hoop organisaties vinden dat ze uitstekend hebben gehandeld. "Er was een crisis, het personeel is gebeld, die zijn gaan werken en hebben het opgelost. Succes! Wat zijn we toch goed!"

Het scannen van oude systemen is een prachtig voorbeeld omdat er twee versies van log4j zijn, een oude en een nieuwe. Alleen de nieuwe was kwetsbaar voor deze bug. Systemen die al 15 jaar geen goed onderhoud hebben gehad is niet nodig, toen bestond de bug nog niet.

Maar 1 week later werd een bijna net zo grote bug gevonden in log4j 1. Hoewel de bug iets kleiner was is de impact misschien wel groter omdat log4j geen support meer heeft en er dus helemaal geen patches voor deze bug zijn. Je zou dus denken dat er een net zo grote paniekreactie zou komen op die nieuwe bug. Maar nee hoor, doodse stilte. Alles is weer zoals het was. Dezelfde mensen die met Kerst een bek vol hadden over "verantwoordelijkheid nemen" en over "uitzonderlijke situaties" en "ernstige bedreigingen van de bedrijfszekerheid" zijn nu weer onbereikbaar.

De pijnlijke realiteit is dat we best wel klem zitten. Deze situatie is over vele jaren opgebouwd en op veel punten zijn er eigenlijk geen goede oplossingen meer, in ieder geval geen die een normal bedrijf kan betalen. Zelf patches voor Windows 2003 systemen schrijven is in theorie mogelijk maar in praktijk niet realistisch. Veel organisaties zijn helemaal afhankelijk van oude software waar geen vervanging voor is, althans niet zonder hun oude data kwijt te raken en als je met andere organisaties moet samenwerken wordt het nog veel lastiger.
Hoe langer je wacht hoe duurder het wordt, daardoor zijn er steeds meer systemen die financieel gezien onvervangbaar zijn.

De onhoudbaarheid van de situatie begint langzaam door te dringen buiten de IT. De realiteit dwingt accountants, verzekeraars, banken, auditors, overheden en ander professionele 'dragers van verantwoordelijkheid' om steeds meer aandacht te geven aan IT. Maar die kunnen ook niks veranderen aan de enorme prijs van verandering.

In mijn omgeving zie ik vooral nog ongeloof. "IT zal wel weer overdrijven want die roepen altijd dat het dak in brand staat" lijkt de houding. Je kan vaak niet anders want concluderen dat je meer in IT moet investeren dan je organisatie waard is wil niemand. Wie dat echt gelooft kan er beter mee stoppen. We houden dus mensen over die de realiteit ontkennen of niet begrijpen

De mensen die het niet geloven of begrijpen beginnen dus een eindeloze series onderzoekjes, kosten-baten-analyses, mitagatietrajcten, prioriteitenlijstjes, gap-analyses, auditrondes in de hoop dat iemand anders met een oplossing komt die technisch, financieel en zakelijk haalbaar is zonder pijnlijke ingrepen. Ondertussen worden ze leeggemolken.

En dan werk ik nog in een sector die veel aandacht krijgt van overheid, toezichthouders en de media.

[Robtimus]

Veel bedrijven draaien dit enkel intern.

De applicaties die Log4J gebruiken draaien misschien vaak intern, maar deze aanval kwam daar vaak gewoon doorheen. Login requests worden normaal gewoon doorgestuurd naar de achterliggende servers. Als deze de username loggen en de opgegeven username bevat een injection string, dan zal die interne server proberen code te downloaden. Als het netwerk goed is opgezet dan lukt dit inderdaad niet, maar er zullen genoeg bedrijven zijn die inbound verkeer wel blokkeren, maar outbound verkeer niet.

[Blokker_1999]

Hoewel vele applicaties intern draaien, heb ik ook voldoende kwetsbare applicaties op de lijst zien staan die net bedoeld zijn om extern gebruikt te worden. Zo was het product dat wij gebruiken voor externen toegang te geven tot onze omgeving van buitenaf kwetsbaar, als we gebruikt hadden gemaakt van de appliance versie ipv de VM versie bijvoorbeeld.

Maar ook intern kan de schade groot worden. Grote inbraken worden meestal mogelijk gemaakt door een aaneenschakeling van kleine foutjes, dit is er daar zo 1 van.

[CAPSLOCK2000]

Hoewel vele applicaties intern draaien, heb ik ook voldoende kwetsbare applicaties op de lijst zien staan die net bedoeld zijn om extern gebruikt te worden.

We moeten af van het "intern" vs "extern" concept. Alles wordt verbonden. Alles hangt aan internet. Ieder modern apparaat doet iets met een netwerk/internet-aansluiting. De cloud dringt overal door. Als het nu nog niet zo is dan over een paar jaar wel.

Ik bedoel daarmee natuurlijk niet dat je je "buitenmuren" moet afbreken maar dat je ook je "binnenmuren" moet versterken.

De situatie doet me een beetje denken aan de http vs https discussie. We hebben jarenlang discussies gevoerd over welke systemen https "nodig" hebben en welke niet. Uiteindelijk zijn we tot de conclusie gekomen dat de kans op vergissingen zo groot is dat je gewoon overal https wil gebruiken. Bijhouden welke systemen wel en welke niet is duurder (in schaalvoordeel, beheer en controle) alles uniform behandelen en dus alles te beveiligen.

log4j geeft ook nog een aardige demonstratie van dat het onderscheid tussen 'intern' en 'extern' helemaal niet zo duidelijk is. De 'externe' systemen staan immers in verbinding met de 'interne' systemen.


Een moderne kijk op security is dat je er van uit moet gaan dat het netwerk zelf niet te vertrouwen is. In iedere organisatie is er wel ergens een klein gaatje te vinden van buiten naar binnen. Iedereen heeft wel een systeem dat niet zo belangrijk is en/of niet goed wordt beheerd. Je wil niet dat als dat kleine gaatje gevonden wordt dat er vanaf daar verder gehackt kan worden naar andere systemen waar de grote gaten nog open staan.

[Reactie gewijzigd door CAPSLOCK2000 op 27 juli 2024 09:24]

[Phntm]

Volgens mij onderschat je de omvang van het Log4j problematiek. Dit raakt niet alleen bedrijven, maar ook gebruikers van producten van deze bedrijven. Kijk alleen al naar 1 van de meest gespeelde games: Minecraft. Daar was deze exploit ook goed op te gebruiken. Botnet verspreiding werd zo makkelijk als 1,2,3. Zou daar maar net iemand met belangrijke functie tussen zitten die dochter of zoonlief even een spelletje laat doen.

[gimbal]

Nog steeds denk ik want de patch zal niet gebackport zijn naar oudere releases. Nu draaien er best wel veel servers een oudere versie voor diverse redenen...

[CAPSLOCK2000]

Nog steeds denk ik want de patch zal niet gebackport zijn naar oudere releases. Nu draaien er best wel veel servers een oudere versie voor diverse redenen...

Het klopt dat die oude versie niet meer wordt onderhouden door de oorspronkelijke auteur, maar het is open source dus iemand anders heeft wel gedaan!
Het project heet reload4j en is een drop-in replacement voor log4j versie 1. https://reload4j.qos.ch/

Het is zo simpel als de oude file weghalen en vervangen door de nieuwe.
Maar er is één grote aantekening, namelijk dat dit alleen een fix is voor dit specifieke probleem. Log4j 1 blijft deprecated en zou je niet meer moeten gebruiken.
Als het echt niet anders kan kun je reload4j overwegen als tussenoplossing maar je zal nog steeds over moeten naar log4j versie 2 (of iets anders dat wel modern is).

Laat je dus niet in de luren leggen door te denken dat je probleem is opgelost als je reload4j installeert.
Ik ben zelfs terughoudend met vertellen over deze software omdat ik weet dat het op een aantal plekken zal worden ingezet als enige fix waarna mensen denken dat ze veilig zijn. Uiteindelijk neemt dat aandacht en resources weg van een echte oplossing.
Maar omdat die partijen toch hopeloos en kansloos zijn wil ik anderen daar niet onder laten lijden. Doe wat je moet doen.

[Marve79]

Minecraft was inderdaad een groot doelwit maar dat verklaart ook direct waarom er weinig ransomware met log4j wordt verspreid. Dat is enkel interessant bij bedrijven. Bij consumenten systemen die niet 24 uur per dag aanstaan is een botnet veel interessanter.

[Cyb]

Veel bedrijven draaien dit enkel intern.

Dat is een veel gemaakte fout: denken dat log4j niet van toepassing is op een systeem omdat het "intern" draait.
Élk systeem waarlangs data stroomt, en een kwetsbare versie gebruikt, is potentieel kwetsbaar. Zelfs indien dit systeem diep weggestopt is in een intern netwerk.

[mbovenka]

Kwetsbaar ja, maar als de getroffen machine dan vervolgens geen Internet-connectiviteit heeft, gebeurt er uitendelijk niets.

[Cyb]

Bij de meeste systemen binnen een intern netwerk, worden uitgaande Internet verbindingen gewoon toegestaan door firewalls. Dat kan uiteraard geblokkeerd worden, maar dat is eerder niet het geval dan wel het geval.

[mbovenka]

Grosso modo heb je daar gelijk in denk ik, maar de laatste tijd is mijn ervaring (bij overheidsinstanties) wel anders.

[Frame164]

Je valt nu in de valkuil waar velen invallen. Een aanvaller hoeft niet per se hier can buitenaf direct bij te kunnen. Via meerdere stappen over andere systemen is ook een optie.

[Marve79]

True. maar dat is allemaal ontzettend hypotetisch. En ik zeg ook niet dat je het niet moet patchen he, dat moet je zeker doen maar er zijn bij bedrijven vaak al grotere lekken aanwezig waar niets aan wordt gedaan. Maar omdat log4j zo zwaar in de media was wordt er vanuit management ineens keihard op het patchen ervan aangestuurd.

[RalphM.]

Ja en nee. Als je 1 framework over het hoofd ziet dat het gebruikt en op een of andere manier toegankelijk is, dan kun je daarmee alle aangesloten computers en servers binnenkomen ongeacht waar ze staan in een network.

Deze hoogleraren aan de universiteit van Nottingham leggen het vrij simpel, maar effectief uit:
https://www.youtube.com/watch?v=Opqgwn8TdlM

[Verwijderd]

Het hoeft niet open te staan voor de buitenwereld. Je hoeft alleen maar te zorgen dat er een url terecht komt in een uiteindelijke logger.
Stel ik heb een nginx draaien waarbij de requests opgeslagen worden in een Elasticsearch/Kibana stack.
Als er een url gefabriceerd wordt waarin een bepaalt patroon zit,. en die een error/warning triggert in Elasticsearch, dan komt het langs LOG4J op een doos die zelf niet extern benaderbaar is, en dan ben je er.

Juist dit soort pakketten draaien heel erg veel achter de schermen bij (web)servers. Denk dus aan paketten als Kibana, Grafana en Graylog.

[Vogel666]

Een beetje bedrijf heeft al gauw een paar duizend client computers in zijn netwerk zitten. Dat betekent dat deze bedrijven naar aller waarschijnlijkheid ten minste 1 client computer in hun netwerk hebben die onder controle is van een hacker. Je moet aannemen dat hackers al een steppingstone hebben in je netwerk.
Daarnaast is het vrijwel onmogelijk om fysieke toegang tot je netwerk af te schermen. Als je echt heel graag ergens binnen wil komen: loop naar binnen en prik je raspberry pi in de netwerkpoort die eigenlijk van die stoffige printer was en je hebt je trojan horse. Bijna niemand heeft 801.2x geregeld voor printers. En omdat tegenwoordig niemand meer print, kan dat zomaar een jaartje duren voordat die RPi wordt opgemerkt.
Ook leveranciers hebben hun trojan horses in je netwerk staan. De klimaat installatie, tal van MFP's met een 3G dialhome functie, camera systemen, alarm installaties, software leveranciers.... Een mooie manier om in 1x binnen te komen in honderden of duizenden netwerken.

Stop met "bastion"-denken en beveilig ieder element in je netwerk met access, authenticatie en authorisatie. Log4J fietst zo langs (tenminste) 2 van deze basisbeginselen..

[Reactie gewijzigd door Vogel666 op 27 juli 2024 09:24]