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

Mir fehlt "keine Ahnung" als Antwort!
 
  • Gefällt mir
Reaktionen: McTheRipper, Beero84, Crazy- Jak und 20 andere
NoXPhasma schrieb:
Mir tun ja nur die Menschen leid die da nun ihr Wochende opfern müssen und auf die alles abgewälzt wird.
Ja, das war ätzend. Aber unsere Leute wurden dafür auch belohnt ;)
 
  • Gefällt mir
Reaktionen: Schmarall und NoXPhasma
Da fehlt mir die Option "Keine Ahnung ob ich davon betroffen bin" ;-)
 
  • Gefällt mir
Reaktionen: Crazy- Jak, Three of Nine, panzercrak und 10 andere
Auf der Arbeit wurden einige Citrix-Services vorsichtshalber eingestellt.
Das hat hier und da für Irritationen geführt...
 
Indirekt betroffen im Sinne von: Wir gehören zur Kritischen Infrastruktur und daher war es eine unruhige Woche für die IT, die die ganzen Scanner am laufen hatten und alles prüfen mussten
 
  • Gefällt mir
Reaktionen: Unnu
Zuerst durch die derzeit in Mode gekommene Panikmache beunruhigt gewesen, dann mich besinnt und etwas informiert und festgestellt dass es mich nicht direkt betrifft und über den indirekten Angriffsvektor über Server ich kaum was dagegen tun könnte. Minecraft Spiel ich nicht derzeit und nach einem kurzen Check auch geklärt, dass unsere Sonicwall Zuhause kein Java implementiert hat.
Seither wieder alles entspannt.

Mal ne Frage zu diesem lauthalsen verkünden der Lücke... Ist sowas eigentlich nicht kontraproduktiv bezüglich Sicherheit? Ich mein klar, man muss davon berichten damit die Verantwortlichen für entsprechende Systeme das prüfen. Aber geht das nicht sachlicher und unaufgeregter, sodass nicht gleich JEDER davon Wind kriegt und evtl. Versucht, daraus Profit zu schlagen?
 
Zuletzt bearbeitet von einem Moderator:
Bei uns (KRITIS) gab es letzten Sonntag + Montag einige Überstunden deswegen, weil das Thema bei uns hoch eskaliert wurde. Aus dem Internet waren wir nicht direkt betroffen, aber wir haben diverse Interne Anwendungen, die betroffen waren. Der Sonntag ging quasi komplett drauf von Mittags bis spät Abends, um alle Anwendungen abzugrasen die wir einsetzen und zu schauen, welche Verwundbar waren. Da dort viele Anwendungen indirekt am Netz hingen, also Input von Anwendungen am Netz weiter verarbeitet und dann auch teilweise geloggt haben, wurde auch viel abgeschaltet am Sonntag, und dann über die Woche kontrolliert wieder hochgefahren.
Das wird jetzt dank des Updates nochmal passieren. Aber man sieht jetzt schön, welche Hersteller ihre Abhängigkeiten im Griff haben und schnell ein Update geliefert haben, und welche es trotz Wartungsvertrags noch nicht hingekriegt haben überhaupt ein Update zu liefern. Letztere Anwendungen sind bei uns aktuell noch gestoppt, auch wenn es nicht viele sind.
 
  • Gefällt mir
Reaktionen: Unnu und Kaulin
Enigma schrieb:
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 habe erst kürzlich wieder ein npm install gemacht. Für EINE Software, die wir brauchen, wurden 1200 Pakete weitere nachgeladen und diesen Quellcode führe ich auf hoch-vertraulichen Systemen aus. In der Console sehe ich wie Leute nach Geld betteln und kritische Sicherheitsprobleme gemeldet werden. In der Dimension, wie das heute stattfindet, ist das ein desaster.
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.
 
  • Gefällt mir
Reaktionen: sebbolein, Razorex, Benji18 und eine weitere Person
Ich nutze SPSS fürs Studium und bekam von der Uni eine Mail inkl. Anleitung, wie ich die betroffenen Dateien aus dem Installationsverzeichnis und Unterordner löschen und durch gepatchte Dateien ersetze. Sonst hat mich das Thema eher kalt gelassen.
 
SheepShaver schrieb:
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.
DevSecOps :) Leider ist diese Praxis bei den allerwenigsten etabliert. Die meisten sind ja schon froh, wenn sie mit gitlab-ci, jenkins etc. überhaupt was auf die Kette kriegen :(
 
  • Gefällt mir
Reaktionen: Unnu, Kaulin und Siffi2
derlorenz schrieb:
Musst du als User ja auch nicht, aber du kannst dich bei den von dir genutzten Produkten an den Hersteller wenden.
Und an der Stelle hört dann die Panik bei mir auch wieder auf:
https://avm.de/service/aktuelle-sicherheitshinweise/#Schwachstelle im Java-Projekt „log4j“
13.12.2021Schwachstelle im Java-Projekt „log4j“
Kürzlich wurde eine Schwachstelle im häufig eingesetzten Java-Projekt „log4j“ bekannt. AVM-Produkte sind davon nicht betroffen. Ebenso ist der MyFRITZ!-Dienst nicht betroffen.
 
  • Gefällt mir
Reaktionen: PegasusHunter, MGFirewater, chartmix und 2 andere
ich habe keine ahnung xD

was soll denn eigentlich dieses github-projekt für rechner mit http server bringen? dann weiß man, dass der http server nicht betroffen ist. da kann man zur not ja auch noch selber nachschauen, welche apache/nginx/... version man hat. bleiben noch alle anderen serverfunktionen übrig, toll...
 
tiga05 schrieb:
Die Software, die davon betroffen ist, hatten die Kollegen in der Abteilung am Montag bereits in Eigeninitiative gefixt.
Ansonsten von der It-Security erstmal nix.
bringt nur nicht viel weil nach dem 2.15 release noch CVEs gefunden wurden aktuell hat man also 2 mal (diese Woche) nachgearbeitet und vermutlich wars nicht das letzte mal.
 
Benji18 schrieb:
bringt nur nicht viel weil nach dem 2.15 release noch CVEs gefunden wurden aktuell hat man also 2 mal (diese Woche) nachgearbeitet und vermutlich wars nicht das letzte mal.
Naja, das schlimmste war ja die RCE. Und wenn man die jndi klassen entfernt hat plus nomsgformatlookup in den jvm optionen gesetzt hat, ist man nach wie vor in den allermeisten Fällen auf der sicheren Seite. Die beiden letzten CVE kommen nur in sehr exotischen Fällen zum Tragen. Und im ersten von beiden hilft bereits die jndi Klasse zu entfernen.
Mickey Cohen schrieb:
ich habe keine ahnung(...)da kann man zur not ja auch noch selber nachschauen, welche apache/nginx/... version man hat
Ja, merkt man. Mit apache/nginx & sonstigen (nicht zufällig in Java geschriebenen) Webservern hat das gar nichts zu tun.
 
Enigma schrieb:
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.
Was schlägst du als bessere Alternative vor?
 
  • Gefällt mir
Reaktionen: pseudopseudonym, Kaulin und foo_1337
KitKat::new() schrieb:
Was schlägst du als bessere Alternative vor?
Er leidet unter dem NIH Syndrom und geht davon aus alles besser zu machen zu können :) Bill Joy hat schon mitte der 70er erkannt, dass das völlig bescheuert ist.
 
  • Gefällt mir
Reaktionen: Beiburca
Bin gespannt wie viele Server in den nächsten Monaten noch betroffen sein werden, weil irgendwelche Backdoor-Programme installiert wurden und sonst bisher nichts mit der Lücke angestellt wurde.
 
freunde von mir sind ganz schön im stress, ich dachte mir: mit php hat man auch gelegentlich mal glück... bis es beim nächsten mal wieder andersrum ist.
 
  • Gefällt mir
Reaktionen: foo_1337
War bei mir eine Höllenwoche. Über 50 Server absichern, testen, dokumentieren, Kunden wie Kollegen informieren. Mein Confluenzartikel wächst jeden Tag. Und ich bin noch nicht fertig. Analyse ergab auf einen Server, das 104 Java Pakete log4j2 mit Version vor 2.15 enthalten.
 
  • Gefällt mir
Reaktionen: Kaulin
Ich arbeite für eine Handvoll deutscher Großkunden im IT Bereich ... die letzte Woche war wohl die stressigste Woche vor einem Urlaub überhaupt.

  • man wurde kontinuierlich zugeschissen mit Kundenanfragen ob XYZ betroffen ist
  • Dienste wurden aus Sicherheitsgründen vom Netz genommen ( es musste ja VMWARE betroffen sein ) , gepatcht, neu hoch gebracht, mit den neuen Releases andere Probleme festgestellt und diese auch behoben...
  • Viele Remote Zugänge / Web Dienste geschlossen die vorher unbedenklich waren.
  • bei einem Kunden wurde Netzwerkhardware getauscht / neukonfiguriert

Und bei einem sehr auf Security setzenden Kunden durften wir dann noch deren generelle Schnappatmung abfangen und jedes einzelne deren Soft / Hardware Produkte, die sie im Einsatz haben, einzeln dreifach verproben / prüfen ob sie betroffen sind und notfalls schritte einleiten das abzusichern.

Schön ist anders, und ich hab persönlich Mitleid mit meinen Kollegen die über die Feiertage bis Neujahr sich den Stress mit minimal Besetzung antun müssen.
 
  • Gefällt mir
Reaktionen: Rickmer
Zurück
Oben