Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
PrestaShop-CVE-2018-19126 — PrestaShop (1.6.x <= 1.6.1.23 ou 1.7.x <= 1.7.4.4) Execução Remota de Código no Back Office (CVE-2018-19126) | Kitploit
Ferramentas/GitHubGitHub/farisv/prestashop-cve-2018-19126
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de PenetraçãoAprendizado e EducaçãoDesenvolvimento de Payloads
GitHubfarisv/prestashop-cve-2018-19126

PrestaShop-CVE-2018-19126

PrestaShop (1.6.x <= 1.6.1.23 ou 1.7.x <= 1.7.4.4) Execução Remota de Código no Back Office (CVE-2018-19126)

Ver Repositório
39106há 7 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Execução Remota de Código no Back Office do PrestaShop (CVE-2018-19126)

Este é o PoC para o CVE-2018-19126, que encadeia múltiplas vulnerabilidades no Back Office do PrestaShop para acionar a desserialização via phar e obter execução remota de código.

Pré-requisitos:

  • PrestaShop 1.6.x anterior à 1.6.1.23 ou 1.7.x anterior à 1.7.4.4.
  • Conta de Back Office (logístico, tradutor, vendedor, etc.).

Nota de versão do PrestaShop: http://build.prestashop.com/news/prestashop-1-7-4-4-1-6-1-23-maintenance-releases/

Link do pacote vulnerável: https://assets.prestashop2.com/en/system/files/ps_releases/prestashop_1.7.4.3.zip

AVISO

APENAS PARA FINS EDUCACIONAIS. NÃO USE ESTE SCRIPT PARA ATIVIDADES ILEGAIS. O AUTOR NÃO É RESPONSÁVEL POR QUALQUER USO INDEVIDO OU DANO.

Exemplo

Você precisa do php com a extensão curl e definir phar.readonly = Off no php.ini para executar o exploit.

# Download repository
wget https://github.com/farisv/PrestaShop-CVE-2018-19126/archive/master.zip -O PrestaShop-CVE-2018-19126.zip
unzip PrestaShop-CVE-2018-19126.zip
cd PrestaShop-CVE-2018-19126-master

# Run the exploit
# Usage: php exploit.php back-office-url email password func param
php exploit.php http://127.0.0.1/admin-dev/ [email protected] 54l35m4n123 system 'cat /etc/passwd'

Observe que o diretório de upload será renomeado e você não poderá enviar o arquivo phar malicioso novamente se o nome da pasta não for revertido. Você pode querer executar um reverse shell para obter RCE persistente ou incluir no seu payload o comando para renomear a pasta novamente (você precisa saber o caminho do diretório de upload).

Explicação

Podemos obter desserialização implícita com o wrapper phar por meio da função getimagesize() em [back-office-path]/filemanager/ajax_calls.php.

https://github.com/PrestaShop/PrestaShop/commit/4c6958f40cf7faa58207a203f3a5523cc8015148#diff-0f03d65f71cdd8eeb12913a97a6b8945

case 'image_size':
    if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
        die();
    }
    $pos = strpos($_POST['path'], $upload_dir);
    if ($pos !== false) {
        $info = getimagesize(substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)));
        echo json_encode($info);
    }

Precisamos encontrar uma forma de fazer getimagesize() ser chamada com a URL do wrapper phar como parâmetro, contornando determinadas verificações.

A primeira verificação, com realpath(), é bastante rígida.

if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
    die();
}

A variável $upload_dir vem do config.php, que é definida com $upload_dir = Context::getContext()->shop->getBaseURI().'img/cms/'; por padrão. Não podemos usar phar://[string] em $_POST['path'] porque realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) retornará false, já que o caminho não existe.

Existe outra vulnerabilidade (CVE-2018-19125) que permite ao usuário excluir ou renomear $upload_dir. Se o diretório $upload_dir não existir, realpath(_PS_ROOT_DIR_.$upload_dir) retornará false e podemos contornar essa verificação porque realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) também é false. Essa vulnerabilidade foi descoberta durante a revisão de código ao tentar encontrar uma forma de contornar a validação :).

Em resumo, o CVE-2018-19125 permite que o parâmetro path na chamada à ação delete_folder ou rename_folder em execute.php fique vazio, fazendo com que a aplicação exclua/renomeie o $upload_dir em vez disso.

A segunda verificação é simples: $_POST['path'] precisa conter $upload_dir.

$pos = strpos($_POST['path'], $upload_dir);
if ($pos !== false) {

Podemos simplesmente acrescentar /img/cms/ à URL phar após o caminho para o arquivo phar, porque mesmo que o diretório não exista dentro do arquivo phar, a desserialização ainda ocorre. A função substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)) apenas substituirá /img/cms/ pelo caminho absoluto ($current_path) dessa pasta (por exemplo, /var/www/html/img/cms/ se a aplicação estiver instalada em /var/www/html/).

Como podemos controlar a função getimagesize() para processar uma URL com wrapper phar, precisamos enviar o arquivo phar malicioso para o servidor. Por padrão, o FileManager do PrestaShop permite apenas 'jpg', 'jpeg', 'png', 'gif', 'bmp', 'tiff', 'svg', 'pdf', 'mov', 'mpeg', 'mp4', 'avi', 'mpg', 'wma', 'flv' e 'webm' como extensão. Podemos simplesmente criar o payload e salvá-lo com uma extensão válida. Podemos usar as cadeias de gadgets do Monolog do PHPGGC (https://github.com/ambionics/phpggc/blob/master/gadgetchains/Monolog/RCE/1/), já que é usado pelo PrestaShop.

Etapas finais da exploração:

  1. Crie o arquivo phar malicioso e salve-o com uma extensão válida (ex.: phar.pdf).
  2. Envie o phar.pdf para o FileManager.
  3. Acione a vulnerabilidade para renomear o diretório de upload para outro nome (ex.: renamed).
  4. Chame a ação image_size com phar://../../img/renamed/phar.pdf/img/cms/ como parâmetro path.
  5. O payload de desserialização em phar.pdf será executado.

O script exploit.php fará todas as etapas automaticamente.

Lembre-se de que o diretório de upload é renomeado na etapa 3 e você não poderá enviar o arquivo phar malicioso novamente se o nome da pasta não for revertido. Talvez você queira usar um reverse shell como payload ou incluir no payload o comando para renomear a pasta novamente (você precisa saber o caminho do diretório de upload).

Baixar ferramenta