Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
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.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
secdim-assurance-drift-challenge — SecDim Challenge Builder repro inspirado na CVE-2026-88861: bypass de MFA AAL1 na fronteira de credenciais privilegiadas | Kitploit
Ferramentas/GitHubGitHub/franklincg/secdim-assurance-drift-challenge
Autenticação e AutorizaçãoAnálise de VulnerabilidadesSegurança WebCTFGerenciamento de Identidade e Acesso (IAM)Aprendizado e EducaçãoSegurança de APILabs e Prática

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
GitHub
franklincg/secdim-assurance-drift-challenge

secdim-assurance-drift-challenge

SecDim Challenge Builder repro inspirado na CVE-2026-88861: bypass de MFA AAL1 na fronteira de credenciais privilegiadas

Ver Repositório
24há 20 diasAinda não revisado

SecDim Challenge Builder Repro — Assurance Drift

Reprodução funcional para um desafio de segurança proposto, inspirado no CVE-2026-88861, publicado em 10 de setembro de 2026.

Conceito de segurança

A aplicação verifica corretamente uma sessão assinada e verifica corretamente a função admin, mas colapsa duas propriedades de segurança independentes: identidade/função e garantia de autenticação. Uma sessão aal1 apenas com senha pode chamar um caminho privilegiado de criação de credenciais que deveria exigir MFA de elevação (aal2). A chave de admin resultante, com escopo de aplicação, é durável e permanece utilizável após o logout da sessão original.

Isso modela uma falha realista de bypass de MFA na fronteira de autorização, em vez de uma assinatura quebrada ou um token forjado.

Reprodução funcional

go test -v ./...

Os testes demonstram a cadeia de ataque local completa:

  1. obter uma sessão de admin válida e assinada, apenas com senha (aal1);
  2. usar o caminho de autorização vulnerável para cunhar uma chave de API privilegiada;
  3. fazer logout da sessão original;
  4. continuar executando ações privilegiadas com a chave cunhada.

Nenhum serviço externo, credencial ou alvo de produção está envolvido.

Formato pretendido do desafio

  • Stack: Go, apenas biblioteca padrão
  • Dificuldade sugerida: intermediário / avançado
  • Lição principal: MFA é uma propriedade de autorização para operações sensíveis, não apenas uma etapa de UI de login.
  • Tarefa do aprendiz: preservar verificações de função, revogação de sessão e comportamento normal do usuário, ao mesmo tempo que impõe garantia de elevação em toda fronteira durável de escalonamento de privilégios.
  • Direções de testes ocultos: verificações independentes de função vs. AAL, sessões obsoletas/revogadas, sessões rebaixadas, criação/rotação de chaves, declarações de garantia malformadas e garantir que AAL2 não conceda acidentalmente a função de admin.
  • Por que não é trivial: o token é válido e corretamente assinado; a função é válida; a falha é semântica e ocorre após a autenticação bem-sucedida. Correções que apenas fortalecem a verificação de token, adicionam MFA no login ou verificam apenas a função ainda falham no contrato de segurança.

Mapeamento

  • CWE-288 — Authentication Bypass Using an Alternate Path or Channel
  • CWE-287 — Improper Authentication
  • OWASP A07:2021 — Identification and Authentication Failures
  • Temas OWASP API5/API6 — autorização de função e fluxos de negócios sensíveis

Fundamentação

O cenário é inspirado na falha de imposição de nível de garantia descrita para o CVE-2026-88861 (sessão AAL1 do Capgo/Supabase contornando MFA em um caminho RBAC privilegiado). Esta reprodução é original, reduzida e autocontida; ela não copia o projeto afetado.

Remediação demonstrada

secureCreatePrivilegedAPIKey exige tanto autorização admin quanto garantia de elevação aal2, enquanto activePrincipal impõe independentemente a revogação de sessão. Os testes verificam intencionalmente que nenhuma das condições substitui a outra.

Baixar ferramenta