Em 15 de julho de 2021, circulavam notícias sobre uma SQL Injection não autenticada no WooCommerce. As vulnerabilidades foram detectadas em 13 de julho e corrigidas nas versões 3.3.6 a 5.5.1 do WooCommerce e nas versões 2.5.16 a 5.5.1 dos Blocos do WooCommerce. Este artigo é uma breve análise das vulnerabilidades, do patch e, em seguida, um PoC para os bugs!
Análise de patch
No artigo do blog de segurança, podemos ver que as vulnerabilidades estão no WooCommerce e no plug-in de recurso Blocos do WooCommerce. Podemos ver duas correções aqui: https://plugins.trac.wordpress.org/changeset?old_path=/woocommerce&old=2564657&new_path=/woocommerce&new=2564657&sfp_email=&sfph_mail=#file22 em ambos ‘class-wc-webhook-store.php ‘em WooCommerce e’ ProductFiltering.php ‘em Blocos.
Ambas as correções são muito interessantes. Contudo, para rastrear um pouco mais, eu busquei a fonte das versões vulneráveis e configurei um site WordPress para ela (isso também será útil para o PoC, é claro). Eu sei da fonte, a parte vulnerável é através da API, então podemos visitar ‘woocommerce \ packages \ woocommerce-blocks \ src \ StoreApi \ RoutesController.php’ para obter uma boa lista das rotas de API.
Usando isso, podemos ver a rota ‘product-collection-data’ para a qual podemos navegar em ‘woocommerce \ packages \ woocommerce-blocks \ src \ StoreApi \ Routes \ ProductCollectionData.php’ que parece promissora!
Portanto, nosso caminho agora é / wp-json / wc / store / products / collection-data. A partir desse arquivo, podemos criar uma URL completa com bastante facilidade, pois isso detalha como usar essa rota específica. Voltando ao patch original, seguir ‘wc_sanitize_taxonomy_name’ nos leva à função da seguinte maneira:
Isso é realmente interessante, e depois de pesquisar no Google o uso de sanitize_title, obtemos:
Por padrão, converte caracteres de acento em caracteres ASCII e limita ainda mais a saída para caracteres alfanuméricos, sublinhado (_) e traço (-) por meio do filtro ‘sanitize_title’.
E este código também está usando urldecode, portanto, se codificarmos em URL uma carga útil 3 vezes para contornar isso, devemos ter um PoC totalmente funcional combinado com a URL criada anteriormente.
Explorando os bugs
Com as informações que descobrimos, agora podemos prosseguir e tentar explorar essas vulnerabilidades! Com base em todos os dados que adquirimos, nosso URL final seria o seguinte. A carga útil contém um comando SQL simples de suspensão:
Executar esta PoC em uma versão vulnerável do WooCommerce realmente funciona!
E por fim, caso exista alguma dúvida, entre em contato com um de nossos especialistas em WordPress.
