Alertas para Injeção de SQL em bbPress

Durante auditorias regulares do nosso nossos especialistas em segurança, descobriu uma vulnerabilidade de Injeção de SQL que afeta o bbPress. Se as condições adequadas forem atendidas, esta vulnerabilidade é muito fácil de ser usada por qualquer visitante no site da vítima.

Como os detalhes sobre esta vulnerabilidade foram tornados públicos hoje em um relatório do Hackerone e atualizando para a versão mais recente do WordPress corrige a causa principal do problema, optamos por divulgar esse bug e tornar seus detalhes públicos.

Linha do Tempo da Divulgação da Vulnerabilidade

• 20 de março – Relato inicial à equipe do bbPress.
• 20 de março – Resposta inicial do bbPress, correção deveria ser lançada nas próximas 40 horas.
• 05 de abril – Sucuri faz o primeiro pedido de atualização.
• 18 de abril – Resposta do bbPress, correção planejada para as branches 2.5 e futuras 2.6.
• 25 de abril – Sucuri pede uma estimativa de tempo para o lançamento das correções.
• 09 de junho – Sucuri pede novamente que as atualizações sejam feitas.
• 09 de junho – Dois consertos (patches) são disponibilizados no próprio Trac server do bbPress (para branches 2.5 e branches 2.6 futuras), não no repositório oficial do WordPress.org.
• 11 de julho – Sucuri anuncia que a divulgação é iminente, mas que o patch ainda não está no repositório oficial do WordPress.
• 20 de julho – Sucuri descobre que o patch não conserta o problema, impedindo seus planos de divulgação da vulnerabilidade. Enviamos um patch para ajudar.
• 21 de julho – bbPress confirma o problema e prometem responder o mais rápido possível.
• 31 de outubro – WordPress 4.8.3 é lançado, resolvendo o problema.
• 13 de novembro – Este mesmo bug no bbPress é divulgado em um relatório do Hackerone.

Seu Site Corre Risco?

Este bug pode ser explorado quando a opção Postagem anônima está habilitada em um site WordPress do bbPress – algo que um invasor pode notar facilmente.
Se você não tem certeza se essa opção está habilitada ou não para o seu site, consulte a página Configuração do plugin.

Quando esta opção é ativada, o bug de segurança pode ser explorado por hackers ao criar/responder a posts como usuários anônimos. Por causa da forma como os ataques de injeção de SQL funcionam, existem várias maneiras pelas quais um invasor pode causar danos – os exemplos incluem vazamentos de senhas e outras chaves criptográficas.

Detalhes Técnicos

O vetor de ataque usado aqui é o mesmo que descrevemos em nossa publicação anterior sobre como encontramos uma Injeção de SQL no Nextgen Gallery, o causada por uso indevido da classe de abstração do banco de dados do WordPress (wp-db).

Em suma, era possível que o input do usuário fosse inserido em uma instrução preparada usando o método $wpdb’s prepare. Como este método tira proveito das tags de formato sprintf e ainda faz um processamento adicional, mesmo inputs que tenham sido sanitizados contra injeções de SQL podem ser usados para inserir statements SQL arbitrários.

O culpado está localizado na função bbp_check_for_duplicate, no bbpress/includes/common/functions.php.

Como você pode ver no fragmento acima, a função get_meta_sql foi projetada para gerar parte da cláusula WHERE que está concatenada com a query SQL preparada mais tarde no código e faz isso usando alguns parâmetros que controlamos, ou seja, o array  $r[‘anonymous_data’] . Claro, o resultado gerado conterá nosso input, sanitizado para evitar ataques tradicionais de injeção de SQL.

Agora, vamos analisar melhor esse último trecho. Ele gera uma cláusula SQL WHERE e anexa-a diretamente ao primeiro argumento do $wpdb->prepare() (a query SQL). Como alguns de vocês podem se lembrar do nosso último post no blog sobre o mesmo vetor de ataque, isso não é uma coisa boa. Mesmo que a query SQL tenha sido sanitizada contra ataques de injeção tradicionais, não faz nada para evitar que um invasor insira rogue especificadores de formato sprintf maliciosos, que, como você pode recordar, nos permitem inserir statements SQL arbitrários na query.

Com esses detalhes em mente, é bastante fácil ver de onde a entrada do usuário é proveniente: é originária dos formulários de Resposta/Nova Postagem Anônimos (Anonymous Reply/New Post).

Como resultado, o envio deste payload resultará na execução da seguinte query no lado do servidor:

SELECT ID FROM wp_posts  INNER JOIN wp_postmeta ON (
 wp_posts.ID = wp_postmeta.post_id ) WHERE post_type = 'reply' AND
 post_status != 'trash' AND post_author = 0 AND post_content = 'or 1=1))
 #'  AND (
 ( wp_postmeta.meta_key = '_bbp_anonymous_email' AND wp_postmeta.meta_value = 'or 1=1)) #'or 1=1)) #'@test.com' )
 ) AND post_parent = 11 LIMIT 1

E pode ser explorado como uma injeção de SQL cega clássica.

Atualize o Mais Rápido Possível!

Se você estiver usando este plugin com a configuração acima mencionada e se seu site não foi atualizado automaticamente para 4.8.3, faça a atualização o mais rápido possível!
Se você não pode fazer essa atualização, recomendamos o uso do Firewall WAF da HostCuritiba ou de uma tecnologia equivalente para consertar essa vulnerabilidade virtualmente.