Was ist Remote Code Execution (RCE)?

Remote Code Execution (RCE) einfach erklärt

„Remote“ heißt aus der Ferne, „Code Execution“ bedeutet das Ausführen von Programmcode. Bei einer RCE-Lücke bringt ein Angreifer einen Server dazu, Befehle auszuführen, die er über das Internet schickt – ohne vor Ort zu sein und häufig sogar ohne gültiges Benutzerkonto.

Stellen Sie sich eine Poststelle vor, die eingehende Briefe nicht nur sortiert, sondern jede Anweisung darin sofort umsetzt. Ein Brief mit dem Satz „Übergeben Sie dem Absender alle Schlüssel“ würde dann nicht abgelegt, sondern ausgeführt. Genau so verhält sich eine Anwendung mit RCE-Lücke: Sie verwechselt Daten, die sie nur verarbeiten soll, mit Befehlen.

RCE ist keine einzelne Angriffstechnik, sondern eine Gruppe von Schwachstellen mit demselben Ergebnis: Der Angreifer kann eigenen Code ausführen. Entsprechend hoch werden solche Lücken bewertet. Auf der CVSS-Skala von 0,0 bis 10,0 landen sie häufig im kritischen Bereich.

So funktioniert Remote Code Execution

Häufige Ursachen sind:

1. Befehlsinjektion: Eine Anwendung baut Eingaben ungeprüft in einen Systembefehl ein – etwa ein Diagnoseformular, das prüft, ob eine IP-Adresse erreichbar ist. Hängt der Angreifer an die Adresse einen eigenen Befehl an, führt der Server ihn mit aus.
2. Ungeprüfte Datei-Uploads: Statt eines Bildes lädt der Angreifer eine Skriptdatei hoch, die der Webserver anschließend als Programm startet. Das Ergebnis ist eine sogenannte Webshell – eine Fernsteuerung für den Server, bedienbar über den Browser.
3. Unsichere Deserialisierung: Programme verpacken Daten für die Übertragung und packen sie anschließend wieder aus. Nimmt eine Anwendung solche Pakete ungeprüft von außen an, kann ein Angreifer ein präpariertes Paket schicken, das beim Auspacken Code ausführt.
4. Template-Injection: Viele Webseiten entstehen aus Vorlagen, sogenannten Templates. Fließen Eingaben ungeprüft in eine Vorlage ein, kann der Angreifer Programmlogik einschleusen.
5. Speicherfehler: In Software, die in den Programmiersprachen C oder C++ geschrieben ist, kann etwa ein Pufferüberlauf – zu viele Daten für einen zu kleinen Speicherbereich – dazu führen, dass eingeschleuste Daten als Code ausgeführt werden.

Auch eine SQL-Injection kann je nach Datenbank bis zur Codeausführung reichen. Für öffentlich bekannte RCE-Lücken kursieren oft schnell fertige Exploits, also Angriffsprogramme. Ist eine Lücke dem Hersteller noch unbekannt, spricht man von einer Zero-Day-Schwachstelle.

Der eingeschleuste Code läuft meist mit den Rechten der betroffenen Anwendung. Läuft sie mit Administratorrechten, hat der Angreifer sofort die volle Kontrolle. Andernfalls folgt häufig eine Privilege Escalation, also eine Ausweitung der Rechte.

Ein Beispiel aus der Praxis

Ein erfundenes Szenario: Ein Onlineshop für Ersatzteile erlaubt seiner Kundschaft, Fotos defekter Teile hochzuladen. Die Anwendung prüft nur, ob der Dateiname auf „.jpg“ endet. Ein Angreifer könnte also eine Datei namens „teil.php.jpg“ hochladen, die in Wahrheit ein Skript enthält. Weil der Webserver falsch eingerichtet ist, würde er die Datei als Programm ausführen. Mit dieser Webshell könnte der Angreifer die Kundendatenbank auslesen und die Zahlungsseite manipulieren.

Aufgedeckt wird die Lücke in einem Penetrationstest, bevor Kriminelle sie finden. Der Tester lädt eine harmlose Testdatei hoch, die lediglich den Namen des Servers ausgibt – genug, um die Schwachstelle zu belegen. Das Entwicklungsteam prüft seitdem den tatsächlichen Dateiinhalt, speichert Uploads außerhalb des öffentlich erreichbaren Web-Verzeichnisses und vergibt zufällige Dateinamen.

Warum ist das für Unternehmen wichtig?

RCE gehört zu den kritischsten Befunden eines Penetrationstests. Mit der Kontrolle über einen Server kann ein Angreifer Daten stehlen, Schadsoftware wie Ransomware nachladen, Zahlungsseiten manipulieren oder den Server als Sprungbrett ins interne Netz nutzen.

Besonders gefährlich sind Lücken in Systemen, die aus dem Internet erreichbar und ohne Anmeldung ausnutzbar sind. Wird eine solche Schwachstelle öffentlich bekannt, durchsuchen Kriminelle das Internet oft automatisiert nach verwundbaren Systemen. Gelangen personenbezogene Daten in fremde Hände, drohen zudem Meldepflichten nach der DSGVO.

So schützen Sie sich

• Updates priorisieren: Spielen Sie Sicherheitsupdates für kritische Lücken sofort ein – vor allem bei Systemen, die aus dem Internet erreichbar sind.
• Eingaben nie ungeprüft verwenden: Eingaben gehören weder direkt in Systembefehle noch in Vorlagen oder Deserialisierungsfunktionen.
• Uploads streng prüfen: Kontrollieren Sie den tatsächlichen Dateiinhalt, speichern Sie Uploads außerhalb des Web-Verzeichnisses und verhindern Sie, dass sie ausgeführt werden.
• Minimale Rechte für Dienste: Lassen Sie Webanwendungen nicht mit Administratorrechten laufen.
• Systeme abschotten: Öffentlich erreichbare Server gehören in ein abgetrenntes Netzsegment, etwa eine DMZ.
• Zusätzliche Schutzschicht: Eine Web Application Firewall filtert viele typische Angriffe, ersetzt aber keine sichere Programmierung.
• Regelmäßig testen: Penetrationstests und Code Reviews finden RCE-Lücken, bevor Angreifer es tun.

Wie Rootsektor unterstützt

Im Penetrationstest für Webanwendungen & Webshops suchen wir gezielt nach Lücken, die zur Codeausführung führen – von Datei-Uploads über Injection-Schwachstellen bis zu unsicherer Deserialisierung. Den Nachweis führen wir kontrolliert und mit Rücksicht auf den laufenden Betrieb. Kritische Schwachstellen wie eine RCE melden wir schon während des Tests sofort an Ihre vereinbarte Ansprechperson. Behobene Schwachstellen prüfen wir im kostenlosen Retest nach.