Onderzoek van Avisi naar Log4Shell kwetsbaarheid binnen Atlassian-applicaties

Op 9 december 2021  is er een nieuwe beveiligingslek gevonden in Log4J, een zeer populair logging framework binnen de Javawereld. Log4J wordt veel gebruikt binnen alle op Java gebaseerde applicaties, waaronder ook Confluence en Jira. In deze blogpost volgt een uitleg over wat de impact is van het lek en in hoeverre applicaties van onze klanten geraakt worden.

Het lek in Log4J is uitgewerkt in CVE-2021-44228. Door het Nationaal Cyber Security Centrum (NCSC) is deze kwetsbaarheid geclassificeerd als Hoog, zowel de kans dat het misbruikt wordt als de schade die het veroorzaakt. De kwetsbaarheid is relatief simpel te misbruiken en geeft kwaadwillenden de mogelijkheid om op de server code uit te voeren (remote code execution ofwel een zogenaamde RCE-kwetsbaarheid).

Het beveiligingslek in Log4J kan misbruikt worden door de kwetsbare applicatie een regel te laten loggen met een bepaalde inhoud. Deze logregel dient dan een verwijzing naar een bepaalde server te bevatten wat Log4J triggert om deze server te proberen te benaderen. Door hier een server te noemen die geïnfecteerd is is de hacker in staat om via die verbinding code uit te voeren op de applicatieserver.

Atlassian

Inmiddels heeft ook Atlassian onderzoek gedaan naar de impact van deze kwetsbaarheid op de Atlassian applicaties. Dit onderzoek hebben ze gepubliceerd in hun documentatie. Daarin wordt aangegeven dat klanten enkel en alleen kwetsbaar zijn als ze de JMSAppender class gebruiken als log appender. Standaard wordt deze class niet gebruikt door Atlassian in hun applicatie configuratie van Jira, Confluence, Bitbucket en Bamboo.

Hoewel Atlassian dus aangeeft niet kwetsbaar te zijn, valt in een blogpost van LunaSec te lezen dat dit geen garantie voor de toekomst is. Er valt op dit moment gewoon nog niet veel te zeggen over mogelijke toekomstige ontdekkingen. Daarom, zegt LunaSec, is het verstandig om nu al een mitigerende maatregel door te voeren. Instructies zijn verderop in deze blog te vinden.

ElasticSearch

Hoewel Bitbucket zelf niet kwetsbaar is (Bitbucket gebruikt Logback in plaats van Log4J), is inmiddels wel gebleken dat ElasticSearch kwetsbaar is. ElasticSearch wordt door Bitbucket gebruikt als implementatie voor de zoekfunctionaliteit. ElasticSearch heeft hiervoor een Security Advisory aankondiging uitgebracht. In het kort zegt ElasticSearch hier het volgende over:

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. 

Klanten die ElasticSearch apart hebben geïnstalleerd op een aparte server van Bitbucket en die een oudere versie van ElasticSearch hebben of deze op een oudere JVM hebben draaien, moeten hun ElasticSearch installatie bijwerken. Klanten die gebruik maken van de interne ElasticSearch van Bitbucket lopen op dit moment geen gevaar omdat Bitbucket op een versie van ElasticSearch zit (7.10.2 in Bitbucket 7.17.4 LTS) die niet kwetsbaar is.

Avisi Full operational service

Binnen Avisi Full Operational Service is Avisi verantwoordelijk voor de hosting van de applicaties namens de klant. Hier zijn inmiddels passende maatregelen genomen richting klanten.

Mitigerende maatregel

Zoals reeds aangegeven is het advies om sowieso de oorzaak van deze kwetsbaarheid weg te nemen. Standaard staat Log4J toe dat er verbinding wordt gemaakt met het internet. Dit maakt het mogelijk om de kwetsbaarheid te benutten. Door dit standaard gedrag uit te zetten zullen deze lookups niet meer gedaan worden en krijgen aanvallers geen kans meer.

Dit gedrag uit zetten kan door een speciale setting mee te geven aan de JVM. Het gaat om de volgende setting:

log4j2.formatMsgNoLookups=true   

Hieronder is per applicatie aangegeven welke files aangepast moeten worden.

Jira

Pas de file setenv.sh aan in de /conf directory binnen de installatiedirectory van Jira en pas de volgende regel aan:

# Haal indien nodig uit commentaar 
JVM_SUPPORT_RECOMMENDED_ARGS=" -Dlog4j2.formatMsgNoLookups=true" 

Confluence

In Confluence dient ook de setenv.sh aangepast te worden op de volgende regel:

CATALINA_OPTS=$CATALINA_OPTS -Dlog4j2.formatMsgNoLookups=true 

Bitbucket

Bitbucket zelf is niet kwetsbaar omdat het geen gebruik maakt van Log4J. Maar ElasticSearch blijk wel kwetsbaar te zijn. Om dit op te lossen dient de file _start-search.sh aangepast te worden met de volgende regel:

export ES_JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true" 

Bamboo

Pas de file setenv.sh aan in de /conf directory binnen de installatiedirectory van Bamboo en pas de volgende regel aan:

# Haal indien nodig uit commentaar
JVM_SUPPORT_RECOMMENDED_ARGS=" -Dlog4j2.formatMsgNoLookups=true" 

Atlassian Cloud

Binnen de Atlassian Cloud is Atlassian zelf verantwoordelijk voor monitoring en oplossing van kwetsbaarheden in alle componenten, en zal zo snel mogelijk acteren op gevonden kwetsbaarheden, conform hun Security Bugfix Policy. Daarbij zullen beschikbare security patches altijd eerst op de Cloud omgeving worden uitgerold alvorens deze ter download beschikbaar te stellen aan overige klanten. Op dit moment is Atlassian bezig zoveel mogelijk klanten te migreren naar Cloud als onderdeel van hun Cloud-First strategie. Avisi kan klanten helpen om ook van deze voordelen gebruik te maken. Op onze Cloud Migration pagina is te lezen hoe we dat aanpakken. Neem contact met ons op om de mogelijkheden te bespreken.