Atlassian patcht ernstige remotecode-executionbug in Confluence en Jira

Meerdere oudere versies van bedrijfssoftware van Atlassian zijn kwetsbaar voor een ernstige remotecode-executionbug. De bug zit in onder andere Confluence en maakt het mogelijk voor een aanvaller om zonder authenticatie code uit te voeren op een server.

Atlassian waarschuwt voor die kwetsbaarheid, die wordt getrackt als CVE-2023-22527. Ook het Nationaal Cyber Security Centrum en het Digital Trust Center waarschuwen voor de gevolgen van die bug, die een CVSS-score van 10 krijgt en daarmee als een zeer hoog risico wordt ingeschaald. Volgens Atlassian zijn versies 8.x en ouder kwetsbaar, vanaf versies 8.5.0-8.5.3. Het bedrijf heeft daar inmiddels een patch voor uitgebracht en raadt beheerders aan die zo snel mogelijk door te voeren.

De kwetsbaarheid is een bug in verschillende softwarepakketten van Atlassian, waaronder vooral Confluence en Jira. Het gaat om een bug die een remotecode-execution mogelijk maakt. Door de bug uit te buiten, is het mogelijk voor aanvallers om van een afstand zonder authenticatie code uit te voeren. Het NCSC noemt onder andere denial-of-serviceaanvallen of het stelen van gebruikersgegevens als mogelijke risico's. Atlassian geeft geen details over hoe de kwetsbaarheid werkt, maar zegt dat het gaat om een template-injectionbug.

Inmiddels is er online een proof of concept verschenen van de bug, al bevat die nog geen werkende exploit. Wel wordt daarin uitgelegd hoe de kwetsbaarheid misbruikt kan worden. Om die reden acht het NCSC het risico op misbruik als hoog. Het Digital Trust Center waarschuwt dat de schade bij misbruik aanzienlijk kan zijn.

Securitybedrijf Shadowserver stelt dat er in Nederland in ieder geval 180 Confluence-omgevingen benaderbaar zijn via internet. Daar vallen ook omgevingen onder die kwetsbaar zijn.

Reacties (47)

[Griffin]

Kleine side note, dit geld alleen voor de OnPremise installaties van Jira & Confluence. De omgevingen op de cloud hebben hier geen last van (aldus Atlassian https://confluence.atlass...ce-server-1333990257.html)

Wat betreft Jira & Confluence als product. Wij gebruiken het al geruime tijd voor Implementatie van de Product & Sprint Backlog (en Confluence voor de wiki) en ik moet zeggen het voldoet erg goed. Maar het staat of valt bij een goede inrichting (iets wat bij Azure DevOps nog veel meer het geval is)

[konfig0]

Volgens die pagina valt Jira overigens niet onder deze bug, op die pagina staan alleen de producten:

• Confluence Data Center
• Confluence Server

Ik denk dat er wellicht wat verwarring is met andere bugs die in de Security Bulletin zijn benoemd op 16 januari, maar wel andere CVE's zijn: https://confluence.atlass...y-16-2024-1333335615.html

[locke960]

Kleine side note, dit geld alleen voor de OnPremise installaties

Vreemde vraag mischien, maar dat lijkt me voor de hand liggen?
Ik neem aan dat als diezelfde bug in de SaaS versie zat, Atlassian dan eerst zijn eigen systemen patcht? Dan zijn ze natuurlijk niet meer kwetsbaar.

[Frame164]

Je hebt dan in ieder geval met 1 actie een groot deel van de gebruikers geholpen. Dat is immers een groot voordeel van SaaS.

[Fishbeast]

Azure DevOps is, imo, een draak van een product als het gaat om gebruiksgemak. Dit is iets dat Atlassian veel beter op het vizier heeft zitten, denk ik.
Desalniettemin, ook hier geldt: garbage in, garbage out. De juiste/passende inrichting en navenant gebruik is erg belangrijk bij deze tools...

[leonboot]

Wat een hoop onduidelijkheid; dit artikel heeft het over Confluence en Jira, maar de links naar de informatie op atlassian.com en het officiële CVE document hebben het uitsluitend over Confluence, terwijl het artikel van het NCSC het weer over een heel scala aan producten heeft (ook Bamboo, Bitbucket en Crowd).

[TommyGun]

Sowieso was deze Advisory op 16 januari j.l. al gedeeld door Atlassian...

Volledige lijst hier: https://confluence.atlass...y-16-2024-1333335615.html

[Reactie gewijzigd door TommyGun op 23 juli 2024 07:44]

[kodak]

Dat lijkt me een andere discussie. Tenzij je kan aantonen dat die informatie onvolledig was en daarom de systemen als jira nog een lek zouden zijn.

[leonboot]

Dat is volgens mij inderdaad een ander issue (of eigenlijk een hele verzameling issues), maar ik denk wel dat daar de verwarring is ontstaan. Dat gaat over een hele rits fixes voor kwetsbaarheden met CVSS scores van 7.2 tot 8.8, terwijl die van vandaag een score van 10.0 heeft. Het artikel op ncsc.nl lijkt een verzameling te zijn van alle issues uit de advisory van 16 januari, aangevuld met deze kwetsbaarheid. Maar voor zover ik kan beoordelen betreft CVE-2023-22527 nog steeds alleen self-hosted Confluence installaties.

[kodak]

Dat lijkt me inderdaad een verklaring te kunnen zijn. Het valt me op dat er eigenlijk geen enkele duidelijk bron is. Zelfs de officiële cve-pagina geeft 2 van de 4 bronnen die niet publiek zijn, waardoor achterhalen wat klopt onnodig moeilijk is. En er lijkt ook geen duidelijke bron te zijn wie het ontdekt heeft en uitsluitsel over de omstandigheden kan geven Ik vind het nogal kwalijk bij dit soort ernstige risico's.

[Llopigat]

Ik vind Jira ook een vreselijke tool. Zo onhandig. Gelukkig gebruiken we het alleen om onze uren in te loggen (men denkt dat dat ons 'agile' maakt).

Maar echt afval software is het. Het is alleen zo populair omdat iedereen mee wil liften op het "Agile" gebeuren.

[Reactie gewijzigd door Llopigat op 23 juli 2024 07:44]

[gimbal]

Ok maar ik heb in mijn gehele loopbaan nog nooit een urenregistratiesysteem gezien wat niet afgrijselijk is. Men bouwt die dingen met het oog op rapportages (en een bijbehorend datamodel...), niet op de gebruikerservaring voor mensen die uren moeten loggen. Het feit dat je het vreselijk vindt is in mijn optiek niet direct aan Jira te koppelen in dit geval.

Op gebied van issue tracking is het ook grotendeels aan hoe het ingezet wordt hoe ergerlijk het is. Je hebt enorm veel vrijheid in hoe dashboards werken... en dus ook erg veel vrijheid om er een hel van te maken.

[Reactie gewijzigd door gimbal op 23 juli 2024 07:44]

[downtime]

Ik weet niet waarom bedrijven aan urenregistraties doen. Ik heb nog nooit van m'n leven een registratie gehad die echt overeenkwam met de uren die ik echt besteedde en ik heb nog nooit een manager of projectleider gezien die zich daar druk om maakte. Blijkbaar kan het niemand ook maar een ruk schelen wat je invult zolang het maar plausibel is en voor mooie grafiekjes zorgt.

[blinchik]

Uiteindelijk moet je wel dingen doorrekenen aan klanten. De baas betaalt jou ook 40 uur per week, het is leuk dat hij daar toch een aardig bedrag voor terugkrijgt. En als je maar 1 uur voor klant 1 hebt gewerkt en 39 uur voor klant 2, dan zou klant 1 het niet leuk vinden dat hij voor 20 uur wordt gefactureerd. Vergelijk het eens alsof jij niet betaald zou worden, maar dat je voor elke taak die je doet een factuur zou moeten sturen en op die manier je loon binnenkrijgt.

Ook voor intern gebruik kan het heel handig zijn om in te schatten hoeveel druk er op de werknemer ligt, hoelang men aan iets bezig is, om in te schatten hoe realistisch het is projecten het volgend jaar te realiseren, of er bijvoorbeeld personeel of externen bij moeten komen, om te ontdekken wat quick wins zijn en of er misschien dingen zijn die eigenlijk niet zo belangrijk zijn, maar wel enorm veel tijd in kruipt.

En uiteraard is het niet leuk om uren te loggen, ik doe het ook niet graag, en het is soms op het einde van de dag ook niet eenvoudig om zelf in te schatten hoe lang je met iets bezig bent geweest omdat je 1000 taken hebt gedaan. Maar je hebt in elk geval een inschatting.

[Korben]

Een ‘goede’ reden is dat het verplicht is als je WBSO-subsidies ontvangt. Schijnbaar moeten dan al je ontwikkelaars uren vastleggen, ook al werken ze nooit aan projecten die voor WBSO in aanmerking komen.

[Llopigat]

Ik vind van wel. Dat de rest het ook slecht doet, maakt Jira niet beter

Het is bij ons echt het een-na-rotste systeem om mee te werken (het allerslechtste is Planon, een systeem om je bureau te reserveren, dat is echt afgrijselijk. Heel erg Web-1.0 en in de mobiele app moet je elke keer opnieuw inloggen met username, paswoord en 2FA voordat je iets kan doen. Nog een Nederlands produkt ook ).

[Reactie gewijzigd door Llopigat op 23 juli 2024 07:44]

[familyman]

Planom aaaaaaargh. Voor ons voor parkeerplaatsen.

Die mag je alleen per dagdeel. Maar de dropdown laadt eerst per kwartier, wist je keuze, en dan de dagdelen

Voor zowel start als stop.

En geen updates als mensen eerder weggereden zijn

[cracking cloud]

heb een tijdje gewerkt met Harvest. Vond dat nou niet echt een afgrijselijke urenregistratiesysteem. Integendeel, vond het wel prettig werken.

[Boy]

Voor uren loggen gebruik ik nu float.com. Is eindelijk een tool die voor mij goed genoeg werkt. Het is niet perfect, maar het beste wat ik tot nu toe ben tegengekomen. M'n werknemers vinden het een fijne logging tool (ik ook) en rapportage gaat ook prima. Maar het is nog een vrij nieuwe applicatie

[BCC]

Het is een tool voor managers, niet voor de gebruikers ben ik bang. En helaas hebben goede sales mensen in dienst, want ik zie jira steeds weer op-poppen hier en daar.

[Llopigat]

Ja het maakt mooie plaatjes voor het management, dat is ook waarom ze willen dat we onze uren loggen.

Echter gebruiken ze de rest van de functionaliteit niet en ook de methodologie niet. Iedereen doet maar wat. Dus wat het eigenlijk aflevert zijn mooie plaatjes die eigenlijk geen ruk zeggen.

Nou is dat natuurlijk iets dat niet aan de tool ligt, maar als gebruiker vind ik het enorm vervelend om mee te werken.

[Reactie gewijzigd door Llopigat op 23 juli 2024 07:44]

[soepah]

Uren loggen heeft niks met agile te maken..
Als je Jira goed gebruikt wil je juist niks met uren te maken hebben (zowel niet gespendeerd als niet qua schatting)

[Llopigat]

Ja onze CIO heeft een keer geroepen: "Alles moet naar agile toe" en toen heeft iemand besloten dat als onze uren in Jira gelogd worden, we hier aan voldoen.

Echt een typisch geval van straatje schoonvegen voor de schijn. Sowieso is mijn werk niet echt geschikt voor agile methodologie (of voor welke methodologie dan ook eigenlijk). Ik werk gelukkig niet veel met anderen samen.

[Reactie gewijzigd door Llopigat op 23 juli 2024 07:44]

[Asitis]

Precies. Ik werk nu in Jira met een heel team en de hele tool wordt gebruikt zoals het bedoeld is, en afgezien van een leercurve en wat UX quirks, werkt het verder prima voor wat het moet doen.

[BCC]

Ja ik gebruik ook 100x liever Gitlab issues met een project board.

[aikebah]

Het is een tool waar managers ver van weggehouden moeten worden, dan is het best een prettig issue management systeem.
Zodra managers zich er tegenaan gaan bemoeien dan wordt het een draak, want die gaan allerlei processen en rapportages inrichten waardoor je niet meer je eigen optimale intra-team ticket handling kunt gebruiken, maar allerlei overbodige corporate reporting tags/labels/whatnot moet gaan gebruiken zodat ze hun rapportjes kunnen draaien met de illusie dat ze in-control zijn.

[Frame164]

Uren boeken in Jira lijkt me eerlijk gezegd niet de juiste toepassing van Akira. Daar zijn andere systemen veel handiger voor.

[edeboeck]

Off-topic voor artikel, wel ingaand op jouw reactie:
Voor timetracking vind ik persoonlijk toggl.com heel geschikt: heel weinig acties nodig vanuit ieder (als je aparte software gebruikt voor de verschillende taken, kan je zelfs automatisch laten loggen). Anderzijds heel flexibel als je iets wil aanpassen.

[BCC]

Ok vindt het aanpassen echt verschrikkelijk sinds de laatste update 🙈

[dehardstyler]

Ik ben echt de dagen aan het aftellen naar 15 februari, dan ben ik eindelijk van de bak ellende genaamd Jira Servicedesk Server af. Kan niet wachten. Waardeloos product, met waardeloze support. Bugs die gewoon niet gefixt worden, of waar juist wordt aangegeven dat er een fix uit is om het in de volgende release gewoon weer kapot te maken en opnieuw te introduceren.

[Cergorach]

Er zijn maar weinig servicedesk tools die echt bagger zijn, ze zijn hoogstens bagger ingericht.

Dat gezegd hebbende, ik heb gewerkt met oude zelf hosted Jira en de nieuwe cloud hosted Jira. Zeker die laatste vind ik regelmatig extreem traag werken (unresponisve design), zowel pagina laden als acties uitvoeren en zo een cloud Jira pagina trekt echt een berg resources in je browser!

Nu heb ik alweer 2+ jaar niet meer gekeken naar het Jira aanbod en weet niet of men een berg (useless) features heeft aangezet bij het inrichten, men niet genoeg resources afneemt of dat Atlassian gewoon regelmatig niet genoeg resources beschikbaar stelt. Maar ik krijg niet het idee dat met de overstap van oude local hosted naar nieuwe cloud een verbetering is, zelfs niet een gelijke ervaring, maar een stap terug. Ik krijg ook niet het idee dat dit een issue van local vs cloud maar eerder developers die heel veel nieuwe meuk hebben geïmplementeerd zonder naar de performance te kijken... Niet een verschijnsel uniek aan Atlassian, iets dergelijks ook wel voorbij zien komen met bv. TOPdesk. Het KISS principe is kennelijk vrij onbekend bij veel webdevelopers...

[dehardstyler]

Ik snap wat je zegt, maar dat is niet waarom ik een hekel heb aan Atlassian. Dit is een mooi voorbeeld waarom ik er echt verdrietig van wordt: https://jira.atlassian.com/browse/JRASERVER-71536

Affected versions:
version < 8.5.8
8.6.0 ≤ version < 8.11.1
Fixed versions:
8.5.8
8.11.1 and above, including 8.13.x

Hoezo loop ik hier tegenaan in versie 9? Waarom staan er comments onder dat 9 hier ook last van heeft sinds december 2022? Dit is tot de dag van vandaag nog niet opgelost.

Waarom wordt het nou eigenlijk niet gefixt?

Note on fix
We've been unable to fully fix this issue due to short SLA and possible performance problems that fix could introduce. Please check the workaround section for mitigation steps.

Een severity Major, dus die wil je gewoon gefixt hebben, helemaal open aan het internet zoals wij het gebruiken. Workaround? Zet publieke toegang uit. Dat hebben we ook zeker gedaan en het was gelijk het laatste Atlassian product.

[Bux666]

Ik snap wat je zegt, maar dat is niet waarom ik een hekel heb aan Atlassian. Dit is een mooi voorbeeld waarom ik er echt verdrietig van wordt: https://jira.atlassian.com/browse/JRASERVER-71536

Die link werkt alleen als je een Atlassian account hebt...

[dehardstyler]

Ik zou het gewoon van mij aannemen en er geen moeite in steken.
Maar het klopt dat je deze issues alleen kunt inzien met een account, die kun je wel gewoon aanmaken, maar ik zou de moeite er dus niet in steken.

[cracking cloud]

useless features worden continu toegevoegd in jira. Zag laatst bv een AI knop toegevoegd in Jira. Ze moeten natuurlijk ook wel mee met de hype

[Cergorach]

Wil je een AI knop in Jira, sure! Maar laad dan niet direct het hele LLM in met de rest van de pageload!

Ik doel niet zo zeer op dat soort 'features' maar meer zaken als overdadig veel gebruik maken van AJAX om bv. een lijst continu te laten laden ipv. gewoon 1x pageload en dan naar een andere pagina gaan.

[Bas_f]

Dat is precies het probleem met het gros van alle "webdevelopers" tegenwoordig. Een librarietje hier, een frameworkje daar. Alles includen, zowel server side, als client side. Toch resources genoeg. Vooral niks meer zelf (kunnen) maken. Soms verlang ik nog wel eens terug naar Assembly.

[Cyberpuppy]

Ja. En dan zelf muterende code schrijven. Het was een draak, maar je leerde wel wat programmeren was en wat elk commando betekende

Ook leuk. Programmeren op papier. Niks opzoeken of trial and error. Moet in 1 keer goed. Inclusief alle puntkomma's en haakjes.

[Cyberpuppy]

Verreweg de meeste servicedesk tools zijn bagger.

Om een paar zaken te noemen die vrijwel geen enkel systeem kan uitvoeren:
-Scheduled en recurring tickets. Bijv. iets als backup restore testen is een procedure die je iedere x periode zou moeten uitvoeren. Daar zou dus volautomatisch een nieuw ticket voor moeten komen
-Gezeur van de tools over openstaande tickets. Er zijn vaker tickets die meerdere maanden open staan om uiteenlopende reden. Hoef ik niet iedere dag uitvoerig aan herinnerd te worden
-Time en material logging. Vrijwel geen enkele tool kan het gebruikte materiaal loggen. Dat moet je maar in een ander systeem bijhouden
-Allerlei verplichte velden die niet altijd relevant zijn
-Geen mogelijkheid om een ticket NIET aan een gebruiker te koppelen. Vanuit systeembeheer kom je allerlei zaken tegen die je wel in je systeem wilt hebben maar waar de gebruiker niks mee van doen heeft.


We hebben op dit moment Trello zodanig verbouwd dat dit prima te gebruiken is voor een niet al te grote servicedesk.

[Cergorach]

Dit is voornamelijk gewoon niet goed ingericht.

Voor veel zaken moet je een beetje out of the box denken, als je tooling niet standaard iets van recuring tickets heeft, kan je prima een recuring email maken en die inlezen met een standaard oplossing.

Dagelijks gezeur over tickets, betekend gewoon dat je geen status heb gemaakt waarbij dit niet gebeurd. SLAs zijn great, maar niet alles bepalend, dat is iets wat veel (management) mensen vergeten.

Er zijn inderdaad tools die geen servicedesk tools die geen tijd loggen en dat hoeft absoluut geen negatief iets te zijn, ik zou het zelfs positief willen noemen want er worden vaak onrealistiche, stressvolle eisen gesteld door management over tijdlogging. Echter als je het absoluut nodig heb ivm. doorbelasting, dan is het een ander verhaal en moet het gewoon bij de eisen van het pakket horen als je het uitzoekt. Hetzelfde geld voor material logging, de meeste bedrijven doen daar niet aan of slechts beperkt. Als het een eis is, stel je die op het moment van uitzoeken van je pakket. Bijhouden in een ander pakket hoeft niet slecht te zijn, mits er goede integratie is...

Verplichte velden zijn nodig in de meeste gevallen, echter als er geen juiste opties zijn om te kiezen, dan is het niet goed ingericht.

Een ticket dien je altijd aan een persoon te koppelen. In het geval van systeembeheer is het gewoon de persoon die het issue constateert, ook al is dit de persoon die het zelf oplost. Op die manier kan je later altijd terugvinden wie het heeft gemeld/gevonden en die persoon er op aanspreken als je er meer over wilt weten. Ik proef echter dat management/rapportages iets doen waarbij ze de aanmelder als stat gebruiken voor iets, waarbij je niet wil dat je naam overal aan hangt. Dat is ook gewoon weer slecht inrichten, niet alleen van de tooling, maar ook van de processen.

Waarbij RMM tooling vaak de software (of de licenties) het issue zijn, is bij servicedesk systemen juist vaak de inrichten en/of de processen het issue.

[Cyberpuppy]

Ik ben het met je eens dat er veel ligt aan het inrichten van dit soort software. En daar is veel te winnen/verliezen.

Echter. Er is weinig software die goed aansluit bij kleine IT serviceproviders.

Pak een simpele taak als een nieuwe pc bij een klant leveren. Ik kan nergens eenvoudig een afleverbon laten tekenen door de klant vanuit de software. Dan kom ik er vervolgens achter dat de netwerkkabel te kort is en er een stekkerdoos bij moet. Waar noteer ik dat? Checklist nieuwe pc voor wat betreft de inrichting? Ook al niet. En zo kan ik nog wel een tijdje doorgaan.

En in de meeste software kun je een medewerker niet aan alle klanten koppelen. Oftewel je moet de medewerkers onder alle klanten als aparte gebruiker gaan opvoeren. Als dat al kan, want dubbele emailadressen. Dus dan weet je wel wie maar, niet voor welke klant. En dat moet dan weer ergens in een tekstveld. Maar ja, bij de facturatie komen deze tickets dan weer niet boven drijven.

[Cuball]

Naar de cloud dan ?

[dehardstyler]

Nee wij gaan echt wisselen van leverancier, heb wel genoeg gehad van Atlassian.

[Keyb]

Maar bij welke buur is het gras echt groener dan?

[dehardstyler]

Wij gaan naar BMC, dat wordt al veel gebruikt bij ons.

[Frame164]

Daar zijn wij juist weggegaan vanwege slechte ervaringen.

[dehardstyler]

Ja, dat zal je altijd zien.
Waarom zijn jullie weggegaan en naar welk product toe?