Marcos Maia
Penetration Tester | Web & API Security | Bug Bounty Researc
New to Contra
Marcos is ready for their next project!
Security Research — Aiven (Bugcrowd)
Descrição:
Pesquisa de segurança no programa "Aiven Managed Bug Bounty" no Bugcrowd, com foco nos repositórios open-source da Aiven (github.com/Aiven-Open e github.com/Aiven), via revisão de código-fonte.
Achado principal (submetido):
IDOR / Broken Access Control em Klaw (Aiven-Open/klaw) — a função updateUser() não aplica escopo de tenant na validação de permissão, permitindo que um usuário com a permissão comum ADD_EDIT_DELETE_USERS edite contas de usuários de outros tenants. Resultado: account takeover cross-tenant, quebrando o isolamento multi-tenant da plataforma.
Trabalho adicional no engajamento:
Achado em Karapace (Aiven-Open/karapace): bypass de ACL do Schema Registry via schema references, permitindo exfiltração de schema cross-subject (mais um bug secundário de ValueError no parser Protobuf) — submetido, marcado como duplicate de report anterior
Revisão de pghoard: identificada falha de validação de filename (webserver.py (http://webserver.py)) que ocorre só para obtype=="archive" — requisição direta a /site/timeline/X ou /site/xlog/X pula a checagem, mas o traversal via HTTP é limitado a 1 nível, sem vazamento de conteúdo real (severidade baixa/hardening)
Auditoria de restore.py (http://restore.py) e postgres_command.py (http://command.py) do pghoard — path traversal e validação de endpoint confirmados como bem protegidos, sem achado adicional
guardian-for-apache-kafka analisado e descartado (projeto deprecated/read-only)
Metodologia:
Priorização de repositórios open-source com maior número de "known issues" documentados pelo programa, como superfície de maior densidade de bugs reais
Validação de cada hipótese de access control contra o fluxo de autorização real do código, não apenas inspeção estática
Documentação de becos sem saída (pghoard bem protegido) pra evitar retrabalho em sessões futuras
Stack/skills: Java/Kotlin (Klaw), Python (Karapace, pghoard), IDOR/broken access control, multi-tenancy security, schema registry/ACL review, source-code review em larga escala.
1
24
Security Research — Circle / Arc Network
Descrição:
Pesquisa de segurança no programa HackerOne da Circle/Arc, via revisão de código-fonte dos repositórios malachite (consenso BFT em Rust) e arc-node. Metodologia focada em execução prática direta, sem gastar ciclos em recon extenso.
Achado principal:
Precompile pós-quântico (PQ) do arc-node registrado sem gate de hardfork — crates/precompiles/src/precompile_provider.rs (http://provider.rs) e pq.rs (http://pq.rs) recebem o parâmetro _hardfork_flags (ativação do hardfork Zero6) mas nunca o usam, deixando o precompile run_pq chamável antes da ativação planejada. PoC funcional (não apenas análise estática): teste poc_pq_precompile_callable_before_zero6_activation executa verificação de assinatura SLH-DSA real (~378k gas) num chain spec sem Zero6 ativado, confirmando a execução do código fora da janela prevista.
Report fechado como "Informative" pelo analista — alegou que o precompile "funciona corretamente, sem impacto de segurança real" — mas o achado demonstra controle de ativação de hardfork quebrado, validado com execução real de criptografia pós-quântica, não suposição teórica.
Trabalho adicional no engajamento:
PoC ao vivo confirmado de Sign() sem autenticação no arc-remote-signer (qualquer cliente de rede podia assinar mensagens de consenso arbitrárias) — fechado como duplicate
Revisão full-depth de malachite (votekeeper, sync, validator-proof, proposal_keeper) e dos precompiles nativos do arc-node (native coin authority/control, system accounting) — auth gates e aritmética segura confirmados, sem brecha adicional
Análise de política KMS do enclave attestation do arc-remote-signer — hipótese de bypass por permissão incondicional no IAM sobrepondo a condição de atestação, ainda não testada em ambiente AWS próprio
Stack/skills: Rust, blockchain consensus (BFT), criptografia pós-quântica (SLH-DSA), hardfork/versioning logic, remote signing security, source-code review.
1
25
Security Research — Auth0 (Okta)
Descrição:
Pesquisa de segurança no programa Bugcrowd da Auth0 (Okta), com foco nos SDKs públicos (auth0-spa-js, auth0.js, nextjs-auth0, express-openid-connect, auth0-react). Trabalho orientado por revisão de código-fonte e validação prática em aplicações reais, não apenas análise estática.
Principais achados:
Cache key collision em auth0-spa-js: o delimitador :: usado em CacheKey.toKey()/fromKey() (src/cache/shared.ts) não é escapado, permitindo colisão entre chaves de cache de audience/scope diferentes. PoC confirmado contra o CacheManager real (compilado via tsc), com exploitability condicionada a aplicações multi-tenant que derivam audience/scope de input controlável pelo usuário.
Nonce validation bypass em auth0.js: falha no idtoken-verifier que pula a checagem de nonce quando o valor esperado é nulo. PoC completo end-to-end, não apenas no módulo isolado: tenant Auth0 próprio, app SPA real, dois usuários (atacante e vítima), fluxo implicit (response_type=id_token) rodando auth0-js de verdade. Resultado confirmado — o id_token do atacante foi aceito sem erro pelo parseHash() na sessão da vítima, com sub e nonce do payload batendo com o atacante.
Metodologia:
Leitura exaustiva de cada SDK antes de testar, priorizando exploração real de app (exigência do programa — função isolada não exposta não é aceita)
Reprodução de rejeição inicial: primeiro PoC do nonce bypass foi recusado por "não reproduzível" (testava só o idtoken-verifier isolado); refeito com ambiente de app real completo até reproduzir o bypass de ponta a ponta
Varredura ampla de nextjs-auth0 (backchannel logout, transaction-store, path traversal em proxy, WebAuthn/passkey) — a maioria descartada por hardening já existente, documentando becos sem saída pra não retestar
Stack/skills: JavaScript/TypeScript, OAuth2/OIDC, JWT, cache poisoning, auth bypass, SDK security review, browser-based PoC engineering.
1
35
Security Research — TRON DAO (java-tron)
Descrição:
Auditoria de segurança em código-fonte contra o programa HackerOne da TRON DAO, com foco no repositório principal tronprotocol/java-tron (toda a base de blockchain, incluindo a TVM — Tron Virtual Machine).
Trabalho cobriu múltiplas camadas do sistema: actuators de transação, processamento de energia/gas, precompiles nativos da TVM, camada JSON-RPC, validação de assinaturas multi-sig, e o pool shielded (privacidade via zk-proofs).
Principais achados (8 reports submetidos):
Critical — CVSS 9.1: Integer underflow em ValidateMultiSign, resultando em valor de energia negativo (-1500). Falha crítica de validação que poderia ser explorada para manipular o custo computacional de transações na rede.
High: Ausência de checkedAdd em CancelAllUnfreezeV2, abrindo brecha para overflow no fluxo de unfreeze de saldo.
High: Falha em EnergyProcessor.scaleByRate, afetando o cálculo correto de energia cobrada por transação.
Reports adicionais relacionados a validação de assinatura, controle de versão de fork e inconsistências de processamento de exceção na TVM.
Metodologia:
Revisão manual linha a linha dos actuators e módulos críticos (sem depender de scanners automatizados)
Validação cruzada de cada hipótese contra o estado real da mainnet (via wallet/getchainparameters) antes de reportar, evitando falsos positivos de bugs já corrigidos por fork
Deploy de contrato Solidity próprio em testnet Nile para gerar PoC funcional e reproduzível do underflow de energia
Análise de forks ativos (ForkController/VERSION_4_8_2_2, ativação Osaka) para confirmar se vulnerabilidades candidatas ainda estavam explorável em produção
Stack/skills: Java, Solidity, Foundry, blockchain security, EVM/TVM internals, integer overflow/underflow, cryptographic validation (zk-SNARK/shielded pool), source-code review em larga escala.
1
33