Atlassian - die grosse Security Nightmare Horror Show?

[Deleted member 16573]

Atlassian stellt ja am 15.2.2024 den On-Betrieb - bis auf große On-Premise Datacenter-Installationen ein. In den letzten Monaten gab es ja recht viele Sicherheitsvorfälle im Zusammenhang mit Atlassian Produkten. Was ich mich frage, ist, ob dass nicht nur eine große, inszenierte Marketingmassnahme ist? D. h. um zu verhindern, dass den Leuten mit der Einstellung "Na dann betreiben wir das halt ohne Softwareassurance weiter." Ihre On-Premise-Installation ungepatched weiter laufen zu lassen und denen mal ordentlich Angst gemacht wird, inszeniert man die grosse Security Nightmare Horror Show, bei der dann immer die Bugfixes mit maximaler Panik veröffentlicht werden, die unbedingt sofort eingespielt werden müssen. Und nur um dann nonchalant in einem Nebensatz anfügen zu können: "Alle Produkte in der Atlassian-Cloud sind bereits vollumfänglich gegen die aktuellen Sicherheitslücken gesichert. Sie müssen sich um überhaupt nichts kümmern!"

D. h. was ich als Gedankenspiel in den Raum stelle ist, dass Atlassian selbst vorsätzlich Sicherheitslücken in Ihre Produkte eingebaut hat, und die Veröffentlichung derer dann gezielt zu bestimmten Terminen über Strohmänner anstösst, um Ihre bisherigen Kunden in Ihre Cloud zu treiben. Und um den Gedanken noch weiter zu treiben: Natürlich werden dann auch Hacker beauftragt, die Sicherheitslücke dann direkt auszunutzen um tatsächlich Schaden zu verursachen. Cyber-Schutzgeldmafia? Well, you know. It's capitalism.

 

[GwenDragon]

Ich glaube nicht an die große Atlassian-will-Euch-in-die-Cloud-zwingen-Verschwörung ;-)
Aber Alles-in-die Cloud kann auch bedeuten: "Alles wurde geklaut" oder "Alle Daten sind dauerhaft weg". In Firmen schwadroniert sowieso oft aus extremen Unwissen bei Entscheidern, dass die Cloud doch überall verfügbar ist und Daten sicher.
Aber wehe irgendwelche Cloudserver haben einen irreparablen Schaden oder der Anbieter will dafür nicht gerade stehen, oder die Cloud ist nicht erreichbar, die Arbeit steht, dann heulen sie alle.

Aber die regelmäßigen Lücken, wenn ich da so denke wie oft bei JIRA in manchen Firmen Updates auflaufen ließen.

 

[Thunderbyte]

Die einzige Software, die bei uns jemals gehackt wurde, war ein Jira. Auf einer VM, die an Leute, die sich drum kümmern sollten, delegiert wurde. Ich will nie wieder Atlassian on premise Software haben.

 

[GwenDragon]

Ja, löchrige JIRA, das hörte ich auch bei 2 Firmen im Bekanntenkreis. Warum Entwickler trotz ernster Lücken immer noch Atlassian nehmen, ist mir nicht so verständlich, wahrscheinlich weil ein "Entscheider" Atlassian so cool fand.

 

[Firewire2002]

Hab 15 Jahre lang Jira und Confluence on Prem betrieben. Und ja die Tools haben ihren Sinn. Vielleicht nicht für jedes 5 Mann Startup, aber wenn man eine vielzahl von Integrationen und Automatisierungen in unterschiedlichste Richtungen braucht, haben die Tools schon ihre Vorteile.
Nur weil beim eigenen Bedarf die Vorteile der Tools nicht zum Tragen kommen, heißt das nicht, dass sie unnütz oder unbrauchbar wären.

Von der Verschwörungstheorie halte ich nicht viel.
Ja, in den letzten Monaten hatte Atlassian ein paar mehr Security Issues als sonst. Über die Gründe lässt sich nur spekulieren. Könnte auch ganz stumpf daran liegen, dass mal jemand genauer in die Ecken geschaut hat, die sich die letzten Jahre nie einer angeguckt hat. Who knows.
Und wenn man den Umgang von Atlassian mit den Security Issues betrachtet, ist das meistens recht vorbildlich. Es wird zeitnah gepatcht, sauber kommuniziert und sehr oft stehen Workarounds/Mitigations vor dem offiziellen Patch oder parallel dazu zur Verfügung.

Einen Confluence Server zu updaten dauert pro Node ca. 30 Minuten. Da sind allerdings schon 10 Minuten Start-Verhalten von Confluence inbegriffen.

Wem die Menge an Sicherheitslücken abschreckt, sollte sich vielleicht mal Windows oder den Linux Kernel anschauen. Die haben in gleicher Zeitspanne mehr. Ja mir ist klar, dass die komplexer als ein Confluence sind. Aber patchen muss man die genauso. Ob ich als Admin nun Software A oder B patche, macht keinen Unterschied.
Entscheidend ist, dass ich sie patche und daran hakt es bei vielen Unternehmen. Die patchen dann allerdings auch oft genug vieles andere nicht. Nicht nur die Atlassian Produkte.

 

[marce]

Und wenn man den Umgang von Atlassian mit den Security Issues betrachtet, ist das meistens recht vorbildlich. Es wird zeitnah gepatcht, sauber kommuniziert und sehr oft stehen Workarounds/Mitigations vor dem offiziellen Patch oder parallel dazu zur Verfügung.

mit dem Punkt wäre ich nicht 100% einverstanden.

Die Changelogs sind gerne mal nichtssagend und unvollständig, "ist man von einer Lücke betroffen" wechselt auch gerne mal von "nein" zu "oops, aber doch", es gibt keinen sinnvoll und unfallfrei auswertbar- oder lesbaren Kommunikationskanal über solche Änderungen, Hinweise von Usern / Tickets im Supportsystem zu Lib-Updates wg. neuer Versionen und gefixed CVEs in Libs dümpeln gerne mal lange in "Gathering Interest" herum um dann auch mal kommentarlos in "Won't fix" zu landen, Backports aus Fixes in der Latest-Version brauchen gerne mal, bis sie evtl. doch auch in den LTS-Releases landen, Release-Notes erscheinen auch gerne mal erst Tage nach dem Release der Software und werden hinterher noch angepasst, ohne das durch irgendwelche Timestamps oder Kommentare zu dokumentieren, ...

 

[Firewire2002]

Die Changelogs sind gerne mal nichtssagend und unvollständig

Würde ich mal unter Jammern auf hohem Niveau verbuchen. Manchmal will oder kann man als Unternehmen schlicht nicht alle Infos rausrücken. Das ist nicht nur bei Atlassian so. Obs der Kundschaft nun gefällt oder nicht. Wirtschaftliche Interessen gehen manchmal vor Komfort.
Als Nutzer machts kaum einen Unterschied. Entweder du setzt die aktuellste Version oder nicht. Nicht zu aktualisieren, nur weil dir das Changelog nicht gefällt, ist eh keine Option.

"ist man von einer Lücke betroffen" wechselt auch gerne mal von "nein" zu "oops, aber doch"

Ohne Unternehmens-Interna zu kennen, würd ich das erstmal pauschal unter Dokumentation des Fortschritts, der eigenen Code-Analyse verbuchen. Denn das braucht Zeit und lieber habe ich eine sich im Verlauf ändernde Aussage, als gar keine.

es gibt keinen sinnvoll und unfallfrei auswertbar- oder lesbaren Kommunikationskanal über solche Änderungen

https://www.atlassian.com/trust/security/advisories
Die Artikel haben ein Creation und ein Modified Date. Man sieht, wenn sich was geändert hat. Was genau ist irrelevant. Letztendlich interessiert der einzelne Artikel immer nur in der aktuellste Fassung. Was will man mit überholten Erkenntnissen?

Hinweise von Usern / Tickets im Supportsystem zu Lib-Updates wg. neuer Versionen und gefixed CVEs in Libs dümpeln gerne mal lange in "Gathering Interest" herum um dann auch mal kommentarlos in "Won't fix" zu landen, Backports aus Fixes in der Latest-Version brauchen gerne mal, bis sie evtl. doch auch in den LTS-Releases landen

Hast du konkrete Beispiele für kritische CVEs dazu? Das müsste man sich an den entsprechenden Einzelfällen anschauen, um die Aussage bewerten zu können. Ansonsten kann man hier nur mutmaßen, dass die CVEs am Ende doch nicht sooo kritisch waren und einer Priorisierung erlegen sind.

Release-Notes erscheinen auch gerne mal erst Tage nach dem Release der Software

Sicherheitsrelevante Dinge sind unter obigem Link aktuell gehalten. Für Funktionsupdates/-upgrades ist es wohl völlig egal, ob die Release-Notes ein paar Tage später kommen oder nicht. Wenn es nicht Sicherheitskritisch ist, kann man getrost abwarten. Die Alternative wäre, sie warten mit dem Release solang, bis auch die Release-Doku fertig ist. Und welchen Vorteil gewinnt man nun daraus?
Wenn du aus nachvollziehbaren Gründen erst updaten willst, wenn die Release-Notes da sind, ändert sich an deinem Zeitplan überhaupt nichts. Ausser das in dem einen Fall die Software selbst schon ein paar Tage früher zur Verfügung steht.
Auch hier wieder, jammern auf hohem Niveau.

 

[marce]

Ich seh' das nicht als Jammern auf hohem Niveau sondern als "warum nicht einfach richtig machen"?

Nicht falsch verstehen - ich nutze und Administriere die Atlassian-Dinger schon seit Jahren und mag sie. Aber gerade Atlassian ist für mich was Kommunikation angeht _kein_ gutes Beispiel. Es ist ok, mehr aber nicht. Das geht besser, viel besser.
Im Laufe der Zeit lernt man damit umzugehen und bei Releases einzuschätzen, ob das wirklich nur ein reines Bugfix-Release ist oder ob da mehr dahinter steckt - und wenn man über die Releases dann mal ein diff macht ist schon erstaunlich, was an versteckten Updates, die oftmals gerne mit einer CVE verbunden sind, in so einem Jira- oder Confluence-Release drin steckt ohne irgendwo auch nur erwähnt zu werden.

... um dann 3 Wochen später plötzlich ein Security-Bulletin via Mail zu erhalten, dass man da doch bitte zügigst updaten soll, alternativ als Mitigation doch bitte den externen Zugriff auf die Anwendung unterbinden. Und die Website ist nett, aber kein brauchbarer Ersatz für irgendeine Art von Feed, Mailingliste oder dem meist eh nicht sauber funktionierenden (inzwischen auch eh nicht mehr angebotenen) Watch auf deren interne Doku - weil sie informiert einfach nicht zeitnah und direkt.
Was die Kommunikation über "affected Versions" und ähnliches angeht - das ist einfach traurig. Da ist leider das Community-Forum die beste Informationsquelle - und das darf bei einer Software, die nun wahrlich nicht günstig ist, echt nicht sein.

... oder lustige kleine Änderungen im Default-Verhalten, die manuelle Anpassungen erforderlich machen wo über Wochen / Monate hinweg keine saubere Kommunikation zu dem geänderten Verhalten vorhanden war und auch jetzt immer noch nicht ist.

Ich hab' damit kein Problem (ok, eigentlich schon, weil ich weiß, dass es besser geht) - und wir updaten unsere Systeme so schnell wie möglich - es ist trotzdem jedes mal ein Spaß und gerne auch mal ein Überraschungspaket.

Man kann natürlich sagen "update einfach immer", dann kann Dir der Rest egal sein - was technisch auch stimmt, aber darum geht es hier nicht sondern eben um die Kommunikation von Atlassian, die an dieser Stelle einfach langsam, suboptimal und unvollständig ist.

... es ist schon ein bisschen traurig, dass ich über mein internes Monitoring (mit Abfragen gegen die API von Jira / Confluence / Bitbucket + ein wenig Voodoo mit Abfragen gegen die Atlassian-Marketplace-API) schneller über ein Update informiert werde und ich dann mit einem Diff über die Releases besser einschätzen kann, wie security-Relevant das Update ist als über alle off. Kommunikationskanäle von Atlassian selbst - und wie hektisch ich werden muss, um unsere Systeme abzusichern (oder ob ich doch den regulären Weg gehen kann über angekündigte Wartungsfenster außerhalb der Kernarbeitszeiten)

 

[d4f]

Die Changelogs sind gerne mal nichtssagend und unvollständig, "ist man von einer Lücke betroffen" wechselt auch gerne mal von "nein" zu "oops, aber doch"

Dass das ein Problem aller Anbieter (ob opensource oder nicht) ist, hatte doch vor genau zwei Jahren Log4Shell so schön gezeigt. Monatelang musste man Herstellern/Enwicklern aller Kaliber nachlaufen und zeigen dass, doch, deren Software die log4j irgendwo einkompiliert hatte und man dann gerne ein Update hätte.

dass Atlassian selbst vorsätzlich Sicherheitslücken in Ihre Produkte eingebaut hat, und die Veröffentlichung derer dann gezielt zu bestimmten Terminen über Strohmänner anstösst

Hier greifen gleich 2 philosophische "Rasiermesser";
- Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity."
- Occam's Razor: "The simplest explanation is usually the best one"



Ab mittelständigen Betrieben sollte man für jeden plausiblen Fall doch einen DRP, einen BCP und eine Exit-Strategie haben. Wenn Atlassian's cloud-Modell nicht zusagt, andere Mütter haben auch schöne Töchter. Exit-Strategie anwenden und ciao sagen.

 

[Deleted member 16573]

Ich würde sagen, dass die Argumentation mit Hilfe von Sprichwörtern eine Diskussion nicht unbedingt weiter bringt....

- Occam's Razor: "The simplest explanation is usually the best one"

Schopenhauer sagt, dass die Wahrheit nur dann gefunden werden kann, wenn man die Oberfläche des Offensichtlichen durchdringt.

- Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity."

Blaise Pascall sagt, dass die größte List des Teufels ist es, uns davon zu überzeugen, dass es ihn nicht gibt.

 

[d4f]

die Argumentation mit Hilfe von Sprichwörtern eine Diskussion nicht unbedingt weiter bringt....

Das sind keine Sprichwörter sondern erprobte logische Aussagen, wenngleich sie zu simpel und universal sind um Axiome zu sein.
Occam's Razor kommt beispielweise gerne in Software zur Auswertung von Massenspektrometrie zum Einsatz.

Aber wenn wir schon bei Sprichwörter sind und da meine Nicht-Aluhut Antwort wohl unangenehm ankam:
Nichts ist leichter als Selbstbetrug, denn was ein Mensch wahr haben möchte, hält er auch für wahr. - Demosthenes