Kritischer Jira-Fehler in Atlassian könnte zu RCE führen

  • Die Software-Engineering-Plattform fordert die Nutzer auf, den kritischen Fehler so schnell wie möglich zu patchen.

    Atlassian hat einen Patch für eine kritische Sicherheitslücke in vielen Versionen seiner Produkte Jira Data Center und Jira Service Management Data Center veröffentlicht, die zur Ausführung von beliebigem Code führen kann.

    Atlassian ist eine Plattform, die von 180.000 Kunden für die Entwicklung von Software und die Verwaltung von Projekten genutzt wird, und Jira ist das firmeneigene Tool zur Fehlerverfolgung und zum agilen Projektmanagement.

    Am Mittwoch veröffentlichte Atlassian einen Sicherheitshinweis zu der Schwachstelle, die als CVE-2020-36239 verfolgt wird. Der Fehler könnte entfernten, nicht authentifizierten Angreifern die Ausführung von beliebigem Code in einigen Jira Data Center-Produkten ermöglichen.

    BleepingComputer hat eine E-Mail erhalten, die Atlassian am Mittwoch an Unternehmenskunden verschickt hat und in der diese aufgefordert werden, so schnell wie möglich ein Update durchzuführen.

    Die Schwachstelle hat mit einer fehlenden Authentifizierungsprüfung in der Jira-Implementierung von Ehcache zu tun. Ehcache ist ein verteilter Open-Source-Java-Cache für Allzweck-Caching, Java EE und leichtgewichtige Container, der für die Leistung verwendet wird und die Skalierbarkeit vereinfacht.

    Atlassian sagte, dass der Fehler in Version 6.3.0 von Jira Data Center, Jira Core Data Center, Jira Software Data Center und Jira Service Management Data Center (vor 4.14 als Jira Service Desk bekannt) eingeführt wurde.

    Laut dem Sicherheitshinweis von Atlassian enthüllt diese Liste von Produkten einen Ehcache-Remote-Methodenaufruf (RMI) Netzwerkdienst, den Angreifer – die sich mit dem Dienst auf Port 40001 und möglicherweise 40011 verbinden können – aufgrund der fehlenden Authentifizierung durch Deserialisierung nutzen können, um “beliebigen Code ihrer Wahl in Jira auszuführen”.

    RMI ist eine API, die als Mechanismus für die Remote-Kommunikation zwischen in Java geschriebenen Programmen dient. Es ermöglicht einem Objekt, das sich in einer Java Virtual Machine (JVM) befindet, ein Objekt aufzurufen, das auf einer anderen JVM läuft; oft handelt es sich dabei um ein Programm auf einem Server und eines auf einem Client. Der Vorteil von RMI ist, wie BleepingComputer es beschreibt, dass “Programmierer Methoden in entfernten Objekten aufrufen können – z. B. in einer Anwendung, die auf einem gemeinsam genutzten Netzwerk läuft – und zwar direkt aus ihrer Anwendung heraus, so als würden sie eine lokale Methode oder Prozedur ausführen.”

    [Blocked Image: https://media.threatpost.com/wp-content/uploads/sites/103/2021/07/22161351/RMI.png]

    Funktionsweise von RMI. Quelle: Wikipedia.

    Atlassian “empfiehlt dringend”, den Zugriff auf die Ehcache-Ports nur auf Data Center-Instanzen zu beschränken, weist aber auf eine Einschränkung hin: “Fixierte Versionen von Jira erfordern nun ein gemeinsames Geheimnis, um den Zugriff auf den Ehcache-Dienst zu ermöglichen”, heißt es in der Empfehlung.

    Betroffene Versionen

    Dies sind die betroffenen Versionen von Jira Data Center und Jira Service Management Data Center:

    Jira Data Center, Jira Core Data Center, und Jira Software Data Center – Bereiche

    • 6.3.0 <= Version < 8.5.16
    • 8.6.0 <= Version < 8.13.8
    • 8.14.0 <= Version < 8.17.0

    Jira Service Management Data Center – Bereiche

    • 2.0.2 <= Version < 4.5.16
    • 4.6.0 <= Version < 4.13.8
    • 4.14.0 <= Version < 4.17.0

    Jira Data Center, Jira Core Data Center und Jira Software Data Center

    • Alle 6.3.x, 6.4.x Versionen
    • Alle 7.0.x, 7.1.x , 7.2.x, 7.3.x, 7.4.x, 7.5.x, 7.6.x, 7.7.x, 7.8.x, 7.9.x, 7.10.x, 7.11.x, 7.12.x, 7.13.x Versionen
    • Alle Versionen 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x
    • Alle 8.5.x-Versionen vor 8.5.16
    • Alle 8.6.x, 8.7.x, 8.8.x, 8.9.x, 8.10.x, 8.11.x, 8.12.x Versionen
    • Alle 8.13.x-Versionen vor 8.13.8
    • Alle 8.14.x, 8.15.x, 8.16.x Versionen

    Jira Service Management Data Center

    • Alle 2.x.x Versionen nach 2.0.2
    • Alle 3.x.x-Versionen
    • Alle 4.0.x, 4.1.x, 4.2.x, 4.3.x, 4.4.x Versionen
    • Alle 4.5.x-Versionen vor 4.5.16
    • Alle 4.6.x, 4.7.x, 4.8.x, 4.9.x, 4.10.x, 4.11.x, 4.12.x Versionen
    • Alle 4.13.x-Versionen vor 4.13.8
    • Alle 4.14.x, 4.15.x, 4.16.x Versionen

    In dem Advisory von Atlassian heißt es, dass Kunden, die eine der betroffenen Versionen heruntergeladen und installiert haben, “ihre Installationen sofort aktualisieren müssen, um diese Sicherheitslücke zu beheben.” Allerdings weist Atlassian auch darauf hin, dass die Einstufung als “kritisch” eine eigene Einschätzung ist und dass Kunden “die Anwendbarkeit auf ihre eigene IT-Umgebung bewerten sollten.”

    Nicht-betroffene Versionen

    Hier ist die Liste der Produkte, die nicht von dem Fehler betroffen sind:

    • Atlassian Cloud
    • Jira Wolke
    • Jira Service Management Cloud
    • Nicht-Rechenzentrum-Instanzen von Jira Server (Core & Software) und Jira Service Management

    Außerdem sind Kunden, die ein Upgrade von Jira Data Center, Jira Core Data Center, Jira Software Data Center auf Version 8.5.16, 8.13.8, 8.17.0 und/oder Jira Service Management Data Center auf Version 4.5.16, 4.13.8 oder 4.17.0 durchgeführt haben, aus dem Schneider: Sie müssen kein Upgrade durchführen.

    Atlassian ist Angreifer-Catnip

    Einige der größten Unternehmen mit der anspruchsvollsten Produktentwicklung verwenden Produkte von Atlassian. Unter den mehr als 65.000 Anwendern zählt Jira einige große Fans, darunter solche wie die Apache Software Foundation, Cisco, Fedora Commons, Hibernate, Pfizer und Visa.

    Leider machen seine Beliebtheit – vor allem bei den großen Fischen – und seine Fähigkeiten es zu einem verlockenden Ziel für Angreifer.

    Im Juni entdeckten Forscher Fehler in Atlassian, die zu einer Übernahme mit einem Klick hätten führen können: Ein Szenario, das das Potenzial für einen Exploit ähnlich dem SolarWinds-Supply-Chain-Angriff in sich barg, bei dem Angreifer ein Standardpasswort als offene Tür in einen Software-Aktualisierungsmechanismus nutzten.

    Chris Morgan, Senior Cyber-Threat Intelligence Analyst beim Digital-Risk-Provider Digital Shadows, sagte, dass die Schwachstelle, die den Kern der Mittwochs-Empfehlung bildet, nur die jüngste in einer Reihe von Fehlern ist, die Software-Engineering- und Management-Plattformen betreffen, die, wenn sie ausgenutzt werden, zu einer Reihe von schädlichen Ergebnissen führen könnten”.

    Während es derzeit keine Anzeichen für eine aktive Ausnutzung gibt, können wir erwarten, dass in den kommenden ein bis drei Monaten Versuche auftauchen werden, sagte Morgan voraus. “CVE-2020-36239 kann aus der Ferne ausgenutzt werden, um willkürliche Code-Ausführung zu erreichen und wird wahrscheinlich sowohl für Cyber-Kriminelle als auch für mit dem Staat verbundene Akteure von großem Interesse sein”, sagte er. Er verwies auf mehrere jüngste Angriffe auf die Lieferkette, darunter Angriffe auf die Softwareanbieter Accellion und Kaseya, bei denen die Schwachstellen ausgenutzt wurden, um einen ersten Zugang zu erlangen und Software-Builds zu kompromittieren, “von denen bekannt ist, dass sie von einem vielfältigen Kundenstamm verwendet werden.”

    Andere Sicherheitsexperten stimmten mit Morgans Einschätzung überein. Andrew Barratt, Managing Principal of Solutions and Investigations bei der Cybersecurity-Beratungsfirma Coalfire, erklärte am Donnerstag gegenüber Threatpost, dass die am Mittwoch bekannt gewordene Schwachstelle bei Atlassian “zeigt, dass Angreifer immer noch versuchen, Skaleneffekte zu nutzen und mehrere Parteien mit Hilfe einzelner plattformweiter Schwachstellen zu kompromittieren.”

    Erwarten Sie Exploitation, In-the-Wild-Angriffe

    TL;DR: Wenden Sie das Update so schnell wie möglich an oder implementieren Sie die von Atlassian vorgeschlagenen Workarounds, betonte Morgan.

    Die tatsächliche Auswirkung hängt jedoch von der Exposition der RMI-APIs ab, schlug Barratt vor. “Das könnte zu gezielten Kampagnen führen, die sich auf Entwickler konzentrieren (die historisch gesehen viele Privilegien und nützliche Tools auf ihren Rechnern haben), die dann versuchen, Malware einzuschleusen, die die Atlassian-Schwachstellen zur weiteren Manipulation der Produktentwicklung ausnutzt”, sagte er.

    Auf der optimistischen Seite könnte sich das Problem verflüchtigen, bevor es schlimm wird, da Atlassian bereits Patches herausgibt und zu temporären Abhilfemaßnahmen rät, fügte Barratt hinzu. “Hoffentlich ist das Zeitfenster, in dem dieses Problem auftritt, minimal – und einige Nachprüfungen der Systeme, um nach Indikatoren für eine Kompromittierung zu suchen, geben die Gewissheit, dass nichts Ernsthaftes schief gelaufen ist.”

    Barratt meint, dass das Besorgniserregendste “der erneute Fokus auf eine potenzielle Goldmine von Möglichkeiten” sein sollte. Während das Anvisieren von Entwicklern nicht neu ist, sagte er, dass das Anvisieren ihrer Tools und ihrer Plattform und das Verringern des potenziellen Vertrauens in das Produkt “den Bedarf an Sicherheitsorchestrierungstools zeigt, die dabei helfen können, die Vielfalt des Problems auf eine einzige Managementansicht zu bringen.”

    Auf der technischen Seite der Dinge postulierte Shawn Smith – Director of Infrastructure beim Application Security Provider nVisium -, dass Supply-Chain-Angriffe ein gutes Argument gegen die automatische Aktualisierung von Abhängigkeiten sind, aber “das bedeutet auch, dass Sicherheitsteams diese effektiv und effizient überwachen und verwalten müssen”, wie er am Donnerstag gegenüber Threatpost per E-Mail erklärte.

    “Alle Aktualisierungen von Abhängigkeiten sollten vor der Verwendung überprüft werden, und Systeme sollten versionsgesperrte Abhängigkeiten verwenden, um zu verhindern, dass CI/CD-Systeme standardmäßig die neuesten Updates übernehmen”, fügte er hinzu. “Gleichzeitig sollten Sicherheitsteams überwachen, um sicherzustellen, dass keine Schwachstellen in den verwendeten Versionen vorhanden sind, und Entwickler und Betriebsteams informieren, wenn Probleme auftreten.”

    Schauen Sie sich unsere kostenlosen kommenden Live- und On-Demand-Webinar-Veranstaltungen an – einzigartige, dynamische Diskussionen mit Cybersecurity-Experten und der Threatpost-Community.

    Einige Teile dieses Artikels stammen aus:
    threatpost.com