Analisi e sfruttamento della vulnerabilità di esecuzione remota di codice non autenticata in Magento (CVE-2016-4010)

---

0x00 Premessa

Il 17 maggio, il ricercatore di sicurezza Netanel Rubin ha reso pubblica una vulnerabilità di esecuzione remota di codice non autenticata in Magento (CVE-2016-4010). Questa vulnerabilità include in realtà diverse vulnerabilità minori e consente a un attaccante di eseguire codice PHP non autorizzato su un server Magento vulnerabile. Magento è una piattaforma e-commerce molto popolare, acquisita da eBay nel 2011. Alcuni marchi noti, come Samsung, Nikon, Lenovo e molte altre piccole attività di e-commerce la utilizzano. Si stima che Magento venga usato da 250.000 negozi online, con un volume di affari annuo di 60 miliardi di dollari.

0x01 Analisi

Condizioni per lo sfruttamento della vulnerabilità:

• Su Magento sono abilitate le RPC (REST o SOAP), e nella maggior parte dei casi sono abilitate di default
• Le versioni CE ed EE di Magento < 2.0.6

Le API web di Magento consentono due diversi tipi di RPC: REST RPC e SOAP API. Entrambi i metodi offrono le stesse funzionalità; l'unica differenza è che il primo usa JSON e richieste HTTP per trasmettere l'input, mentre il secondo usa XML.

Per esporre soltanto le API di alcuni moduli, Magento offre agli sviluppatori un metodo comodo: dichiarare in un file "webapi.xml" soltanto le API dei moduli che si desidera rendere accessibili. Il file webapi.xml contiene tutte le classi e i metodi delle Web API da esporre, e per ogni metodo specifica anche l'autorizzazione concreta richiesta. Queste autorizzazioni includono:

• anonymous – consente a chiunque di accedere al metodo
• self – consente l'accesso solo agli utenti registrati e ad autorizzazioni amministrative specifiche, ad esempio l'autorizzazione "Magento_Backend::admin" consente l'accesso solo agli amministratori che possono modificare la configurazione del server

Naturalmente, questo modo di consentire agli sviluppatori di usare il file webapi.xml per comunicare tra il frontend e il backend (Web API) del sistema apre di fatto una backdoor diretta al cuore dei moduli.

Inoltre, anche se disponiamo dell'autorizzazione "anonymous", abbiamo comunque bisogno di un modo per passare valori in modo dinamico. Qui si fa riferimento ai diversi oggetti che possono essere usati nel sistema. Ad esempio, la funzione API "CustomerRepositoryInterface::save()" ci consente di utilizzare un oggetto "CustomerInterface" nella variabile "$customer". Il codice prototipo è il seguente:

interface CustomerRepositoryInterface
{
/**
 * Create customer.
 */
public function save(\Magento\Customer\Api\Data\CustomerInterface $customer);
}

Allora, come possiamo creare oggetti usando l'interfaccia RPC? In realtà, la risposta sta nel modo in cui Magento configura il server SOAP.

Magento usa un server SOAP che include di default il "SoapServer" di PHP. Per essere configurato correttamente, "SoapServer" richiede un file WSDL, in cui vengono definiti tutti i metodi, i parametri e i tipi personalizzati usati nelle richieste RPC effettive. Magento genera file WSDL differenti per ogni modulo che supporta XMLRPC e imposta direttamente i valori provenienti dal file webapi.xml del modulo.

Quando una richiesta RPC viene analizzata dal server, il server usa i dati trovati nel file WSDL per determinare se la richiesta è valida, controllando metodi, parametri e tipi. Se la richiesta è valida, l'oggetto richiesta analizzato viene passato a Magento per un'ulteriore elaborazione. Un punto molto importante è che "SoapServer" non interagisce in alcun modo con Magento: tutte le informazioni su metodi e parametri dei moduli provengono dal file WSDL. In questa fase, la richiesta inviata è ancora composta da array nidificati; nessun oggetto viene creato durante l'analisi di SoapServer. Per creare gli oggetti necessari, Magento continua a elaborare l'input da solo.

Per estrarre i nomi dei parametri e i tipi di dati, Magento recupera il prototipo dal metodo richiesto (come nel codice precedente). Per alcuni tipi di dati di base, come stringhe, array, booleani, ecc., il sistema associa l'input al tipo corrispondente. Ma per i tipi di oggetti, la soluzione è più complicata.

Se il tipo di dato di un parametro è l'istanza di una classe, Magento tenterà di creare un'istanza usando l'input fornito. Ricordiamo che in questo momento l'input è soltanto un dizionario, le cui chiavi sono nomi di proprietà e i valori sono valori di proprietà.

In primo luogo, Magento creerà una nuova istanza della classe richiesta. Poi cercherà di popolarla usando il seguente metodo:

1. Ottiene il nome della proprietà (dalle chiavi del dizionario di input)
2. Cerca un metodo pubblico chiamato "Set[Nome]", dove [Nome] è il nome della proprietà
3. Se esiste un metodo del genere, lo esegue usando il valore della proprietà come argomento
4. Se non esiste, ignora la proprietà e continua con quella successiva

Magento applicherà questo metodo a ogni proprietà che l'utente sta cercando di impostare. Quando tutte le proprietà sono state controllate, Magento considera l'istanza completata e passa al parametro successivo. Quando tutti i parametri sono stati elaborati, Magento esegue infine il metodo API.

In sintesi, Magento ti consente di creare un oggetto, impostarne le proprietà pubbliche e infine eseguire, tramite le sue RPC, qualsiasi metodo che inizi con "Set". È proprio questo comportamento a causare la vulnerabilità di Magento.

Dalla ricerca è emerso che alcune chiamate API consentono di impostare determinate informazioni nel carrello degli acquisti; tali informazioni possono essere il nostro indirizzo postale, i prodotti e persino la nostra modalità di pagamento.

Quando Magento imposta le nostre informazioni nell'istanza del carrello, usa il metodo "save" dell'istanza per memorizzare i nuovi dati nel database.

Vediamo come funziona il metodo "save"!

/**
* Save object data
*/
public function save(\Magento\Framework\Model\AbstractModel $object)
{
...
// If the object is valid and can be saved
if ($object->isSaveAllowed()) {
    // Serialize whatever fields need serializing
    $this->_serializeFields($object);
    ...
    // If the object already exists in the DB, update it
    if ($this->isObjectNotNew($object)) {
        $this->updateObject($object);
    // Otherwise, create a new record
    } else {
        $this->saveNewObject($object);
    }
     
    // Unserialize the fields we serialized
    $this->unserializeFields($object);
}
...
return $this;
}
// AbstractDb::save()

Magento verifica che l'oggetto sia valido, quindi serializza tutte le parti che devono essere serializzate e le memorizza nel database; infine deserializza le parti precedentemente serializzate.

Sembra semplice, vero? In realtà non lo è. Continuiamo a vedere come Magento determina quali parti devono essere serializzate.

/**
* Serialize serializable fields of the object
*/
protected function _serializeFields(\Magento\Framework\Model\AbstractModel $object)
{
// Loops through the '_serializableFields' property
// (containing hardcoded fields that should be serialized)
foreach ($this->_serializableFields as $field => $parameters) {
    // Get the field's value
    $value = $object->getData($field);
     
    // If it's an array or an object, serialize it
    if (is_array($value) || is_object($value)) {
        $object->setData($field, serialize($value));
    }
}
}
// AbstractDb::_serializeFields()

Come possiamo vedere, solo le parti presenti nel dizionario hardcoded "_serializableFields" possono essere serializzate. Soprattutto, questo metodo serializza solo dopo essersi assicurato che il valore del campo sia un array o un oggetto.