Sårbarhet kopplad till felaktig auktorisering i Atlassian Confluence

Varför denna exploit var så farlig

Incidenten CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server uppmärksammades först tisdagen den 31 oktober, men detaljerna var då mycket knapphändiga. Det var ett allvarligt problem med allvarlighetsgraden 9,1 (men endast destruktiv kapacitet angavs). Det bästa sättet att begränsa risken var att säkerställa en robust backupstrategi och ta bort din instans från internet om du inte kunde uppdatera till en patchad version, som fanns tillgänglig direkt.

Vid den här tidpunkten antar vi att den interna diskussionen liknade vår på Eficode. Vi trodde att det kunde handla om något i stil med en injektion av SQL-kommandon för att radera databasen. Oavsett vilket patchade vi i det tysta, meddelade våra kunder och gick vidare.

Atlassians försäkran om att kodexekvering och dataexfiltrering var omöjliga bidrog sannolikt till faran. Om de däremot förstod hur sårbarheten skulle utvecklas är okänt.

Vilseledande initial kommunikation och åtgärdsplaner

Att agera snabbt visade sig vara räddningen för Eficode. Leverantörer väljer ett av två sätt att sprida information. Antingen informerar de sina partner först, så att patchning kan ske i det tysta innan detaljer om exploiten blir offentliga, eller så går de ut brett för att säkerställa att informationen finns tillgänglig direkt.

I det andra fallet uppstår en kapplöpning mellan säkerhetsteam som försöker patcha och hotaktörer som försöker utnyttja sårbarheten. I det här fallet gav dock den initialt lägre allvarlighetsgraden ett visst andrum. Sårbarheten bedömdes som destruktiv, inte exploaterbar.

Men i slutet av veckan hade exploitens allvarlighetsgrad höjts till 10,0 och Remote Code Execution hade tagits fram som proof of concept. När detta skrivs finns färdiga, vapeniserade exploits lätt tillgängliga på GitHub.

Flera dagar efter att de första PoC:erna dök upp fick vi information om Ransomware-attacker.

När detta inträffade var Eficodes instanser redan patchade.

Brist på grundläggande säkerhetsåtgärder

Ransomware är naturligtvis i hög grad beroende av att ett företag saknar effektiva säkerhetsåtgärder. I det här fallet handlade det om backuper. En robust backuplösning är nyckeln till att snabbt och effektivt hantera Ransomware-attacker.

Inom cybersäkerhet finns ett begrepp: cybersäkerhetströtthet. Det innebär att medarbetare blir trötta på de åtgärder som krävs för att upprätthålla en säker plattform. Just detta fenomen leder till situationer där det saknas backuper, brandväggar inte implementeras och känsliga resurser är offentligt åtkomliga.

I takt med att säkerhetshoten och arbetet med att hantera dem fortsätter att öka, ökar också tröttheten. Detta syns tydligt inom DevOps, där team ofta består av tillfälligt sammansatta grupper av utvecklare och infrastrukturspecialister utan tydligt definierade säkerhetspolicyer.

Oåterkallelig dataförlust är den snabbaste vägen till ett företags insolvens hittills. Allt fler företag försöker undvika fakta och misslyckas med att erkänna att de numera är IT-företag, vid sidan av allt annat de tidigare var.

Ett sätt att komma runt detta är naturligtvis att använda en Managed Service-leverantör som Eficode, som driver dessa plattformar för hundratals företag och omfattar tjänster som Jira, Confluence, Bitbucket, GitLab, GitHub, Jenkins och andra hostade DevOps-applikationer.

Hur instanser upptäcks

En av de första åtgärderna för att begränsa denna sårbarhet var enkel: ta bort den från det publika internet. Det är alltid ett bra sätt att minska attackytan, men det förutsätter att du alltid kan lita på alla medarbetare i företaget.

Med tanke på risken för interna attacker och företagsprofiler är det lätt att tro att sådana attacker är riktade. Men för det mesta stämmer det inte. Det handlar om enkla, opportunistiska attacker. Verktyg som Shodan.io fungerar som sökmotorer, inte för information utan för maskiner som är anslutna till internet.

Sökning efter:

Confluence "country:fi"

visar flera hundra öppna Confluence-instanser på det publika internet bara i Finland. Utan filtret får vi tiotusentals.

Så utnyttjas sårbarheten

Det visade sig vara extremt enkelt att utnyttja problemet: att skicka en enda HTTP POST-förfrågan till följande endpoint:

/json/setup-restore.action

med följande header angiven:

"X-Atlassian-Token": "no-check",

Confluence-administratörer använder denna endpoint för att återställa webbplatsen från en komprimerad backup, som laddas upp i förfrågans data. Vanligtvis skyddas en administrativ endpoint av någon form av autentisering. I de berörda versionerna saknas dock en sådan säkerhetsåtgärd.

Det räcker att lägga in en komprometterad Confluence-backup som innehåller skadliga plugins, till exempel Web Shell Plugin som ofta används i den här attacken, för att genomföra attacken.

Så minskar du risken

Det finns flera sätt att minska risken. Att uppdatera till en ny version är det säkraste alternativet. Om det inte är möjligt är det bra att ta bort instansen från det publika internet för att minska attackytan, även om det inte helt eliminerar risken.

Att blockera följande URL:er på nätverksnivå stoppar också exploateringen baserat på aktuell

/json/setup-restore.action/json/setup-restore-local.action/json/setup-restore-progress.action

Det säkraste är dock att helt enkelt uppdatera till den senaste korrigerade versionen.

Vad händer härnäst för mig som användare?

Om du har uppdaterat till en korrigerad version bör din Confluence-instans vara säker. Du kan hålla dig uppdaterad genom Atlassians säkerhetsnotiser. Liknande flöden finns för de flesta DevOps-verktyg.

Men om dina team lider av cybersäkerhetströtthet kan du också anlita en leverantör av Managed Services som tar hand om sådant här. Då får dina utvecklare mer tid till det de gör bäst: att skriva fantastisk kod.

Vad händer härnäst inom säkerhet?

Den här sårbarheten visar på ett problem i cybervärlden, som kan sammanfattas i en enkel fråga: Vad har den här exploateringen och Log4Shell gemensamt?

Båda har allvarlighetsgraden 10,0.

Ändå lamslog Log4Shell internet i flera veckor, medan den här exploateringen är relativt väl under kontroll. Vad är skillnaden?

Det visar sig att det vanligaste måttet inom cybersäkerhet för att bedöma incidenter, CVSS (Common Vulnerability Scoring System), bara mäter en sak: påverkan per system.

Vi saknar ett sätt att mäta hur utbredd en attack är. Så länge vårt enda betydande mått är hur allvarlig en exploatering kan vara när den är aktiv i systemet kommer vi att stöta på förvirrande fall som detta: en allvarlighetsgrad på 10,0 påverkar några tusen Confluence-installationer, medan Log4j fanns installerat i miljontals system.

Cybersäkerhetsbranschen bör utveckla mått för omfattning och påverkan som kompletterar CVSS-poängen, så att dessa incidenter – och deras konsekvenser – blir tydligare.

Säkerhet för Atlassian Data Center med Eficode ROOT

Avslutningsvis är det värt att nämna hur Eficode ROOT kan göra vardagen enklare i dessa utmanande tider för cybersäkerhet. Se det som att ha ett dedikerat team som alltid har koll på exempelvis patchen för CVE-2023-22518. Teamet hanterar säkerhetsuppdateringar smidigt och snabbt som en del av det dagliga arbetet. Det innebär att du kan fokusera på din kärnverksamhet, med tryggheten att säkerheten hanteras utan extra stress eller arbete.