Atlassian waarschuwt voor kritiek zerodaylek in Confluence Server en Data Center

Beveiligingsonderzoekers hebben een kritieke kwetsbaarheid in Confluence Server en Confluence Data Center van Atlassian aangetroffen. Volgens Atlassian wordt de zerodaykwetsbaarheid actief misbruikt.

Alle huidige versies van Confluence Server en Confluence Data Center zijn getroffen door het beveiligingsprobleem, dat kwaadwillenden in staat stelt een exploit te starten en op afstand willekeurige code uit te voeren met rechten van de applicatie. Er is op het moment van schrijven nog geen patch voor het beveiligingsprobleem. Volexity, het beveiligingsbedrijf dat het lek heeft ontdekt, adviseert bedrijven de externe toegang tot Confluence Server uit te schakelen.

Atlassian meldt bekend te zijn met de kwetsbaarheid en spreekt de verwachting uit dat fixes voor de ondersteunde versies van Confluence binnen 24 uur beschikbaar zijn voor klanten. Ook Atlassian adviseert gebruikers om de externe toegang tot Confluence Server- en Confluence Data Center-instances uit te schakelen. Als alternatief wijst het bedrijf op het geheel uitschakelen van deze instances totdat er een fix beschikbaar is.

Volgens het Nationaal Cyber Security Centrum gaat er voor zover bekend nog geen proof-of-concept rond op internet. Volexity beschrijft hoe het de kwetsbaarheid ontdekte nadat een klant melding had gemaakt van verdachte activiteit met betrekking tot twee webservers die Confluence Server draaiden. Daaruit blijkt dat het lek wel al in de praktijk wordt misbruikt. De kwetsbaarheid heeft de aanduiding CVE-2022-26134 gekregen.

Confluence is software die teams in staat stelt om online samen te werken aan projecten. Data Center draait on-premise en op clouddiensten zoals Azure en AWS; Server is de beperktere voorganger die Atlassian niet meer verkoopt en ook niet verder ontwikkelt. Atlassian benadrukt dat Confluence Cloud, waarbij het de hosting zelf verzorgt, niet kwetsbaar is.

Reacties (40)

[MG88]

De fix is inmiddels vrijgegeven:
Confluence Security Advisory 2022-06-02

[Cybje]

Dit stukje op hun site levert ook wel wat vraagtekens op:

If you are unable to take the above actions implementing a WAF (Web Application Firewall) rule which blocks URLs containing ${ may reduce your risk.

Zou dit een overgebleven log4j dingetje zijn? Dan hebben ze echt hun dependency management niet op orde namelijk.

[bergamot]

Confluence maakt gebruik van Apache Velocity.
Binnen deze Java-gebaseerde template engine kun je naar variabelen refereren met de ${...} syntax.
Zie ook hier.

[Reactie gewijzigd door bergamot op 22 juli 2024 16:18]

[NoControl]

Het eerste waar "${" mij aan doet denken is Bash parameter expansion. Misschien een stukje shell-script-lijm tussen processen dat geen correcte escaping toepast?

[beerse]

Het eerste waar "${" mij aan doet denken is Bash parameter expansion. Misschien een stukje shell-script-lijm tussen processen dat geen correcte escaping toepast?

Dat het jou aan bash doet denken zegt meer over jou dan over bash. Er zijn bijna meer computer talen die met ${...} werken dan talen die dat niet gebruiken. Unix en dus ook linux gebruikt dat zo ongeveer als standaard in de meeste daar bekende script talen. Daarnaast is het ook bij veel programmeer talen zo gebruikelijk dat je het ook vaak ziet langs komen in pseudo-code.
Nu ken ik de ontstaan geschiedenins van powershell niet, maar ook daar is het de standaard voor variabelen.

[Sando]

Dat het jou aan bash doet denken zegt meer over jou dan over bash.

Het klopt dat string interpolation niet exclusief in bash gebeurt, maar je bent wel een beetje streng in je reactie.

Bash/sh/unix kan dit al sinds de jaren '70.
Powershell bestaat pas sinds 2005.
Javascript kan dit pas sinds 2015.

Misschien zegt het toch wel wat over bash/sh/unix, namelijk dat het van grote invloed is geweest.

[Reactie gewijzigd door Sando op 22 juli 2024 16:18]

[Bulkzooi]

Het eerste waar "${" mij aan doet denken is Bash parameter expansion. Misschien een stukje shell-script-lijm tussen processen dat geen correcte escaping toepast?

...

Het klopt dat string interpolation niet exclusief in bash gebeurt, maar je bent wel een beetje streng in je reactie.

Bash/sh/unix kan dit al sinds de jaren '70.
Powershell bestaat pas sinds 2005.
Javascript kan dit pas sinds 2015.

Misschien zegt het toch wel wat over bash/sh/unix, namelijk dat het van grote invloed is geweest.

Hij is ook niet correct. Er zijn nl. meer OS'es dan Unix en GNU/Linux, zeker historisch gezien.

${...} is dus generieke pseudo code om "environment variables" te declareren aan het begin van een file zodat de compiler weet wat te doen. De $ staat voor variabele en de {...} staat voor een arbitraire functie. Dergelijke instructies zijn welbekend in vele file formats, en staan aan het begin.

En overigens, scripting bestondt al met ALGOL60, nog ouder en komend vanaf IBM. Een beetje ten tijde van de verschuiving van mainframe naar home computing, of personal computing. Bovendien had je voor het object-georiënteerde Powershell van Microsoft, ook al de gewone Shell in DOS, die gewoon lineair interpreteerde. En Python biedt de mogelijkheid "parameter expansion for string manipulation" al langer dan Javascript dat heeft. Bovenal kunnen meerdere talen dit, zoals PERL of nieuwere talen zoals Rust.

Qua programmeren is die feature niet beperkt tot voor scripten, denk ook aan Query languages. Betreft ook een beetje de succesverhalen van Lisp en Clojure, zeker in combinatie met een POSIX shell. Maar omvat ook vele industriebrede discussies, helemaal terug naar die van de GOTO statement.

Waarom denk je dat RMS altijd zo hamerde op GNU/Linux, i.t.t. "gewoon" linux? Indeed, the GCC (en/of binutils). Maar nou heb je een filosoof als Plato nodig om nog effe encyptie en zo uit te leggen.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:18]

[beerse]

Naar mijn geheugen bestaat bash toch pas sinds het begin van deze eeuw? In de jaren '70 (1969 zelfs al) hadden we /bin/sh, de bourne shell. Daarna (en vooral daar naast) kwam de c-shell (/bin/csh) maar die werd vooral interactief gebruikt, minder in scripting. Dat is samen gevoegd in de korn-shell (/bin/ksh) ergens in de jaren 1990. Pas bij het opkomen van linux is bash ook boven komen drijven als opvolger van de korn-shell, misschien ook wel omdat die een niet zo vrije licentie had. Wel gebruiken ze allemaal ${Variabele} namen.

Leuk dat je powershell noemt. Vorige maand had ik een collega script-hacker die mijn powershell script van binnen bekeek en daar het gebruik van ${variabele} zag. Had hij in powershell nog nooit gezien, gebruikt zelf alleen maar $variabelen...

[lecrab]

Ik kwaak mogelijk onzin, maar ik las op the register dat men heeft gezien dat een bash shell werd opgestart, die python startte en daaruit weer een bash kon starten. Misschien is dat gerelateerd, maar mijn expertise is het zeker niet.

[wica]

Hoeft volgens mijn niet. er zijn wel meer systemen die ${....} als iets specials behandelen.
Daarnaast, als het met log4j te maken had, was er denk ik wel een update geweest.

[Keypunchie]

Atlassian benadrukt dat Confluence Cloud, waarbij het de hosting zelf verzorgt, niet kwetsbaar is.

Zal vast wel kwetsbaar zijn, maar door de web application firewall worden afgevangen.

[Roy23]

Altijd zo fijn dat ze eerst hun eigen cloud product patchen (dmv een work around of een daadwerkelijke patch) en dan pas naar buiten brengen dat je on premise product vatbaar is voor een kwetsbaarheid... Gebeurd ook vaak wanneer Microsoft een probleem heeft, zoals laatst met Exchange.

Weer een slimme truc om mensen naar hun cloud producten te lokken.

[Mellow Jack]

Das wel een heel snelle conclusie

In hun eigen cloud kunnen ze een vieze hack uithalen of ze kunnen iets tussen de gebruiker en de dienst plaatsen als mitigerende maatregel. Zoals hierboven al wordt gesuggereerd. Als je de link in het artikel bekijkt lijkt het idd alsof ze een WAF regel hebben geimplementeerd. Mja niet iedereen heeft een WAF

[Roy23]

Hoezo is dat een snelle conclusie?
Op het moment dat zij het bericht wereldkundig maken geven ze al aan dat hun eigen cloud product niet kwetsbaar is.
Dan weet je toch dat ze iets ontdekt hebben, eerst een analyse gedaan van de impact, daarna op hun cloud systeem een patch of workaround uitgevoerd en daarna pas is dit bericht wereldkundig gemaakt?
Oftewel, op het moment dat het bij het grote publiek bekend wordt is het bij hun eigen cloud product al gemitigeerd. Dat is wel een bewuste keuze. Er is namelijk ook een moment geweest dat zowel hun cloud product als de on premise producten kwetsbaar waren, maar ze hebben op dat moment niets gezegd.

[wica]

Sowieso, kan je op je eigen platform. Gemakkelijker testen en daarmee patches doorvoeren, dan bij een klant.
Maar wat Atlassian zeer waarschijnlijk gedaan heeft. Is een workaround in hun WAF gezet. Waardoor url's met ${ er in geblokkeerd worden. Deze workaround kan iedereen gebruiken.

[Ludewig]

Het kan natuurlijk ook zo zijn dat hun cloud-systeem al niet kwetsbaar was doordat ze bepaalde URLs al wegfilteren.

[Mellow Jack]

Verschil tussen hun cloud product en cloud infrastructuur. Ik weet het gewoonweg nog niet.

Ze (de onderzoekers) hebben op 31 mei een melding gedaan. Geen idee hoe laat en in welk land dus ong 3 tot 4 dagen geleden. Ze zeggen dat Atlaissian het heeft erkend maar laten in het midden wanneer precies. Atlassian geeft daarna toe dat ze hun cloud product niet hebben gefixed maar een mitigerende maatregel hebben genomen in hun cloud infrastructuur (WAF). Dat geven ze ook gelijk als advies voor hun klanten.

Dus los van mijn mening over security van atlassian tools (niet heel positief) kan het in deze situatie best zijn dat ze accuraat hebben geacteerd. De mitigerende maatregel die ze hebben genomen is letterlijk 1 regel in de WAF die je (o.b.v. een SEV1 incident) binnen 5 minuten erin heb zitten

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 16:18]

[mijsk1974]

Ik mag hopen dat ze eerst een analyse maken en de impact hebben bepaald alvorens deze wereldkundig te maken. En elk goed bedrijf zal toch echt proberen om, alvorens slapende honden wakker te maken, enige kwetsbaarheden in de eigen systemen te dichten. Zij hebben ook een verplichting naar de reeds bestaande klanten van hun cloud oplossing.

Dat sluit niet uit dat je ongelijk hebt maar het proces zal vaak, zo niet altijd, zo worden uitgevoerd omdat dit een logische methode is ongeacht de achterliggende motieven.

Ondertussen zal je vast gelijk hebben dat een paar honderd medewerkers moedwillig meewerken aan een duivels plan ten gunste van de eigen cloud oplossing. Een actie die niet alleen strafbaar is maar ook nog eens geheimhouding vereist van diezelfde medewerkers.

Maar dat wil niet zeggen dat je ongelijk hebt.
De apotheek belde overigens, je medicijnen liggen klaar.

[YGDRASSIL]

Ze testen de patch dus eerstop hun eigen cloud. Lijkt me prima

[DutchieSmokah]

Vanaf 15 February 2024 zijn de server producten van Atlassian sowieso EOL/EOS en supporten ze enkel hun producten in de Cloud

[GeroldM]

Helaas maar waar.

Heb klanten die absoluut niet willen dat de voor hen bedoelde code op welke manier dan ook op een cloud-drive terechtkomt. En ben zelf ook niet zo'n groot voorstander van alles maar in de cloud te schieten. Waar het nuttig is, daar wil ik het best wel gebruiken. Maar om klanten geen aanleiding tot zeuren te geven, begin ik er niet aan.

Maar deze move van Atlassian, die komt wel aan, want gebruik Jira on-prem al ruim 10 jaar en moet door hun stap op zoek naar een alternatief.

[DutchieSmokah]

Geldt voor ons precies hetzelfde. Echter, vind maar een keer een goed alternatief (vooral als je ook nog veel leunt op add-ons/plugins)... Verwacht dan ook een uiteindelijk migratie bij ons richting Cloud bij gebrek aan alternatief.

[anvil]

Onzin, je kunt ook gewoon een datacenter license nemen ( wel prijs 2 maal zo hoog als server ) en gewoon on premise blijven draaien.

[DutchieSmokah]

Thanks voor het berichtje, wist nog niet van het bestaan van deze licentie!

[anvil]

Graag gedaan. Licenties zijn grofweg 2x zo duur. Wel krijg je soms wat extra mogelijkheden zoals een product in High Availability te kunnen draaien.

Upgraden is soms kwestie van nieuwe license key, soms een echte migratie (export-import)

[Frame164]

Hier zie je direct het voordeel van cloud tov onprem

[Roy23]

En dat is dus niet waar, maar deze manier van communiceren doet dat wel vermoeden.

Wat je hier ziet is dat de ontwikkelaar het lek stil houdt tot aan het moment dat hij zijn cloud dienst heeft gepatched of anders heeft beveiligd, en daarna publiceert dat er een lek is, en dat on premises installaties kwetsbaar zijn maar hun cloud product niet.
De volgorde van communiceren en de keuzes die de ontwikkelaar maakt maken dat het cloud product als eerste gepatched is, maar het is niet zo dat per definitie een cloud product veiliger is.

[johnny2000]

Tja natuurlijk hebben ze een voordeel. Maar het is ook het eat-your-own-dog-food principe. Dus in principe weet je als onpremise gebruiker dat je een redelijk geteste versie hebt. Uitzonderingen daar gelaten 😉

[oef!]

Tja, als ze een workaround of fix hebben, waarom niet? Dit is wat hun cloud klanten zouden willen/eisen.

[Bulkzooi]

@Roy23 Kan ook niet anders; ze beheren de source code. En daarna gaan pas de externe servers upgraden, als de patch beschikbaar is, maar niks weerhoudt onpremise gebruikers ervan om hun geforkte code zelf te patchen, zoals bv. Cloudfare dat doet.

Dit is niet anders dan bv. Gitlab, en dit probleem heeft dan ook dezelfde aard. Maar dit probleem is complexer omdat er addons of auxiliary frameworks ingecompiled kunnen worden.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:18]

[Moartn]

Of al gepatched.

[Keypunchie]

Dan zouden ze die patch toch al beschikbaar hebben gemaakt?

[Anonymoussaurus]

Het zou ook kunnen gaan om een patch welke getest wordt en dus nog niet voor het grote publiek beschikbaar is.

[tele-n-ettertje]

"Data Center draait op clouddiensten zoals Azure en AWS; Server is bedoeld om te draaien op eigen hardware van de organisatie."
Nieuwe "server" licenties worden al meer dan een jaar niet meer verkocht, enkel verlengd en tegen 2024 is het helemaal gedaan met server. Wij draaien "data center" op eigen hardware, dus de uitleg in het artikel is niet helemaal correct.

[Frame164]

Hoe het wordt geleverd hangt ook af van wat voor klant je bent. Als je maar belangrijk genoeg bent kan er altijd meer.

[pang-frang-punk]

Belangrijk om hierbij te vermelden is de nota dat deze kwetsbaarheid niet geldt voor de door Atlassian gehoste versies van confluence:
Atlassian Cloud sites are protected
If your Confluence site is accessed via an atlassian.net domain, it is hosted by Atlassian and is not vulnerable. Our investigations have not found any evidence of exploitation of Atlassian Cloud.

Edit: ik zie nu dat het in de laatste zin van het artikel staat, maar dit mag wel stevig benadrukt worden.

[Reactie gewijzigd door pang-frang-punk op 22 juli 2024 16:18]

[RobinJ1995]

Heeft deze enorm populaire wiki-software een goede editor? Nee.
Maar wel een goede zoekfunctie? Well... No.
...
Maar hij heeft wel een ingebouwde compiler om arbitraire code te draaien

[Bulkzooi]

Die compiler en historische vertrekpunten en/of de andere software binnen de infrastructuur zijn de meest voorkomende argumenten om voor dit product te kiezen ipv voor gitlab. De initiële behoefte is mn. projectmanagement bij de source code en haar versiebeheer. Meestal komen gebruikers van bitbucket of zo. Een beetje de typische JAVA workflow.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:18]

[aikebah]

De initiele behoefte is documentatie bij Confluence. Voor projectmanagement grijp je toch logischer naar Jira met plugins dan naar Confluence lijkt me als je in de Atlassian stack zit.

[Bulkzooi]

Klopt; documentatie in menselijke taal maakt het schrijfsysteem voor alles wat interpreteert.

JAVA heb ik voor eigen gebruik nooit overwogen o.a. vanwege die idiote runtime die je moest draaien. .NET framework heb ik overigens ook niet op mijn systeem dus ik ben geen specialist en heb mijn meeste informatie van de Joël Spolsky blogs. Maar als JAVA programmeur of Atlassin klant zijn het rechtvaardigbare keuzes.

Maar ook C programmeurs/projecten die niet naar C++ waren geconverteerd, m.a.w. veel embedded code, kregen steeds meer problemen om lokaal source control te draaien, om de steeds maar uitdijende software projecten te managen. Ken je de Linus Thorvald verhalen over GIT nog? Daarna was de ICT belandt in een styleguide discussie en een conversie naar web3. De bsd-like Apple approach heeft me altijd meer aangesproken, met Xcode en zo.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:18]