Best Practices – Unsichere Deserialisierung nicht vertrauenswürdiger Daten

Unsichere Deserialisierung nicht vertrauenswürdiger Daten

Erklärung der Sicherheitslücke

Die Deserialisierung nicht vertrauenswürdiger Daten (CWE-502) tritt auf, wenn Anwendungen Daten aus nicht vertrauenswürdigen Quellen deserialisieren, ohne ausreichend zu überprüfen, ob die resultierenden Daten gültig sind und das In-Memory-Objekt daher sicher verwendet werden kann. Da diese Schwachstelle zu einer vollständigen Kompromittierung eines anfälligen Systems führen kann, gilt sie als eine der schädlichsten Angriffsarten. Erschwerend kommt hinzu, dass Deserialisierungsangriffe in den letzten Jahren zu einer der am weitesten verbreiteten Sicherheitslücke geworden sind.

Bei der Serialisierung wird ein Objekt im Speicher in einen Bytestrom umgewandelt, um es im Dateisystem zu speichern oder an eine andere Drittanwendung zu übertragen. Deserialisierung ist der umgekehrte Prozess, der den serialisierten Bytestrom zurück in ein Objekt im Speicher konvertiert. Alle wichtigen Programmiersprachen wie Java und .NET bieten Funktionen zur Durchführung nativer Serialisierung und Deserialisierung und die meisten sind anfällig. Deserialisierungsschwachstellen beschränken sich nicht nur auf Sprachdeserialisierungs-APIs, sondern umfassen auch Bibliotheken, die andere Serialisierungsformate wie XML und JSON verwenden.

Die Funktionsweise des Angriffs lässt sich in den folgenden Schritten zusammenfassen:

1.Eine anfällige Anwendung akzeptiert vom Benutzer bereitgestellte serialisierte Objekte.

2. Ein solcher Angriff wird normalerweise folgendermassen durchgeführt:

       a. Erstellen schädlicher Inhalte (Abfolge von Methodenaufrufen)

       b. Serialisierung in einen Bytestrom mithilfe der Serialisierungs-API

       c. Der Inhalt wird an die Anwendung gesendet.

3. Die Deserialisierung erfolgt, wenn die anfällige Anwendung den empfangenen Bytestrom liest und versucht, das Objekt zu erstellen.

4. Wenn ein bösartiges Objekt deserialisiert wird, wird die Gadget-Kette ausgeführt und das System gefährdet.

Empfohlene Sicherheitskontrollen

Gemäß den CERT- und MITRE-Empfehlungen müssen Anwendungen zum Schutz vor Deserialisierungsangriffen Folgendes tun:

• Minimieren Sie die Berechtigungen, bevor Sie aus einem privilegierten Kontext deserialisieren.
• Rufen Sie während der Deserialisierung keine potenziell gefährlichen Vorgänge auf.
  
  

Ausserdem erwähnt OWASP folgendes:

• Fehlerhafte oder unerwartete Daten könnten zum Missbrauch der Anwendungslogik verwendet werden.
• Schädliche Objekte können die Logik benutzerdefinierter Deserialisierer missbrauchen, um die Codeausführung zu beeinträchtigen.
  
  
  

So funktioniert der Schutz von Waratek

In Übereinstimmung mit den Empfehlungen und Beobachtungen von CERT, MITRE und OWASP schützt Waratek vor Deserialisierungsangriffen (CWE-502), indem es das Problem aus der Sicht der Rechteausweitung (CWE-250) und des API-Missbrauchs (CWE-227) angeht.

Die Aufgabe der Deserialisierung besteht darin, einen Bytestrom in ein Objekt im Speicher umzuwandeln. Die Laufzeitplattform (z. B. JVM) sollte diese Konvertierung zulassen, jedoch keine privilegierteren Vorgänge zulassen, die außerhalb des Bereichs der Objektdeserialisierungs-API liegen. Deserialisierungsangriffe basieren auf dem Aufruf von API-Methoden, die als privilegiert gelten, wie etwa java.lang.Runtime.exec(), um einen Angriff durchzuführen. Das Ziel des Deserialisierungsangriffs besteht darin, eine Gadget-Kette zu erstellen, die diese privilegierten Plattformfunktionen erreicht und ausführt und die Nutzlast auf dem System ausführt. Die Nutzlast könnte das Dateisystem, das Betriebssystem oder Systemressourcen missbrauchen.

Bei bestimmten Deserialisierungsvorgängen für Objekte ("Boundaries") erstellt der Waratek-Agent ein dynamisch eingeschränktes Mikrofach im Ausführungsthread und setzt die Deserialisierung des Objekts darin fort. Waratek deeskaliert die privilegierten Vorgänge im Mikrofach und überwacht die Ressourcennutzung. Wenn eine privilegierte Funktion innerhalb des Mikrokompartiments aufgerufen wird, wird die Ausführung beendet und die Nutzlast wird nicht ausgeführt. Die gleiche Logik gilt für Denial-of-Service-Angriffe: Wenn Ressourcen innerhalb des Mikrokompartiments missbraucht werden, wird der Deserialisierungsprozess beendet und der Angriff verhindert, bevor die Systemressourcen erschöpft sind. Das Mikrofach wird bei Abschluss der Deserialisierung eines nicht bösartigen Objekts zerstört und die Deeskalation der Berechtigungen wird dem ausführenden Thread widerrufen. Der Waratek-Schutz unterstützt gängige Deserialisierungs-APIs und -Formate, die in der gesamten Anwendung verwendet werden können. Darüber hinaus ist der Waratek-Agent in der Lage, vor Angriffen zu schützen, unabhängig von der nicht vertrauenswürdigen Quelle, z. B. wenn die serialisierten Daten von einem HTTP-Client (z. B. einer externen Webanforderung) oder von einem anderen internen System (z. B. einer Nachrichtenwarteschlange) stammen.

Das Mikrofach zur Privilegiendeeskalation bietet Schutz vor Deserialisierungsangriffen, ohne auf White- oder Blacklisting bekannter gefährlicher Klassen angewiesen zu sein, die von öffentlich zugänglichen Gadget-Ketten und Exploits verwendet werden. Dadurch können Benutzer neue Versionen ihrer Anwendungen bereitstellen, ohne die neue Funktionalität ihrer Anwendung profilieren und die White/Black-Listen entsprechend anpassen zu müssen. Waratek bietet Schutz vor Deserialisierungsangriffen über die Deserial-Deklaration in der ARMR-Marshal-Regel. Derzeit gibt es zwei Deserial-Regeln:

1.Die rce()-Regel, die vor Remote Code Execution (RCE)-Deserialisierungsangriffen schützt

2.Die dos()-Regel, die vor Denial-of-Service (DoS)-Deserialisierungsangriffen schützt

Durch die Aktivierung dieser Regeln wird das Laufzeit-Mikrokompartimentalisierungs-Framework zur Berechtigungsdeeskalation eingerichtet, das die Speicherzuweisung, die CPU-Auslastung, die Tiefe der zirkulären Abhängigkeiten, die Codeinjektion und die Berechtigungsausweitung während Deserialisierungsvorgängen überwacht und steuert.

Schutzfunktion

Wenn die Deserialisierungsregel im Schutzmodus aktiviert ist und ein Deserialisierungsangriff identifiziert wird, wird der böswillige Deserialisierungsvorgang beendet und gemäß der Deserialisierungs-API eine Java-Ausnahme an die Anwendung zurückgeworfen.

Anwendbarkeit der Regel

Die Deserialisierungsregeln können in allen Arten von Anwendungen sicher aktiviert werden, um vor Java- und XML-Deserialisierungsangriffen geschützt zu sein. Beachten Sie, dass Sicherheitslücken bei der JSON-Deserialisierung derzeit nicht unterstützt werden. Sicherheitslücken bei der XML-Deserialisierung können durch verschiedene XML-APIs und -Bibliotheken verursacht werden. Derzeit ist die einzige unterstützte XML-API java.beans.XMLDecoder

Waratek empfiehlt, die Regeln auch dann zu aktivieren, wenn die Anwendung keine expliziten Deserialisierungsvorgänge durchführt. Dies liegt daran, dass die Deserialisierung überall im Java-Stack erfolgen kann, z. B. in WebLogic, Struts, Spring, Log4j usw.

Die Deserial-Regeln erfordern insgesamt keine Konfiguration. In sehr seltenen Fällen kann die geschützte Anwendung möglicherweise Berechtigungen benötigen, die durch das Deserialisierungs-Mikrofach eingeschränkt sind. In solchen Fällen muss die Waratek-Eigenschaft „AllowDeserialPrivileges“ verwendet werden, um das Mikrofach so zu optimieren, dass die gegebene Berechtigung zugelassen wird.

Zum Beispiel:

com.waratek.AllowDeserialPrivileges=java.lang.SecurityManager.<init>(),java.lang.System.getenv()

Empfohlene Vorgehensweise

Aufgrund der Gefährlichkeit der Schwachstelle und weil Benutzer normalerweise nicht wissen, ob irgendwo in ihrem Java-Stack Komponenten vorhanden sind, empfiehlt Waratek, beide Deserialisierungsregeln zu aktivieren, um sowohl vor RCE- als auch DoS-Deserialisierungsangriffen geschützt zu sein.

Weiterführende Verweise