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 em WordPress O principal fator para garantir a segurança foi a confiança na infraestrutura e nos servidores. WordPress (Após o download, o hash foi verificado sem que a fonte fosse verificada). Se os servidores do projeto fossem comprometidos, os atacantes teriam a oportunidade de substituir a atualização e distribuir código malicioso entre sites baseados em WordPress, utilizando o sistema de instalação automática de atualizações. No modelo de entrega confiável usado anteriormente, essa substituição teria passado despercebida pelo usuário.
Levando em conta o fato de que projeto de plataforma w3techs WordPress Utilizado por 33.8% dos sites na Internet, um incidente teria sido catastrófico. Além disso, o perigo de comprometimento da infraestrutura não era hipotético, mas bastante real. Por exemplo, há alguns anos, um pesquisador 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, no mínimo, com suporte em WordPress Versões do PHP Versão 5.2.4 (a partir de WordPress 5.2 - 5.6.20). Habilitar o suporte para assinaturas digitais teria aumentado significativamente os requisitos para a versão mínima suportada do PHP ou adicionado uma dependência externa, o que os desenvolvedores não podiam fazer devido à prevalência de versões do PHP nos sistemas de hospedagem.
A solução foi e inclusão na composição WordPress 5.2 variante compacta do Libsodium - , 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.
Em questão WordPress 5.2 A verificação de assinatura digital atualmente abrange 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. Decidiu-se não habilitar o bloqueio por padrão devido à necessidade de uma verificação completa e de uma forma de contornar o bloqueio. . 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 de oferecer suporte a assinaturas digitais, WordPress Em 5.2, podem ser observadas as seguintes mudanças:
- 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 em WordPress-plugin (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
