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

SheepShaver schrieb:
Nennt sich bei Veracode SCA.
Aha, OK, wieder was gelernt. Software Composition Analysis.
Aber SQ? Haben die sich die letzten 6 Monate derart weiterentwickelt?

Kennst DU vielleicht ein brauchbares DAST, welches Dir APIs ggf. auch Fuzzt?
 
foo_1337 schrieb:
Nein, das ist nicht die Aussage. Die Aussage ist, dass wenn auf einer Kiste z.B. Tomcat läuft, die Wahrscheinlichkeit, dass log4j läuft, hoch ist.
Kann ich so bestätigen, unsere Tomcats sind davon massenweise betroffen, weil der Hersteller diese so gekoppelt hat mit mehreren Komponenten.
 
  • Gefällt mir
Reaktionen: BorstiNumberOne, Unnu und foo_1337
Tipp, mal auf die TK-Anlagen schauen, insbesondere die Callmanager, wird echt uferlos 😂
 
Drizz schrieb:
Ich arbeite in einem großen Unternehmen in der Network Security, wir betreuen zwar die Infrastruktur, haben aber von dem Gebastel der Programmierer und der Applikationsumgebung weniger die Ahnung.

Leider ist es in der heutigen Zeit wohl auch so, dass man nicht mehr auf die Applikationsverantwortlichen zugeht,

Viele Grüße an alles Leidensgenossen
ich bin ehrlich gesagt überrascht das es so lange gebraucht hat bis das Publik geworden ist. Diese Lücke od. besser gesagt „Festure“ gibts seit März, Anfang April ist der erste POC öffentlich zugänglich gewesen… Das Problem ist in Log4J sogar ein Feature und wurde absichtlich integriert warum auch immer man sowas in ner Logging Lib braucht ….
 
@Benji18 noch extremer: HPE hat auf der Blackhat 2016 bereits vor Missbrauch der Funktion gewarnt.

Zynisch könnte man nun sagen: schade, dass wir keine Langzeit Vorratsdatenspeicherung der Logdaten (zur Analyse) haben ^^

works as intended, meanwhile … 🤓
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Benji18 und Unnu
poly123 schrieb:
@Benji18 noch extremer: HPE hat auf der Blackhat 2016 bereits vor Missbrauch der Funktion gewarnt.
works as intended, meanwhile … 🤓
ganz ehrlich ich frag nochmal allgemein wie kommt man auf die idee sowas in ne log lib zu integrieren?
 
Benji18 schrieb:
Anfang April ist der erste POC öffentlich zugänglich gewesen

Das ist schlicht falsch! Diese Behauptung bezieht sich auf eine GitHub Repo mit dem Namen log4j_POC dabei wird aber eine vollkommen andere Lücke genutzt (CVE-2019-17571). Diese Serialization Lücke betrifft nur log4j 1 (EOL) und nicht log4j 2.

https://logging.apache.org/log4j/1.2/
https://old.reddit.com/r/netsec/com...xploit_found_in_log4j_a_popular_java/ho3uf7c/
https://twitter.com/fiasco_averted/status/1470185395165884416

Benji18 schrieb:
besser gesagt „Festure“ gibts seit März,

Auch falsch. Das Feature gibt es seit 2013/log4j 2.0-beta9:
https://issues.apache.org/jira/browse/LOG4J2-313

Im Übrigen wurde die Lücke auch nicht über Minecraft entdeckt wie so häufig behauptet, sondern wurde am 24. November 2021 vom Alibaba Cloud Security Team an die Apache Entwickler gemeldete.
Gekracht hat es erst als der Sinn des öffentlich einsehbaren fix auf Github verstanden wurde.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: foo_1337, Unnu, PHuV und eine weitere Person
Benji18 schrieb:
ganz ehrlich ich frag nochmal allgemein wie kommt man auf die idee sowas in ne log lib zu integrieren?
Wie immer, man will andere komplizierte Schwierigkeiten vermeiden um ein vermeidlich einfaches Problem zu lösen. Das findest Du immer wieder in diverser Software, daß solche Dinge eingebaut werden. Ich sag nur mal telnet Funktion, weil man damit so einfach und schön prüfen kann, ob die Gegenseite entsprechend mit Port reagiert. Das man telnet eigentlich für was anderes verwenden denn zur Prüfung von Netzwerkverbindungen mißbrauchen kann, darauf kommt dann der zuständige Entwickler erst mal nicht. So, und nun wird überall telnet zurecht blockiert und verboten, und was macht man dann? Man liefert eine telnet.jar Datei mit, die genau das macht. 🙄 Warum? Weil man hier telnet auch verwendet, um einen Service zu stoppen. 🤦‍♂️Daß man man seine uralte Software diesbezüglich mal umschreibt, auf die Idee kommt man nicht. 😠

Ne, keine Realsatire, erlebte harter Alltag im IT-Betriebsgeschäft.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BorstiNumberOne, Piktogramm, Unnu und eine weitere Person
@SV3N @Jan lasst das Thema doch im page-rank in eurem CMS oben, finde die Diskussion und jegliche Infos extrem informativ.
 
  • Gefällt mir
Reaktionen: BorstiNumberOne
@PHuV : Naja, das ist schon Realsatire.
Einfallsreich ist er ja schon, der Entwickler.
Allerdings klingt das auch nach höchst misslungener Kommunikation.

Und eine Schulung in Secure Coding täte dem Betreffenden wahrscheinlich auch gut.

… telnet.jar 👍🤣
 
Wenn Du es noch erschütternder willst, das kommt von einem größeren Softwarehersteller, der das an zig Kunden ausliefert.
 
  • Gefällt mir
Reaktionen: Unnu und BorstiNumberOne
Unnu schrieb:
Kennst DU vielleicht ein brauchbares DAST, welches Dir APIs ggf. auch Fuzzt?
Nennt sich Gehirn, die CI/CD integration ist aber nicht so gelungen :)
Je dynamischer desto aufwändiger ist im allgemeinen aber die Automatisierung. Project Zero hatte da gerade ein gutes Beispiel: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html
Welches Tool brauchbar ist, hängt aber auch von der Art der Anwendung ab. Für eine node.js Web-Anwendung kann man mit acunetix, burp, nikto usw. schon sinnvolle Ergebnisse erzielen, während ein Flight Management Computer ganz andere Tools und Anpassungen erfordert...
 
  • Gefällt mir
Reaktionen: Unnu
Tya was ich schon immer festgestellt hatte,software ist schrott.Das merkt man des öfteren auch in so vielen Bereichen. Weil es halt mit viel Arbeit verbunden ist,sau teuer ist also noch Teuer als Hardware zu entwickeln. Am ende sind also die Menschheit die sowas nutzt ,die Leitragenden davon. Naja ich habe auch software die auf der Liste ist,aber ob ich da nun angst haben muss oder nicht,weis ich nicht.Ich habe das auch noch nicht so lange endeckt diese Meldung. Wie merkt man ob man betroffen ist oder nicht.Ich habe da keine Ahnung,weil mit Software kenne ich nur die wo ich verwenden. Also nur das was ich am meisten verwenden. Der rest wenig bis null Ahnung.Ich hoffe mich kann da wer aufklären,danke.
 
PHuV schrieb:
Wenn Du es noch erschütternder willst, das kommt von einem größeren Softwarehersteller, der das an zig Kunden ausliefert.
Bei uns auch, Log4j war in der Applikationschichtkomponente auf dem Linux AppServer und in der Webkomponente auf dem WebServer drin. Darum auch der Riesenmarathon zum Rauspatchen aus allen Instanzen weltweit. Auch hier in unserem Fall eine große Software, die bei mehreren großen DAX Konzernen im Einsatz ist. Aber der Hersteller hat sehr schnell und sehr gut reagiert, auch mit internen Tests unserem Management nahegelegt, die allererste Mitigation (Start mit Parameter) schnellstens wieder zu verwerfen und die JndiLookup.Class zu entfernen. Patchen geht auch, aber da kommt ja jetzt wahrscheinlich ein Update nach dem anderen raus, siehe 2.16 und 2.17 allein in der letzten Woche.
 
  • Gefällt mir
Reaktionen: PHuV, foo_1337 und Unnu
BorstiNumberOne schrieb:
Patchen geht auch, aber da kommt ja jetzt wahrscheinlich ein Update nach dem anderen raus, siehe 2.16 und 2.17 allein in der letzten Woche.
Ich komme hier kaum mit dem Dokumentieren bei uns hinterher, so oft wie das Ding jetzt gepatch wird. 😅
 
  • Gefällt mir
Reaktionen: poly123 und BorstiNumberOne
PHuV schrieb:
Ich komme hier kaum mit dem Dokumentieren bei uns hinterher, so oft wie das Ding jetzt gepatch wird. 😅
Das glaube ich Dir. 😅
Wir mussten ja immer den TAR Ball für das Deployment bauen, dann deployen auf dem Testssystem, dann das gröbste testen, dann für das Prod-Deployment freigeben. Und das in der folgenden Nacht für 26 produktive Systeme.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: poly123 und PHuV
So, alles nochmal durchgecheckt:
  • Die MediathekView-Version, die bei meinen Eltern läuft, ist so alt, dass sie noch kein Log4J enthält, wenn ich es nicht übersehen hab (bei neueren fehlt die Cli-Option für Abos). Irgendwann muss ich mir da aber mal etwas besseres überlegen, eine gute Idee ist das natürlich trotzdem nicht. Wäre da nicht der Zeitfaktor...
  • AVM ist nicht betroffen (https://avm.de/aktuelles/kurz-notie...a-projekt-log4j-avm-produkte-nicht-betroffen/).
  • Smartzeug läuft bei mir über Homeassistant, welches nichts mit Java zu tun hat.
  • Irgendwelche Fernseher oder so am Netzwerk gibt es nicht, selbst meinen Eltern habe ich einen guten alten HTPC hingestellt, mit Autoupdates.
  • Und falls ich etwas übersehen hab, die Kisten laufen alle mit Linux und haben Autoupdates an.
Wohl nochmal Glück gehabt, wenn ich nichts übersehen habe.
 
BorstiNumberOne schrieb:
Das glaube ich Dir. 😅
Wir mussten ja immer den TAR Ball für das Deployment bauen, dann deployen auf dem Testssystem, dann das gröbste testen, dann für das Prod-Deployment freigeben. Und das in der folgenden Nacht für 26 produktive Systeme.
Arme Sau 😂 - aber den mangelnden Respekt der Administration gegenüber ist man berufsbedingt ja gewohnt ^^

Bei uns waren es hunderte Installationen - aber bin CISO nahe eher weit weg vom praktischen doing 😝
 
  • Gefällt mir
Reaktionen: ComputerJunge und BorstiNumberOne
poly123 schrieb:
Arme Sau 😂 - aber den mangelnden Respekt der Administration gegenüber ist man berufsbedingt ja gewohnt ^^
Das hat zum Glück gepasst, wir sind ja direkt von der Applikationsverantwortung und haben direkt an den IT Krisenstab bei uns im Konzern berichtet. Die Aktionen aller kamen sehr gut an und für mich gibt es ja in so einem Fall allerhand Zuschläge (Nacht, Sonntag, etc.), da geht es von der Seite her. 😉
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: poly123
Zurück
Oben