DEV Community

Cover image for Por que essa vulnerabilidade existe? CVE-2024-11205 (WPForms)
Bolha Sec
Bolha Sec

Posted on

1

Por que essa vulnerabilidade existe? CVE-2024-11205 (WPForms)

Nos últimos dias, percebi que a vulnerabilidade CVE-2024-11205 (CVSS 8.5) no plugin WPForms do Wordpress chamou bastante atenção. Principalmente por 3 motivos:

  • WPForms é um plugin muito usado, com mais de 6 milhões de instalações ativas (sites usando)
  • É uma vulnerabilidade de criticidade alta
  • É bizarramente simples de entender

O post original da Wordfence já fez um ótimo trabalho explicando a vulnerabilidade e suas consequências. Por isso, o meu objetivo aqui é outro: teorizar como uma vulnerabilidade tão bizarramente simples ficou no ar por mais de um 1 ano em um dos plugins mais utilizados do Wordpress.

Vulnerabilidade

Relembrando as informações do post original. O plugin usa as funções ajax_single_payment_refund() e ajax_single_payment_cancel() para manipular as ações de pagamento da Stripe. Porém, não há validação se o usuário logado tem permissão de executar tais ações ⚰️. Para completar, as funcionalidades estavam “protegidas” pelo método wpforms_is_admin_ajax que simplesmente não checa se o usuário é admin, como alguns poderiam pensar.

Vulnerabilidade original

Fix

Iniciando pela mitigação da vulnerabilidade, o fix oficial é atualizar para a versão 1.9.2.2. Nessa versão do código, foi adicionada uma validação de autorização nas duas funcionalidades, ajax_single_payment_refund e ajax_single_payment_cancel. Porém, o wpforms_is_admin_ajax foi mantido como está 🌚.

Fix

Quando surgiu a vulnerabilidade?

Primeira versão vulnerável é a WPForms 1.8.4 lançada em 28 de Novembro de 2023. A versão introduzia “New Stripe Payment Tools”, incluindo, entre outras coisas “Synchronized Stripe Dashboard” e “Logic for Recurring Payments”.

Lançamento 1.8.4

Como alterações, o update trouxe a adição de 15 novos arquivos, a deleção de 64 arquivos e a edição de 425 arquivos. Parece uma ótima release para alguém revisar manualmente ☠️.

Changes in Lançamento 1.8.4

Por que a vulnerabilidade existe?

Ferramentas de segurança automatizadas podem detectar?

Pra responder essa pergunta, testei o SAST Semgrep (que gosto bastante de usar) e o Gepeto (aka ChatGPT).

Semgrep

Rodei um semgrep . no projeto inteiro e ele não conseguiu detectar a vulnerabilidade 😢.

Semgrep 1

Semgrep 2

O resultado é o esperado. Oficialmente, vulnerabilidades de falha de autorização são consideradas como business logic vulnerabilities. O que significa que dificilmente são detectadas por ferramentas automatizadas.

O Common Weakness Enumeration CWE-862 Missing Authorization parece concordar.

CWE

Gepeto

Perguntei do ChatGPT se ele conseguia identificar algum problema no código passado. Enviei pra ele apenas os métodos ajax_single_payment_refund e wpforms_is_admin_ajax (porque não quero estourar meu ChatGPT free do dia 🤣).

Gepeto 1

E incrivelmente ele conseguiu identificar a vulnerabilidade e apontar a solução (que ficou bem parecida com o fix real 🤣), entre outras “possíveis vulnerabilidades” nesse código, como No Rate Limiting or Logging.

Gepeto 2

“ahh, mas vc rodou o SAST no projeto inteiro, enquanto direcionou a IA” a vida é assim msmo 🤣 🤷‍♂️

Por que a vulnerabilidade existe?

Como foi visto, ferramentas tradicionais de segurança dificilmente conseguem detectar vulnerabilidades de autorização.

De acordo com o CWE-862 Missing Authorization , essa vulnerabilidade pode ser detectada usando análise manual, como code review, pentest e threat modeling. E a efetividade é considerada “Moderate” apenas 🤣.

CWE2

Outros materiais que falam de vulnerabilidades de autorização reforçam que essa é uma classe de vulnerabilidades complicada de tratar e comum no mundo real, como OWASP Top 10 API Security 2019 e 2023 que tem como primeira e terceira posição vulnerabilidades de autorização.

Outro ponto é que o método sendo usado anteriormente como validação (wpforms_is_admin_ajax) tem um nome bem ruim, feito para confundir desenvolvedores e revisores de código, já que essa função não verifica se o usuário logado é admin.

Assim, a minha teoria é que essa vulnerabilidade existe porque 1) sem análise manual, é quase impossível detectá-la; 2) o método wpforms_is_admin_ajax confundiria muitos revisores analisando o código.

Espero trazer outras análises assim no futuro. Se você gostou, compartilhe o post com a titia e com a vovó. Dúvidas? Estou sempre no Bluesky, Threads e Twitter.

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

Top comments (0)

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay