Kwetsbaarheid in Apache Log4j 2 maakt remote code execution mogelijk
Een zeer kritieke kwetsbaarheid in de populaire open source Apache Log4j 2-library maakt remote code execution mogelijk waardoor duizenden organisaties risico lopen. Er is inmiddels een update uitgebracht om het probleem te verhelpen, maar exploitcode is ook online verschenen.
Log4j 2 is een tool voor het loggen van informatie van Java-applicaties. Zo kunnen ontwikkelaars, door de library aan hun Java-applicatie toe te voegen, bijvoorbeeld problemen met de applicatie ontdekken. Een kwetsbaarheid zorgt ervoor dat wanneer de library een bepaalde string logt een aanvaller willekeurige code kan uitvoeren en zo controle over de applicatieserver kan krijgen.
De kwetsbaarheid, aangeduid als CVE-2021-44228 en Log4Shell, raakt allerlei grote diensten zoals Steam, Apple iCloud en apps zoals Minecraft, stelt Free Wortley van securitybedrijf LunaSec. "Iedereen die van Apache Struts gebruikmaakt is waarschijnlijk kwetsbaar. We hebben misbruik van dergelijke kwetsbaarheden eerder gezien bij datalekken zoals het Equifax-datalek van 2017", merkt Wortley op.
"Er zal zeer waarschijnlijk misbruik van deze kwetsbaarheid worden gemaakt die vermoedelijk duizenden organisaties raakt. Het beveiligingslek vormt een aanzienlijk risico voor kwetsbare systemen", aldus securitybedrijf Randori. Volgens het bedrijf wordt de Log4j 2-library veel gebruikt in zakelijke Java-software. De impact is vanwege de manier waarop de software wordt ingezet lastig te bepalen. "Net als andere impactvolle kwetsbaarheden zoals Heartbleed en Shellshock denken we dat de komende weken een groeiend aantal kwetsbare producten zal worden ontdekt", zo stellen de onderzoekers van Randori.
Beheerders wordt opgeroepen om te updaten naar Apache Log4j 2 versie 2.15.0. Volgens Randori en Cloudflare is de kwetsbaarheid ook te verhelpen door de parameter "log4j2.formatMsgNoLookups" bij het starten van de Java Virtual Machine op true te zetten.
Update
Het Australische Cyber Security Centre (ACSC) meldt dat er inmiddels actief naar kwetsbare servers wordt gezocht.
Update 2
De impact van de kwetsbaarheid is op een schaal van 1 tot en met 10 met een 10 beoordeeld.
Reacties (26)
Ik krijg op https://news.ycombinator.com/item?id=29504755 het idee dat het veranderen van de parameter geen zin heeft.
Door Anoniem: Ik krijg op https://news.ycombinator.com/item?id=29504755 het idee dat het veranderen van de parameter geen zin heeft.
En dit is waarom ik nu weet dat gij geen security engineer bent
10-12-2021, 14:17 door
karma4
Als het veel in zakelijk software gebruikt wordt dan is het kansloos te vragen beheerders de betreffenden log4j te vervangen.
Het zal door de zakelijke softwarebouwer via de supply chain moeten gaan.
Met vele andere afhankelijkheden rol je maar niet zo maar een nieuw pakket van de zakelijke suite uit.
Het zal door de zakelijke softwarebouwer via de supply chain moeten gaan.
Met vele andere afhankelijkheden rol je maar niet zo maar een nieuw pakket van de zakelijke suite uit.
When shit hits the fan....
Al diverse change verzoeken binnen zien komen van software, waarin dit verwerkt zit.
Hopelijk kan alles snel genoeg aangepakt worden, en heeft iedere leverancier deze bug in zijn vizier.
Maar ik ben bang......
Al diverse change verzoeken binnen zien komen van software, waarin dit verwerkt zit.
Hopelijk kan alles snel genoeg aangepakt worden, en heeft iedere leverancier deze bug in zijn vizier.
Maar ik ben bang......
Door karma4: Als het veel in zakelijk software gebruikt wordt dan is het kansloos te vragen beheerders de betreffenden log4j te vervangen.
Het zal door de zakelijke softwarebouwer via de supply chain moeten gaan.
Met vele andere afhankelijkheden rol je maar niet zo maar een nieuw pakket van de zakelijke suite uit.
Het zal door de zakelijke softwarebouwer via de supply chain moeten gaan.
Met vele andere afhankelijkheden rol je maar niet zo maar een nieuw pakket van de zakelijke suite uit.
Precies, deze gaat nog wel wat langer ellende opleveren dan alleen de komende weken ben ik bang. ;-).
Een ernstige kwetsbaarheid in Javasoftware leidt tot grote ongerustheid bij bedrijven en technisch experts. Door het lek zijn de inlogdiensten van grote bedrijven als Apple, Google, Amazon maar ook Nu.nl momenteel kwetsbaar voor misbruik.
door Huib Modderkolk, 10 december 2021, 15:29 uur
https://www.volkskrant.nl/nieuws-achtergrond/lek-ontdekt-in-java-de-software-die-wordt-gebruikt-door-bedrijven-van-google-tot-nu-nl~baf541d5f/
Door Wrebra: Precies, deze gaat nog wel wat langer ellende opleveren dan alleen de komende weken ben ik bang. ;-).
Hoef je niet bang voor te zijn. Het is een zeer goede voorspelling, Maak je bost maar vast nat.Het is vrijwel hetzelfde scenario van de shell-shock, ofwel niets geleerd.
Open een kritisch koppelvlak moet je niet te veel, zeg maar minimale functionaliteit hebben. Zit je in een bepaald gebied dan is een fout niet zo erg, je krijgt er NIET meer rechten door dan wel je ziet NIET meer dan je al kon.
De automatische scans met de vele resultaten van codeerfouten verleggen de aandacht naar wat echte risico's zijn naar minder relevante. Daarmee geven die niet meer veiligheid maar juist minder. Denk aan standaard pentesten.
Ik lees:
Description: Apache Log4j2 <= 2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.
Typical uses of JNDI include:
- connecting a Java application to an external directory service (such as an address database or an LDAP server)
- allowing a Java Servlet to look up configuration information provided by the hosting web container
Je haalt gegevens van buiten je systeem op zet dat in de logging waarbij je een call back naar meer gegevens buiten je eigen controle laat gebeuren. Vertaald:. Code-injection toestaan.
Het goede bij dit gebeuren.
Mitigation: In releases> = 2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookupsor the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPSto true. For releases from 2.0 beta9 to 2.10.0, the mitigation is to remove the JndiLookupclass from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Dat ingrijpen en uitzetten moet wel degeljk goed te doen zijn. Het is niet iets compleet anders neerzetten.
Weer typisch een gevalletje van te veel onnodige "handige" functionaliteit inbouwen.
Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Log4Shell the ‘most critical vulnerability of the last decade’
https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell
De eerste duidelijke tekenen van de uitbuiting van het lek verschenen in Minecraft, een onlinespel dat enorm populair is bij kinderen en eigendom is van Microsoft. Microsoft zei dat het een update had uitgebracht voor Minecraft-gebruikers.
https://en.wikipedia.org/wiki/Log4j#Log4Shell_vulnerability
“The internet’s on fire right now,” said Adam Meyers, senior vice-president of intelligence at the cybersecurity firm Crowdstrike. “People are scrambling to patch”, he said, “and all kinds of people scrambling to exploit it.” He said on Friday morning that in the 12 hours since the bug’s existence was disclosed, it had been “fully weaponized”, meaning malefactors had developed and distributed tools to exploit it.
https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell
De eerste duidelijke tekenen van de uitbuiting van het lek verschenen in Minecraft, een onlinespel dat enorm populair is bij kinderen en eigendom is van Microsoft. Microsoft zei dat het een update had uitgebracht voor Minecraft-gebruikers.
https://en.wikipedia.org/wiki/Log4j#Log4Shell_vulnerability
Hoe kan ik checken of mijn servers hier ook kwetsbaar voor zijn?
Mijn servers zijn apache webservers.
Mijn servers zijn apache webservers.
Door Anoniem: Weer typisch een gevalletje van te veel onnodige "handige" functionaliteit inbouwen.
Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Het wordt nog veel erger dan dat als jouw code ook nog gebruikt, of nog erger, misbruikt wordt. De OpenBSD jongens zagen dit al lang geleden aankomen en daarom zitten zij nog steeds standaard met versie 1 ipv 2 van Apache. Dat zijn slimme gasten bij OpenBSD. Een ander alternatief voor Apache is nog altijd Hiawatha. Maar ik vrees dat het gros van alle mensen gewoon Apache2 gebruiken, gewoon omdat dat het enige is wat ze kennen.Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Door Anoniem:
door Huib Modderkolk, 10 december 2021, 15:29 uur
https://www.volkskrant.nl/nieuws-achtergrond/lek-ontdekt-in-java-de-software-die-wordt-gebruikt-door-bedrijven-van-google-tot-nu-nl~baf541d5f/
nu.nl gebruikt geen apache maar nginxEen ernstige kwetsbaarheid in Javasoftware leidt tot grote ongerustheid bij bedrijven en technisch experts. Door het lek zijn de inlogdiensten van grote bedrijven als Apple, Google, Amazon maar ook Nu.nl momenteel kwetsbaar voor misbruik.
door Huib Modderkolk, 10 december 2021, 15:29 uur
https://www.volkskrant.nl/nieuws-achtergrond/lek-ontdekt-in-java-de-software-die-wordt-gebruikt-door-bedrijven-van-google-tot-nu-nl~baf541d5f/
Door Anoniem:
Door Anoniem: Weer typisch een gevalletje van te veel onnodige "handige" functionaliteit inbouwen.
Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Het wordt nog veel erger dan dat als jouw code ook nog gebruikt, of nog erger, misbruikt wordt. De OpenBSD jongens zagen dit al lang geleden aankomen en daarom zitten zij nog steeds standaard met versie 1 ipv 2 van Apache. Dat zijn slimme gasten bij OpenBSD. Een ander alternatief voor Apache is nog altijd Hiawatha. Maar ik vrees dat het gros van alle mensen gewoon Apache2 gebruiken, gewoon omdat dat het enige is wat ze kennen.Na een tijdje zit je dan met een grote crufty library waarvan niemand nog een goed totaalbeeld heeft en wijzigingen uiteindelijk voor bugs en kwetsbaarheden zorgen.
Het ophalen van extra configuratie en code moet er helemaal niet inzitten en anders enkel optioneel.
Sinds enkele versies is het uit te schakelen, dat is al heel wat, maar voorkomen is beter dan genezen.
Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver. En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen. Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
12-12-2021, 12:20 door
karma4
Door Toje Fos: ... En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen. Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
1/ Het betreft hier gewoon open source software : Apache foundation.
Iedereen kon het zien niemand zag het. Het moet er al vele jaren fout in zitten, pas nu zag iemand iets.
2/ Leverancier die de fix niet uitrollen? Door de onderlinge afhankelijkheden zal dit niet lukken. Als je alles moet nalopen ben je maanden of jaren verder. Daarna komt als als de leverancier het uitgerold heeft dan komt de afnemer om actie te ontplooien.
Zelfde probleem van afhankelijkheden in de klantomgevingen. ALs je dat niet weet dan zit je niet in de ICT.
Aanpassen van de config naar de JVM moet snel te doen zijn als het niet te verborgen is in containers.
Dank je voor de onderbouwing van het onbegrip in gedegen ICT opbouw.
Door karma4:
1/ Het betreft hier gewoon open source software : Apache foundation.
Iedereen kon het zien niemand zag het. Het moet er al vele jaren fout in zitten, pas nu zag iemand iets.
Door Toje Fos: ... En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen. Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
1/ Het betreft hier gewoon open source software : Apache foundation.
Iedereen kon het zien niemand zag het. Het moet er al vele jaren fout in zitten, pas nu zag iemand iets.
Nou en? Omdat het open source is kan je nu zien hoe het opgepakt wordt, wat er precies wordt gedaan, heb je versiehistorie, etc. En het is natuurlijk snel opgelost.
Door karma4: 2/ Leverancier die de fix niet uitrollen? Door de onderlinge afhankelijkheden zal dit niet lukken. Als je alles moet nalopen ben je maanden of jaren verder. Daarna komt als als de leverancier het uitgerold heeft dan komt de afnemer om actie te ontplooien.
Zelfde probleem van afhankelijkheden in de klantomgevingen. ALs je dat niet weet dan zit je niet in de ICT.
Aanpassen van de config naar de JVM moet snel te doen zijn als het niet te verborgen is in containers.
Zelfde probleem van afhankelijkheden in de klantomgevingen. ALs je dat niet weet dan zit je niet in de ICT.
Aanpassen van de config naar de JVM moet snel te doen zijn als het niet te verborgen is in containers.
Gezeik van scriptkiddies die hun eigen gebrek aan grip op de situatie proberen recht te praten.
Door karma4: Dank je voor de onderbouwing van het onbegrip in gedegen ICT opbouw.
Gedegen ICT is juist waaraan ik refereer maar dat snap je blijkbaar gewoon niet. Je blijft je liever verstoppen achter de muren van propriëtaire closed source oplossingen met de bekende wat niet weet, wat niet deert instelling.
"Dit is echt heel groot", zegt Jeroen van der Ham, onderzoeker bij het NCSC. "We hebben vrijdagavond actief meldingen uitgestuurd naar de Rijksoverheid en naar vitale infrastructuur, zoals de financiële markt, spoorwegen en internetproviders."
Nieuwsuur Tech redactie
11 december 2021, 22:16 uur
https://nos.nl/nieuwsuur/artikel/2409121-cyberwaakhond-waarschuwt-voor-gevaarlijk-beveiligingslek
Er zijn mogelijkheden om misbruik te detecteren. Het cybersecurity bedrijf Northwave heeft een tool beschikbaar gesteld.
NCSC nieuwsbericht [update]
11 december 2021, 20:02 uur
https://www.ncsc.nl/actueel/nieuws/2021/december/10/ernstige-kwetsbaarheid-in-apache-log4j
Verschillende reacties hier beschrijven dat Log4Shell problematisch is. Hieronder een oplossing voor de toekomst.
Voor grote organisaties misschien een suggestie om eigen ontwikkelde software in een goed beveiligde (on premises) repository te hebben, waarvan altijd per direct het gehele applicatielandschap geheel opnieuw uitgerold kan worden.
Infrastructuur, Applicaties en Data zijn verschillende entiteiten, en moeten zo ook gescheiden behandeld worden.
Stacken is het toverwoord.
Voor grote organisaties misschien een suggestie om eigen ontwikkelde software in een goed beveiligde (on premises) repository te hebben, waarvan altijd per direct het gehele applicatielandschap geheel opnieuw uitgerold kan worden.
Infrastructuur, Applicaties en Data zijn verschillende entiteiten, en moeten zo ook gescheiden behandeld worden.
Stacken is het toverwoord.
Door Toje Fos:
Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
Het zal je verbazen hoeveel open source projecten door hobbyisten gemaakt worden. En Apache een 'professionele' applicatieserver? Worden de ontwikkelaars betaald of zijn dat ook gewoon mensen die daar in hun vrije tijd aan werken?Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen.
Ja en nee. Ja, de kwetsbaarheid in Log4j is gepatched, nee, nog lang niet alle software die daar gebruik van maakt zijn gepatched. Het probleem is dus alles behalve verholpen.Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
Lekker makkelijk he, vanuit je luie stoel de wereld die je maar half begrijpt bekritiseren.Securitybedrijven melden grootschalig misbruik van Apache Log4j-kwetsbaarheid
zondag 12 december 2021, 18:53 door Redactie
https://www.security.nl/posting/733832/Securitybedrijven+melden+grootschalig+misbruik+van+Apache+Log4j-kwetsbaarheid
Duitsland geeft code rood af wegens Log4j-lek, VS komt met patch-deadline
zondag 12 december 2021, 19:29 door Redactie
https://www.security.nl/posting/733834/Duitsland+geeft+code+rood+af+wegens+Log4j-lek%2C+VS+komt+met+patch-deadline
zondag 12 december 2021, 18:53 door Redactie
https://www.security.nl/posting/733832/Securitybedrijven+melden+grootschalig+misbruik+van+Apache+Log4j-kwetsbaarheid
Duitsland geeft code rood af wegens Log4j-lek, VS komt met patch-deadline
zondag 12 december 2021, 19:29 door Redactie
https://www.security.nl/posting/733834/Duitsland+geeft+code+rood+af+wegens+Log4j-lek%2C+VS+komt+met+patch-deadline
Door Anoniem:
Door Toje Fos:
Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
Het zal je verbazen hoeveel open source projecten door hobbyisten gemaakt worden. En Apache een 'professionele' applicatieserver? Worden de ontwikkelaars betaald of zijn dat ook gewoon mensen die daar in hun vrije tijd aan werken?Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
Schaal(baarheid) en niet in elkaar gehackt.
Door Anoniem:
Door Toje Fos: ...
En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen.
Ja en nee. Ja, de kwetsbaarheid in Log4j is gepatched, nee, nog lang niet alle software die daar gebruik van maakt zijn gepatched. Het probleem is dus alles behalve verholpen.En het beveiligingsprobleem waar we het hier over hebben zit in een Java EE bibliotheek en is al verholpen.
Zie het deel van mijn reactie hieronder. Je zal alle broncode die gebruik maakt van Log4j moeten controleren en op z'n minst opnieuw door de linker moeten halen. Duh...
Door Anoniem:
Door Toje Fos: ...
Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
Lekker makkelijk he, vanuit je luie stoel de wereld die je maar half begrijpt bekritiseren.Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
Ik begrijp het dus heel goed (zie hierboven).
13-12-2021, 19:54 door
karma4
Door Anoniem:
Log4j en zijn broertjes/zusjes is al vrij al oud. Ik geloof van rond ca 2000. https://pubs.opengroup.org/onlinepubs/009619299/toc.pdf Het is vrij ondankbaar om er in te investeren en anderen met de voordelen er vandoor zien te gaan. Dat blijft een terugkerend probleem, geen licentie dan wel afnemer vergoedingen en iets gratis en voor niets moeten doen. RedHat is niet niet gratis en voor niets.Door Toje Fos:
Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
Het zal je verbazen hoeveel open source projecten door hobbyisten gemaakt worden. En Apache een 'professionele' applicatieserver? Worden de ontwikkelaars betaald of zijn dat ook gewoon mensen die daar in hun vrije tijd aan werken?Hiawatha is een webservertje gemaakt door één of meer hobbyisten, dat kan je toch niet serieus gaan vergelijken met een professionele applicatieserver.
De fout hier lijkt echt op shell shock. Het doel is een adresnaam resolving. Waarom daar een complete shell in moet is mij een raadselen. Ja snel te coderen en er bij te zetten, dus afnemers vragen zijn blij met het werk dat minder is aan hun kant.
Dat je door het niet zelf toegang hebben tot broncode en / of een onbekwame leverancier te hebben, de fix niet snel genoeg uitgerold kan krijgen, tja, dat is nogal knullig hè? Trek er lering uit zou ik zeggen. Stelletje scriptkiddies.
Lekker makkelijk he, vanuit je luie stoel de wereld die je maar half begrijpt bekritiseren.[/quote]Er is zeker geen spraken van scriptkiddies. Log4j is overal ingezet omdat men wegens de security met de monitoring de logging eiste. Best tegenstrijdig de eisen om te monitoren tbv security zet de omgeving open als securtity-lek. kijk eens bij SPlunk Qradar. Het zijn de logconfhttps://www.security.nl/glitch/javascriptiguraties in producten naar dit soort siem war een dynamische configuratie zo handig leek. Het zijn de script kiddies die niet dat soort omgevingen begrijpen waar de verwarring vandaan komt.
13-12-2021, 19:56 door
karma4
Door Toje Fos: Zie het deel van mijn reactie hieronder. Je zal alle broncode die gebruik maakt van Log4j moeten controleren en op z'n minst opnieuw door de linker moeten halen. Duh...
..
Ik begrijp het dus heel goed (zie hierboven).
Konden ze al zo;n 20 jaar en toch zag niemand wat er mis zat ..
Ik begrijp het dus heel goed (zie hierboven).
Nee je begrijpt het echt niet waar die problemen echt vandaan komen.
..dubbel..
Door karma4:
Nee je begrijpt het echt niet waar die problemen echt vandaan komen.
Het gaat allee nu om versie 2 en alibaba xag het omdat het open source is (apache licentie) Als het closed source was geweest hadden we het nu niet geweten behalve de nsa en enkele hackers.Door Toje Fos: Zie het deel van mijn reactie hieronder. Je zal alle broncode die gebruik maakt van Log4j moeten controleren en op z'n minst opnieuw door de linker moeten halen. Duh...
..
Ik begrijp het dus heel goed (zie hierboven).
Konden ze al zo;n 20 jaar en toch zag niemand wat er mis zat ..
Ik begrijp het dus heel goed (zie hierboven).
Nee je begrijpt het echt niet waar die problemen echt vandaan komen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
