Remotecodeausführung (RCE), erklärt: Was es ist und wie man es verhindert

Remotecodeausführung (RCE) ist eine Klasse von Softwaresicherheitslücken. RCE-Schwachstellen ermöglichen es einem böswilligen Akteur, beliebigen Code seiner Wahl auf einem Remote-Computer über LAN, WAN oder Internet auszuführen. RCE gehört zur breiteren Klasse der ACE-Schwachstellen (Arbitrary Code Execution). Da das Internet jedoch allgegenwärtig wird, nehmen die Auswirkungen von RCE-Schwachstellen rapide zu. So, RCEs sind jetzt wahrscheinlich die wichtigste Art von ACE-Schwachstelle.

Da dies der Fall ist, wollten wir uns die verschiedenen Arten von RCE-Schwachstellen und die möglichen Gegenmaßnahmen genauer ansehen.

RCE-Klassifizierung nach Herkunft

Die meisten, wenn nicht alle der bekannten RCE-Schwachstellen haben eine kleine Anzahl von Ursachen.

Dynamische Codeausführung

Dynamische Codeausführung ist tendenziell der häufigste Angriffsvektor, der zu RCE führt. Die meisten Programmiersprachen haben eine Möglichkeit, Code mit Code zu generieren und vor Ort auszuführen. Dies ist ein sehr leistungsfähiges Konzept, das hilft, viele komplexe Probleme zu lösen. Ein böswilliger Dritter kann es jedoch leicht missbrauchen, um RCE-Funktionen zu erhalten.

Häufig basiert der zur Laufzeit generierte Code auf Benutzereingaben. Meistens enthält der Code diese Eingabe in irgendeiner Form. Ein böswilliger Akteur, der erkennt, dass die dynamische Codegenerierung eine bestimmte Eingabe verwendet, könnte gültigen Code als Eingabe bereitstellen, um Ihre Anwendung anzugreifen. Wenn die Benutzereingaben nicht überprüft werden, wird dieser Code auf dem Zielcomputer ausgeführt.

Im Großen und Ganzen verursacht die dynamische Codeausführung zwei Hauptklassen von RCE-Schwachstellen: direkte und indirekte.

Direct

Bei direkter dynamischer Codeausführung ist sich der böswillige Akteur bewusst, dass seine Eingabe bei der Codegenerierung verwendet würde.

Indirekt

Ein indirekter Fall läuft wiederum auf die dynamische Codegenerierung einschließlich Benutzereingaben hinaus. Die Benutzereingaben durchlaufen jedoch eine oder mehrere Ebenen. Einige der Ebenen können diese Eingabe sogar transformieren, bevor sie mit der dynamischen Codegenerierung endet. Außerdem kann die dynamische Codegenerierung ein Nebeneffekt und nicht die primäre Verwendung der Eingabe sein. Daher ist es für den Benutzer, der die Eingabe bereitstellt, nicht wirklich offensichtlich, dass die Eingabe als Baustein in einem Codeausschnitt verwendet wird, der auf einem Remotecomputer ausgeführt werden soll.

Deserialisierung

Deserialisierung ist ein sehr gutes Beispiel für dieses Szenario. Anscheinend sollte bei der Deserialisierung keine dynamische Codegenerierung erfolgen. Dies ist tatsächlich der Fall, wenn das serialisierte Objekt nur Datenfelder primitiver Typen oder andere Objekte dieser Art enthält. Komplizierter wird es jedoch, wenn Methoden / Funktionen eines Objekts serialisiert werden. Die Deserialisierung umfasst dann normalerweise eine Form der dynamischen Codegenerierung.

Sie könnten denken, dass dynamische Sprachen der einzige Ort sind, an dem die Serialisierung von Funktionen sinnvoll ist. Das Problem wird dann von begrenztem Umfang sein. Aber es ist auch ein nützliches Szenario in statischen Sprachen. Es ist etwas schwieriger in einer statischen Sprache zu erreichen, aber bei weitem nicht unmöglich.

Häufig besteht die Implementierung aus durch Deserialisierung generierten Proxy-Objekten / -Funktionen. Das Generieren von Objekten / Funktionen zur Laufzeit ist ein Fall der dynamischen Codegenerierung. Wenn also die zu deserialisierenden Daten von einer Anforderung eines Remotecomputers stammen, kann ein böswilliger Akteur sie ändern. Es können sorgfältig gestaltete serialisierte Codeausschnitte eingefügt werden, die die dynamische Codegenerierung dazu verleiten, sie auszuführen, wenn sie als Teil der Deserialisierung aufgerufen werden.

Speichersicherheit

Eine weitere Ursache für RCE-Schwachstellen hat mit der Speichersicherheit zu tun. Speichersicherheit bedeutet, dass verhindert wird, dass Code auf Teile des Speichers zugreift, die er nicht initialisiert oder als Eingabe erhalten hat. Intuitiv können Sie erwarten, dass ein Mangel an Speichersicherheit zu unbefugtem Datenzugriff führt. Das Betriebssystem und die zugrunde liegende Hardware verwenden jedoch Speicher, um tatsächlich ausführbaren Code zu speichern. Metadaten zur Codeausführung werden ebenfalls im Speicher gespeichert. Der Zugriff auf diese Art von Speicher kann zu ACE und möglicherweise zu RCE führen. Was sind die Hauptgründe für Speichersicherheitsprobleme?

Softwaredesignfehler

Softwaredesignfehler sind eine Art Sicherheitsanfälligkeit im Speicher, bei der ein Designfehler in einer zugrunde liegenden Komponente vorliegt. Meistens wäre das ein Compiler, Interpreter oder eine virtuelle Maschine oder möglicherweise der Betriebssystemkern oder die Bibliotheken. Es gibt eine Reihe verschiedener Fehler, die zu dieser Klasse gehören. Wir werden uns genauer ansehen, was wohl am häufigsten vorkommt.

Pufferüberlauf oder Pufferüberlesen

Pufferüberlauf (auch als Pufferüberlesen bezeichnet) ist eine ziemlich einfache und bekannte Technik, um die Speichersicherheit zu verletzen. Es nutzt einen Konstruktionsfehler oder einen Fehler aus, um in die Speicherzellen zu schreiben, die dem tatsächlichen Ende eines Speicherpuffers folgen. Der Puffer selbst wird von einem legitimen Aufruf der öffentlichen API zurückgegeben. Der Puffer dient jedoch nur als Ausgangspunkt für die Berechnung der physischen Speicheradressen privater Feld- / Elementwerte eines Objekt- oder Programmzählers. Ihre relative Position zum Puffer ist entweder bekannt oder kann erraten werden. Die Untersuchung des Codes, falls verfügbar, oder das Debuggen der Programmausführung zur Laufzeit können einem böswilligen Akteur helfen, relative Positionen zu erhalten.

Ein Pufferüberlauf ermöglicht also das Ändern von Speicher, auf den von Vornherein zugegriffen werden sollte. Dieser Puffer befindet sich möglicherweise im Adressraum eines anderen Computers und kann durch Aufrufen einer Remote-API geändert werden. Dies ermöglicht den Zugriff auf den Speicher des Remote-Computers. Offensichtlich gibt es verschiedene Möglichkeiten, diese Art des Zugriffs bei der Instrumentierung eines RCE zu verwenden. Die allgemeine Annahme ist, dass, wenn ein Pufferüberlauf Verwundbarkeit besteht, dann ist ein RCE möglich. Daher sollten Codebesitzer Pufferüberläufe so schnell wie möglich beheben, lange bevor der eigentliche RCE-Angriff auftritt.

Scope

In den meisten Fällen zielt der Pufferüberlauf auf C / C ++ – Code ab, da diese Sprachen keine integrierten Puffergrößenprüfungen haben. Viele andere gängige Frameworks und Technologien verwenden C / C ++ – Bibliotheken tief unter der Oberfläche, was sie automatisch anfällig für diese Art von Angriff macht.

Knoten.js ist ein gutes Beispiel dafür, da JavaScript Runtime nicht nur auf C / C ++ basiert, sondern auch native C / C ++ – Add-Ons ermöglicht. Aus diesem Grund kann ein Angreifer die Anforderungen an einen Knoten sorgfältig erstellen.js Server Pufferüberlauf zu verursachen und damit den Systemspeicher auf dem betroffenen Rechner ändern, was die Ausführung von beliebigem Code.

Hardwaredesignfehler

Interessanterweise können Speichersicherheitsverletzungen auch aufgrund von Hardwaresicherheitsdesignfehlern auftreten. Solche Schwachstellen sind zwar seltener und schwerer zu finden, haben jedoch in der Regel extrem hohe Auswirkungen.

Ablenkung von RCE-Angriffen

Während das Ergebnis jedes RCE-Angriffs das gleiche ist, wenn ein Angreifer Code ausführt, sind die Angriffsvektoren sehr unterschiedlich. Das Blockieren aller erfordert erhebliche Anstrengungen. Darüber hinaus wächst der Aufwand mit dem Technologie-Stack. Alle in diesem Beitrag beschriebenen Angriffsvektoren sind technologieunabhängig. Alle Implementierungen sind jedoch technologiespezifisch, ebenso wie die Abwehrmechanismen.

Ein herkömmlicher zeitsparender Ansatz besteht also darin, den Netzwerkverkehr auf verdächtige Inhalte zu überwachen, anstatt jeden Endpunkt mit seiner spezifischen Technologie zu überwachen. Eine Web Application Firewall (WAF) führt diese Aufgabe normalerweise aus. Das spart zwar Zeit, hat aber auch seinen Preis — die WAF ist ein Engpass bei der Netzwerkleistung, und es fehlen alle Hintergrundinformationen, die am tatsächlichen Endpunkt oder auf Anwendungs- und Benutzerebene verfügbar sind. Daher könnte die WAF-Verkehrsanalyse niemals perfekt sein. Heuristiken sind ohne vollständige Daten unvermeidlich, sodass entweder nicht alle Bedrohungen auftreten oder Fehlalarme auftreten oder meistens beides.

Umzug in die App: Sqreen-Ansatz

Sqreen behebt diese WAF-Mängel, ohne die Entwicklungskosten für den Endbenutzer zu erhöhen, indem die Sichtbarkeit innerhalb der Anwendung verschoben wird und ein umfassenderer Schutz mit einem technologiespezifischen RASP und einer In-App-WAF bereitgestellt wird. RASP und WAF von Sqreen werden innerhalb der eigentlichen Webanwendung, API oder des Microservices ausgeführt, die Netzwerkverkehr empfangen. Es erfordert jedoch keine Codeänderung. Es verwendet Instrumentierungspunkte, die für jede Technologie spezifisch sind (z. B. JVM-API für Java, v8-API für Node.js, etc.), um Code vor der Ausführung zur Laufzeit zu ändern. Somit ist es in der Lage, System- und Netzwerkereignisse zu überwachen und zu ändern, während der vollständige Kontext von allem, was in der Anwendung passiert, erhalten bleibt.

Somit kann Sqreen erkennen, dass die App Komponenten mit bekannten Speichersicherheitsproblemen verwendet. Es kann auch die tatsächlichen Benutzereingaben erkennen, die es zu den dynamischen Codeausführungsereignissen machen. Dies ist natürlich ein überlegener Ansatz zum Erkennen und Verhindern von RCEs im Vergleich zu einer herkömmlichen WAF, die nur Zugriff auf den Netzwerkverkehr hat.

Einpacken

RCE ist eindeutig ein sehr starker Angriffsvektor. Aber zum Glück ist es auch möglich, sich gegen RCE-Angriffe zu verteidigen. Die obigen Informationen können wirklich beim Aufbau Ihrer Verteidigungsstrategie helfen. Wenn Sie an anderen Angriffsvektoren und Details interessiert sind, lesen Sie unsere vorherigen Beiträge zu SQL Injection, XXE und LFI.