News Sonntagsfrage: Eine Woche Log4Shell, was hat das für dich bedeutet?

[Enigma]

Deswegen integriert man in die Buildpipeline einen Scanner wie SonarQube oder Veracode. Der untersucht nicht nur den eigenen Sourcecode sondern auch sämtliche Abhängigkeiten auf Schwachstellen.

Das ist (analog zu einem Virenscanner auf dem PC) nicht die richtige Lösung. Das kann ergänzend gemacht werden.

 

[Salamimander]

Horrorwoche. 2x alles patchen. Privat als auch beruflich :/. Das schwierige was das auffinden der betroffenen Systeme.

 

[Piktogramm]

Betroffen waren trotzdem nur Vergleichsweise wenige Produkte und oft dazu auch nur ältere Versionen.

Öh...
https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
1. Die Liste ist was offizielles der National Cyber Security Centrum der Niederlande
2. Die Liste ist so lang, dass Githubs Markdownrenderer nicht komplett wiedergibt (derzeit hört es irgendwo beim R auf)
3. Allerhand Einträge sind als "nicht verwundbar" gekennzeichnet, was die Liste etwas aufbläht
4. Clusterfuck

 

[Sannyboy111985]

Für mich ist das Fehlerbild "erlaube das Parsen von Logmeldungen auf JNDI-URLs" genau so ein Nicht-Feature, das sich wie ne gute Idee anhört, bis man sich überlegt, ob man sowas wirklich braucht und dann sehr schnell zu dem Ergebnis kommt, nein.

Dass zusammen mit „warum ist das standardmäßig aktiviert“ waren meine ersten Gedanken zu dem Thema, nachdem ich es verstanden habe.

Und die Menge der betroffenen Produkte gibt eine gute Indikation dafür, dass viel Software mit vielen Abhängigkeiten entwickelt wird, ohne alle Komponenten zumindest hinsichtlich ihrer Standard Optionen zu prüfen.
Best practice der security ist doch: „lass nur das laufen/angeschaltet was du auch brauchst“.

Vielleicht ist ja der ein oder andere Entwickler anwesend, der ein real live Beispiel für solche lookups hat.

 

[transfigurator]

Ich bin indirekt betroffen, weil meine Uni Teile ihrer SAP Anwendung abgeschaltet hatte, scheint aber mittlererweile wieder zu laufen.

Ich würde behaupten, dass man als Privatnutzer von dieser Lücke nicht betroffen ist. Wenn man z. B. einen Minecraft Server hat, ist man nämlich kein Privatnutzer mehr, sondern ein Serveradmin.

Oder könnte jemand die Lücke auch in meinem Minecraft Client ausnutzen, indem er mir auf dem Server auf dem ich spiele eine entsprechende Nachricht schickt?

 

[mitch-dk]

Für Firmen sollten zuerst die DMZ Systeme Prio1 sein und Systeme die nach außen reichen, vor allem mit Web oder Benutzerinteraktion..
Gibt ja vom BSI und MS und SecFirmen inzwischen genug Infos dazu, wie was wo behoben werden muss und welche Programm(teile) betroffen sind. Leider nicht von vielen "Kundenprodukten".. hier hilft halt nur hinterher telefonieren..

Der Privatbereich sollte dennoch auch geprüft werden, evtl. mit den gleichen Infos - da viele Programme hier ähnlich ticken.
Minecraft Client sollte zumindest auf v1.18.1 laufen (Mods zusätzlich überprüfen). Hier könnte es sogar ausreichen wenn jemand den Schadaufruf im Chat startet und das eigene System mit einem eingebundenen log4j das "interpretiert" um am Arsch zu sein. Ob und wie weit da Module eingebunden sind - Foren/Modseiten durchlesen.

Gibt genug Scanner die vom BSI oder MS "empfohlen" werden um zumindest betroffene Anwendungen zu lokalisieren. Entfernen ist dann wieder eine ganz andere Nummer.

Finde es schade das in DE bei solchen Lücken jeder selber sehen kann wie er klar kommt. Dafür sollte sich mal der Staat einsetzen und nicht wie man die IT Sicherheit noch weiter aufweicht..

 

[xexex]

3. Allerhand Einträge sind als "nicht verwundbar" gekennzeichnet

Eben! Die Liste ist vor allem deshalb so lang, weil das meiste davon nicht betroffen ist.

 

[Enigma]

Was schlägst du als bessere Alternative vor?

Neu-Bewertung der gesamten Entwicklungsstrategie. Das funktioniert so nicht und mit der Masse mitschwimmen bewährt sich auf lange sicht nicht. Dafür braucht man halt einen Architekt, der die Strategie vorgibt und auch mal klar die Entscheidung trifft, einen Trend wie Vue NICHT mizugehen. Das gesamte Unternehmen ist dann halt nur so gut wie der Architect, der muss gut gewählt werden.

Ich nehme als Beispiel auch gerne die gesamte JavaScript Szene. Nur weil Ihnen ein Framework wie ExtJS zu komplex war, haben Sie die letzten Jahre damit verbracht ihr eigenes Framework zu bauen. Duzende Standards wurden durchgeprügelt und ganze Generationen an Entwicklern verheizt. Dazu riesen Budgets in Frameworks wie Angular, React oder Vue in den Sand gesetzt, weil der Standard nur wenige Jahre danach obsolut ist.

Edit: Und auf größerer Ebene eine BSI-Empfehlung für Dependency Management in der Softwareentwicklung, der das Treiben der Entwickler managebar macht.

 

[xexex]

Definiere wenige Produkte. Wie selten siehst du Tomcat/Jetty/Jboss/Wildfly Webapps an?

In meinem Zuständigkeitsbereichen? Beim deutschen Mittelstand? Absolut irrelevant! Der Punkt an der Geschichte ist gewesen, es hat praktisch entweder große Dienstleister betroffen, oder Firmen die viele Open Source Produkte einsetzen.

Sicherlich für einige eine Katastrophe, für andere jedoch nicht im Ansatz ein so großes Problem wie die Exchange Server Lücke von ein paar Monaten. Man braucht sich ja nur die Microsoft Produkte anschauen die betroffen waren.

Heartbleed war mal eine große Katastrophe, die aktuelle Lücke? Geschenkt! Vor Jahren als JAVA und Apache noch omnipräsent waren, wäre es viel kritischer gewesen. Wie du schon erwähnt hast, Amazon war stark betroffen, was aber deren Problem ist, andere waren maximal mit einzelnen Diensten involviert oder gar nicht. Das ist weit entfernt von "jeder".

 

[chartmix]

Finde es schade das in DE bei solchen Lücken jeder selber sehen kann wie er klar kommt. Dafür sollte sich mal der Staat einsetzen und nicht wie man die IT Sicherheit noch weiter aufweicht

Wie sollte sich der Staat denn wofür und für wen einsetzen?

 

[Piktogramm]

[...]oder Firmen die viele Open Source Produkte einsetzen.

Also alle die nicht mehr mit Tontafeln und Keilschrift arbeiten?!

Beim deutschen Mittelstand?

Ahhh, also doch alles sicher


Ernsthaft, gerade beim deutschem Mittelstand und dem Softwaregefrickel welches da von Nischenanbietern abgeliefert wird, würde mir der Arsch auf Grundeis gehen. Die Software prüft fast keiner und ist meist ein gigantisches Flickwerk aus FOSS-Produkten bei vollständiger Ignoranz aller Lizenzbedingungen...

Ergänzung (19. Dezember 2021)

Wie sollte sich der Staat denn wofür und für wen einsetzen?

Es kochen immer mal wieder Ideen hoch, dass Deutschland bzw. die EU mit der Gießkanne über FOSS-Projekte drüber gehen könnte.
Da gab es auch sowas wie EU-FOSSA: https://ec.europa.eu/info/departments/informatics/eu-fossa-2_en

 

[foo_1337]

Sicherlich für einige eine Katastrophe, für andere jedoch nicht im Ansatz ein so großes Problem wie die Exchange Server Lücke von ein paar Monaten. Man braucht sich ja nur die Microsoft Produkte anschauen die betroffen waren.

Geniale Logik. Wir waren Null von der Exchange Geschichte betroffen. Spiele ich deshalb die Lücke runter weil ich denke, dass wir der Nabel der Welt sind? Nein.

Heartbleed war mal eine große Katastrophe, die aktuelle Lücke? Geschenkt! Vor Jahren als JAVA und Apache noch omnipräsent waren, wäre es viel kritischer gewesen.

Du checkst es nicht, oder? Es waren duzende public rechable Portale betroffen. Jeder Idiot konnte hier RCE ausführen weil die Lücke trivial auszunutzen ist. Und ich wiederhole mich gerne: Sehr viele große Portale wie z.B. iCloud, Amazon, Twitter, Linkedin etc. nutzen Tomcat & Co. Die waren alle Betroffen. Auch du hättest da Code einschleußen können. Die haben glücklicherweise schnell reagiert. Andere halt nicht, weil Sie vermutlich eine Denke haben wir du. "Och alles halb so wild..". Und Heartbleed war keine RCE, ist also nur bedingt vergleichbar.
Und zu deinem letzten Satz: Java EE ist Serverside auch heute noch omnipräsent. Nur weil sie ein bisschen Konkurrenz durch node.js gekriegt haben, hat sich das wenig geändert. Im Bankenbereich sowieso, da ist nur Paypal der große Ausreißer (wenn man die dazu zählen mag), da sie vor einigen Jahren alles nach node.js migriert haben.

Man braucht sich ja nur die Microsoft Produkte anschauen die betroffen waren.

Das ist ungefähr so wie wenn du bei OpenSSL Heartbleed damals mit dem Argument gekommen wärst, dass ja alles nicht so schlimm sei, nur weil keine Microsoft Produkte betroffen waren. Merkst du selbst, oder?

Ergänzung (19. Dezember 2021)

Wer es noch nicht gesehen hatte, bei Apple hatte auch ein Songname via iTunes gereicht

https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/internet/apple4.jpg

 

[elgorro]

Das war früher undenkbar.

Früher gabs nichtmal Qualitätssicherung. Das sowas wie Docker, ElasticSearch, Apache (,...) betroffen sind wird einfach wegdefiniert?? In Mircosoft Azure oder Google Cloud laufen zig dieser Dinger! Es gibt nen tollen Speech, den ich auf die schnelle nicht gefunden habe vom CCC zum Abhängigkeitsdilemma: Fazit, ob Quelloffen oder geschlossener Code - eine 100%ige Garantie gibt es nicht.

Damit jeder stattdessen sein eigenes Süppchen mehr schlecht als recht kochten muss und Software den dreifachen Entwicklungsaufwand hat?

Und ich glaube im Leben nicht, dass früher die Sicherheitsprüfungen mehr/besser gemacht wurden als heute.

Genau. Wenn es so unscheinbare Quelltexte in den Mainstream schaffen, dann sind definitiv nicht die OpenSource-Entwickler schuld, das daraus eine Katastrophe resultiert. Hier sind alle aufgefordert sich zu kümmern - gratis Goldesel gibts in der Realität nun mal nicht.

 

[xexex]

Geniale Logik. Wir waren Null von der Exchange Geschichte betroffen. Spiele ich deshalb die Lücke runter weil ich denke, dass wir der Nabel der Welt sind? Nein.

Du hast behauptet es wären "alle" betroffen gewesen. Ich kann dir nur sagen, dass von unseren Kunden einer betroffen war. Hier wird ja so getan, als würde jeder Hinz und Kurz auf Open Source setzen und da kann ich nur das wiedergeben was in meinem Umfeld passiert, man macht einen Bogen drum.

Wie ich schon erwähnte, war früher vieles noch stark Java verseucht. Von Sonicwall SSL, über LSI MSM, bis zu Supermicro IPMI, war alles noch Java basiert. Der Trend seit Jahren ist aber eindeutig, längst haben diese Produkte sich von Java verabschiedet.

Natürlich kann ich nur das wiedergeben was in meinem Umfeld passiert und wenn bei dir vieles auf Open Source oder Java Basis passiert, wird du die letzten Tage sicherlich anders erlebt haben als ich. Für die IT Firma in der ich arbeite, verlief die Sache jedenfalls vergleichsweise entspannt, von zig Kunden die angerufen haben und nachgefragt haben ob sie betroffen sind mal abgesehen.

 

[abilio]

Direkt betroffen war das ElasticSearch Module in Gitlab
Indirekt Salesforce, Microsoft und solche Services
Eigentlich recht unaufgeregt bei uns

 

[foo_1337]

Du hast behauptet es wären "alle" betroffen gewesen.

Ich kann dir nur nahe legen, die Postings auch richtig zu lesen. Und ich habe es dir sogar erklärt. Offensichtlich vergebene Mühe.

(...)Aber was wenn du, wie so viele, wie z.B. amazon, iCloud, twitter usw. einen servlet container hast, dessen servlets direkt log4j benutzen und direkt public reachable sind?*
(...)
* Und nein, das war kein Rant. Die waren wirklich alle betroffen. iCloud z.B. beim Login, Amazon bei der Suche ...

Siehst du das Sternchen hinter dem Fragezeichen? Und genau auf diese Aufzählung ist das Sternchen unten bezogen. Macht man üblicherweise so, wenn man den Lesefluss nicht ganz so stören möchte. Die Fußnote sollte lediglich nochmal verdeutlichen, dass die wirklich komplett ausnutzbar betroffen waren und es nicht nur eine theoretische Angriffsmöglichkeit gab.

Wie ich schon erwähnte, war früher vieles noch stark Java verseucht. Von Sonicwall SSL, über LSI MSM, bis zu Supermicro IPMI, war alles noch Java basiert. Der Trend seit Jahren ist aber eindeutig, längst haben diese Produkte sich von Java verabschiedet.

Du zählst bis auf das SSL VPN(? Fragezeichen weil ich es nicht kenne.. möglicherweise also auch nur Clientgedöns..) irgendwelches Clientgeraffel auf. Es geht hier im Serverside.. Tomcat, JBOSS, Jetty & Co. Habe ich schon mehrfach gesagt. Aber zeigt mal wieder, dass du keinerlei Einblick hast, worum es hier geht und was diese Lücke so heftig macht.

 

[AppZ]

Nein, bin für eine Software bei einem Kunden verantwortlich. Obwohl die Software auch teilweise auf Java basiert, ist diese nach ausführlicher Sicherheitsüberprüfung nicht betroffen.

 

[Blutschlumpf]

Diese paketbasierten Abhängigkeiten sind ein Schritt in die falsche Richtung. Es wird Quellcode verwendet, der nie einer Sicherheitsprüfung unterzogen wurde. Das war früher undenkbar.

Ich bezweifle ganz stark, dass du am Markt bestehen wirst wenn du alles selber schreibst.
Ganz einfach deshalb weil du dann alles 10x so teuer anbieten müsstest und das keiner zahlen wird.
Ich bezweifle auch, dass du dann weniger Lücken hast, es hat dann nur jeder andere und einzigartige Lücken.
Ob das besser ist weiß ich nicht. Das wären vielleicht weniger große "Events" wie hier, dafür dürften die individuellen Lücken deutlich kritischer sein wenn sie jemand findet weil die Wahrscheinlichkeit niedriger sein dürfte, dass die dadurch entstandenen Backdoors je gefunden werden.

Mir fehlt "keine Ahnung" als Antwort!

Das habe ich mir auch als erstes gedacht.
Ich weiß, dass auf der Arbeit Dutzende Kollegen da wer weiß wie viele Stunden versenkt haben (bei uns in der Abteilung wars überschaubar, wir haben nur bei ein paar Herstellern nachgefragt oder geschaut was die rausgegeben haben und mussten ein paar Services firewall-mäßig deaktivieren, hatten aber selber nichts zu patchen), aber ich habe zum Beispiel keine Ahnung ob und wieweit ich selber (privat) betroffen bin und ob ich dadurch z.B. jetzt Teil eines Botnetzes bin oder meine Daten in der xy-Cloud jetzt noch woanders liegen.
Im Grunde kann niemand auch nur ansatzweise seriös sagen, dass es nicht betroffen war.

Deswegen integriert man in die Buildpipeline einen Scanner wie SonarQube oder Veracode. Der untersucht nicht nur den eigenen Sourcecode sondern auch sämtliche Abhängigkeiten auf Schwachstellen.

Was checken die genau (laufen die einmal oder einmal bei Programmstart oder dauerhaft la Teil des Programms?) und wie gut funktionieren die?
Sprich benutzen die ne DB mit bekannten Lücken und prüfen gängige Fehler (a la fehlendes Escapen) oder versuchen die selber rauszufinden ob Code xy Fehler hat?
Ich stell es mir jetzt nahezu unmöglich vor, dass ein Programm Fehler erkennt, die in der Programmlogik liegen.
Oder anders formuliert: Wenns so einfach wäre automatisch Fehler zu finden, dann gäbs ja vermutlich keine mehr.

 

[xexex]

Du zählst bis auf das SSL VPN(?

Ganz einfach, weil solche Sachen früher auf Java gesetzt haben, JRE vorausgesetzt haben, oder Teile davon irgendwo verwendet hatten und stellenweise aus dem Internet erreichbar waren.

Es geht hier im Serverside.. Tomcat, JBOSS, Jetty & Co

Jo, alles stark mit Java verzahnte Produkte, die zum Glück bis auf eine Ausnahme nirgendwo bei unseren Kunden im Einsatz sind.

 

[kim88]

Ab dem Moment wo die "Nicht-Technik-Medien" über die Lücke berichteten hatte ich in erster Linie einen etwas nervösen Chef.

Bei uns war aber nur eines von vielen Projekten betroffen - das einzige Java Projekt. War am Ende ein Segen, wir wollten diese Altlast schon lange loswerden, der Kunde wollte es immer als Legacy-Lösung laufen lassen.

Nun konnten wir dem Kunden schreiben, hej die Lücke ist da wir nehmen das PRodukt vorerst Offline + Offerte für Lösung des Problems. Nun hat de rKunde eingewilligt, das wir das Projekt beerdigen können -> daher am Ende war es ein eine Win Situation ^^