Desenvolvedores de plugins e temas: isso é o que você pode aprender com a vulnerabilidade de segurança do nosso SDK

Esta semana foi bastante intensa para nossa equipe, pois tivemos que lidar com uma vulnerabilidade de segurança. A segurança é prioridade para nós e esta é a primeira grande vulnerabilidade encontrada em nosso SDK em quatro anos. Infelizmente, como em qualquer software – os desenvolvedores também são humanos, então erros acontecem, seja você um desenvolvedor independente, uma loja temática de 20 pessoas ou o Google. O objetivo deste artigo é, em primeiro lugar, a transparência, mas também fornecer informações sobre como lidamos com o incidente e o que você pode aprender com ele.

Na segunda-feira, 25 de fevereiro de 2019, recebemos um e-mail de suporte de um desenvolvedor útil que encontrou um problema do GitHub no repositório WooCommerce. O problema foi criado por um representante de uma pequena empresa de hospedagem que notou atividades suspeitas em seus servidores. O representante incluiu os logs de atividades relevantes que indicavam dois ataques em potencial, e um deles tinha como alvo um plug-in que executava o Freemius SDK.

Como levamos a segurança muito a sério, imediatamente conduzimos uma investigação completa e confirmamos que a vulnerabilidade estava de fato em nosso SDK.

Devido à gravidade da vulnerabilidade, começamos a trabalhar em uma correção imediatamente. Depois de apenas algumas horas, lançamos uma tag corrigida e notificamos todos os desenvolvedores que estavam usando uma versão vulnerável do SDK para atualizar o SDK em todos os seus produtos o mais rápido possível. Também atualizamos o problema original do GitHub para informar a equipe do WooCommerce sobre ele (o problema do GH que removemos após algumas horas para reduzir a exposição).

Para mitigar a exposição e dar a todos um período de “graça” para atualizar para a versão corrigida, pedimos aos desenvolvedores duas coisas:
(a) Se esta atualização de segurança for incluída em seu registro de alterações, use apenas palavras genéricas como “Correção de segurança”.
(b) Mesmo depois de atualizar e liberar as versões corrigidas, não divulgue esse problema nos próximos 30 dias, dando tempo suficiente para que todos os nossos parceiros e seus usuários atualizem.

Apenas um dia depois, um site que cobre vulnerabilidades de plugins (intencionalmente não vinculando a eles ou mencionando seu nome) publicou um post sobre a vulnerabilidade, incluindo informações sobre como explorá-la ao nomear alguns dos plugins afetados. Isso nos pegou de surpresa, pois acabamos de notificar os desenvolvedores de plugins e temas sobre o problema menos de 24 horas antes. Eles não entraram em contato conosco nem seguiram a prática do mercado de Divulgação Responsável , que consideramos bastante irresponsável e antiética.

Entrei em contato com eles pedindo para cancelar temporariamente a publicação do relatório para reduzir a exposição e dar aos nossos desenvolvedores e seus usuários a chance de atualizar para as versões corrigidas antes que atraia atenção indesejada de mais hackers. Mas a pessoa com quem me comuniquei, que nunca expôs seu nome (eu perguntei a eles), tem sua própria ideologia justa e parece que o bom senso realmente não os atrai. Tentei explicar a situação problemática e o aumento do risco que eles estão expondo a muitos desenvolvedores e usuários, mas meus esforços caíram em ouvidos surdos e percebi que minha troca de e-mail era apenas uma perda de tempo.

Como a comunidade de nossos desenvolvedores estava atualizando seus plugins e temas para o SDK recém-corrigido que lançamos, descobrimos dois problemas:

1. Vários desenvolvedores não receberam nosso e-mail de alerta porque se registraram no Freemius com um endereço de e-mail que não estão verificando.
2. Nós intencionalmente não sinalizamos a tag do GitHub corrigida como uma versão oficial para evitar chamar a atenção. No entanto, descobrimos que os desenvolvedores que estavam usando o Composer para atualizar suas bibliotecas não estavam recebendo a atualização mais recente porque o packgist busca apenas lançamentos, a menos que especifique uma tag explicitamente.

Para superar esses problemas:

1. Como a vulnerabilidade já foi publicada publicamente, há dois dias sinalizamos a versão corrigida como uma versão oficial para que os desenvolvedores que dependem do packgist possam atualizar.
2. No início desta manhã, enviamos outro lote de mensagens para desenvolvedores que ainda não atualizaram o SDK em todos os seus produtos. Desta vez, enviamos as mensagens para seus canais oficiais de suporte para aumentar as chances de todos receberem os e-mails corretamente.

Embora quiséssemos adiar a publicação dessa vulnerabilidade por pelo menos duas semanas, recebemos uma nova consulta do WP Tavern solicitando nossa opinião antes de publicarem seu próprio artigo sobre o tópico, que foi a gota d'água que quebrou o teclado do desenvolvedor.

Os erros que cometemos e o que você pode aprender com eles

Olhando para o incidente, cometemos vários erros que poderíamos facilmente evitar e que tornariam a vida de todos muito mais fácil.

Entre no modo silencioso e alerte apenas aqueles que precisam saber

Como estávamos tão ansiosos para corrigir o problema o mais rápido possível, eu cometi um erro de “iniciante” que atraiu atenção indesejada muito cedo. Fui em frente e confirmei a correção no repositório GitHub que usamos para gerenciar o SDK. Não apenas o repositório é público, mas eu expliquei a correção e usei a palavra “segurança” nele.

A melhor abordagem foi criar uma versão privada/fechada do repositório, corrigir o problema de segurança e expô-lo apenas aos desenvolvedores relevantes em vez de torná-lo público. Isso não chamaria a atenção dos “caçadores de vulnerabilidades”.

Não desperdice sua energia com “trolls de segurança”

O segundo erro foi tentar interagir com a empresa por trás do site que publicou a vulnerabilidade. Foi um total desperdício de tempo e energia, e só desencadeou mais antagonismo que acabou com outro post sobre a vulnerabilidade. Eu diria que um bom indicador para decidir se vale a pena entrar em contato com um autor de um post que arrisque seus usuários de plugin ou tema, é se há um nome por trás do post/site/empresa. Se eles estão se escondendo atrás de proxies e agindo irracionalmente, a chance de você poder falar com eles é praticamente zero.

Portanto, este é o meu conselho – entre no modo silencioso e notifique apenas as pessoas que devem saber sobre a vulnerabilidade. No caso de um plugin/tema, são seus usuários. Essa também é uma boa oportunidade para enfatizar a importância de coletar os e-mails de seus usuários. Se você não tiver uma maneira de se comunicar em particular com seus usuários, não terá uma maneira eficaz de notificá-los de forma privada sobre problemas de segurança.

O Status Atual do Incidente

Mais de 60% dos desenvolvedores que estão usando nosso SDK já atualizaram para a versão corrigida. Além disso, o SDK vem com um mecanismo especial que permite que vários plugins ou temas suportados pelo Freemius instalados no mesmo site WordPress usem a versão mais recente do SDK se um dos produtos já estiver atualizado. Então isso é bom.

Dito isto, ainda existem muitos sites vulneráveis. É por isso que não mencionei nenhum detalhe técnico sobre a vulnerabilidade em si, nem os produtos afetados. Ainda queremos oferecer aos nossos desenvolvedores a chance de corrigir seus produtos e permitir que seus usuários atualizem para as versões seguras.

Como reduzir os riscos de segurança em seu plugin/tema WordPress?

Se você não tem experiência em segurança, pesquise no Google “práticas recomendadas de segurança na web” e encontrará vários artigos e práticas. Leia alguns deles para estar ciente dos riscos e erros potenciais modernos e típicos. Lembre-se disso durante os processos de desenvolvimento e teste. Outra boa prática é realizar auditorias de segurança periódicas contratando um pesquisador de segurança. Vai custar algumas centenas de dólares, mas se você estiver confiando em seu produto como sua principal fonte de renda, não tem problema.

Infelizmente, como no nosso caso, coisas ruins ainda podem acontecer. Embora tenhamos um histórico de segurança muito forte, realizamos revisões completas de código e trabalhamos com um pesquisador de segurança experiente da comunidade HackerOne, mas essa vulnerabilidade ainda escapou das rachaduras. 😔

Acho que uma das razões que aconteceu é porque o código vulnerável foi realmente adicionado para depurar casos de borda e não faz parte da funcionalidade principal do SDK. Portanto, se houver uma lição aqui, trate qualquer parte do código em seu produto da mesma maneira, seja parte da lógica de negócios real ou qualquer outra coisa.

Recapitular

Problemas de segurança são inevitáveis ​​no mundo do software. Quer gostemos ou não, um dia seu plugin ou tema terá um problema de segurança. O problema pode estar em seu código, uma biblioteca/framework que você está usando, um método principal do WordPress que fornece resultados inesperados e muitos outros cenários.

Quando isso acontecer (espero que não aconteça), não se estresse (nós definitivamente fizemos isso) e aja impulsivamente – só causará mais danos. Elabore um plano de recuperação metodológico, notifique as partes afetadas e esteja presente para ajudar seus usuários a proteger seus sites. Todo mundo sabe que problemas de segurança acontecem, o mais importante é como você lida com a situação.

Com isso dito, em nome de toda a equipe Freemius, sentimos muito pelo inconveniente e estaremos aqui durante todo o fim de semana para oferecer suporte, aconselhamento ou qualquer outra ajuda relacionada ao problema. E para nossos novos usuários, eu sei o quão importante é a primeira impressão, e isso definitivamente não é bom. Espero que você dê outra chance ao Freemius e, com o tempo, veja os incríveis recursos que oferecemos para seus plugins e temas do WordPress.