Os plugins mantidos devem ser suspensos do repositório do WordPress quando houver um problema de segurança?
Publicados: 2020-03-12Em 27 de fevereiro de 2020, às 21h34 (CET), recebemos um e-mail notificando que nosso plug-in WP Activity Log foi “ temporariamente retirado do diretório de plug-ins do WordPress.org devido a uma exploração” .
Enviamos uma correção na sexta-feira, 28 de fevereiro de 2020, às 16h08. Levamos apenas 16,5 horas para liberar a correção. Teríamos resolvido o problema muito antes se isso acontecesse durante nosso horário normal de trabalho (estamos sediados na Europa), porque temos um tempo de resposta de suporte muito bom (referência).
Nosso plugin foi restabelecido na segunda-feira, 2 de março de 2020, às 13h. Isso é 69 horas depois que enviamos a correção. É importante notar que a equipe demorou tanto para restabelecer o plugin por causa do fim de semana.
Por que estou escrevendo isso?
Gostaria de salientar que acredito que plugins não mantidos que tenham problemas de segurança devem ser suspensos do repositório do WordPress. Além disso, tenho enorme respeito pelo trabalho que os voluntários da equipe de revisão de plugins fazem e também assumo total responsabilidade pelo problema de segurança relatado.
No entanto, acredito que os problemas de segurança relatados em plugins mantidos podem ser tratados melhor. Por causa da maneira como eles são tratados no momento, a reputação do plugin sofre um grande impacto negativo e seus usuários e seus sites são colocados em risco. Portanto, no final deste post, destaco algumas melhorias possíveis que podem ajudar, e acho que elas devem ser consideradas. A ideia é sempre colocar menos usuários em risco e diminuir o impacto no plugin e nos desenvolvedores.
Neste post, também documento todos os detalhes do que aconteceu e explico a vulnerabilidade de caso de borda de baixa gravidade relatada em nosso plugin.
Qual é o procedimento para relatar um problema de segurança do plugin WordPress?
Das diretrizes oficiais no Manual do Plugin:
Todas as tentativas de entrar em contato diretamente com o desenvolvedor devem ser feitas antes de você nos reportar o plug-in (embora entendamos que isso pode ser difícil – verifique primeiro o código-fonte do plug-in, muitos desenvolvedores listam seus e-mails). Se você não puder contatá-los em particular, entre em contato conosco diretamente e nós o ajudaremos.
O que aconteceu no nosso caso?
Deixamos bem claro no plugin quem desenvolve o plugin. Basta olhar para a página do plugin no repositório e você terá uma ideia! Também facilitamos muito o contato conosco.
No entanto, ninguém nos relatou o problema de segurança antes do plugin ser temporariamente retirado do repositório de plugins. Então, alguém relatou o problema para a equipe de revisão de plugins do WordPress e eles retiraram temporariamente nosso plugin do repositório sem qualquer notificação prévia.
Antes de mergulharmos nos porquês e o que é, e o que é bom, ruim e o que pode ser melhorado, vamos dar uma olhada na vulnerabilidade do plugin e uma breve explicação de quem somos.
Qual era a vulnerabilidade do plugin?
Temos um assistente de instalação no WP Activity Log para ajudar os usuários a configurar o plugin. Uma das configurações do assistente permite que usuários não administradores leiam os logs de atividades.
No entanto, cometemos um erro; não verificamos se o usuário que executa o assistente foi autenticado. Portanto, usuários não autenticados podem executar o assistente e permitir que outro usuário ou função acesse as configurações do plug-in. No entanto, este é um problema de baixa gravidade do caso extremo.
Por que esse é um problema de segurança de caso de borda de baixa gravidade?
Os invasores só poderiam explorar isso se:
- o assistente de instalação nunca foi concluído pelo instalador,
- os invasores já tinham um usuário / tiveram acesso a um usuário no site,
- Os invasores só podem acessar as configurações do plug-in e o registro de atividades.
Ao explorar esses problemas de segurança, os invasores não obtêm acesso a outros privilégios no site do WordPress. Portanto, essa exploração não tem nenhum efeito negativo no comportamento e na funcionalidade do site em si.
Prova de conceito
O POC é muito simples. Visite esta página como usuário não autenticado:
http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access
Esta é a etapa do assistente que permite especificar quem pode ver os logs. Procure o nonce '_wpnonce' na fonte da página HTML, copie e insira-o no seguinte comando curl:
$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D= subscriber&save_step=Próximo'
Depois de fazer login como assinante, você terá acesso total às configurações do plug-in.
Por que achamos que este caso foi mal administrado?
No e-mail que nos foi enviado, havia o seguinte:
Não fechamos plugins de ânimo leve e, quando se trata de problemas de segurança, tentamos equilibrar o volume de usuários e o histórico dos desenvolvedores com a gravidade e o potencial de danos do relatório.
No entanto, acho que nosso plugin foi retirado muito cedo. Até aqui;
- Quando tivemos problemas no passado, sempre os resolvíamos em poucas horas. Fizemos o mesmo desta vez.
- Sempre respondemos a tempo quando a equipe de revisão de plugins entrava em contato.
- O problema de segurança afetou apenas nosso plugin (baixa gravidade) e foi um caso extremo.
- O problema de segurança não pôde ser explorado automaticamente.
- O único dano que o invasor poderia causar era alterar as configurações do plug-in, ler os logs de atividades ou eliminá-los.
O que outros desenvolvedores pensam de tais situações?
A maioria de nós já leu um artigo, tweet ou mensagem nas redes sociais sobre questões semelhantes. No entanto, eu queria descobrir por mim mesmo o que outras pessoas, especialmente desenvolvedores, pensam sobre isso. Eu acho que isso é importante porque pode haver algumas coisas que eu não estou vendo.
Para começar, enviei um e-mail para a pessoa que identificou o problema, agradecendo a divulgação responsável. Sua resposta foi:
“Fico feliz em ver que você corrigiu rapidamente o problema no plug-in. BTW, notei que o pessoal do wordpress.org fechou por alguns dias, isso foi um pouco duro e não foi realmente necessário.” - Jerome Bruandet.
Também fiz uma pequena enquete no grupo do Facebook Vendendo Produtos WordPress. Embora este grupo seja pequeno, a maioria de seus membros são desenvolvedores de plugins e temas. A partir da pesquisa, podemos ver que os desenvolvedores concordam unanimemente que, no caso de problemas de gravidade baixa a média, os desenvolvedores devem ser contatados e ter a chance de fornecer uma correção e não retirar o plug-in:
Como esses procedimentos podem ser melhorados?
Até onde sei, não há procedimentos documentados em vigor para quando alguém relata um problema de segurança em um plug-in. Se este for o caso, procedimentos como os abaixo podem ajudar os desenvolvedores e também colocar menos pessoas em risco.
Entre em contato com os desenvolvedores e concorde com um plano de ação antes de fechar o plug-in
A equipe de revisão de plugins pode tentar entrar em contato com os desenvolvedores e confirmar a vulnerabilidade antes de fechar o plugin. Os desenvolvedores devem responder com um plano de ação, incluindo uma data razoável para a correção.
Se necessário, a equipe de revisão de plugins pode definir um prazo. Por exemplo, os desenvolvedores devem ter entre 12 e 24 horas para corrigir o problema. No entanto, em alguns casos, eles podem precisar de mais tempo, dependendo do fuso horário em que estão, etc. Caso os desenvolvedores não respondam, o plugin deve ser retirado do repositório.
Determinar a gravidade e o tipo do problema de segurança
Isso pode estar aberto ao debate. No entanto, alguém com um pouco de experiência em segurança pode dizer facilmente se um problema de segurança relatado pode ser explorado automaticamente, se é um caso extremo ou não, e qual é o impacto da prova de conceito (POC) relatada.
Verifique se os desenvolvedores seguem o plano de ação
Deve haver uma espécie de verificação para confirmar que os desenvolvedores enviam a correção a tempo e se atêm a quaisquer outras tarefas incluídas no plano de ação.
Retirar plugins mantidos do repositório não ajuda
No caso de plugins mantidos, retirá-los do repositório faz mais mal do que bem. Por exemplo;
- Você torna público que o plugin tem um problema, provavelmente um problema de segurança. Isso gera muitos alarmes e destaca o plug-in. Isso também é como convidar invasores, dizendo a eles que algo no plug-in é possivelmente explorável.
- Ele expõe a base de usuários de plugins atual porque, de repente, seus sites se tornaram um alvo. A maioria dos usuários não tem ideia do que devem fazer, especialmente se a funcionalidade do plug-in for essencial para seu site e negócios.
- Você aumenta as chances de atrasar a correção. Isso geralmente é causado por falta de comunicação ou por causa de feriados e fins de semana.
Pode-se argumentar que ao retirar um plugin do repositório você está impedindo a propagação da infecção. No entanto, se o problema de segurança for de baixa gravidade, a exploração não pode ser automatizada e a divulgação é responsável, não há riscos envolvidos ou os riscos são extremamente baixos.
Aviso: Este não é um ataque
Gostaria de salientar que este não é um ataque contra a equipe de revisão de plugins do WordPress ou qualquer pessoa envolvida nesses processos. Eu honestamente respeito o trabalho deles e sei que o que eles fazem é feito de boa fé. No entanto, certamente há espaço para melhorias, como em qualquer outro sistema e processo.
Muitos provavelmente me dirão que, se eu quiser uma mudança, devo ser voluntário em vez de escrever este post.
Estou tentando participar há algum tempo; Conversei com várias pessoas em diferentes WordCamps para me envolver, e também tenho monitorado a página Make WordPress plugins para chamadas de voluntários. No entanto, nos últimos anos não houve vagas. Quando eles precisavam de ajuda, eles adicionavam novos membros apenas por convite.