Oft starten Unternehmen mit einem dieser Produkte und steigen mit der Zeit tiefer in das \u00d6kosystem von Atlassian ein, wodurch auch weniger verbreitete Anwendungen des Konzerns zum Einsatz kommen. Darunter etwa Bitbucket zum Hosting des Quellcodes oder Bamboo als Buildserver. Diese lassen sich auch untereinander recht einfach integrieren: Etwa Jira-Tickets in Confluence, wenn man etwas zu einem Fehler dokumentieren m\u00f6chte.<\/p>\n
Sicherheitsprobleme<\/h2>\n
Atlassian ist alleine in den letzten Monaten dutzende Male durch Sicherheitsprobleme aufgefallen. Hierbei geht es mir aber nicht um die Quantit\u00e4t<\/a>. Wenn eine Software wenig oder keine bekannten Sicherheitsl\u00fccken aufweist, ist sie dadurch nicht automatisch sicherer als eine andere mit mehreren L\u00fccken. Die Art der L\u00fccke und der Umgang damit sagt jedoch weit mehr dar\u00fcber aus, wie wichtig dem Unternehmen Sicherheit wirklich ist.<\/p>\n Und gerade hier f\u00e4llt Atlassian besonders negativ auf: Oft handelt es sich um fahrl\u00e4ssige Fehler, die bei sauberer Programmierung oder zumindest gr\u00fcndlichen Tests auffallen. Die Auswirkungen sind zudem nicht selten gravierend und Enden in der M\u00f6glichkeit, aus der Ferne eigenen Code auszuf\u00fchren. Remote Code-Ausf\u00fchrung bedeutet: Der Angreifer kann so ziemlich alles machen, worauf er Lust hat! Zum Beispiel Informationen entwenden, manipulieren oder zerst\u00f6ren. Und das sind noch die vergleichsweise harmlosen Dinge. Er hat Rechte auf alles, was auch die Anwendung darf. Somit k\u00f6nnte er auf andere Systeme im Netz zugreifen, dort nach L\u00fccken oder schlecht gesch\u00fctzten Anwendungen suchen. Im schlimmsten Falle kommt er bis zum Active Directory und kann das gesamte Netzwerk wahlweise ausspionieren, kompromittieren oder lahm legen.<\/p>\n Wir sprechen hier also von keiner Kleinigkeit. Wenn Angreifer so eine L\u00fccke ausnutzen, ist das ein potenzieller Totalschaden! Je nach Sichtweise kurz vor einem GAU oder bereits der GAU.<\/p>\n Atlassian gibt bei Sicherheitsproblemen keinen CVSS-Wert an. Sondern stattdessen eine von vier Kategorien<\/a>, die bestimmten Bereichen der Skala entsprechen. CVSS 9.0 bis 10.0 steht beispielsweise f\u00fcr „kritisch“.<\/p>\n Bitbucket dient zum Hosten von Git-Repositorys: Man betreibt einen Server und kann seinen Code dort hin pushen. Andere haben die M\u00f6glichkeit, den Code von dort per pull zu laden sowie \u00c4nderungen zu verteilen. Im Grunde wie Gogs, oder im Cloudbereich GitHub.<\/p>\n Mehrere Fehler in Bitbucket f\u00fchren dazu<\/a>, dass jeder Nutzer der Repositorys klonen oder darin pushen darf, Schadcode auf dem Server ausf\u00fchren konnte. Die Sicherheitsl\u00fccke wurde von Atlassian als „kritisch“ eingestuft.<\/p>\n Im August 2022 erschien ein Sicherheitsupdate, das die L\u00fccke CVE-2022-36804 behob<\/a>. Dabei konnte ein Angreifer per HTTP-Header Code einschleusen und damit mindestens den Server kompromittieren. S\u00e4mtliche unterst\u00fctzte Versionen waren betroffen, sowohl Server als auch DataCenter. Man musste lediglich ein \u00f6ffentliches Repository haben, oder Lesezugriff auf ein privates, um die L\u00fccke auszunutzen.<\/p>\n Oktober 2021 wurde eine Schwachstelle in Jira Service Management bekannt.<\/a> Angreifer k\u00f6nnen aus der Ferne manipulierten Code ausf\u00fchren, dementsprechend wurde die L\u00fccke als „kritisch“ eingestuft. Der Fehler liegt in der Bibliothek f\u00fcr H2 Datenbanken. Dabei handelt es sich um eine eingebettete Datenbank, \u00e4hnlich wie SQLite. Von Jira wird H2 jedoch nicht f\u00fcr den produktiven Betrieb unterst\u00fctzt. Die Bibliothek ist nur f\u00fcr Testinstallationen vorhanden, sodass man diese ohne eigenen Datenbankserver ausprobieren kann.<\/p>\n Hier zeigt sich, dass Abh\u00e4ngigkeiten die Angriffsfl\u00e4che erh\u00f6hen. Atlassian h\u00e4tte dieses Problem leicht verhindern k\u00f6nnen, in dem die H2 Bibliothek nicht in jeder Jira-Instanz vorhanden ist, obwohl sie produktiv gar nicht ben\u00f6tigt wird. Sondern diese nur bei Bedarf in z.B. einem Testpaket integriert. Diese Vereinfachung hat dazu gef\u00fchrt, dass eine zu Testzwecken gedachte Bibliothek zum Risiko f\u00fcr s\u00e4mtliche produktive Installationen wurde.<\/p>\n Die Erweiterung soll eine Integration zwischen Jira und Slack erm\u00f6glichen. So kann man etwa Jira-Projekte mit bestimmten Kan\u00e4len in Slack verbinden. „Jira Server for Slack“ ist nicht standardm\u00e4\u00dfig installiert. Allerdings handelt es sich um eine offizielle Erweiterung von Atlassian selbst. Gegen\u00fcber Drittanbietersoftware genie\u00dft diese daher einen Vertrauensvorteil – leider zu unrecht, denn die als „kritisch“ eingestufte L\u00fccke erm\u00f6glicht es jedem angemeldeten Benutzer, beliebigen Schadcode auszuf\u00fchren. Sie wurde im Februar 2021 bekannt<\/a>.<\/p>\n Mitte 2021 kam es zu einer kritischen Schwachstelle<\/a> in Confluence, die nur authentifizierte Benutzer treffen soll<\/a>. Wenige Tage sp\u00e4ter wurden jedoch auch Systeme ohne Konto angegriffen<\/a> – Atlassian musste zur\u00fcck rudern. Wie kam es zu dieser falschen Information? Der verwundbare Code befindet sich in einer Java Teilansicht, die nur bei angemeldeten Benutzern eingebunden wird. \u00dcbersehen wurde jedoch, dass man diese Teilansicht auch direkt \u00fcber ihren Name aufrufen kann – somit lie\u00df sich die L\u00fccke problemlos auch ohne Authentifizierung ausnutzen. Wer sich auf diese ersten Informationen verlassen hatte und sich in Sicherheit wog, weil keine anonymen Konten m\u00f6glich sind, wurde m\u00f6glicherweise nichtsahnend infiziert.<\/p>\n Es geh\u00f6rt zu den grundlegenden Sicherheitsma\u00dfnahmen f\u00fcr Entwickler, dass man von au\u00dfen stammende Daten nicht vertraut. Falls diese in dynamischem Code eingesetzt werden, kommen Filter zum Einsatz, um Manipulation auszuschlie\u00dfen. Dies ist hier nicht bzw. nur unzureichend geschehen, wodurch eine schwere Sicherheitsl\u00fccke entstand.<\/p>\n Anfang Juni informierte Atlassian \u00fcber eine schwerwiegende Zero-Day Sicherheitsl\u00fccke<\/a> (CVE-2022-26134). Sie erm\u00f6glicht es Angreifern, beliebigen (Schad-) Code auszuf\u00fchren. Bereits wenige Stunden sp\u00e4ter konnten die ersten Angriffsversuche beobachtet werden<\/a>, auch Medien berichteten dar\u00fcber<\/a>.<\/p>\n Ein Workaround wurde nicht angeboten. Man empfiehlt Betroffenen, sich an die eigenen Sicherheitsteams (also die des Kunden, nicht von Atlassian!) zu wenden, was man dagegen tun k\u00f6nnte. Als Optionen wird genannt, den Zugriff auf Confluence \u00fcber eine Firewall in Richtung Internet einzuschr\u00e4nken – sodass nur interne Anwender das System nutzen k\u00f6nnen. Oder alternativ Confluence komplett abzuschalten<\/a>. Vor allem letzteres d\u00fcrfte f\u00fcr viele absolut unrealistisch sein: Als zentrales Dokumentationssystem enth\u00e4lt es wichtige Informationen. Ein Ausfall auf unbewusste Zeit w\u00fcrde die M\u00f6glichkeit zu Arbeiten deutlich einschr\u00e4nken.<\/p>\n Sp\u00e4ter wurde erg\u00e4nzt, dass man eine Firewall f\u00fcr Webanwendungen vor Confluence setzen kann, um darin Adressen zu blockieren, die „${“ enthalten. Das sei allerdings kein Workaround, der sch\u00fctze. Sondern man w\u00fcrde damit „m\u00f6glicherweise das eigene Risiko reduzieren“<\/a>.<\/p>\n Einige Zeit darauf kommunizierte Atlassian einen Workaround, der gegen einzelne Sicherheitsl\u00fccken sch\u00fctzt, nicht aber gegen alle. Es folgten dann Sicherheitsaktualisierungen, die jedoch nur Kunden mit Wartungslizenz erhielten. Wer diese nicht f\u00fcr einen jedes Jahr \u00fcppig steigenden Aufschlag besa\u00df, erhielt keinen Zugriff auf die Sicherheitskorrektur. Wer hingegen die teure DataCenter-Edition lizenziert hatte, musste einen Ausfall hinnehmen – trotz Clustering, wodurch genau das vermieden werden sollte.<\/p>\n „Questions for Confluence“ erzeugt automatisch im Hintergrund ein Konto namens disabledsystemuser<\/strong>.<\/a> Das Passwort ist bei jedem<\/strong> gleich und leicht zu ermitteln. Dar\u00fcber kann man sich anmelden und auf alle Seiten zugreifen, die f\u00fcr s\u00e4mtliche Nutzer freigegeben sind. Laut Atlassian dient es zur Migration, wenn Benutzer von On-Prem in die Cloud umziehen. So wie es umgesetzt wurde, erf\u00fcllt es jedoch alle Merkmale einer Hintert\u00fcr (Backdoor). Im Juni 2022 informierte der Hersteller \u00fcber diese L\u00fccke und stufte sie mit der h\u00f6chsten Einstufung „kritisch“ auf der eigenen Skala ein.<\/p>\n Bei „Questions for Confluence“ handelt es sich um eine Erweiterung, die es Benutzern erm\u00f6glicht, Fragen zu stellen, \u00fcber Antworten abzustimmen, Punkte zu sammeln und \u00e4hnliches. Als Wiki-Software stellt Confluence keine derartige Funktionalit\u00e4t bereit. Im Marktplatz stehen verschiedene Erweiterungen bereit, womit sich das System um zus\u00e4tzliche Funktionen erweitern l\u00e4sst. Zwar wird „Questions for Confluence“ nicht automatisch installiert, sodass nur ein Teil der Benutzer betroffen ist. Allerdings handelt es sich um eine offizielle Erweiterung von Atlassian selbst. Sie genie\u00dft dadurch besonderes Vertrauen im Gegensatz von Drittanbietern, die von anderen Unternehmen bereitgestellt werden.<\/p>\n Atlassian stellte eine Aktualisierung bereit. Die neue Version legt keinen Account mehr an und entfernt das Konto, falls es existiert. Doch nicht alle Betroffene werden damit gesch\u00fctzt: Wer Beispielsweise die Erweiterung fr\u00fcher installiert hatte, bei dem ist die Hintert\u00fcr noch vorhanden. So jemand lie\u00dft die Meldung m\u00f6glicherweise gar nicht, weil er sich sich f\u00fcr nicht betroffen h\u00e4lt. Oder deaktiviert bzw. entfernt die Erweiterung, im Glaube, damit die Gef\u00e4hrdung abzuschalten. Das reicht jedoch nicht. Auch das L\u00f6schen des Kontos ist unzureichend: Wenn die Erweiterung aktiv ist und nicht aktualisiert wurde, wird sie den Account wieder anlegen.<\/p>\n Noch brisanter wird der Vorfall dadurch, dass eine Einweg-E-Mail-Adresse des Dienstes Yopmail eingetragen wurde: \u00dcber das Web kann dort jeder durch Eingabe der in Confluence sichtbaren Adresse s\u00e4mtliche Mails lesen, ohne Schutz<\/a>. Das ist problematisch, weil Confluence an alle Benutzer regelm\u00e4\u00dfig Newsletter verschickt. Das Postfach dieser Adresse enth\u00e4lt viele solcher Mails<\/a>. Schon in diesen Nachrichten k\u00f6nnen Inhalte aus Confluence und damit sensible\/interne Informationen enthalten sein, etwa als Vorschautext. Noch schwerwiegender ist aber, dass die vorhandenen Newsletter eine f\u00fcr jeden abrufbare Liste mit verwundbaren Installationen darstellen. Schlie\u00dflich enthalten diese Links zum jeweiligen Confluence. Und alle Instanzen welche E-Mails an diese Adresse senden, sind von der L\u00fccke betroffen.<\/p>\n Ein weiteres Risiko besteht durch die M\u00f6glichkeit, das Passwort per E-Mail zur\u00fcck zu setzen. Auch daf\u00fcr lie\u00dfe sich das \u00f6ffentlich erreichbare Postfach missbrauchen. In einer Sammlung von h\u00e4ufig gestellten Fragen<\/a> listet der Hersteller die Frage „Warum es j\u00fcngst so viele Sicherheitswarnungen“ gab, weicht jedoch aus.<\/p>\n Zusammen mit der vorhin erw\u00e4hnten Sicherheitsl\u00fccke in „Questions for Confluence“ wurden zwei weitere Sicherheitsl\u00fccken bekannt: Nahezu die gesamte Produktpalette des Herstellers Atlassian ist von CVE-2022-26136 und CVE-2022-26137 betroffen<\/a>. In beiden F\u00e4llen geht es um fehlerhafte Filter. Die zweite L\u00fccke erm\u00f6glicht es, CORS-Header mithilfe einer manipulierten Anfrage zu umgehen. In der Praxis bedeutet das: Der Angreifer sendet dem Opfer einen pr\u00e4parierten Link. Klickt das Opfer darauf, kann der Angreifer das Konto kapern – er hat die gleichen Rechte in der verwundbaren Atlassian-Anwendung, wie das Opfer.<\/p>\n CVE-2022-26136 erm\u00f6glicht sogar zwei Schwachstellen: Per XSS kann der Angreifer mit einer bestimmten Adresse JavaScript-Code in den Browser einschleusen. Klickt das Opfer auf so einen Link, kann der Angreifer z.B. die Sitzung des Opfers stehlen. Oder alle Aktionen ausf\u00fchren, zu denen das Konto des Opfers die notwendigen Rechte besitzt. Zus\u00e4tzlich l\u00e4sst sich die Authentifizierung durch diese L\u00fccke sogar komplett aushebeln: Der Angreifer hat damit Zugriff auf Funktionen der Anwendung, ohne dass ein anderer Benutzer daf\u00fcr irgend eine Aktion ausf\u00fchren muss.<\/p>\n Im November 2021 kam es zu einer mit Risiko „hoch“ kategorisierten Schwachstelle, die einen Gro\u00dfteil der Atlassian-Software betraf<\/a>. Die Systeme pr\u00fcften Nutzereingaben nicht korrekt, etwa aus Beschreibungs- oder Kommentarfeldern. Dadurch k\u00f6nnen unsichtbare Zeichen in den Code eingeschleust werden<\/a>, um ihn zu manipulieren.<\/p>\n Es gibt noch viele weitere Beispiele. CVE-2019-3398 ist beispielsweise eine Sicherheitsl\u00fccke<\/a>, bei der Angreifer durch hochgeladene Dateien beliebig in das Dateisystem des Servers schreiben konnten. Dadurch war die unkontrollierte Ausf\u00fchrung von Schadcode m\u00f6glich. Solche L\u00fccken sind leicht auszunutzen<\/a>, haben jedoch schwerwiegende Folgen. Das Pr\u00fcfen von Inhalten die von Nutzern eingegeben werden, ist eine grundlegende Schutzma\u00dfnahme. Atlassian f\u00e4llt immer wieder damit auf, dass Grundlagen der Sicherheit unvollst\u00e4ndig oder gar nicht umgesetzt werden. Offensichtlich sieht das Unternehmen selbst die seit 2017 explodierende Anzahl an Schwachstellen<\/a> nicht als Anlass, ihre Sicherheitsvorkehrungen zu pr\u00fcfen und deutlich zu verbessern.<\/p>\n Was bei Atlassian gravierend schief l\u00e4uft, demonstrieren CVE-2016-10750 und CVE-2022-26133<\/a> an einem Extrembeispiel: Die erste CVE wurde im April 2016 in der Hazelcast-Bibliothek entdeckt<\/a>. Dort erhielt sie einige Zeit lang wenig Beachtung, bis dieser Pull request das Problem im Januar 2018 l\u00f6ste<\/a>. Die V<\/a>ersion 3.11<\/a> enth\u00e4lt den Fix. Bei Atlassian interessierte man sich nicht daf\u00fcr – erst im M\u00e4rz 2022 ver\u00f6ffentlicht Atlassian einen Security Advisory, dass mehrere Atlassian-Anwendungen von der 2016 entdeckten L\u00fccke betroffen sind. Mindestens 4 Jahre lang hielt es Atlassian also nicht f\u00fcr n\u00f6tig, ihre Abh\u00e4ngigkeiten zu pr\u00fcfen, geschweige denn zu aktualisieren. Und das w\u00e4re wahrscheinlich noch viel l\u00e4nger, denn CVE-2022-26133 hat ein unabh\u00e4ngiger Dritter gemeldet. Erst dadurch wurde Atlassian auf das Sicherheitsproblem aufmerksam.<\/p>\n Und selbst danach scheint Atlassian schlampig gearbeitet zu haben: Im Security Advisory wird bis heute behauptet, es seien nur die DataCenter-Versionen von z.B. BitBucket betroffen. In dieser Ank\u00fcndigung schlie\u00dfen sie sogar explizit aus<\/a>, dass BitBucket Cloud sowie Server von dieser L\u00fccke verwundbar sind. Offensichtlich stimmt das nicht, wenn der Hazelcast-Port 5701 auch auf meiner BitBucket Server Instanz lauscht:<\/p>\n Diese erschreckende Nachl\u00e4ssigkeit l\u00e4sst nur einen Schluss zu: Atlassian hat jede Menge Drittanbieter-Abh\u00e4ngigkeiten in ihrer Software, die sie offensichtlich nie pr\u00fcfen oder gar aktualisieren. Das sind grundlegende Sicherheitsma\u00dfnahmen, sie geh\u00f6ren zum kleinen Einmaleins.<\/p>\n Wenn eine Software Sicherheitsaktualisierungen bereitstellt, sollte man diese nat\u00fcrlich so schnell wie m\u00f6glich einspielen – das ist eine altbekannte Grundlage f\u00fcr IT-Sicherheit und gilt unabh\u00e4ngig von einzelnen Produkten oder Herstellern. Bei Atlassian ist dies jedoch mit einem cleveren Preisschild versehen: S\u00e4mtliche Aktualisierungen kann man nur installieren, sofern zum Ver\u00f6ffentlichungsdatum ein aktiver Supportvertrag besteht wurde. Der kostet, und zwar nicht zu knapp. Fehlerkorrekturen sind hierbei keine Ausnahme, selbst f\u00fcr Sicherheitsaktualisierungen verlangt Atlassian Geld<\/a>.<\/p>\n Dass der Fehler ja bereits von Atlassian in der Vergangenheit gemacht wurde und somit dem Kunde ein mangelndes Produkt verkauft wurde, spielt f\u00fcr das Unternehmen keine Rolle. Man stelle sich das in anderen Branchen vor: Es wird z.B. ein Serienfehler in einem Automodell bekannt. Der Hersteller behebt ihn, aber verlangt daf\u00fcr einen Wartungsvertrag. Dieser kostet nicht nur jeden Monat bzw. jedes Jahr Geld, sondern wird zudem jedes Jahr deutlich teurer. W\u00fcrde man vermutlich nicht akzeptieren, und das zu Recht. Vor allem dann, wenn es sich dazu nicht um einen einzigen Fehler handelt. Sondern alle paar Monaten ein neuer entdeckt wird.<\/p>\n Diese Frage stellt sich nach einem Blick auf Atlassians Qualit\u00e4t unweigerlich: M\u00fcsste der Markt das nicht regeln? Das passiert aus vermutlich mehreren Gr\u00fcnden nicht: Atlassian versucht mit allen Mitteln, die Kunden in ihre Cloud zu dr\u00e4ngen. Beispielsweise ist bei jeder der Dokumente zu den Sicherheitsl\u00fccken zu lesen, alle Cloud-Produkte seien nicht betroffen. Im besten Falle lie\u00dft man, dass Atlassian die Updates dort bereits eingespielt hat<\/a>. Als sei On-Prem das Problem, nicht die offensichtlich fragw\u00fcrdige Qualit\u00e4t. <\/p>\n Ob man glauben mag, dass Atlassian bei den Cloudprodukten viel bessere Arbeit liefert als On-Prem, muss jeder f\u00fcr sich selbst entscheiden. Wer das tat, d\u00fcrfte sp\u00e4testens seit M\u00e4rz 2022 wieder entt\u00e4uscht sein: Dort sind Atlassians Clouddienste f\u00fcr mehrere Wochen ausgefallen<\/a>. Ursache waren mehrere Fehler des Unternehmens selbst. Neben schlechter Kommunikation und fehlerhaften Skripten hat es Atlassian vers\u00e4umt, die Wiederherstellung zu testen. F\u00fcr eine garantierte Verf\u00fcgbarkeit von 99,9 % oder gar 99,95 % zahlt man \u00fcbrigens Aufpreise<\/a>. Im Standardpreis ist gar keine Verf\u00fcgbarkeit inbegriffen. Auf der Werbeseite<\/a>, um den Kunden die Cloud schmackhaft zu machen, wird mit „H\u00f6here Zuverl\u00e4ssigkeit“ geworben.<\/p>\n Das gr\u00f6\u00dfte Problem, warum Kunden sich das antun, d\u00fcrfte aber woanders liegen: In bestimmten Bereichen gibt es keine „Enerprise-Software“, die uneingeschr\u00e4nkt mit Atlassian vergleichbar ist. Besonders bei Jira und Confluence hat das Unternehmen eine Monopolstellung aufgebaut. In anderen Gebieten dagegen kann sich Atlassian gegen die Konkurrenz nicht durchsetzen, weil die mindestens gleichwertig ist – teils sogar besser und\/oder g\u00fcnstiger: <\/p>\n Bitbucket verliert deutlich an Marktanteilen<\/a> zugunsten von GitLab und GitHub.<\/p>\n HipChat wurde daher 2019 sogar komplett abgeschaltet<\/a>. Wer Cloud m\u00f6chte nutzt Slack oder Teams, zum selber Betreiben stehen genug FOSS-Alternativen wie z.B. Matrix oder Mattermost bereit.<\/p>\n Offensichtlich fehlen bei Atlassian grundlegende Sicherheitsma\u00dfnahmen und Qualit\u00e4tskontrollen seit Jahren. Das hindert den Konzern aber nicht daran, die Kunden mit saftigen Preiserh\u00f6hungen zur Kasse zu bitten oder gar in die Cloud zu dr\u00e4ngen. Ironischerweise werden diese u.a. mit dem „besonderen Wert auf Sicherheit“ begr\u00fcndet<\/a>. Leidtragende sind alle Kunden, die trotz stetig steigender Kosten schlechte Produkte erhalten, welche immer wieder ein schweres Sicherheitsrisiko darstellen.<\/p>\nBitucket<\/h3>\n
Codeausf\u00fchrung Januar 2020<\/h4>\n
Codeausf\u00fchrung August 2022<\/h4>\n
Jira<\/h3>\n
Codeausf\u00fchrung Service Management Oktober 2021<\/h4>\n
Codeausf\u00fchrung in Slack-Erweiterung f\u00fcr Jira<\/h4>\n
Confluence<\/h3>\n
CVE-2021-26084 ist doch f\u00fcr nicht authentifizierte Nutzer ausnutzbar<\/h4>\n
Zero-Day Schwachstelle im Juni 2022<\/h4>\n
„Questions for Confluence“ umgeht Benutzerauthentifizierung<\/h4>\n
Sicherheitsl\u00fccken in allen Atlassian-Produkten<\/h3>\n
Viele Beispiele, wenig Besserung<\/h2>\n
Falschinformationen und ein kaputtes Update-Konzept<\/h2>\n
\n$ sudo netstat -tulpn | grep 5701\ntcp 0 0 0.0.0.0:5701 0.0.0.0:* LISTEN 6728\/java\n\n$ sudo ps -ax | grep 6728\n 6728 ? Sl 104:13 \/usr\/java\/latest\/bin\/java -classpath \/home\/bitbucket\/bitbucket\/app -Datlassian.standalone=BITBUCKET -Dbitbucket.home=\/home\/bitbucket\/data -Dbitbucket.install=\/home\/bitbucket\/bitbucket -Xms512m -Xmx1g -XX:+UseG1GC -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -Djava.io.tmpdir=\/home\/bitbucket\/data\/tmp -Djava.library.path=\/home\/bitbucket\/bitbucket\/lib\/native;\/home\/bitbucket\/data\/lib\/native com.atlassian.bitbucket.internal.launcher.BitbucketServerLauncher start\n<\/pre>\n<\/div>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2022\/11\/grafik-1024x267.png\")
<\/a><\/figure>\nSicherheitsupdates nicht f\u00fcr alle<\/h2>\n
Warum werden die Produkte trotzdem genutzt?<\/h2>\n
Fazit<\/h2>\n