Weitgreifende Sicherheitslücke in Java Anwendungen

Angreifbarkeit der Atlassian Toolchain

Liebe Kund*innen, verehrte Partner*innen,

zu Ihrer Sicherheit informieren wir Sie über eine aktuelle Sicherheitsbedrohung, die wir gemeinsam beobachten sollten (Einstufung BSI: Die IT-Bedrohungslage ist extrem kritisch. Ausfall vieler Dienste, der Regelbetrieb kann nicht aufrecht erhalten werden).

Am 9. Dezember 2021 wurde in der sehr verbreiteten Java-Bibliothek log4j eine Schwachstelle gefunden, die es erlaubt, Programmcode auszuführen (Remote Code Execution).

Nach aktuellen Kenntnissen wurde die gefundene Schwachstelle bereits – auch auf Grund ihrer einfachen Nutzbarkeit – durch Angreifende ausgeführt.
Hierfür reicht es schon aus, eine entsprechend manipulierte Anfrage an das betroffene System zu schicken.

Ferner ist aktuell eine ansteigende Menge von Scans auf aus dem Internet erreichbare und verwundbare Systeme festzustellen. Zudem steht der notwendige Code zur Ausnutzung öffentlich zum Download bereit. Da diese Lücke durch die jeweiligen Softwarehersteller behoben werden muss, ist davon auszugehen, dass noch viele verwundbare Systeme existieren.

Uns bei it-economics ist Ihre Sicherheit ein großes und wichtiges Anliegen, so dass wir seit Veröffentlichung der Verwundbarkeit sofort mit der Analyse der betroffenen Kundensysteme begonnen haben.

Da Teile der betroffenen Bibliotheken auch in den Produkten des Herstellers Atlassian eingesetzt werden, ist eine genaue Untersuchung dieser Anwendungen unabdingbar.

Nach aktueller Aussage von Atlassian besteht keine Gefahr für On-Premise-Kunden, sofern keine Anpassungen im Bereich des Loggings durchgeführt wurden.

Sollten Sie Anpassungen vorgenommen haben, kontaktieren Sie uns bitte für Unterstützung.

Die betroffene Bibliothek log4j wird in einer Vielzahl von weit verbreiterer Standardsoftware eingesetzt:

  • Apache Struts
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • ElasticSearch
  • Flume
  • Apache Dubbo
  • Logstash
  • Kafka
  • Spring-Boot-starter-log4j2

Is my on-premises Server/Data Center instance affected?

Our Security team investigated the impact of the Log4j remote code execution vulnerability (CVE-2021-44228) and have determined that no Atlassian on-premises products are vulnerable to CVE-2021-44228.

Some on-premises products use an Atlassian-maintained fork of Log4j 1.2.17, which is not vulnerable to CVE-2021-44228. We have done additional analysis on this fork and confirmed a new but similar vulnerability that can only be exploited by a trusted party. For that reason, Atlassian rates the severity level for on-premises products as low. Specifically, Atlassian products that use Log4j 1.x are only affected if all of the following non-default configurations are in place:

  • The JMS Appender is configured in the application’s Log4j configuration
  • The javax.jms API is included in the application’s CLASSPATH
  • The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application’s configuration, or by trusted code setting a property at runtime

The following products use the Atlassian-maintained fork of Log4j 1.2.17:

  • Bamboo Server and Data Center
  • Confluence Server and Data Center
  • Crowd Server and Data Center
  • Fisheye / Crucible
  • Jira Server and Data Center

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.

How can I mitigate this exploit?

If you’re using the functionality provided by JMS Appender we recommend you mitigate the vulnerability as soon as possible by temporarily disabling any configured appenders utilizing org.apache.log4j.JMSAppender by commenting out the relevant lines in your Log4j configuration file and restarting the application. In a Data Center environment, a rolling restart of the nodes is sufficient after updating affected configuration files.

The default location of the Log4j configuration file for each product is listed in the table below:

ProductDefault Path
Bamboo Server & Data Center/atlassian-bamboo/WEB-INF/classes/log4j.properties
Confluence Server & Data Center/confluence/WEB-INF/classes/log4j.properties
Crowd/crowd-webapp/WEB-INF/classes/log4j.properties
/crowd-openidclient-webapp/WEB-INF/classes/log4j.properties
/crowd-openidserver-webapp/WEB-INF/classes/log4j.properties
Fisheye / Crucible/log4j.xml
Jira Server & Data Center/atlassian-jira/WEB-INF/classes/log4.properties

How can I tell if my system has been compromised?

Unfortunately, Atlassian cannot confirm if your instance has been compromised. All security compromises are different, and we strongly recommend involving your local security team or a specialist security forensics firm for further investigation.

https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

Da eine Infektion seitens Atlassian jedoch auch ohne Anpassungen nicht auszuschließen ist, haben wir für unsere Kunden eine Notfallhotline eingerichtet, unter der eine Erstberatung vereinbart werden kann:

Sie erreichen uns unter 089 – 215 488 009 oder 

Für alle Kunden, die sich bei uns in einem Managed Hosting, beziehungsweise Managed Service Vertrag befinden kümmern wir uns automatisch um die Bereitstellung und Installation aller relevanten Security-Patches.

Weitere Details zur Sicherheitslücke CSV- 2021-44228 (Score 9.8/10) finden Sie unter:
https://www.lunasec.io/docs/blog/log4j-zero-day/) bzw.

https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/ oder beim BSI.

Mögliche Hinweise auf eine Ausnutzung der Schwachstelle finden Sie in den Zugriffslogs Ihrer entsprechenden Applikation.

Sofern es weitere Updates gibt, werden wir Sie in diesem Post auf dem Laufenden halten.

Sichere Grüße,
Ihr Atlassian und DevOps-Team von it-economics

Update vom 14.12.2021

Nach Prüfung durch Atlassian sind die on-Premise-Installationen, welche keine Anpassungen bezüglich Logging besitzen, von der Sicherheitslücke nicht betroffen, da hier eine angepasste und sichere Variante von log4j im Einsatz ist.