Thought Leadership
Mitte Dezember veröffentlichte SolarWinds, Anbieter von IT-Management-Software, ein Security Advisory. Darin legte das Unternehmen dar, dass es Opfer einer anspruchsvollen Supply-Chain-Attacke geworden war. Der Angriff schleuste die als SUNBURST bekannte Backdoor in die Orion Plattform-Software des Unternehmens ein.
Betroffen sind die Versionen 2019.4 HF 5, 2020.2 ohne installierten Hotfix, und 2020.2 HF 1. Wird SUNBURST ausgeführt, ist ein Angreifer in der Lage, den Server zu kompromittieren, auf dem Orion-Build läuft.
Der Angriff auf die Lieferkette von SolarWinds betraf eine Vielzahl von Unternehmen und Regierungsbehörden. Eines dieser Opfer war Microsoft. In einem Blog-Update vom 31. Dezember teilte der Tech-Gigant mit, dass die Untersuchung keine Beweise für einen unbefugten Zugriff auf Produktionsdienste oder Kundendaten ergeben habe. Allerdings deckten die Analysen bei dieser Gelegenheit einen weiteren Angriffsversuch auf. Microsoft erklärt dazu in dem betreffenden Blog:
Wir haben bei einer kleinen Anzahl interner Konten ungewöhnliche Aktivitäten entdeckt. Bei der Überprüfung haben wir festgestellt, dass eines der Konten benutzt wurde, um Quellcode in etlichen Quellcode-Repositories anzusehen. Das Konto verfügte nicht über die Berechtigung, Code oder technische Systeme zu verändern. Unsere Untersuchung bestätigte außerdem, dass keine Änderungen vorgenommen worden sind.
Das in Redmond ansässige Unternehmen stellte klar, dass es bei seiner Software-Entwicklung einen sogenannten „Inner Source“-Ansatz verfolgt, bei dem der Quellcode in Microsoft sichtbar ist. Dadurch hängt die Sicherheit des Unternehmens nicht von der Geheimhaltung seines Quellcodes ab. Dennoch wirft ein solcher Versuch einige wichtige Fragen auf. Insbesondere zu der Art von Risiken, denen Microsoft aufgrund der Offenlegung möglicherweise noch ausgesetzt sein wird.
Dazu Fragen an Sam Curry, Chief Security Officer bei Cybereason.
Wird Microsofts Reputation aufgrund des Angriffs leiden? Welchen Risiken sind die Geschäftsgeheimnisse des Tech-Giganten ausgesetzt?
Sam Curry: Die Antwort auf die erste Frage lautet “Ja”. Das ist bereits passiert. Was die zweite Frage anbelangt, geht es darum, welcher Quellcode genau betroffen ist. Hat sich die Enthüllung möglicherweise auf die Microsoft Quantencomputer-IP oder auf die überaus wichtige Logik in Azure ausgewirkt? Das ist nämlich das Risiko des Unternehmens. Darüber muss Microsoft sich Gedanken machen, obwohl es soweit gut gelungen ist, das Risiko eines Reputationsschadens in Grenzen zu halten und mit der Öffentlichkeit in einen Dialog zu treten.
Besteht unabhängig davon, welche Informationen von diesem Angriff betroffen waren, die Möglichkeit, dass Bedrohungsakteure den Quellcode von Microsoft nutzen, um einen 0-Day-Angriff zu starten?
Sam Curry: Eventuell, ja. Vertritt Microsoft bei der Anwendungssicherheit einen aggressiven Ansatz? Praktiziert das Unternehmen Secure-by-Design, nutzt es Code- und Architektur-Reviews, Quellcode-und Objektcode-Analysen sowie solide, bewährte Praktiken bei der nachträglichen Bearbeitung von gemeldeten Fehlern und Schwachstellen? Wenn die Antwort „Ja“ lautet, super! Das heißt nämlich, dass der Code wahrscheinlich nur wenige bisher unentdeckte Probleme aufweist, die Angreifer bei einem 0-Day-Angriff ausnutzen können.
Um das zu verifizieren, muss man den Bereich des betroffenen Codes dahingehend überprüfen, wie viele Schwachstellen in der Vergangenheit aufgetreten sind und wie sie behandelt wurden. Ich gehe davon aus, dass das Unternehmen dies nachvollziehen kann. Niedrige Raten bei neu aufgetretenen Sicherheitslücken und schnelle Reaktionen sind ein gutes Zeichen, das Gegenteil ist weniger gut. Wenn der betroffene Code alt ist, ist er mit größerer Wahrscheinlichkeit bekannt, zuverlässig und mit weniger Tretminen behaftet. Aber auch hier kommt es auf die Historie an. Wir sollten nicht vergessen, dass bei einigen Programmiersprachen und Applikationstypen die Quelle ohnehin mehr oder weniger zugänglich ist (ja genau JavaScript, Dich meine ich). Daher spielt es zusätzlich eine Rolle, welche Anwendungen und Sprachen betroffen sind.
Daraus lässt sich die Frage ableiten: Wie groß ist der von diesem Angriff betroffene Code-Bestand? Welche Produkte und Dienste sind eventuell in Mitleidenschaft gezogen? Wie lange wird es dauern, bis der Code im Wesentlichen vollständig ersetzt ist? Handelt es sich um einen großen Code-Bestand, an dem sich wahrscheinlich nicht viel ändern wird? Oder handelt es sich eher um einen relativ kleinen Teil, der sich schnell überholt? Das wäre der bessere Fall – aber welcher Code betroffen war, ist eine nicht ganz triviale Überlegung, da einiger Code häufig wiederverwendet und großflächig genutzt wird.
Wenn nicht über einen 0-Day-Angriff, besteht dann die Möglichkeit, dass Angreifer bestimmte Codierungsmuster oder einen bestimmten Entwicklungsstil nutzen, um Sicherheitsschwachstellen und Mängel an anderer Stelle zu extrapolieren?
Sam Curry: Wenn ich das richtig verstehe, meint die Frage folgendes: Wenn ein Entwickler, sagen wir mal eine Vorliebe für bestimmte Codierungsschwächen oder Strukturen hat, könnten diese von einem fortgeschrittenen Angreifer für die eigene Forschung und Entwicklung genutzt werden? Ich halte das für höchst unwahrscheinlich. Trotzdem liegt es immer noch im Bereich des Möglichen. Diese Überlegungen fallen jetzt in den Zuständigkeitsbereich der Architekten, Stipendiaten, Führungskräfte, Sicherheitsexperten und Manager von Microsoft. Wichtig ist es, die Informationen mit der Sicherheits-Community zu teilen, um Kunden und Benutzer zu schützen, während das Unternehmen seine internen Berechnungen anstellt. Möglicherweise passt Microsoft sogar seine Entwicklungspraktiken an, damit Angreifer so wenig wie möglich zu sehen bekommen.
Kunden, die die Cybereason Defense Platform einsetzen, sind vor den SUNBURST- und SolarWinds-Attacken geschützt. Weitere Informationen finden Sie hier.
