Atlassian waarschuwt voor kritiek lek waarmee Jira kon worden overgenomen

Atlassian waarschuwt gebruikers van Jira voor een ernstige kwetsbaarheid waarmee aanvallers write-toegang tot Service Management konden krijgen. Daarvoor is het wel nodig dat aanvallers een bepaalde Jira-gebruikerslink krijgen. Er is een patch voor de bug beschikbaar.

Atlassian waarschuwt op een aparte pagina voor de kwetsbaarheid, die trackingnummer CVE-2023-22501 meekrijgt. De bug krijgt een Kritieke classificatie van 9,4 mee. Atlassian heeft ook een faq online gezet met details over de kwetsbaarheid.

De kwetsbaarheid zit in Jira Service Management and Data Center, het centrale platform voor Jira-beheerders. Via de kwetsbaarheid is het mogelijk voor een aanvaller om 'onder voorwaarden' toegang te krijgen tot Jira Service Management. Een aanvaller kan dan tokens onderscheppen die naar bestaande gebruikers zijn gestuurd, maar ook naar gebruikers die nog niet eerder hebben ingelogd. Zo kunnen ze nieuwe gebruikersaccounts aanmaken.

Dat geldt alleen voor zelfgehoste systemen en niet voor Atlassian Cloud-gebruikers, die inmiddels beschermd zijn tegen de bug. Atlassian zegt dat ook installaties die niet via internet benaderbaar zijn de upgrade moeten uitvoeren, al zegt het bedrijf dat bij die installaties de attack surface wel significant kleiner is.

Volgens Atlassian kunnen aanvallers de bug uitbuiten als ze al een gebruikersaccount hebben dat is betrokken bij een Jira-issue, of als een aanvaller toegang heeft tot een e-mail waarin een View Request staat van zo'n gebruiker. Atlassian zegt dat met name bot-accounts vaak onder die voorwaarden zullen vallen.

De kwetsbaarheid zit in versies 5.3.0, 5.3.1, 5.3.2 en in 5.4.0, 5.4.1 en 5.5.0. Het is daar inmiddels opgelost, maar beheerders moeten nog wel een patch installeren. Atlassian heeft drie patches beschikbaar gesteld waarin de bug is gerepareerd: 5.3.3, 5.4.2, 5.5.1 en 5.6.0.

Reacties (42)

[HollowGamer]

Ik heb ervaringen gelezen van Atlassian gebruikers, dat zelfhosten echt een ramp is. Zo installeren updates niet of gaat het stuk halfweg tijdens de update. Klopt dit?

Merk ook dat zelfhosten gewoon het niet waard is. Ja, je bespaart maandelijkse kosten, maar je krijgt al het beheer en gedoe erbij. Tijd geleden geprobeerd met Gitlab, maar het was een gedoe en erg gevoelig bij package upgrades. In vervolg zou ik het in een Docker doen.

Maar back ontopic, dit soort updates zou ik ook altijd lokaal installeren. Er hoeft maar een malware of extensie te zijn die het lek misbruikt, maar goed er zijn genoeg die vinden dat ze achter een firewall/vlan zitten, dat updates niet nodig zijn.

[dehardstyler]

Ik word inderdaad verdrietig van JSM. Gelukkig kunnen we het niet meer zelf hosten vanaf februari 2024, dus ik ben al bezig met een vervanger zoeken.

Weet iemand toevallig een goed incident tracking system met asset management ingebakken? Dus niet weer via plugins zoals bij Jira, dat was ook een ramp.

[Muurtegel]

De cloud producten verschillen ondertussen aanzienlijk met server/DC. Asset management zit volgens mij ingebakken op cloud nu.

Misschien interessant om eens te kijken. Maar heb zelf al tijden geen JSM meer gebruikt.

[R0SSI]

Asset Management zit ook bij JSM bij Data Center. Maar klopt dat Cloud aardig voor getrokken wordt...

[deadinspace]

Weet iemand toevallig een goed incident tracking system met asset management ingebakken? Dus niet weer via plugins zoals bij Jira, dat was ook een ramp.

Ik heb ooit op werk Phabricator (tegenwoordig Phorge) gebruikt, dat vond ik een stuk fijner werken dan Jira; een stuk soepeler en gebruiksvriendelijker vond ik het. Het is open source en self-hosted, al zijn er vast ook wel partijen die het hosten en je dat als dienst kunt afnemen.

Ik weet niet precies wat je verstaat onder asset management (en dus of Phorge dat biedt), maar het is allicht het bekijken waard.

[anvil]

Je kunt het na 2024 nog prima zelf hosten alleen betaal je meer. Wij zijn inmiddels met Bitbucket over van server naar datacenter met slechts een nare gotcha : backend moest ineens van MySQL naar PostgreSQL

Maar verder afgezien van prijs geen issue om selfhosted te blijven.

Qua upgrades weinig issues gehad afgelopen 10 jaar, alleen de overstap naar MySQL8 met utfmb4 was messy.

[jessesteinen]

Ik heb een tijdje een aantal instances ge-self-host en nooit problemen daarmee ondervonden. Hooguit dat soms wat custom config teruggezet was (reverse proxy voor https, toen dat nog niet goed native ondersteund werd), maar ik heb nooit een echt botched upgrade meegemaakt.
Having said that, het is zó veel gemakkelijker om het in de cloud te hebben draaien, ook omdat de Cloud-versie vaker/sneller nieuwe features krijgt dan Server. Atlassian heeft Server een tijd bewust ontmoedigd (ten faveure van Cloud) en je kunt nu volgens mij alleen nog de Data Center versie self-hosten. En ook daar stop de licentieverkoop volgend jaar van.

edit: Server kun je niet meer kopen en wordt vanaf volgend jaar niet meer supported. Data Center blijft wel bestaan vooralsnog.
bron: https://www.atlassian.com/migration/assess/journey-to-cloud

[Reactie gewijzigd door jessesteinen op 24 juli 2024 00:25]

[Settler11]

Poeh, dus binnen een jaar moet je geforceerd over naar cloud als je de (security) updates/patches wilt hebben?

[tele-n-ettertje]

Nee, datacenter blijft bestaan voor on-premise installaties

[Baardmeester]

Hier hebben wij ook nooit problemen met Jira Server updates. Ik denk dat het misschien een Data Center ding is?

[phex]

Mijn ervaring was dat, zelfs met een goed gespecte bare-metal linux machine, self hosted vaak erg traag was.

Na jaren Atlassian producten gebruikt te hebben zijn we inmiddels overgestapt op modernere software pakketten die prettiger in gebruik zijn.

[HollowGamer]

Welke andere producten?

Wij gebruiken de doorsnee van hun (JIRA, Confluence, Bitbucket, etc.), maar persoonlijk vind ik iets als GitHub voor developers fijner. Daar zit ook gewoon een issue tracker, wiki, etc. in.

[phex]

Ik denk dat voor issue tracking onze grootste "win" Linear is.

https://linear.app/

[Argantonis]

Ik denk dat voor kleine bedrijven die niet teveel eisen hebben aan hoe inzichtelijk en traceerbaar alles is en vooral met informele processen werken, Lineair wel prima werkt. Wij gebruiken het zelf ook. Maar ik moet er toch niet aan denken om alleen dat te gebruiken als het bedrijf flink zou groeien, met een eerstelijns support afdeling, alles auditable te moeten houden et cetera. Dan is Jira toch nog wel een stuk geschikter. Maar inderdaad, om even wat projecten en stories te maken is Linear wel prima, kan gemiddeld net wat meer dan Trello wat echt al snel te simpel is, zonder dat het al te vroeg complex wordt.

[phex]

Wij gebruiken Linear ook niet als support tool maar puur als team driven software development oplossing.

Vooral door de interface en snelheid vraag je je af hoe je überhaupt met Jira al die jaren hebt kunnen werken.

Alle software developers die ik spreek hadden vrij snel dezelfde mening.

[orvintax]

Mijn ervaring was dat, zelfs met een goed gespecte bare-metal linux machine, self hosted vaak erg traag was.

Die ervaring heb ik ook maar dan met de cloud oplossing

[tweakerbee]

Bij Jira ook vastgelopen op mislukte upgrades. Ongetwijfeld veroorzaakt door plugins die uitgeprobeerd waren maar niet goed te verwijderen. Zelf hosten zou ik niet aan beginnen.

[-=bas=-]

Het enige grote voordeel van zelf hosten is dat je de emoji's gewoon uit kan zetten.
In de cloud versie, krijg je bij elke dubbele punt gelijk een emoji ingevoegd in je text.
Alsof je bij een professionele organisaties emojis in je tickets gaat gebruiken.

[Noppie1991]

Ik heb geen ervaring met Jira maar Confluence zelf hosten en up to date houden was inderdaad een ramp door het gedoe met updaten. Een snapshot maken voor het updaten was vaker een noodzaak dan "voor de zekerheid".

[Frame164]

Up to date houden is sowieso lastig met on-prem zaken. Het is eigenlijk een continu process, dat je uit handen wordt gehouden bij een cloud variant. Al die tijd die je als IT afdeling nodig hebt om de boel up-to-date te houden kan je niet besteden aan het definieren van een goede IT strategie.

[rrozijn]

Eigenlijk nooit problemen gehad met updaten van Jira en Confluence. Is denk ik afhankelijk van de type installatie die gebruikt wordt. Ik gebruik de tar.gz variant op Linux. Er zijn ook varianten met een installer. Mogelijk dat die problemen geven.

[R0SSI]

Zelf nog geen issues ervaren met het deployen van diverse Atlassian producten (o.a. Jira met Service Management) via de tar.gz bestanden met behulp van Ansible. Sinds het mogelijk is, ook via Rolling Upgrades meerdere updates uitgerold. We hebben alleen wel staging omgevingen om updates te testen voordat we Productie updaten. In die omgevingen komen we ook wel issues tegen die breaking zijn, maar dat komt bijna altijd om we bepaalde dingen uit hadden staan etc.

We maken gebruik van Data Center, al is de software in theorie gelijk aan Server... Maar het fijne aan Data Center en rolling upgrades is dat we niet vaak down zijn. En in combinatie met Ansible kan de eerste omgeving (een omgeving bestaat uit alle applicaties van Atlassian) binnen een uur bijgewerkte worden (als alle andere werkzaamheden aan de kant gelegd wordt).

Ik hoor veel mensen klagen over performance, maar met 1 miljoen+ actieve issues en 1000+ projecten, draait het heel soepel bij ons.

[GeroldM]

Hier ook een zelfhoster van Jira. Deze staat niet open naar het internet.

Basis systeem kan een Windows of Linux machine zijn, want het is gebaseerd op Java.
En je kan ervoor kiezen om het te installeren, zodat het automatisch opstart als een achtergrond service. Of een archief uit pakken, Dan via een Windows Batch of Linux Bash bestand even te configureren (zoals poort nummer, browser-url, basis-mappen en database) om dan via een Windows Batch of Linux Bash bestand Jira en de inbegrepen TomCat webserver te starten. Op een redelijk vlotte computer met 8 GByte aan RAM start Jira op in een minuut. Sneller als je rappe drives in je computer hebt zitten.

Starten en stoppen van Jira is simpel (voor updates en ander soort onderhoud), installeren is ook niet moeilijk. Had de laatste tijd wel een probleem opgemerkt dat de TomCat server de communicatie poort niet vrijgaf na een automatische herstart. Jira startte en stopte wel, maar Jira kon niet meer worden benaderd vanaf elke andere computer, behalve de host.

De oplossing nam een half uur in beslag en dat is het enige probleem wat ik in 11 jaar ben tegengekomen. Waar je veel meer tijd aan besteed is het opzetten van een administratie die integreert in de werkwijze van je bedrijf. De basis (of default) opzet die standaard in Jira zit, kan al meteen goed genoeg werken in een kleine, flexibele toko. Ben je door verschillende managementlagen wat logger of wens je een geheel naar eigen wens opzet, dan kan dat ook. Dat is waar je dus veel meer tijd aan kwijt bent dan aan Jira beheer.

Draai al Jira sinds versie 4.1.0 (in combinatie met PostgreSQL) en na 11 jaar kan ik vertellen dat Jira qua beheer/onderhoud/updates zeer weinig tijd of moeite heeft gekost. Het mag dan een n=1 ervaring zijn, ik weet zeker dat ik niet de enige n=1 ben.

Nu maak ik zeer weinig gebruik van extra extensies en wat ik gebruik is door Atlassian zelf geschreven. Dat kan mijn beeld hebben "verkleurd". Maar extensies van derde partijen (en hun eigenaardigheden) is ook vaak een recept voor problematische (server) software. Dat is niet iets specifieks van Jira.

[CyBeR]

Ik self-host GitLab (met hun Omnibus package op Debian) en daar heb ik echt werkelijk nooit gezeur mee. Je moet alleen even hun upgrade path volgen qua versies als je een beetje achter loopt, want ze garanderen een bepaald path wel en andere dus niet.

[miitjohn]

Bij jira valt er iets over te zeggen dat er weinig voordelen zijn om het zelf te hosten en dus by default het als saas af te nemen het beste idee is. Maar bij zoiets als gitlab zijn er toch ook een hoop andere aspecten die spelen die maken dat het in eigen beheer hosten (wat eveneens cloud based kan zijn ) voordelen kan opleveren.

Denk daarbij aan integraties met on premise systemen (brengt dan vanuit de gitlab cloud extra moeilijkheden met zich mee), maar ook kost beheer, je kan zelf finer grained gaan kiezen waar je jobs draati en wat je daarvoor wenst te betalen. Hangt natuurlijk zeer sterk af van de behoeften af, de grote van het project, de inhouse expertise, maar daar het kan wel degelijk interessant zijn. Of je daarbij gitlab gewoon op public internet wil gooien is een andere zaak. Ik zou het afraden en altijd afschermen (whitelisting, vpn, ...)

[Crew One]

Een van de weinige voordelen is wel de prijs. De SAAS optie is gewoon erg duur, zeker als je maar een klein team van developers hebt en minder dan 20 eindgebruikers. De kosten voor de SAAS oplossing zijn €4500 per jaar.

Daar hosten we al jaren de meest advanced versie zelf voor. (Wat nu dus met het opdoeken van hun self-hosted software dus niet meer kan)

[Yggdrasil]

Waar je GitLab CI jobs draait is toch onafhankelijk van of je GitLab cloud gebruikt, of niet?

Wij draaien een docker+machine Gitlab-Runner in Google Cloud op spot instances. Met Cloud Storage als cache en Artifact Registry als registry voor Docker images. Werkt goed en goedkoop en we missen niks.

[Bas_f]

Ja, die ervaring heb ik ook helaas.

Het hele pakket van Jira, incl. Confluence en Bitbucket zelf gehost, maar dat was een draak. De software heeft bizar veel geheugen nodig en dan is het nog niet genoeg. En een update kan zomaar ervoor zorgen dat het niet meer opstart. En omdat er dan niet uit te komen is, is het een kwestie van de backup terugzetten en wachten op de volgende update, die misschien beter werkt.

Datzelfde geldt in iets mindere mate voor Gitlab. Heeft ook een hoop geheugen nodig en updates gaan ook wel eens stuk, maar net iets minder als bij Jira.

[Opperpanter2]

Ik beheer al bijna 15 jaar JIRA en Confluence instanties en heb nog nooit problemen gehad met updates. Nadeel van de atlassian cloud is dat het vrij duur is en ongelogelijk traag. En je hebt heel veel (gratis) addons niet tot je beschikking.

[Neocortex-re]

Die traagheid nooit zo ervaren,

[magician2000]

Zelf hosten (van Atlassian weet ik overigens niet) kan zeker de moeite waard zijn. Maar het is wel afhankelijk van wat je wilt bereiken en wat je verwachtingen zijn.

Zelf hosten hoef je natuurlijk niet altijd thuis te doen. Je kunt ook een basis VPS afnemen waar je zelf dingen bij op gaat zetten. Dat neemt een hoop werk uit handen, maar lang niet alles.

Het grote voordeel van zelf hosten of een VPS die flexibel genoeg is, is dat je veel meer opties hebt dan een basis / standaard hosting omgeving. Iets specifieks nodig? Gewoon installeren (na testen op een thuisomgeving, dat wel). Vaak heb je ook meer ruimte tot je beschikken en zijn er minder zaken beperkt (aantal domeinnamen, databases, mailadressen, enz.). Uiteraard allemaal afhankelijk van met welk hostingpakket je e.e.a. vergelijkt.

[Frame164]

Is een zelf gehoste oplossing niet lastiger als je ook externen (klanten, leveranciers) toegang wilt geven? Hoe ga je dat secure inregelen?

[Mellow Jack]

Niet perse maar je hebt wel meer nodig dan alleen atlassian. Hardening op je servers, een losse web application firewall en een losse identity provider.

Heb je die componenten toch al is het peanuts. Zo niet is het inderdaad best lastig

[Mellow Jack]

Merk ook dat zelfhosten gewoon het niet waard is. Ja, je bespaart maandelijkse kosten, maar je krijgt al het beheer en gedoe erbij. Tijd geleden geprobeerd met Gitlab, maar het was een gedoe en erg gevoelig bij package upgrades. In vervolg zou ik het in een Docker doen.

Voor GitLab werkt het prima maar je moet de oude ICT gedachte een beetje vergeten en bedenken dat 'je een soort van SaaS oplossing host.

Toen wij overstapten van maandelijkse updates naar een nachtelijke update check hebben we nergens meer last van gehad.

On-premise is naar mijn mening prima maar je moet de materie wel voldoende begrijpen om het onderhoudsvrij te maken.

[ernstoud]

Vandaar de portscans die ik zie naar poorten die aan Atlassian producten gelinkt worden?

[PROnline]

Voor de duidelijkheid, het zit in "Jira SCM". Dat is dus niet hetzelfde als Jira wat de halve wereld gebruikt.

[Julian]

De halve wereld gebruikt "Jira Software". Een beetje een verwarrende naam, maar het is ooit begonnen als tool om softare mee te ontwikkelen met Kanban-bordjes. Jira Service Management is een tool om tickets van klanten mee te verwerken.

[Reactie gewijzigd door Julian op 24 juli 2024 00:25]

[Opperpanter2]

Die Kanban bordjes zijn er pas later bijgekomen, dat heette eerst Greenhopper en toen JIRA agile en toen JIRA Software

[Opperpanter2]

Voor de duidelijkheid, het lek zit in JIRA Service Management. Dat is dus niet hetzelfde als JIRA SCM wat geen product van atlassian is :-D

[Bor]

Nee, het lek zit in:

Product:
Jira Service Management Server
Jira Service Management Data Center

Dat is wat anders dan Jira SCM.

[kodak]

De CVSS-score lijkt zeer ruim gekozen door kennelijk aan te nemen dat alle bijkomende benodigdheden standaard van toepassing zijn.

Als eerste moet een account al bepaalde instellingen hebben.
Daarbij moet er een account bestaan of net gemaakt zijn maar dan nog nooit gebruikt. Dat is volgens de score op te vatten dat er user-interactie moet zijn: iemand anders moet eerst dat account aangevraagd of gemaakt hebben.
En zelfs als je dat niet als user interactie wil zien, dan is dat account net aangemaakt waardoor het direct wegkapen zou moeten opvallen. Of er is ook nog slecht accountbeheer, dat niet direct/snel geactiveerde account mogen blijven bestaan.
En dan is heeft het probleem ook nog een verschil tussen lokale gebruikers of criminelen die vanaf het internet een account kunnen gebruiken.

Natuurlijk doen klanten er goed aan om de update niet uit te stellen. Maar het laat ook zien dat als je de situatie hebt om deze hoge score te halen er maar beter ook nagedacht kan worden welke gebruikers je wil accepteren en waarom je accounts die niet in gebruik zijn langer dan uren of dagen laat bestaan.

[Frame164]

Maar is dat niet altijd het geval met CVSS scores? Je moet echt naar de specifieke situatie kijken of een vulnerability echt gevaarlijk is.