lançamento de sistema de gerenciamento de conteúdo web . O lançamento é notável por sua conclusão na implementação verificar atualizações e adições usando uma assinatura digital.
Até agora, ao instalar atualizações no WordPress, o principal fator de segurança era a confiança na infraestrutura e nos servidores do WordPress (após o download, o hash era verificado sem verificar a fonte). Se os servidores do projeto fossem comprometidos, os invasores conseguiriam falsificar uma atualização e distribuir código malicioso entre sites baseados em WordPress que usam um sistema de instalação automática de atualizações. De acordo com o modelo de entrega de confiança utilizado anteriormente, tal substituição teria passado despercebida por parte dos usuários.
Levando em conta o fato de que do projeto w3techs, a plataforma WordPress é utilizada em 33.8% dos sites da rede, o incidente teria assumido a dimensão de um desastre. Ao mesmo tempo, o perigo de comprometimento das infra-estruturas não era hipotético, mas bastante real. Por exemplo, há vários anos, um dos investigadores de segurança uma vulnerabilidade que permitiu que um invasor executasse seu código no lado do servidor de api.wordpress.org.
No caso de assinaturas digitais, obter controle sobre o servidor de distribuição de atualizações não comprometerá os sistemas dos usuários, pois para realizar um ataque será necessário obter adicionalmente uma chave privada armazenada separadamente, com a qual as atualizações são assinadas.
A implementação da verificação da fonte de atualizações por meio de assinatura digital foi dificultada pelo fato de que o suporte para os algoritmos criptográficos necessários apareceu no pacote PHP padrão há relativamente pouco tempo. Os algoritmos criptográficos necessários surgiram graças à integração da biblioteca para a equipe principal . Mas como a versão mínima suportada do PHP no WordPress versão 5.2.4 (do WordPress 5.2 - 5.6.20). Habilitar o suporte para assinaturas digitais levaria a um aumento significativo nos requisitos para a versão mínima suportada do PHP ou à adição de uma dependência externa, o que os desenvolvedores não poderiam fazer dada a prevalência de versões PHP em sistemas de hospedagem.
A solução foi e a inclusão de uma versão compacta do Libsodium no WordPress 5.2 - , em que um conjunto mínimo de algoritmos para verificação de assinaturas digitais é implementado em PHP. A implementação deixa muito a desejar em termos de desempenho, mas resolve completamente o problema de compatibilidade e também permite que os desenvolvedores de plugins comecem a implementar algoritmos criptográficos modernos.
Um algoritmo é usado para gerar assinaturas digitais , desenvolvido com a participação de Daniel J. Bernstein. Uma assinatura digital é gerada para o valor hash SHA384 calculado a partir do conteúdo do arquivo de atualização. Ed25519 tem um nível de segurança mais alto que ECDSA e DSA e demonstra altíssima velocidade de verificação e criação de assinaturas. A resistência ao hacking para Ed25519 é de cerca de 2 ^ 128 (em média, um ataque ao Ed25519 exigirá operações de 2 ^ 140 bits), o que corresponde à resistência de algoritmos como NIST P-256 e RSA com tamanho de chave de 3000 bits ou cifra de bloco de 128 bits. Ed25519 também não é suscetível a problemas com colisões de hash e não é suscetível a ataques de temporização de cache ou ataques de canal lateral.
Na versão 5.2 do WordPress, a verificação de assinatura digital atualmente cobre apenas as principais atualizações da plataforma e não bloqueia a atualização por padrão, apenas informa o usuário sobre o problema. Foi decidido não habilitar o bloqueio padrão imediatamente devido à necessidade de uma verificação completa e desvio . No futuro, também está prevista a adição de verificação de assinatura digital para verificar a fonte de instalação de temas e plugins (os fabricantes poderão assinar lançamentos com sua chave).
Além do suporte para assinaturas digitais no WordPress 5.2, podem ser observadas as seguintes alterações:
- Duas novas páginas foram adicionadas à seção “Site Health” para depurar problemas comuns de configuração, e também foi fornecido um formulário através do qual os desenvolvedores podem deixar informações de depuração para os administradores do site;
- Adicionada implementação da “tela branca da morte”, exibida em caso de problemas fatais e ajudando o administrador a corrigir de forma independente problemas relacionados a plugins ou temas, alternando para um modo especial de recuperação de falhas;
- Foi implementado um sistema de verificação de compatibilidade com plugins, que verifica automaticamente a possibilidade de utilização do plugin na configuração atual, levando em consideração a versão do PHP utilizada. Se um plugin exigir uma versão mais recente do PHP para funcionar, o sistema bloqueará automaticamente a inclusão deste plugin;
- Adicionado suporte para habilitar módulos com código JavaScript usando и ;
- Adicionado um novo modelo privacy-policy.php que permite personalizar o conteúdo da página de política de privacidade;
- Para temas, um manipulador de gancho wp_body_open foi adicionado, permitindo inserir código imediatamente após a tag body;
- Os requisitos para a versão mínima do PHP foram aumentados para 5.6.20; plugins e temas agora têm a capacidade de usar namespaces e funções anônimas;
- Adicionados 13 novos ícones.
Além disso, você pode mencionar vulnerabilidade crítica no plugin WordPress (CVE-2019-11185). A vulnerabilidade permite que código PHP arbitrário seja executado no servidor. O plugin é utilizado em mais de 27 mil sites para organizar um bate-papo interativo com um visitante, inclusive em sites de empresas como IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald's (o Live Chat é frequentemente usado para implementar pop-ups irritantes bate-papos em sites da empresa com ofertas de bate-papo com o funcionário).
O problema se manifesta no código de upload de arquivos para o servidor e permite ignorar a verificação de tipos de arquivos válidos e fazer upload de um script PHP para o servidor e, em seguida, executá-lo diretamente pela web. Curiosamente, no ano passado já foi identificada uma vulnerabilidade semelhante no Live Chat (CVE-2018-12426), que permitia carregar código PHP sob o disfarce de uma imagem, especificando um tipo de conteúdo diferente no campo Content-type. Como parte da correção, foram adicionadas verificações adicionais para listas de permissões e tipo de conteúdo MIME. Acontece que essas verificações são implementadas incorretamente e podem ser facilmente contornadas.
Em particular, o upload direto de arquivos com extensão “.php” é proibido, mas a extensão “.phtml”, que está associada ao interpretador PHP em muitos servidores, não foi adicionada à lista negra. A lista de permissões permite apenas uploads de imagens, mas você pode ignorá-la especificando uma extensão dupla, por exemplo, “.gif.phtml”. Para contornar a verificação do tipo MIME no início do arquivo, antes de abrir a tag com código PHP, bastava especificar a linha “GIF89a”.
Fonte: opennet.ru