Nieuwe Log4j-kwetsbaarheid...

Kunnen inmiddels beginnen met Log4Shell Alfa, Log4Shell Beta....

Zoals altijd, als er in bepaalde software een serieus lek wordt ontdekt dan ligt deze software de eerste weken onder een vergrootglas. Vaak is de eerste fix ook niet toereikend, vaak zien we dan een pleister die later vervangen wordt door een structurele oplossing.

Volgende week weer wat te doen voor veel beheerders, maar belangrijk is dat dit enkel in "bepaalde niet-standaard configuraties" voorkomt. Een stuk minder aanvalsvectoren dus.

Log4j: the gift that keeps on giving :-)

Waarom niet gelijk door naar Log4Shell Delta en Log4Shell Omikron?

Ik zei het al, nu komt een brak stuk code onder de aandacht van de hackers en blijkt het ene na het andere probleem.
Als log4j uitgemolken is zullen de andere modules van Tomcat wel onder de aandacht komen. En dat zijn er nogal wat.

Waarschijnlijk al honderduizenden backdoors geplaatst. Gaat een hete kerst worden. Maandagochtend 27 december vele confrontaties met randsomeware.

Maar goed dat het open source is. Nu wordt het door heel veel beveiligingsmensen bekeken en gefixt. Dat gaat een stuk sneller dan bij closed source.
Dat lijkt mij niet want die code draait onder Linux niet als root maar als een gebruiker met verder weinig rechten. Onder windows weet ik niet. Ik weet wel dat veel IIS plugins gewoon met admin rechten draait.

Hoe kom je erbij dat log4j 'brakke' software zou zijn? En dat rare verhaal over andere 'modules' van Tomcat? Weet je eigenlijk wel wat log4j is (hint: het is geen 'module'). Het is echt geen gevalletje consumentensoftware in lichte consumententoepassingen, waarover we zo vaak (bijna 100% van de voorvallen) lezen op security.nl,


Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware').

Wat er in al deze scriptkiddiepaniek staat te gebeuren is dat de scriptkiddies van de echte beheerders gescheiden gaan worden.

Ook wel goed om even te constateren dat open source niet tegen houdt dat afgrijselijke blunders zoals het expanderen van macro's in extern aangeleverde data (zeg maar het kaliber SQL statements samenstellen uit form data) gewoon in een module kunnen worden ingebouwd (zat er in versie 1 niet in, is in versie 2 ingebouwd) zonder dat er mensen op de rem trappen en dat soort kolder naar de bittenbak verwijzen!

Nee, het is inderdaad geen gevalletje consumentensoftware. Het is een hobbyprojectje van zes ontwikkelaars dat door tientallen bedrijven in hun software is opgenomen omdat het handig en gratis is. Die zitten nu op de blaren. Net als die 6 hobbyisten die nu vele onbetaalde overuren moeten maken. Dat is het mooie van FOSS. Het is gratis. Maar helaas; There ain't no such thing as a free lunch.

Waren die al niet gescheiden? Ik mag hopen van wel.
Er komt echt wel wat aan https://www.bleepingcomputer.com/news/security/new-ransomware-now-being-deployed-in-log4shell-attacks/

T valt wel mee, speciale omstandigheden, 2 niet standaard configuraties en alleen op een Mac OS. Dus geen paniek mensen. Sowieso upgraden uiteraard, maar deze is niet direct dodelijk voor iedere organisatie.

Andere anoniem hier.

Ik heb zojuist de source repository gekloond om een idee te krijgen hoeveel Java-code dit eigenlijk is:

Dat zijn 296.960 regels broncode in 2.301 .java-bestanden. Ik heb steekproefsgewijs wat sources bekeken. Die zien er op het oog kort en netjes uit, al valt me op dat er buiten het licentieblok voorin elke source geen letter commentaar in staat.

Maar een kleine 300.000 regels code voor een logcomponent? Wat doet dat in vredesnaam allemaal? Logging is toch in de basis een behoorlijk simpele actie. Mijn eerste indruk is dat log4j vreselijke bloatware is, en dat het ontiegelijk veel een applicatie binnen sleept dat die applicatie vermoedelijk helemaal niet nodig heeft.

Een mogelijke reden die bij mij opkomt voor log4j om zo enorm te zijn is dat het in zo'n beetje elke denkbare omgeving in te passen is, omdat het alles ondersteunt wat je maar tegen kan komen qua logging-infrastructuur. Dan zou je hopen dat ze het het zo hebben opgezet dat alleen de onderdelen geïnstalleerd worden die ook werkelijk gebruikt worden. De kwetsbaarheden die nu aan het licht zijn gekomen doen vermoeden dat het niet zo in elkaar zit. Als dit beeld klopt zie ik dat als een ontwerpfout, die veiligheidsrisico's met zich meebrengt. Dat los je niet op met netjes programmeren maar met een wezenlijk andere opzet.

Trouwens, hoe moet een gebruiker van deze component de kwaliteit ervan beoordelen? Even in 2.300 sources met 300.000 regels code zonder verklarend commentaar overzien dat het goed zit? Ga er maar aanstaan. Het voordeel dat open source in dit opzicht kan hebben wordt zo niet waargemaakt. Ik denk dat het problematisch is als de logcomponent alleen al groter is dan de gebruikende applicatie, en ik denk dat dat vaak genoeg zal voorkomen.

Dit is geen probleem dat specifiek is voor open source, er is in het algemeen een sterke neiging om elk wiel dat al elders is uitgevonden niet zelf nog eens uit te gaan vinden, én om gaan voor componenten die geweldig veel kunnen. Maar als je kijkt hoeveel meer je dan binnenhaalt dan je nodig hebt wordt het heel twijfelachtig om zoiets in te zetten. Je haalt namelijk ook de problemen binnen die erin zitten.

Je beschrijft het probleem van een ontwerp fout. Gescheiden segmenten met niet door direct gekoppelde programmatuur doorgeven van informatie. Het is kostbaarder stelt meer technische eisen maar is wel veiliger.
De aloude keus van snel resultaat vs kwaliteit.

Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.
Randsomware lijkt me een prima woord. Random wat bij elkaar graaien, de gevolgen met een ransom. Prima aanduiding

Hier gaat de hele ransomeware industrie op duiken. Beetje naief te denken dat dit alleen iets voor scriptkiddies is.
https://www.zdnet.com/article/log4j-flaw-this-new-threat-is-going-to-affect-cybersecurity-for-a-long-time/

Dat is het doel van open source helemaal niet maar genoeg eyeballs fixen elk probleem snel omdat de source beschikbaar is. Dat is nu ook het geval en misschien gaat men inzien dat er meer eyeballs nodig zijn bij dit soort software. Zo ging het met openssl ook.

Tuurlijk. Slaap rustig verder.
https://www.bleepingcomputer.com/news/security/log4j-vulnerability-now-used-by-state-backed-hackers-access-brokers/

Wat opmerkelijk is, is dat Microsoft in een waaier van applicaties, en in hun Azure cloud, Log4j heeft gebruikt, maar dat de techreus blijkbaar nooit de moeite heeft genomen om de Log4j code eerder aan een grondige audit te onderwerpen. Men zou mogen veronderstellen dat zo'n gigant over voldoende middelen en mensen beschikt om zo'n klus zelf te klaren.

https://www.security.nl/posting/734616/Microsoft+waarschuwt+voor+Log4j-kwetsbaarheid+in+eigen+software

Daar heb je er weer een die het niet heeft begrepen. Het gaat niet om een gratis lunch of bier maar om vrijheid. Het recht om code te bestuderen (wat nu heel belangrijk is) het te mogen aanpassen (waar velen op hebben gewacht) en te copieren etc.
Daarnaast is het snel gefixt door een paar hobbyisten zoals jij het noemt. Kunnen Citrix, Microsoft (exchange en printspooler), etc nog een puntje aan zuigen. Microsoft zal deze software niet hebben opgenomen in haar producten omdat het gratis of handig was.

Ja ik slaap rustig verder. Mijn systemen worden niet versleuteld. Wat klanten zelf installeren als gebruiker moeten ze zelf weten. IK weet wel dat het Windows ecosysteem er het meest last van heeft omdat die per default closed source producten kopen waar dit in zit verwerkt zonder dat ze er weet van hebben.

Klopt. Daar heb ik al voor gewaarschuwd en het is ook logisch.
Een fout van dergelijke magnitude trekt onguur cyber-volk aan.

Ja dat is een probleem wat vaak over het hoofd gezien wordt bij het verhaaltje "iedereen kan de source bekijken".
Maar in dit geval is het eigenlijk veel ernstiger! Het is niet zo zeer een bug in de implementatie, iets wat je zou kunnen
hebben als iemand een foutje gemaakt heeft bij het programmeren, en wat je dan maar toevallig moet zien.
Nee dit is een DOMME ONTWERPFOUT VAN DE 1E ORDE.
Dit zou je in de documentatie al moeten zien. Source is hier helemaal niet voor nodig. Als er ergens in de documentatie
staat dat je op willekeurige plekken van die handige ${....} macro's mag opnemen en dat die dan vanalles kunnen doen
waaronder connecten naar externe datasources en de geretourneerde waarden op die plek invoegen, dan zouden
alle alarmbellen moeten afgaan en dit product meteen naar de "onbruikbaar, in de bittenbak" categorie moeten worden
verwezen.

Zeker ook omdat die feature in de 1e versie niet aanwezig was, en toen dit erin gedesigned werd iedereen al wist
dat het heel dom is om dit soort dingen te doen (zie bijvoorbeeld SQL injection door queries die zijn opgebouwd
op zo'n soort manier).

Nee, ik snap echt niet hoe zo iets in productie gekomen kan zijn. Ik houd me altijd ver van Java omdat ik nog nooit
de combinatie "Java - acceptabel werkend" ben tegengekomen (wel "Java - onbruikbaar traag", "Java - resource hog"
en "Java - alleen maar ellende met versies"). Maar dit soort dingen laat me weer 5 jaar alles waar Java in zit
mijden als de pest.

Het trekt ook de aandacht van een hoop cyber-volk dat op verbetering gericht is. Hun inbreng om de problemen op te sporen en te verhelpen heeft een blijvende positieve impact op de code, terwijl de activiteiten van de ongure types, ook al kunnen die aanzienlijke schade veroorzaken, van voorbijgaande aard zijn.

Ik heb overigens grote twijfels of een logcomponent van maar liefst 300.000 regels Java-sourcecode wel goed in elkaar zit, in de zin dat dat wel heel erg veel code is voor een in essentie simpele functie. Dat roept de vraag op hoeveel van de geïnstalleerde code in een specifieke operationele omgeving daadwerkelijk geraakt wordt. De volgende vraag is of de code die voor die omgeving overbodig is weggelaten kan worden uit de installatie. Ook code waarvan de bedoeling niet is dat die uitgevoerd wordt in een bepaalde omgeving kan exploiteerbare lekken opleveren. Uit security-oogpunt kan die beter niet geïnstalleerd zijn, want code die niet in je runtime beschikbaar is kan niet voor exploitatie misbruikt worden. Als het nu niet mogelijk is om de gewenste functionaliteit selectief te installeren (ik ben nog niet tegengekomen dat dat wel kan) dan zou het wel eens een enorme klus kunnen zijn om uit elkaar te trekken wat nu met elkaar verweven is.

Het doen van JNDI-lookups (de oorspronkelijke log4shell-kwetsbaarheid), omdat een string gelogd wordt die syntax voor die lookup bevat, lijkt mij een duidelijk voorbeeld van iets dat je niet eens geïnstalleerd wilt hebben als je het niet bewust gebruikt. Niet alleen zou die mogelijkheid niet default actief moeten zijn, het levert extra veiligheid op als die mogelijkheid default om te beginnen niet aanwezig is. Dergelijke mogelijkheden zet je dus bij voorkeur op als plug-ins die een gebruiker expliciet moet installeren en die in een default-installatie domweg ontbreken. Het had denk ik nooit zo'n groot probleem kunnen worden als het nu is als dat de opzet was geweest.

Je gebruikt in de automatisering altijd 'wat van een ander dat je niet begrijpt'. Van microcode tot assemblercode tot API's van het besturingssysteem tot bibliotheken bij je programmeertaal tot de compiler/interpreter van je programmeertaal, enzovoort. Jij wilt het nog eens verergeren door closed source te gebruiken zodat je er zelfs in geval van nood niet bij kan. Nou, succes daarmee.

Inderdaad dat hebben we bij de gesloten supplychain software tik gezien waardoor ook Microsoft werd gehackt.

is dit weer zo'n NSA backdoortje die er stiekem ingeslopen is?

Maar open Source was toch altijd zo veilig omdat "iedereen" er naar kan kijken en het kan controleren op fouten?
Dat is tenminste wat ik altijd lees hier als er weer eens iets met Windows software aan de hand is.

Chris

Ja, want daarom is het nu ontdekt en wordt het verholpen, door een grote hoeveelheid mensen die zich nu inzet daarvoor.