Vulnerabilidades do WordPress explicadas - Site Urbano
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.
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.
Não autenticado – Uma vulnerabilidade WordPress não autenticada significa que qualquer um pode explorar a vulnerabilidade.
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.
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.
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 ( ( 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.
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.
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:
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:
element.innerHTML = " Tags and markup";
element.outerHTML = " Tags and markup";
document.write(" Tags and markup");
document.writeln(" Tags and markup");
Para fazer atualizações dinâmicas em HTML no DOM safe, o OWASP recomenda:
Codificação HTML, e então
JavaScript codificando todas as entradas não confiáveis, conforme mostrado nestes exemplos:
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.
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.
É possível que um invasor altere o parâmetro de URL para acessar um arquivo arbitrário no servidor.
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:
Prevenção de inclusão remota de arquivos
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.
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.
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.
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.
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 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:
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.
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.
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.
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.
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.
Scope Unchanged4  Roundup(Minimum((Impact+Exploitability),10))
Scope Changed Roundup(Minimum(1.08×(Impact+Exploitability),10))
Scope Changed 7.52 × (ISCBase - 0.029) - 3.25 × (ISCBase - 0.02)15
ISCBase = 1 - ((1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail))
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)