O WordPress é sem dúvida o CMS (Content Management System) mais popular na Internet, ocupando uma fatia de nada mais que 65% (para se ter uma ideia o 2º colocado tem uma participação de apenas 6,6%).

O Nuclei funciona por meio de templates que instruem a ferramenta quais ações realizar sobre o alvo. Esta ações podem ser desde uma simples identificação de um software até a exploração de uma vulnerabilidade em várias etapas.

Um dos templates disponíveis no Nuclei fazia a identificação dos plugins presentes em uma instalação do WordPress por força-bruta, passando uma relação de aproximadamente 90.000 palavras. Essa abordagem não me pareceia muito eficiente e, dependendo do número de URLs testadas, o processo se demonstrava bastante oneroso em termos de recursos de processamento além de inundar o alvo com requisições desnecessárias.

Pensando nisso, desenvolvi um script em Python que acessa o site do WordPress e faz uma varredura pelos 200 plugins mais populares e, em seguida, acessa o respectivo repositório SVN do plugin para recuperar o número da última versão disponível e, finalmente, gera automaticamente um template que, além de identificar o plugin, verifica se está na versão mais recente, oferecendo uma informação bastante útil sobre a possível presença de componentes desatualizados.

Esta é a aparência do template gerado, neste caso, para o plugin contact-form-7.

id: wordpress-contact-form-7

info:
  name: Contact Form 7 Detection
  author: ricardomaia
  severity: info
  reference:
    - https://wordpress.org/plugins/contact-form-7/
  metadata:
    plugin_namespace: contact-form-7
    wpscan: https://wpscan.com/plugin/contact-form-7
  tags: tech,wordpress,wp-plugin,top-100,top-200

requests:
  - method: GET
    redirects: true
    max-redirects: 2
    path:
      - "{{BaseURL}}/wp-content/plugins/contact-form-7/readme.txt"

    payloads:
      last_version: helpers/wordpress/plugins/contact-form-7.txt

    extractors:
      - type: regex
        part: body
        internal: true
        name: internal_detected_version
        group: 1
        regex:
          - '(?i)Stable.tag:\s?([\w.]+)'

      - type: regex
        part: body
        name: detected_version
        group: 1
        regex:
          - '(?i)Stable.tag:\s?([\w.]+)'

    matchers-condition: or
    matchers:
      - type: dsl
        name: "outdated_version"
        dsl:
          - compare_versions(internal_detected_version, concat("< ", last_version))

      - type: regex
        part: body
        regex:
          - '(?i)Stable.tag:\s?([\w.]+)'

Como se pode notar o template utiliza como payload o conteúdo de um arquivo que contêm o número da versão do componente para então compará-lo à versão detectada no arquivo readme.txt.

O template quando executado gera uma saída como na figura a seguir:

Observe a diferença entre as variáveis outdate_version e detected_version que são exibidas conforme o caso.

Para manter os templates atualizados faço uso do GitHub Actions para executar o script diariamente.

Na data de hoje (23/12/2022) meu PR (Pull Request) foi aceito e incluído no repositório do projeto. 🎉🎉🎉

Com estas limitações todas as funcionalidades como busca, dashboards, configurações e logs ficam acessíveis para qualquer pessoa que acesse a console web. Então para prevenir esse problema você poderia usar um túnel SSH para conectar o seu PC diretamente ao servidor que estaria configurado para aceitar apenas conexões locais.

Aqui parto do pressuposto que você já possui o Splunk instalado e tem conhecimentos básicos sobre comandos de terminal no Linux.

Edite o arquivo web.conf localizado em $SPLUNK_HOME/etc/system/default/ modificando a respectiva linha como se segue:

server.socket_host = localhost

Salve as mudança e reinicie o serviço SplunkWeb:

$SPLUNK_HOME/bin/splunk restart splunkweb

Crie um túnel SSH entre seu computador e servidor remoto:

ssh user@your-splunk-server.com -L 1080:localhost:8000

Abra seu navegador no endereço: http://localhost:1080/en-US/app/launcher/home

Pronto! Você verá que a interface gráfica web será exibida mesmo sem estar exposta a Internet. 👌

Como se pode observar na representação do triângulo, existe uma interdependência entre estes aspectos. À medida que tornamos um sistema mais seguro, dificultamos seu uso e perdemos em termos de funcionalidade. Ou seja, em teoria, um sistema perfeitamente seguro seria tão difícil de usar ou com tão poucas funcionalidades que se tornaria inútil.

Na contramão deste processo observamos o crescimento da Autenticação sem Senha ou Passwordless Authentication, com a finalidade de proporcionar, simultaneamente, maior segurança e usabilidade (facilidade de uso). Mas o quanto disso é verdade?

Em primeiro lugar, precisamos perceber que a proteção de dados por senhas já não é mais suficiente. Segundo relatório da Verizon, estima-se que aproximadamente 81% dos incidentes com comprometimento de dados ocorrem em razão de senhas fracas ou roubadas.

Somado a este cenário, em enquete realizada pelo Google / Harris Poll, aponta que 52% dos respondentes utilizam a mesma senha em vários serviços e 13% utiliza a mesma senha em todas as suas contas.

Na autenticação sem senha a verificação das credenciais não depende do segredo de algo que usuário sabe (a senha), mas sim de algo que o identifica de forma única (posse).

A autenticação sem senha anda de mãos dadas com outro conceito, denominado autenticação de dois fatores (two factor authentication - 2FA) que utiliza, por exemplo, uma segunda senha de uso único ou "link mágico" enviado por e-mail, SMS, por meio de aplicativos instalados no celular, biometria (iris, digital, face etc.) ou ainda tokens UF2/FIDO.

Alguns benefícios no uso da autenticação sem senha incluem:

• melhor experiência do usuário;
• simplificação na gestão de senhas pela área de TI;
• menor exposição a ataques de força bruta, phishing, keylogging ou roubo de credenciais;

Mas finalmente respondendo a pergunta... É seguro utilizar Autenticação sem Senha?

Bem, isso depende principalmente do método utilizado. Entre os mais fracos estão os links mágicos ou códigos de uso único enviados por e-mail. Isso porque a segurança estará diretamente relacionada a segurança do e-mail que pode utilizar para autenticação a forma convencional de usuário e senha. Em terceiro lugar eu elegeria o SMS. Apesar de estar sujeito a ataques de SIM Swap ou interceptação, é bem mais seguro do que o e-mail, e a mensagem é entregue diretamente para algo que o usuário de fato tem a posse física, no caso, o celular.

No segundo lugar os aplicativos de autenticação no celular. Esse método resolve o problema do SIM Swap, mas normalmente requer que você armazene de forma segura, geralmente de forma impressa, códigos de backup para o caso de perda do aparelho. Ainda assim gosto bastante desta abordagem. No topo da lista e primeiro lugar estão os tokens UF2/FIDO. Estes dispositivos podem combinar múltiplos fatores de autenticação, como biometria da digital, e utiliza técnicas avançadas de criptografia assimétrica.

Os maiores problemas na autenticação sem senha, como já mencionado, são os custos elevados dependendo da solução, não protege contra ataques de SIM Swap, pode ser um problema para o usuário no caso da perda do dispositivo (celular ou token) e a biometria não é a prova de falhas. Apesar de tudo, é um controle de segurança que vale à pena. O Google, por exemplo, iniciou no ano passado a adoção de 2FA para seus usuários e já reduziu em 50% o comprometimento de contas entre os usuários que adotaram.