Duitsland waarschuwt met code rood voor uitval diensten door Log4j-kwetsbaarheid

Het Duitse ministerie van Binnenlandse Zaken heeft code rood afgekondigd vanwege de Log4j 2-kwetsbaarheid. Dit is het hoogste dreigingsniveau, waarmee voor uitval van veel diensten gewaarschuwd wordt. Het NCSC zet op een rij welke applicaties kwetsbaar zijn.

Het Bundesamts für Sicherheit in der Informationstechnik, onderdeel van het Duitse ministerie van Binnenlandse Zaken, constateert dat wereldwijd massaal scans op kwetsbare Log4j 2-implementaties door kwaadwillenden worden uitgevoerd. Ook wijst de dienst er op dat er succesvolle aanvallen worden gemeld. De BSI heeft code rood, oftewel de hoogste van vier alarmfasen, afgekondigd om de ernst van de situatie aan te geven. De reden voor deze inschatting is dat Log4j 2 zo wijdverspreid is, de kwetsbaarheid eenvoudig uit te buiten is en er proof-of-concept-code publiekelijk beschikbaar is.

Het Nederlandse NCSC heeft een lijst van applicaties die kwetsbaar zijn als gevolg van de Log4j-kwetsbaarheid gepubliceerd. Op de lijst staan producten van onder andere Apache zelf, Amazon, Cisco, Microsoft, Red Hat, Sonicwall en VMware. Het NCSC meldt daarbij zoveel mogelijk de kwetsbare versie, de actuele status en de bron. De organisatie benadrukt dat de lijst nog niet volledig is. Het NCSC heeft partners, organisaties en bedrijven dringend gevraagd om aanvullende informatie te delen op Github. "Deze pagina gaat ook gebruikt worden om scan- en detectiemogelijkheden en Indicators of Compromise bekend te maken", aldus het NCSC. De organisatie zet stappen op een rij die beheerders kunnen nemen om problemen te verhelpen.

Vrijdag werd bekend dat er een ernstige kwetsbaarheid in de opensourcetool Apache Log4j 2 zit, die het mogelijk maakt voor ongeauthenticeerden om op afstand willekeurige code te injecteren en uit te voeren met de rechten van de webserver. De Java-logtool wordt door veel organisaties gebruikt, waardoor het risico op misbruik als hoog gezien wordt. De kwetsbaarheid heeft de aanduiding CVE-2021-44228 gekregen en staat ook bekend als Log4Shell of LogJam. Apache heeft updates uitgebracht om de kwetsbaarheid te verhelpen en bij versie 2.15.0 is het probleem verholpen.

Volgens het Microsoft Threat Intelligence Center wordt de kwetsbaarheid al ingezet om Cobalt Strike-malware en coinminers te plaatsen. Netlab 360 waarschuwt dat criminelen de kwetsbaarheid misbruiken om Mirai- en Muhstik-malware voor botnets te installeren op systemen.

Reacties (167)

[r2504]

Dit is alvast een mooi en duidelijk artikel over hoe het precies werkt... https://www.fastly.com/bl...ce-exploit-found-in-log4j

[mocean]

Typisch features die je echt niet wil in een logger: Resources ophalen via LDAP....

[Polderviking]

Tjah.
Wat die module wel en niet moet doen kan je jaren over doorpraten.

Volgens mij moeten techgiganten die hun miljoenen/miljarden business op dit soort module's laten leunen vooral eens de handen ineen gaan slaan en zorgen dat dit soort belangrijke open source hoekstenen in de tech wereld niet op één of ander non-budget in de vrije tijd van Gerrit de Hobbybob uit havelterlutjebroek onderhouden worden zodat hun miljoenenproduct niet keihard omflikkert als Gerrit ergens een beredeneringsfoutje maakt in softwarelogica.

En met handen ineens slaan bedoel ik eigenlijk vooral gewoon een beetje geld in de richting gooien van al die dames en heren die voor de leuk al die gratis software maken.

Het is niet de eerste keer dat zo'n omhooggevallen hobbyproject op schaal ellende geeft gewoon omdat er geen geld is. (hallo heartbleed)

[mocean]

De Apache foundation is niet echt een hobbyclub...

[Polderviking]

Apache is een non-profit en volgens hun wikipediapagina hadden ze in 2019 een omzet van 2 miljoen, daarmee moeten ze alles afdekken wat ze doen.
Dat is echt kruimeltjeswerk als je kijkt naar de schaal waarop apache software werkt.

Log4j2 specifiek wordt onderhouden door 2 of 3 mensen op vrijwillige basis.

Edit:
En desondanks toch in een bliksemtempo met fixes op de proppen komen ook.

Ik zit ondertussen al bijna 4 dagen te wachten op feedback van Adobe (15,4 miljard omzet...) rond de attack surfance van deze kwestie in Coldfusion.

[Reactie gewijzigd door Polderviking op 23 juli 2024 03:56]

[mocean]

Wow Coldfusion deed in in 2000 of zo, bestaat dat nog?

[roberttttt]

Ik begrijp niet hoe een logging systeem die geacht wordt alleen maar data op te slaan malafide code kan uitvoeren. Kennelijk doet het dus meer dan alleen loggen.
Als dat zo is snap ik niet dat de makers daarvan niet hebben begrepen dat dat een gevaar kan opleveren.

[ACM]

Logging-bibliotheken/systemen bieden vaak mogelijkheden om wat meer met de berichtjes te doen dan puur platte tekst doorgeven. Bijvoorbeeld om een variabele op een bepaalde plek in te voeren. Dat kan handig zijn om automatisch iets als een servernaam toe te voegen in een bericht als "Server $server started", zonder dat je dat op voorhand al moet doen of zelfs maar hoeft te weten hoe server eigenlijk heet.

Dit lek bevindt zich in het soort logica die dan zo'n $server zou vervangen door de echte waarde. En blijkbaar had log4j daarbij ondersteuning om informatie van externe servers, met name ldap, op te vragen.

[blackbaby]

Wij hebben uitgerekend deze vulnerability ontdekt op een authenticatieserver van PingIdentity, die grotendeels blibliotheken bij Apache foundation zoals log4j heeft geleend. Een authenticatieserver met een lek op LDAP commando's, tja, daarmee leg je letterlijk alle Active Directory diensten binnen het bedrijf te grabbel.

[Reactie gewijzigd door blackbaby op 23 juli 2024 03:56]

[ACM]

heeft 'geleend'

Dat staat de apache-licentie dan ook gewoon toe, dus de ' is overbodig

Neemt de ironie verder niet weg natuurlijk

[Sebazzz]

Dit legt het goed uit: https://twitter.com/entropyqueen_/status/1469606438632833027

Basically door een logbericht op een bepaalde manier te formatteren kan je een download triggeren en uitvoer van de gedownloade payload.

[delphium]

Zo werkt het niet helemaal. De logserver (log4j) kan ook logs van andere systemen ontvangen. Het blijkt nu mogelijk om in plaats van een logbericht, code te laten loggen en die vervolgens op afstand uit te voeren met de rechten van de loggende (web)server.

[aikebah]

Alleen is log4j helemaal geen logserver, maar een logging-bibliotheek. En @roberttttt heeft helemaal gelijk: onbegrijpelijk dat nadat er (in de log-call meegegeven) variabele-substitutie heeft plaatsgevonden het log framework in de resulterende log MESSAGE nog een keer zoekt naar placeholders om te gaan vervangen.
Dat daarbij dan gebruikt gemaakt wordt van een methode die ook nog eens remote code execution faciliteert is wat onfortuinlijk, maar de functionaliteit had er naar mijn idee helemaal niet in moeten zitten, of anders in de standaard-configuratie uit moeten staan (wat ze nu, in reactie op dit probleem ook hebben gedaan, samen met wat extra restricties op de placeholdervervangingslogica als je die wel aan zet)

[Anoniem: 1322]

Het is ook in de basis een enorm oud stuk software (2001). Men ontwikkelde toen ook niet secure-by-design maar gelukkig zie je in veel (oude) open-source software dat dit soort ongein wordt aangepakt.

[dcm360]

Het gaat echter wel specifiek om Log4j 2, en die is geheel opnieuw opgebouwd met eerste release in 2014. De oude versie (hoewel daar onderhand ook wel bekende problemen in zitten) met de basis uit 2001 bevat deze kwetsbaarheid niet.

[TheekAzzaBreek]

Heb je daar een bron voor?
Ik lees dat ook in verschillende berichten, maar afgezien van de beschrijving in het CVE entry ( "Log4j2 <=2.14.1") worden ze nergens heel specifiek.

Wij hebben nog wel wat 1.2.x versies rondzwerven. Duidelijk dat we daar wat aan moeten doen, maar als je gelijk hebt hoeft dat niet vandaag.

@straaljager27 Dank!

[Reactie gewijzigd door TheekAzzaBreek op 23 juli 2024 03:56]

[straaljager27]

http://slf4j.org/log4shell.html
Geeft aan dat:"Is log4j 1.x vulnerable?
As log4j 1.x does NOT offer a look-up mechanism, it does NOT suffer from CVE-2021-44228.
Given that log4j version 1.x is still very widely deployed, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.
As log4j 1.x does NOT offer a look up mechanism, it does NOT suffer from CVE-2021-44228."


Dus ondanks dat (uiteraard) 1.X versies oud en kwetsbaar zijn, zijn deze níet kwetsbaar voor de CVE-2021-44228 kwetsbaarheid

[edit1]: @FreezeXJ

[Reactie gewijzigd door straaljager27 op 23 juli 2024 03:56]

[FreezeXJ]

Helaas, dat is nog niet gegarandeerd. Volgens de Apache website:

Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

[dcm360]

Op zich staat in dit artikel niet dat de oude versie vatbaar is. Wel dat er al een sinds 2019 bekende bug in zit waardoor RCE mogelijk is, dus upgraden moet hoe dan ook wel.

[d3burt]

Die RCE lijkt alleen bij zeer specifiek gebruik van log4j te exploiten (namelijk, als je log4j zelf een socket laat openen). Dat is zover ik weet niet de meest gebruikelijke manier om log4j in te zetten.

[Anoniem: 30722]

V1.x is Al sinds 2019 zo lek als een mandje verklaard en al sinds 2015 EOL. Moet je niet meer willen gebruiken dus.

[dcm360]

Helemaal mee eens, dat stel ik in mijn latere reactie ook: niet meer gebruiken. Maar versie 2 is niet een oud project dat al 20 jaar aan code meesleept, en dat was in deze context het punt.

[ACM]

Placeholders vervangen is helemaal niet zo gek. Het is zelfs een van de standaard codesmells in Sonar (iig bij logback); dat je (vooral) ivm performance variabelen door de logbibliotheek moet laten vervangen. Die weet tenslotte of het bericht daadwerkelijk gelogd gaat worden.

Maar dat zijn dan wel variabelen die je dan direct meegeeft, en enkel de toString nog van aangeroepen moet worden.

[R4gnax]

Maar dat zijn dan wel variabelen die je dan direct meegeeft, en enkel de toString nog van aangeroepen moet worden.

Zelfs complexe variabelen die eerst nog door een stack aan deconstructing modifiers heen zou moeten, zoals bijv. Serilog dat doet - zijn niet meteen een probleem.

Het specifieke probleem hier bij log4j is dat één of andere complete idioot schijnbaar ooit eens besloten heeft dat een replacer die een willekeurige download start adhv de waarde v/e token, een handig ding zou kunnen zijn.

Vervolgens hoeft er maar één applicatie geschreven te zijn die user input niet als replacer waarde mee stuurt, maar direct als de message template -- en die zijn er maar genoeg; dat is dan ook waarom quality-control systemen als Sonar je moet vertellen dat niet te doen... -- en de rapen zijn gaar.

Dit is gewoon SQL injection, maar dan via log4j.

[riven4096]

Het enge van deze exploit is juist dat zelfs je parameterized log-msg kwestbaar is:

logger.error("msg: ${jndi:ldap://127.0.0.1:5555/exploit}");
logger.error("msg: {}", "${jndi:ldap://127.0.0.1:5555/exploit}");

In beide gevallen wordt de exploit uitgevoerd, dus ook een goed geschreven applicatie biedt geen bescherming.

[riven4096]

Mijn 2e regel laat toch het scenario zien van een log-message template, met 1 parameter, die door log4j in de template wordt geplaatst. Wellicht iets duidelijker zo:

String exploitValue = "${jndi:ldap://127.0.0.1:5555/exploit}"

logger.error("msg: " + exploitValue); // user-input in template
logger.error("msg: {}", exploitValue); // geen user-input in template

Beide varianten zijn kwetsbaar.

[riven4096]

Voer de code maar uit, dan zie je dat het mis gaat. Dit is zo eenvoudig te reproduceren, dat een citation wat overbodig lijkt, maar ik doe de moeite graag, zie comments in dit log4j2 jira-ticket, waar men het ook reproduceert:
https://issues.apache.org...tabpanel#comment-17457333

yes, unfortunately the lookup is performed after formatting the message, which includes the user input. Hence the vulnerability can still be triggered using a ParametrizedMessage:

En kun je volgende keer niet direct op de man spelen? Dat wordt gewaardeerd

Dan heb jij het, zoals honderden Java applicaties, niet begrepen.

[R4gnax]

Ik heb hier lokaal geen Java staan; dus even reproduceren is er dan niet zo makkelijk bij.

En holy shit: expansie van specifiek jdni tokens vindt dus inderdaad plaats nadat de log message al geformatteerd is. Wow. Wie heeft daar dan liggen slapen?! Dat is inderdaad super-gevaarlijk.

[EDIT]
En als ik de merge van de PR op Github er even op napluis die deze exploit zou moeten verhelpen, dan hebben ze dat aspect dus daadwerkelijk niet gefixed ook niet. Enige wat er toe gevoegd is, is een expliciete allow-list voor jdni lookups.

Droef...

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:56]

[aikebah]

Ik heb hier lokaal geen Java staan; dus even reproduceren is er dan niet zo makkelijk bij.

En holy shit: expansie van specifiek jdni tokens vindt dus inderdaad plaats nadat de log message al geformatteerd is. Wow. Wie heeft daar dan liggen slapen?! Dat is inderdaad super-gevaarlijk.

[EDIT]
En als ik de merge van de PR op Github er even op napluis die deze exploit zou moeten verhelpen, dan hebben ze dat aspect dus daadwerkelijk niet gefixed ook niet. Enige wat er toe gevoegd is, is een expliciete allow-list voor jdni lookups.

Droef...

De parameterised log actie is dan ook gewoon een string-pattern met simpele placeholders. Daar komt dus totaal geen lookup handling bij kijken. Ieder string-argument wordt verbatim ingeplakt, ieder ander argument de toString() waarde.
De parameterised log actie is een heel ander iets dan een parameterised query.
Is sinds jaar en dag enkel een makkelijke manier om geen oneindige string concatenatie te hoeven doen om de logmessage samen te stellen.

En de fix die ze gedaan hebben is om die 'advanced lookup macro' mogelijkheid niet langer aan te hebben staan by default - de minder verstandige programmeur / beheerder moet die nu zelf opt-in aanzetten met een %m{lookups} in het pattern ipv het oude gedrag dat ze hem uit moeten zetten met een %m{nolookups}.

Daarnaast hebben ze restricties ingebouwd in de constructies die nog geaccepteerd worden voor jndi lookups om die minder verstandige programmeur/beheerder een beetje tegen zichzelf in bescherming te nemen.

Naar mijn idee is het feitelijke bewust gebruik van de lookup functionaliteit in de log-message minimaal (lookup funtionaliteit in de log pattern layout - op basis van interne trusted data - wordt wel breder gebruikt, maar die zoekt dus niet iets op op basis van de log message, maar op basis van door de beheerder in het log-pattern gedeclareerde lookups)

[ACM]

Vervolgens hoeft er maar één applicatie geschreven te zijn die user input niet als replacer waarde mee stuurt, maar direct als de message template -- en die zijn er maar genoeg; dat is dan ook waarom quality-control systemen als Sonar je moet vertellen dat niet te doen... -- en de rapen zijn gaar.

Zeker dmv concats zal dat idd vast wel vaak voorkomen.

Dit is gewoon SQL injection, maar dan via log4j.

Nouja, net zo'n soort "injection attack", maar niet daadwerkelijk dat. Uiteindelijk is het feit dat je remote code kunt uitvoeren zelfs nog wat erger.

[Erwin1967]

Hoe kan een log functionaliteit nog iets gaan doen met data die hij krijgt om te loggen. Code downloaden en daarna onbedoeld uitvoeren? Ik noem dat een major design flaw of gewoon ontzettend dom van de ontwikkelaar. Tegelijkertijd draait Apache zeker ook nog onder het root account?

[Snow_King]

Log4j is een library die in een andere applicatie draait.

Of die onder root draait is helemaal afhankelijk van de applicatie waar log4j in draait.

[SanSnoopy]

Externe logs verwerken e.d.? Dit is maar gewoon input en output, net zoals er vroeger SQL-injections bestonden (alsof die trouwens nooit meer voorkomen), kan en kon hier iets mislopen. En op Windows kan dit gehijackte proces dan zomaar andere dingen beginnen doen. Foutloze code bestaat niet he

[ACM]

De Apache webserver-software heeft niets met deze log4j-bibliotheek te maken. De Apache-organisatie (die ook verantwoordelijk is voor Apache HTTPD) faciliteert deze bibliotheek en verbindt er daardoor haar naam aan.

[Cyb]

Aan de andere kant kan de Apache webserver Tomcat er wel weer wat mee te maken hebben Maar die gebruikt standaard Commons Logging (toevallig ook van Apache) i.p.v. Log4j, maar de webapps die er op draaien kunnen wel Log4j bevatten, en dus de hele Apache (Tomcat in dit geval) webserver potentieel kwetsbaar maken.

[Reactie gewijzigd door Cyb op 23 juli 2024 03:56]

[Erwin1967]

Dat kan best zo zijn maar de functionaliteit om externe code op te halen moet er gewoon niet inzitten. Ik kan me niet voorstellen dat de Apache webserver geen gebruikmaakt van deze log4j bibliotheek en als deze daadwerkelijk onder root draait, omdat het inderdaad zo lekker makkelijk is met de benodigde rechten, zijn de rapen gaar. Gewoon stom is het enige wat ik kan bedenken.

[ACM]

Zie de opmerking van @Cyb met betrekking tot de Apache Tomcat server.

Maar de Apache HTTPD is niet in Java geschreven en kan dus per definitie geen gebruik maken van deze java-bibliotheek. Ze gebruiken in Apache HTTPD voor logging overigens geen bibliotheek, maar een implementatie specifiek die software.

Apache HTTPD (of Tomcat of ...) als root draaien is al vele jaren een bad practice die niet standaard als zodanig geinstalleerd kan worden (dus dat moet je zelf zo instellen na installatie).

[downtime]

Log4j is een product van de Apache Foundation. Het heeft verder niks te maken met de Apache webserver. En er is geen enkele reden om een webserver onder een root account te draaien want dat is gewoon niet nodig. Maar er zullen natuurlijk altijd beheerders zijn die het toch doen want dat is lekker makkelijk.

[Lapa]

Ja natuurlijk is dit een major design flaw in Log4J, daarom is dit zo'n groot probleem: weinig mensen hadden verwacht dat dit zo werkt.

De fout is overigens niet dat deze functie er in zit, daar zijn zeker wel use-cases voor. De fout is dat het default aan stond, terwijl misschien 1% van de systemen met Log4J dit nodig hebben/gebruiken. En de ontwikkelaars van die andere 99% zich dus helemaal niet realiseerden dat dit kan en misbruikt kon worden.

[Reactie gewijzigd door Lapa op 23 juli 2024 03:56]

[koelpasta]

Hoe kan een log functionaliteit nog iets gaan doen met data die hij krijgt om te loggen.

Wat jij 'krijgen van data' noemt is gewoon een vorm van 'iets doen met de data'.

[koelpasta]

Ik begrijp niet hoe een logging systeem die geacht wordt alleen maar data op te slaan malafide code kan uitvoeren.

Afhankelijk van de kwetsbaarheid kan je een willekeurig stuk code alles laten doen wat je wilt. De kwetsbaarheid zorgt ervoor dat je controle krijgt over de uitvoer van die code en het programma kan afbuigen naar je eigen code. De gehackte software hoeft verder niks te kunnen behalve jou de gelegenheid geven de flow af te buigen.

[roberttttt]

Ja wel, maar blijft een feit dat codes alleen maar uitgevoerd kunnen worden als ze "in uitvoeringsmode" zitten. Als data alleen ontvangen wordt en vervolgens opgeslagen kan er niets "verkeerds' gebeuren, wat er ook aan slechte code in zit.
Een mogelijkheid is dat als data executable code bevat en die data op een plek gezet wordt in het geheugen waar het programma naar toegaat in de veronderstelling dat daar de "goede" executable code staat, dan kan er dus malware uitgevoerd worden. Maar bij logging wordt normaal gesproken de data opgeslagen waar geen executable code verwacht mag worden in het geheugen om uiteindelijk in een database te belanden.
Dus dat kan het niet zijn, tenzij de makers hoogst onverantwoordelijke types zijn die dat wel hebben gedaan. In elk beroep vindt je tenslotte mensen die daar niet thuis horen.

[koelpasta]

Ja wel, maar blijft een feit dat codes alleen maar uitgevoerd kunnen worden als ze "in uitvoeringsmode" zitten.

Hmm, zo werkt een computer niet en ook hacken werkt niet op die manier.
En praat alsjeblieft niet over 'codes'. Dat klinkt zo 'Rian Rijbroek'.

Een mogelijkheid is dat als data executable code bevat en die data op een plek gezet wordt in het geheugen waar het programma naar toegaat in de veronderstelling dat daar de "goede" executable code staat, dan kan er dus malware uitgevoerd worden.

Als je data als code wilt laten uitvoeren dan gebruik je bijvoorbeeld een buffer overrun. Bij zo een kwetsbaarheid overschrijf je letterlijk een stuk van het programma. Het programma heeft niks door. Een programma veronderstelt verder ook niks wat dat betreft, in ieder geval niet automatisch. Het voert gewoon dom de commando's uit die op zn pad komen. Als het pad dan 'off grid' gaat (dus buiten wat jij 'goede' code noemt) dan heeftie dat helemaal niet door tenzij je buiten een voor het rpogramma gereserveerd stuk geheugen gaat. Maar bij een buffer overflow ga je daar meestal niet buiten.

Maar bij logging wordt normaal gesproken de data opgeslagen waar geen executable code verwacht mag worden in het geheugen

Zelfrs als we dat aannemen (wat in de praktijk vaak niet het geval is) dan nog wordt het door het programma verwerkt via geheugen dat dicht op het programma zit. Die data komt niet magisch vanzelf in dat beschermde geheugen terecht. Een stuk code moet dat daarheen verplaatsen en vaak worden er nog operaties gedaan op de binnenkomende data. De data gaat dus door meerdere buffers heen voordat het op zn lokatie terechtkomt.
En als je dan bijvoorbeeld de data die je erin stopt verkeerd formateert dan kan je met die data een stuk programma overschrijven. Dat heet dan een buffer overflow. Met wat uitzoekwerk kan je dan op een plek waar het programma van zichzelf al een keer langskomt je eigen code zetten die vervolgens dus uitgevoerd wordt alsof het onderdeel maakt van het originele programma.
.

Maar bij logging wordt normaal gesproken de data opgeslagen waar geen executable code verwacht mag worden in het geheugen om uiteindelijk in een database te belanden.

Je slaat een hoop stappen over. Er is nog een heel stuk waarbij de data ingevoerd wordt. Het logging programma haalt ergens zn brokjes logging info van daan, neemt die brokjes 1 voor 1 op in buffers waar het iets mee kan (bijvoorbeeld formateren voor de database of checken of er geen rare leestekens in staan) en schrijft die buffers weg naar bijvoorbeeld een database. En de exploit vindt dan plaats op die buffers en niet op de data in de database.

[johan223]

Voor mij als leek: dit klinkt met name als een probleem voor servers en bedrijven etc. Maar hoe kwetsbaar is de gemiddelde burger hierdoor (met een windows pc en eventueel een NAS of zo)?

[rjd22]

Dit is zeker wel een groter probleem ook voor consumenten.

Voor degenen die Ubiquity Unifi draaien ga als de wiedeweer je controller updaten deze is namelijk ook exploitbaar:

https://community.ui.com/...bb-4979-8b10-99db36ddabe1

Ook via de access points is de exploit uit te voeren, zo ver ik weet.

[Reactie gewijzigd door rjd22 op 23 juli 2024 03:56]

[psy]

Een groter probleem?
Ik zie niet in hoe dit een risico is als je Unifi Controller alleen in je LAN te bereiken is. Wat mis ik hier?

[Sleepkever]

Als je Unifi controller inderdaad van alleen maar binnen je LAN te bereiken is ben je al relatief veilig. Echter is het pad om toegang tot je netwerk krijgen wel vele malen makkelijker. Als je nu dus in je netwerk een besmette website opent die http requests afvuurt op het hele internet netwerk hebben ze daarna dus gewoon volledig controle tot de machine / vm / container waar de unifi controller op draait.

Nu is dit risico al wel een stukje minder mits de java versie die onder de unifi controller zit enigszins bij is (groter dan 1.8_191), maar updaten kan sowieso geen kwaad.

[sOid]

Als je nu dus in je netwerk een besmette website opent die http requests afvuurt op het hele internet netwerk...

Kán dat? En hoe veilig is zo'n docker container dan eigenlijk? Want dat is ook nog een extra beveiligingslaag, toch?

[Sleepkever]

Waarom zou dat niet kunnen? Die unifi controllers zijn kwetsbaar op een vaste URL, internet netwerken hebben vaak vaste ranges. Koud kunstje om alles van 192.168.1.1 tot 192.168.1.255 in een loopje af te gaan op de juiste URL's en poorten met een stukje javascript. Moet de website in kwestie dat wel aangeven in de headers dat hij dat mag maar als die website onder controle staat van de kwaadwillende kan dat gewoon. Het request hoeft niet eens behandeld te worden door unifi, als er maar gelogd wordt ben je eigenlijk al kwetsbaar.

Docker kan voorkomen dat mensen naar je host machine komen, de virussen/botnet processen komen dan in de docker container te draaien maar dat kan natuurlijk net zo slecht zijn.

[sOid]

Misschien zeg ik domme dingen hoor, maar ik begrijp het graag. Dus dank voor je uitleg

Mijn Unifi controller draai ik dus via een docker container en die is verder ook niet bereikbaar vanaf het internet, alleen LAN. Hoe kan iemand dan zo'n code uitvoeren op een machine die niet bereikbaar is? Als ik jou goed begrijp, is het dus mogelijk om via JavScript in browser (als ik kwaadwillende website bezoek) de LAN-adressen te scannen om zodoende achter het IP (en poort) van de Unifi-controller te komen. Klopt dat?

Voordeel van docker is dat je een eventueel geïnfecteerde container natuurlijk ook gemakkelijk kan verwijderen en opnieuw opbouwen met een nieuwe versie (net voor de zekerheid alvast een upgrade van de container gedaan).

[Sleepkever]

Als ik jou goed begrijp, is het dus mogelijk om via JavScript in browser (als ik kwaadwillende website bezoek) de LAN-adressen te scannen om zodoende achter het IP (en poort) van de Unifi-controller te komen. Klopt dat?

Correct, als het adres maar tussen een van de duizenden zat die aangeroepen wordt is het eigenlijk al raak. Je kan dus eigenlijk requests doen zonder op antwoord te wachten en daarom kan dat ook best snel achter elkaar.
Bij deze kwetsbaarheid is het namelijk genoeg dat de invoer gelogged word ergens in een bestand en daarna gaat de unifi controller applicatie zelf naar buiten de exploit ophalen.

[sOid]

Helder. Intrigerend wel, wist niet dat dit mogelijk was. De impact van deze kwetsbaarheid wordt me nu wel duidelijker!

[psy]

Duidelijk, thanks

[rjd22]

Unifi logd ook je traffic en andere dingen die op je netwerk gebeuren. Kans bestaat dat dit ook met log4j gedaan wordt wat dus betekent dat het lek misschien zelfs van buitenaf geëxploiteerd kan worden.

Dit is natuurlijk nog niet bevestigd maar ik zou zeker niet wachten met updaten.

[GekkePrutser]

Unifi logt ook de namen van de access points om je heen dus wellicht zou het zelfs op die manier geinjecteerd kunnen worden! Al is het natuurlijk inderdaad de vraag of die info ook door log4j komt, en bovendien of een SSID lang genoeg kan zijn (edit: Met een kort genoege domeinnaam zo te zien wel)

Maar ik heb ook maar gelijk geupdate.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 03:56]

[psy]

Alles al weer geupdate. Bedankt in ieder geval.

[GertJan2012]

Betekent dit dat als je je Network Application hebt ge-update naar versie 6.5.54 hebt het goed is?

[Reactie gewijzigd door GertJan2012 op 23 juli 2024 03:56]

[GekkePrutser]

Ja dit is de gepatchte versie.

[florisvdk]

De accespoints zijn niet vatbaar voor dit. deze draaien geen java app.

[rjd22]

Ze zijn niet perse zelf vatbaar maar kunnen gebruikt worden om de exploitatie uit te voeren in je Unifi controller van wat ik gelezen hebt.

Unifi logt enorm veel dus het kan dat stimuli van buitenaf gelogd worden zoals access point namen of ap connectie verzoeken. Natuurlijk is dit theorie maar ik zou er niet op wachten totdat iemand deze bewezen heeft.

[david-v]

Waar lees je dat de AP's ook kwestbaar zijn? voor zover ik kan lezen gaat het alleen om de controller software. Ik heb de sofware van de Unifi Network Application al geupdate, dat is zeker wel een must

[rjd22]

Zie mijn reactie hierboven. Niet de ap's zelf maar de ap's kunnen een entry point zijn doordat gebeurtenissen op de ap zoals connectie verzoeken en ssid's gelogd kunnen worden.

[Reactie gewijzigd door rjd22 op 23 juli 2024 03:56]

[david-v]

Ah ok, als entry point voor de controller. Maar als de controller gepatched is, dan is het geregeld lijkt mij. Er komt in ieder geval geen patch voor de APs, dat bedoelde ik meer.

[pmeter]

@rjd22
Dank voor de tip over Ubiquity Unifi updates. Even voor mijn begrip. Want ik weet niet goed wat je bedoelt met het updaten van de 'controller'.

Ik heb de Windows software geupdated naar "UniFi Network Application 6.5.54 for Windows". Die kwam uit op 11 december 2021. Heb ik door het installeren van de 'application' ook een 'controller' op mijn Windows pc die ik nog afzonderlijk moet updaten? Als ik in het start menu zoek heb ik geen 'UniFi controller' die ik kan opstarten. Ik kan de controller update afzonderlijk downloaden, maar ik weet dus niet of ik überhaupt een controller geïnstalleerd heb.

Mijn accesspoints heb ik geupdated naar "UniFi firmware 5.43.52 for UAP-AC-Lite/LR/Pro/M/M-PRO/IW". Maar die dateert nog van 18 november 2021. Zit hier mogelijk nog een log4j lek in? Of zat die lek alleen in de Windows software?

[Reactie gewijzigd door pmeter op 23 juli 2024 03:56]

[rjd22]

@pmeter Het lek zit alleen in de UniFi Network Application dus wanneer je deze gepatched hebt zit je goed.

Wat ik bedoelde is dat het heel goed mogelijk is dat de exploit in je UniFi Network Application uitgevoerd kon worden door op een bepaalde manier contact te maken met je AP. De firmware op de AP zelf is zo ver ik weet gewoon veilig aangezien deze niet zelf log4j draait.

[pmeter]

Ah dank!

Inmiddels begrijp ik dat "Unifi Network Application" de nieuwe naam is van "UniFi Network Controller". Vandaar mijn verwarring.

En goed om te weten dat in de firmware waarschijnlijk geen probleem zit.

[maartenyh]

Kwetsbaar.
Als jij een apparaat op internet beschikbaar hebt en je draait bijv een Minecraft server, dan kan een persoon jouw ip vinden, scannen, met geluk zelfs zien wat jij voor software draait, en een download triggered in de service die kwetsbaar is. De download kan dan ook uitgevoerd worden (met de rechten van de user die de service draait) en ben je deel van een botnet of kan je bitcoin gaan minen.

De laatste twee voorbeelden zie ik zo snel terug, wie weet wat nog meer mogelijk is.
Het eerste voorbeeld is de eerste van velen

Update; Mijn eerste reactie bevatte foutief dat Apache HTTP ook kwetsbaar zou zijn maar dat is niet het geval. Andere Tweakers die hier meer verstand van hebben geven aan dat alleen Java applicaties kwetsbaar KUNNEN zijn. Voor de kwetsbaarheid moet de app eerst Apache Log4j hebben ingeschakeld. Ik ga even een kop koffie halen want die heb ik blijkbaar nodig

[Reactie gewijzigd door maartenyh op 23 juli 2024 03:56]

[DJMaze]

of een oude versie van Apache voor een kleine website

Apache HTTPD != Apache Log4j

Log4j is een Java applicatie en die kan je net zo goed op Windows OS gebruiken.
Het gaat er dus om:
* Gebruik je Java?
* Ja => Gebruik je Log4j?

[maartenyh]

Bedankt, aangepast!!

[carlpls]

of een oude versie van Apache voor een kleine website

Mag ik vragen waar je dit op baseert? Ik heb dit op verschillende plekken voorbij zien komen afgelopen weekend maar bij mijn weten maakt de Apache webserver geen gebruik van log4j, deze is overigens ook niet geschreven in Java. Zie o.a. ook de link met lijst van vatbare applicaties van het NCSC waar de Apache webserver ontbreekt (of ik lees ergens overheen).

[thePiett]

Zie ook thePiett in 'nieuws: Duitsland waarschuwt met code rood voor uitval diensten ...

[Reactie gewijzigd door thePiett op 23 juli 2024 03:56]

[cariolive23]

Wat heeft Apache Webserver hier meer te maken? Voor zover ik weet, draait daar geen Java op, noch log4j

[thePiett]

Inderdaad. Apache HTTP server is geschreven in C, niet in Java. Zie ook https://github.com/NCSC-NL/log4shell/tree/main/software .

[demianmonteverd]

Het gaat volgens het artikel om producten van Apache. Dus de projecten onder de vlag van Apache. En daar zijn er zeer veel van, vandaar de waarschuwing.

[maartenyh]

Bedankt, aangepast!

[Jay-v]

Wellicht bedoeld hij Apache Tomcat. Dat draait op heel veel devices, vaak met log4j.

[Sleepkever]

De webserver van Apache, Apache httpd, is gelukkig niet kwetsbaar, die is ook niet op Java gebaseerd. Minecraft is zeker een goed voorbeeld en alle andere java gebaseerde software is zeker verdacht.

[tmfh]

Draai je java op je nas? Is je nas van buitenaf benaderbaar? Doe dan een check of je ergens log4j gebruikt.

[Cyb]

Alle systemen die de getroffen versies van Log4j gebruiken, zijn potentieel kwetsbaar. Zelfs indien deze niet van buitenaf benaderbaar is. Client software kan immers ook Log4j gebruiken, en extern verkregen data loggen. Om daadwerkelijk te bepalen of client software kwetsbaar is indien een kwetsbare versie gebruikt wordt, zal je source code in moeten duiken.

Dat maakt de impact van deze exploit ook zo groot. Zelfs een ver weggestopt backend systeem dat al jaren probleemloos draait, kan potentieel kwetsbaar zijn.

[Reactie gewijzigd door Cyb op 23 juli 2024 03:56]

[Oliekoets]

Vrijwel niet, maar de hobbyist die zelf op een raspberry-pi een website draait, die moet wel ontzettend oppassen als daar java-apps in zitten.

[[Yellow]]

Als je als hobbyist een Minecraft server of Ubiquiti Unifi server draait ben je vatbaar voor deze hack. Patchen of workaround dus.

Zie ook mijn reaktie in https://tweakers.net/nieu...ction=16927348#r_16927348

[Reactie gewijzigd door [Yellow] op 23 juli 2024 03:56]

[Joey-94]

Als je een minecraft server huurt bent je dan ook nog kwetsbaar?

[FreshMaker]

Als je een minecraft server huurt bent je dan ook nog kwetsbaar?

Ja, alleen is de impact minder groot.
Tenzij je de server OOK als dataopslag voor je eigen backups gebruikt.

[Skyclad]

Jij waarschijnlijk niet, maar het bedrijf waar je het huurt wel.

[jnz]

Dan is de host-dienst kwetsbaar. Jij niet (direct)

[init6]

De eerste foto's zag ik al op Linkedin met Tesla dashboard die een java logo lieten zien. Ik weet alleen niet in hoeverre Tesla het display systeem geisoleeerd heeft van basis functionaliteit. Toen we een paar jaar geleden bezig waren met de Tesla van de zaak om de API te benaderen, hebben we een paar keer de hoorn laten afgaan en vonden het vreemd dat we niets hoorden vanaf de parkeerplaats. Wat we niet wisten was dat een manager op dat moment rond reed. Volgens mij kan je best veel functionaliteit gebruiken vanuit de console, het is naar mijn idee dus niet echt het entertainment systeem wat je alleen maar hacked. Het blijft alleen een systeem waar je expliciet toegang tot moet hebben. Bij de API kom je niet zomaar gezien die beveiligd is met 2FA en volgens mij Catcha of je moet directe toegang tot de dashboard hebben.

[Reactie gewijzigd door init6 op 23 juli 2024 03:56]

[OkselFris]

Wat een puinhoop weer, vooral om uit te zoeken wat wel en wat niet vulnerable is.
Zoals ik het nu begrijp is log4j versie 1 niet vulnerable maar gaat het om Log4j 2.0 - 2.14.*

[wildhagen]

Klopt. We zijn ook al de hele dag aan het inventariseren.

Hier is een powershell-script dat op de hele omgevng kijkt of je bestanden hebt staan die voldoen aan het filter *log4j-*.jar, je moet dan nog wel even verder beoordelen of het versie 1.x (en dus niet kwetsbaar) of 2.x <2.0.15 (en dus kwetsbaar) is: https://github.com/devote...blob/main/check-log4j.ps1

[Cyb]

Het gaat dacht ik alleen om de core. De API is onschuldig. Dus als je zoekt op "*log4j-*.jar", dan kan je ook per ongeluk ongeschuldige artifacten verwijderen als bijvoorbeeld log4j-over-slf4j.

[wildhagen]

Je moet uiteraard niet zomaar klakkeloos dingen verwijderen.

Wij gebruiken het om te identificeren waar we sowieso iets van Log4J hebben staan. Aan de hand van de bevindingen gaan we dan kijken of er actie ondernomen moet worden (mitigation danwel fix) of niet (te oude versie, of niet de juiste componenten etc),

Het script is dus een hulpmiddel om (relatief) snel je omgeving te inventariseren.

[OkselFris]

Top, had ook een ander script gezien. alleen een 1500 servers checken met een standalone script is niet altijd even simpel, al doen we het soms wel. ik ben nu maar in Defender ATP met wat scripts naar bovenhalen waar Log4j wordt aangeroepen. In ieder geval intussen het één en ander gevonden. Langzaam wordt het wat duidelijker wat vulnerable is en wat niet. Sommige berichten, ook van leveranciers zijn niet altijd even duidelijk. Tot nu toe zie ik toch veel apps welke nog van versie 1 gebruik maken.

[kwiebus]

Log4j kan toch ook genest zijn, dan levert het zoeken naar *log4j-*.jar lijkt mij niet alles op?

Het lijkt mij dat je dan beter deze kunt gebruiken:https://github.com/mergebase/log4j-detector
Die kijkt ook meteen of de versie vulnerable is.

Een scan kan dan bijvoorbeeld het volgende opleveren:

e:\logserver\logstash_752\vendor\bundle\jruby\2.5.0\gems\logstash-input-tcp-6.0.3-java\vendor\jar-dependencies\org\logstash\inputs\logstash-input-tcp\6.0.3\logstash-input-tcp-6.0.3.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_

[Reactie gewijzigd door kwiebus op 23 juli 2024 03:56]

[gaskabouter]

Gewoon een oprechte vraag maar dit is een open source tool; dat maakt het misschien makkelijker dit soort exploits te bedenken? En op te lossen misschien?

[FreshMaker]

Gewoon een oprechte vraag maar dit is een open source tool; dat maakt het misschien makkelijker dit soort exploits te bedenken? En op te lossen misschien?

Dat niet alleen, maar een belangrijk leermoment is ook, dat OOK open source niet heilig is.

Hoe vaak je niet tegenkomt "ik gebruik OS want veiliger" zonder dat men ooit de code maar in gaat kijken, OF het ook zo is

[Anoniem: 1322]

Dat niet alleen, maar een belangrijk leermoment is ook, dat OOK open source niet heilig is.
Iedereen die met open-source software werkt, weet dat open-source ook niet fantastisch is. Uiteraard is dat afhankelijk van de software maar is zijn veel dingen waar je je aan kan storen (afwezigheid van documentatie is meestal mijn ergernis). Ik ken niemand die van open-source software zegt dat het 'heilig' is.

Ik denk wel dat het de beste manier is voor velen om software te ontwikkelen (zeker voor overheden). De hoeveelheid innovatie die het geeft is ongekend. Dus ik denk dat je 'heilig' verhaal daar vandaag komt, het idee is heilig, maar de uitvoering meestal niet.

Hoe vaak je niet tegenkomt "ik gebruik OS want veiliger"
Ik zie ook helemaal niemand die dat aangeeft, was dat niet alleen vroeger? Zou ook erg raar zijn. Theoretisch zou je wel kunnen zeggen dat een OS anders dan Windows gebruiken, je een minder groot doelwit maakt. Gezien de meeste virussen ontwikkeld worden voor het meest gebruikte OS.

zonder dat men ooit de code maar in gaat kijken, OF het ook zo is
Überhaupt kun je dan 100% van de comments afschrijven gezien code begrijpen van een OS zo complex en veel is, dat dit volledig onmogelijk is. Mensen 'schrijven' ook maar een klein stuk code, zo weet iemand die aan kernel werkt niet of een stuk van de GUI veilig is. Ook bij Microsoft met gesloten code weet men dat niet...

[Reactie gewijzigd door Anoniem: 1322 op 23 juli 2024 03:56]

[keigezellig123]

Je kunt beter zeggen software is niet heilig, of het nu closed source of open source is. Software ontwikkeling is en blijft mensenwerk en er kunnen altijd bugs/design flaws ontstaan. Ik denk wel dat er bij open source eerder aan de bel wordt getrokken (zeker als het een project met een grote community is)

[moredruid]

Theoretisch zou je wel kunnen zeggen dat een OS anders dan Windows gebruiken, je een minder groot doelwit maakt. Gezien de meeste virussen ontwikkeld worden voor het meest gebruikte OS.

Linux(-gebaseerde) software heeft met (enorme) afstand de grootste install base. Denk aan consumenten hardware zoals routers, IoT-devices (slimme koelkasten, thermostaten, deurbellen, ovens, vaatwassers), NAS-sen, Raspberry Pi's, IP camera's en het hele ecosysteem van Android telefoons. Je ziet nu ook steeds meer exploits hiervoor omdat fabrikanten om te beginnen al oude kernels gebruiken EN hun spul niet lang patchen (routers en IP camera's zijn hier beruchte voorbeelden van) tenzij er een abonnement aan hangt.

[McNutters]

over dat belangrijke leermoment gesproken, las op ars dat er in 1996 een boek is geschreven waarin dit soort foutpatronen al beschreven staan.

ben zelf geen programmeur, toch begrijp ik wel dat random user input proberen te interpreteren problemen op kan leveren. Als ik dit al snap, bedenk dan eens wat iemand met verstand van zaken met deze kennis kan...

[dcm360]

[...]
Hoe vaak je niet tegenkomt "ik gebruik OS want veiliger" zonder dat men ooit de code maar in gaat kijken, OF het ook zo is

Eigenlijk kom ik het alleen tegen in posts als die van jou, waarin gesteld wordt dat het vaak als reden genoemd wordt. Onderhand is wel bekend dat alle software veiligheidsproblemen kan hebben, en dat open of closed source daar weinig mee te maken heeft.

[FreshMaker]

Fijn, op de man spelen ... good job !

Maar dit komt over alle platformen voor, kijk de passwordmanagerposts maar eens door, waar open source wordt geprefereerd.
Of de messengers, waar Whatsapp wordt afgeschoten ( naast een Meta connectie )

[dcm360]

Het was zeker niet persoonlijk bedoeld, maar ik kom dergelijke opmerkingen daadwerkelijk alleen tegen onder berichten over veiligheidslekken. De voorbeelden die je noemt zijn naar mijn idee ook vaak discussies die zelden echt nuttig inhoudelijk worden, en ontwijk ik om die reden (als daar ook vaak open source als veiliger beschouwd wordt als argument, is het discussieniveau bij dergelijke posts blijkbaar ook dusdanig dat ik er ook wel weg kan blijven). Het ligt dus aan mijn 'bubbel' kan ik concluderen.

[LOTG]

Het is gewoon heel simpel, hoe meer mensen het gebruiken, hoe vatbaarder het is voor exploits en malware. Die trend zie je overal terug, het is immers lucratiever om de grootste groep potentiële klanten te hebben, dan voor een of ander exotisch stuk software wat misschien met ducttape aan elkaar hangt. Niet dat het niet gebeurt, maar dat valt gewoon minder op.

Dat opensource niet heilig is, daar zal niemand van op kijken die weet waar hij heet over heeft. Ook zat projecten met een brakke basis, maar dat word meestal pas een probleem als ze populair worden.

[thePiett]

Exploits worden niet "bedacht", maar ontdekt. Het is een fout in software die wordt misbruikt. Ookal is dit een open source pakket; waarschijnlijk zit deze fout er al jaren in alleen heeft niemand hem ontdekt.

[Cyb]

Ze worden ontdekt, maar je kan natuurlijk altijd een corrupte committer hebben die het van de te voren bewust bedacht heeft. (Daarmee wil ik niet suggereren dat dat bij Log4j gebeurd is.)

waarschijnlijk zit deze fout er al jaren in alleen heeft niemand hem ontdekt

De fout zit er zo'n 5,5 jaar in, en was al te ontdekken met een relatief simpele message als "${jndi:}".
Er zit een verschil tussen ontdekken en publiekelijk maken. Het kan zijn dat het al een paar jaar ontdekt is, en bekend is in bepaalde kringen die daar belang bij hebben, bijv. bepaalde inlichtingendiensten.

[svennd]

vulnerabilities worden ontdekt, exploits worden weldegelijk bedacht/uitgewerkt Het probleem bij deze vulnerability is dat hij 'eenvoudig' remote te exploiten is.

[svennd]

open-source of closed-source maken weinig uit; Dit soort exploits wordt voornamelijk gevonden in populaire software, omdat daar veel onderzoek naar gedaan wordt.

Of vulnerabilities sneller of trager opgelost worden open of closed source is mogelijks voer voor discussie. Je zou verwachten dat commerciële bedrijven meer middelen hebben om dit aan te pakken, maar de realiteit is vaak anders ... zoek maar eens op Steam's reputatie hierover.

[NLxAROSA]

Bovendien ook nog eens grote kans dat veel closed source software deze library onder de motorkap heeft.

[cariolive23]

Dus de manier waarop geld wordt verdient, zegt iets over de veiligheid van de code? Leg dan eens uit waarom er zoveel virussen zijn/waren voor Windows.

Er is geen verband tussen de licentie vorm en de veiligheid van de code. De code is ontworpen door mensen en mensen maken fouten. Zo simpel is het.

[nexus64]

We zitten nu in de voorbereidende fase, pas later als die botnets worden geactiveerd wordt pas duidelijk hoe erg het is, dus het is nu zaak om terwijl de hackers het infection window aan het benutten zijn om alles te herscannen op malware / botnets VOOR die zooi wordt geactiveerd.

[FreshMaker]

Dus is het zaak om NU backups van voor 26 november veilig te stellen.
Kans is kleiner dat de pre-emptive files daar al inzitten.

Alleen heb je aan een backup van 14 november weinig, als je in feb '22 op slot gezet wordt..

[Cyb]

Ik begrijp alleen niet hoe dit onopgemerkt 5,5 jaar lang in Log4j heeft kunnen zitten. JNDI lookups is een feature van Log4j voor in message patterns. Dan moet het toch ook opvallen dat dat mogelijk ongewenst bij de message zelf ook kan gebeuren? Het loggen van een simpele message als "${jndi:}" veroorzaakt al een exception met een standaard Log4j config.

[mpol]

Omdat er maar een paar mensen enigszins hobbymatig aan deze software werken. Ondanks dat het blijkbaar vitale infrastructuur is wordt er weinig onderhoud gedaan en geen beveiligingsreview gedaan.
Dit wordt gezien als een incident en wordt ook als zodanig behandeld, maar er is een patroon, er is meer vitale infrastructuur waar weinig onderhoud gepleegd wordt. Een goed voorbeeld was openssl een aantal jaren geleden, daar wordt nu wel geld in gestoken door grote partijen.

Wat een oplossing moet zijn weet ik niet. Je kunt de grootgebruikers van deze soorten software niet verplichten de programmeurs te betalen of een security-audit verplicht te laten uitvoeren. De licenties geven veel vrijheid om de software te gebruiken zonder iets terug te hoeven doen.

[Reactie gewijzigd door mpol op 23 juli 2024 03:56]

[Cyb]

Ik zie Log4j als wel iets meer dan alleen een "hobbymatig" project, al hoewel veel projecten zo beginnen, en het in principe wel een hobby project kan zijn. Het heeft enorme bekendheid in de Java wereld. Vele enterprises gebruiken het. Er zijn dedicated boeken over geschreven. Je zou verwachten dat volledig los van de 9 auteurs van Log4j, er diverse externe partijen zouden zijn die codereviews zouden uitvoeren, en het zouden ontdekken, of dat de community het zelf ontdekt. Al hoewel ik een grote voorstander ben van open source, begrijp ik niet dat zoiets ("the single biggest, most critical vulnerability of the last decade" volgens Tenable) er zo lang in heeft kunnen zitten.

Nu is het wel zo dat Log4j 2 niet de populariteit heeft die Log4j 1 vroeger had. Op https://mvnrepository.com/popular?p=5 staat Log4j 2 op de 43ste plek, terwijl versie 1 op de 13de staat. Als Log4j 2 de populariteit van versie 1 had (of SLF4J), dan was het waarschijnlijk eerder aan het licht gekomen.

[GMig]

Ik herinner me nog toen ik aan een java-project werkte 6-7 jaren geleden en we een framework gebruikten om met XML en xslt te werken en dit was bij iets grotere bestanden pokketraag. Bleek dat er onderliggend een Eclipse OS library gebruikt werd met dat probleem. Na de (2) developers hierop gewezen te hebben kregen we een sneer terug dat ze met hun 2 al blij waren dat ze de afgesproken standaard konden implementeren, maar dat ze performantie en stabiliteit niet echt als prio zagen.
Bleek achteraf dat deze library in zowat alle Eclipse producten en afgeleiden gebruikt werd. 😕

[pruxor]

Straks eerst maar eens kijken of Trivy deze al kan vinden in onze productie images 🤞

[JoooostB]

Ja hoor, daar stond hij vrijdag ook al netjes in

[mrbullet]

Zou Log4net ook dezelfde kwetsbaarheid hebben?

[j00000st]

Dat vraag ik mij ook af. Ik kan er (gelukkig) niets over vinden.

[ThaWalrus]

Volgens iemand op StackExchange:

> That CVE does not impact the ports, only Log4j, since it requires the use of Java interfaces (and some JVM versions prevent the vulnerability from being exploited). It may be that the ports have similar vulnerabilities, but they would likely be of a substantially different nature such that we would issue a different CVE for them to help distinguish the vulnerabilities, patching, and remediation steps.

https://security.stackexchange.com/a/257883

[digital8]

Voor de geïnteresseerden hierbij de mededeling van CryptShare.

https://www.cryptshare.co...ryptshare-support/#c67572