lançamento do sistema de gerenciamento de conteúdo web . A versão é notável pelo término na implementação de verificação de atualizações e complementos por assinatura digital.
Até agora, na instalação de atualizações no WordPress, o principal fator de segurança era a confiança na infraestrutura e servidores do WordPress (após o download, era feita a verificação do hash sem verificação da fonte). Em caso de comprometimento dos servidores do projeto, os atacantes poderiam substituir a atualização e espalhar código malicioso entre os sites baseados em WordPress que utilizam o sistema de instalação automática de atualizações. Com base no modelo de entrega de confiança anteriormente aplicado, uma substituição do lado dos usuários permaneceria indetectável.
Considerando que, segundo o projeto w3techs, a plataforma WordPress é utilizada em 33.8% dos sites na rede, o incidente teria a magnitude de uma catástrofe. Nesse contexto, o risco de comprometimento da infraestrutura não era hipotético, mas bem real. Por exemplo, há alguns anos, um dos pesquisadores de segurança descobriu uma vulnerabilidade que permitia ao atacante executar seu código no lado do servidor api.wordpress.org.
No caso da utilização de assinaturas digitais, obter controle sobre o servidor de distribuição de atualizações não resultaria na comprometimento dos sistemas dos usuários, uma vez que para realizar o ataque também seria necessário obter a chave privada armazenada separadamente, com a qual as atualizações são assinadas.
A implementação da verificação da fonte das atualizações por assinatura digital foi dificultada pelo fato de que o suporte aos algoritmos criptográficos necessários foi introduzido na entrega padrão do PHP relativamente há pouco tempo. Os algoritmos criptográficos necessários surgiram graças à integração da biblioteca no núcleo do . Mas, como versão mínima suportada pelo WordPress, foi declarado A solução foi
o desenvolvimento e a inclusão no WordPress 5.2 de uma versão compacta do Libsodium — , onde um conjunto mínimo de algoritmos para verificação de assinaturas digitais foi implementado na linguagem PHP. A implementação deixa a desejar em termos de desempenho, mas resolve completamente o problema de compatibilidade, além de permitir que os desenvolvedores de plugins comecem a incorporar algoritmos criptográficos modernos.
Para a formação de assinaturas digitais, é utilizado o algoritmo , desenvolvido com a participação de Daniel Bernstein (Daniel J. Bernstein). A assinatura digital é gerada para o valor do hash SHA384, calculado a partir do conteúdo do arquivo de atualização. Ed25519 possui um nível de segurança superior ao ECDSA e DSA, demonstrando uma velocidade muito alta na verificação e criação de assinaturas. A resistência a ataques do Ed25519 é da ordem de 2^128 (em média, para atacar Ed25519, seriam necessárias 2^140 operações bit a bit), equivalente à resistência de algoritmos como NIST P-256 e RSA com tamanho de chave de 3000 bits ou um bloco de cifragem de 128 bits. Ed25519 também não é suscetível a problemas de colisões em hashes, não é sensível a ataques via análise de tempos de cache e a ataques de canal lateral.
Na versão do WordPress 5.2, a verificação da assinatura digital abrange apenas as principais atualizações da plataforma e não resulta, por padrão, no bloqueio da atualização, mas apenas informa ao usuário sobre a ocorrência de um problema. O bloqueio por padrão não foi ativado imediatamente devido à necessidade de uma verificação completa e contorno . No futuro, a verificação por assinatura digital também será planejada para a verificação da fonte de instalação de temas e plugins (os fabricantes poderão assinar lançamentos com sua chave).
Além do suporte a assinaturas digitais, o WordPress 5.2 traz as seguintes mudanças:
- Duas novas páginas foram adicionadas à seção 'Saúde do Site' para depuração de problemas típicos de configuração, além de uma forma pela qual os desenvolvedores podem deixar informações de depuração para os administradores do site;
- Foi adicionada a implementação da 'tela branca da morte', que aparece em caso de problemas fatais, ajudando o administrador a resolver problemas relacionados a plugins ou temas, acessando um modo especial de recuperação após falhas;
- Foi implementado um sistema de verificação de compatibilidade com plugins, que verifica automaticamente a possibilidade de uso do plugin na configuração atual, considerando a versão do PHP utilizada. Se uma versão mais nova do PHP for necessária para o funcionamento do plugin, o sistema bloqueará automaticamente a ativação deste plugin.
- Adicionada a suportação para ativação de módulos com código JavaScript usando e ;
- Adicionado um novo modelo privacy-policy.php, permitindo personalizar o conteúdo da página com os termos de conformidade de privacidade.
- Para os temas, foi adicionado um manipulador do hook wp_body_open, permitindo a inserção de código logo após a tag body.
- Os requisitos para a versão mínima do PHP foram elevados para 5.6.20, e agora é possível usar namespaces e funções anônimas em plugins e temas.
- Adicionar 13 novos ícones.
Além disso, pode-se mencionar uma vulnerabilidade crítica no plugin do WordPress (CVE-2019-11185). Essa vulnerabilidade permite a execução de código PHP arbitrário no servidor. O plugin é utilizado em mais de 27 mil sites para organizar chats interativos com visitantes, incluindo em sites de empresas como IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald’s (Live Chat é frequentemente utilizado para implementar janelas de chat pop-up em sites que oferecem a interação com um funcionário).
O problema se manifesta no código de upload de arquivos para o servidor e permite contornar a verificação de tipos de arquivos permitidos e fazer o upload de um script PHP no servidor, que pode ser executado diretamente através da web. Curiosamente, no ano passado, já havia sido identificada uma vulnerabilidade semelhante no Live Chat (CVE-2018-12426), que permitia o upload de código PHP disfarçado de imagem, especificando um tipo de conteúdo diferente no campo Content-type. Como parte da correção do problema, verificações adicionais foram adicionadas para listas brancas e tipos MIME. No entanto, essas verificações estavam implementadas de forma incorreta e eram facilmente contornáveis.
Em particular, o upload direto de arquivos com a extensão «.php» é proibido, mas a extensão «.phtml» não foi adicionada à lista negra, que em muitos servidores é associada ao interpretador PHP. A lista branca permite apenas o upload de imagens, mas pode ser contornada ao especificar uma dupla extensão, como «.gif.phtml». Para contornar a verificação do tipo MIME no início do arquivo, antes da abertura da tag com o código PHP, era suficiente inserir a string «GIF89a».
Fonte: opennet.ru
