Wie X.509-Zertifikate in den SolarWinds-Angriff involviert waren

Einen Moment lang waren wir bereit, das Jahr 2020 hinter uns zu lassen, bis zu dieser Woche.

Es begann mit dem gemeldeten Diebstahl der Red-Team-Tools von FireEye, und dann kamen die größeren Nachrichten. FireEye und die US-Finanz- und Handelsministerien wurden über SolarWinds Orion software -Updates infiltriert, die bösartigen Code enthielten, der von der russischen Hackergruppe Cozy Bear (APT 29) eingeschleust wurde.

Diese Nachricht betrifft nicht nur SolarWinds, FireEye und US-Behörden - sie betrifft uns alle. Wenn ein Nationalstaat einen von uns angreift, greift er uns alle an, und wir alle spüren den Stachel. Es ist eine ernüchternde Erinnerung an unsere tägliche Realität: Jeder kann angegriffen werden.

Während die vollständigen Details des Angriffs - der jetzt als SUNBURST bekannt ist - noch nicht bekannt gegeben wurden, haben wir viel mehr über unsere Gegner erfahren und darüber, wie sie es geschafft haben, die Verteidigungsmaßnahmen zu umgehen.

Schauen wir uns an, was wir bis jetzt wissen:

• Am^8. Dezember gab FireEye den Diebstahl seiner Red-Team-Bewertungstools aus einem GitHub-Repository bekannt. Trotz des Hypes waren die meisten dieser Tools und Exploits bereits bekannt.
• Am^13. Dezember entdeckte FireEye in einer eigenen Untersuchung, dass es sich bei dem Angriff um bösartigen Code handelte, der in legitime software Updates der SolarWinds Orion Platform aus der Zeit zwischen März 2020 und Mai 2020 eingefügt wurde.
• Am selben Tag gaben das US-Finanzministerium und das Handelsministerium bekannt, dass ihre Systeme von einer von Russland unterstützten Hackergruppe namens CozyBear (APT 29) angegriffen wurden. Die CISA veröffentlichte daraufhin die Notfallrichtlinie 21-01, "Mitigate SolarWinds Orion Code Compromise".
• Am^15. Dezember beschlagnahmte Microsoft den bösartigen Domänennamen, der zur Steuerung der betroffenen Systeme verwendet wurde, um den Angriff mit einem "Kill Switch" zu verhindern oder sogar zu entschärfen.

Es wird wahrscheinlich eine Weile dauern, den Umfang und das Ausmaß dieses Vorfalls zu ermitteln, aber in der vergangenen Woche haben wir viel über die von den Angreifern verwendeten Tools und Techniken erfahren.

Nachdem sich der Staub gelegt hat und weitere Details aufgetaucht sind, ist eines klar geworden: Angreifer haben X.509-Zertifikate und -Schlüssel als Teil ihrer Werkzeuge missbraucht, um sich als vertrauenswürdig auszugeben und eine Entdeckung zu vermeiden. Es begann mit SolarWinds, aber damit ist es nicht getan.

In einem kürzlich veröffentlichten Artikel des Microsoft Security Response Center werden einige der technischen Details des Angriffs auf die Lieferkette erläutert. Hier sind einige wichtige Erkenntnisse darüber, wie X.509-Zertifikate von den Angreifern zum Fälschen und Untergraben des Vertrauens verwendet wurden:

Eine Spur von Brotkrumen führt uns zurück zu SolarWinds, wo Angreifer den Quellcode modifiziert haben, um eine bösartige Hintertür einzubauen, die dann von SolarWinds unwissentlich kompiliert, signiert und über die software Update- und Code-Signierungssysteme an fast 18.000 Kunden geliefert wurde.

Der ursprüngliche Einbruch war nicht das Ergebnis eines gestohlenen Code-Signatur-Zertifikats, sondern die manipulierte Bibliothek wurde von SolarWinds signiert, wodurch sie auf den Systemen der Endbenutzer als legitim erschien. Es gibt zwar keine Beweise dafür, dass das Signierzertifikat oder der Prozess selbst kompromittiert wurde, aber der Erstellungs- und Überprüfungsprozess vor dem Signieren wurde kompromittiert, wodurch der bösartige Code durchschlüpfen konnte.

Das ist auch nicht das erste Mal. Angreifer machen sich zunehmend das Vertrauen zunutze, auf das wir uns verlassen. Bei ähnlichen Angriffen auf die Lieferkette wurden entweder Code-Signaturzertifikate gestohlen(z. B. bei den Angriffen von APT41 und Kimsuky) oder manipulierter Code durch den Signierungsprozess geschleust (z. B. beim Angriff auf ASUS im vergangenen Jahr).

Laut Microsoft "nutzt der Eindringling dann, sobald er im Netzwerk ist, die administrativen Berechtigungen, die er durch die Kompromittierung vor Ort erlangt hat, um Zugriff auf das globale Administratorkonto des Unternehmens und/oder das vertrauenswürdige SAML-Tokensignaturzertifikat zu erhalten".

In diesem Fall fälschten die Angreifer SAML-Tokens und signierten sie mit legitimen, kompromittierten Zertifikaten, um sich als vertrauenswürdige Benutzer und Konten auszugeben, so dass sie sich unentdeckt bewegen konnten.

In einigen Fällen nahm der böswillige Akteur Änderungen an den Azure-Active-Directory-Einstellungen vor, um langfristigen Zugriff zu erlangen, einschließlich des "Hinzufügens von Anmeldeinformationen (X.509-Schlüssel oder Kennwort-Anmeldeinformationen) zu einer oder mehreren legitimen OAuth-Anwendungen...".

Wenn sie erst einmal Fuß gefasst haben, besteht die nächste Priorität für Angreifer oft darin, Wege zu finden, um im Netzwerk zu bleiben. Hier nutzten sie X.509-Zertifikate, um einen legitimen OAuth-Zugang zum Netzwerk zu schaffen.

Wie ich bereits erwähnt habe, gibt es keine Patentlösung, um diese ausgeklügelten Angriffe zu verhindern. Es handelte sich um einen äußerst raffinierten Angriff, bei dem viele verschiedene Tools und Techniken zum Einsatz kamen.

Wir sind nicht hier, um zu spekulieren, sondern um auf ein wachsendes Problem aufmerksam zu machen, das wir in der Branche beobachten: den zunehmenden Missbrauch und Diebstahl von Schlüsseln und digitalen Zertifikaten. Es geht nicht um diese oder die nächste Sicherheitsverletzung, sondern um die Notwendigkeit, die Verwendung von Zertifikaten in Anwendungen, Cloud- und Netzwerkinfrastrukturen effektiv zu verfolgen und zu überwachen.

Im Folgenden werden einige bewährte Verfahren zur Eindämmung des Missbrauchs von Schlüsseln und Zertifikaten empfohlen:

• Führen Sie ein aktives Inventar aller Zertifikate, wo sie installiert sind, von wem sie ausgestellt wurden und wem sie (und Ihre Domänen) gehören.
• Steuern Sie die Arbeitsabläufe für die Ausstellung und Genehmigung von Zertifikaten, um sicherzustellen, dass jedes Zertifikat vertrauenswürdig, richtlinienkonform und aktuell ist.
• Testen Sie regelmäßig Ihre Fähigkeiten zur Neuausstellung und zum Widerruf von Zertifikaten, um sicherzustellen, dass Sie effektiv auf eine Kompromittierung reagieren können.
• Speichern Sie Code-Signierungsschlüssel niemals auf Entwickler-Workstations oder Build-Servern. Private Schlüssel sollten in einem FIPS 140-2-validierten HSM aufbewahrt werden und niemals die hardware verlassen.
• Trennen Sie die Aufgaben derjenigen, die zum Signieren von Code berechtigt sind, die den Antrag genehmigen können und die die Einhaltung der Signierrichtlinien überwachen und durchsetzen können.
• Definieren Sie Richtlinien zur Beschränkung des Zugriffs auf Code-Signaturschlüssel nach Benutzer, Rechner, Standort, Dauer, Tageszeit, Signiermethode oder anderen Parametern, die für Ihr Unternehmen sinnvoll sind.

Wenn Sie mehr über die Trends erfahren möchten, die wir bei der Verwendung (und dem Missbrauch) von Kryptografie beobachten, lesen Sie unseren Bericht zu den Kryptografie-Trends 2021.