3.000 geleakte ASP.NET-Schlüssel mit Angriffspotenzial entdeckt
Microsoft warnt vor einer unsicheren Praxis bequemer Softwareentwickler: Diese bedienen sich gerne aus öffentlich frei zugänglichen Quellen an ASP.NET Machine Keys und integrieren sie in ihre Anwendungen. Was sie dabei nicht auf dem Radar haben: Ihre Software wird dadurch anfällig für Code-Injection-Angriffe.
ASP.NET Machine Keys aus frei zugänglichen Quellen werden oft in Online-Dokumentationen, Code-Repositories oder Foren veröffentlicht und von Entwicklern möglicherweise aus Bequemlichkeit oder Unwissenheit gerne übernommen.
Das Problem: Diese Machine Keys sind essenziell für die Sicherheit von ASP.NET-Anwendungen. Sie werden unter anderem zur Verschlüsselung und Signierung von ViewState-Daten verwendet, die Informationen über den Zustand einer Webanwendung zwischen Client und Server speichern. Wenn ein Angreifer Zugriff auf diese Schlüssel hat, kann er manipulierte ViewState-Daten einschleusen, die dann vom Server als legitim anerkannt werden. Dadurch wird es möglich, Schadcode auszuführen und die Kontrolle über die Anwendung zu übernehmen.
Microsofts Sicherheitsteam hat im Dezember 2024 verdächtige Aktivitäten entdeckt: Ein unbekannter Angreifer nutzte einen öffentlich zugänglichen, festgelegten ASP.NET Machine Key, um schädlichen Code einzuschleusen und das Godzilla Post-Exploitation-Framework zu verbreiten.
Zudem hat Microsoft über 3.000 öffentlich bekannte Machine Keys identifiziert, die für ähnliche Angriffe verwendet werden könnten. Diese Angriffsmethode wird als ViewState Code Injection Attack bezeichnet.
Wie der Angriff im Detail funktioniert
„Während frühere Angriffe dieser Art meist gestohlene oder kompromittierte Schlüssel nutzten, die im Darknet verkauft wurden, stellen diese öffentlich einsehbaren Schlüssel ein noch größeres Risiko dar. Sie sind in verschiedenen Code-Repositories verfügbar und könnten unverändert in Entwickler-Code eingeflossen sein“, so Microsoft. „Standardmäßig wird ViewState-Daten in einem versteckten Feld auf der Seite abgelegt und mit Base64 kodiert“, erklärt Microsoft in einer Dokumentation. „Zusätzlich wird ein Hash-Wert mit einem Machine Authentication Code (MAC)-Schlüssel erstellt und dem ViewState-String hinzugefügt.“
Dieser Hash soll sicherstellen, dass die ViewState-Daten nicht manipuliert wurden. Sind die Schlüssel jedoch öffentlich oder gestohlen, können Angreifer sie nutzen, um manipulierte ViewState-Anfragen zu senden und Schadcode auszuführen. „Wenn die Anfrage vom ASP.NET Runtime auf dem Zielserver verarbeitet wird, wird der ViewState entschlüsselt und validiert, da die richtigen Schlüssel verwendet werden“, so Microsoft. „Der Schadcode wird dann in den Arbeitsspeicher geladen und ausgeführt, wodurch der Angreifer Zugriff auf den betroffenen IIS Webserver erhält.“
Microsoft hat eine Liste mit Hash-Werten der betroffenen Machine Keys veröffentlicht und empfiehlt dringend, diese mit den eigenen Machine Keys zu vergleichen. Ein einfaches Ersetzen der Schlüssel reicht im Falle eines erfolgreichen Angriffs jedoch nicht aus, da sich Angreifer möglicherweise bereits dauerhaft auf dem System eingenistet haben.
Um das Risiko zu minimieren, rät Microsoft, keine Schlüssel aus öffentlichen Quellen zu übernehmen und Machine Keys regelmäßig zu wechseln. Zudem hat Microsoft sicherheitskritische Schlüssel aus einigen seiner eigenen Dokumentationen entfernt, um es Angreifern schwerer zu machen, diese für Attacken zu missbrauchen.
Ähnlich gelagerte Schwachstelle im OPA-Gatekeeper
Diese Entwicklung fällt mit den neuesten Erkenntnissen des Cloud-Sicherheitsunternehmens Aqua zusammen. Aqua hat eine Schwachstelle im OPA Gatekeeper entdeckt, die Angreifer nutzen könnten, um in Kubernetes-Umgebungen unautorisierte Aktionen auszuführen – etwa das Bereitstellen unerlaubter Container-Images. „In der k8sallowedrepos-Richtlinie entsteht ein Sicherheitsrisiko durch einen Fehler in der Rego-Logik innerhalb der ConstraintTemplate-Datei“, erklären die Sicherheitsexperten Yakir Kadkoda und Assaf Morag in einer Analyse.
Das Problem wird noch größer, wenn Nutzer Werte in der Constraint YAML-Datei angeben, die nicht mit der Funktionsweise der Rego-Logik übereinstimmen. Dadurch können Sicherheitsrichtlinien umgangen werden, sodass eigentlich vorgesehene Einschränkungen wirkungslos bleiben.