Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2020-3580 — Cisco ASA XSS CVE-2020-3580 | Kitploit
Ferramentas/GitHubGitHub/cruxn3t/cve-2020-3580
ReconhecimentoAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebColeta de InformaçõesTestes de Penetração
GitHubcruxn3t/cve-2020-3580

CVE-2020-3580

Cisco ASA XSS CVE-2020-3580

Ver Repositório
há 3 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CVE-2020-3580

XSS refletido em Cisco ASA / FTD no endpoint ACS do WebVPN SAML SP (/+CSCOE+/saml/sp/acs). Corrigido em cisco-sa-asaftd-xss-multiple-FCB3vPZe.

Este repositório contém:

  • xss.html — um PoC verificável por humanos para alvos autorizados.
  • src/ — um pipeline de descoberta e validação ciente de escopo.
  • docs/ — metodologia e ética.

O que o pipeline faz

root@kitploit:~
┌──────────┐   ┌──────────────┐   ┌────────────────────┐   ┌────────────────┐   ┌──────────────┐
│ Shodan   │ → │ correspond.  │ → │ aprovação manual   │ → │ verificação    │ → │ rascunho     │
│ (3 dorks)│   │ de escopo    │   │ negação por padrão │   │ canário        │   │ de relatório │
└──────────┘   └──────────────┘   └────────────────────┘   └────────────────┘   └──────────────┘

Cada estágio grava um artefato JSON inspecionável e executa de forma independente.

O validador não dispara alert(). Ele envia via POST uma string canário única contendo <>"' puros e avalia o corpo da resposta. Confirmações recebem um rascunho em Markdown com o xss.html original incluído para que o revisor do programa verifique em seu próprio navegador.

A validação é controlada por aprovação. Uma correspondência de escopo é apenas um ponto de partida; o briefing atual do programa é o contrato. Antes da validação ativa, revise a política do programa e defina as flags de aprovação do alvo em data/validation_approvals.json.

Configuração

root@kitploit:~
git clone https://github.com/cruxN3T/CVE-2020-3580
cd CVE-2020-3580
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp creds.env.example creds.env
$EDITOR creds.env   # adicione sua chave Shodan e, opcionalmente, tokens H1/BC

creds.env está no .gitignore. O .gitignore bloqueia qualquer arquivo que corresponda a *.env (exceto *.env.example), além de data/ e reports/, para manter listas de alvos e trechos de validação fora do repositório público.

Uso

O comando padrão de ponta a ponta intencionalmente para antes da validação:

root@kitploit:~
python -m src.pipeline run

Isso grava data/validation_approvals.json com todas as flags de aprovação definidas como false. Revise cada briefing de programa atual e defina os três campos como true somente quando o alvo ainda estiver no escopo e esse tipo de validação for permitido:

root@kitploit:~
{
  "manual_policy_reviewed": true,
  "automated_testing_allowed": true,
  "cve_testing_allowed": true
}

Em seguida, valide e gere os rascunhos de relatório:

root@kitploit:~
python -m src.pipeline validate
python -m src.pipeline report

Ou estágio por estágio:

root@kitploit:~
python -m src.pipeline discover            # Shodan → data/shodan_hits.json
python -m src.pipeline scope               # correspondência → data/in_scope.json
python -m src.pipeline approve-template    # → data/validation_approvals.json
python -m src.pipeline validate            # somente verificações canário aprovadas
python -m src.pipeline report              # → reports/<host>__CVE-2020-3580.md

Apenas para alvos de laboratório privado, validate --allow-unapproved dispensa o arquivo de aprovação. Para appliances legados em que a validação de certificado é impossível, validate --allow-insecure-tls desativa a verificação TLS nessa execução.

O estágio scope funciona sem nenhuma chave de API — ele busca dados de arkadiyt/bounty-targets-data. Adicionar H1_USERNAME + H1_API_TOKEN ao creds.env pode complementar isso com dados recentes da HackerOne Hacker API quando H1_LIVE=true estiver definido.

Configuração

Tudo vive em creds.env. Consulte creds.env.example para a lista completa. As opções que vale a pena conhecer:

  • SCOPE_PLATFORMS — separado por vírgulas. O padrão é hackerone,bugcrowd. Adicione intigriti e yeswehack se quiser uma cobertura mais ampla.
  • TARGET_RPM — requisições por minuto por host. O padrão é 10. Não aumente sem um motivo.
  • TLS_VERIFY — o padrão é true.
  • REQUIRE_VALIDATION_APPROVAL — o padrão é true.

Leia estes antes de executar

  • docs/ETHICS.md — o que a correspondência de escopo autoriza e o que não autoriza, e o que o validador deliberadamente não faz.
  • docs/METHODOLOGY.md — como funciona a classificação de reflexão e por que cada estágio existe.

O que este repositório não é

Não é uma ferramenta de exploração em massa. Não é um 0day. Não substitui a leitura do briefing do programa na plataforma antes de você enviar. O correspondente de escopo é um ponto de partida; o texto da política é o contrato.

Licença

MIT. Consulte LICENSE.

Baixar ferramenta