• youtube
• imgur
• fever°

after googlereader was gone a friend told me about Fever°. it is a very good rss-feed-reader for your own server. not for free, but it's worth the 30 bucks! the last articles I marked there are listed below... (mostly german)

Awful Cityscapes (21 pics)

<#comment hash="7bde71d84849aff2fa479017d52bab57" /><#comment hash="4daa99762ce59f13f17c9919bba9cb40" />

heise+ | Anti-Tracking-Maßnahmen in Chrome, Firefox, Edge und Safari aktivieren

Browserhersteller haben diverse Methoden zum Schutz der Privatsphäre implementiert. Aber davon liegen viele brach. Wir zeigen, wie Sie Ihre Daten schützen.

Memes About 90's (40 pics)

<#comment hash="524495819dfff910d112554f79f53def" /><#comment hash="4daa99762ce59f13f17c9919bba9cb40" />

heise+ | Security: Ransomware-Angriffsmuster und wie man sich vor ihnen schützt

Ransomware-Angriffe erfolgen häufig nach Mustern. Gute Vorbereitung durch angemessene Präventionsmaßnahmen ist zentral, ebenso schnelles Handeln im Ernstfall.

Kennt ihr den schon? Grundschule forkt Matrix-Client, ...

Kennt ihr den schon? Grundschule forkt Matrix-Client, passt ihn für eigene Bedürfnisse an?

Wie? Nein. Nicht Silicon Valley. Stolberg.

Das ist ein paar Kilometer östlich von Aachen.

Warte mal, war das nicht mitten im Hochwassergebiet? Ja, war es. Haben die trotzdem gemacht.

Was haben die denn da angepasst? Nun, in erster Linie ist die Zielgruppe Kinder, die noch nicht alle lesen und schrieben können. Also: Sprachnachrichten. Einfache Benutzerführung. Anmeldung mit QR-Code statt Text-Accountdaten. Sowas.

Wir hatten im Keller noch einen alten Verwaltungsserver, darauf habe ich CentOS installiert. Für die Installation vom Matrix-Server Synapse haben wir uns Hilfe von einem externen Admin geholt, der selbst eine große öffentliche Matrix-Instanz in Deutschland betreibt und nun auch unseren Server verwaltet. Mit ihm haben wir auch ganz DSGVO-Konform einen Auftragsverarbeitungsvertrag.

Europas ISS-Modul hat jetzt 50 MBit/s Anbindung.Wenn ...

Europas ISS-Modul hat jetzt 50 MBit/s Anbindung.

Wenn das die Brandenburger hören! Das gibt schlechte Laune!!

Aber wartet, ein Lacher kommt noch:

Während die USA und Russland bereits mit mehreren Hundert Mbit/s Daten zur ISS schicken können, gibt es nun auch für das Columbus-Modul eine bessere Anbindung.

Waren bestimmt Lieferprobleme aus Asien. Hier wird ja nichts mehr hergestellt. Warum eigentlich nicht?

Liebe Leser, ihr müsst jetzt sehr tapfer sein.Die ...

Liebe Leser, ihr müsst jetzt sehr tapfer sein.

Die Allianz hat mal Führungskräfte aus Unternehmen gefragt, was ihnen die größten Sorgen macht im Moment.

Inflation? Fachkräftemangel? Pandemie? The Great Resignation?

Nope. Nichts davon..

Gefährlicher als die Pandemie oder Naturkatastrophen: Fach- und Führungskräfte, die vom Versicherungskonzern Allianz befragt wurden, sehen Hackerangriffe und deren Folgen als Risiko Nummer eins für ihr Unternehmen.

Also DAMIT konnte ja wohl NIEMAND rechnen!

Besonders geil auch das Framing mal wieder. "Hackerangriffe". Nicht etwa "unsere verkackte Infrastruktur" oder "dass ich die letzten Jahre nichts investiert habe" oder "Sicherheit war bei uns halt nie Thema, da haben wir wohl Fehler gemacht". Nein, nein. "Hackerangriffe". Die bösen Hacker sind hier die Bedrohung. Nicht etwa dass es bei uns reinregnet, weil wir nie das Dach repariert haben.

Betty White Tweets (24 pics)

<#comment hash="3f28ea4e0874f06a11d1444133e36a9b" /><#comment hash="4daa99762ce59f13f17c9919bba9cb40" />

Wolltet ihr schon immer mal wissen, wie sich eine Notaufnahme ...

Wolltet ihr schon immer mal wissen, wie sich eine Notaufnahme Silvester anfühlt?

Ich frage mich ja schon länger, was eigentlich die Aliens denken sollen, die unseren Planeten beobachten. Wenn die sehen, wie wir mit Alkohol umgehen, dann ist das bestimmt so wie wenn wir Tiervideos wie das hier sehen.

Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31

Subject: Apache Log4j2 Vulnerability - CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 - ESA-2021-31

​​Note - We will update this announcement with new details as they emerge from our analysis. Please check back periodically.

Update Log

• Dec 16, 2021 - 04:20 UTC - Update Summary: ECK 1.9 released which automatically adds the JVM option to impacted Elasticsearch clusters managed by ECK.
• Dec 17, 2021 - 23:50 UTC - Update latest release of APM Java Agent to 1.28.2. Statement of plan to release 7.16.2 and 6.8.22. Added mitigation summary matrices for APM Java Agent, Elasticsearch, Logstash, and Elasticsearch on Elastic Cloud.
• Dec 18, 2021 - 23:40 UTC - Added statement that Elasticsearch, Logstash, and APM Java agent have no known vulnerabilities to CVE-2021-45105. Targeting Dec 19 for release of Elasticsearch and Logstash 7.16.2 and 6.8.22
• Dec 19, 2021 - 13:32 UTC - Elastiscsearch and Logstash 7.16.2 and 6.8.22 are now released. These releases include the most recent version of Log4j (2.17.0).
• Dec 20, 2021 - 19:55 UTC - APM Java Agent has no known vulnerabilities to CVE-2021-45105. Regardless, we do intend to remain current on log4j and plan to update the APM Java Agent after log4j 2.12.3 becomes available.
• Dec 22, 2021 - 20:30 UTC - APM Java Agent updates available with log4j 2.12.3
• Jan 6, 2022 - 01:20 UTC - Update with responses for CVE-2021-44832. APM Java Agents 1.26.2 and 1.28.4 release. ECE 2.12.4 release. Planned release for Elasticsearch, Logstash 7.16.3 and 6.8.23
• Jan 11, 2022 03:40 UTC - Update APM Java Agents advisory for CVE-2021-44832.
• Jan 13, 2022 21:00 UTC - Elasticsearch, Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1. Note about ECE and Apache Zookeeper.

Summary

A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.

This announcement summarizes the currently known potential impacts to Elastic products and related announcements for mitigations of the issue. Elastic engineering and security teams continue to actively work on the analysis and any actions our users should perform, alongside detection signatures that may be used to identify exploitation of the vulnerability.

[Update Jan 13]

Elasticsearch, Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1. By default, Elasticsearch and Logstash have no known vulnerabilities to CVE-2021-44832.

[Update Jan 11]

APM Java Agents versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 are susceptible to CVE-2021-44832 when used in an application where an attacker has access to create files within the application directory. Users should upgrade to APM Java Agent versions 1.26.2 or 1.28.4, which have Log4j 2.12.4 which addresses CVE-2021-44832.

[Update Jan 6]

A vulnerability (CVE-2021-44832) was disclosed on December 28th where an attacker having access and permission to write the Log4j configuration file can result in Remote Code Execution. By default, Elasticsearch and Logstash have no known vulnerabilities to this as relevant configuration files are only writable by cluster administrators. We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13.

APM Java Agents have no known vulnerabilities for CVE-2021-44832. See Jan 11 Updates, versions 1.27.0, 1.27.1, 1.28.0 and 1.28.1 are susceptible to CVE-2021-44832 when an attacker has access to create files within the application directory.

APM Java Agent versions 1.26.2 and 1.28.4 are available with updated Log4j 2.12.4.

ECE has no known vulnerabilities for CVE-2021-44832. ECE 2.12.4 is available which updates internal ECE components to Log4j 2.17.1

[Update Dec 19]

Elastiscsearch and 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not trigger false positives in vulnerability scanners.

[Update Dec 18]

​​Log4j2 Version 2.17.0 was released to address a denial of service vulnerability reported in CVE-2021-45105. Elasticsearch, Logstash, and APM Java agent are not exploitable by this vulnerability and the prior guidance is still valid.

As previously announced, we are targeting to release Elasticsearch and Logstash 7.16.2 and 6.8.22 which will include the latest version of Log4j (2.17.0). The target for this release is December 19.

[Update Dec 17]

The 7.16.1 and 6.8.21 releases of Elasticsearch and Logstash fully mitigate CVE-2021-44228 and CVE-2021-45046, but may trigger false positives in vulnerability scanners based on the bundled version of Log4j. In order to address these false positives, we will release 7.16.2 and 6.8.22 containing an updated version of Log4j that should not trigger false positive alerts from vulnerability scanners. Several new Log4j versions have been released in recent days, and we are waiting for some stability before incorporating the latest Log4j and releasing these new versions.

[Update Dec 15]

A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability.

Elasticsearch

Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager. Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change. The information leak vulnerability does not permit access to data within the Elasticsearch cluster. We have released Elasticsearch 7.16.1 and 6.8.21 which contain the JVM property by default and remove certain components of Log4j out of an abundance of caution. This is applicable to both CVE-2021-44228 and CVE-2021-45046. Elasticsearch has no known vulnerabilities to CVE-2021-45105. Elasticsearch 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1Details below.

Elastic Cloud

Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. As a normal practice we will update components with the latest version of Log4j as they become available. We recommend that users who are on versions before 7.2 restart their deployments to pick up an updated setting. Details below.

APM Java Agent

Details below

Elastic Cloud Enterprise

Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release. Mitigation details for an Elasticsearch cluster managed by ECE are below.

[Update Jan 13]

ECE uses Apache Zookeeper which depends on log4j 1.2.17 as an internal dependency. There is no known exploitation of CVE-2021-4104 in this implementation, and there are currently no upstream plans announced by the Apache Zookeeper project to update the log4j version in Zookeeper.

[Update Jan 6]

ECE has no known vulnerabilities for CVE-2021-44832. ECE 2.12.4 is available which updates internal ECE components to Log4j 2.17.1.

To remove impacted Log4j assemblies from the filesystem, ECE customers will need to:

1. Upgrade their installation to 2.12.4 or newer.
   This will update all ECE components as well as ECE system clusters to use components that have been updated to Log4j 2.17.0 or newer.
2. Upgrade all deployments within the installation to use versions 7.16.2 / 6.8.22 or newer for major versions 7 / 6 respectively.
3. Remove stack packs for impacted deployment stack versions.
   Removing stack packs for versions prior to 7.16.2 / 6.8.22 will ensure new deployments violating scan policies won’t get created in the future.
4. Purge all old images from the filesystem.
   Customers can run docker image prune -a on all ECE hosts to remove all images not currently in use by running containers.

Elastic Cloud on Kubernetes

While the ECK Operator is not impacted by this vulnerability, mitigation details for an Elasticsearch cluster managed by ECK are below.

Logstash

Exposure to remote code execution exists on JDKs prior to 8u191. On newer versions of JDKs there is exposure to Denial of Service and information leakage, but no known remote code execution exposure. Logstash has no known vulnerabilities to CVE-2021-45105. Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1Details below.

Swiftype

Our security testing has not identified any exploitable RCEs against Swiftype products. Our investigation continues and we will provide updates of any new findings. We have mitigations in place as a precaution and will update components with the latest version of Log4j as they become available.

Not Impacted

We have validated that the vulnerability does not exist in the following Elastic products:

• APM Server
• Beats
• Cmd
• Elastic Agent
• Elastic Cloud on Kubernetes
• Elastic Endgame
• Elastic Maps Service
• Endpoint Security
• Enterprise Search
• Fleet Server
• Kibana
• Machine Learning

APM Java Agent announcement (ESA-2021-31)

In versions 1.17.0-1.28.0, the only known way the CVE-2021-44228 vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT).

Additionally CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 in the circumstance where an attacker has access to create files within your application directory.

Affected Versions:

Versions 1.17.0-1.28.1, excluding 1.26.1 & 1.26.2

Solutions and Mitigations:
Users running affected versions should upgrade to the latest version (1.26.1, 1.26.2 or 1.28.3 or newer).

In versions 1.17.0-1.28.0, CVE-2021-44228 can be mitigated manually by setting system property -Dlog4j2.formatMsgNoLookups=true.

In versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1, CVE-2021-44832 can be mitigated by ensuring filesystem permissions prevent unauthorized users writing the log4j.properties file in the application directory.

[Update Jan 11]

CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 if an attacker has access to create files within your application directory. Users should upgrade to APM Java Agent versions 1.26.2 or 1.28.4, which have Log4j 2.12.4 which addresses CVE-2021-44832.

[Update Jan 6]

APM Java Agent versions 1.26.2 and 1.28.4 are available with updated Log4j 2.12.4.
A vulnerability (CVE-2021-44832) was disclosed on December 28th where an attacker having access and permission to write the Log4j configuration file can result in Remote Code Execution. APM Java Agent has no known vulnerabilities to CVE-2021-44832 as the ability to modify the log4j configurations is not exposed by default. [Jan 11] CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 if an attacker has access to create files within your application directory

The latest APM Java Agent versions are updated to include Log4j 2.12.4.

[Update Dec 22]

APM Java Agent 1.26.1 and 1.28.3 are now available. Both include log4j2 2.12.3 which fully addresses CVE-2021-45046 and CVE-2021-45105. Users running APM Java Agent <=1.26.0 are advised to select 1.26.1 in order to move to a version with a fully-patched log4j with minimal qualification required of other changes in the APM Java Agent. Users who have already adopted Java APM Agent >= 1.27.0 can move forward to the latest which is APM Java Agent 1.28.3.

[Update Dec 20]

APM Java Agent has no known vulnerabilities to CVE-2021-45105. Regardless, we do intend to remain current on log4j and plan to update the APM Java Agent after log4j 2.12.3 becomes available.

[Update Dec 17]

We have now released 1.28.2, which ships with a patched log4j version (2.12.2) that should not trigger false positive alerts from vulnerability scanners.

[Update Dec 15]

Version 1.28.1 of the Elastic APM Java agent also mitigates CVE-2021-45046, as we have excluded the vulnerable JndiLookup class. This version still uses log4j 2.12.1 but the vulnerable code is not present.
We will release 1.28.2 soon, which ships with a patched log4j version (2.12.2) that should not trigger false positive alerts from vulnerability scanners.

APM Java Agent mitigation summary matrix

Note: While the below mitigations are considered complete, our overall recommendation is to update <=1.26.0 to 1.26.1 and >=1.27.0 to 1.28.3

Yes indicates the versions are subject to the vulnerability in question, No indicates they are not vulnerable. Version ranges are inclusive.

¹ Set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart your application. This is a complete mitigation where noted above. The Elastic APM Java Agent has no known vulnerabilities to Thread Context Message and Context Lookup from CVE-2021-45046.

² The only known way the Log4j vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT).

³ Only CVE-2021-44832 if an attacker can create files within your application directory

⁴ Ensure that correct filesystem permissions prevents unauthorized file creation

Elasticsearch announcement (ESA-2021-31)

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM option identified below. This option is effective for Elasticsearch versions 5.6.11+, 6.4+, and 7.0+.

As of December 13, 2021, we have released Elasticsearch 6.8.21 and 7.16.1 which set the JVM option identified below and remove the vulnerable JndiLookup class from Log4j out of an abundance of caution. If you are on a 6.x version prior to 6.4.0 and upgrading is not possible, you can follow the instructions here.

Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. For versions 5.6.11 - 5.6.16, this can be mitigated by setting the JVM option. Users on an earlier version of 5.x, are recommended to upgrade to 5.6.16. If you are on a 5.x version prior to 5.6.11 and upgrading is not possible, you can follow the instructions here. Please note that while we provide these remediations, Elasticsearch 5 is not a supported version, and we always recommend updating to the latest release.

Elasticsearch 2 and earlier used a Log4j version that is not vulnerable to the newly discovered flaw. Please note that Elasticsearch 2 is not a supported version, and we always recommend updating to the latest release.

For users running on Elastic Cloud, versions 7.2+ have never been susceptible to either the RCE or the information leakage as these versions already run on JDK11 or higher. We recommend users running any version of Elasticsearch earlier than 7.2 restart their clusters as soon as possible - the JVM option identified below will automatically be applied and fully protect clusters on restart. Any new clusters will be deployed with the JVM option included. See Elastic Cloud announcement for more details

Affected Versions:

Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7.

Solutions and Mitigations:

The simplest remediation is to set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart each node of the cluster.
For Elasticsearch 5.6.11+, 6.4+, and 7.0+, this provides full protection against the RCE and information leak attacks.

Users may upgrade to Elasticsearch 7.16.2 or 6.8.22, which were released on December 19, 2021 and updates Log4j to the most recent version (2.17.0).

The previous 7.16.1 and 6.8.21 releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.

Note: Prior to 7.16.2 and 6.8.22, some vulnerability scanners may continue to flag Elasticsearch in association with this vulnerability based on the Log4j version alone. However, any of the above mitigations sufficiently protect both remote code execution and information leakage.

[Update Jan 6]

By default, Elasticsearch’s log4j2.properties configuration file is only writable to the administrators of the cluster. If you have modified your file system permissions to grant non-admins write access to this file, then you may be susceptible to CVE-2021-44832, and should take steps to ensure that Elasticsearch’s configuration files are only writable by cluster administrators. We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13.

[Update Dec 19]

Elastiscsearch 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not cause false positives in vulnerability scanners.

[Update Dec 14]

Log4j 2.16.0 has been released to address CVE-2021-45046. This does not change the mitigation guidance for Elasticsearch described above, that does not require an update to Log4j 2.16.0. Elastic guidance remains to either apply the JVM option described above and restart all nodes, or upgrade Elasticsearch to 7.16.1 or 6.8.21.

Elasticsearch with ECK

If Elasticsearch is managed by ECK, set the JVM option in the Elasticsearch custom resource podTemplate specification or upgrade to ECK 1.9.1 which automatically adds the JVM option to impacted Elasticsearch clusters.

Elasticsearch with ECE

If Elasticsearch is managed by ECE, for versions 6.x and <7.2, we recommend reinstalling stackpacks, which have been patched to include the JVM option mitigation. After re-installing relevant stackpacks, we recommend restarting deployments. For the 5.x series, we recommend overriding the JVM options to add the property that will mitigate the vulnerability, and restart the cluster to pick up the change: For details and guidance, please reach out to Elastic support.

Details on Elasticsearch information leakage

The information leakage vulnerability in Log4j enables an attacker to exfiltrate certain environmental data via DNS - it does not permit access to data within the Elasticsearch cluster. The data that can be leaked is limited to those available via Log4j “lookups”, which includes system environment variables and a limited set of environmental data from other sources. For a complete list, see the Log4j Lookups documentation.

Notes of PoCs expanding RCEs to recent Java versions**

We are actively monitoring developments in the security community, such as this one, which seek to expand the JDKs and scenarios where this exploit will apply. Our implementation of the Java Security Manager in Elasticsearch 6 and 7, in combination with JDK9 or greater, continues to protect against all known PoC’s. While these efforts seek to provide a viable RCE even when com.sun.jndi.ldap.object.trustURLCodebase=false (as in recent JDKs), our Security Manager cuts off the attack earlier in the process, preventing both remote and local (on the class path) variants of the attack.

Elasticsearch mitigation summary matrix

Note: While the below mitigations are considered complete, our overall recommendation is to update to version 7.16.2 or 6.8.22 or newer.

Yes indicates the versions are subject to the vulnerability in question, No indicates they are not vulnerable. Version ranges are inclusive.

¹Set the JVM option -Dlog4j2.formatMsgNoLookups=true on each node and restart each node. This is a complete mitigation where noted above. Elasticsearch has no known vulnerabilities to Thread Context Message and Context Lookup from CVE-2021-45046.

²Removal of the JndiLookup class from the Log4j library. Instructions here.

³No mitigation is needed as this configuration is not vulnerable. On Elasticsearch 6.4.0 or higher, you can still add the system property in an abundance of caution.

Logstash announcement (ESA-2021-31)

A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Logstash uses Log4j as its logging subsystem and may be vulnerable.

When running Logstash on JDKs older than 8u191 and 11.0.1, an attacker is able to inject and execute a remote Java class. On recent JDKs the attack is limited to DoS - causing data ingestion to temporarily stop - and information leakage, but no remote code execution attack vectors are known.

Affected Versions:

Logstash versions 5.0.0+ up to and including 7.16.0 contain a vulnerable version of Log4j. The severity depends on the JDK used as stated above.

Docker images below version 6.4.3 include a JDK older than 8u191, which means they are open to Remote Code Execution. Images 6.4.3+ don't have known RCE attacks but are still susceptible to Denial of Service and information leaks.

Solutions and Mitigations:

Users should upgrade to Logstash 7.16.3 or 6.8.23. These releases replace vulnerable versions of Log4j with Log4j 2.17.1.

The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. If the user cannot upgrade to Logstash 7.16.2 or 6.8.22, it is necessary to remove the JndiLookup class from the log4j2 core jar, with the following command (which is applicable for 5.x, 6.x, and 7.x):

zip -q -d <LOGSTASH_HOME>/logstash-core/**/*/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class

Please note that a restart of the Logstash process is necessary for the change to take effect.

[Update Jan 6]

By default, Logstash’s log4j2.properties configuration file is only writable to the local administrator. If you have modified your file system permissions to grant non-admins write access to this file, then you may be susceptible to CVE-2021-44832, and should take steps to ensure that Logstash’s configuration files are only writable by administrators. We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13.

[Update Dec 19]

Logstash 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not cause false positives in vulnerability scanners.

[Update Dec 15]

Users have noticed that the newly released Logstash 6.8.21 contains a jar that bundles a vulnerable version of log4j-core. Logstash core will load the Log4j 2.15.0 from core instead of any other log4j-core jar in plugins, so no Jndi Lookups will happen.

[Update Dec 14]

Log4j 2.16.0 has been released to address CVE-2021-45046. Logstash is not impacted by the vulnerability disclosed in CVE-2021-45046 because Logstash does not ship with logging layouts that can be exploited to trigger JNDI lookups through Thread Context references. Elastic guidance remains to either remove the JndiLookup.class or upgrade Logstash to 7.16.1 or 6.8.21.

The fact that the logj4-core 2.15.0 from core is the only one loaded has been confirmed through code analysis and experimentation, but if users are required to remove the class, the command is:

zip -q -d <LOGSTASH_HOME>/vendor/**/*/logstash*tcp*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Logstash mitigation summary matrix

Note: While the below mitigations are considered complete, our overall recommendation is to update to version 7.16.3 or 6.8.23 or newer.

Yes indicates the versions are subject to the vulnerability in question, No indicates they are not vulnerable. Version ranges are inclusive.

¹Removal of the JndiLookup class from the Log4j library. Instructions here.

Elastic Cloud announcement (ESA-2021-31)

Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. Our investigation continues and we will provide updates of any new findings. As a normal practice we will update components with the latest version of Log4j as they become available. Users runningElastic Cloud versions 7.2+ have never been susceptible to either the RCE or the information leakage as these versions already run on JDK 11 or higher.

Solutions and Mitigations:

Deployments hosted in Elastic Cloud have been updated to leverage the JVM Option -Dlog4j2.formatMsgNoLookups=true which will take effect on restart of the deployment and on any config change to the Elasticsearch deployment.

For users running a cluster on a minor version older than 7.2, we recommend a restart.

The simplest way to restart a deployment is to do the following:

1. Log in to the Cloud UI. Navigate to the “deployments” section in Elasticsearch Service.
2. Select the deployment you’d like to restart.
3. In the “manage” menu, select “restart”. Any kind of restart will work: “no downtime” restarts are fine.

Elasticsearch on Elastic Cloud mitigation summary matrix

Note: While the below mitigations are considered complete, our overall recommendation is to update to version 7.16.3 or 6.8.23 or newer.

Yes indicates the versions are subject to the vulnerability in question, No indicates they are not vulnerable. Version ranges are inclusive.

¹ Run a no-downtime restart on your deployment. Instructions here.

² Running a restart as in 1 will enable the system property in an abundance of caution.

7 posts - 2 participants

Read full topic

Interesting Data (26 pics)

Wolltet ihr schon immer mal sehen, wie in der Praxis ...

Wolltet ihr schon immer mal sehen, wie in der Praxis ein Hardware-Angriff auf einen ausgeschalteten Laptop mit Bitlocker Full Disk Encryption abläuft?

Hier hat das mal jemand schön nachgestellt.

Gen X Memes (31 pics)

People Who Really Good At Math (35 pics)

Perfect Calm Places To Spend Here Your Weekend (50 pics)

Habt ihr eigentlich von diesem Skandal gehört?Kanzlerkandidat ...

Habt ihr eigentlich von diesem Skandal gehört?

Kanzlerkandidat schreibt Buch? Gibt Leistung anderer als seine aus? Richtig mit Betrug und so! Hat den Erlös gespendet aber die Spendenquittung privat bei der Steuererklärung eingereicht.

Wie? Nein, nicht Baerbock.

Laschet!

Ich finde das ja großartig, wie du bei Politikern im Wesentlichen egal wo mal stochern kannst, und du wirst Skelette im Keller finden. Die Story wäre im Archiv vergammelt, wenn die Baerbock nicht mit ihrem Buch Anlass zur Archivexploration bei den anderen gegeben hätte.

James May hat ein wunderbares Ingenieursversagen beim ...

James May hat ein wunderbares Ingenieursversagen beim Tesla Model S gefunden.

Und zwar hat das Auto einmal ein fettes Batteriepack unter dem Boden für das elektrische Fahren, aber es hat auch eine reguläre Autobatterie vorne drin, die die Computersysteme betreibt.

Wenn man die Hauptbatterie lädt, dann lädt die auch die andere Batterie. Wenn man aber das Auto wegen Lockdown längere Zeit in der Garage stehen hat, dann ist die Hauptbatterie halt voll und bleibt auch voll und die Ladeelektronik schaltet sich ab. Dann wird auch die Zweitbatterie nicht geladen und die ist dann halt irgendwann alle.

In dem Video beschreibt er, was er alles abmontieren musste, um die Zweitbatterie zu laden.

Ganz großes Kino!

Grafik des Tages: Apple-Privacy-Labels von einigen ...

Grafik des Tages: Apple-Privacy-Labels von einigen Messenger-Apps.

Der neue Zwang zu Privacy-Statements ist wohl auch der Grund, dass es von Google keine Updates mehr gibt für ihre Apple-Apps.

Tibetan Throat Singing

Interesting Reaction

Verwendet hier jemand Bigbluebutton?Wer da Präsentationen ...

Verwendet hier jemand Bigbluebutton?

Wer da Präsentationen hochladen darf, hat Admin-Zugriff.

Update: Hanno Böck hat den Bigbluebutton-Leuten das im Mai (!) gemeldet. Seit dem sitzen die darauf. Stellt sich raus: Man kann da ne Präsentation hochladen und der Server öffnet das dann in Libreoffice. Lasst mich da völlig klar ansagen: DAS IST EINE FURCHTBAR SCHLECHTE IDEE. Dass das Projekt diese Idee überhaupt implementiert hat, ist für mich ein Zeichen, dass ich nie wieder mit Software interagieren will, bei der diese Leute Teil der Entscheidungsfindung waren. Die sind fürs Leben verbrannt. Das ist ungefähr so schlau wie im Winter einen Krieg gegen Russland zu starten. Nicht nur offensichtlich eine schlechte Idee sondern da sind sogar schon vorher andere mit auf die Fresse geflogen. Diese Officeformate sind eine einzige Schlangengrube und die Wahrscheinlichkeit, dass das irgendjemand anständig implementiert kriegt, ist sehr nahe an Null. Aber in diesem Fall musste gar kein Exploit her, denn die Dateiformate haben (völlig ohne Not, möchte ich anmerken!) ein Feature, über das man externe Ressourcen über eine URL einbinden kann. Da kann man natürlich auch eine file://-Url nehmen und sich beliebige Dateien auf dem Server anzeigen lassen.

Vom Niveau her ist das absolut am unteren Ende der Skala. Tiefer sinkt nur Cisco mit ihren ständigen Hintertüren und "vergessenen, versehentlich hart einkodierten Passwörtern".

Ein Leser fragt, ob nicht die EU mit Geld auf ein paar ...

Ein Leser fragt, ob nicht die EU mit Geld auf ein paar Entwickler werfen könnte, die dann die Servo-Engine und Rust weiterentwickeln, und wir perspektivisch einen vertrauenswürdigen Browser mit weniger Sicherheitslücken kriegen könnten, möglicherweise gar einen, der unsere Privatsphäre wahrt.

Finde ich eine gute Idee. Hey, wir haben doch gerade eine Bundesbehörde für Cybersicherheit gekriegt!!1! Mag da nicht mal jemand anfragen?

Denn das wäre aus meiner Sicht das wichtigste, was man auf absehbare Zeit für Cybersicherheit tun könnte. Wenn man den Leuten einen ordentlichen Browser in die Hand gäbt.

Food Facts (40 pics)

Hacker hacken ... Emotet. Also deren Infrastruktur. ...

Hacker hacken ... Emotet. Also deren Infrastruktur. Die Server, die die Malware-Binaries verteilen sollen. Die verteilen im Moment stattdessen animierte GIFs.

Irgendjemand rennt da gerade rum und löscht Leuten ...

Irgendjemand rennt da gerade rum und löscht Leuten ihre nicht passwortgeschützten Datenbanken, die sie im Internet hängen haben.

Ich kann da beim besten Willen kein Mitleid entwickeln.

Löschen erscheint mir auf jeden Fall weniger schlimm als wenn die Daten rausgetragen und dann an Spammer und Scammer verkloppt werden.

Just Use Finger

Immer noch schlechte Laune? Keine Sorge! Die Schlangenölindustrie ...

Immer noch schlechte Laune? Keine Sorge! Die Schlangenölindustrie liefert!

Exploiting Bitdefender Antivirus: RCE from any website

Der Schweizer Geheimdienstsumpf will unbedingt Threema ...

Der Schweizer Geheimdienstsumpf will unbedingt Threema abschnorcheln. Damit sind sie bisher gescheitert, zuletzt hat Threema vor dem Schweizer Bundesverwaltungsgericht gewonnen.

Leider zieht das EJPD (Eidgenössische Justiz- und Polizei-Departement) jetzt vor das Bundesgericht.

Ich drücke Threema ganz doll die Daumen. Das ist der einzige der großen Messenger, der nicht darauf besteht, dass man den Account mit der Telefonnummer assoziiert, und der auch nicht die Komplexität von Krypto hinter Bullshit-Automatismen versteckt (wie z.B. Signals "die Sicherheitsnummer hat sich geändert").

Von der Krypto her ist Signal noch ein bisschen cooler, aber Threema hat mehr dafür getan, das Vertrauen seiner Nutzer wirklich zu gewinnen, und nicht bloß Sicherheit zu behaupten. Ich habe in meinem Leben für eine einzige Smartphone-App Geld ausgegeben. Es war Threema.

Ich bin ja ehrlich gesagt sehr irritiert, dass die Schweizer Regierung das so kurz nach der Aufarbeitung des Crypto-AG-Skandals in der Presse wagt. Die letzten paar verbleibenden rauchenden Ruinen von Glaubwürdigkeit bezüglich Kryptografie in der Schweiz sind Threema. Die jetzt auch noch plattzumachen wäre ein irreparabler Rufschaden für die Schweiz.

Update: BTW: Glaubt mal gar nicht, dass nur die Schweizer Dienste freidrehen.

Das Niveau der Spionage gegen Deutschland sei auf dem Stand des Kalten Krieges oder sogar noch deutlich höher, schätzte Haldenwang.

Probleme mit Microsoft Outlook: Juni-Patches beschädigen PST-Dateien

Seit Microsoft seine Sicherheitsupdates für Juni 2020 freigegeben hat, leiden einige Outlook-Nutzer unter beschädigten PST-Dateien.

Slack Connect: Sicher mit externen Partnern zusammenarbeiten

Bei der Online-Zusammenarbeit zwischen Firmen hakelt es oft. Slack bietet nun eine Plattform, über die sich Geschäfte reibungslos abwickeln lassen sollen.