Análise e Exploração da Vulnerabilidade de Execução Remota de Código Não Autenticada no Magento (CVE-2016-4010)

---

0x00 Prefácio

Em 17 de maio, o pesquisador de segurança Netanel Rubin divulgou uma vulnerabilidade de execução remota de código não autenticada no Magento (CVE-2016-4010). Essa vulnerabilidade na verdade engloba várias pequenas falhas e permite que um atacante execute código PHP não autenticado em servidores Magento vulneráveis. Magento é uma plataforma de e-commerce muito popular, adquirida pela eBay em 2011. Empresas conhecidas, como Samsung, Nikon, Lenovo e muitas outras pequenas lojas virtuais, a utilizam. Segundo informações, o Magento é usado por 250.000 lojas online, movimentando anualmente um montante de 60 bilhões de dólares.

0x01 Análise

Condições de exploração da vulnerabilidade:

• O Magento tem RPCs ativados (REST ou SOAP), e a maioria vem ativada por padrão.
• Versões CE & EE do Magento < 2.0.6

A API web do Magento permite dois tipos diferentes de RPCs: REST RPC e SOAP API. Ambos oferecem as mesmas funcionalidades, a única diferença é que o primeiro usa JSON e requisições HTTP para transmitir entradas, enquanto o segundo usa XML.

Para expor apenas as APIs de alguns módulos, o Magento oferece aos desenvolvedores um método conveniente: declarar no arquivo "webapi.xml" apenas as APIs dos módulos que desejam tornar acessíveis. O arquivo webapi.xml contém todas as classes e métodos das Web APIs que precisam ser expostos, e cada método também especifica a permissão específica necessária. Essas permissões incluem:

• anonymous – permite acesso de qualquer pessoa ao método
• self – permite acesso apenas a usuários registrados e permissões específicas de administrador, por exemplo: a permissão "Magento_Backend::admin" permite acesso apenas a administradores que podem editar configurações do servidor

Claro, essa forma de permitir que desenvolvedores usem o arquivo webapi.xml para comunicação entre o frontend e o backend (Web API) do sistema também abre uma porta direta para o núcleo do módulo.

Além disso, mesmo que tenhamos permissão "anonymous", ainda precisamos de uma maneira de passar valores dinamicamente. Refere-se aqui aos diferentes objetos que podem ser usados no sistema. Por exemplo: a função da API CustomerRepositoryInterface::save() permite usar um objeto CustomerInterface na variável $customer. O protótipo do código é o seguinte:

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

Então, como usar a interface RPC para criar objetos? Na verdade, a resposta está em como o Magento configura o servidor SOAP.

O Magento usa o servidor SOAP padrão do PHP, o "SoapServer". Para configurá-lo corretamente, o "SoapServer" precisa de um arquivo WSDL que defina todos os métodos, parâmetros e tipos personalizados usados nas requisições RPC reais. O Magento gera diferentes arquivos WSDL para cada módulo que suporta funcionalidades XMLRPC, e define diretamente os valores do arquivo webapi.xml do módulo.

Quando uma requisição RPC é analisada pelo servidor, o servidor usa os dados encontrados no arquivo WSDL para determinar se a requisição é válida, verificando o método, parâmetros e tipos. Se for válida, o objeto de requisição analisado é passado para o Magento para processamento adicional. Um ponto muito importante é que o "SoapServer" não interage com o Magento de forma alguma; todas as informações sobre os métodos e parâmetros do módulo vêm do arquivo WSDL. Neste ponto, a requisição enviada ainda é composta por arrays aninhados; nenhum objeto é criado durante a fase de análise do SoapServer. Para criar os objetos necessários, o Magento continua processando a entrada por conta própria.

Para extrair os nomes dos parâmetros e tipos de dados, o Magento obtém o protótipo do método da requisição (veja o código anterior). Para tipos de dados básicos, como string, array, booleano, etc., o sistema mapeia a entrada para o tipo correspondente. Mas para tipos de objeto, a solução é mais complicada.

Se o tipo de dado de um parâmetro for uma instância de uma classe, o Magento tentará construir a instância usando a entrada fornecida. Lembre-se: a entrada neste momento é apenas um dicionário, cujas chaves são nomes de propriedades e os valores são valores de propriedades.

Primeiro, o Magento criará uma nova instância da classe necessária. Em seguida, tentará preenchê-la usando o seguinte método:

1. Obter o nome da propriedade (da chave do dicionário de entrada)
2. Procurar por um método público chamado "Set[Nome]", onde [Nome] é o nome da propriedade
3. Se existir tal método, executá-lo usando o valor da propriedade como argumento
4. Se não existir tal método, ignorar a propriedade e continuar para a próxima

O Magento processará dessa forma cada propriedade que o usuário está tentando definir. Quando todas as propriedades forem verificadas, o Magento considera a instância completamente configurada e processa o próximo parâmetro. Quando todos os parâmetros forem tratados assim, o Magento executará finalmente o método da API.

Em resumo, o Magento permite que você crie um objeto, defina suas propriedades públicas e, finalmente, execute qualquer método que comece com "Set" através de sua RPC. E é exatamente esse comportamento que leva à vulnerabilidade no Magento.

A pesquisa descobriu que algumas chamadas de API permitem definir informações específicas no carrinho de compras, como nosso endereço de entrega, produtos e até mesmo nossa forma de pagamento.

Quando o Magento define nossas informações na instância do carrinho, ele usa o método "save" da instância para armazenar os novos dados no banco de dados.

Vamos ver como o método "save" funciona!

/**
* 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()

O Magento garante que nosso objeto seja válido, serializa todas as partes que devem ser serializadas, armazena no banco de dados e, finalmente, desserializa as partes serializadas anteriormente.

Parece simples, certo? Na verdade não. Vamos continuar vendo como o Magento determina quais partes devem ser serializadas.

/**
* 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()

Como vemos, apenas os campos que aparecem no dicionário codificado "_serializableFields" podem ser serializados. O mais importante é que este método só prossegue com a serialização se o valor do campo for um array ou um objeto.

Agora, vejamos como o Magento determina quais partes devem ser desserializadas.